BSIMM

Building Security In Maturity Model (BSIMM) - модель оценки безопасности жизненного цикла ПО, результат сбора лучших практик за несколько лет от более чем 100 различных организаций. Основная цель - количественная оценка действий, осуществляемых реальными инициативами в области безопасности программного обеспечения, чтобы помочь более широкому сообществу разработчиков программного обеспечения безопасности планировать, осуществлять и оценивать собственные инициативы.

Модель включает 119 видов деятельности, сгруппированных в четыре области: Управление (Governance) , Сведения (Intelligence), Точки взаимодействия SSDL (SSDL Touchpoints) и Развертывание (Deployment). Каждая область разделена на 3 уровня в зависимости от степени зрелости организации.

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

#bsimm #bestpractice #checklist #dev #ops

Стратегия и метрики (BSIMM - Governane, Strategy & Metrics)

Первый блок в Governance посвящен практике «Стратегия и метрики» и включает планирование, распределение ролей и обязанностей, определение целей безопасности программного обеспечения, определение бюджетов, а также определение метрик и гейтов.

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

https://github.com/dvyakimov/BSIMM_ru

#bsimm #dev #ops

Обеспечение соответствия и ведение политик (BSIMM - Governance, Compliance & Policy)

Подготовил вторую часть перевода из блока Управления (Governance) фреймворка BSIMM. На этот раз лучшие практики обеспечения соотвтетствия, будь это PCI DSS, HIPPA, либо внутренние требования заказчика - о том, что из себя представляет политика безопасности, об уровне обслуживания (SLA) подрядчиков и важности постоянного изменения политики на основе фидбека из SDLC.

Друзья, пишите мне в личку, насколько вам интересно и полезно читать такой перевод, стоит ли идти по переводу последовательно, либо отбирать самое интересное (например то, что касается анализа архитектуры, code review, тестирования).

https://github.com/dvyakimov/BSIMM_ru

#bsimm #compliance #dev #ops

Обучение (BSIMM - Governance, Training)

Завершил перевод первой части BSIMM, посвященой управлению процессом SSDLC, а именно разделу про обучение сотрудников.

BSIMM гласит, что даже незрелым организациям будет полезно иметь внутренние электронные ресурсы для обучения сотрудников безопасному коду с элементами геймификации. Для более зрелых организаций приемлемо проводить мероприятия с привлечением внешних спикеров, а также учитывать историю собственной компании в своих внутренних курсах. Наконец, для самых зрелых организаций полагается обучение внешних подрядчиков на уровне своих сотрудников, организация массовых мероприятий, ежегодное повышение квалификации и поиск спутников (чемпионов) через их заслуги.

О том, что такое BSIMM

Подробнее про обучение:
https://github.com/dvyakimov/BSIMM_ru/blob/master/Governance/Training.md

#bsimm #dev #ops

BSIMM 11 - Что изменилось, event-driven security и платформа о рисках артефактов

Два дня назад вышла новая версия BSIMM, главного документа по организации безопасности SDLC с точки зрения оценки зрелости процессов и предоставления лучших практик. Для написания BSIMM независимая группа проводит исследование сотни компаний разных размеров, агрегируя их активности по безопасности SDLC в этот сборник.

Что изменилось, помимо перестановки активностей между практиками?

1) Появление активности "[ST3.6:0] Implement event-driven security testing in automation". Исследования BSIMM гласят, что инженеры в опрашиваемых компаниях идут по пути поиска дефектов на основе событий в процессе непрерывного мониторинга, а не поиска их на ранних стадиях жизненного цикла ПО. Тем не менее, развивается тенденция, при которой группа безопасности задает события-тригеры в рамках пайплайнов. То есть, например, привлекать инженеров ИБ не когда валится одна из проверок безопасности в пайплайне, а когда поступает какое-то конкретное событие от ботов или агентов. Эти агенты/боты могут следить как за результатами самого пайплайна, так и за реакцией со стороны dev-окружения. Также эти агенты/боты могут запускать собственные автоматические задачи по мере обнаружения необычных событий. Идею с event-driven automation можно найти в статьях Netflix от 2016 года. Тогда они описали свою платформу Winston, которая позволяла помочь инженерам не вскакивать посреди ночи из-за ложных событий.

2) Появление активности "[CMVM3.6: 0] Publish risk data for deployable artifacts", согласно которой растет значимость централизованных платформ управления безопасностью. Согласно BSIMM платформа должна содержать информацию об активах организации (артефактов, зависимостей) и связанных с ними рисками. При этом автоматическая актуализация информации и ее визуализация в платформе положительно сказывается на принятии стейкхолдерами решений, связанных с рисками.

#bsimm