Есть множество полезных фреймворков, позволяющих оценить процессы безопасной разработки, например, SAMM, BSIMM, DSOMM, MSDL. Так же есть лучшие практики, бенчмарки, рекомендуемые подходы к защите контейнеров и сред контейнерной оркестрации, такие как NSA Kuberentes Hardening Guide, или, например CIS for Kubernetes. Помимо этого, существует множество инструментов, повышающих защищенность при формировании и совершенствовании процессов DevSecOps: инструменты SAST, DAST, SCA, Container security, Secret management и другие. Но нет чего-то одного, описывающего, что конкретно и в какой последовательности нужно делать, чтобы выстроить процесс безопасной разработки, а также чтобы объективно оценить существующий уровень зрелости безопасной разработки и понять, куда двигаться дальше.
Эту проблему призван решить DevSecOps Assessment Framework (DAF). Он включает в себя не просто набор рекомендаций и лучших подходов из разных областей DevSecOps, но еще и большой экспертный опыт нашего коммьюнити, структурированный и адаптированный под реалии РФ и СНГ. Часть практик из общеизвестных фреймворков были исключены из DAF, а другая значительная часть практик была добавлена. Все модели, домены, поддомены и практики описаны понятным языком во избежании двусмысленностей и разных толкований.
В публичный доступ выложены не все наши наработки по DAF. Но мы считаем, что основная часть фреймворка DAF должна быть публичным достоянием:
- пиратская карта;
- тепловая матрица;
- модели “Технологии” и “Процессы”, а также все практики в этих моделях;
- маппинг практик на другие стандарты;
- Кирилламида (пирамида зрелости)
все это навсегда останется общедоступным.
Однако, есть и “закрытая” часть, которую мы реализуем в наших проектах по аудиту с использованием DAF. В ней есть:
- опросные листы для команд разработки для более удобного сбора информации от них “оффлайн”;
- супердетальные примеры того, “как проверить, что та или иная практика ДЕЙСТВИТЕЛЬНО выполняется”, а также примеры того, как необходимо реализовывать КАЖДУЮ практику;
- roadmap построения процессов DevSecOps на основе каждой практики и ее реализации из пункта выше;
- динамическая “иллюминация” - подсветка каждой ячейки Кирилламиды, тепловой карты и пиратской карты, в зависимости от степени выполнения соответствующего набора практик;
- расширенный и кастомизируемый отчет по аудиту по DAF;
- автоматизированный рассчет FTE специалистов DevSecOps \ AppSec для внедряемых инструментов безопасности с учетом количества команд разработки и планируемыех задач;
- и кое-что другое.
- пересмотрели часть практик и их расположение в уровнях зрелости;
- добавили маппинг практик DAF на фреймворк BSIMM (и SAMM, если успеем);
- добавили Кирилламиду (детальное описание ниже);
- исправили опечатки, баги.
- привязать расчет FTE команды ИБ (AppSec), необходимый для сопровождения предлагаемых к внедрению инструментов на основе результатов DAF;
- сделать маппинг практик на фреймворки OSSF и CNCF;
- добавить фреймворки BSIMM, SAMM, DSOMM в фреймворк, чтобы при выборе ответов на вопросы фреймворка DAF автоматически проставлялись ответы и для BSIMM, SAMM, DSOMM. Таким образом, проводя аудит по DAF, сразу же можно будет оценить насколько закрываются требования других фреймворков (за один заход провести аудит по всем широкораспространенным фреймворкам).
При внедрении практик и процесса безопасной разработки ПО первый и самый главный вопрос, с которым сталкиваются компании -- «С чего начать?». Для того, чтобы ответить на этот вопрос, нужно преодолеть следующий путь:
- Определить, где вы находитесь сейчас.
- Определить, в какую сторону хотите развиваться.
- Зафиксировать целевое состояние.
- Определить инициативы, реализация которых поможет достичь целевого состояния.
- Проанализировать всю собранную информацию для оценки необходимых ресурсов.
- Сформировать дорожную карту реализации инициатив.
- Реализовать инициативы.
DAF - это фреймворк оценки зрелости процесса безопасной разработки ПО. В данном случае под словом фреймворк мы понимаем набор инструментов, принципов, правил, руководств и процессов, которые помогают создавать безопасное ПО.
Основные задачи, которые ставились при создании фреймворка:
- сформировать набор практик, который будет охватывать весь процесс безопасной разработки с детализацией;
- сформировать набор практик, которые будут актуальны только для рынка РФ;
- сделать максимально простой процесс оценки зрелости;
- сформировать подход к определению текущего уровня зрелости организации и практик, которые к этому уровню относятся;
- создать визуализацию результатов для удобства восприятия результатов;
- сформировать инкрементальный подход к уровням зрелости.
DAF состоит из трех компонентов:
Пиратская карта - это верхнеуровневый взгляд на весь фреймворк. Она включает в себя все аспекты процесса безопасной разработки с этапа планирования до перевода ПО в промышленную эксплуатацию. Карта делится на два блока: Технологии и Процессы.
Таблица оценки содержит различные практики, а также критерии оценки (”Верно” и “Неверно” для нулевого уровня, а также “Выполняется”, “Частично выполняется” и “Не выполняется” для практик 1го и последующих уровней зрелости). В таблице онценки практики сгурппированы в поддомены, а поддомены - в домены. Для соответствия конкретному уровню зрелости, может потребоваться выполнение одной или нескольких практик.
Тепловая матрица показывает степень выполнения практик в рамках определенного поддомена в соответствии с четырьмя уровнями зрелости практики (в процентах). Например, если для соответствия ТРЕТЬЕМУ уровню “Идентификация секретов” требуется соблюдение 4х условий, но на момент аудита выполняется только 2 условия, то в матрице отобразится значение “50%” соответствия третьему уровню.
Основная цель тепловой матрицы - визуализация полученных данных.
В Таблице оценки и Тепловой матрице существуют следующие уровни зрелости (по аналогии с большинством других общеизвестных фреймворков):
- Уровень 0: Uninitiated
На этом уровне компания не имеет никаких формализованных процессов или инструментов безопасной разработки. Практики могут использоваться случайным образом по инициативе отдельных работников.
- Уровень 1: Beginners
На этом уровне зрелости практик в компании начинают появляются инструменты, используемые при безопасной разработке с минимальной зоной покрытия и без автоматизации. Появляются базовые процессы.
- Уровень 2: Intermediate
Процессы на этом уровне становятся повторяемыми и управляемыми, происходит расширение зоны покрытия используемых инструментов, внедрение автоматизации. Компания начинает применять методики для планирования, выполнения и отслеживания активностей. Однако эти методики могут быть не всегда последовательными или полностью документированными. Инструменты по прежнему не покрывают весь процесс безопасной разработки.
- Уровень 3: Advanced
На данном уровне фактически инструменты безопасной разработки обеспечивают максимальное покрытие и автоматизацию. Все процессы являются последовательными и полностью документированными
- Уровень 4: Experts
Когда все процессы и инструменты развиты максимально, нет предела совершенству. Можно по прежнему что-то улучшить и повысить зрелость
Понятие родилось из слияния слова “Пирамида” и имени ее основателя - Кирилла Бочкарева. Только теперь она перестала быть пирамидой в угоду удобства навигации, но понятие надежно закрепилось за этой частью DAF.
Кирилламида нужна для отображения последовательности внедрения практик безопасной разработки с максимальной детализацией всех активностей.
Зачем она нужна:
- Понять текущее положение дел в рамках всего процесса безопасной разработки: Компания может определить на каком уровне безопасности находится в данный момент.
- Планировать: Кирилламида позволяет планировать следующие шаги в развитии процессов безопасной разработки.
- Мотивировать: Отслеживая прогресс в Кирилламиде, команды разработки могут видеть свое развитие, что может служить мотивацией для дальнейших улучшений.
- Стандартизировать: Кирилламида может служить основой для внутренних стандартов и правил, устанавливаемых Компанией для повышения качества процессов безопасной разработки.
Кирилламида состоит из 3 основных частей:
- Уровни 0 - 2. В рамках данных уровней основная цель компании - добиться внедрения основных инструментов и процессов, используемых при безопасной разработке, а также обеспечить базовый уровень покрытия процессов этими инструментами.
- Уровни 3 - 5. В рамках данных уровней происходит расширение зоны покрытия использования инструментов до максимального, развитие основных процессов, а также дополнительное внедрение инструментов безопасной разработки, которые не входят в базовый уровень
- Уровни 6 - 7. Когда внедрены все основные инструменты и процессы безопасной разработки, то компания занимается внедрением наиболее современных, сложных и трудозатратных практик.
Для создания фреймворка были проанализированы и использованы следующие материалы:
- Международные лучшие практики:
- Building Security In Maturity Model (BSIMM);
- OWASP Software Assurance Maturity Model (OWASP SAMM);
- DevSecOps Maturity Model (DSOMM);
- Microsoft Security Development Lifecycle (SDL);
- ГОСТ Р 58412-2019. РАЗРАБОТКА БЕЗОПАСНОГО ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ. Угрозы безопасности информации при разработке программного обеспечения
- A Model For Measuring Improvement Of Security In Continuous Integration pipelines
- Open Source Software (OSS) Secure Supply Chain (SSC) Framework Simplified Requirements
- Практики от Center for Internet Security (CIS):
- Best practices:
- Aqua Cloud Native Security Maturity Model
- Secrets Management Maturity Model
- Наш опыт, а также опыт наших заказчиков.