Сопоставление угроз БДУ и мер защиты

Инструмент проводит систему через часть шагов методики оценки угроз ФСТЭК России от 05.02.2021 (профиль системы, модель нарушителя, выбор угроз, сценарии) и сопоставляет итоговый список угроз БДУ ФСТЭК (227 записей) с мерами защиты информации по четырём приказам — №239 (значимые объекты КИИ), №21 (ИСПДн), №31 (АСУ ТП) и №117 (ГИС). Веб-версия на Django, выросшая из настольного tkinter-приложения fstek-239-fstek (см. страницу «Об авторе»).

Как начать

Работа идёт через «Мои системы» — заводите систему и последовательно заполняете её профиль, каждый шаг сохраняется и переживает выход из аккаунта:

1. Технологии — каких точно нет в системе (14 категорий), их угрозы исключаются.
2. Негативные последствия — что и кому может быть плохо (приложение 4 методики).
3. Модель нарушителя — какие из 13 видов актуальны, уровень возможностей считается автоматически (приложения 6 и 8).
4. Способы реализации — какие методы и интерфейсы применимы (раздел 5.2).
5. Выбор угроз — список уже сужен технологиями и моделью нарушителя.
6. Сценарии — обоснование по каждой угрозе со справочником по 143 техникам (приложение 11).
7. Меры защиты — итоговый отчёт, со скачиванием в Word, PDF или .txt.

Зарегистрироваться → аккаунт нужен только для сохранения систем — справочники («Тактики», «Охват») открыты без входа.

Что делает инструмент

• Ведёт профиль системы по методике — технологии, последствия, нарушитель, способы реализации, каждый шаг сохраняется отдельно.
• Сужает список угроз БДУ этим профилем — можно посмотреть, сколько угроз осталось, на каждом шаге, и вернуться к полному списку в любой момент.
• Даёт справочник по 143 техникам приложения 11 и место записать обоснование актуальности по каждой выбранной угрозе.
• Выбираете один или несколько приказов сразу — объект часто подпадает под несколько одновременно (например, значимый объект КИИ, который одновременно является ИСПДн).
• Получаете меры защиты, необходимые для закрытия выбранных угроз, с разбором «почему именно эта мера» под каждой угрозой и разрывом с официальным базовым набором.
• Скачиваете отчёт в .txt, Word или PDF — все три формата строятся из одних и тех же данных.
• Смотрите живую статистику проекта на странице «Охват» — сколько мер задействовано по каждому приказу, целостность каталога.

Как устроено сопоставление

Угроза не привязывается напрямую к коду конкретного приказа — она ссылается на концепт, меру «по сути» (например, «анализ уязвимостей» или «шифрование каналов связи»). У концепта есть код в каждом приказе, где такая мера присутствует, и нет — там, где её нет. Так один и тот же маппинг угроз обслуживает все четыре приказа одновременно, а не переписывается под каждый заново.

Один и тот же концепт может называться в разных приказах по-разному. Например, мера «анализ уязвимостей» — это АУД.2 в №239 и №31, но АНЗ.1 в №21; «защита каналов связи» — ЗИС.19 в №239/№31, но ЗИС.3 в №21. Поэтому в отчёте под одной и той же угрозой список мер выглядит по-разному в зависимости от того, какой приказ выбран — это не ошибка данных, а следствие того, что приказы нумеруют одни и те же по смыслу меры по-своему.

Бывает и наоборот: приказы дробят одну и ту же область по-разному. Управление обновлениями ПО в №239/№31 разложено на 4 отдельные меры (получение из доверенного источника, контроль целостности, тестирование, установка), а в №21 это, по сути, одна мера — «Контроль установки обновлений программного обеспечения» (АНЗ.2). Когда для концепта в выбранном приказе своего кода нет, он не пропадает молча, а попадает в список угрозы с пометкой:

• сверить — автоматический подбор нашёл вероятный аналог по схожести формулировок (с оценкой уверенности), но соответствие не подтверждено человеком — переносить в техпроект можно только после проверки.
• доп. — аналога не нашлось вообще; похоже, что такой меры в выбранном приказе действительно нет. Это кандидат в «дополнение» базового набора (шаг 4 методики ФСТЭК), требует отдельного обоснования.

Приказ №117 (самый свежий из четырёх) всегда доступен как приказ-дополнение по умолчанию: если меры нет ни в одном из приказов, которые вы выбрали, но она есть в №117 — она всё равно попадает в отчёт как реализованная, с явной пометкой источника, а не молча.

Обоснование «Почему эти меры»

Под каждой проверенной угрозой на странице результата есть раскрывающийся блок с текстовым обоснованием — почему выбраны именно эти меры и как они нейтрализуют угрозу по существу, а не формально по совпадению кода. Этот текст написан один раз на уровне концептов и одинаков независимо от того, какой приказ вы выбрали в отчёте — коды мер в нём это общая, наиболее подробная нумерация (обычно в терминологии №239/№31), а не обязательно та, что будет показана вам под конкретной угрозой, если выбран другой приказ. Расхождение в номерах между обоснованием и списком мер ниже — ожидаемое поведение, а не баг: список мер всегда точен для выбранного вами приказа, обоснование объясняет замысел меры вне привязки к конкретной нумерации.

Ограничения

• Не все связки между приказами подтверждены вручную — часть показана как «сверить» и требует проверки перед переносом в техпроект.
• Данные не обновляются автоматически при выходе новых редакций приказов или изменении выгрузки БДУ — актуальность нужно сверять с первоисточниками.
• Автоматический подбор аналогов ошибается на пограничных случаях (одинаковый код в разных приказах не всегда означает одну и ту же меру) — поэтому подсказки никогда не вливаются в данные без проверки человеком.