Анализ проекта Методики определения угроз безопасности ФСТЭК России

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

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

---

По сравнению с подходом, применяемым ранее, планируются следующие изменения:

• моделирование должно проводиться с учетом применяемых средств защиты информации, что ранее указывалось как ошибочный подход (п.2.7 и 4.6 Методики). Таким образом, количество актуальных угроз безопасности в информационных системах, в которых СЗИ внедрены, потенциально должно стремиться к нулю и содержать только угрозы, которые появились за период, прошедший с момента последнего моделирования (требует уточнения у регулятора);
• моделирование предлагается основывать на результатах оценки рисков от нарушения бизнес-процессов и от нарушения безопасности информации, что позволяет сосредоточиться на действительно важных для владельца информации процессах и получить информацию об угрозах в важном для него направлении (сфере). При этом, как проводить оценку не указано, что вносит дополнительную путаницу при моделировании угроз (п.3.1 Методики);
• существенно детализировано описание возможного нарушителя. Нарушитель теперь соотносится с целями реализации угроз безопасности, что позволяет более тонко относить пользователей и возможных нарушителей к классам нарушителей и определять их возможности (потенциал). А возможность (потенциал) нарушителя уже может учитываться при моделировании на этапе формирования сценариев реализации угроз и актуальности угроз из перечня bdu.fstek.ru (п.5.4 Методики). Это упрощает задачу разработчика модели, т.к. позволяет явно связать нарушителя и реализуемые им угрозы;
• указывается на необходимость разделения сфер ответственности центра обработки данных и оператора информационной системы при использовании виртуальной инфраструктуры. При этом, виртуализация остается в сфере ответственности оператора, а программно-аппаратные средства ЦОД, на которых функционирует виртуальная инфраструктура, рассматриваются в модели угроз безопасности, формируемой центром обработки данных (п.2.12 Методики). Однако, остается непонятным вопрос как будут разделять полномочия администраторов ЦОД и администраторов информационных систем при эксплуатации виртуальных машин;
• при рассмотрении удаленных пользователей в качестве потенциальных нарушителей предлагается рассматривать их как в качестве внешних, так и в качестве внешних с локальным доступом, что характерно для внутренних нарушителей (это относится к распространенной ситуации для пользователей, работающих с терминальным сервером в удаленном режиме). И это же позволяет дополнить рассматриваемые угрозы безопасности и более полно описать модель информационной безопасности (п.4.7 Методики);
• экспертный метод опросов при определении опасности угроз, предлагаемый раньше, заменяется более формализованным подходом на основании четких критериев (уровень сложности системы, значимость ресурсов, тип доступа), что делает моделирование прозрачнее для владельца информации, а выводы, сформированные на основании моделирования, более убедительными (п.7 Методики).

Вместе с тем, в предложенной методике моделирования нет однозначного описания как коррелировать угрозы bdu.fstek.ru с негативными последствиями, а также на каком шаге можно и нужно рассматривать таблицу уязвимостей на сайте bdu.fstek.ru.

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

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

Обращает на себя внимание раздел с описанием сценариев реализации угроз безопасности информации. Это описание должен проводить разработчик МУН. Описание сценариев предлагается осуществлять на естественном языке, при этом, как проводить оценку полноты сценариев, достаточности глубины их проработки, их реализуемости – не понятно. Отсутствуют формальные характеристики (ограничения, применимость) при описании сценариев, которые бы не зависели от эксперта. Пример ограничений, которые можно было бы ввести: «сценарий действий внешнего нарушителя по отправке письма с эксплойтом необходимо рассматривать на компьютере пользователя и на почтовом сервере», или «в сценарии действий внешнего нарушителя по DOS-атаке внешнего веб-ресурса рассматривать угрозы, реализуемые только в пределах сегмента локальной вычислительной сети, в которой располагается веб-сервер».

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

На наш взгляд, Методика одновременно и несет в себе много интересных идей (именно интересных, а не новых), и создает, кроме вышеуказанных, много дополнительных вопросов, которые придется выяснять у регулятора лицензиатам, при направлении МУН для согласования.