Модель угроз: от статической к динамической

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

В таком виде модель угроз очень похожа на список конфиденциальной информации. Список нужный, но на практике работать с ним сложно - он не конкретен в конкретной организации :-) Допустим, в модели угроз упомянуто использование уязвимостей. Каких? Где? На каких узлах? А если у меня стоит IPS, препятствующая их использованию?

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

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

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

В идеале, наша задача увидеть вот такую картину:

Но тут встает другая проблема. Сеть меняется очень активно. Бизнесу может потребоваться запустить новый сервис, открыть какие-то порты или разрешить протоколы на сетевом оборудовании или межсетевом экране. Мы должны заранее оценить, как изменится модель угроз в этом случае. Выглядеть это может так (опять без средства автоматизации не обойтись):

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

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

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

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

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

Правда на практике модель угроз обычно ограничивается только первым уровнем - простым перечнем угроз, который нередко делается "для галочки" или при построении системы защиты. Динамические модели угроз не так развиты. Отчасти из-за консервативного отношения к этому процессу, отчасти из-за отсутствия достаточного количества доступных средств автоматизации этого процесса. Кстати, о средствах автоматизации. Последние два скриншота принадлежат системе Cisco Advanced Malware Protection и ее функциональности File Trajectory, а первые шесть снимков экрана сняты с системы RedSeal.

Подробнее…

Почему мы никак не дождемся от 8-го Центра ФСБ моделей угроз ПДн?

Давайте взглянем на ст.19 ФЗ-152 в разрезе определения угроз безопасности персональных данных. В соответствие с п.1 ч.2 ст.19, это то, с чем начинается процесс обеспечения безопасности ПДн. Кто может определять такие угрозы? В соответствие с частью 5 той же статьи 19 могут это делать только:

• Федеральные органы исполнительной власти, осуществляющие функции по выработке государственной политики и нормативно-правовому регулированию в установленной сфере деятельности,
• Органы государственной власти субъектов Российской Федерации,
• Банк России,
• Органы государственных внебюджетных фондов,
• Иные государственные органы в пределах своих полномочий,

согласовав полученные модели угроз с ФСТЭК или ФСБ в удобной для всех сторон форме, как это и указано в части 7 статьи 19. Указанные модели угроз в соответствие с частью 6 статьи 19 могут быть расширены ассоциациями, союзами и иными объединениями операторов ПДн. Если такое желание у кого-то возникнет (пока таких прецедентов я не встречал), то получившаяся расширенная модель должна быть также согласована с ФСТЭК и ФСБ в соответствии с частью 7 статьи 19 в порядке, установленным 940-м Постановлением Правительства.

В целом достаточно целостная картина вырисовывается. Есть отраслевой регулятор, который за всю отрасль разрабатывает модель угроз и согласует ее с ФСТЭК или ФСБ. Тем самым снимается с операторских плеч бремя самостоятельной разработки модели угроз, как это было по предыдущей версии ФЗ-152. На первый все красиво и правильно. Но... тут вступают в игру в российские реалии. С момента принятия данной схемы прошло уже почти 2 года и где хотя бы одна разработанная госорганами модель угроз? Именно по новой схеме. Где? Я это предполагал и пока предположения меня не обманывают. Из всех пяти упомянутых выше участников, только Банк России готовит свою отраслевую модель угроз.

Но пойдем дальше. А может ли быть ситуация, когда у оператора ПДн, работающего в какой-либо сфере деятельности, нет отраслевого регулятора? Вот допустим есть госкорпорация "Росатом". Какой из федеральных органов исполнительной власти возьмет на себя функцию выработки модели угроз Росатома? Или ОАО "Газпром" или ОАО "ФСК ЕЭС"? Кто у них отраслевой регулятор? Минэнерго? Что-то я сомневаюсь, что оно способно сделать отраслевые модели угроз для подведомственных ему холдингов. Ну да ладно, Газпром или Росатом. Крупные монополисты. Они и сами в состоянии сделать себе модели угроз (правда, встанет вопрос с их легитимностью...). А вот если взять небольшой Интернет-магазин, торгующий туристическим снаряжением? Или вообще муниципальное учреждение? Или управляющую компанию, работающую в сфере ЖКХ? Кто им будет разрабатывать модель угроз?

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

А есть и третий сценарий. Если внимательно посмотреть на часть 5 статьи 19, то федеральным органом исполнительной власти, осуществляющим функции по выработке государственной политики и нормативно-правовому регулированию в рассматриваемой области, является... Федеральная служба безопасности. Ведь именно в ее епархии находится сфера деятельности под названием "защита персональных данных". Почему бы не запросить у достопочтенного регулятора, который так много усилий приложил для роста уровня защищенности ПДн в России и несмотря на все предложения экспертов, так и не поменял ни статью 19, ни Постановление Правительства №1119, разработанную ими модель угроз?..

Подробнее…

Детальная программа курса "Построение модели угроз"

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

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

1. Что такое угроза и риск?
2. Классификация источников угроз
3. Характеристики угроз и элементы риска
4. Анализ рисков vs. анализ угроз
5. Зачем нужно моделирование угроз
6. Общий подход к моделированию угроз в современном мире
7. Качественная и количественная оценка: сравнение подходов
8. Можно ли доверять экспертам? Метод Дельфи
9. Моделирование угроз на разных этапах жизненного цикла системы
10. 4 стратегии анализа рисков
11. Процесс моделирования угроз
12. Идентификация угроз
13. Анализ последствий (ущерба)
14. Классификация последствий
15. Анализ неопределенностей (чувствительности)
16. Как проверить адекватность модели угроз?
17. Классификация нарушителей
18. Каталоги угроз
19. 16 методов анализа рисков и определения опасностей. Как выбрать адекватный метод?
20. Оценка рисков
21. 5 методов оценки вероятности угроз
22. Потенциал нападения
23. Какая градация вероятностей угроз правильная? 9-тиуровневая, 6-тиуровневая, 3-хуровневая...
24. Как оценить ущерб? Может ли ущерб измеряться не деньгами?
25. Ценность материальных и нематерильных активов. Имеет ли информация стоимость?
26. 12 методов оценки стоимости информации
27. Зарубежные и отечественные методики моделирования угроз - ГОСТ Р ИСО/МЭК 13335-3-2007, ISO\IEC TR 13569, ГОСТ Р 51344-99, "дерево атак", модель угроз Microsoft (методы DREAD и STRIDE), модель угроз OWASP, модель Trike, модель N-Softgoal, модель Digital Security, методики ФСТЭК для персональных данных, коммерческой тайны и ключевых систем информационной инфраструктуры, методика ФСБ и т.п.
28. Примеры моделей угроз
29. Средства автоматизации моделирования угроз
30. Как оформить модель угроз?

Среди рассматриваемых стандартов по данной теме: ГОСТ Р 52448-2005, ГОСТ Р ИСО/МЭК 13335-3-2007, ГОСТ Р ИСО/МЭК 13335-4-2007, ГОСТ Р 51901.1-2002, MAGERIT, ГОСТ 51275-2006, ГОСТ Р 51344-99, ГОСТ Р ИСО/МЭК18045, ISO\IEC TR 13569, IT-Grundschutz Methodology, AS/NZS 4360:2004, EBIOS, MEHARI, OCTAVE, FRAP, NIST 800-30, MG-2, MG-3, SOMAP, IRAM, РС БР ИББС-2.2-2009 "Методика оценки рисков нарушения информационной безопасности", Cisco SAFE и т.п.

Ближайший курс пройдет в Москве 28-го сентября в Институте банковского дела АРБ (очно и онлайн).

Презентация курса: часть 1, часть 2, часть 3, часть 4 и часть 5.

Подробнее…

Тенденции моделирования угроз

На сочинском "Код ИБ. Профи" я буду проводить практический мастер-класс по моделированию угроз. Но до него еще почти 10 дней и поэтому мне сейчас хотелось бы немного коснуться тех изменений и тенденций, которые происходят в этом вопросе. Так уж сложилось, что мы часто рассматриваем моделирование угроз как нечто незыблемое и редкое, что уже давно не соответствует действительности. Мир меняется, должны менять и мы свои взгляды. Что же поменялось за последнее время в области моделирования угроз? Попробую тезисно сформулировать ключевые изменения:

• Угрозы эволюционируют. Да вы что?! Вот это новость! Но как бы очевидно это не звучало, в моделях угроз этот факт не часто находит свое отражение. Такое впечатление (и что уж греха таить, так оно и бывает), что модель угроз делают только для галочки или для регулятора, а не для реальной работы. Вот возьмем, к примеру, утвержденную ЦБ модель угроз для биометрических ПДн. И вроде бы достаточно свежий документ, но в нем в принципе не рассмотрена угроза, которую для простоты можно именовать DeepFake, то есть создание фальшивых лиц, отпечатков пальцев, голосов и иных биометрических факторов. То есть в реальной жизни использовать такую модель нельзя - ее надо существенно дорабатывать.
• Инструментарий спецслужб утекает. И это тоже не новость. Но это меняет потенциальную модель нарушителя, который теперь по своим возможностям сравним с АНБ. Или не сравним? Или все-таки нарушитель определяется не сиюминутными возможностями, которые в определенный момент времени могут совпадать с обычными киберпреступными группировками, а мотивацией и целеполаганием? Но в любом случае, появление инструментария спецслужб в широком доступе требует пересмотра модели угроз.
• Supply Chain. Spectre, Meltdown... Только две уязвимости в процессорах Intel, которые показали всю слабость современной системы защиты, базирующейся на недоверенных элементах. Да, вы ничего с этим поделать не можете, так как взять и выбросить все свои процессоры вы не в состоянии - заменить их нечем. Но внести это в модель угроз надо, так как реализация угроз на аппаратном уровне сегодня уже не редкость и игнорировать эту проблему, закрывая на нее глаза нельзя. А надо ли эту угрозу включать в модель, если вы не в состоянии с ней ничего делать? 
• Гибкая разработка. Вы внедрили SCRUM или Agile или иную методологию гибкой разработки или проектирования? А вы учли эту методологию с точки зрения методологии угроз? Ведь обычно угрозы моделируются в рамках каскадного проектирования ("Waterfall") - анализ требований, проектирование, реализация... Как моделировать угрозы при длительности спринта (в терминологии SCRUM) в 1-4 недели?  
• Размытость границ. И это тоже не новость, но и она нечастно находит свое отражение при моделировании угроз. Хотя очерчивание границ для объекта защиты - это основа моделирования угроз. Но сегодня у нас активно внедряются технологии виртуализации, Zero Trust, облачные вычисления. Учитываются ли они при определении негативных сценариев развития событий? А если да, то как?
• Искусственный интеллект. 2018-й и 2019-й годы ознаменовались публикацией большого числа исследований про применение машинного обучения для обмана различных защитных технологий - от биометрии до антивирусов, от антифишинговых решений до систем обнаружения атак. И вновь вопрос, который я уже не раз задавал выше. Как учитывает модель угроз такие исследования? Насколько наши технологии безопасности способны выявлять атаки, созданные искусственным интеллектом?
• API. Мир становится все более открытым - продукты интегрируются между собой и разрешают доступ к своим ресурсам извне. Все это делается через API, которые часто становятся самым слабым звеном "защищенной" системы, в которой предусмотрено все, кроме контроля вызовов API.

Вот такой небольшой список того, что сегодня влияет на моделирование угроз и недооценка чего приводит к успешным проникновениями в корпоративные и ведомственные сети. Вот про это мы и будем говорить на сочинском "Коде ИБ. Профи" через 10 дней. И будем пробовать на практике учесть все эти нюансы, создавая модели угроз для одной из нескольких систем, которые будут предложены на выбор участникам. 

ЗЫ. А чтобы у заметки была картинка, вставлю вот этот список акторов, реализующих угрозы, и атрибутов, с ними связанных.

Подробнее…

Новости ФСТЭК по моделированию угроз

Доклад Елены Борисовны Торбенко из 2-го управления ФСТЭК стал для меня неожиданностью по нескольким причинам. Во-первых, нечасто от регулятора в области ИБ выступает представительница прекрасной половины человечества :-) Во-вторых, ФСТЭК поделилась своим опытом по анализу присланных им в 2014-м году моделей угроз и выделила типовые ошибки, которые посоветовала не повторять. Такое бывает не часто - регуляторы обычно говорят, что надо делать, но редко говорят как. В-третьих, ФСТЭК признала, что далеко не все модели согласовываются - больше половины отправляются обратно на доработку. В итоге у меня сложилось впечатление, что процедура это явно непростая. 

В 2014-м году было рассмотрено свыше 60 моделей угроз - преимущественно от госорганов. Модели от коммерческих организаций ФСТЭК не рассматривает, исключая госкорпорации.

Отдельно было отмечено, что согласование моделей угроз - процедура необязательная; в отличие от согласования актуальных угроз безопасности ПДн, как это предусмотрено в части 5 статьи 19 ФЗ-152. На эту тему была большая дискуссия, касающаяся терминологии. В законе нет ни слова про моделирование угроз - говорится только о перечне актуальных угроз, которые госорганы должны согласовать с регуляторами (ФСТЭК и ФСБ). Поэтому госорганы часто направляют в ФСТЭК просто перечень угроз на 1-2 страничках и ФСТЭК обязан их согласовать. А вот обязанность заниматься моделирование угроз установлена в 17-м приказе ФСТЭК - она действует только для госорганов. Модель угроз для операторов ПДн является рекомендательной и согласовывать ее не надо. А вот для операторов АСУ ТП методика моделирования еще будет писаться - единая методика для этой задачи не подошла. Если резюмировать, то перечень актуальных угроз ПДн (не типов) может составлять только госорган и... (как написано в ч.5 ст.19 ФЗ-152), а вот модель угроз (почувствуйте разницу) может составлять кто угодно - это не запрещено.

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

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

• структуру ИС
• состав ИС
• взаимосвязи между сегментами ИС
• взаимосвязи с другими ИС и ИТКС
• условия функционирования ИС.

ФСТЭК специально уточняет, что не надо отправлять подробный и многостраничный отчет о проведенном аудите или обследовании ИС - нужно только резюме из него. В противном случае время на рассмотрение модели только увеличится.

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

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

Третья ошибка заключается в неверном определении объектов защиты.

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

• Не проводится анализ возможных источников угроз (нарушитель, вредоносная программа, аппаратная закладка и т.д.). Обратите внимание! В новой методике моделирования немало внимания будет уделено оценке потенциала нарушителя (из ГОСТ Р ИСО/МЭК 18045).
• Не анализируются последствия от действий нарушителя. Многие по привычке оценивают только угрозы нарушения конфиденциальности, забывая про нарушение целостности и доступности.
• Не учитываются уязвимости, присутствующие в системе. Вообще ФСТЭК стал очень много внимания уделять именно уязвимостям и безопасности ПО. Так что стоит на этот момент обратить внимание.
• Неверное определение способов реализации угроз.

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

Последние три ошибки связаны с:

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

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

Было интересное высказывание Виталия Сергеевича Лютикова, что они планируют разработать ряд типовых моделей угроз для распространенных систем и технологий. Но сроки не определены и боюсь, что учитывая другие планы по более приоритетным документам, до типовых моделей руки не скоро дойдут. Вот только если кто-то из экспертов предложит свои наработки...

ЗЫ. Зато хочу отметить, что почти все эти ошибки я рассматриваю в курсе по моделированию угроз :-)

Подробнее…

Как я моделировал угрозы по проекту новой методики ФСТЭК. Часть 1

Многие коллеги уже высказались по поводу проекта новой методики ФСТЭК по моделированию угроз (тут, тут, тут, тут и тут) и мне бы не хотелось повторять за ними. Я поступил проще - я взял в качестве примера систему удаленного доступа, которую многие реализуют сейчас для своих работников, и попробовал реализовать пошаговую процедуру, предусмотренную проектом методики. Раздел 1 практической ценности не несет - он просто определяет некоторые общие вещи и вводит ограничения на моделирование угроз. Комментировать историю с БДУ сейчас, наверное, нет смысла. ФСТЭК обещала серьезно переработать эту базу и привести ее в соответствие с новой методикой.

Раздел 2 является обзорным, описывающим, как нам надо выстраивать процесс моделированияЕ не погружаясь в детали. Пункт 2.1 говорит нам, что мы можем закрыть глаза на ошибки пользователей, так как они врядли относятся к неправомерным действиям. С другой стороны у нас неоправданно расширен список возможных угроз, с которыми нам придется бороться, так как в качестве угроз мы рассматриваем не только действия и(или) воздействия, в результате которых возможно нарушение безопасности информации и(или) нарушение или прекращение функционирования систем и сетей, повлекшее наступление негативных событий, но и все остальные неправомерные действия и(или) воздействия, в результате которых возможно нарушение безопасности информации; уже независимо от наступления негативных событий. Возможно, в предпоследней строке п.2.1 вместо слова "повлекшЕе" должно было стоять "повлекшИе", но пока это слово относится только к последней части абзаца, то есть к нарушению или прекращению функционирования систем и сетей. Также, этим пунктом мы исключаем из рассмотрения все угрозы, связанные с бездействием. Например, появилась уязвимость в VPN-клиенте или шлюзе удаленного доступа и логично было бы ее устранить, но мой администратор решил забить на это и ничего не делать. Позже через эту уязвимость в сеть залезли хакеры, но администратор разводит руками, так как в модели угроз его бездействие не было учтено.

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

На пункте 2.3 я впал в ступор, так как мне казалось, что прежде чем определять негативные последствия, надо все-таки определиться с объектом защиты, с его границами, условиями функционирования, взаимосвязями и решаемыми задачами. Тогда у меня сразу сузится область моделирования и моя деятельность будет более эффективной. И косвенно моя правота подтверждается и самой методикой. По крайней мере входными данными для 1-го этапа моделирования на рисунке 1 указаны как раз сведения об архитектуре систем и сетей (на мой взгляд было бы проще написать просто "объект защиты") и особенностях их функционирования. Многие пункты 2-го раздела говорят именно об описании границ анализируемой системы, но почему этот этап не выделен отдельно.

Пункт 2.4 как раз нам и говорит о том, что надо определиться с границами объектам защиты (почему-то названными границами процесса моделирования) и его взаимосвязями, в том числе и с обеспечивающими системами. Например, если злоумышленники выведут из строя подстанцию, которая дает электричество на мой офис, то им не надо будет атаковать ни моих удаленных пользователей, ни кластер удаленного доступа. Они решат свою задачу окольным путем (если им надо было нарушить доступность всей системы). Тоже самое касается и провайдеров VPN-доступа, которые не относятся к моему объекту защиты, но при этом этот объект от них сильно зависит и мы должны включить его в зону нашего внимания. Правда, регулятор, возможно, чтобы не усложнять методику, исключил обслуживающие системы из процесса моделирования, оставив только те, которые принадлежат обладателю информации или оператору ИС или сети, ее обрабатывающей, то есть лицу, с которым у меня заключен соответствующий договор. Рисунок 2, про границы моделирования для ИС, использующих ресурсы внешнего ЦОДа, это подтверждает. Не знаю, насколько это правильно; я бы все-таки старался учитывать еще и системы обеспечения. Пока я не дошел до следующих пунктов, задамся вопросом, а надо ли мне при моделировании учитывать возможные неправомерные действия, осуществляемые при ремонте компонентов моей системы? А при их поставке и разработке?

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

Моделировать угрозы, согласно п.2.8, может либо обладатель информации или оператор, ее обрабатывающий, либо лицензиат ФСТЭК. Почему моделирование угроз вдруг стало лицензируемым видом деятельности я не знаю; наверное, просто по привычке. Также не совсем понятно, почему я не могу воспользоваться моделью угроз от разработчика системы, который гораздо лучше знает свое детище, чем другие лица? Тем более, что дальше в разделе именно на провайдеров используемых нами систем возлагается обязанность предоставить нам эту модель угроз.

Внезапно, пункт 2.9, который должен быть в 1-м разделе, говорит нам о том, что для экспертной оценки я могу создавать группы экспертов согласно приложению 2, которое нам подсказывает, что эксперты должны быть независимыми, не иметь финансовых интересов (у лицензиатов ФСТЭК их, конечно же, нет), быть квалифицированными и т.п. А чтобы их оценка была более взвешенной, методика ФСТЭК рекомендует использовать больше столетия используемый в разных отраслях метод Дельфи. Хорошо, что Приложение 2 рекомендуемое, а не обязательное, а то согласно нему формирование экспертной группы превратится в задачу посложнее самого моделирования угроз. Но рекомендацию использовать метод Дельфи я могу только приветствовать.

П.2.11 рекомендует для "внешних" систем использовать модели угроз, разработанные владельцем этих внешних систем (ЦОДов, облаков, сервисов телеконференций, файловых хранилищ, CRM-систем и т.п.). Тут у меня два комментария. Во-первых, таких владельцев, которые бы готовы были делиться своими моделями угроз, почти нет. На их сайтах вы этой информации точно не найдете, а при общении с ними, они, даже если и имеют разработанные модели угроз, будут ссылаться на конфиденциальность этой информации и невозможность поделиться ею. ФСТЭК в этом случае не рекомендует пользоваться услугами таких компаний. С точки зрения специалиста по ИБ я может и разделяю подход регулятора, но с точки зрения бизнеса прекрасно понимаю, что ему наплевать на наличие/отсутствие моделей угроз у контрагентов. Он оценивает свои риски совсем иначе. И если уж мы говорим о риск-ориентированном моделировании угроз (раз уж мы привязываемся к негативным последствиям), то и стоять на этом надо до конца (хотя стоять на своем бывает больно). И задача службы ИБ как раз и состоит в том, чтобы оценить эти риски и дать бизнесу рекомендации по их снижению. Поэтому если у выбранного поставщика услуг нет модели угроз, ее надо разработать самим и исходя из нее сформировать защитные мероприятия.

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

А рисунок 3, кстати, запутывает процесс моделирования. Распределение зон ответственности лучше было отражать на рисунке 2. Это же относится и к рисункам 4 и 5. Понятно, что хотел сказать регулятор, но отобразить это стоило бы, как мне кажется, в виде вертикальных блоков/зон, как это часто показывают в презентациях и статьях по защите облаков, рассказывая про разделяемую ответственность. Я вот нашел такую в какой-то из своих презентаций 10-тилетней давности. На ней, кстати, показан и такой непростой вопрос при моделировании угроз, как API, который в методике назван интерфейсами взаимодействия с иным программным обеспечением.

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

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

Таблица 4 6-го раздела содержит 10 тактик и 77 техник. И если мне надо определить максимально возможное число таких совокупностей, то взяв на вооружение комбинаторику и предположив, что для реализации угрозы нарушитель будет использовать все 10 тактик (то есть шагов kill chain), я получу... до хрена вариантов. Очень условно, я бы назвал, что таких комбинаций будет чуть больше 1 триллиона (число сочетаний из 77 техник по 10 штук в каждом). Даже если "выровнять" число техник до 5 для каждой из 10 тактик, число возможных сочетаний у меня будет больше 10 миллиардов. Для матрицы MITRE ATT&CK (я о ней писал неоднократно), которую использовать тоже можно, у меня число возможных сочетаний будет измеряться квадриллионами. Да, я понимаю, что в реальности не все такие сочетания будут возможны, но формулировка "максимально возможное число сценариев" заставляет перебирать их все и отбрасывать неприменимые. А в условиях отсутствия средств автоматизации такой работы, на ней все и умрут...

На этой позитивной ноте я завершил изучение 2-го раздела проекта методики моделирования угроз. Завершу и эту заметку, продолжение которой будет завтра.

Подробнее…

Не методикой ФСТЭК единой или модели угроз, утвержденные государством российским

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

Итак, на первое место я поставлю базовую модель угроз безопасности персональных данных при их обработке в ИСПДн (она же в Консультанте), выпущенную ФСТЭК в 2008-м году. Несмотря на выпущенную в 2021-м году методику оценки угроз, которая отменила методику оценки угроз безопасности ПДн 2008-го года, базовую модель при этом никто не отменял, что заставляет задавать вопросы, какой статус этой базовой модели, празднующей свое 13-тилетие. 

На второе место можно смело ставить модель угроз безопасности ПДн, выпущенную в 2015-м году Банком России и утвержденную в виде Указания Банка России от 10.12.2015 №3889-У "Об определении угроз безопасности персональных данных, актуальных при обработке персональных данных в информационных системах персональных данных".

Спустя 3 года после предыдущего нормативного акта банковский регулятор выпустил новый документ - Указание Банка России от 9 июля 2018 года №4859-У "О перечне угроз безопасности, актуальных при обработке, включая сбор и хранение, биометрических персональных данных, их проверке и передаче информации о степени их соответствия предоставленным биометрическим персональным данным гражданина Российской Федерации в государственных органах, банках и иных организациях, указанных в абзаце первом части 1 статьи 14.1 Федерального закона от 27 июля 2006 года N 149-ФЗ "Об информации, информационных технологиях и о защите информации", в единой биометрической системе". Однако, ввиду серьезной переработки законодательства о ЕБС и навязывании ее везде и всем, Банк России решил отменить данное Указание, предложив вместо него два новых проекта, которые должны быть приняты в этом году:

• Проект Указания Банка России "О перечне угроз безопасности, актуальных при обработке биометрических персональных данных, их проверке и передаче информации о степени их соответствия предоставленным биометрическим персональным данным физического лица, при взаимодействии организаций финансового рынка с единой биометрической системой с учетом оценки возможного вреда, проведенной в соответствии с законодательством Российской Федерации о персональных данных"
• Проект Указания Банка России "О перечне угроз безопасности, актуальных при обработке биометрических персональных данных, их проверке и передаче информации о степени их соответствия предоставленным биометрическим персональным данным физического лица в информационных системах организаций финансового рынка, осуществляющих идентификацию и (или) аутентификацию с использованием биометрических персональных данных физических лиц, за исключением единой биометрической системы, а также актуальных при взаимодействии организаций финансового рынка, иных организаций, индивидуальных предпринимателей с указанными информационными системами, с учетом оценки возможного вреда, проведенной в соответствии с законодательством Российской Федерации о персональных данных"

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

• Приказ Минцифры от 26.11.2020 № 624 «Об утверждении перечня угроз безопасности, актуальных при идентификации заявителя – физического лица в аккредитованном удостоверяющем центре, выдаче квалифицированного сертификата без его личного присутствия с применением информационных технологий путем предоставления сведений из единой системы идентификации и аутентификации и единой информационной системы персональных данных, обеспечивающей обработку, сбор и хранение биометрических персональных данных, их проверку и передачу информации о степени их соответствия предоставленным биометрическим персональным данным гражданина Российской Федерации, а также хранении и использовании ключа электронной подписи в аккредитованном удостоверяющем центре».
• Приказ Минцифры от 21.12.2020 № 734 "Об определении угроз безопасности персональных данных, актуальных при обработке персональных данных в информационных системах персональных данных, эксплуатируемых в сферах деятельности, нормативно-правовое регулирование которых осуществляется Министерством цифрового развития, связи и массовых коммуникаций Российской Федерации".

Кроме того, Мицифры подготовило еще один проект приказа,  который также касается угроз биометрическим ПДн, - "Об утверждении перечня угроз безопасности, актуальных при обработке биометрических персональных данных, их проверке и передаче информации о степени их соответствия предоставленным биометрическим персональным данным физического лица в информационных системах организаций, осуществляющих идентификацию и (или) аутентификацию с использованием биометрических персональных данных физических лиц, за исключением единой биометрической системы, а также актуальных при взаимодействии государственных органов, органов местного самоуправления, индивидуальных предпринимателей, нотариусов и организаций, за исключением организаций финансового рынка, с указанными информационными системами, с учетом оценки возможного вреда, проведенной в соответствии с законодательством Российской Федерации о персональных данных, и учетом вида аккредитации организации из числа организаций, указанных в частях 18.28 и 18.31 статьи 14.1 Федерального закона от 27 июля 2006 года N 149-ФЗ "Об информации, информационных технологиях и о защите информации".

Минцифры вернулось в стройные, но плохо согласующие свои действия, ряды регуляторов по ИБ относительно недавно. Лет 10 от них ничего в этой области не было слышно, хотя раньше они были вполне активны и выпускали/согласовывали разные документы по защите информации. Одним из таких документов была "Модель угроз и нарушителя безопасности ПДн, обрабатываемых в ИСПДн отрасли [связи]", согласованная с ФСТЭК и ФСБ России. Текущий статус этого документа ввиду выхода новой методики ФСТЭК не совсем ясен (хотя с сайта министерства она не убрана) и возможно новый руководитель департамента кибербезопасности Минцифры наведет порядок в том, что делали его предшественники, коих сменилось на этом посту не мало.    

При этом не забывайте, что помимо указанных нормативных актов, выпущенных регуляторами и действующими на территории всей страны, существует немало перечней угроз ПДн, которые утверждались или каким-либо субъектом РФ, или каким-то министерством для себя и своих поднадзорных структур. Например, приказ Департамента здравоохранения Курганской области от 30 мая 2018 года №632 "Об утверждении Перечня угроз безопасности персональных данных, актуальных при обработке персональных данных в информационных системах персональных данных в Департаменте здравоохранения Курганской области и подведомственных ему учреждениях, организациях", приказ Минэнерго от 02.08.2019 №819 "Об определении угроз безопасности персональных данных, актуальных при обработке персональных данных в информационных системах персональных данных, эксплуатируемых при осуществлении Минэнерго России функций, определенных законодательством Российской Федерации" или Постановление Правительства Пензенской области от 20.04.2017 №192-пП "Об определении угроз безопасности персональных данных, актуальных при обработке персональных данных в информационных системах персональных данных Пензенской области" (почти в каждом субъекте РФ есть такое постановление).

Немного особняком стоит тема моделирования угроз, а точнее атак, на средства криптографической защиты информации. И если раньше ею можно было и не заниматься, так как обычно все эти вопросы ложились на производителей СКЗИ, которые и должны были решить эту задачу, то сейчас ситуация меняется. ФСБ подготовило проект приказа "Об утверждении Требований о защите информации, содержащейся в государственных информационных системах, с использованием средств криптографической защиты информации", а последние правки в Постановление Правительства от 6 июля 2015 №676 "О требованиях к порядку создания, развития, ввода в эксплуатацию, эксплуатации и вывода из эксплуатации государственных информационных систем и дальнейшего хранения содержащейся в их базах данных информации". Оба документа подразумевают согласование модели угроз с ФСБ, что заставляет нас задумываться о том, есть ли утвержденные этим, уже 4-м в сегодняшней заметке регулятором, перечни угроз безопасности? На самом деле их нет. Но есть документы, на которые стоит ориентироваться при составлении модели угроз (атак) на СКЗИ:

• Приказ ФСБ от 10.07.2014 №378 "Об утверждении Состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных с использованием средств криптографической защиты информации, необходимых для выполнения установленных Правительством Российской Федерации требований к защите персональных данных для каждого из уровней защищенности".
• Методические рекомендации ФСБ по разработке нормативных правовых актов, определяющих угрозы безопасности персональных данных, актуальные при обработке персональных данных в информационных системах персональных данных, эксплуатируемых при осуществлении соответствующих видов деятельности.

Но не персональными данными едиными. Существуют перечни угроз и для других объектов защиты, например, для Интернета, а точнее для функционирования Интернета на территории России. Российские власти выделяют для него три типа негативных событий - угрозы устойчивости, безопасности и целостности функционирования Рунета. Они описаны в Постановлении Правительства  от 12.02.2020 № 127 "Об утверждении Правил централизованного управления сетью связи общего пользования".

Еще одним "особняком" я бы назвал тему моделирования угроз при разработке безопасного программного обеспечения, которая стала новым "фетишем" (в хорошем смысле) и для ФСТЭК и для Банка России. Существующая методика оценки угроз ФСТЭК не очень подходит для моделирования угроз для разрабатываемого ПО, как того требует утвержденный ГОСТ Р 56939-2016 "Защита информации. Разработка безопасного программного обеспения. Общие положения". Но зато в качестве перечня угроз можно ориентироваться на ГОСТ Р 58412-2019 "Защита информации. Разработка безопасного программного обеспения. Угрозы безопасности информации при разработке программного обеспечения". Не STRIDE, конечно, но тоже ничего.

Есть и совсем специфические перечни угроз, которые применимы для объектов защиты, работающих в очень узких сферах деятельности. Например, приказ Минэнерго от 6 ноября 2018 года №1015 «Об утверждении требований в отношении базовых (обязательных) функций и информационной безопасности объектов электроэнергетики при создании и последующей эксплуатации на территории Российской Федерации систем удаленного мониторинга и диагностики энергетического оборудования» определяет базовые атаки и базовые уязвимости для построения модели угроз СУМиД, а также перечень из 59 угроз безопасности.

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

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

Подробнее…

Можно ли исключать защитные меры при неактуальности угроз?

Моя пятничная заметка вызвала оживленную дискуссию в Twitter и Facebook на тему, можно ли отказываться от какой-либо защитной меры согласно приказу 17/21/31 при неактуальности угроз. Сергей Борисов даже пост на эту тему написал. Он считает, что в 21-м приказе отсутствует возможность исключения защитных мер только на основании неактуальности угроз, для которых эта мера предназначена. По причине отсутствия какой-либо информационной технологии можно, из-за определенных структурно-функциональных характеристик тоже можно, а вот по причине неактуальности угроз нельзя. Я с такой позицией несогласен и вот почему.

В 17-м приказе, в п.14.3 есть такой фрагмент "При определении угроз безопасности информации учитываются структурно-функциональные характеристики информационной системы... применяемые информационные технологии...". Далее, в п.14.4 говорится, что "Требования к системе защиты информации информационной системы определяются в зависимости от класса защищенности информационной системы и угроз безопасности информации". В 20-м пункте говорится, что "Организационные и технические меры защиты информации, реализуемые в информационной системе в рамках ее системы защиты информации, в зависимости от угроз безопасности информации, используемых информационных технологий и структурно-функциональных характеристик информационной системы должны обеспечивать...". Иными словами, ФСТЭК неоднократно указывает, что система защиты и ее наполнение мерами зависит от угроз и никак иначе.

31-й приказ построен на аналогичных вводных. В 8-м пункте говорится о том, что защита информации в АСУ ТП достигается путем принятия в рамках системы защиты АСУ "совокупности организационных и технических мер защиты информации, направленных на блокирование (нейтрализацию) угроз безопасности информации, реализация которых может привести к нарушению штатного режима функционирования...". В п.13.3 также говорится, что угрозы зависят от структурно-функциональных характеристик АСУ ТП. Пункт 13.4 гласит - "Требования к системе защиты... определяются в зависимости от класса защищенности... и угроз безопасности, включенных в модель угроз безопасности информации". Ну а 18-й пункт 31-го приказа почти дословно повторяет упомянутый выше 20-й пункт 17-го приказа.

Иными словами, ФСТЭК в двух своих приказах четко дает понять, что система защиты зависит от угроз и с неактуальными угрозами (которые не приводят к нарушению функционирования или ущербу) бороться не надо; в модель угроз неактуальные угрозы включать не надо.

Почему таких фраз нет в 21-м приказе? На самом деле все просто. Во-первых, в 21-м приказе это сказано, но другими словами. В частности, в п.3 говорится, что "меры по обеспечению безопасности персональных данных... должны быть направлены на нейтрализацию актуальных угроз безопасности персональных данных". 4-й пункт тоже упоминает только актуальные угрозы. И 8-й пункт тоже. 2-й пункт Постановления Правительств №1119 тоже, как ни странно, упоминает только актуальные угрозы, которые и должна нейтрализовывать система защиты.

А во-вторых, в 21-м приказе просто нет тех разделов по жизненному циклу системы защиты персональных данных, которые есть в 17-м и 31-м приказах. Нет их не из-за забывчивости, все-таки документы писали одни и те же люди. Причина проста - ФСТЭК, являясь уполномоченным органом по защите ГИС и АСУ ТП, для них установила требования по тому, как строить систему защиты; из каких этапов этот процесс должен состоять. А вот коммерческим операторам ПДн, на которых и распространяется 21-й приказ, ФСТЭК, не имея полномочий для их проверки, решила дать свободу в выборе того, как строить систему защиты. Поэтому, соблюдая общую идеологию, общий алгоритм выбора защитных мер, единый перечень защитных мер, в 21-м приказе не говорится (и теперь понятно, что может быть и зря), как это все объединить вместе.

Отсутствие этих разделов дает основание некоторым экспертами считать, что неактуальность угрозы не дает права на исключение соответствующей защитной меры. Собственно, мы опять возвращаемся к тому, о чем я уже как-то писал, - свобода выбора - это для многих зло. Слишком много степеней свободы появляется - у владельца защищаемой системы своя, у интегратора своя, у аттестационной лаборатории своя, у проверяющих от регуляторов своя. И даже если последние допускают (а это именно так) широкое толкование 17/21/31-го приказов, то вот остальные участники этого процесса пока не перестроились и постоянно рассчитывают на "а вдруг". А вдруг нельзя? А вдруг не согласуют? А вдруг накажут? А вдруг неправильно?...

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

Подробнее…

Стандарт по ИБ виртуализации

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

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

Приглашаем профессиональные ассоциации и экспертов поддержать эту инициативу!

Предварительная структура данного стандарта:

1. Введение
2. Термины и определения
3. Виртуализация.
• Типы виртуализации
• Серверная виртуализация
• гипервизорная
• контейнерная
•  Виртуализация рабочих станций
• гипервизорная
• контейнерная
• Виртуализация приложений
• Виртуализация сервисов
• Виртуализация сети
• Виртуализация СХД
• Виртуализация аппаратного обеспечения
•  Жизненный цикл системы защиты виртуализированных инфраструктур
• Общие рекомендации по защите виртуализированных инфраструктур
4. Серверная виртуализация
• Модель угроз
• Рекомендации по защите
5. Виртуализация рабочих станций
• Модель угроз
• Рекомендации по защите
6. Виртуализация приложений
• Модель угроз
• Рекомендации по защите
7. Виртуализация сервисов
• Модель угроз
• Рекомендации по защите
8. Виртуализация сети
• Модель угроз
• Рекомендации по защите
9. Виртуализация СХД
• Модель угроз
• Рекомендации по защите
10. Виртуализация аппаратного обеспечения
• Модель угроз
• Рекомендации по защите
11. Внедрение и эксплуатация системы защиты виртуализированных инфраструктур
12. Оценка соответствия
13. Заключение

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

Разработка проекта стандарта по безопасности виртуализированных инфраструктур будет проводиться под эгидой Ассоциации профессионалов в области информационной безопасности RISSPA.

Авторами документа будут указаны все эксперты, принявшие участие в его разработке.

Присоединиться к инициативной группе можно написав по адресу - virtual[at]risspa[dot]ru

Алексей Лукацкий
Мария Сидорова

Подробнее…

Автоматизация работы по персданным

Довелось мне тут поглубже ознакомиться с продукцией екатеринбургской компании НТЦ "Сфера" - системой WingDoc ПД. Продукт зачетный, надо сказать прямо. Конечно, у него есть свои недочеты, как с точки зрения удобства пользования, так и с точки зрения некоторых вопросов безопасности. Но если перед организацией встала задача выполнить требования ФСТЭК и ФСБ в части разработки модели угроз (а именно это один из камней преткновения сейчас), то WingDoc ПД отлично справится с этой задачей.

Разумеется, если вы готовы потом выполнять ее (читай ФСТЭКовские/ФСБшные) рекомендации, т.к. в систему заложены именно методики построения модели угроз от наших регуляторов. Ну а так как большинство отечественных интеграторов тоже не сильно отклоняются от рекомендаций ФСТЭК и ФСБ, то система автоматизации тут как нельзя кстати. Особенно если учесть, что стоит она всего каких-то 12 тысяч рублей. Супротив ценника в несколько сотен тысяч (хотя я слышал про предложение одного интегратора - 17 миллионов рублей), который выставляют отечественные компании, специализирующиеся на данной тематике. Не удивлюсь, если появятся конторы, которые начнут демпинговать и предлагать разработку модели угроз на основе WingDoc ПД за смешные деньги ;-)

Но вернемся к программе. Более подробно она описана на сайте разработчиков. Что мне понравилось:

• Модуль ИСПДн-К позволяет построить модель угроз по методике ФСБ. А это уже немало. Исходя из существующих публичных документов самостоятельно построить модель нереально. Тут же автоматически строится и модель нарушителя и модель угроз. Правда, задача нетривиальная оказалась ;-( Придется вначале заняться инвентаризацией всех своих ресурсов, а уж потом браться за моделирование.
  
• Модуль ИСПДн автоматизирует процесс создания модели угроз по методике ФСТЭК. При этом по умолчанию модуль содержит список угроз из "Базовой модели", но как я понял, этот список может быть расширен. Вот если бы разработчики добавили в систему каталог угроз BSI и классификации из наших ГОСТов, то программе бы цены вообще не было. Итоговый документ у меня получился около 45 страниц с кучей разных таблиц.
  
• Система построена на анкетировании пользователя (около 100 вопросов). С одной стороны это позволяет автоматизировать процесс определения актуальных угроз, а с другой заставляет пользователя сначала собрать немало информации о своей системе. Но зато она потом вся хранится в базе.
• Хоть это и не так просто, но система программируема. Можно в анкету добавлять свои вопросы и связывать их с угрозами, список которых тоже можно пополнять. Единственное, что врядли можно поменять сам алгоритм определения актуальности угрозы. Если бы можно было поменять и его, то из WingDoc можно было сделать систему моделирования угроз не только для ПДн, но и других приложений и систем.
• Модуль "Техническое задание" позволяет на основе модели угроз составить ТЗ на разработку системы защиты ИСПДн.
• Система позволяет сформировать целый набор документов - Акт классификации, модель угроз, 8 разных приказов, требуемых при проверках, а также ТЗ на разработку системы защиты ИСПДн.

В заключение хочу еще раз порадоваться за специалистов НТЦ "Сфера", которые выпустили нужный продукт в нужное время. Сегодня это редкость ;-)

Подробнее…

Анализ модели угроз ПДн Банка России

Банк России опубликовал долгожданный проект отраслевой модели угроз безопасности персональным данных. За прошедший с небольшим месяц это уже третий документ в области моделирования угроз ПДн. Сначала появился проект методики моделирования угроз ФСТЭК, затем методика ФСБ и вот уже готовая модель от Банка России.

История этого документа достаточно стара. Его впервые подготовили в 2013-м году, но его согласование застряло в ФСБ России. Потом Крым присоединился к России и ЦБ было уже не до принятия модели угроз - были более важные дела и документы (по этой же причине и FinCERT появился на год позже запланированного). Затем начались геополитические игрища и ЦБ решил пересмотреть свой подход к моделированию угроз ПДн. Если раньше в модели был прописан тезис о неактуальности угроз 1-го и 2-го типа (т.е. недокументированные возможности в системном и прикладном ПО), а в текущей редакции СТО БР ИББС 1.0 эта мысль звучит до сих пор, то в нынешней модели угроз от этого подхода отказались, отдав его на откуп каждому банку, который сам и должен принять решение - опасаться ли закладок в операционных системах, СУБД, банковских приложениях или нет.

В модели зафиксировано всего 10 актуальных угроз ПДн:

1. НСД лицами, обладающими полномочиями
2. НСД лицами, необладающими полномочиями, но использующими уязвимости
• в организации системы защиты
• в ПО ИСПДн
• в обеспечении защиты сетевого взаимодействия и каналов передачи данных
• в обеспечении защиты вычислительных сетей ИСПДн
• вызванных несоблюдением требований по эксплуатации СКЗИ
3. Воздействие внешнего по отношению к ИСПДн вредоносного кода
4. Социальный инжиниринг
5. НСД к отчуждаемым носителям
6. Утрата носителей ПДн, включая переносные компьютеры.

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

Отличия между проектами моделей угроз ПДн 2013-го и 2015-го годов

Наконец, в прошлом варианте говорилось даже не о перечне актуальных угроз, а скорее о комбинации 4-х элементов - источнике угрозы, категории нарушителя, способе реализации угрозы и оценке актуальности. То, что в текущем проекте называется угрозой, в прежней версии называлось способом реализации угроз. И тогда их было 21, а не 10, как сейчас. Поэтому на выходе комбинированный из 4-х элементов перечень содержал еще больше пунктов - 47.

Фрагмент проекта модели угроз ПДн 2013-го года

Если уж я начал сравнивать, то нельзя не упомянуть и модель угроз из уже отмененной РС 2.4. В ней структура также отличалась и от модели 2013-го года, и от модели 2015-го года. По сути угроз в этой модели было всего 3 - угрозы нарушения классической триады - конфиденциальности, целостности и доступности. Но скомбинированные с типом объекта среды, в которой угрозы реализовывалась, уровнем ИСПДн и источником угрозы, на выходе модель содержала уже 88 пунктов.

Фрагмент модели угроз ПДн из РС 2.4

В целом можно отметить, что текущая модель стала гораздо проще и понятнее. Перечень из 10 угроз, с которыми и надо бороться, опираясь на 382-П, если речь идет ПДн в рамках денежных переводов, и на 21-й приказ ФСТЭК и 378-й приказ ФСБ, если речь идет обо всех остальных случаях. При этом не требуется создавать своих моделей угроз по методикам ФСТЭК или ФСБ - по сути, Банк России это уже сделал за банки. Пожалуй, можно только расширить этот перечень актуальных угроз чем-то своим, что не попало в Указание ЦБ.

Документ согласован с ФСБ и ФСТЭК и, с вероятностью близкой к 100%, изменяться уже не будет. Так что на него можно ориентироваться уже сейчас, не дожидаясь его официального принятия и опубликования в "Вестнике Банка России".

Подробнее…

2 государевых модели угроз, авторы которых забили болт на требования ФСТЭК

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

• Где модель нарушителя? Предположу, что это в неопубликованной части, но что-то по тексту это не прослеживается. Либо модели нарушителя не было вообще, либо на сайте выборов опубликовали не просто выписку, а отдельно написанный документ для публичного ознакомления. Походя указано, что администраторы могут иметь деструктивные наклонности и негативно повлиять на инфраструктуру ДЭГ и поэтому для борьбы с этим предлагается использовать... СКЗИ (как связаны СКЗИ и возможность противодействия деструктивным действия администраторов, я не знаю).
• Меня немного удивило заявление, что в ДЭГ не обрабатываются специальная категория персональных данных о политических взглядах. При выборах в Госдуму и при волеизъявлении в пользу той или иной политической партии ДЭГ не обрабатывает данных о политических взглядах? Смелое заявление, отображающее стремление занизить уровень защищенности ИСПДн. Но рассчитано явно на людей, плохо соображающих или тех, с кем есть договоренность. С другой стороны, РКН модель не согласовывает, а ФСТЭКу в целом все равно, какой там уровень защищенности ИСПДн, если класс защищенности ГИС 1-й. 
• Также, видимо, в целях снижения уровня защищенности ИСПДн в ДЭГ признаны неактуальными недокументированные возможности (читай, закладки) на уровне ОС и приложений. Я склонен был бы согласиться с таким выводом, если бы речь шла о ИСПДн какой-либо noname-компании, но система для государственных выборов?.. Но тогда возникает вопрос, зачем там СКЗИ класса КА, которое как раз от таких угроз среди прочего и защищает? 
• Кстати, о криптографии. А где угрозы по этой части? В выписке написано, что модель разрабатывалась в соответствие с 676-м Постановлением Правительства, но в нем есть требование согласования модели не только с ФСТЭК, но и (а не или) с ФСБ, которой все равно, что написано в БДУ, но которая требует, чтобы были указаны угрозы именно по части СКЗИ. Но их в опубликованной выписке нет. Видимо, в закрытой части.  
• А что есть в открытой, так это упоминание необходимости применения СКЗИ при общении с  избирателем и СКЗИ это должно быть класса КС1. Но как это сделать, если у избирателя нет браузера "Спутник" или он работает с мобильного устройства? По тексту допускается применение шифрования RSA (написано, что это даже согласовано), но вот зачем тогда упоминается КС1? Кстати, меня покоробило упоминание RSA в контексте шифрования данных. Обычно с помощью RSA шифруется только сеансовый ключ, а уж сам сеанс защищается симметричной криптографией, включенной в протокол TLS. Ну да оставим это на совести тех, кто писал часть по криптографии - она вообще очень куцая в выписке.
• В выписке перечислен чуть ли не весь банк данных угроз, признанных актуальными для ДЭГ, но я не нашел в модели, описывающей угрозы для системы на базе блокчейна, угроз для собственно самого блокчейна. Они признаны неактуальными? 
• В одной из своих презентаций, я рассказывал о том, как была взломана три года назад компания British Airways. Одной из высказанных версий назывался взлом не самого сайта авиакомпании, а кеширующих серверов CDN, которые не контролировались самой BA. Так вот в описании модели угроз ДЭГ также говорится об использовании CDN, но ни слова о том, что эти распределенные сервера входят в контур защиты ДЭГ и что для них рассматривались угрозы. Возможно технология взаимодействия с избирателями никак не завязана на CDN и угрозы ему признаны неактуальными, "а что, мля, если да", как пелось в известной песне Слепакова? 
• В приложении А в выписке отображена архитектура ДЭГ. Если она верна, то компоненты всей системы работают через VPN, а Интернет используется только на получение данных от избирателей. То есть, если верить опубликованной схеме, у членов избирательных комиссий нет прямого выхода в Интернет для того, чтобы посерфить в свободное от мониторинга голосования время. И это правильно. Но тогда зачем в списке актуальных угроз фишинг и фарминг? А откуда взялась угроза внедрения ВПО через рекламу (члены электронных избирательных комиссий рекламу смотрят)? А угрозы внедрения ВПО при посещении зараженных сайтов? Угроза хищения информации из cookies? Зачем рассматривать угрозы, которых по идее быть вообще не должно на рабочих местах людей, ответственных за голосование? 

Но основной вопрос, который у меня возник после прочтения этой выписки, связан не с упомянутыми выше темами. Вопрос в другом. В феврале этого года ФСТЭК утвердила методику оценки угроз, которая является обязательной для всех ГИС (а система дистанционного электронного голосования относится к ним). В этом нормативном документе описана и структура модели угроз, которая должна быть, и ряд обязательных элементов, среди которых сценарии реализации угроз. Но где они в выписке? Они судя по всему отсутствуют и в закрытой части. ПОЧЕМУ?

Почему владельцы государственной информационной системы забили болт на требования регулятора по ИБ? И если такое сделано публично, то почему остальные госорганы не должны сделать тоже самое? И почему субъекты КИИ, операторы ИСПДн и АСУ ТП не должны следовать той же логике?

Но возможно ФСТЭК не согласовала эту модель угроз или ей приказали сверху не чинить препятствие системе честных выборов, где россияне, все как один, должны в очередной раз поддержать партию власти. Но как тогда воспринимать модель угроз для интеллектуальных систем учета электроэнергии, письмо об утверждении которой в июне этого года была разослано от имени министре энергетики г-на Шульгинова? В письме написано, что эта модель разработана Минэнерго совместно с ФСБ, ФСТЭК и Минцифры. Но как? Как ФСТЭК могла согласовать эту модель, если она нарушает требования самой же ФСТЭК, выпущенных 5 месяцами раньше? Опять кто-то ровнее других? Опять одним можно, а другим нельзя?

Если честно такая политика ФСТЭК в отношении своих требований немного смущает и удивляет. То есть сначала выпускается документ, в отношении понятности которого (чтобы не говорили представители компании-лицензиата, участвовавшие в его разработке) с самого начала были вопросы его реализуемости. Потом оказывается, что один из ключевых элементов процесса моделирования (БДУ) не совместим с новой методикой, но при этом обязателен к использованию. Но ФСТЭК молчит и не публикует никаких информационных писем на этот счет, разъясняющих свою позицию. Зато представители ФСТЭК участвуют в мероприятиях коммерческих компаний и комментируют (как сотрудники регулятора или как частные лица?) свой же документ. А теперь еще и сам документ вроде как необязательно выполнять, коль скоро две государственных структуры публично это демонстрируют. Доверие к регулятору в такой ситуации явно не растет :-(

Подробнее…

Как я моделировал угрозы по проекту новой методики ФСТЭК. Часть 5

К настоящему моменту, пройдя 5 разделов проекта методики моделирования угроз, мы знаем кто нас будет атаковать и какими возможностями он обладает. Мы понимаем, зачем он это будет делать и к чему приведу его действия. Теперь неплохо бы разобраться, что эти нарушители будут делать, то есть определиться с угрозами, которые могут быть против нас реализованы. Но нет. 6-й раздел проекта методики моделирования угроз ФСТЭК посвящен определению сценариев реализации угроз, то есть пропустив ответ на вопрос "ЧТО может сделать нарушитель", мы сразу обратились к вопросу "КАК он может это сделать". Что ЭТО мы не знаем, зато сейчас мы погрузимся в КАК.

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

Явно это не говорится, но идея использования терминов "тактики" и "техники" взята из американской MITRE ATT&CK, которая содержит уже за 200 техник и больше десятка тактик. Почему нет упоминания американской матрицы понятно, но это еще сыграет злую шутку с нами. Местами в таблице 4 используются совершенно непонятные без разъяснения термины, которые являются достаточно грубой калькой с англоязычной матрицы. Например, техника 5.4 "Запасные и многоступенчатые каналы" в оригинале определены как две техники - T1104 "Multu-Stage Channel" и T1008 "Fallback Channels". И если, вдруг, какой-то госорган спросит регулятора, что означает техника 5.4 придется как-то выкручиваться. А самое неприятное, что и сопоставление TTP ФСТЭК и MITRE очень сложно реализовать, так как у нас постеснялись признать применение общепринятой методики и решили "пойти своим путем". Поэтому у нас свой набор техник, свой набор тактик, своя нумерация и невозможность сопоставить их один к одному. И хотя у методике написано, что помимо таблицы 4 можно использовать и иные базы, в реальности все будет известно как. Проверяющие, незнакомые с английским языком и ATT&CK, а также боящиеся самодеятельности, будут ориентироваться на то, что есть в таблице 4, тем самым доводя изначально хорошую идею до абсурда. Если уж регулятор не хочет признаваться в копировании чужого опыта (и понятно почему), может тогда поступить как Банк России, который в своих нормативных актах написал, что список инцидентов размещается на сайте ЦБ. Его и править тогда проще. Так и ФСТЭК могла бы поступить.

При этом ATT&CK - это не про моделирование угроз, это про понимание конкретных действий, совершаемых киберпреступниками. Если уж приземлять ATT&CK на моделирование угроз, то это низкоуровневое моделирование. Сначала мы должны определиться с высокоуровневой моделью угроз, описывающей классы нарушителей и реализуемых ими действий "по-крупному", влекущих негативные последствия. Только определившись с ними, можно переходить уже к тактикам и техникам, который помогут мне не только понять, КАК меня могут взломать, но и помогут проводить киберучения, выявлять слабые места в текущей системе защиты, осуществлять поиск (threat hunting) следов незамеченных на этапе проникновения атак и т.п. И процессы высокоуровневого и нижнеуровневого моделирования не являются независимыми друг от друга - второе вытекает из первого. Высокоуровневая модель, она про ЧТО плохого со мной может произойти, а вот низкоуровневая, с тактиками и техниками, про то, КАК это плохое со мной может произойти. Если мы посмотрим на вот эту картинку из моего курса по моделированию угроз, то мы увидим, что ФСТЭК в этот раз сразу ушла в левую часть, забыв про правую или хотя бы середину, с которой и стоило бы начать.

В проекте методики ФСТЭК, к сожалению, первая часть совершенно упущена из ввиду. Разобравшись с типами антропогенных источников, мы сразу стали разбираться в сотнях миллиардов возможных сценариев реализации угроз (хотя правильно было говорить о сценариях атак, но это вряд ли возможно, так как термин "атака" уже закреплен за другим регулятором в области ИБ). При этом даже в части с TTP у текущего, "фстэковского" варианта, есть свои нюансы. Например, если посмотреть на онтологию взаимосвязей техник, тактик и процедур, то мы увидим, что они очень тесно завязаны с инструментарием, используемым тем или иным нарушителем (причем та же MITRE ATT&CK оперирует конкретными группировками, а не абстрактными антропогенными факторами), используемыми им командами и характеризующими его индикаторами (IOC). У ФСТЭК эти три компонента отсутствуют и у меня есть стойкое подозрение, что их и не появится, так как конкретными хакерскими группировками и их атрибуцией у нас в России если и занимаются, то только частные компании типа Лаборатории Касперского, Groip IB или Positive Technologies, а индикаторы у нас рассылают ГосСОПКА (ФСБ) и ФинЦЕРТ (Банк России). А будут ли все эти участники следовать общей стратегии я не знаю.

Еще один момент, связанный с развитием всего этого подхода. Матрица MITRE ATT&CK поддерживается и активно развивается международным сообществом ИБ и любой желающий может поучаствовать в расширении списка техник и атак. Кто будет поддерживать модель угроз и БДУ ФСТЭК? Один Воронежский ГНИИ ПТЗИ? Или им еще Positive Technologies будет помогать, чьи картинки используются в проекте методики ФСТЭК? Ну одна она будет не в состоянии это тянуть. В п.6.3 написано, что при выявлении новых TTP информацию о них надо направлять во ФСТЭК, но кто это будет делать и зачем? В итоге одни вопросы...

Но вернемся к проекту методики ФСТЭК. Выше я написал, что формирование перечня сценариев никак не связана с формированием перечня типов доступа, типов нарушителей, видов ущерба, целей и т.п. По уму, чтобы это вся схема заработала и было связано между собой, нужно иметь три уровня документов, которые можно было бы объединить термином "модель угроз":

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

Чтобы увязать сценарии атак, являющиеся целью проекта методики ФСТЭК надо добавить раздел, связанный именно с левой частью вышеприведенной иллюстрации, расширив уже имеющуюся часть про нарушителей и негативные последствия еще и частью про типы угроз, которые могут быть актуальны для конкретного стейкхолдера (заинтересованного лица в организации). И если поставить во главу угла (чтобы не сильно переделывать уже проделанный титанический труд) сценарии угроз, то картинка взаимосвязей (онтология) может быть такой.

П.6.6 вновь напоминает, что моделировать угрозы надо на 5-ти уровнях - аппаратном, системном, прикладном, сетевом и сервисном. Правда, в 3-м разделе последний уровень касался только пользователей, а сейчас в него добавили еще Web-интерфейсы, информацию и иные компоненты (синхронизировать бы).

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

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

То есть оформление этого множества превратит специалистов по моделированию угроз в апологетов супрематизма. На рисунке 11 показан пример того, как может быть определен сценарий реализации угрозы. И такие картинки надо рисовать на каждый сценарий или группу сценариев. "Позитиву" впору выпускать библиотеку готовых сценариев или библиотеку иконок и шаблонов для их оформления. Большинство компаний будет не в состоянии оформить даже одну угрозу, не говоря уже обо всех. При этом п.6.8 зачем-то посылает нас на три буквы, то есть к БДУ, который должен стать основой для формирования исходного перечня угроз. Но формат БДУ сейчас вообще не соответствует тому, что написано в методике. И еще не меньше года не будет соответствовать, так как описать даже текущих 77 техник и соотнести их с текущими 200 угрозами - задача нетривиальная. Еще же надо не забыть решить вопрос с теми, кто уже провел моделирование по БДУ. Надо ли им будет все переделывать или нет? И, кстати, вопрос. Будет ли введена эта методика сразу или только после обновления БДУ?

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

Вообще после прочтения п.6.8 сложилось впечатление, что его писали совершенно разные люди с разным пониманием задач моделирования, которые попытались объединить то, что было у ФСТЭК в прежней методике, и то, что привнесли с идеей сценариев реализации угрозы. В итоге получилось не очень. Так как предыдущая версия методики моделирования была больше похожа на то, что я выше описал как стратегическую или высокоуровневую модель угроз, а нынешняя редакция все перевернула с ног на голову и, не доделав прошлую задачу, перешла сразу к низкоуровневой модели.

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

Подробнее…