Заметки о безопасности
Начало работы со средством моделирования угроз SDL
Адам Шостак (Adam Shostack)
Cодержание
Начало работы по моделированию угроз
Анализ угроз
Экран настройки переменных окружения
Отслеживание с помощью отчетов
Меню действий
Встречи, посвященные моделированию угроз
Размышления об активах
Рис. 1 Работа по моделированию угроз
В ноябре 2008 г. корпорация Майкрософт объявила об общей доступности средства моделирования угроз SDL путем бесплатной загрузки с веб-сайта MSDN. В этой статье приводится поэтапный рассказ о том, как отдел начинает работу с моделированием угроз SDL с целью показать, как использовать это новое средство как основу процесса по обеспечению безопасности.
Эта статья не является учебником по моделированию угроз SDL. Для получения подробного руководства обратитесь к статьеMSDN Magazine, выпущенной в ноябре 2006 года. Я написал ее в соавторстве, а называется она «Моделирование угроз: Обнаружение недостатков безопасности при помощи STRIDE». Нарис. 1 представлен краткий обзор этого процесса.
Начало процесса моделирования угроз
При запуске средства моделирования угроз SDL можно увидеть, что правый нижний угол очень напоминает Microsoft Office Outlook благодаря четырем открытым областям просмотра: диаграмма, анализ, среда и отчеты (см. рис. 2 для получения более подробных сведений). Обратите внимание на то, что эти области несколько отличаются от материала на рис. 1, поскольку имеет смысл рассмотреть угрозы и стратегии их устранения, так они тесно связаны друг с другом.
В этом разделе мы проследим за тем, как Деб (разработчик), Пол (руководитель программы) и Тим (тестировщик) выполняют процесс разработки своей первой модели угроз. Кроме того, мы обсудим каждую область просмотра средства.
«Привет, Деб, я работаю над диаграммой модели угроз и хотел бы разобрать ее вместе с тобой, чтобы убедиться в том, что все в порядке».
«Без проблем, Пол! Показывай».
Пол достает распечатку диаграммы, которую создал из отчета средства "Diagrams only" («Только диаграммы»), показанного на рис. 3.
«Знаешь, Пол, я раньше не видел таких диаграмм. На вид она довольно простая, только объясни, зачем все эти разные формы?»
«В рамках этого метода Карл, обычный представитель нашего заказчика, изображен как внешняя сущность -- в виде прямоугольника. Он отправляет команды на наш веб-сервер – кругом обозначен любой выполняемый код, а стрелка указывает на направление взаимодействия. Веб-сервер связывается с базой данных, которая, как и любое место, где хранятся данные, обозначена двумя параллельными линиями. Вся эта система называется диаграммой потока данных (DFD). На википедии есть хорошая статья, посвященная этим диаграмма. Единственный аспект, который мы не рассмотрели, – это граница доверия, обозначенные пунктирными линиями. Эти границы проведены по зонам ответственности разных людей. Например, как вам известно, ИТ-специалисты требуют, чтобы информация о входе в систему хранилась в их системе Active Directory, поэтому Active Directory показана вне зоны нашего управления».
Рис. 3 Диагармма DFD Пола
При запусе средства отображается область просмотра диаграммы. Именно здесь Пол использовал средства и представленный трафарет для создания DFD (см. рис. 4). Несмотря на то, что он впервые выполнял эту задачу, у него не возникло сложностей: средство проверки, расположенное слева, помогало ему на основе его опыта в использовании моделирования угроз в SDL. Изображая все более сложные концепции, он добавлял дополнительные детали, щелкая правой кнопкой мыши контекстную папку в правом верхнем углу, и в итоге создал сложную многоуровневую диаграмму.
Рис. 4 Область просмотра переменных диаграммы
Анализ угроз
Открыв область просмотра анализа, Пол был слегка озадачен (см. рис. 5). Ам он увидел большой список угроз – откуда они все взялись? Их создало средство с помощью подхода SDL, который называется «STRIDE по элементам». Идея заключается в том, что программное обеспечение, как правило, подвергается прогнозируемому набору угроз (они показаны на рис. 5). Некоторые специалисты по безопасности любят первыми устроить охоту на взломщиков, потому что это само по себе весело. Мне кажется, что разумно обезопасить свой дом, установив замки на окна и двери, а только потом заниматься вопросами сигнализации. Поэтому начните с подхода «STRIDE по элементам», щелкнув любое из строк в области просмотра анализа.
Рис. 5 Область просмотра анализа
Пол начал с того, что выбрал базу данных в списке элементов. В верхней части области просмотра он прочел о том, что «база данных» – это хранилище данных, значит, она подвергается угрозам взлома, раскрытия информации и отказа в обслуживании. Он продолжил чтение, и вопросы помогли ему задуматься о том, как люди могут взломать данные. Он понял, что никто не указал, кому можно подключаться к базе данных. Диаграмма на белой доске и несклько простых правил открыли первую угрозу! Первое очко в области моделированию угроз.
Через несколько минут обсуждения они поняли, что нужно подумать о контроле доступа и ролях. Пол сделал несколько заметок о первых двух угрозах. На первой было написано: «Отсутствие плана контроля доступа». Он также отправил рабочий документ в базу данных Team Foundation Server (TFS). Вторая заметка гласила: «Контроль доступа требует списка ролей». Затем Пол отправился в TFS и создал вторую ошибку, которая зависела от первой.
Поскольку Пол занялся вопросом раскрытия информации, он понял, что их план контроля доступа требует несколько записей с правами «только чтение» для аудита и создания отчетов. Он задумался о том, не новая ли это угроза, а затем решил, что это не так, поскольку стратегия ее устранения такая же, а он уже исправил эту ошибку в TFS. Затем он решил пометить эту угрозу как устраненную везде и записал: «Устранено в TFS ошибка №235». Он не был уверен в том, что этого достаточно, но для того и существует функция проверки (см. рис. 6).
Рис. 6 Проверка того, что угрозы неприменимы
Кроме того, он еще подумал о раскрытии информации и понял, что для резервного копирования необходимо шифрование, но это работаотдела операций. (Я расскажу о том, как он отследил этот вопрос в течение минуты, после того как расскажу о еще одной функции, связанной с этой: флажок "auto-generate threats for this element" (автоматическое создание угроз для данного элемента), расположенный наверху.
Функция автоматического создания предназначена для крупных отделов, где существует множество моделей угроз и у которых существует способ гарантировать то, что все тестировщики и руководители программ обсуждают, что именно заключено в моделях угроз. Поэтому в данной ситуации Пол мог сказать, что Фил несет ответственность за несколько элементов, которые нужно показать для контекста и для того, чтобы узнать, как они взаимодействуют с его функциями. Флажок автосоздания установлен по умолчанию, но Пол может отключить его и сказать, что это функция Фила.
Экран настройки переменных окружения
Обеспокоенный операциями шифрования резервных копий, пол открыл экран настройки переменных окружения и увидел раздел для внешних примечаний в области безопасности (см. рис. 7). Там он сделал примечание о том, что отдел операций должен поработать с резервными копиями. Ему нужно позаботиться о том, чтобы у них был экземпляр этого средства.
Рис. 7 Внешние примечания в области безопасности
Находясь в этом разделе, он думал о том, что представляет собой раздел заголовка документа, и с облегчением понял, что там есть справочная информация, гласившая, что здесь можно определить, кому принаждлежит модель угроз, для чего она предназначена и так далее. Он заполнил этот раздел, и ему понадобилось указать номер отслеживания проекта Contoso.
Перемещаясь по элементам дерева, Пол обратил внимание на то, что существуют зависимости от SQL Server и библиотки средств визуализации Fabrikam Foxy Web Widgets 2.3. Пол оставил замечание о том, что этим вопросом должен заняться Тим, а также убедиться в том, что они обновлены и получают уведомления безопасности от Fabrikam.
Отслеживание с помощью отчетов
Существует пять видов отчетов моделирования угроз.
Аналитический отчет Данный отчет предназначен для того для советника по вопросам безопасности или консультанта с тем, чтобы они выполнили обзор модели угроз, несмотря на то, что любой может использовать его для того, чтобы узнать, какие проблемы при проверке диаграммы не решены, какие угрозы еще не внесены в нее, для каких угроз нет решений, какие угрозы были проверены или помечены как не создающие угрозы.
Модель отчета об угрозе Этот отчет включает в себя сведения, введенные в модель угрозы, представленные на отдельной странице.
Только диаграммы Этот отчет создается с целью упростить печать диаграмм. Некоторым людям нравится работать с бумагой, но нет необходимости в печати всего отчета целиком, если нужны только диаграммы.
Отчет об ошибках В данном отчете показаны ошибки, полученные из данной модели угроз, и их состояние
Отчет по тестированию компонентов наборами случайных входных данных Этот отчет использует информацию архитектуры, предоставляемую на этапе создания диаграммы, для создания списка приоритетов целей тестирования. Тестирование компонентов наборами случайных входных данных – это методика тестирования, которая включает в себя создание случайных данных ввода для программы. Просто удивительно, насколько полезной она может быть, если необходим сбой, а многие из сбоев можно изучить. (Обратитесь к материалам Создание настраиваемого тестового интерфейса поставщика для системы отдела илиFuzz Testing at Microsoft and the Triage Process (Тестирование наборами случайных данных и сортировка результатов тестирования по степени важности выявленных проблем в корпорации Майкрософт) для получения дополнительных сведений по этому вопросу.)
Меню действий
В меню действий есть парочка полезных функций: эскизы, параметры отслеживания ошибок и режим руководителя. Эскизы предоставляют простой доступ к диаграммам, когда вы находитесь в других областях просмотра. Это полезно, если у вас сложная диаграмма, а вам хотелось бы, чтобы при анализе модели эта диаграмма была в области просмотра. Размер эскиза автоматически изменяется так, чтобы она занимала большую часть экрана, таким образом, при изменении размера видна вся диаграмма.
При попытке отправки ошибки без указания какой-либо информации о ней появится диалоговое окно отслеживания ошибки, но его также можно вызвать в любое время через меню действий. Это очень простой файл XML, который можно использовать для определения того, какие поля следует заполнять, или можно просто изменить значения полей (при условии, что флажок "use template" (использовать шаблон) не установлен). Ошибки автоматически получают название «TM: [threat] affects [element]», а их содержимое предварительно заполняется на основе сведений об угрозе и ее устранении. Поля можно удалить, выбрав их и нажав клавишу «Delete».
В режиме руководителя отображается новый раздел, где описан экран настройки переменных окружения, который называется Template Settings (параметры шаблона). Этот экран позволяет руководителю проекта изменять руководящие вопросы и устанавливать местоположение по умолчанию для сохранения моделей угроз. Руководитель также может изменять значения полей в заголовке документа, добавляя и удаляя параметры в соответствии с окружением.
Пол, как и собирался ранее, добавил номер отслеживания проекта Contoso как новое поле. Любая модель угрозы, сохраненная в режиме руководителя, может функционировать в качестве шаблона.. (На сама деле, любая модель угрозы может функционировать как шаблон для дополнительной работы.)
Изменение руководящих вопросов включает в себя изменение файла XML, который находится в папке средства моделирования угроз SDL \Data. Этому формату очень просто следовать.
Встречи, посвященные моделированию угроз
Когда Пол распространил свою модель угроз, Тим, тестировщик, был не в восторге. На него сразу навалилось множество дел, и он спросил Пола: «Вы, руководители, всегда думаете, что все будет работать, да?»
Это может показаться удивительным, но вклад тестировщиков и их скептицизма в дело моделей угроз очень велик. В результате во многих отделах тестировщиков просят руководить процессом моделирования угроз. В нашей ситуации после того как Тим взялся за модель угроз, он назначил два собрания по моделированию угроз: первое – по синхронизации процесса и рассмотрению диаграмм, второе – по обзору угроз и завершению работы.
На первом собрании Тим посвятил 10 минут рассказу о процессе моделирования угроз SDL. Затем он достал диаграмму и начал более подробное объяснение. За пять минут было выявлено отсутствие важного компонента.
Еще через несколько минут Тим и Пол углубились в более подробное обсуждение того, как в действительности собран веб-сервер. Это был не самый лучший вариант продолжения собрания, но все согласились с тем, что обнаружение проблемы на раннем этапе в дальнейшем сэкономит всем массу времени.
На втором собрании отдел обсудил угрозы и способы борьбы с ними и закончил работу с моделью. Документ был помещен в систему управления версиями, и разработка была продолжена.
Размышления об активах
Многие читатели, работавшие с моделированием угроз, возможно, заметили, что мы совсем не говорили об активах. Мы узнали о том, что многие разработчики ПО понимают ПО лучше, чем концепцию активов и то, в каких именно активах заинтересован злоумышленник.
Собираясь создать модель угроз для дома, вы, наверное, начнете думать о семейных или редких фотографиях или ценных картинах. Возможно, вы размышляете о том, кто может влезть в дом, и об установленной системе безопасности. Или же, возможно, вы думаете о его физических особенностях, например бассейне или двери на веранду. Такие размышления аналогичны размышлениям об активах, злоумышленниках или разработке ПО. Любой из этих подходов сработает.
Подход, продемонстрированный в этой статье, значительно проще, чем предложенные корпорацией Майкрософт в прошлом. Отдел SDL корпорации Майкрософт обнаружил, что подход с точки зрения разработки ПО отлично работает для разных отделов. Надеемся, в их число войдет и ваш.
Вопросы и комментарии направляйте по адресу briefs@microsoft.com.
Адам Шостак (Adam Shostack) является руководителем программы в группе жизненного цикла разработки безопасности (SDL) в корпорации Майкрософт. Он занимается разработкой компонента моделирования угроз SDL.