...о моделировании угроз: угроза не существует лишь потому, что она есть в каталоге

Каталог — это не модель

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

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

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

Рассмотрим атаку отказа в обслуживании на канал связи внутри промышленной системы управления. Атаки отказа в обслуживании, безусловно, существуют. Каналы связи, безусловно, существуют. Поэтому кажется разумным включить в модель угроз «DoS-атаку на каналы связи ICS».

Но прежде чем оценивать тяжесть последствий или вероятность такой атаки, необходимо ответить на более фундаментальный вопрос:

Из какого достижимого состояния системы атакующий может её выполнить?

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

Архитектура предшествует угрозам

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

Пусть \(S\) обозначает множество состояний системы, и пусть

\[s_i \rightarrow s_j\]

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

Тогда сценарий атаки можно рассматривать как последовательность достижимых переходов

\[s_0 \rightarrow s_1 \rightarrow \ldots \rightarrow s_n,\]

где \(s_0\) — состояние, доступное атакующему, а \(s_n\) — состояние, в котором целевое свойство безопасности может быть нарушено.

Это меняет порядок моделирования угроз.

Вместо

\[\text{catalogue} \rightarrow \text{threat} \rightarrow \text{risk assessment},\]

анализ должен выполняться примерно так:

\[\text{system} \rightarrow \text{architecture} \rightarrow \text{trust boundaries} \rightarrow \text{reachable states} \rightarrow \text{attack paths} \rightarrow \text{threats}.\]

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

DoS внутри сети управления

Это различие становится особенно заметным в промышленных системах управления.

Предположим, модель угроз содержит сценарий

DoS-атака на каналы связи ICS.

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

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

Для сильно изолированного технологического сегмента это предположение далеко не тривиально.

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

Следовательно, реальный сценарий ближе к

\[s_{\mathrm{external}} \rightarrow s_{\mathrm{compromised}} \rightarrow s_{\mathrm{OT}} \rightarrow s_{\mathrm{DoS}}.\]

Интересные вопросы безопасности относятся к стрелкам.

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

Начинать анализ непосредственно с \(s_{\mathrm{DoS}}\) означает удалить именно ту часть сценария, которую должна объяснить модель угроз.

Недостижимость — это не низкий риск

Это различие также влияет на количественную оценку риска.

Предположим, интегральная модель риска присваивает числовое значение сценарию DoS. Низкое значение может наводить на мысль, что сценарий маловероятен или относительно неважен.

Но существует категориальная разница между

\[\text{достижимой атакой с низкой вероятностью}\]

и

\[\text{атакой, требующей состояния, которое моделируемая архитектура не допускает}.\]

Последнему не следует просто назначать меньший коэффициент.

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

И наоборот, обнаружение такого пути само по себе является важным результатом. Если атакующий может неожиданно переместиться из внешней или менее доверенной среды в защищённый технологический сегмент, проблема безопасности недостаточно описывается конечной техникой атаки. Вновь обнаруженный переход в архитектуре может быть важнее, чем DoS, MitM, инъекция команд или другое действие, которое в итоге выполняется через него.

Модели угроз как модели достижимости

Это предлагает простую интерпретацию моделирования угроз.

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

Каталоги атак описывают известные механизмы переходов. Базы данных уязвимостей описывают условия, которые могут позволить некоторые из этих переходов. Архитектура ограничивает, где могут происходить переходы. Границы доверия ограничивают, от кого ожидается их выполнение.

Следовательно, итоговый вопрос — не просто

Может ли существовать эта атака?

а

Может ли эта система достичь состояния, в котором эту атаку можно выполнить, начиная с возможностей, реально доступных атакующему?

Это существенно более сильное требование.

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

Алфавит атак не определяет модель угроз.

Её определяет архитектура.