Аннотация. В данной статье описаны десять лет работы Microsoft по созданию программных продуктов и служб для моделирования угроз. Рассмотрена современная методология моделирования, использующаяся в цикле разработки программного обеспечения Security Development Lifecycle. Данная методология представляет собой практический подход, который могут применять и неэксперты. Этот подход основан на построении диаграмм потоков данных и методе перечисления "угрозы на элемент". Статья описывает тот опыт, который будет полезен и при использовании других методик анализа безопасности. В заключении работы приводятся возможные темы для дальнейших научных исследований.
1 Введение
Компания Microsoft использует различные методологии моделирования угроз с 1999 года. Эти методы помогали находить ошибки в защите программных продуктов и были объединены в Security Development Lifecycle (SDL) - набор процедур, применяемый ко всем разработкам Microsoft, предполагающим работу с высоким уровнем угроз безопасности и конфиденциальности. Microsoft и сейчас продолжает развивать и совершенствовать имеющиеся инструменты, методологии и процедуры с учетом накопленного опыта. Данная статья призвана рассказать об истории создания SDL-методов моделирования угроз и об уроках, усвоенных в процессе их разработки (которые могут оказаться полезными и за пределами Microsoft), описать используемые сегодня подходы и поделиться темами, представляющими, как мы надеемся, интерес для научных исследователей.
Автор является обладателем прав на средства моделирования угроз в SDL, включая процессы, инструменты и методы обучения. Так как данная статья написана одним автором, единственное число будет использоваться в ней для выражения собственных суждений и личного мнения автора, а множественное - для описания взглядов, с большой вероятностью поддерживаемых всей нашей организацией. Например, это касается следующего раздела - я уверен, что в Microsoft не существует единого мнения по поводу выбора между дескриптивной и прескриптивной лингвистиками.
1.1 Что я имею в виду под моделированием угроз
Термин "моделирование угроз" имеет множество значений. Для ответа на вопрос "что такое моделирование угроз?" я воспользуюсь дескриптивным подходом и опишу, как может использоваться данный термин, вместо того, чтобы пытаться подобрать для него одно строгое определение. Итак, рассмотрим наиболее распространенные значения: термин "угроза" используется для обозначения как злоумышленников, то есть людей, атакующих систему, так и рисков, то есть тех нежелательных событий, которые могут произойти. Моделирование угроз может относиться как к методике установления требований к системе ("каковая принятая Вами модель угроз?"), так и к методике конструкторского анализа ("разрешите взглянуть на Ваш анализ модели угроз?"). Кроме того, моделирование угроз может строиться на рассмотрении ресурсов, злоумышленников или программного обеспечения. Моделирование угроз, ориентированное на ресурсы, часто включает в себя различные уровни оценки, аппроксимации или ранжирования рисков. Моделирование угроз с акцентом на злоумышленниках иногда включает ранжирование рисков или оценку ресурсов, возможностей и мотиваций (выполнение таких оценок представляет крайне сложную задачу для разработчиков пакетов программ широкого применения, так как разнообразие вариантов использования влечет и разнообразие угроз, связанных с каждым конкретным применением). Каждый подход к моделированию угроз имеет свои сильные и слабые стороны, на которых я буду при необходимости останавливаться, объясняя некоторые другие аспекты или описывая полученный опыт.
Кроме того, о моделировании угроз можно говорить применительно к анализу программных продуктов, организационных сетей, систем или даже промышленных секторов (см., например, [9]). Моделирование протоколов часто выполняется с использованием разнообразных формальных методов, иногда называемых моделями сетевых угроз. Термин "моделирование сетевых угроз" также используется при анализе развернутой сети.
Наконец, моделирование угроз может выполняться экспертами по безопасности с последующей передачей результатов инженерам, совместно экспертами и инженерами либо одними инженерами без участия экспертов. Специалисты по безопасности могут усомниться в ценности последнего подхода. Тем не менее, существует, по крайней мере, две причины, по которым стоит проводить моделирование угроз без экспертов. Во-первых, эксперты могут просто отсутствовать в организации по финансовым или иным причинам. Во-вторых, вовлечение в процесс моделирования людей, которые будут разрабатывать систему, но которые не являются специалистами по безопасности, позволяет им ощутить свою причастность к защите системы и обрести понимание модели безопасности. Моделирование угроз включает в себя множество различных процедур по выявлению требований к безопасности системы и по анализу различных схем защиты. Не существует одного "лучшего" или "правильного" метода моделирования угроз, напротив, необходимо сочетать и комбинировать различные альтернативы для того, чтобы достичь явно заданных или скрытых целей.
1.2 Оценка методологий
При оценке какой-либо методологии важно решить, с чем ее сравнивать. Разумеется, любое решение может быть легко раскритиковано относительно некоторого идеального представления о том "что нужно было бы сделать, не будь у нас никаких ограничений". "Что нужно сделать?" - очень важный вопрос для исследователей, и мы полностью поддерживаем изучение таких вопросов. Однако существуют и другие вопросы, которые особенно важно поднимать на конференциях, собирающих вместе ученых и специалистов-практиков: "что обычно делается?" и "что препятствует внедрению новых методов?". А главным в этом смысле становится вопрос "как необходимо усовершенствовать существующие процедуры и сколько это будет стоить?". Под стоимостью здесь подразумеваются затраты на внедрение (обучение, установку, программное обеспечение) и дальнейшее развитие проекта. Основными целями моделирования угроз для нас являются повышение уровня защищенности выпускаемых продуктов, документирование результатов анализа (как в целях проверки, так и для повторного использования) и обучение работников проведению непрямого анализа безопасности, даже если они не должны непосредственно решать задачи моделирования угроз.
2 Немного истории
Процесс моделирования угроз был впервые описан в 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.
Я привел здесь эти публикации для того, чтобы показать, как развивалась наши методологии; более того, они продолжают эволюционировать, чтобы отвечать тем запросам, которые мы выработали в процессе развития. Сначала я опишу систему, используемую нами сегодня, затем проанализирую некоторые из требований, повлекших развитие системы, а затем рассмотрю возникшие в связи с этим проблемы и вопросы, которые могут заинтересовать ученых-исследователей, надеющихся довести до реализации свои инновационные системы.
3 Современная методология SDL
Современная методология моделирования угроз в SDL представляет собой процесс, состоящий из четырех этапов, разработанный для того, чтобы сократить объем экспертных оценок безопасности, которые необходимы инженерам для построения модели угроз и уверенности в том, что все серьезные угрозы действительно были определены. Целями данной процедуры являются повышение уровня безопасности разработок, документирование событий, связанных с защитой продуктов, и обучение работников вопросам защиты системы в процессе разработки. Метод включает четыре основных этапа: построение диаграмм, перечисление угроз, снижение рисков и проверку.
3.1 Построение диаграмм
Обычно мы пользуемся системой диаграмм, заимствованной из методологии построения диаграмм потоков данных (Data Flow Diagram, DFD), добавляя к ней "границы доверия". Как оказалось, такие DFD-элементы как "процесс", "хранилище данных", "поток данных" и "внешний элемент" отлично работают в качестве средств извлечения информации и могут использоваться при проведении анализа. Описание этих элементов приведено в таблице 1. Кроме того, мы добавили элемент "границы доверия", изображаемый в виде пунктирной линии или прямоугольника, который показывает, что элементы, расположенные по разные стороны от этой границы, функционируют на разных уровнях привилегий. Первоначальное решение об использовании DFD было основано на двух факторах. Во-первых, стандарт DFD прост для понимания, и, во-вторых, он ориентирован именно на рассмотрение данных. Огромное количество атак тем или иным образом используют потоки данных, проходящие через систему, а значит, DFD позволяет рассматривать как раз самую важную сторону вопроса. Опыт 7-8 лет применения DFD-подхода к построению диаграмм показал его надежность и эффективность. Другие методологии, предлагаемые для заметы DFD-подхода, должны продемонстрировать заметные преимущества перед DFD, чтобы мы могли рассматривать их в качестве альтернативы.
|
Название |
Внешний элемент |
Процесс |
Поток данных |
Хранилище данных |
|
Графическое изображение |
круг |
прямоугольник |
стрелка |
параллельные линии |
|
Определение |
Объекты, не находящиеся под нашим контролем |
Программный код |
Как информация передается между элементами |
Стационарные данные |
|
Примеры |
Люди, другие системы, web-сайты |
exe-файлы, сборки, COM-компоненты |
Вызовы функций |
Файлы, базы данных, регистрационные ключи |
Таблица 1. DFD-элементы
Обычно DFD-диаграмма содержит от 10 до 150 элементов (не включая границ доверия и текстовых пояснений). Основную сложность в диаграмму вносят границы доверия и та степень детализации, которая необходима для описания процессов, происходящих при переходе объектов через эти границы. Для многих систем мы строим диаграммы по восходящему принципу, и тому есть две причины. Во-первых, в Microsoft часто организуют группы, состоящие из разработчиков, испытателей и руководителей проектов, которые занимаются только выделенным для этой группы вопросом или вопросами. Поэтому представляется естественным и логичным разделить работу по моделированию угроз между этими группами так, чтобы каждая команда составляла модель угроз для своей части проекта. Вторая причина состоит в том, что язык SDL требует наличия моделей угроз для "всех новых блоков и продукта в целом". Я коснулся этого вопроса для того, чтобы показать, как одна конкретная формулировка в каком-либо описании может привести к совершенно неожиданным последствиям.
3.2 Перечисление угроз
Начало. Большинство инициатив по моделированию угроз, возникавших в 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-каналами.
3.3 Снижение рисков
На семинарах и в работах по SDL-моделированию угроз обсуждаются четыре подхода к снижению рисков, а именно (в порядке возрастания предпочтительности): перепроектирование; использование стандартных методов снижения рисков, таких как списки управления доступом (Access Control List, ACL); использование (с осторожностью) уникальных методов; работа с рисками в соответствии с политиками безопасности.
С точки зрения инженера-практика, соотнесение модели с практическими этапами решения проблемы очень важно. Во-первых, целью моделирования является повышение безопасности системы, а связывание обнаруженной проблемы с методом ее решения упрощает эту задачу. Во-вторых, здесь существует и психологический аспект. Инженер, проинформированный о существовании проблемы, но не получивший ее точного определения или оценки, в большинстве случаев просто растеряется (Найдутся и такие инженеры, которые с энтузиазмом примут этот вызов. Однако опыт показывает, что простые и очевидные методы в сфере информационной безопасности редко срабатывают, поэтому дело, скорее всего, все равно закончится разочарованием. (психологические аспекты будут рассмотрены более подробно в разделе 4.5).).
3.4 Проверка
Мы используем ряд эвристических методов для проверки моделей угроз, включая графовый анализ диаграмм, проверку соответствия итоговых диаграмм конечному программному коду, проверку того, что были перечислены все STRIDE-угрозы элементам, что вся модель угроз была просмотрена, и что для каждой угрозы был найден способ снижения рисков. Мы также стремимся к тому, чтобы иметь возможность сопоставлять модели с программным кодом, написанном на различных языках программирования (более подробно см. раздел 5.1).
3.5 Анализ методологии
Описанный подход применялся при разработке нескольких очень крупных программных продуктов и был интегрирован как в SDL-процессы, так и в другие процедуры создания программного обеспечения. Наш опыт работы с этими процедурами показал, что модели угроз, созданные для программных продуктов, являются корректными и полными. Перенесение этого опыта на более широкий круг других процедур принесет определенные преимущества, но и потребует некоторых затрат. Преимущества состоят в строгом определении ответственности и в интеграции. Конкретные люди будут отвечать за то, чтобы модели угроз были полными с точки зрения границ доверия и точными с точки зрения сущности разрабатываемой системы. Главная трудность же заключается в том, что отсутствие строгой теоретической базы препятствует использованию в моделях имеющихся результатов научных исследований. Однако в целом мы уверены, что простота нашего подхода, его интеграция в процесс разработки, а также новый инструментарий (не описанный здесь) делают эту методологию очень эффективной для выявления и решения проблем, связанных с разработкой коммерческих программных продуктов.
Один из наших рецензентов попросил доказать, что "приведенные подходы являются верными". Однако я не утверждаю, что это так. Я утверждаю, что эти подходы могут быть полезны при разрешении трудностей, с которыми мы сталкиваемся, и о которых я говорил выше. Учитывая многозначность термина "моделирование угроз" и разнообразие решаемых процессами задач, я не думаю, что можно говорить о правильных или неправильных подходах; подходы могут быть только более полезными или менее полезными.
4 Выявленные проблемы и накопленный опыт
4.1 Моделирование угроз как tabula rasa
Многие специалисты, имея свое представление о том, как должно выглядеть моделирование угроз (термин, имеющий, как я уже отметил в разделе 1.1, множество значений), воплотили эти представления в своих методологиях и дополнениях к существующим методам. Чаще всего такие дополнения создаются без учета и осознания того, какие затраты потребуются на их внедрение, каковы приносимые ими выгоды и издержки. Пример - внедрение методики оценки рисков DREAD [6]. Для некоторых систем эта методика работает, но при моделировании угроз с акцентом на программном обеспечении методика DREAD начинает вводить числовые переменные, не задавая их области определения, что приводит к опасности принять оценку рисков за алгоритмическую, в то время как она таковой не является. Тем не менее, SDL-моделирование угроз в Microsoft явно нуждается в методике управления рисками, и поэтому DREAD была внедрена.
4.2 Сложность
Многие специалисты, занимающиеся моделированием угроз, не проходили соответствующее обучение, а просто узнали о том, что нужно делать, от других. Я был очень удивлен, увидев однажды целый отдел компьютерной безопасности, все сотрудники которого хорошо разбирались в методиках моделирования угроз и владели профессиональной лексикой, при этом ни разу не посетив какой-либо семинар. В Microsoft существует множество курсов по безопасности, инструментов и методик, однако стоит отметить, что большинство инженеров посетили максимум 2 часа семинарских занятий за последние несколько лет.
Метод, приведенный в описании SDL, включает 9 этапов. Некоторые другие методы содержат до 11 этапов. Сложность этапов сильно различается и варьируется от "описать сценарии использования" до "определить типы угроз". И если первое задание большинство инженеров должно выполнить, то второе, скорее всего, окажется не под силу неэкспертам, да и среди экспертов вызовет существенные разногласия. Описания методологий изобилуют специальными терминами, что еще больше усложняет их понимание.
Разработчикам методологий следует внимательнее и бережнее относиться к запросам пользователей и тщательно оценивать каждый этап или элемент.
4.3 Жизненность
Моделирование угроз может показаться сильно оторванным от реальной разработки программного обеспечения. Складывается такое ощущение, что меткое выражение "YAGNI" (Вам это никогда не понадобиться, "You Ain"t Gonna Need It") было создано специально для этого вида деятельности. Использование ряда подходов позволило интегрировать моделирование угроз в процесс разработки программных продуктов (сюда относится, например, работа с угрозами как с ошибками в программном коде и представление мер борьбы с ними в виде функциональных особенностей системы). Разработчики отлично понимают, что такое ошибки и функциональные особенности, и компании знают, как с ними работать. Кроме того, мы призываем проводить дискуссии в отделах по безопасности, задавая простой вопрос "можно взглянуть на Вашу модель угроз?". Это побудит Вас и Ваших коллег разрабатывать действительно хорошие модели (В большинстве случаев подходы, подобные Microsoft SDL, применяемые к различным методологиям разработки, могут показаться оторванными от жизни. Однако это вообще свойственно области моделирования угроз).
Существует еще два аспекта, оба связанные с человеческим фактором, на которых я хотел бы остановиться отдельно. Первый - это представление людей в модели угроз, и второй - это проблемы проектирования, вызванные человеческим фактором, возникающие при разработке методов, процедур и инструментов моделирования систем безопасности.
4.4 Люди в модели угроз
Представление людей в моделях угроз рассматривалось уже не одним исследователем. Эллисон (Ellison) в работе [3] доказывает, что действительно полное описание сетевых протоколов само по себе включает учет и компьютеров, и людей. Неэффективное представление людей в модели приводит к таким проблемам, как фишинг, когда сочетание трех уровней слабой аутентификации отрывает двери для мошенников (здесь три уровня - это неадекватные схемы аутентификации электронных адресов, web-сайтов и пользователей). Моделирование пользователей представляет собой крайне сложную задачу, однако если эта задача не решается, то неизбежно возникают серьезные проблемы с безопасностью системы. Вопрос о том, как помочь инженерам эффективно решать эту задачу, остается открытым; например, он рассматривается в работе Крэнора (Cranor) [7].
4.5 Люди как пользователи систем моделирования средств защиты
Инженеры, разрабатывающие средства для таких же инженеров, обычно не беспокоятся об удобстве использования этих средств. Между тем, вопросам разработки пользовательского интерфейса, взаимодействию между человеком и машиной и другим подобным темам посвящено множество работ, и я подозреваю, что разработчики систем прекрасно с ними знакомы. Я бы хотел рассмотреть три аспекта, которые имеют большое значение при создании систем моделирования средств защиты, предназначенных для использования широким кругом специалистов. Первый состоит в необходимости четко определить, на пользователей какого уровня рассчитана Ваша система. Традиционная рекомендация "мыслите как злоумышленник" для большинства людей лишена всякого смысла (Более того, многие люди неохотно признавались в том, что на самом деле не понимают, что значит "мыслить как злоумышленник". Обычно этот совет подавался так, как будто "мыслить как злоумышленник" - это самое естественное и простое занятие на свете. Поэтому осознание того, насколько важна Ваша модель пользователя, так же необходимо, как и проверка того, что Ваша модель действительна применима).
Вторая проблема состоит в необходимости создания строгих и доступных указаний по интеграции методологии моделирования средств защиты в процесс разработки. Инструкции по интеграции могут казаться разработчику абсолютно ясными, и при этом быть совершенно непонятными человеку, в первый раз изучающему данную систему. Четкие указания по тому, как интегрировать модель в быстро протекающий процесс разработки или в процесс, построенный по типу "водопада", помогут преодолеть этот барьер. Например, полезно приводить объяснение того, какие выходные сигналы могут свидетельствовать об ошибках, а какие лишь отражают предусмотренные функциональные особенности системы. Другими словами, моделированием средств защиты занимается широкий круг людей, и все они имеют различные навыки, опыт и цели. Создавайте разноплановые инструменты для решения вопросов безопасности и рассматривайте проблему с различных сторон (включая позицию инженеров и фирм, в которых они работают).
Наконец, третий вопрос может показаться очевидным, но он, тем не менее, заслуживает рассмотрения с точки зрения перспектив использования. Процедуры, которые может выполнить любой образованный и опытный инженер, всегда будут использоваться больше, чем те, которые требуют от специалиста исключительных способностей и навыков. Простота использования и понятная документация очень важны, однако им часто уделяется мало внимания, даже в работах, заявленных как "практические".
5 Вопросы, предлагаемые нами для исследований
Описанные выше методологии меньше опираются на математическое обоснование, нежели многие из тех, что предлагаются на научных конференциях. Как я подчеркнул, этот подход приносит свои выгоды и издержки. Мы хотели бы, чтобы производители программного обеспечения и специалисты по моделированию больше сотрудничали друг с другом. Именно поэтому я попытался описать здесь наши мотивации и основные проблемы, возникшие при принятии нами определенных решений. Я надеюсь, что та часть научного сообщества, которая работает и над прикладными задачами, найдет среди этих проблем темы, интересные для исследования. На пути развития наших процедур и инструментария стоит еще множество практических проблем, некоторые из которых я уже упоминал. Еще три вопроса из тех, что могут быть интересны для ученых-исследователей, я опишу ниже.
5.1 Соответствие моделей и программного кода
Предложенная нами простая модель имеет множество преимуществ. В то же время модель - это еще не программный код, и здесь нам хотелось бы иметь возможность работать по двум сценариям. Первый - когда у нас уже имеется тело программы, но для него не создана ни модель угроз, ни диаграмма потоков данных DFD (такая ситуация может возникнуть, например, после приобретения программного продукта). Мы бы хотели иметь возможность быстро создавать модели, используя исходный код, и тем самым ускорять процесс моделирования угроз. Второй вариант возникает, когда мы имеем и модели угроз, и программный код, и хотим сравнить их друг с другом. Отражает ли модель все границы доверия и точки входа, имеющиеся в коде? Содержит ли исходный код связи, важные для моделирования, но отсутствующие в модели?
Некоторая работа по решению этих вопросов уже была проделана [1]; в ней использовались модели Reflexion Models для полуавтоматического генерирования моделей на основе программного кода и сравнения их с пользовательскими моделями. Однако еще многое нужно сделать для того, чтобы перейти к полностью автоматическому получению моделей из исходного кода. В частности, огромная доля существующих программ написана на языках C и C++, а эти языки являются очень трудными для моделирования и анализа. Впрочем, полученные преимущества могли бы окупить все затраты.
5.2 Введение в модели контроля данных
Одно из самых распространенных правил в обеспечении безопасности звучит так: "принимайте только те данные, которые явно разрешены". Подразумевается, что инженер знает, что под этим подразумевается, и сможет отбросить все остальные входные сообщения. В частных случаях это действительно верно; большая часть данных, поступающих в систему, уже были проверены и занесены в список надежных источников или получили соответствующую отметку, например "допустимый IP-пакет" или "допустимое POP3-сообщение". Однако такие данные не являются надежными вообще, они считаются допустимыми лишь для некоторых целей. Процесс определения списка таких целей может быть простым для небольших задач, но его трудно представить в общем виде. Было бы очень удобно иметь возможность пользоваться специальными языками для описания таких целей, а также инструментами, использующими подобную информацию для повышения эффективности программирования и/или анализа модели средств защиты.
5.3 Количественная оценка моделей угроз
Сегодня нами создается огромное количество моделей угроз. Существует несколько тривиальных параметров, которые мы МОЖЕМ измерить количественно (число элементов, различные меры полноты и словесного наполнения). Гораздо более сложными являются вопросы о том, какие параметры мы ДОЛЖНЫ измерять и ПОЧЕМУ. Какие свойства модели угроз наиболее точно показывают, достигнуты ли поставленные нами цели анализа, обеспечения безопасности и обучения? Говоря иначе, какие параметры системы соответствуют определенным целям и как они с этими целями связаны? Какие затраты потребуются для измерения таких параметров? (Небольшой пример: в одну из наших групп по обсуждению проблем обеспечения безопасности поступило электронное письмо с вопросом о том, как решить определенную проблему. Несколько человек ответило на него; после короткого обсуждения группа выбрала один из предложенных вариантов. Вряд ли какое-то из этих решений было когда-либо формально описано и зафиксировано. Сделанный выбор полностью оправдал себя: мы смогли с небольшими затратами повысить уровень безопасности. Таким образом, документирование повторяющихся решений не имеет особого смысла.) Существует ли возможность проанализировать модель и определить вероятность, с которой она повторяется? Какие еще подходы к измерению параметров могут быть полезны для разработчиков и специалистов, занимающихся принятием решений?
6 Благодарности
Я бы хотел поблагодарить рецензентов Шона Хернана (Shawn Hernan), Стивена Липнера (Steven Lipner), Дж. Д. Мейера (J.D. Meier) и Гленна Питвея (Glenn Pittaway) за ценные замечания по черновикам моей работы, а также своих многочисленных коллег (перечислить всех поименно здесь просто невозможно) за познавательные разговоры о вопросах моделирования угроз.
7 Заключение
В настоящей статье вкратце описана история развития моделирования угроз в Microsoft. Приведены некоторые детали современной состояния вопроса, а также накопленный нами опыт. Кроме того, предложены несколько важных тем для дальнейших исследований, которые, как мы надеемся, могут заинтересовать членов научного сообщества.