Безопасная разработка является неотъемлемой частью непростого пути к безопасности приложений. И у всех руководителей и лидов R&D, кто задумывается о построении у себя AppSec, возникает вопрос — с чего же начать? А начать нужно с организации процессов: определить положение дел, понять, какие активности необходимо внедрить, какие оптимизировать, а какие убрать. В общем, оценить зрелость текущих процессов безопасной разработки и обозначить дальнейшие шаги в светлое AppSec-будущее компании. И тут на помощь нам приходят фреймворки по безопасной разработке.

Привет! Меня зовут Артем Кармазин, я старший консультант внедрения процессов безопасной разработки Positive Technologies. Существует множество методологий для оценки зрелости компании в части AppSec, например OWASP SAMM, DSOMM, OpenSAMM, Microsoft SDL и BSIMM. О BSIMM и будет идти речь дальше, поскольку на сегодняшний день это один из самых популярных фреймворков в безопасной разработке.

Что такое BSIMM14

В конце 2023 года Synopsys опубликовал ежегодный отчет BSIMM14, основанный на анализе подходов к обеспечению безопасности программного обеспечения в 130 организациях. Сам отчет содержит статистические данные о мерах безопасности, применяемых в организациях, и в нем даже упомянута тема безопасности LLM, ведь она сейчас у всех на слуху, и еще много чего интересного. На официальном сайте Synopsys можно подробнее ознакомиться с отчетом. А мы остановимся на самой методологии.

Внедряем безопасную разработку с помощью BSIMM. Теория

Building Security in Maturity Model (BSIMM) — это методология оценки процессов безопасной разработки программного обеспечения в организации. Благодаря данной методике можно определить, на какой стадии находятся текущие процессы и какая отправная точка к повышению уровня зрелости — экспертизы сотрудников и подходов к разработке.

BSIMM распределяется на 4 домена:

• Governance— практики, которые помогут организовать процессы и управлять ими, а также оценивать инициативы безопасной разработки.

• Intelligence— практики по сбору информации обо всем, что связано с безопасной разработкой в организации.

• SSDL Touchpoints — содержит практики анализа артефактов и процессов в рамках разработки ПО.

• Deployment — практики, отвечающие за взаимодействие с подразделениями инфраструктурной и сетевой безопасности.

Домены, в свою очередь, делятся на 12 практик. В каждом домене 3 практики.

Практики BSIMM:

1. Governance:

• Strategy & Metrics.

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

• Compliance & Policy.

  Помогает комплексно подойти к выполнению всех требований регуляторов, проводить аудиты и контроль соответствия.  

• Training.

  Описывает подходы к повышению компетенций всех заинтересованных лиц. Помимо обучения, учтены и активности по поощрению достижений в учебе, не забыли про обучение для подрядчиков и аутсорсинговых сотрудников.

2. Intelligence:

• Attack Models.

  Предназначена для того, чтобы сформировать понимание, какая угроза по-настоящему актуальна, какова вероятность ее возникновения и какие категории злоумышленников могут навредить данным.

• Security Features & Design.

  Описывает коммуникации архитектурных и ИБ-подразделений, а также подходы к проектированию архитектуры.

• Standards & Requirements.

  Отвечает за формирование требований, мер безопасности, соблюдение стандартов и других документов, регулирующих отрасль. Для того чтобы в процесс были вовлечены все заинтересованные, описывает этапы создания внутреннего портала.

3. SSDL Touchpoints:

• Architecture Analysis.

Описывает анализ архитектуры с учетом рисков, применение стандартизации к архитектурному описанию и как сделать ранжирование приложений по уровню риска.

• Code Review.

Отвечает за использование инструментов безопасной разработки в CI/CD (например, статический анализ), автоматизацию обнаружения уязвимостей, создание кастомных правил и соблюдение best practices в разработке.

• Security Testing.

Помогает настроить процесс обнаружения дефектов, автоматизацию тестирования безопасности и практики QA.

4. Deployment:

• Penetration Testing.

Объясняет, как организовать процесс тестирования на проникновение и обработку этих результатов.

• Software Environment.

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

• Configuration Management & Vulnerability Management.

Описывает работу с уязвимостями, взаимодействие подразделений при реагировании на инциденты и меры по обнаружению дефектов.

Вот перечень всех активностей, структурированных по практикам и доменам. BSIMM распределяет активности по трем уровням зрелости, показывая, насколько популярна сама практика и как часто она применяется. Чем выше уровень — тем сложнее практика.

На каждой активности останавливаться не будем, давайте посмотрим на те, которые входят в топ-10 активностей BSIMM14 и считаются самыми популярными.

1. [SM1.4] Внедрение и контроль quality gates

Суть: Постепенный подход к внедрению контрольных точек безопасности позволит командам на начальном этапе определять, что является критичным в разработке и как это не допускать в дальнейшем, не блокируя сам конвейер.

2. [CP1.1] Стандартизация требований регуляторов

Суть: Комплексный подход к определению требований регуляторов поможет не упустить нормативные нюансы и заложить все требования еще на начальных этапах жизненного цикла.

3. [CP1.2] Обеспечение конфиденциальности

Суть: Тут все понятно, квадратное не катим, круглое не носим, конфиденциальные данные защищаем.

4. [SR1.2] Создание внутреннего портала

Суть: Внутренний портал по безопасности поможет всем заинтересованным быстро найти нужную информацию, изучить подходы к безопасности и поделиться чем-то полезным.

5. [AA1.1] Реализация проверки безопасного проектирования

Суть: Не секрет, что при проектировании архитектуры должны быть заложены функции безопасности (например, шифрование, контроль доступа и так далее). 

6. [CR1.4] Использование инструментов автоматического анализа исходного кода

Суть: Must have в безопасной разработке. Ведь применение SAST-инструментов позволит выявлять уязвимости еще до того, как артефакты попали в сборку.

7. [ST1.1] Тестирование пограничных значений в ходе QA

Суть: Команда QA, помимо функционального тестирования, проводит базовые тесты злоумышленника, чтобы проверить те или иные условия.

8. [PT1.1] Привлечение внешних специалистов для поиска уязвимостей

Суть: Одна из активностей, которая поможет определить, насколько ваше приложение безопасно. Очень важно смотреть на подход к безопасности с различных векторов.

9. [SE1.2] Обеспечение базовой безопасности сети

Суть: Пункт, без которого построение безопасной инфраструктуры абсолютно невозможно.

10. [CMVM1.1] Реагирование на инциденты

Суть: Быстрое и организованное реагирование на инциденты позволит оперативно восстановить работоспособность и корректное функционирование приложения или инфраструктуры. Ведь нарушение доступности, целостности и конфиденциальности несет за собой не только репутационные риски, но и материальные.

А еще относительно BSIMM13 добавилась новая активность, связанная с обеспечением целостности инструментов разработки (SE3.9). Суть данной практики заключается в предотвращении несанкционированных изменений в исходном коде и других артефактов жизненного цикла.

Смотрим, как все устроено на практике

Представим, что мы небольшая компания, где трудится десяток программистов, и мы хотим вывести безопасность разработки на уровень выше. Для начала необходимо определить, какие активности у нас уже запущены, а какие необходимо внедрить, и обозначить сроки. Временной промежуток обычно определяют в 3 года — это оптимальный вариант. Да, процесс построения безопасной разработки небыстрый, поэтому стоит как можно раньше начать.

Для удобства разобьем наш план поквартально. Пример подхода показан на практике «Стратегия и метрики» домена «Управление».

После того как мы прошлись по каждому домену, у нас есть четкий план реализации активностей и перечень уже существующих.

 Для наглядности BSIMM рекомендует строить радиальную диаграмму, на ней видно текущий уровень зрелости и как этот уровень будет меняться в запланированный период. С таким представлением уже не стыдно приходить к руководству и показывать наши грандиозные планы.

Необходимо помнить, что выбор методологии — важный этап на пути к построению процессов безопасной разработки. Кто-то использует уже готовые фреймворки, такие как BSIMM, DSOMM, OWASP SAMM и другие. А кто-то разрабатывает свои, исходя из собственных целей и задач. В конечном итоге главное понять, в каких аспектах компании необходимо подрасти, как улучшить и поддержать текущие процессы.

Вот здесь можно посмотреть, какие еще существуют фреймворки на данный момент. P. S. Там не только про фреймворки, а еще много чего интересного!