Моделирование угроз для тех, у кого лапки (и ручки)

Привет, Хабр! Меня зовут Сергей Зиновьев, я бизнес-партнёр по информационной безопасности в Авито. Если какие-то сканы на безопасность кода легко автоматизировать, то с уязвимостями на этапе проектирования всё обстоит сложнее. Для превентивного выявления подобных проблем организации и сообщества вроде NIST и OWASP рекомендуют использовать моделирование угроз в рамках своих гайдлайнов и фреймворков. В нашей практике это довольно творческий процесс, требующий понимания как продуктовой, так и технической стороны.

В Авито мы масштабировали этот процесс на 2500+ инженеров, и сегодня я расскажу, как мы к этому пришли — с какими сложностями столкнулись, какой фреймворк выработали и как адаптировали его под реальные потребности продуктовых команд.

В этой статье

• Суть процесса и практическая ценность

• Методологии моделирования угроз и международная практика

• Методологии и инструменты

• С какими сложностями мы сталкивались при выборе методологии

• Выработка решения

• Ключевые вопросы и abuse cases

• Приоритизация угроз и артефакты

• Библиотека атак

• Улучшение процесса

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

• Регулярность процесса

• Вместо итогов

Суть процесса и практическая ценность

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

Моделирование угроз обычно проводят в формате мозгового штурма. Команда экспертов обсуждает модель программной системы и отвечает на вопрос «Что может пойти не так?» Главное — не просто найти возможные проблемы, а заранее спланировать, как их избежать. То есть суть процесса заключается в следующем:

1. Нужно построить модель системы

2. Найти слабые места

3. Определить, что и в каком порядке необходимо исправить.

Модель помогает отбросить лишние детали и сосредоточиться на важном. В ИБ — фокус на потоках данных между частями системы и способах, которыми злоумышленник может их украсть, подменить или сделать недоступными, т. е. нарушить их конфиденциальность, целостность или доступность.

Аналогия

Представьте, что вы хотите сделать тумбу с ящиком для хранения документов. Габариты или цвет мебели не влияют на уровень защиты, но важны:

• расположение ящика (чтобы его нельзя было вытащить сверху);

• тип замка (чтобы его нельзя было сбить);

• материал тумбы (чтобы нельзя было проломить стенки);

• крепление к полу или стене (чтобы тумбу нельзя было унести).

Большинство этих пунктов можно сразу учесть ещё на этапе проектирования тумбы.

То же самое происходит при разработке ПО: на этапе технического дизайна для оценки угроз ИБ достаточно листочка бумаги и пары разноцветных карандашей — дёшево и не требует тестового стенда.

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

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

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

1. Определяем основные ценности на участке и в доме.

Например, это сам дом, находящиеся в нём люди, автомобиль в гараже и сейф в спальне.

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

Угрозы могут быть как очень вероятные (например, проникновение на территорию обманом, разрушение забора, природные катаклизмы), так и маловероятные (например, подкоп или падение акулы на крышу). При этом стоит помнить, что «маловероятные» — не значит невозможные.

3. Особенно отметим возможные угрозы для наших ценностей.

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

4. Приоритизируем угрозы, от которых хотим защититься (так как ресурсы ограничены).

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

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

Почему моделирование угроз полезно и необходимо в Авито

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

Секция ИБ в TDR. В Авито есть процесс TDR (Technical Design Review): команды защищают предложенную архитектуру, получают обратную связь и согласуют решения. Это лучший момент для оценки угроз ИБ: код ещё не написан, корректировки стоят дешевле.

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

Моделирование угроз выгодно всем:

• для Авито — удобный и масштабируемый способ снижения рисков ИБ;

• для инженера — рост компетенций и шаг к роли фича-лида.

Методологии моделирования угроз и международная практика

Если вам кажется, что моделирование угроз при разработке ПО — это сложно и искусственно, взгляните на опыт мировых лидеров:

• компания Microsoft десятилетиями продвигает свой подход к оценке угроз ИБ под названием STRIDE:

• американский институт NIST начал стандартизацию моделирования угроз в 2015–2016 годах и постоянно расширяет набор рекомендаций;

• проект OWASP имеет отдельный  стрим по моделированию угроз;

• моделирование угроз требуется уже на первом уровне зрелости ИБ в моделях BSIMM и OWASP SAMM;

• гуру мира Computer Science Мартин Фаулер и его последователи очень детально описали внедрение этой практики в Agile-разработку в гайде.

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

Методологии и инструменты

MITRE ATT&CK®

Это объёмный фреймворк, позволяющий сфокусироваться на деталях реализации благодаря проработанной классификации потенциальных атак. Этот подход не зря некоторые называют «Библией безопасника»: все атаки каталогизированы и упорядочены в соответствии с последовательностью действий при проведении атаки — от разведки и сбора информации до применения деструктивных действий в целевой системе.

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

Elevation of Privilege

Это карточная игра, которая позволяет сделать процесс моделирования угроз более интерактивным и креативным. Требует модератора-ведущего, организующего игровые раунды.

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

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

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

С какими сложностями при выборе методологии мы сталкивались

К числу наиболее очевидных проблем можно отнести:

• необходимость встраивания моделирования угроз в текущие процессы разработки, дополняя их, а не перекраивая с нуля;

• систематизация процесса;

• возможность проведения ретроспективного моделирования угроз наравне с проактивным;

• требуемый порог вхождения в процесс.

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

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

Выработка решения

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

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

Ключевые вопросы и abuse cases

На одном из вопросов хочется остановиться отдельно: «Что может произойти, если решение будет использовано не по назначению?» (abuse cases).

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

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

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

Приоритизация угроз и артефакты

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

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

По итогам моделирования угроз у команды должны появиться:

• схема или описание фичи с указанием потенциальных угроз, привязанных к возможным точкам их появления;

• задокументированные угрозы, которые были приняты или отложены до лучших времён;

• задачи в Jira с указанием DoD для наиболее критичных угроз.

Библиотека атак

Библиотека атак состоит из нескольких разделов:

1. Раздел атак через бэкенд. Здесь мы рассматриваем атаки на недостаточно изолированные микросервисы; атаки, связанные с обработкой входных данных (различные инъекции, получение небезопасных данных и их дальнейшее выполнение на сервере, и прочие валидации) и атаки, основным вектором которых является неавторизованное получение различной служебной и конфиденциальной информации.

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

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

4. Атаки на мобильные платформы. Как правило, угрозы для мобильных приложений таятся на рубеже границ видимости и автоматически исполняемого кода, то есть в JS, WebView и межпроцессном взаимодействии. Использование нестандартных компонентов и переадресация данных между приложениями расширяют потенциальную поверхность атаки по сравнению с более привычным фронтендом, который можно запускать в том числе и из мобильного браузера. 

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

Улучшение процесса

Здесь нам никак было не обойтись без сбора обратной связи для улучшения процесса, чтобы адресовать все вышеперечисленные сложности. В результате полученных отзывов мы сформировали конкретный список критериев применимости моделирования угроз, внедрили секцию информационной безопасности в шаблон TDR. С более глубоким проникновением ИИ в наши процессы мы не раз перерабатывали шаблоны, чтобы они с одной стороны отражали состояние ИБ в TDR, а с другой позволяли фильтровать и подсвечивать потенциальные проблемы с помощью автоматизации и LLM. При этом важно найти баланс: чем понятнее текст для автоматики, тем он менее понятен для человека, который его читает и валидирует. Также в рамках обкатки процесса мы идентифицировали проблему различного фокуса проработки TDR — от высокоуровневого дизайна до точечного улучшения в конкретном сервисе.

Изменение процесса для отдельных случаев

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

Межкомандное взаимодействие

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

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

Мобильное приложение

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

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

Регулярность процесса

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

Вместо итогов

Мы масштабировали решение на 2500+ инженеров, сделав ставку на гибкость подхода, интеграции с другими процессами и обучение. Мы разобрали ключевые типичные ошибки и уязвимости, научили команды их выявлять. В итоге мы перераспределили около 15% трудозатрат на моделирование угроз на команды продуктовой разработки — и снизили порог входа в процесс настолько, что он стал доступен «даже тем, у кого лапки».

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