ИБ. Как не нужно моделировать угрозы ИБ

ИБ. Как не нужно моделировать угрозы ИБ

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

Зачастую отдельные территориальные органы предъявляют специфические требования к моделям угроз.  И сегодня хотелось бы обсудить такое требование, как указание в модели угроз перечня уязвимостей из БДУ ФСТЭК России.  
Но идею использовать базу уязвимостей из БДУ ФСТЭК при моделировании угроз я встречал не только у регулятора, но и у некоторых продвинутых специалистов операторов. Что в общем не удивительно – раз уж есть база, почему бы её не использовать?

Предлагается использовать уязвимости из БДУ следующим образом: определять перечень используемого в ИС программного обеспечения, а потом выбирать все уязвимости, соответствующие версиям используемого ПО. 

Например, если у нас используется ОС Window 7, то мы должны привести перечень всех 306 уязвимостей, связанных с данной ОС


Если MS office 2007 – ещё 135 
MS Adobe Flash Player 11 – ещё 646.

Таким образом, в достаточно большой ИС, с разным прикладным и системным ПО, мы выберем из БДУ ФСТЭК, например, половину всех уязвимостей. Порядка 9000. И что дальше? Зачем нам эта информация на этапе моделирования угроз? На этапе, когда самой ИС ещё нет, а только формируются требования к ней?
    
Для чего нам вообще моделирование угроз? Для того чтобы на этапе создания системы защиты мы могли выбрать правильные меры и средства защиты. Как нам поможет этот перечень гипотетических уязвимостей, которые могут быть, а могут и не быть в итоговой системе.  Ведь для нейтрализации угроз, связанных с эксплуатацией публично известных уязвимостей, существует всего 2-3 меры:
·         установка патчей и патч-менеджмент
·         виртуальный “патчинг”, для тех случаев, когда мы не можем быстро установить обновление
·         изолирование уязвимого узла на уровне сети

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

Но нам же надо моделировать… от нас требуют анализировать уязвимости при моделировании угроз – скажете Вы.  
Посмотрите, как классифицировались угрозы по типам уязвимостей в базовой модели угроз ФСТЭК от 2008 г. – там нужно было ответить, могут ли у нас быть уязвимости на разных уровнях: в системном ПО, прикладном ПО, сетевых протоколах, СЗИ, наличие аппаратных закладок, технических каналов утечки, недостатки мер защиты. 7 уязвимостей.
Посмотрите в текст угроз из БДУ ФСТЭК, как там описаны уязвимости, которые могут быть использованы при реализации угроз. Это совсем не те уязвимости.
 


Да, они плохо структурированы, они не типизированы, но их хотя бы 200, а не 18000 как в соседней ветке. С 200 уже можно работать.  Но ещё лучше структурировать уязвимости, упомянутые в тексте угроз из БДУ и привести их к 7-30 типам, по которым необходимо будет принять обоснованное решение – могут у нас быть такие уязвимости или нет.

Хотите ещё пример, как можно описывать и классифицировать уязвимости в рамках моделирования угроз? Ну вот хотя бы ГОС ИСО/МЭК 27005-2010 Менеджмент риска ИБ


Alt text

Цифровые следы - ваша слабость, и хакеры это знают.

Подпишитесь и узнайте, как их замести!