Безопасная разработка является неотъемлемой частью непростого пути к безопасности приложений. И у всех руководителей и лидов 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:
Governance:
Strategy & Metrics.
Помогает понять, как подойти к процессу планирования, какие роли и обязанности необходимо определить, какие метрики сформировать для достижения заветных целей в безопасной разработке.
Compliance & Policy.
Помогает комплексно подойти к выполнению всех требований регуляторов, проводить аудиты и контроль соответствия.
Training.
Описывает подходы к повышению компетенций всех заинтересованных лиц. Помимо обучения, учтены и активности по поощрению достижений в учебе, не забыли про обучение для подрядчиков и аутсорсинговых сотрудников.
Intelligence:
Attack Models.
Предназначена для того, чтобы сформировать понимание, какая угроза по-настоящему актуальна, какова вероятность ее возникновения и какие категории злоумышленников могут навредить данным.
Security Features & Design.
Описывает коммуникации архитектурных и ИБ-подразделений, а также подходы к проектированию архитектуры.
Standards & Requirements.
Отвечает за формирование требований, мер безопасности, соблюдение стандартов и других документов, регулирующих отрасль. Для того чтобы в процесс были вовлечены все заинтересованные, описывает этапы создания внутреннего портала.
SSDL Touchpoints:
Architecture Analysis.
Описывает анализ архитектуры с учетом рисков, применение стандартизации к архитектурному описанию и как сделать ранжирование приложений по уровню риска.
Code Review.
Отвечает за использование инструментов безопасной разработки в CI/CD (например, статический анализ), автоматизацию обнаружения уязвимостей, создание кастомных правил и соблюдение best practices в разработке.
Security Testing.
Помогает настроить процесс обнаружения дефектов, автоматизацию тестирования безопасности и практики QA.
Deployment:
Penetration Testing.
Объясняет, как организовать процесс тестирования на проникновение и обработку этих результатов.
Software Environment.
Описывает подходы к мониторингу приложений, объясняет, как внедрить средства контроля облачной безопасности, оркестрацию контейнеров и многое другое, что связано с развертыванием.
Configuration Management & Vulnerability Management.
Описывает работу с уязвимостями, взаимодействие подразделений при реагировании на инциденты и меры по обнаружению дефектов.
Вот перечень всех активностей, структурированных по практикам и доменам. BSIMM распределяет активности по трем уровням зрелости, показывая, насколько популярна сама практика и как часто она применяется. Чем выше уровень — тем сложнее практика.
Управление | |||||
Стратегия и метрики | Комплаенс и политики | Обучение | |||
[SM1.1] | Описание процесса SSDL и его развитие при необходимости | [CP1.1] | Стандартизация требований регуляторов | [T1.1] | Обучение сотрудников компании основам ИБ |
[SM1.3] | Обучение руководителей и топ-менеджмента | [CP1.2] | Обеспечение конфиденциальности | [T1.7] | Организация индивидуального обучения по запросу |
[SM1.4] | Внедрение и контроль quality gates | [CP1.3] | Разработка регламентирующих документов | [T1.8] | Привлечение сотрудников ИБ к процессу проведения обучения |
[SM2.1] | Публикация данных о безопасности ПО внутри организации | [CP2.1] | Создание перечня персональных данных | [T2.5] | Проведение awareness среди группы поддержки ИБ |
[SM2.2] | Соблюдение контрольных точек ИБ в процессе разработки ПО | [CP2.2] | Принятие рисков безопасности, связанных с комплаенсом | [T2.8] | Использование материалов, связанных с историей компании |
[SM2.3] | Создание института вовлеченных в ИБ (спутники, помощники, обеспечивающие поддержку) | [CP2.3] | Внедрение средств контроля соответствия | [T2.9] | Расширение учебных программ, ориентированных на конкретные роли |
[SM2.6] | Требование подтверждения выпуска ПО сотрудниками безопасности | [CP2.4] | Определение SLA по безопасности ПО для всех контрактов с поставщиками | [T2.10] | Проведение мероприятий по безопасности ПО |
[SM2.7] | Создание роли евангелиста и проведение внутреннего маркетинга | [CP2.5] | Обеспечение осведомленности руководства об обязательствах по обеспечению соответствия требованиям регуляторов и конфиденциальности | [T2.11] | Ежегодное повышение квалификации |
[SM3.1] | Отслеживание программных активов | [CP3.1] | История соответствия ПО комплаенсу | [T3.1] | Вознаграждение за успехи в обучении |
[SM3.2] | Внедрение внутреннего маркетинга | [CP3.2] | Обеспечение совместимости политик ИБ | [T3.2] | Обучение поставщиков и внешних сотрудников (аутстафф/аутсорс) |
[SM3.3] | Использование метрик для управления ресурсами | [CP3.3] | Внесение изменений в политики ИБ на основе данных эффективности SSDL | [T3.5] | Возможность предоставления экспертных знаний по открытым каналам |
[SM3.4] | Интеграция управления жизненным циклом программного обеспечения | [T3.6] | Определение новых сторонников ИБ с помощью наблюдения | ||
[SM3.5] | Управление рисками цепочки поставок ПО | ||||
База знаний | |||||
Модели атак | Особенности безопасного проектирования и дизайна | Стандарты и требования | |||
[AM1.2] | Использование схемы классификации данных для инвентаризации программного обеспечения | [SFD1.1] | Внедрение средств защиты | [SR1.1] | Создание стандартов ИБ |
[AM1.3] | Выявление потенциальных злоумышленников | [SFD1.2] | Взаимодействие архитекторов и ИБ-подразделения | [SR1.2] | Создание внутреннего портала |
[AM1.5] | Сбор и использование информации об атаках | [SFD2.1] | Использование компонентов и услуг, обеспечивающих безопасность при проектировании | [SR1.3] | Перевод ограничений соответствия в требования |
[AM2.1] | Создание моделей атак и примеров злоупотреблений, связанных с потенциальными злоумышленниками | [SFD2.2] | Решение сложных проблем архитектуры | [SR2.2] | Процесс создания и пересмотра стандартов |
[AM2.2] | Создание моделей атак, специфичных для конкретной технологии | [SFD3.1] | Создание совета по верификации и поддержке безопасных паттернов архитектуры | [SR2.4] | Идентификация открытого исходного кода |
[AM2.6] | Архивация истории атак | [SFD3.2] | Использование утвержденных СЗИ | [SR2.5] | Создание шаблона SLA |
[AM2.7] | Внутренний форум для обсуждения атак | [SFD3.3] | Размещение безопасных моделей архитектуры | [SR2.7] | Контроль риска использования OSS-компонентов |
[AM3.1] | Исследовательская группа для анализа новых методов атаки | [SR3.2] | Создание требований ИБ к поставщикам | ||
[AM3.2] | Создание и использование автоматизации для имитации злоумышленников | [SR3.3] | Использование стандартов безопасного написания кода | ||
[AM3.4] | Создание шаблонов атак в зависимости от конкретной технологии | [SR3.4] | Создание стандартов для технологического стека | ||
[AM3.5] | Поддержка и использование списка наиболее вероятных атак | ||||
| |||||
Точки соприкосновения с жизненным циклом | |||||
Анализ архитектуры | Код-ревью | Тестирование безопасности | |||
[АА1.1] | Реализация проверки безопасного проектирования | [CR1.2] | Организация регулярного код-ревью | [ST1.1] | Тестирование пограничных значений в ходе QA |
[АА1.2] | Анализ архитектуры для высокорисковых приложений | [CR1.4] | Использование инструментов автоматического анализа исходного кода | [ST1.3] | Тестирование, основанное на требованиях безопасности |
[АА1.4] | Внедрение методики оценки риска приложений | [CR1.5] | Обязательное код-ревью всех проектов | [ST1.4] | Интеграция инструментов ИБ в процесс QA |
[АА2.1] | Внедрение процесса анализа архитектуры | [CR1.7] | Назначение ответственных за инструменты | [ST2.4] | Тестирование QA с учетом результатов сканирования ИБ |
[АА2.2] | Шаблонизация артефактов описания архитектуры | [CR2.6] | Использование кастомных правил для большей точности сканирования | [ST2.5] | Включение тестов ИБ в автоматические тесты QA |
[АА2.4] | Передача лидирующей роли в архитектурном анализе группе ИБ | [CR2.7] | Использование перечня самых частых ошибок | [ST2.6] | Фаззинг-тестирование API |
[АА3.1] | Передача лидирующей роли в архитектурном анализе инженерам | [CR2.8] | Централизация информирования о дефектах | [ST3.3] | Управление тестами с помощью анализа результатов сканирований |
[АА3.2] | Внесение результатов анализа в архитектурные шаблоны | [CR3.2] | Оркестрация результатов ИБ-проверок | [ST3.4] | Использование анализа покрытия кодовой базы |
[АА3.3] | Выстраивание процесса наставничества группы ИБ по архитектурному анализу | [CR3.3] | Создание возможности устранения ошибок централизованно | [ST3.5] | Создание и применение тестов безопасности на основе недопустимых действий |
[CR3.4] | Автоматизация обнаружения вредоносного кода | [ST3.6] | Внедрение тестирования, основанного на событиях безопасности | ||
[CR3.5] | Обеспечение соблюдения стандартов безопасного написания кода | ||||
Развертывание и эксплуатация | |||||
Тестирование на проникновение | Среда эксплуатации | Управление конфигурацией и уязвимостями | |||
[PT1.1] | Привлечение внешних специалистов для поиска уязвимостей | [SE1.1] | Мониторинг входных данных | [CMVM1.1] | Реагирование на инциденты |
[PT1.2] | Передача результатов тестирований на проникновение в систему управления дефектами | [SE1.2] | Обеспечение базовой безопасности сети | [CMVM1.2] | Выявление дефектов программного обеспечения, обнаруженных в ходе мониторинга операций, и передача их в инженерную службу |
[PT1.3] | Внутреннее использование инструментов тестирования на проникновение | [SE1.3] | Внедрение средств контроля безопасности облачной среды | [CMVM1.3] | Отслеживание дефектов, обнаруженных в процессе эксплуатации |
[PT2.2] | Тестирование методом «белого ящика» | [SE2.2] | Определение критериев безопасного развертывания | [CMVM2.1] | Экстренное реагирование и внесение изменений |
[PT2.3] | Регулярное тестирование на проникновение | [SE2.4] | Обеспечение целостности кода | [CMVM2.3] | Инвентаризация ПО |
[PT3.1] | Привлечение сторонних пентестеров для проведения глубокого анализа | [SE2.5] | Использование контейнеризации | [CMVM3.1] | Исправление всех дефектов ПО |
[PT3.2] | Настройка инструментов тестирования на проникновение | [SE2.7] | Внедрение оркестрации контейнеров | [CMVM3.2] | Совершенствование цикла SSDL для предотвращения дефектов, обнаруженных в ходе эксплуатации |
[SE3.2] | Использование инструментов защиты кода | [CMVM3.3] | Симуляция критических ситуаций | ||
[SE3.3] | Мониторинг и диагностика поведения приложений | [CMVM3.4] | Запуск программы Bug Bounty | ||
[SE3.6] | Создание SBOM для развернутых приложений | [CMVM3.5] | Автоматизация проверок безопасности операционной инфраструктуры | ||
[SE3.8] | Анализ компонентов приложений | [CMVM3.6] | Публикация данных о рисках для артефактов | ||
[SE3.9] | Обеспечение целостности инструментов разработки | [CMVM3.7] | Организация процесса ответственного раскрытия уязвимостей | ||
[CMVM3.8] | Управление скоупом атак для приложений | ||||
На каждой активности останавливаться не будем, давайте посмотрим на те, которые входят в топ-10 активностей BSIMM14 и считаются самыми популярными.
[SM1.4] Внедрение и контроль quality gates
Суть: Постепенный подход к внедрению контрольных точек безопасности позволит командам на начальном этапе определять, что является критичным в разработке и как это не допускать в дальнейшем, не блокируя сам конвейер.
[CP1.1] Стандартизация требований регуляторов
Суть: Комплексный подход к определению требований регуляторов поможет не упустить нормативные нюансы и заложить все требования еще на начальных этапах жизненного цикла.
[CP1.2] Обеспечение конфиденциальности
Суть: Тут все понятно, квадратное не катим, круглое не носим, конфиденциальные данные защищаем.
[SR1.2] Создание внутреннего портала
Суть: Внутренний портал по безопасности поможет всем заинтересованным быстро найти нужную информацию, изучить подходы к безопасности и поделиться чем-то полезным.
[AA1.1] Реализация проверки безопасного проектирования
Суть: Не секрет, что при проектировании архитектуры должны быть заложены функции безопасности (например, шифрование, контроль доступа и так далее).
[CR1.4] Использование инструментов автоматического анализа исходного кода
Суть: Must have в безопасной разработке. Ведь применение SAST-инструментов позволит выявлять уязвимости еще до того, как артефакты попали в сборку.
[ST1.1] Тестирование пограничных значений в ходе QA
Суть: Команда QA, помимо функционального тестирования, проводит базовые тесты злоумышленника, чтобы проверить те или иные условия.
[PT1.1] Привлечение внешних специалистов для поиска уязвимостей
Суть: Одна из активностей, которая поможет определить, насколько ваше приложение безопасно. Очень важно смотреть на подход к безопасности с различных векторов.
[SE1.2] Обеспечение базовой безопасности сети
Суть: Пункт, без которого построение безопасной инфраструктуры абсолютно невозможно.
[CMVM1.1] Реагирование на инциденты
Суть: Быстрое и организованное реагирование на инциденты позволит оперативно восстановить работоспособность и корректное функционирование приложения или инфраструктуры. Ведь нарушение доступности, целостности и конфиденциальности несет за собой не только репутационные риски, но и материальные.
А еще относительно BSIMM13 добавилась новая активность, связанная с обеспечением целостности инструментов разработки (SE3.9). Суть данной практики заключается в предотвращении несанкционированных изменений в исходном коде и других артефактов жизненного цикла.
Смотрим, как все устроено на практике
Представим, что мы небольшая компания, где трудится десяток программистов, и мы хотим вывести безопасность разработки на уровень выше. Для начала необходимо определить, какие активности у нас уже запущены, а какие необходимо внедрить, и обозначить сроки. Временной промежуток обычно определяют в 3 года — это оптимальный вариант. Да, процесс построения безопасной разработки небыстрый, поэтому стоит как можно раньше начать.
Для удобства разобьем наш план поквартально. Пример подхода показан на практике «Стратегия и метрики» домена «Управление».
После того как мы прошлись по каждому домену, у нас есть четкий план реализации активностей и перечень уже существующих.
Для наглядности BSIMM рекомендует строить радиальную диаграмму, на ней видно текущий уровень зрелости и как этот уровень будет меняться в запланированный период. С таким представлением уже не стыдно приходить к руководству и показывать наши грандиозные планы.
Необходимо помнить, что выбор методологии — важный этап на пути к построению процессов безопасной разработки. Кто-то использует уже готовые фреймворки, такие как BSIMM, DSOMM, OWASP SAMM и другие. А кто-то разрабатывает свои, исходя из собственных целей и задач. В конечном итоге главное понять, в каких аспектах компании необходимо подрасти, как улучшить и поддержать текущие процессы.
Вот здесь можно посмотреть, какие еще существуют фреймворки на данный момент. P. S. Там не только про фреймворки, а еще много чего интересного!