20.04.2020

Как я моделировал угрозы по проекту новой методики ФСТЭК. Часть 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-го раздела проекта методики моделирования угроз. Завершу и эту заметку, продолжение которой будет завтра.

11 коммент.:

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

По методике Вы должны были сначала оценить возможные для Вас негативные последствия от реализации угроз, затем оценить условия реализации угроз, затем описать возможные источники угроз.
Граница моделирования (зона Вашей ответственности) так же не определена.
Откуда взялся Ваш перечень угроз, непонятно.

Что касается мер - то их обладатель выбирает и реализует сам, исходя из тех угроз, которые он намоделировал. Про меры ни в методике, ни в моделях не пишут.

Алексей Лукацкий комментирует...

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

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

ФСТЭК всегда требовала про меры в МУ не писать: не нравится им это. Тем более, что про меры все равно придется писать в других документах (в ТЗ, в проектной документации). Зачем лишняя писанина?

Алексей Лукацкий комментирует...

Я вроде не писал, что надо именно в саму модель вносить меры защиты. Я писал, что это цель моделирования :-)

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

"Задачей моделирования является как раз выработка защитных мер. А уж поместить их список в модель или в отдельный документ - вопрос второй"

Алексей Лукацкий комментирует...

Именно :-)

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

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

А именно в "моделирование" выработка защитных мер не входит. М.б. только в варианте "а если мы сюда FW поставим - актуальность/опасность угрозы изменится ?"

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

Конкретно эта методика мне не нравится по ряду причин, но в начале документа русским по белому написано для чего она предназначена. И если в инструкции к молотку написано "для забивания гвоздей" - не надо претензии предъявлять что им плохо шурупы заворачивать (только потому что вы считаете что молотком надо работать так).

Модель угроз (как мне кажется из этого документа) неявно поминается в том же 21 приказе ФСТЭК, п.8. Цитирую "В состав мер по обеспечению безопасности персональных данных, реализуемых в рамках системы защиты персональных данных с учетом актуальных угроз безопасности персональных данных и применяемых информационных технологий, входят:". Аот актуальные угрозы (с возможностью ранжирования по уровню опасности) и берутся из Модели угроз. (Приказы по КИИ и т.д. мне смотреть лень).

Алексей Лукацкий комментирует...

Я не говорю про ЗАДАЧИ, которые надо сделать при моделировании. Я говорю про ЦЕЛИ моделирования. Например, когда я измеряю эффективность ИБ, мне это надо не для красивых дашбордов и графиков с отображением метрик, а для того, чтобы принять решения по улучшению этой самой эффективности. Когда я моделирую угрозы, я это делаю, чтобы реагировать на них, а не чтобы иметь список угроз, который ляжет в шкаф и будет выниматься только при проверках. У вас вообще все действия должны быть направлены на реагирование и снижение негативных последствий от реализации угроз. ВСЕ! До единого. А пока методика выглядит как вырванный из контекста документ, непонятно, зачем он появился (утрировано) и что делать с результатами его работы?

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

"Чудны дела твои, ..."
В нашей деревне перед съеданием слона было принято делить его на части. И Моделирование _угроз_ (обращаю внимание на название документа и п.п. "1.2 Методика определяет порядок и содержание работ по моделированию угроз безопасности информации," и "1.3. Методика ориентирована на выявление и оценку антропогенных угроз безопасности информации, возникновение которых обусловлено действиями нарушителей" - там написано для чего эта методика) - одна из таких частей (или один из кирпичиков/свай большого дома под названием Информационная беезопасность).

Тобы понятнее было - когда готовится ЧТЗ - туда вносятся требования по конкретным подсистемам, а не пытаются переписать всё ТЗ с разъяснениями отдельных пунктов. Не надо требовать от "Методики моделирования угроз безопасности информации" "выработки защитных мер". Это следующий шаг (даже через один, после приоритезации).

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

По крайней мере в моей голове вопрос "а нафига нам нужна такая методика и что дальше делать" у меня не возникает, у меня картинка целостная. Какой-то я не такой ...

P.S. это не значит что у меня претензий к методике нет, но они несколько другие.

Алексей Лукацкий комментирует...

Я не про содержание методики, а про целеполагание

Михаил Новокрещенов комментирует...

Я не очень понял, а что значит "не про содержание, а про целеполагание"? Вставить в модель предложение, что для сформированного набора угроз необходимо определить набор нейтрализующих их мер защиты? - но это же очевидно