Выявленные проблемы и накопленный опыт

Моделирование угроз как tabula rasa

Многие специалисты, имея свое представление о том, как должно выглядеть моделирование угроз (термин, имеющий, как я уже отметил в разделе 1.1, множество значений), воплотили эти представления в своих методологиях и дополнениях к существующим методам. Чаще всего такие дополнения создаются без учета и осознания того, какие затраты потребуются на их внедрение, каковы приносимые ими выгоды и издержки. Пример – внедрение методики оценки рисков DREAD [6]. Для некоторых систем эта методика работает, но при моделировании угроз с акцентом на программном обеспечении методика DREAD начинает вводить числовые переменные, не задавая их области определения, что приводит к опасности принять оценку рисков за алгоритмическую, в то время как она таковой не является. Тем не менее, SDL-моделирование угроз в Microsoft явно нуждается в методике управления рисками, и поэтому DREAD была внедрена.

Сложность

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

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

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

Жизненность

Моделирование угроз может показаться сильно оторванным от реальной разработки программного обеспечения. Складывается такое ощущение, что меткое выражение «YAGNI» (Вам это никогда не понадобиться, «You Ain’t Gonna Need It») было создано специально для этого вида деятельности. Использование ряда подходов позволило интегрировать моделирование угроз в процесс разработки программных продуктов (сюда относится, например, работа с угрозами как с ошибками в программном коде и представление мер борьбы с ними в виде функциональных особенностей системы). Разработчики отлично понимают, что такое ошибки и функциональные особенности, и компании знают, как с ними работать. Кроме того, мы призываем проводить дискуссии в отделах по безопасности, задавая простой вопрос «можно взглянуть на Вашу модель угроз?». Это побудит Вас и Ваших коллег разрабатывать действительно хорошие модели (В большинстве случаев подходы, подобные Microsoft SDL, применяемые к различным методологиям разработки, могут показаться оторванными от жизни. Однако это вообще свойственно области моделирования угроз).

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

Люди в модели угроз

Представление людей в моделях угроз рассматривалось уже не одним исследователем. Эллисон (Ellison) в работе [3] доказывает, что действительно полное описание сетевых протоколов само по себе включает учет и компьютеров, и людей. Неэффективное представление людей в модели приводит к таким проблемам, как фишинг, когда сочетание трех уровней слабой аутентификации отрывает двери для мошенников (здесь три уровня – это неадекватные схемы аутентификации электронных адресов, web-сайтов и пользователей). Моделирование пользователей представляет собой крайне сложную задачу, однако если эта задача не решается, то неизбежно возникают серьезные проблемы с безопасностью системы. Вопрос о том, как помочь инженерам эффективно решать эту задачу, остается открытым; например, он рассматривается в работе Крэнора (Cranor) [7].

Люди как пользователи систем моделирования средств защиты

Инженеры, разрабатывающие средства для таких же инженеров, обычно не беспокоятся об удобстве использования этих средств. Между тем, вопросам разработки пользовательского интерфейса, взаимодействию между человеком и машиной и другим подобным темам посвящено множество работ, и я подозреваю, что разработчики систем прекрасно с ними знакомы. Я бы хотел рассмотреть три аспекта, которые имеют большое значение при создании систем моделирования средств защиты, предназначенных для использования широким кругом специалистов. Первый состоит в необходимости четко определить, на пользователей какого уровня рассчитана Ваша система. Традиционная рекомендация «мыслите как злоумышленник» для большинства людей лишена всякого смысла (Более того, многие люди неохотно признавались в том, что на самом деле не понимают, что значит «мыслить как злоумышленник». Обычно этот совет подавался так, как будто «мыслить как злоумышленник» – это самое естественное и простое занятие на свете. Поэтому осознание того, насколько важна Ваша модель пользователя, так же необходимо, как и проверка того, что Ваша модель действительна применима).

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

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

Вопросы, предлагаемые нами для исследований

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