Что я имею в виду под моделированием угроз

Термин «моделирование угроз» имеет множество значений. Для ответа на вопрос «что такое моделирование угроз?» я воспользуюсь дескриптивным подходом и опишу, как может использоваться данный термин, вместо того, чтобы пытаться подобрать для него одно строгое определение. Итак, рассмотрим наиболее распространенные значения: термин «угроза» используется для обозначения как злоумышленников, то есть людей, атакующих систему, так и рисков, то есть тех нежелательных событий, которые могут произойти. Моделирование угроз может относиться как к методике установления требований к системе («каковая принятая Вами модель угроз?»), так и к методике конструкторского анализа («разрешите взглянуть на Ваш анализ модели угроз?»). Кроме того, моделирование угроз может строиться на рассмотрении ресурсов, злоумышленников или программного обеспечения. Моделирование угроз, ориентированное на ресурсы, часто включает в себя различные уровни оценки, аппроксимации или ранжирования рисков. Моделирование угроз с акцентом на злоумышленниках иногда включает ранжирование рисков или оценку ресурсов, возможностей и мотиваций (выполнение таких оценок представляет крайне сложную задачу для разработчиков пакетов программ широкого применения, так как разнообразие вариантов использования влечет и разнообразие угроз, связанных с каждым конкретным применением). Каждый подход к моделированию угроз имеет свои сильные и слабые стороны, на которых я буду при необходимости останавливаться, объясняя некоторые другие аспекты или описывая полученный опыт.

Кроме того, о моделировании угроз можно говорить применительно к анализу программных продуктов, организационных сетей, систем или даже промышленных секторов (см., например, [9]). Моделирование протоколов часто выполняется с использованием разнообразных формальных методов, иногда называемых моделями сетевых угроз. Термин «моделирование сетевых угроз» также используется при анализе развернутой сети.

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

Оценка методологий

При оценке какой-либо методологии важно решить, с чем ее сравнивать. Разумеется, любое решение может быть легко раскритиковано относительно некоторого идеального представления о том «что нужно было бы сделать, не будь у нас никаких ограничений». «Что нужно сделать?» – очень важный вопрос для исследователей, и мы полностью поддерживаем изучение таких вопросов. Однако существуют и другие вопросы, которые особенно важно поднимать на конференциях, собирающих вместе ученых и специалистов-практиков: «что обычно делается?» и «что препятствует внедрению новых методов?». А главным в этом смысле становится вопрос «как необходимо усовершенствовать существующие процедуры и сколько это будет стоить?». Под стоимостью здесь подразумеваются затраты на внедрение (обучение, установку, программное обеспечение) и дальнейшее развитие проекта. Основными целями моделирования угроз для нас являются повышение уровня защищенности выпускаемых продуктов, документирование результатов анализа (как в целях проверки, так и для повторного использования) и обучение работников проведению непрямого анализа безопасности, даже если они не должны непосредственно решать задачи моделирования угроз.

Немного истории

Процесс моделирования угроз был впервые описан в Microsoft как методология в 1999 году во внутреннем документе «Threats to our software» («Угрозы нашим программным продуктам»), составленном Джейсоном Гармсом (Jason Garms), Прэритом Гаргом (Praerit Garg) и Майклом Ховардом (Michael Howard). Надо сказать, что до этого в Microsoft уже занимались моделированием угроз, однако именно в указанной работе соответствующая методология была формализована (я использую здесь термин «формализованный» в значении «приведенный к форме (как следует из названия) рассуждений» [8], а не в смысле математической формализации, необходимой для доказательства теорем. Таким образом, формальная методология содержит набор повторяемых и документально зафиксированных этапов с определенными входными и выходными данными), а моделирование угроз рассмотрено как конструкторская работа с теоретической точки зрения. Позже в Microsoft были опубликованы следующие работы:

- Writing Secure Code (Написание безопасного кода), Ховард (Howard) и Ле Бланк (LeBlanc), 2001;
- Writing Secure Code (Написание безопасного кода), Ховард (Howard) и Ле Бланк (LeBlanc), 2-е издание 2002;
- Threat Modeling (Моделирование угроз), Свидерски (Swiderski) и Снайдер (Snyder), 2004;
- Security Development Lifecycle (Цикл разработки безопасного программного обеспечения), Ховард и Липнер (Lipner), 2006.

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

Современная методология SDL

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

Построение диаграмм

Обычно мы пользуемся системой диаграмм, заимствованной из методологии построения диаграмм потоков данных (Data Flow Diagram, DFD), добавляя к ней «границы доверия». Как оказалось, такие DFD-элементы как «процесс», «хранилище данных», «поток данных» и «внешний элемент» отлично работают в качестве средств извлечения информации и могут использоваться при проведении анализа. Описание этих элементов приведено в таблице 1. Кроме того, мы добавили элемент «границы доверия», изображаемый в виде пунктирной линии или прямоугольника, который показывает, что элементы, расположенные по разные стороны от этой границы, функционируют на разных уровнях привилегий. Первоначальное решение об использовании DFD было основано на двух факторах. Во-первых, стандарт DFD прост для понимания, и, во-вторых, он ориентирован именно на рассмотрение данных. Огромное количество атак тем или иным образом используют потоки данных, проходящие через систему, а значит, DFD позволяет рассматривать как раз самую важную сторону вопроса. Опыт 7-8 лет применения DFD-подхода к построению диаграмм показал его надежность и эффективность. Другие методологии, предлагаемые для заметы DFD-подхода, должны продемонстрировать заметные преимущества перед DFD, чтобы мы могли рассматривать их в качестве альтернативы.

Название	Внешний элемент	Процесс	Поток данных	Хранилище данных
Графическое изображение	круг	прямоугольник	стрелка	параллельные линии
Определение	Объекты, не находящиеся под нашим контролем	Программный код	Как информация передается между элементами	Стационарные данные
Примеры	Люди, другие системы, web-сайты	exe-файлы, сборки, COM-компоненты	Вызовы функций	Файлы, базы данных, регистрационные ключи

Таблица 1. DFD-элементы

Обычно DFD-диаграмма содержит от 10 до 150 элементов (не включая границ доверия и текстовых пояснений). Основную сложность в диаграмму вносят границы доверия и та степень детализации, которая необходима для описания процессов, происходящих при переходе объектов через эти границы. Для многих систем мы строим диаграммы по восходящему принципу, и тому есть две причины. Во-первых, в Microsoft часто организуют группы, состоящие из разработчиков, испытателей и руководителей проектов, которые занимаются только выделенным для этой группы вопросом или вопросами. Поэтому представляется естественным и логичным разделить работу по моделированию угроз между этими группами так, чтобы каждая команда составляла модель угроз для своей части проекта. Вторая причина состоит в том, что язык SDL требует наличия моделей угроз для «всех новых блоков и продукта в целом». Я коснулся этого вопроса для того, чтобы показать, как одна конкретная формулировка в каком-либо описании может привести к совершенно неожиданным последствиям.

Перечисление угроз

Начало. Большинство инициатив по моделированию угроз, возникавших в Microsoft и в других компаниях, были основаны, включая ранние процедуры SDL, на проведении ”мозговых штурмов” или использовании других неформальных подходов к перечислению вариантов. Мозговые штурмы могут быть полезны при участии в них экспертов, но даже в этом случае сохраняются проблемы полноты и повторяемости. Мы осознали необходимость в создании инструмента, позволяющего получать более строгие и понятные рекомендации. Метод, который мы используем сегодня, берет свое начало из неопубликованного анализа CVE и MSRC, проведенного Шоном Хёнаном (Shawn Hernan) и Майклом Ховардом (Michael Howard).

Современная методология. В нашей сегодняшней методологии используются диаграммы, построенные по методике, которую мы называем «угрозы STRIDE на элемент» (STRIDE – Spoofing of user identity (подмена идентификатора пользователя), Tampering (вмешательство), Repudiation (Отказ), Information disclosure (Разглашение данных), Denial of Service (Отказ в обслуживании), Elevation of privilege (Повышение привилегий) – система классификации угроз), позволяющей получать инструкции для неэкспертов и достигать высокой повторяемости. Эта методика основывается на следующем наблюдении: угрозы программному обеспечению, которыми мы занимаемся, можно объединить в кластеры. Принцип методики базируется на том, что каждому типу DFD-элементов соответствуют определенные классы угрозы (см. таблицу 2).

	Подмена	Несанкционированный доступ к компьютеру	Отказ от факта получения или отправки сообщения	Раскрытие информации	Отказ в обслуживании	Повышение привилегий
Внешний элемент	x		x
Процесс	x	x	x	x	x	x
Хранилище данных		x	?	x	x
Поток данных		x		x	x

Таблица 2. Распределение «угрозы STRIDE на элемент»

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

Анализ. Я не претендую на универсальность описанного метода перечисления. Он ориентирован на те проблемы, которыми занимаются в Microsoft; другие организации могут расширить или заменить его. Например, «разглашение информации внешним объектом», казалось бы, хорошо подходит для описания определенного подмножества угроз конфиденциальности. Однако другие компании, специализирующиеся на приложениях Web 2.0, могут заменить список угроз своим, составленным в соответствии с их окружением.

В наших современных инструментах мы размещаем руководство по тому, как каждая из перечисленных угроз проявляется по отношению к элементам различных типов. Очевидно, что необходима разработка более подробного руководства. Например, возможности и методы борьбы с несанкционированным доступом к компьютерам сильно различаются при работе с HTTP GET-запросами, локальными вызовами процедур Windows LPC и Unix-каналами.

Снижение рисков

На семинарах и в работах по SDL-моделированию угроз обсуждаются четыре подхода к снижению рисков, а именно (в порядке возрастания предпочтительности): перепроектирование; использование стандартных методов снижения рисков, таких как списки управления доступом (Access Control List, ACL); использование (с осторожностью) уникальных методов; работа с рисками в соответствии с политиками безопасности.

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

Проверка

Мы используем ряд эвристических методов для проверки моделей угроз, включая графовый анализ диаграмм, проверку соответствия итоговых диаграмм конечному программному коду, проверку того, что были перечислены все STRIDE-угрозы элементам, что вся модель угроз была просмотрена, и что для каждой угрозы был найден способ снижения рисков. Мы также стремимся к тому, чтобы иметь возможность сопоставлять модели с программным кодом, написанном на различных языках программирования (более подробно см. раздел 5.1).

Анализ методологии

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

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