Кто взломает ваш пайплайн? Моделирование угроз, о которых все забывают. Часть 2

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

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

Эта статья посвящена фундаментальным этапам построения модели, с которых начинается работа по риск-ориентированной защите:

1. идентификации активов — формированию полного и структурированного перечня того, что имеет ценность и в случае атаки может нанести ущерб компании;

2. оценки активов — расчету уровня критичности активов;

3. идентификации угроз — определению возможных угроз в процессе разработки ПО.

Входные данные: из чего строится модель угроз

Прежде чем приступить к моделированию угроз процессов РБПО, важно понимать: мы не начинаем с чистого листа. Методика опирается на заранее определенный набор базовых компонентов — своего рода «строительные блоки», которые обеспечивают системность и полноту анализа. Эти компоненты можно разделить на четыре логические группы.

1. Что защищаем?

Перечень типов активов: категории объектов воздействия в SDLC (исходный код, секреты, инфраструктура, инструменты и т.д.). Процессы РБПО: перечень практик безопасной разработки для защиты от возможных угроз.

2. От кого и зачем защищаемся?

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

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

Тактики и техники нарушителя: общие подходы к реализации атак по аналогии с MITRE ATT&CK, но с адаптацией под безопасную разработку.

3. Как могут атаковать?

Виды воздействия: на какие свойства активов направлены атаки (конфиденциальность, целостность, доступность).

Способы реализации: конкретные технические и организационные методы атак.

Перечень угроз: базовый каталог сценариев атак.

4. Что будет, если атака успешна? Последствия

Последствия от реализации угроз: виды ущерба.

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

Этап 1. Идентификация активов/объектов воздействия

Определение активов

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

Для удобства инвентаризации все активы логично разделить на следующие категории:

• Разрабатываемое ПО. То, что непосредственно относится к самому ПО: исходный код, документация на ПО, артефакты разработки, внешние зависимости, серверы, базы данных, секреты и т.п.

• Среда разработки. То, где разрабатывается ПО и какие инструменты применяются: конвейер CI/CD, инфраструктура ПО, IDE, хранилище артефактов разработки, инструмент SAST и т.п.

• Обрабатываемые данные. Какие данные хранятся и/или обрабатываются в ПО: ПДн клиентов, коммерческая тайна, банковская тайна и т.п.

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

• наименование, например, Docker-образ, GitLab, ключи API;

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

• владелец — конкретное лицо или команда, ответственная за актив.

На следующих этапах актив будем называть «объектом воздействия», чтобы не возникало путаницы с методикой оценки угроз безопасности информации ФСТЭК России.

Виды воздействия

Под видом воздействия понимается деструктивное действие, которое нарушитель может совершить в отношении актива.

В рамках методики моделирования угроз процессов РБПО определены следующие виды воздействия:

• утечка конфиденциальной информации или отдельных данных, в том числе информации, содержащейся в объектах среды разработки ПО;

• несанкционированный доступ к защищаемой информации: к требованиям по безопасности, описанию архитектуры ПО, исходному коду ПО, артефактам ПО, элементам конфигурации ПО, ПК разработчиков, объектам среды разработки и т.п.;

• преднамеренное или непреднамеренное изменение, подмена, искажение защищаемой информации, а также внесение ошибок в требования безопасности, архитектуру ПО, исходный код ПО, артефакты ПО, модификация инструментальных средств и объектов среды разработки;

• нарушение функционирования или неверная настройка программных/ программно-аппаратных средств, инструментов, применяемых для разработки и тестирования ПО;

• наличие и неисправление выявленных/актуальных дефектов или уязвимостей, в том числе ошибок в требованиях по безопасности, архитектуре ПО, эксплуатационной документации, дефектов и уязвимостей в ПО и исходном коде, образах, конфигурационных файлах и т.п.;

• отказ в обслуживании компонентов.

Для каждого вида воздействия определяется актив, в отношении которого может быть совершена атака.

Результат

Получаем сформированный перечень активов компании и для каждого вида воздействия перечень актуальных активов.

Этап 2. Оценка активов

Основным рабочим инструментом на этом этапе является опросный лист — структурированный набор вопросов, который заполняется самостоятельно заказчиком или совместно с ним.

Практический совет: финальные результаты должны быть верифицированы специалистом по ИБ. Это позволяет избежать как занижения критичности «у нас все не так важно», так и завышения «все критично, увеличьте бюджет».

Итоговый уровень критичности актива — это не просто субъективное мнение, а взвешенная комбинация следующих уровней критичности:

• с точки зрения бизнеса;

• с учетом защитных мер;

• с учетом воздействия уязвимостей, если проводился анализ защищенности или пентест.

Итоговый уровень критичности актива может принимать одно из следующих значений:

• критический;

• высокий;

• средний;

• низкий.

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

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

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

Уровень критичности актива с учетом защитных мер (УК_А) рассчитывается как сумма весовых коэффициентов для каждой метрики. Значения некоторых метрик являются отрицательными или положительными, что в результате может понизить или повысить итоговый уровень.

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

Для выявленных уязвимостей рассчитывается базовая оценка уровня критичности, например, по CVSS v.3.1 (предоставляется системой или может использоваться калькулятор CVSS 3.1 от ФСТЭК России:

• критический (Critical (9.0–10.0)) — полная компрометация системы;

• высокий (High (7.0–8.9)) — серьезное воздействие, легкая эксплуатация;

• средний (Medium (4.0–6.9)) — ограниченное воздействие, часто требует условий;

• низкий (Low (1–3.9)) — минимальное техническое воздействие.

Далее определяется фактор эксплуатации:

• теоретический — эксплойт отсутствует, сложная цепочка атаки, требуется физический доступ;

• базовый — наличие публичных доказательств эксплуатации уязвимости;

• вооруженный — эксплойт встроен в сканеры для поиска уязвимостей;

• активная атака — уязвимость эксплуатируется злоумышленниками в реальной жизни.

Уровень критичности актива с учетом воздействия уязвимости (УК_Уяз) рассчитывается на основании таблицы ниже, каждому наименованию уровня в рамках методики присвоено числовое значение.

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

Итоговый уровень критичности актива (УК_АсУ) рассчитывается по формуле:

УК_{АсУ =} УК_{А *} УК_Уяз

Результат

Для каждого актива рассчитан уровень критичности.

Этап 3. Идентификация угроз

Основной перечень угроз для каждого этапа жизненного цикла разработки приведен в ГОСТ Р 58412-2019, также в методике моделирования угроз процессов РБПО этот перечень был дополнен новыми угрозами, которые могут быть актуальны для компаний. В рамках текущего этапа могут быть добавлены дополнительные угрозы с учетом специфики компании, разрабатываемого ПО или наличия новых угроз из подтвержденных источников.

В методике для каждой угрозы определены все возможные варианты для следующих компонентов:

• этап, на котором может возникнуть угроза;

• идентификатор угрозы по аналогии с существующими;

• наименование;

• описание;

• виды воздействия;

• категория нарушителя и его уровень возможностей;

• объект воздействия;

• способы реализации.

В случае добавления новой угрозы необходимо указать значения этих компонентов.

В ходе моделирования угроз процессов РБПО значения этих компонентов меняются в соответствии с актуальными для обследуемой компании данными.

Результат

Полный перечень возможных угроз процессов РБПО для обследуемой компании.

Резюме: фундамент модели заложен

В этой статье мы прошли первые три этапа моделирования угроз процессов РБПО и заложили прочный фундамент для всей дальнейшей работы. Давайте посмотрим, что мы получили:

• реестр активов — полный перечень объектов воздействия в нашем SDLC;

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

• каталог угроз — структурированный перечень потенциальных сценариев атак, адаптированный под специфику компании и включающий как базовые угрозы из ГОСТ Р 58412-2019, так и современные векторы атак на DevSecOps.

Но это только начало. Мы определили защищаемые активы и возможные угрозы. Теперь предстоит решить две ключевые задачи: оценить уровень критичности угроз и смоделировать сценарии их возникновения.