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

Как упростить сложную задачу

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


Специалисты по кибербезопасности часто задают бесполезный вопрос: «Какая у вас модель угроз?». Ответ совершенно не конкретный и неопределённый, как если бы вы обернулись и сказали «Всё зависит от ситуации». Хуже того, «модель угроз» для многих людей звучит как непонятный технический жаргон, добавляющий ненужной таинственности. И если вы исследуете тему моделирования угроз, то информация может оказаться ошарашивающей и трудновыполнимой. Не существует общепринятого определения для термина «модель угроз» или чего-то подобного.

Так что такое модели угроз и что такое моделирование угроз? Основная идея очень проста. Это понимание причин ущерба от киберугроз. Это использование этого понимания для защиты нашей системы с учётом рисков. В качестве исходной точки мы берём потенциальные угрозы в нашем конкретном случае, а не просто следуем какому-то чек-листу.


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

Реальные истории проникновений демонстрируют сложность угроз и причинно-следственных связей. Подробности зачастую просто поразительны. Яркий пример — история с NotPetya. Разработанный в госструктурах зловред был продан хакерской группой «ShadowBrokers» и превращён в оружие. В итоге это привело к большим потерям среди компаний, в основном случайным образом. Транспортной компании Mearsk пришлось приостановить морские перевозки. Кондитерской компании Cadbury's пришлось приостановить производство шоколада. Каковы были их соответствующие модели угроз? Какие разработчики могли вообразить такую сложную причинно-следственную связь и последовавший ущерб? Сколько времени заняло бы моделирование этого события и всех остальных опасных вероятностей?

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

Сначала технологии

Первая рекомендация: сосредоточьтесь в основном на технических угрозах, а не на масштабных. Хотя бы в первую очередь.

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

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

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

Совместный подход

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

Создание идеальной модели угроз

Часто разработчики ищут какую-то идеальную, финальную, определяющую «модель угроз». Она может иметь форму документа или спецификации, подробно описывающей всю систему вместе с исчерпывающим списком угроз, уязвимостей и деревьев атак.

Первая проблема в том, что ваша система меняется и вы никогда не сможете выявить все угрозы. Вторая проблема в том, что создание отдельного документа не поможет выработать шаги по борьбе с обнаруженными угрозами.

Посмотрите, как далеко вы сможете зайти с помощью этого руководства, прежде чем приступать к созданию сложной и формальной «модели угроз».

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

Принцип моделирования угроз «понемногу и часто»

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

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

Скажу пару слов о методиках PASTA и OCTAVE. Их должны внедрять специалисты по инфобезопасности на полную ставку. Кроме того, эти методики удобны для сред, в которых предпочтение отдаётся большим архитектурам. Хотя в них много полезного, однако в условиях гибких сред разработчикам трудно будет осмысленно внедрять эти методики. Обычно их применение приводит к тому, что тратится много сил на создание всевозможных документов (чаще всего деревьев атак!). А затем, «раздув бюджет», команды не справляются со всеми изменениями в ПО, которые призваны снизить риски.

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

Подготовка

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

Три главных вопроса

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

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


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

Эту структуру создал Адам Шостак, который много пишет о моделировании угроз. Он добавляет и четвёртый вопрос: «Достаточно ли мы сделали?». Я не спорю с Адамом, что нужно отразить и улучшить результат нашего моделирования. Однако я убрал этот вопрос из основной структуры, поскольку считаю, что он может применяться когда угодно. В гибкой разработке априори должно применяться итерирование и улучшение на основе обратной связи, особенно когда мы моделируем «понемногу и часто». В конце этого руководства мы рассмотрим, как отразить, улучшить и расширить результат моделирования угроз вашей командой.

Практические соображения

Нужно кое-что прояснить, прежде чем переходить к моделированию. Следующие подсказки помогут вам в планировании.

Кого нужно вовлечь?

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

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

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

Ритм и длительность

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

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

Очные и удалённые встречи

Что нужно приготовить для очной встречи:

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

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

• Совместное редактирование.
• Создание, изменение и удаление карточек.
• Рисование блочных диаграмм.
• Использование разных цветов.
• Голосование участников.

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

При удалённой встрече вам нужно слегка скорректировать план, чтобы все могли участвовать виртуально. Понадобятся инструменты для видеоконференций и совместной работы. Обсудите и выберите их заранее. Например, команды в ThoughtWorks используют Mural, Miro, Google Jamboard и Google Docs.

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

Вот ещё несколько подсказок для удалённого моделирования:

• Полезно рисовать диаграммы на виртуальных досках до начала обсуждения, потому что это занимает немало времени.
• Убедитесь, что все понимают концепции и символы, используемые для иллюстрирования системы. Объясните обозначения, стрелки потоков информации и цифровую кодировку.
• Внимательнее следите за тем, чтобы все были вовлечены. Попробуйте использовать головоломки на тему инфобезопасности. Обратитесь к универсальным рекомендациям по удалённым встречам.
• Если группа большая, целесообразно разделить её на более мелкие, а затем объединить результаты их работы. Несколько небольших сеансов лучше и надёжнее одного большого.
• Вам потребуется больше перерывов по сравнению с очной встречей. При удалённой работе устаёшь сильнее.

Не важно, очная у вас встреча или удалённая, старайтесь завершить её вовремя. И с конкретными результатами! Для этого необходима дисциплина: предложите опытному сотруднику следить за выдерживанием сроков, чтобы встреча прошла успешно.


Мона Фенцель (Mona Fenzl) и Сара Шмид (Sarah Schmid) из ThoughtWorks Germany успешно используют инструмент для совместной работы Mural. С его помощью они создали шаблон моделирования угроз, чтобы помочь другим начать работу с этим инструментом.

Определение темы встречи

«Определение темы» — это выбор правильной темы и степени детализации. Убедитесь, что вы решили эту задачу до того, как собрали людей. Ориентируйтесь на то, что сейчас важнее всего. Возможно, это какие-то пользовательские сценарии, над которыми вы работаете в текущей итерации?

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

Вот несколько хороших примеров тем:

• Тема текущей итерации.
• Будущая фича, которая повлияет на безопасность, например, новая процедура регистрации пользователей.
• Процесс и инфраструктура непрерывной доставки.
• Конкретный микросервис и связанные с ним сервисы.
• Высокоуровневый обзор системы для определения технического долга.

Какую бы тему вы ни выбрали, убедитесь, что она не слишком велика.

Рабочий пример: выбор темы

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

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

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

Объясняйте и изучайте

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

«Что мы создаём?»

Диаграммы — прекрасный способ объяснить и изучить структуру ПО и его возможности по взаимодействию. В этой части руководства я подскажу диаграммы, которые лягут в основу ваших сеансов моделирования.

Рисуйте «низкокачественные» технические диаграммы

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

Нарисуйте соответствующие компоненты

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

Не нужно рисовать сложно или идеально, просто блоки для основных компонентов и подписи к ним.

Нарисуйте пользователей

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

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

Доверие описывает, кто или что может выполнять определённые действия. Убедитесь, что нарисовали «действующих лиц», потому что они важны для обеспечения безопасности.

Рабочий пример: низкокачественная диаграмма

Вернёмся опять к реальному примеру и посмотрим, как команда проиллюстрировала новую функциональность «страницы с пользовательскими данными»:


Диаграмма отражает понимание системы:

• Она основана на микросервисной архитектуре.
• Уже имеет поставщика идентификационной информации, которая обеспечивает аутентификацию клиента.
• Содержит бэкенд-сервис с пользовательскими данными (написан на Java).
• Содержит сервис Backend for Frontend (BFF) и графический интерфейс для клиентской части (написан на Javascript и React).
• Содержит пользователей, являющихся клиентами, которые хотят редактировать свои профили.

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

Нарисуйте потоки данных

Важно показать, как в системе движутся данные.

III. Стрелками покажите потоки данных

Злоумышленники часто движутся в системе по тем же маршрутам, что и обычные пользователи. Отличие в том, что злоумышленники мешают другим или используют так, как никто не предполагал. Поэтому важно показать доверенные маршруты внутри системы, что помочь другим увидеть, где могут возникнуть угрозы.

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

IV. Подпишите сети и покажите их границы

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

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

Рабочий пример: нарисуйте потоки данных

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

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

V. Нарисуйте свои ресурсы

Полезно быстро обозначить расположение ценных для бизнеса данных или сервисов. Например, хранилища персональной информации. Если ваша система обрабатывает платежи, возможно, ценными будет выполняющий эту задачу сервис. Ресурсы системы — это информация, которую нужно сохранить в секрете или целостности, а также сервисы, которые должны оставаться доступными.

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

Рабочий пример: нарисуйте свои ресурсы

Команда сочла наиболее ценными для бизнеса ресурсами персональную информацию (PII), которая хранится в Customer Service, а также хранилище учётной информации у поставщика идентификационных данных.


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

Мозговой штурм угроз

«Что может пойти не так?»

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

Используйте STRIDE

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

Заранее разберитесь и обсудите с командой все шесть концепций безопасности. Чтобы вам было проще, в ThoughtWorks создали набор карт подсказок. На обратной стороне у них списки примеров:

В интернете никто не знает, что ты собака.

Могут ли данные переполниться и стать инструкциями?

Если улик нет, то легко отрицать случившееся.

Кто ещё может смотреть?

Можно ли уронить сервис?

Насколько легко обойти защиту?

Злой мозговой штурм

Придумывание способов атаковать, сломать или нарушить работу конкретной части ПО — это само по себе моделирование угроз. И то может быть очень интересно!

Кроличья нора: споры о предложениях

Когда участники предлагают угрозы, часто все погружаются в обсуждения. Обычно кто-то предлагает угрозу, а другой говорит: «Да, но...».

Да, но… действительно ли нужно шифрование, ведь данные публичные? Да, но… покрывает ли функциональность библиотеки SQL-инъекции?

Такие дискуссии хорошо, но не сейчас. Во время мозгового штурма «нет неправильных ответов». Позднее в ходе сеанса вы отфильтруете неправдоподобные или менее опасные угрозы. А пока сосредоточьтесь на мозговом штурме.

I. Мозговой штурм угроз!

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

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

II. Следуйте по стрелкам потоков данных!

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

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

III. Записывайте угрозы на листиках для заметок

Записывайте отдельно каждую угрозу: «SQL-инъекция из интернета», «недостаток шифрования в БД», «отсутствие многофакторной аутентификации». Можно записывать вопросы: «нужно ли хранить эти данные?», «можно ли обойти авторизацию?», «кто будет аннулировать аккаунты уволившихся сотрудников?».

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

Рабочий пример: определённые угрозы

С помощью диаграммы команда с помощью STRIDE обсудила каждый поток данных в системе.


Вот что получилось у команды в конце мозгового штурма:


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

Приоритизация и исправление

«Что я собираюсь с этим делать?»

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

Приоритизация по степени опасности

I. Обмен информацией полезен для приоритизации

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

• Ценность для бизнеса — ущерб какого рода представляет опасность для целей организации? Украденная база данных клиентов? Репутационный ущерб?
• Масштабная угроза — каковы вероятные исходные причины ущерба из-за проблем с кибербезопасностью в организации? Нас беспокоит мошенничество? Умышленный вред со стороны сотрудников? Очень умелые хакеры?

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

II. Все голосуют за самые опасные угрозы!

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


Каждый участник должен отдать свои голоса, нарисовав точки на листиках. У всех равное количество голосов. Можно отдавать за одну угрозу несколько своих голосов, если вы считаете это целесообразным.

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

III. Определите самые опасные угрозы

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

Меня часто спрашивают, сколько угроз нужно определить за сеанс? В первый раз достаточно трёх. Это хороший результат с учётом потраченного времени. Но руководствуйтесь здравым смыслом и экспериментируйте. Может оказаться только одна высокорисковая угроза, и тогда имеет смысл сосредоточиться только на ней. Или же за сеанс можно определить 4-5 угроз.

IV. Сфотографируйте диаграмму и запишите угрозы

На этом этапе сфотографируйте диаграмму, чтобы сохранить результат мозгового штурма и приоритизации. Если вы используете удалённые инструменты, то сделайте скриншот или экспортируйте. Можно загрузить картинку в вашу вики или сохранить в репозиторий.

Внесите исправления в бэклог

Крайне важно, чтобы потраченное командой время привело к последующей работе. У разработчиков ПО уже есть хороший способ представления и выбора очерёдности действий по доставке: бэклог. Пора разобраться, какие исправления нужно в него внести, чтобы снизить риски. Используйте для этого устоявшиеся процессы и способы.

Кроличья нора: отказ от использования командного бэклога ради безопасности

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

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

V. Отразите в бэклоге исправления в безопасности

Для каждой приоритизированной угрозы определите конкретные шаги. Можете называть их «контролем», «снижением рисков», «защитой» или просто исправлениями в безопасности. Эти исправления могут принимать разный облик. Описывайте их подробно, чтобы сразу было понятно, когда исправление «сделано» и риск снижен.

• Критерий приемлемости — самый частый вид исправлений в результате моделирования угроз. Такие исправления могут добавлять что-то новое или отражать уже имеющееся истории. Например, вам нужно выполнить какое-то действие, а дополнительным критерием приемлемости может быть проверка авторизации. Нужно иметь возможность тестировать критерии приемлемости.
• Истории (Story) могут возникать для реализации конкретного контроля или для разделения уже имеющегося сценария, это нужно бизнес-аналитику или команде. Например, интеграция одностраничного приложения в систему идентификации может превратиться в историю «Аутентификация пользователя».
• Ограниченные по времени пики (Timeboxed Spikes) полезны, если вы не уверены в своей уязвимости (быть может, обращения к бэкенду очищаются автоматически?) или если не уверены в лучшем решении проблемы и нужно поискать другое.
• Определение завершённости — это набор положений и критериев приемлемости, которые должна соблюсти команда для завершения фичи. Если вы определили, что вызовы API нужно аутентифицировать, авторизовать и журналировать, то нужно отразить это в определении завершённости. Так вы сможете последовательно проверять сценарии, прежде чем завершать их.
• Эпики (Epics) — это значительные части архитектуры безопасности, которые относятся к моделированию угроз. Например, это может быть поставщик идентификационной информации, система событий безопасности или определённое конфигурирование сети. Моделирование угроз будет генерировать эпики на ранних стадиях проекта.

VI. Завершайте встречу

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

Будет прекрасно, если после моделирования вы внесёте исправления, а затем снова проведёте моделирование.

Рабочий пример: задачи в бэклоге

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

Прямое обращение к API с обходом авторизации

Хотя пользователь должен быть залогинен (аутентифицирован), чтобы видеть страницу, команда выяснила, что напрямую к API можно отправлять неаутентифицированные запросы. Это было бы серьёзной дырой в рабочей системе! До этой встрече уязвимость никто не заметил.

Участники добавили в историю следующие критерии приемлемости, чтобы их можно было проверять:

• ЕСТЬ запрос от одностраничного приложения к API.
• КОГДА в запрос не включается корректный токен авторизации для текущего пользователя.
• ТОГДА запрос к API отклоняется как неавторизованный.

XSS или инъекция через вводимые пользователем данные

Профиль пользователя позволяет вводить персональные данные, адреса и параметры доставки. Эта информация интерпретируется разными устаревшими бэкенд-системами, которые могут быть уязвимы к атакам с инъекцией SQL и XML.

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

• Все изменения в API протестированы на очистку от XSS-, SQL- и XML-инъекций.

DoS из интернета

Специалист по безопасности, присутствующий на встрече, напомнил о важности защиты от потери прибыли из-за распределённых DoS-атак.

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

• Как специалист по кибербезопасности, я должен сделать так, чтобы все открытые в интернет графические интерфейсы и API-запросы проходили через CDN, чтобы можно было уменьшить потери прибыли из-за DoS-атак.

Когда работа определена и готова для добавления в бэклог, встречу по моделированию угроз можно считать законченной. До следующего раза!