Новые и перспективные подходы к моделированию угроз ИБ

Различные подходы к моделированию угроз

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

Несмотря на то что существуют и параллельно развиваются три различных подхода к моделированию угроз (Asset Centric, System Centric, Attacker Сentric), в российской действительности, закрепляемой действиями регуляторов, больше всего находит отражение подход, ориентированный на активы, – Asset Centric. Он прослеживается и в нормативных документах ЦБ, начиная с самого СТО БР ИББС и его производных, таких как РС БР ИББС-2.2-2009 и РС БР ИББС-2.9-2016, и в документах ФСТЭК «Методика определения угроз безопасности информации в информационных системах (проект)» и уже ставшей классикой «Методике определения актуальных угроз безопасности персональных данных при их обработке в информационных системах персональных данных», также ориентированных на активы.

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

Подход Attacker Сentric является по сути собой аналогом процесса моделирования нарушителей. В центр внимание ставится мотив злоумышленника (чего он пытается добиться) и то, какие действия он должен предпринять для этого. Фактически можно считать, что наши отечественные фреймворки являются гибридом подходов Asset Centric и Attacker Centric.

Подход System Centric (или Software Centric) предполагает моделирование угроз для конкретных приложений.

Отличным примером такого подхода может служить майкрософтовская практика моделирования угроз в рамках SDL и используемая в ней классификация угроз STRIDE. Особенностью подобных подходов является покомпонентное рассмотрение конкретного приложения и визуализация его в виде DFD (data-flow-diagrams). В итоге угрозы определяются или непосредственно для компонентов (per-Element), или для взаимодействия между компонентами (per-Integration).

STRIDE – предполагает отнесение всех угроз ИБ к одному из шести классов, каждый из которых по сути своей отражает нарушение одного из свойств ИБ и их производных

• Spoofing – аутентификация;
• Tampering – целостность;
• Repudiation – неотказуемость;
• Information disclosure – конфиденциальность;
• Denial of service – доступность;
• Elevation of privilege – авторизация.

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

Ориентация на активы

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

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

Источники информации для моделирования угроз:

• активы (все, что ценно для организации) – определяются в рамках отдельного мероприятия по инвентаризации активов, что само по себе является крайне нетривиальной задачей;
• источники угроз (нарушители) – определяется в рамках отдельных мероприятий по составлению модели нарушителя или используется стандартная модель, предоставленная регулятором;
• угрозы – содержатся в специализированных каталогах угроз (Банк угроз ФСТЭК, CAPEC от MITRE, IT-Grundschutz-catalogues, ENISA Threat Taxonomy и многие другие);
• уязвимости (или недоработки) – базово содержатся в специализированных каталогах уязвимости (Банк уязвимостей ФСТЭК, CWE, CVE, Vulnerability Notes Database и т. д.) и экспертно выявляются для каждого актива с помощью различных техник обследования (аудиты, анализ защищенности);
• вероятность реализации – определяется на основе имеющейся статистики или экспертно с помощью различных техник;
• ущерб от реализации – качественно или количественно определяется, исходя из степени влияния реализованной угрозы на бизнес-процесс/основную деятельность организации. Единственный параметр, который должен определятся не специалистом по ИБ, а бизнес-пользователями.

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

Проблемы Asset Centric-подхода

Все классические подходы к моделированию угроз и последующему анализу рисков имеют одну концептуальную проблему, которую в свое время очень точно сформулировал У. Черчилль: «Генералы всегда готовятся к прошлой войне». В контексте информационной безопасности эту фразу можно перефразировать: «Безопасники учитывают только уже известные угрозы». Но не одно это является проблемой методик, построенных по принципу Asset Centric. На каждом шаге таких методик приходится сталкиваться с задачами, которые с теоретической точки зрения выглядят вполне выполнимыми, но на практике оказываются нерешаемыми в большинстве случаев из-за ограниченных временных и человеческих ресурсов тех, кто проводит моделирование угроз.

Возможные решения с практической точки зрения

На практике перспективное решение подобных сложностей лежит в плоскости принятия ряда допущений, которые могут отличаться в каждом конкретном случае, и кардинального упрощения процесса моделирования угроз за счет перехода к более высоким уровням абстракции. В качестве таких допущений можно рассматривать уход от моделирования угроз для отдельных элементов ИТ-инфраструктуры и переход к моделированию угроз для информационных систем, а лучше целых бизнес-процессов. Переход от частного указания уязвимостей в виде «присутствие уязвимости CVE-2017-xxxx» к верхнеуровневому «отсутствует процесс управления уязвимостями». Отказ от определения вероятности реализации и ущерба от реализации или крайне упрощенное, экспертное определение. Если на текущем этапе требуется только моделирование угроз, направленное на лучшее понимание объекта защиты, без последующего анализа рисков от определения вероятности и ущерба можно отказаться. Использование допущений позволяет реализовать принцип 80 на 20, избавится от большого количества незначительных деталей, учет которых с практической точки зрения крайне трудоемкая задача.

Подобный подход «меняющейся детализации» постепенно находит свое отражение в принимаемой нормативной документации. Например, он в явном виде указан в Приложении А «Основные положения базовой модели угроз и нарушителей безопасности информации» к стандарту «Безопасность финансовых (банковских) операций. Защита информации финансовых организаций. Базовый набор организационных и технических мер»[1]: А.1 Основой для реализации финансовой организацией системы защиты информации являются разработанные и утвержденные модели угроз и нарушителей безопасности информации. Степень детализации содержимого моделей угроз и нарушителей безопасности информации может быть различна и определяется реальными потребностями финансовой организации.

Кроме того, значительно облегчает процесс моделирования угроз использование специализированного инструментария, позволяющего визуализировать связи между всеми описанными выше параметрами. Примером такого инструмента может служить open-source-решение ADtool.

Перспективы

Методы моделирования угроз ИБ постоянно развиваются. Не так давно был опубликована фундаментально новая методология (risk centric threat model), пытающаяся объединить в себе лучшие черты всех остальных методов, – Process for Attack Simulation and Threat Analysis (PASTA). В отличие от большинства остальных методов в рамках этой методологии производится анализ влияния на бизнес, фактически реализуются элементы анализа рисков. PASTA состоит из 7 шагов:

• определение целей;
• определение технического контекста;
• декомпозиция приложения;
• анализ угроз;
• анализ уязвимостей;
• моделирование атак;
• анализ рисков.

По сути своей PASTA является больше чем просто средством моделирования угроз, а скорее полноценным фреймворком по анализу рисков ИБ. Это является одновременно и плюсом, и минусом описываемой методологии. Минус в том же смысле, которым обладают большинство детально проработанных методик моделирования угроз, – излишнее усложнение. К сожалению, в российской ИБ-действительности с учетом повсеместной нехватки кадров полноценно реализовать подобные фреймворки невозможно. Да и нужно ли? Так ли необходимо проводить полноценное моделирование угроз и анализ рисков, чтобы понять, что в системе требуется реализовать парольную политику?

[1] Цитата из проекта документа.