Автоматизация AppSec. Как обеспечить безопасность и защищённость продуктов в сжатые сроки

BIS Journal №2(49)2023

17 мая, 2023

Автоматизация AppSec. Как обеспечить безопасность и защищённость продуктов в сжатые сроки

Сложность и скорость процессов производства ИТ-продуктов растут с каждым годом: увеличивается количество инструментов, объём кодовой базы, а вместе с тем и число уязвимостей в ПО, что пропорционально усложняет задачи по обеспечению безопасности ИТ-продуктов. В связи с постоянно растущим количеством кибератак и сложностью ИТ-ландшафта ИБ должно менять свои традиционные методы и подходы, подстраиваясь под новую реальность с помощью автоматизации.

 

ПРОДУКТ ИЛИ БЕЗОПАСНОСТЬ?

Продуктовая безопасность — это одна из наиболее актуальных областей информационной безопасности, в то же время испытывающая голод в области средств контроля и экспертов. На сегодняшний день ИТ-ландшафт практически любой компании, устроенной по принципу «Энтерпрайз», — это логически сложная, технологически гетерогенная и распределённая инфраструктура, которая в любой момент может быть подвержена кибератаке. И тем не менее для большинства ИТ-компаний, производящих цифровые продукты и владеющих ими, ключевой фактор — показатель T2M (Time to Market). Скорость, с которой продуктовые команды должны представлять новые релизы, чтобы соответствовать требованиям рынка и интересам бизнеса, вытесняет вопросы безопасности на второй план. 

Поэтому современные задачи по обеспечению защищённости требуют трансформаций от команд ИБ: большего уровня погружения и скорости реагирования, чем было несколько лет назад, освоения новых подходов, практик и инструментов. 

5 ключевых принципов, по которым должно сейчас работать продуктовое ИБ:

  • обеспечивать безопасность «по дизайну» и иметь фокус на автоматизацию;
  • уметь работать с инновациями и обеспечивать Compliance при постоянно меняющихся правилах и требованиях;
  • быть прозрачным и удобным для цифрового потребления сервисов;
  • быть быстрее ИТ, работая на опережение;
  • отсутствие задержек и трений при взаимодействии ИТ и ИБ.

Чтобы безопасность приложений, из которых строится продукт, стала одной из ключевых ценностей для разработчиков, а не только страхом перед вероятностью киберугрозы или исполнением обязательных требований регуляторов, необходимо выстроить корректный процесс безопасной разработки. Один из способов достижения данной цели — автоматизация контролей ИБ, которая достигается созданием платформенных решений.

 

ФОКУС НА АВТОМАТИЗАЦИЮ, УДОБСТВО И ПРОЗРАЧНОСТЬ

Определив для себя, что количество ручных операций ИБ и явных Security Gates для команд разработки должно быть снижено, мы сформировали подход предоставления сервисов ИБ через платформы (рис. 1). Они работают в режиме Self-Service (единое окно для самостоятельного взаимодействия с функциями ИБ) и поддерживают процесс безопасного производства с помощью интеграции этих контролей «под капот» (непрерывные сканирования и контроли на каждом этапе создания приложения). Это позволяет повысить уровень наблюдаемости за процессом создания приложений и получить больший объём информации, что приводит к внедрению контролей ИБ с качественным уровнем погружения в контекст.

Рисунок 1. Подход предоставления сервисов ИБ через платформы

 

Внедрение большего количества «целевых» контролей, выставленных на различных этапах процесса, позволяет на этапах сборки, доставки и частично производства применить проактивный подход к безопасности создаваемых приложений. Таким образом, снизить нагрузку на команду продуктов за счёт более раннего обнаружения уязвимостей, большого количества подсказок, рекомендаций, шаблонов корректного использования Inner Source экосистемных компонентов и недопущения возможности использования недоверенного компонента, который может использоваться для блокирования уязвимости типа PROTESTWARE (рис. 2, 3).

Рисунок 2. Пример того, как может быть интегрирована платформа в процесс производства продукта

 

Рисунок 3. Принцип работы с платформой для продуктовой команды

 

При таком подходе построения процессов ИБ удаётся качественно повысить уровень их прозрачности и получать большое количество сводной и скоррелированной информации, специально проработанных метрик и статистик в реальном или почти реальном времени. Это помогает не только продуктовым командам и ИБ, но и смежным подразделениям — IP Compliance, HR и даже C-Level, позволяя им отслеживать уровень «здоровья» продукта и его зависимостей по ИБ в удобном дашборде с понятными и описанными метриками. 

 

КОРОТКО ПРО МЕТРИКИ И ФАКТЫ

Сейчас ни одна сфера бизнеса не может представить свою работу без метрик, но интеграция аналитики до сих пор вызывает немало вопросов и проблем. С помощью разработанного подхода через автоматизированную платформу можно получить доступ к информации о составе продукта, результатов анализа SAST, SCA (например, статистику по уязвимостям и OSS компонентам, стеки разработки и лицензии). Также о Supply Chain, релизах и экземплярах (например, динамику появления и исправления уязвимостей, их жизненный цикл, Products Security Heatmap) и о профиле разработчиков, поверхности атаки, исторических данных. Например, жизненный цикл анализаторов и контролей, технический долг по ИБ и его стоимость, наиболее часто допущенные уязвимости при разработке и пр. 

И это подводит к одной из краеугольных проблем текущего уровня ИТ и ИБ-специалистов в России — их профессионализму и пониманию процессов безопасности. 

 

ВЗАИМОДЕЙСТВИЕ ИТ И ИБ: НАВСТРЕЧУ ДРУГ ДРУГУ

К сожалению, большинство разработчиков до сих пор не воспринимают безопасность как ценность продукта, а относятся к ней скорее как к теоретической данности или навязанной необходимости. На это, в частности, влияет и общепринятый подход ИБ — запрещать, не вдаваясь в подробности. Чтобы перебороть этот тренд, необходимо предложить команде разработчиков удобные процессы и факты, которые позволят быстро выявлять и анализировать наиболее частые ошибки, разбирать их на реальных уязвимостях в продукте, определять индивидуальный вектор обучения и отслеживания успехов разработчика. 

Это требует и пересмотра функциональности инженеров ИБ. С повышением уровня зрелости ИБ, а именно глубинного внедрения платформ ИБ в производство продуктов и масштабированием этого подхода на большее количество команд, обязательным требованием для специалистов ИБ стало понимание процессов производства и умение интегрировать безопасность в эти процессы. Для эффективной работы с ИТ над ценностью продукта специалисты ИБ должны уметь говорить с ними на одном языке, понимать малейшие нюансы продукта и уметь программировать. К сожалению, без этих навыков современный AppSec не получит качественного изменения процессов ИБ и уважительного отношения со стороны команд разработчиков. 

 

РАБОТАЮЩИЙ МЕТОД

Описанный подход через платформы ИБ уже с успехом внедряется в Дзен и в других продуктах и приложениях VK. На возможную критику о том, что данный подход может быть применен только в компаниях, где уровень зрелости ИБ уже достаточно высок, стоит отметить, что он был также удачно опробирован и на опыте «бирюзовой» компании. 

Платформы ИБ легко встроить в существующие процессы производства и эксплуатации за счёт большого уровня универсализации и широких возможностей интеграции. Это позволяет реализовать контроли прозрачно и в непрерывном режиме, а за счёт их гибкости ИБ и ИТ могут в дальнейшем совместно повышать общую зрелость без задержек и трений между двумя командами. Наш опыт показывает, что с повышением прозрачности процессов ИБ и демонстрацией реального уровня безопасности и защищённости ИТ-продукта возрастает и уровень лояльности продуктовой команды к ИБ. Это, в свою очередь, влияет на качество и количество исправленных уязвимостей командой ИТ без эскалации и дополнительных напоминаний со стороны команды ИБ. 

Подход через платформы ИБ не серебряная пуля, его основной минус — высокие требования к инженерам ИБ, потому что им нужно понимать процессы производства, уметь разрабатывать средства защиты, системы-оркестраторы и платформы, а также дорабатывать уже существующие анализаторы. Но есть и плюсы — таких инженеров требуется намного меньше. 

Стать автором BIS Journal

Смотрите также

Подписаться на новости BIS Journal / Медиа группы Авангард

Подписаться
Введите ваш E-mail

Отправляя данную форму вы соглашаетесь с политикой конфиденциальности персональных данных

01.03.2024
Банки будут строже следить за криптотранзакциями, связанными с дропперами
01.03.2024
Холода прошли, но голос берегите — скамеры усиленно собирают слепки
01.03.2024
Лишение банковской лицензии — это ещё не всё
01.03.2024
«Они подобны смартфонам на колёсах». В США проверят «умные» авто из Китая
01.03.2024
Набиуллина: Дважды «красные» клиенты будут исключаться из реестра
01.03.2024
Банк России усовершенствует платформу цифрового рубля
01.03.2024
Организации здравоохранения США стали жертвами массовых кибератак
29.02.2024
«ИнфоТеКС» — о проблемах стандартизации ИБ
29.02.2024
Почему нормативные акты выполняются формально
29.02.2024
Почему затянулся переход на российские решения

Стать автором BIS Journal

Поля, обозначенные звездочкой, обязательные для заполнения!

Отправляя данную форму вы соглашаетесь с политикой конфиденциальности персональных данных