Требования ФСТЭК: от угрозы до средства защиты

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

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

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

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

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

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

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

Коды мер в обосновании приведены в наиболее подробной нумерации — как правило, в терминологии № 239 и № 31. Если выбран другой приказ, номера в обосновании и в перечне мер ниже могут не совпадать. Это ожидаемое поведение: перечень мер всегда точен для выбранного приказа, а обоснование объясняет замысел меры вне привязки к конкретной нумерации.

• Не все соответствия между приказами подтверждены вручную. Часть из них помечена как «сверить» и требует проверки перед переносом в технический проект.
• Данные не обновляются автоматически при выходе новых редакций приказов и при изменении выгрузки БДУ. Актуальность следует сверять с первоисточниками.
• Автоматический подбор аналогов ошибается на пограничных случаях: одинаковый код в разных приказах не всегда означает одну и ту же меру. Поэтому подсказки не вносятся в данные без проверки экспертом.
• Классы средств защиты — единственный раздел справочника, не имеющий документального источника. Приказы устанавливают меры защиты и не называют классы средств. Связь «мера → класс» определена экспертным путём по смыслу формулировок и является подсказкой, а не требованием приказа; об этом сказано на каждой такой странице. Названия продуктов и производителей в справочнике не приводятся.
• Перечень средств защиты предназначен для предварительной оценки состава СЗИ и не заменяет проектных решений: требование АВЗ.1, например, не содержит указания на антивирусное средство. Меры, для которых средство не подобрано, конструктор выводит отдельными списками — без них перечень выглядел бы завершённым, оставаясь полным только в пределах принятых допущений.