SavePearlHarbor

BSIMM: с чего начинается AppSec в компании

—

от автора

admin

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

  • Управление

    Стратегия и метрики

    Комплаенс и политики

    Обучение

    [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 и считаются самыми популярными.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


ссылка на оригинал статьи https://habr.com/ru/articles/805395/

Комментарии

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *