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

Автоматизация 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. На возможную критику о том, что данный подход может быть применен только в компаниях, где уровень зрелости ИБ уже достаточно высок, стоит отметить, что он был также удачно опробирован и на опыте «бирюзовой» компании. 

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

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