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

Напомню тем, кто успел подзабыть — меня зовут Светлана Газизова, я руководитель направления аудита и консалтинга в области безопасной разработки Swordfish Security. В прошлый раз мы с вами взвешивали плюсы и минусы BSIMM. Недостатки этой и других зарубежных моделей подтолкнули нашу команду к созданию собственного фреймворка безопасной разработки. Мы собрали в нем best practices общеизвестных методологий и лучшие отраслевые технологии, а главное — соотнесли всё это с требованиями российских регуляторов. В статье я расскажу, из чего состоит фреймворк Swordfish Security, в чем его плюсы и как мы планируем улучшить нашу модель.

Оглавление

• Почему мы решили разработать собственный фреймворк

• Какой фреймворк мы стремились создать

• Структура фреймворка

• Преимущества модели

• Планы на будущее

• Вывод

Почему мы решили разработать собственный фреймворк

Реализовав множество проектов в области безопасной разработки, мы смогли достаточно близко познакомиться с фреймворками BSIMM, Microsoft SDL, OWASP SAMM, Open SAMM и другими. Если говорить точнее — нам пришлось изрядно помучиться. На наш взгляд, во всех методологиях уж очень не хватает конкретики и прозрачности. Мы пытались адаптировать их под наши проекты, собрать на основе всех моделей единый фреймворк с огромным пулом задач, меняли порядок активностей, дописывали к ним поясняющие блоки. И в конце концов поняли — ни один из существующих фреймворков не получится адаптировать так, чтобы с ним было удобно работать. 

Кроме этого, к нашему удивлению, мы обнаружили, что многие методологии недооценивают важность инструментальных проверок. Возьмем, к примеру, ту же самую BSIMM. В ней практики с рекомендациями использовать оркестрацию контейнеров находятся на уровне 2 (SE2.7. Use orchestration for containers and virtualized environments), а предложения применять инструменты класса ASOC — на уровне 3 (SE3.3. Use application behavior monitoring and diagnostics; SM 3.1. и далее). Практика композиционного анализа вообще располагается в самом подвале раздела Software Environment (SE3.8. Perform application composition analysis on code repositories). А это, между прочим, важные задачи, без которых невозможно обеспечить безопасность пайплайна с поддержкой достаточного уровня автоматизации. 

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

В качестве еще одного не менее серьезного недостатка общеизвестных фреймворков стоит отметить то, что все они очень далеки от запросов российских регуляторов. Когда мы реализовывали проекты для крупных компаний из финсектора, от методологий и построенных по ним стратегий внедрения процесса безопасной разработки практически ничего и не оставалось. В зависимости от специфики и потребностей организаций мы подстраивали материалы под ГОСТ 15408, ГОСТ 56939 (стандарт по безопасной разработке), конкретные положения ЦБ и другие нормативные акты. А теперь попробуйте представить, какие у нас получались «монстры» при такой вот попытке подружить стандарты и умозрительные рекомендации зарубежных фреймворков. 

Какой фреймворк мы стремились создать

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

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

Непротиворечивый. Что должен делать фреймворк? Описывать подходы к построению процесса безопасной разработки. А что должен делать хороший фреймворк? Учитывать требования регуляторов. Существуют ГОСТы, Приказ ФСТЭК №239 с требованиями по обеспечению безопасности КИИ, указы президента и еще много всего. Основная цель нашего фреймворка состоит в том, чтобы помогать компаниям становиться более защищенными. Мы не должны порождать проблемы с регуляторами, поэтому в основе и лежит принцип непротиворечия.

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

Структура фреймворка

Во фреймворке Swordfish Security 4 домена:

• Верификация безопасности. Этот домен посвящен различным проверкам ИБ, которые реализуются в рамках процесса безопасной разработки. Сюда входит архитектурный анализ, сканирование защищенности с помощью инструментов, проведение пентестов, исследование метрик — в общем всё, что помогает определить уровень безопасности продуктов. 

• Среда эксплуатации. Данный блок включает в себя практики, помогающие поддерживать необходимый уровень защищенности ПО, которое уже покинуло пределы CI/CD-пайплайна. Эти задачи позволяют сформировать понимание того, как реагировать на инциденты, что делать с дефектами и так далее.

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

• Обучение. Блок содержит инструкции по проведению базового обучения в области ИБ, формированию института Security Champions, повышению ценности информационной безопасности внутри компании. 

Наименования доменов еще не зафиксированы окончательно, но в текущей версии (1.0) мы обозначили их именно так.

Табл. 1. Структура фреймворка Swordfish Security.

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

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

• перечень шагов — активности, которые нужно выполнить для достижения результата, и их последовательность;

• условия завершенности — критерии, помогающие понять, в какой момент можно считать задачу завершенной;

• профит — описание пользы, которую получит компания после того, как выполнит конкретную задачу;

• артефакт — материал, который получит организация после реализации задачи (например, регламент безопасной разработки или перечень курсов для повышения квалификации);

• зона ответственности — раздел, помогающий специалистам, участвующим в построении процесса безопасной разработки, понять, к какому подразделению отнести определенную задачу и кого назначить ответственным;

• сложность реализации — показатель, позволяющий оценить, какой объем ресурсов нужно потратить на задачу;

• ценность реализации — отметка, обозначающая приоритет задач (ведь есть активности более ценные, чем остальные, например, по нашему опыту, в 90% случаев внедренный SAST-анализ приносит больше профита, по сравнению с фаззингом);

• инструмент — блок с указанием инструментов, которые помогут выполнить определенные задачи (очевидно, что для тестирования поведения приложения можно использовать DAST, а вот как реализовать анализ метрик — уже не так понятно);

• уровень зрелости — раздел, коррелирующий с ценностью реализации, но стоит придерживаться здравого смысла: на первом уровне лучше уделять внимание тем задачам, которые возможно выполнить «малой кровью»;

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

Преимущества модели

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

Обратимся к разделу BSIMM Code Review, CR 1.4 Используйте автоматизированные инструменты проверки кода. Вот как здесь описан теоретический подход к внедрению инструмента:

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

И тут-то возникает куча вопросов из разряда: как внедрить этот анализ, когда можно считать задачу завершенной, как оптимизировать работу с результатами сканирований и так далее. Поэтому в рамках нашего фреймворка мы постарались дать вводные, которые будут оставлять как можно меньше пробелов. Сравним приведенные выше описание из BSIMM с материалом из раздела SFS Framework, ST1.6 Использование инструментов статического анализа кода (SAST):

Задача:

ST1.6 Использование инструментов статического анализа кода (SAST)

Перечень шагов:

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

2. Провести исследование доступных решений и пилотные испытания.

3. Выбрать решение SAST с учетом информации, полученной во время анализа и пилотных испытаний.

4. Определить сотрудников, которые будут взаимодействовать с инструментом и результатами сканирований.

5. Подготовить всю необходимую эксплуатационную документацию по инструменту и провести инструктаж для сотрудников по работе с ним.

6. Провести первичное сканирование в ограниченном числе команд и сформировать технический долг.

7. Разработать общую стратегию разбора срабатываний – определить правила выставления статусов, этапы закрытия уязвимости и пр.

8. Фиксировать и проводить анализ результатов сканирования.

9. Внедрить инструмент в конвейер разработки в ограниченном числе команд.

10. Определить quality gates.

11. Подключить инструмент к платформе безопасной разработки.

12. Разработать кастомные правила для повышения точности срабатываний.

13. Тиражировать инструмент на остальные команды.

Условия завершенности:
Инструмент внедрен в MVP-проекты и успешно осуществляет сканирования. Сотрудники регулярно используют инструмент и проводят триаж найденных уязвимостей.

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

Артефакт:
Детальное описание работы с инструментом может быть определено в регламенте безопасной разработки.

Зона ответственности:
Организация (Команда ИТ/Команда ИБ).

Сложность реализации:
Средняя.

Ценность реализации:
Высокая.

Инструмент:
Статический анализатор.

Уровень зрелости:
1.

Маппинг:
BSIMM CR1.4, СR1.7, CR2.6; ГОСТ 56939 5.3.3.4, 5.6.3.4. 

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

Планы на будущее

Сейчас мы разрабатываем методичку по работе с нашим фреймворком. Там будут более детальные советы по внедрению процесса безопасной разработки. Также мы планируем отразить в ней модель зрелости: многим нравится так называемая «паутинка» BSIMM, или круговая диаграмма практик. Она помогает визуально оценить, на каком уровне зрелости относительно идеальной картины находится компания в данный момент, где она будет через год, два и так далее. Кроме этого, такой материал отлично смотрится в презентациях и документах. Мы сделали аналогичную штуку и разработали алгоритм расчета диаграммы. Также наша команда сейчас создает опросник для самостоятельной оценки выполненных работ по внедрению процесса разработки защищенных продуктов.

Рис. 2. Обезличенная круговая диаграмма практик безопасной разработки. 

Вывод

Мы уже провели успешные «боевые» испытания, то есть полноценные коммерческие исследования нашего фреймворка, и получили высокие оценки от клиентов. Разработанные стратегии и дорожные карты внедрения практик безопасности по методологии Swordfish Security подтверждают ее жизнеспособность и применимость.

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