14.4.16

Средства моделирования угроз: обзор возможностей

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

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

  • Библиотека компонентов, из которых будет строиться анализируемая система или продукт. Базы данных, web-сервисы, коммутаторы, точки доступа, МСЭ, база пользователей, хранилище криптографических ключей... Перечень компонентов должен быть обновляемым, а, возможно, и самостоятельно расширяемым, чтобы пользователь мог самостоятельно создать свой собственный элемент анализируемой системы.
  • Наличие системы визуализации как бы вытекает из предыдущего пункта, но лучше это выделить особо. Компоненты из библиотеки надо уметь соединять между собой, строить информационные потоки между ними, тем самым облегчая процесс анализа угроз. 
  • Безусловно в системе должна быть библиотека (банк данных) угроз, из которых мы будем выбирать актуальные для нас. Библиотека должна быть не только расширяемой, но и иметь возможность подгружать данные из внешних источников, например, из банка данных угроз ФСТЭК или из базы CAPEC.
  • Без библиотеки (банка данных) защитных мер средство моделирования угроз будет неполным. Мы же должны не просто составить перечень угроз, но и оперативно начать их нейтрализовывать, а для этого нужно сопоставить угрозы с защитными мерами, знанием о которых и должно быть оснащено средство моделирования. Как минимум, должна быть просто библиотека защитных мер (опять же пополняемая). Как максимум - система помогающая сопоставлять угрозы с защитными мерами в автоматическом режиме. Но задача это очень непростая.
  • Система генерации отчетов должна на выходе создавать два отчета - список актуальных угроз и список нейтрализующих их мер защиты.
Я перечислил этакий джентльменский набор, которым должно обладать средство моделирования угроз. Разумеется, можно помечтать и расширениях, среди которых я бы выделил:
  • Привязку защитных мер к различным стандартам, требованиям и лучшим практикам в области ИБ
  • Учет динамичности угроз и многоходовости при их реализации. Правда, это скорее уже системы типа RedSeal или Skybox, которые могут динамически строить и перестраивать карту угроз, исходя из информации об уязвимостях, настройках средств защиты и т.п.
  • Корпоративные фишки типа удаленного Web-доступа, ведения репозитория моделей угроз, ролевого доступа, отказоустойчивости и т.п.
  • Учет разных целевых аудитория для модели угроз и, как следствие, разные описания угроз.
  • Автоматизацию "пересчета" модели опираясь на новые угрозы, заложенные в систему.
  • Возможность сравнения разных моделей угроз и анализа тенденций.
Вот такие мечты. Если бы ФСТЭК финансировала разработку такого инструмента (да еще и запустила бы его на своем сайте в виде онлайн-инструмента), то проблема со сложностью моделирования угроз исчезла бы в течение короткого промежутка времени. В крайнем случае, хорошо, если бы какой-либо лицензиат подхватил эту идею и предложил рынку средство автоматизации, рекомендуемое регулятором. Пока же ничего этого нет и приходится рассматривать существующие, преимущественно зарубежные средства моделирования угроз, о которых речь пойдет в следующей заметке.

12 коммент.:

p.a.kulikov комментирует...

Как бы такая система от регулятора не превратилась в рекламную солянку. Навыбирал себе угроз, а он тебе раз и ССПТ-2. И монетизация сервиса и импортозамещение.

Александр комментирует...

Ну от регулятора - вряд ли, а вот если кто из лицензиатов - разработчиков - то да, такая опасность (угроза ;-) ) есть.

Сергей Борисов комментирует...

Алексей, хотелось отметить что средства моделирования угроз уже есть и ещё наверняка появится.
А вот методики ФСТЭК действительно не хватает. http://sborisov.blogspot.ru/2016/04/blog-post_14.html

biakus комментирует...

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

Сергей Городилов комментирует...

Что приходит в голову: "лучше хорошее решение сегодня, чем очень хорошее завтра" или похоже это на "паралич анализа". Ждать можно долго. Короче из ямы это нужно вылезать. Два документа с разными подходами, например, сделать.

Мы тут так делали для разноплановых ИСПДн - свой подход сделали: что-то навроде ФСТЭКовсокго+перечень вытекающий из архитектуры ИС+из структуры ИС.

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

Зачем объединять их в один документ эти подходы? Пусть отдельно сущестувуют.

С уважением.

Сергей Городилов комментирует...

Да, и зачем 90% владельцев типовых ИСПДн вообще эти модели угроз?

Главное упускаемое в этой всей разработке методик - компетентность персонала.

90% ИСПДн нужен ПРОСТО КОМПЕТЕНТНЫЙ БЕЗОПАСНИК, а не модель угроз.

Вот где фокус должен быть. Тем более набор намордников-то не разбежишься.

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

Александр Бодрик комментирует...

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

Сергей Городилов комментирует...

Александр, 90% бизнеса как раз такие исследования не делают а полагаются на интуицию, неформальный подход и опыт. Другой вопрос, что 50% из них заканчивают с делом на 1 год, а еще 30% в следующие два года. Но это не меняет картины. Если им чужда бумага во всём, то бумажная МУ - будет также чужда.

Об измерении компетентности: в ISO 9001 об этом хотя сжато, но исчерпывающе написано. Компетентность включает: образование, обучение, тренинги, навыки и опыт. Раскладываете это на части и с каждой работаете отдельно, т.к. свои критерии. Нет единого способа подтвердить компетентность поэтому. Ответственность за обеспечение компетентности несет руководитель. И отдельно еще выделяется "квалификация". Например, безопасники должны квалифицироваться перед допуском. Это совсем другое. Это не компетентность, а способность достигать результата.

Ronin комментирует...

Методики более-менее адекватные есть давно - те же FRAM, CRAMM и OCTAVE. Другой вопрос, что прочитав и изучив их, фиг кто нормально сделает сходу анализ даже для не самой сложной конторы. Нужен огромный опыт, серьезные наработки, базы угроз, уязвимостей, цепочек, а лучше еще и данные по мониторингу систем и рисков во времени для этой системы.
Поэтому в 99,9% случаев получаем сферического коня в вакууме. Хорошо, если нанятые специалисты реально грамотные, рассматривают систему в деталях и не просто подгоняют свои шаблоны, а думают. Чаще это копирка на тему "средняя угроза вирусного заражения через канал Интернет". Более того, такой подход провоцируют сами регуляторы, навязывая неадекватные методики, ну а далее флаг подхватывают спецы.
О чем вообще речь, если у нас даже понятия путают почти все. Надоело объяснять, что это только говорится "угроза вирусного заражения", а реально: угроза - нарушение конфиденциальности, объект - бухгалтерская отчетность, уязвимость - существующие уязвимости системного ПО, канал атаки - почтовые сообщения на корпоративный почтовый ящик пользователей (это лишь грубый пример, но насколько огромна разница!).
В свое время перебрал кучу софта для риск анализа и дипломную делал на этот счет (она, кстати, на текущий взгляд также весьма убога), так вот так и не нашел адекватного инструмента. Или это вообще черти что и сбоку бантик, когда в системе все эти вещи напутаны, нет взаимосвязей, весов и т.д. или (что гораздо реже и относится к очень крутым зарубежным продуктам, которые пользуют товарищи из Big4) инструмент такой громоздкий и сложный, что использовать его для анализа одной системы и даже одной компании смысла нет - дешевле и проще нанять этого самого консультатнта, который с ним разобрался и у которого уже есть огромные базы от международных профи, живущих этим делом.
Подозреваю, что в обычных ИТ-интеграторах и консалтерах (а мы ведь говорим про моделирование угроз для ИСПДн и ГИС) нет специалистов (боюсь, что будет много недовольны, поэтому можно добавить специалистов, имеющих достаточно времени и ресурсов), которые могут сделать действительно качественный анализ рисков, вот чтоб как по азбуке, со всеми связками и зависимостями. И это не догадки, листал десяток-другой моделей и отчетов от компаний, которые все знают, и которые хорошо раздувают щеки в статьях и на конференциях. Но и сам могу также встать на этот плац, так как собственная попытка создания методики и рабочего фреймворка для оценки рисков затянулась на 2 года (в свободное время), вылилась в огромные базы и невообразимые графы, но результаты даже в первом приближении были все еще далеки от идеального варианта, поэтому для проектов урезал и обобщил - иначе заказчик все равно сойдет с ума от табличек и расчетов на сотни страниц, особенно если они всего лишь для формальнго закрытия необходимости иметь МУ на ИСПДн. Но результат хотя бы адекватен, а то почитаешь иногда...

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

Сергей Городилов комментирует...

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

Ronin комментирует...

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

Сергей Городилов комментирует...

Ronin, так я не понял, Вы нашли адекватный инструмент или всё-таки дело в недостатке опыта?