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

А я продолжаю свое путешествие по проекту методики моделирования угроз и перехожу к 4-му разделу, который позволяет оценить мне потенциал нарушителя или, как написано в методике, условия реализации угроз безопасности информации. Почему я оцениваю потенциал нарушителя ДО определения самих нарушителей, для меня остается тайной. Возможно потому, что пройдя через 4-й раздел вы поймете, что вам уже все равно, кто вас атакует — мамкин хакер или хакер в погонах. А может потому, что потенциал нарушителя, то есть оценка его возможностей, описывается в 5-м разделе? Зачем надо было разделять условия реализации угроз и возможности нарушителя?

Что нарушитель что-то плохое сделал с вашей системой должно совпасть два условия — должны быть уязвимости и у злоумышленника должен быть доступ для реализации угроз. Про второе мы поговорим чуть позже, а пока попробуем разобраться с первой частью. Уязвимости необходимо оценить все! В ПО, в архитектуре, в конфигурации, в организации процесса. Причем первые три типа уязвимостей могут быть не только на уровне общесистемного и прикладного ПО, сетевого оборудования и средств защиты, но и на уровне микропрограммного ПО, то есть на уровне BIOS, процессоров, контроллеров и т.п. Определение «недекларированных возможностей» из раздела 4.4 мне показалось очень размытым и совершенно неформализованным (ну что такое «потенциально опасные функциональные возможности»), но важно, что НДВ могут быть внедрены как разработчиком используемого в ИС софта и железа, так и иными нарушителями на этапе поставки, производства и ремонта (привет, Сноуден).

Определяете уязвимости вы как на этапе создания системы, так и на этапе ее эксплуатации. В последнем случае вы обязаны провести пентест. В п.4.6 почему-то говорится, что вывод вы делаете в том числе и на основе экспертного анализа, но предыдущие предложения этого пункта этого не допускают — только пентест. С одной стороны — это хорошо, так как позволяет уйти от экспертов-теоретиков, которые начинают не к месту говорить о возможностях АНБ для кражи зарплатной ведомоссти ООО «Рога и копыта». С другой — вам придется раскошелиться на пентест (кто-нибудь оценивал, насколько способны существующие лицензиаты-пентестеры окучить хотя бы все госорганы, не говоря уже об остальных российских компаниях?). Кроме того, вы становитесь заложником пентестера и его квалификации. Ну я задался для себя вопросом — должен ли пентестер пытаться атаковать всех удаленных пользователей в случае с системой удаленного доступа или ему надо попробовать это сделать всего один-два раза и потом экстраполировать полученные результаты на все тысячи подключений?

Пункт 4.7 предлагает мне подумать над тем, откуда нарушитель может реализовать свои угрозы — удаленно, локально или… физически. Для меня деление на локальный и физический доступ выглядит несколько надуманно; даже при разъяснении в примере 4. Вот представьте, что вы согласно 3-му разделу отнесли к компонентам ИС PLC или IP-телефон. Если я втыкаюсь в PLC, находясь внутри компании, или подменяю IP-телефон, то это какой доступ, локальный или физический? А в случае с удаленным доступом, если теща со своей учетки решила разложить пасьянс на домашнем ПК, подключенном к корпоративной сети, и случайно занесла на этот компьютер вредоносный код, то это какой доступ — удаленный, локальный или физический? Или, вспоминая первую заметку, это вообще не угроза, так как никаких неправомерных действий теща не совершала? 🙂 Теще, кстати, посвящен п.4.8, но и он не отвечает на вопрос выше.

Трата времени на определение типов доступа при моделировании угроз по анализируемой методике является, на мой взгляд, избыточным. В 6-м разделе, в п.6.5, говорится, что тип доступа определяет начальные тактики Т1 и Т2. Фигушки. Ничего он не определяет, так как Т1 — это сбор информации о сетях и системах, а он, и это я бы принял за аксиому, проводится почти во всех серьезных сценариях угроз (а для непреднамеренных угроз «отказ» нарушителя от этой тактики не влияет на конечный результат методики — для остальных типов нарушителей сбор всего равно осуществляется и мы все равно должны на него закладываться). С Т2, получением первоначального доступа к компонентам систем и сетей, тоже все проще. Я вот с трудом себе представляю ситуацию, когда злоумышленник действует только извне или только изнутри. А если мы посмотрим на 5-й раздел (его мы анализируем завтра), то вы поймете, что из-за нечеткости определения внутреннего и внешнего нарушителя и достаточно динамичного перехода одного статуса в другой, совершенно не важно, какие типы доступа у вас есть — вы все равно, перебирая сценарии угроз, включите в список актуальных оба варианта. По-другому сегодня просто не бывает.

Раздел завершается пунктом 4.9, который говорит, что должно быть определено по итогам оценки потенциала нарушителя. Но я так и не понял, что, а самое главное, как это должно быть определено. Как, конкретно, выявить уязвимости на этапе создания системы? Как, конкретно, выявить уязвимости, на этапе эксплуатации системы (или только пентест, условия проведения которого выходит за рамки методики)? Как выявить недекларированные возможности? По ДСПшному документу ФСТЭК (ну так где ссылка на него или выписку из него)? Зачем мне подробное описание типов доступа нарушителей и как я его должен использовать (кроме п.6.5)? А самое главное, как все выявленное я должен описать? В разделе 3 хотя бы пример таблицы был дан, а тут пустота. Возможно, в следующих разделах станет понятно, зачем это все надо было. Но пока 4-й раздел выглядит для меня незаконченным.