Привет, Хабр!

Меня зовут Света Газизова, я ведущий аудитор компании Swordfish Security. Поговорим сегодня о безопасной разработке, вернее, об инструментах, которые могут сделать ее проще (или нет).

Никому не хочется быть на прицеле у хакеров. Все боятся, что данные клиентов утекут в сеть. И уж тем более никто не желает видеть по ночам кошмары про DDoS-атаки. Инструменты безопасности (лекарства от всех этих страхов) вроде бы и есть, но ими сложно управлять. А кроме этого, нужно постоянно следить за разработкой. Неплохим выходом из этой мрачной реальности может стать фреймворк безопасной разработки. Главное — уметь его готовить. На сегодняшний день таких фреймворков существует несколько, самые яркие — Microsoft SDL, OWASPSAMM, OpenSAMM, BSIMM. О последнем как раз пойдёт речь в этой статье.

Содержание:

• С чего все началось?

• Модели оценки зрелости и то, зачем они нужны

• Терминология BSIMM

• Плюсы и минусы BSIMM

• Оценка зрелости BSIMM

• А как обстоят дела в России?

• Выводы

С чего всё началось?

Еще на заре XXI века в Microsoft заметили, что чем сложнее, масштабнее и круче становятся технологии, тем труднее их защищать. Нужно было с этим что-то поделать. Ребята из MS хорошенько проанализировали ситуацию и решили, что компаниям из самых разных сфер поможет концепция безопасной разработки — Security Development Lifecycle (SDL), которую они и создали. Это некий свод принципов: если их придерживаться, можно обеспечить разрабатываемым приложениям достойный уровень безопасности, причем сразу на всех этапах жизненного цикла.

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

Вот, что сказала по этому поводу сама компания Microsoft: «Microsoft SDL стала неотъемлемой частью процесса разработки программного обеспечения в Microsoft в 2004 году. Разработка, внедрение и постоянное совершенствование SDL представляют собой наши стратегические инвестиции в усилия по обеспечению безопасности. Это эволюция способов проектирования, разработки и тестирования программного обеспечения, которая теперь превратилась в четко определенную методологию».

Модели оценки зрелости и то, зачем они нужны

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

«В 2008-ом году стало ясно, что организации выбирают разные пути для защиты своего программного обеспечения. Эксперты, входящие в состав нынешней группы Synopsys Software Integrity Group, приступили к сбору данных об этих различных путях с целью изучения организаций, которые были высокоэффективны в области безопасности программного обеспечения, провели личные интервью со специалистами по безопасности в организациях и опубликовали свои выводы» — (с) BSIMM

Так, на основе интервью с 9 компаниями в 2009-ом году была создана первая версия BSIMM. С тех пор модель ежегодно совершенствуется и обновляется. К 2021 году BSIMM12 насчитывала уже 128 компаний-участников, среди которых Adobe, Black Duck, Cisco, Lenovo, NVIDIA, Synopsys, Bank of America и др.

Все, кто пользуется BSIMM, практически в один голос заявляют, что она помогает им:

1. Оценивать текущий уровень процессов безопасной разработки и находить слабые места

2. Знакомиться с best practices и понимать, к чему нужно стремиться

3. Отслеживать повышение уровня зрелости

4. Составлять дорожные карты и грамотно внедрять процессы безопасной разработки

5. Определять уровень своей эффективности относительно других компаний

Терминология BSIMM

Готовы погрузиться в BSIMM? Для начала давайте-ка разберёмся с терминологией и посмотрим, как всё устроено.

Итак, фреймворк разделён на 4 крупных домена:

1. Governance (Управление) — практики, которые отвечают за организацию, управление и оценку эффективности SSDL;

2. Intelligence (База знаний) — практики для сбора и консолидации знаний в области ИБ внутри организации. Они нужны для того, чтобы внедрять и тиражировать практики разработки защищенного ПО в полном объеме;

3. SSDL Touchpoints (Точки соприкосновения с жизненным циклом разработки ПО) — практики для анализа и оценки конкретных артефактов и процессов в рамках производства ПО;

4. Deployment (Развёртывание и эксплуатация) — практики, которые отвечают за взаимодействие с подразделениями сетевой и инфраструктурной безопасности, а также службами технической поддержки.

Каждый домен, в свою очередь, разделяется на 3 практики.

Практики объединяют в себе несколько активностей, которые распределены на три уровня зрелости BSIMM. Ниже приведён пример домена «Управление».

В BSIMM12 в общей сложности описаны 122 активности (ниже мы разберем некоторые из них). Строгих правил по количеству активностей в практиках и уровнях зрелости нет. У каждой активности есть свой ID и сквозная нумерация.

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

Передохнули? Вот вам еще несколько важных терминов BSIMM:

Безопасный жизненный цикл разработки ПО (SSDL) — жизненный цикл программного обеспечения с интегрированными контрольными точками безопасности ПО и его деятельности.

Группа по безопасности программного обеспечения (SSG) — внутренняя группа из тех, кто в ответе за обеспечение и поддержание безопасности ПО.

Фреймворк безопасной разработки (SSF) — гайдлайн, на котором держится вся структура BSIMM (там 12 практик, объединённых в 4 домена).

Инициатива по безопасности ПО (SSI) — подход для внедрения, измерения, управления и развития безопасности ПО.

Секьюрити Чемпионы — это те самые разработчики, архитекторы, менеджеры с «горящими глазами», которые работают с программными продуктами; а также тестировщики и люди, выполняющие аналогичные функции. Такие чемпионы напрямую связаны с безопасностью ПО. Они вносят свой вклад в создание концепции безопасной организации её продуктов.

Сторонники информационной безопасности («Спутники») — их также часто называют Секьюрити Чемпионами (зачем?). Это команда, которая организуется и задействуется Группой безопасности (SSG). Но глаза у них, видимо, горят немного меньше ;-)

А теперь разберем подробнее некоторые практики BSIMM.

1. Управление

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

• Соответствие регуляторам. Здесь про то, как собрать вместе все необходимые требования внешних регуляторов отрасли и оценить, насколько они вообще подходят для процессов разработки. Еще в этом блоке описано, как улучшить процессы, снабдить их внутренней нормативной документацией, внедрить мониторинг новых тенденций отрасли.

• Обучение. Эта практика нужна для того, чтобы создавать материалы по обучению безопасной разработке и расширять знания команды в области ИБ. Также этот блок предусматривает, что нужно поощрять тех самых сотрудников с «горящими глазами» и уделять внимание подрядчикам и работникам на аутсосорсе (например, организовывать для них тренинги).

2. База знаний

• Механизмы безопасности и дизайн. Цель этого блока — привлечь группы ИБ к процессу разработки архитектуры приложений и наладить коммуникацию между всеми участниками. Также эта практика про то, как собрать и опубликовать в открытом доступе безопасные шаблоны проектирования для переиспользования.

• Модели атак. Активности этой практики нужны для того, чтобы смоделировать и проанализировать угрозы безопасности, найти уязвимости и защититься от всех опасностей.

• Стандарты и требования. Здесь всё про анализ стандартов и подзаконных актов, которые регулируют отрасль. А для самых увлеченных в практике есть активности по созданию собственного стандарта по разработке безопасного ПО с учётом действующего законодательства.

3. Точки соприкосновения с жизненным циклом разработки ПО

• Анализ архитектуры. Эта практика BSIMM описывает проведение архитектурного анализа, включая участников, структуру процесса и основные его моменты. Здесь есть и рекомендации, как распределить приложения по уровню риска.

• Анализ кода. Этот блок про внедрение инструментальных проверок в конвейер CI/CD, автоматизацию обнаружения уязвимостей и покрытие стандартов безопасного кодирования.

• Тестирование защищённости. Здесь про автоматизацию тестирования безопасности, внедрение фаззинга и подключение QA-команды в процесс тестирования защищённости.

4. Развёртывание и эксплуатация

• Тестирование на проникновение. В практике есть рекомендации не только для внешних пентестеров, но и для внутренних.

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

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

Плюсы и минусы BSIMM

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

Преимущества:

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

2. Отсутствие ограничений позволяет «запихать» сколько угодно активностей в практику. Кроме того, это отличная возможность постоянно обновлять и декомпозировать активности, удаляя, добавляя, разделяя, объединяя, актуализируя их по уровню зрелости;

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

4. Регулярное обновление. Каждый год BSIMM выкатывает новую версию, актуализируя уровни зрелости, состав активностей и описание;

5. Возможность сравнить свой прогресс SSDL с другими организациями и руководствоваться теми best practices, которые действительно используются в крупных компаниях, без абстрактных рекомендаций;

6. Большое, приятное и компетентное сообщество. Лично не присутствовала, но мне рассказывали;

7. Тенденции. BSIMM учитывает, что происходит на рынке — куда ветер дует, какие практики меняются и как это происходит, что становится более приоритетным. Всё это находит отражение в каждой обновленной версии;

8. Очень хороша наглядная диаграмма, отображающая степень выполнения практик и прогресс. Вы только посмотрите:

Это же не стыдно показать директору и сказать: «А мы молодцы, уже не такое у нас всё и коричневое!»

Изъяны:

1. Структура хоть и хороша, но недостаточно. Хронология и связь между активностями отсутствует напрочь, хоть многие сильно связаны, а иногда и вовсе являются логичным продолжением друг друга. При том, те ссылки, что иногда встречаются, зачастую абсолютно бесполезны;

2. Описание активностей. Так как BSIMM — модель сугубо описательная, порой формулировки просто сводят с ума. Иногда они очень расплывчаты, порой очень громоздки и запутаны;

3. Отсутствие условий завершённости, профита, описания ролей и последовательности действий, а также много чего ещё;

4. Иногда активности частично дублируют друг друга, при этом находясь вообще в разных доменах;

5. BSIMM является собственностью Synopsys, с чем связана ее закрытость. Полную оценку нельзя провести самостоятельно, только за дополнительную плату;

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

Оценка зрелости BSIMM (паутинка)

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

Представленный срез отражает покрытие каждой практики по отношению к идеальной картине, т. е. выполнение активностей всех практик, которые содержатся во фреймворке BSIMM. Коричневым цветом выделены уже выполняющиеся активности, оранжевым — запланированные активности на 2022 год, желтым — запланированные на 2023 год, зеленым — запланированные активности 2024 года (целевое состояние).

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

А как обстоят дела в России?

Вообще дела с SSDLC в России обстоят, можно сказать, «средне по больнице». Не намного хуже и не лучше, чем в аналогичных отраслях за рубежом.

Но в России мы живем всё-таки в парадигме стандартов и методик, а не фреймворков. Это создает некоторые сложности (некоторые, лол). Например, если трактовать BSIMM слово в слово, то мы должны выложить на наш портал (в Википедию компании, в Confluence или ещё куда-нибудь) информацию обо всех инцидентах. И дать доступ всем заинтересованным. Это несколько противоречит стандарту по менеджменту инцидентов (ГОСТ Р ИСО/МЭК ТО 18044-20). Примерно такая же ситуация будет с публикацией на портале контактов AppSec-специалистов. Если выложить в общий доступ их телефоны и почты, мы получим конфликт с 152-ФЗ про обработку и хранение ПДн.

Еще один важный пункт, который умаляет достоинства BSIMM и даже эту прекрасную паутинку — ну уж очень верхнеуровневая проработка некоторых действий. Нам пишут: «Унифицируйте ограничения, накладываемые на Компанию». А какие? Как унифицировать? Что именно должно стать результатом?

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

Выводы

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

С одной стороны, в модели всё выглядит довольно просто, есть структура, конкретная иерархия и даже паутинка для оценки результатов. Вот вам, берите и не благодарите. Но если погрузиться в BSIMM с головой, можно очень сильно запутаться, поскольку там не три сосны, как показалось изначально, а целые дебри. Десятки активностей, у многих из них непонятные описания, нет условий завершенности и последовательности действий. За что здесь, собственно, благодарить? — возможно, спросите вы.

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

P.S. Если вдруг станет интересно почитать больше, то https://www.bsimm.com/.
А за помощь в подготовке статьи огромнейший респект моему коллеге Евгению Иляхину, аудитору по безопасной разработке:)

P.P.S. А еще, мы делали вот такой вот интерактивный курс по 12-ой версии BSIMM, его можно пройти бесплатно - https://edu.swordfishsecurity.ru/bsimm-model-zrelosti-proczessa-bezopasnoj-razrabotki/. Он, кстати, будет обновляться время от времени:)

Все остальное, упомянутое в статье, отлично гуглится и, если будут вопросы, всегда велком, расскажу:)