Если вам есть, что сказать сообществу профессионалов ИБ и ИТ – заведите здесь свой блог

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

Аватар пользователя SergeyBorisov
Автор: Борисов Сергей,
(6)
()

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


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

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


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

Например, если у нас используется ОС 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 Менеджмент риска ИБ



Оцените материал:
Total votes: 127
 
Комментарии в Facebook
 

Комментарии на сайте

Аватар пользователя Александр Германович

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

В идеале нужно делать 2 модели: одну для ФСТЭК, а вторую собственно для безопасности.

 

up
3 users have voted.
Аватар пользователя Атаманов Геннадий

Моделировать угрозы и не нужно, потому что … невозможно!

Ну как вы смоделируете, например, такую угрозу – «я убью тебя, лодочник!».

- «Я убью тебя, лодочник!» - это угроза?

- Однозначно!

- Какова её модель?

А главное – зачем? Зачем моделировать угрозы?

Угроз может быть бесконечно много. Построить модель бесконечного множества в принципе НЕВОЗМОЖНО! Это – элементарная логика. У регулятора её не было, нет и вряд ли когда будет, но вы же умные и грамотные специалисты.

Моделировать можно атаки. Можно смоделировать нарушителя. Причём одного: можно построить модель конкретного трактора, но нельзя построить «модель трактора вообще» или «модель тракторов». Можно и нужно было бы построить «модель киберразведки» (по аналогии с «Моделью ИТР), но ….

А «Банк угроз и уязвимостей» как был образчиком абсурдизма, так и остался.

up
3 users have voted.
Аватар пользователя SergeyBorisov

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

 

up
3 users have voted.
Аватар пользователя Атаманов Геннадий

Сергей, меры защиты выбираются совсем по другим основаниям. Никто никогда не «анализировал нарушителя»! Никто никогда не «анализировал угрозы»! Те, что в «Банке УУ» - вообще не угрозы! Всю эту ... – модель угроз/модель нарушителя/анализ рисков и пр. – делают по требованию регулятора для удовлетворения его самолюбия. И делаются все эти модели и анализы неправильно! И прежде всего потому, что неправильно всё это понимается и трактуется.

Вот я задал простой вопрос: какова модель угрозы «я убью тебя, лодочник!»? Кто-то может на него ответить?

Упрощаю: назовите угрозу чему угодно (информации, информационной системе, информационной безопасности и пр.) и постройте её модель.

Интересно, найдётся среди российских экспертов/специалистов/аналитиков хоть один, кто хотя бы рискнёт ответить на этот наипростейший вопрос?

up
2 users have voted.
Аватар пользователя SergeyBorisov

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

Кроме того для анализа угрозы необходимо определить все данные об объекте защиты. 

Потрудитесь правильно сформулировать угрозу, опишите объект защиты и вы увидите что проблема решена.  

up
3 users have voted.
Аватар пользователя Атаманов Геннадий

Сергей, а Вы не задумывались вот над каким вопросом: зачем и почему для построения модели угроз нужно описание объекта защиты? Ведь для того, чтобы смоделировать, например, молнию, совершенно не нужно описание земли. Для построения модели трактора абсолютно не нужно описание плуга или прицепа. Почему же тогда для построения моли угроз нужно описание объекта защиты?

Может быть нужно 1) назвать объект, которому угрожают; 2) сформулировать угрозу? Именно это я и сделал в приведенном мной примере-вопросе:

объект – лодочник

угроза – я убью, тебя

модель угрозы – ???

Какова будет модель этой угрозы?

И ещё: помогите мне, пожалуйста, сформулировать хоть одну угрозу информационной безопасности и увидеть её модель:

объект – информационная безопасность

угроза – …?

модель угрозы – …?

up
3 users have voted.
Вы сообщаете об ошибке в следующем тексте:
Нажмите кнопку «Сообщить об ошибке», чтобы отправить сообщение. Вы также можете добавить комментарий.