Приказ ФСТЭК России № 239: требования, меры и внедрение

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

Общие положения

КИИ — это совокупность ИТ-систем и сетей, от которых напрямую зависит безопасность, национальные интересы, общественное благополучие.

Среди них выделяются значимые объекты КИИ —  их сбой или разрушение влечет за собой тяжёлые потери, угрозы жизни и здоровью граждан, экономические риски, нарушение общественного порядка или национальной безопасности. Именно для них Приказ ФСТЭК №239 устанавливает обязательные защитные меры.

Смысл приказа ФСТЭК России № 239

Документ регламентирует весь жизненный цикл защиты — от проектирования и внедрения комплексов ИБ до сопровождения и вывода из эксплуатации. Это основа для снижения рисков кибератак, поддержания устойчивой работы критических систем, а также документальное подтверждение соответствия государственным требованиям.

Постараемся передать содержание приказа ФСТЭК № 239 кратко, чтобы специалисты быстро поняли требования и смогли эффективно по ним работать.

История и развитие

Приказ ФСТЭК 239 от 25.12.2017 развивается вместе с угрозами. За последние годы в него были внесены важные изменения:

• 2018: уточнение проектирования и документации
• 2019: усиление мер ИБ и работы с ПДн
• 2020: расширен анализ уязвимостей
• 2024: добавлена устойчивость от DDoS, удалённого доступа, взаимодействия с интернетом

На кого распространяется приказ ФСТЭК № 239

Речь идёт о субъектах КИИ —  организациях государственного, коммерческого сектора, работающих в чувствительных сферах.

Значимыми считаются инфосистемы, АСУ, ИТ-сети, без которых невозможна нормальная работа отрасли или региона. Значимость подтверждается через процедуру категорирования.

Организации вправе применять требования приказа ФСТЭК России № 239 и к другим системам по собственной инициативе в рамках внутренней политики ИБ.

Есть нюансы для компаний, работающих с особыми типами данных:

1. Если обрабатывается гостайна, применяется соответствующее законодательство.
2. Если в есть персональные данные (ИСПДн), нужно учитывать ПП № 1119.
3. ГосИнфосистемы (ГИС) также защищаются — в рамках приказа ФСТЭК № 17.

239 приказ ФСТЭК о КИИ при этом не отменяется — он действует в связке с перечисленными нормативами.

Приказ 239 требует организовывать безопасность критически важных ИТ-систем на всех этапах — от идеи до полного завершения использования. Защита закладывается с момента проектирования, развивается по мере его функционирования, действует до завершения работы (пп.7-8).

Общие требования приказа ФСТЭК к безопасности

Меры безопасности выбирает сам субъект КИИ или назначенный специалист на основе категории значимости, утвержденной по правилам категорирования — ПП РФ N 127 от 08.02.2018.

Затем составляется техническое задание (п.10), в нем описываются:

• цели, стоящие перед системой обеспечения ИБ
• перечень обязательных к применению нормативных документов, методических указаний и стандартов
• описание всех защищаемых компонентов — данных, оборудования, каналов связи и ПО
• набор технических и административных мер по защите информации
• структура и порядок внедрения средств контроля доступа
• условия и регламент взаимодействия с внешними устройствами и информационными платформами

Если значимая структура создаётся как часть капстроительства, требования по безопасности прилагаются к проектному заданию. Дополнительно учитываются внутренние регламенты компании, составленные на основании положений N 187-ФЗ.

Построение комплекса организационных, технических мер безопасности: пп.11-11.3

Кто отвечает. Ответственность за формирование организационно-технических механизмов защиты возлагается на владельца цифровой платформы или подрядную организацию, участвующую в его создании или доработке.

Что входит в разработку по требованиям 239 Приказа ФСТЭК. Процесс создания комплексов ИБ включает: оценку рисков, формирование модели угроз, проектирование элементов подсистемы безопасности, а также разработку пакета эксплуатационных документов.

Требования. Организационно-технические механизмы необходимо увязывать с архитектурой системы, чтобы сохранить ее нормальную работу. Также учитываются связи с другими КИИ-объектами и инфосистемами.

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

Как правильно построить и применять модель угроз — читайте наш полный обзор.

Исследование опирается на Банк угроз ФСТЭК и другие доступные ресурсы. По итогам анализа возможно вынесение заключения об изменении архитектурных решений или корректировке внутренних процедур.

Приказ №239 регламентирует, что структура модели угроз должна содержать:

• общее описание объекта, его техническое устройство;
• перечень потенциальных источников опасности;
• список наиболее актуальных рисков;
• описание уязвимых точек, каналов, способов исполнения угроз;
• оценку потенциальных негативных эффектов.

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

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

В рамках проектирования устанавливаются:

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

Если требуется собственная разработка ПО или СЗИ, она ведётся по правилам безопасной разработки. В ходе проектирования допускается уточнение категории инфоресурса.

Для проверки работоспособности может применяться макетирование или тестовая среда, особенно при сложной архитектуре или новых компонентах. Тестирование подтверждает совместимость, отсутствие сбоев, выполнение защитных функций.

На завершающем этапе разрабатывается комплект рабочих документов:

• структуру, описание подсистемы защиты;
• инструкции по конфигурации СЗИ, сопутствующих компонентов;
• нормы, порядок безопасной эксплуатации.

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

Как в приказе реализуются защитные меры административного и технического характера: пп.12-12.7

Отвечает за это субъект КИИ. При необходимости он может привлечь эксплуатирующее предприятие. Субъект КИИ реализует мероприятия по защите значимой ИС, следуя проектной документации, внутренним правилам.

Что включает внедренческий этап:

• монтаж, регулировка СЗИ, прочих элементов
• подготовка регламентов, инструкций, норм безопасности
• проведение организационных процедур — например, контроль доступа
• назначение ответственных лиц
• организация первичного тестирования
• запуск пилотной эксплуатации
• выявление, удаление уязвимостей
• проведение финальных проверок на соответствие требованиям

Установка СЗИ проводится в соответствии с регламентами. Не допускается нарушение эксплуатационных ограничений, зафиксированных в паспортах СЗИ.

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

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

Предварительные испытания. Проверяется, насколько корректно работают средства обеспечения устойчивости, влияют ли их компоненты на работу всей структуры, выполняются ли требования к СЗИ.

Опытная эксплуатация. Тестируются не только технологии, но и готовность персонала — знания, навыки, соблюдение процедур. Результаты влияют на решение о допуске к следующему этапу.

Проверка на уязвимости. До начала эксплуатации проводится комплексная проверка:

• анализ программного кода, настроек, структуры системы;
• аудит установленного ПО, сетевых компонентов;
• проведение испытаний на устойчивость к внешнему вторжению.

Можно использовать тестовую среду или макет. По итогам необходимо устранить уязвимости либо подтвердить, что они не создают рисков. Обязательно сверяются с Банком угроз ФСТЭК.

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

Если защищаемый комплекс КИИ относится к государственной инфосистеме, оценка защиты проводится в форме аттестации (на основании закона или решения владельца). Аттестация проводится по Приказу ФСТЭК от 11.02.2013 № 17, применяется к системам не содержащих государственную тайну.

Запуск значимой ИС в работу разрешается только, если заключение положительное. Необходимо пройти все этапы: от настройки до проверки уязвимостей, в противном случае запуск запрещён.

Эксплуатация

Безопасности во время эксплуатации посвящены пп.13-13.8 приказа 239. За соблюдение всех требований по защите значимого объекта во время его работы отвечает субъект КИИ. Все действия проводятся на основании эксплуатационной и внутренней документации.

Реализуются следующие меры:

• планирование мер защиты;
• регулярная оценка актуальных, новых рисков с анализом возможного ущерба;
• администрирование системы безопасности, контроль событий;
• управление конфигурацией: фиксация изменений, контроль обновлений, журналирование действий;
• реагирование на инциденты в рамках закона № 187-ФЗ;
• организация аварийной готовности: резервирование, обучение персонала, восстановление работы;
• обучение сотрудников, контроль знаний;
• анализ эффективности защиты, при необходимости — корректировка.

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

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

Администрирование системы обеспечения безопасности включает назначение ответственных, сопровождение всех процессов, контроль доступа, обновлений, анализ событий. Документация и меры должны быть актуальными, соответствовать условиям эксплуатации.

Контроль и поддержание конфигурации (п. 13.4). Речь идёт о строгом контроле любых изменений, включая настройки, компоненты, программный код. Все действия документируются, анализируются. Обязательно учитываются дистанционные работы, включая сервис и техподдержку.

Решение ситуаций, связанных с инцидентами (13.5). Назначаются конкретные сотрудники, определяются их обязанности, включая обнаружение, ликвидацию последствий инцидентов. Все действия соответствуют нормам, установленным в законе № 187-ФЗ.

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

Информирование и обучение (13.7). До сотрудников доводится актуальная информация о факторах риска, правилах безопасной работы, проводятся тренировки, занятия. Проверяется уровень знаний, готовности к работе в условиях угроз.

Контроль и корректировка (13.8). Проводится комплексная проверка защищённости как на техническом, так и на организационном уровне. Обнаруженные уязвимости устраняются, итоги фиксируются в документации. При необходимости комплекс безопасности дорабатывается или обновляется.

Обеспечение ИБ на финальном этапе использования

В приказе ФСТЭК № 239  этот этап описывают пункты 14-14.4.

Если принято решение прекратить применение значимого объекта или завершить обработку информации на нём, субъект КИИ обязан обеспечить ИБ на завершающем этапе его жизненного цикла. Все действия должны соответствовать эксплуатационной и внутренней нормативной документации.

На основании 239 приказа ФСТЭК меры, предпринимаемые при выводе значимой ИС из эксплуатации, включают:

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

При решении об уничтожении — обязательная фиксация состава, способа и даты ликвидации.

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

Сброс настроек и удаление служебных данных. При завершении эксплуатации ИС должна быть очищена от всех настроек, конфиденциальных данных: удаляются учётные записи, сведения о доступах, идентификаторы, настройки СЗИ. Это обязательное условие безопасного вывода ресурса из обращения.

Хранение или уничтожение документов. Вся эксплуатационная, организационно-распорядительная документация может быть передана в архив на сроки, установленные самим субъектом КИИ. Если принимается решение о её уничтожении, процесс подлежит обязательной фиксации: состав, способ, дата уничтожения должны быть документально оформлены.

Какие меры обязательны для защиты: организационные, технические — пп.15-26.2

Цель этих мер — обеспечить устойчивую работу цифровой системы, даже если на неё воздействуют угрозы безопасности. Задача Приказа №239 ФСТЭК — защита информации от утечек, сбоев, атак, а сам объект — от остановки и потери контроля (п.16).

Под охрану попадает всё, что критично: данные, техника, программы, архитектура, способы взаимодействия системы с другими. Это касается как ИТ-инфраструктуры, так и автоматизированных систем управления (п.17).

Организационные и технические меры должны быть встроены в работу. Подбираются с учётом категории значимости объекта, уровня рисков, архитектуры. Их нужно адаптировать под конкретную систему. Что-то можно исключить, если оно не применяется, а что-то — дополнить, если стандартных средств недостаточно. Главное — не нарушить стабильную работу самой ИС.

Меры выбираются из базового перечня (приведен в приложении к Требованиям), адаптируются под объект:

1. Исключаются нерелевантные мероприятия.
2. При необходимости добавляются решения из других НПА (например, по защите персональных данных или ГОСТ).
3. При невозможности внедрения определенных действий разрабатываются компенсирующие.

Особое внимание — устойчивость к DDoS-атакам. Если объект доступен из интернета, его нужно дополнительно обезопасить: фильтровать трафик, блокировать вредоносные запросы, хранить информацию о происшествиях.

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

Ключевые направления обеспечения кибербезопасности включают:

• аутентификацию, контроль прав доступа к информационным ресурсам
• использование антивирусных решений, ведение журналов событий, управление конфигурациями
• реагирование на ИБ-инциденты, организация резервирования, восстановления данных
• повышение осведомлённости персонала, регулярное обучение сотрудников, доведение до них актуальной информации о рисках
• обеспечение устойчивости ИТ-инфраструктуры к внешнему воздействию, в том числе противодействие интернет-атакам с применением средств фильтрации, мониторинга, управления сетевыми соединениями.

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

Как защищать значимые объекты от новых угроз и атак на отказ в обслуживании (DDoS) — приказ ФСТЭК № 239, изменения 2024 года.

Если в процессе эксплуатации появляются новые технологии или дополнительные риски, для которых еще не прописаны меры защиты, необходимо разработать компенсирующие механизмы. Это обязательное требование, даже если такие угрозы выявлены позже или связаны с нетипичной архитектурой ИС.

Отдельное внимание уделяется угрозе отказа в обслуживании — особенно для объектов, которые доступны из интернета. В этом случае организация должна:

1. Подключиться к государственной системе мониторинга и реагирования на кибератаки (ГосСОПКА).
2. Наладить автоматический обмен данными с Центром мониторинга сетей связи общего пользования.
3. Обеспечить, чтобы все технические средства фильтрации и блокировки трафика находились в пределах РФ.
4. Согласовать доступность интерфейсов и сервисов с ответственными за ИБ.
5. Отработать схему взаимодействия с хостинг-провайдером на случай DDoS.
6. Предусмотреть фильтрацию трафика, блокировку вредоносных запросов.
7. Использовать собственную инфраструктуру либо перенаправить трафик на защищённые мощности сторонней компании, если своих ресурсов недостаточно.

Требования к программным и программно-аппаратным средствам

Технические меры реализуются программными, программно-аппаратными средствами (СЗИ), включая встроенные компоненты в ПО и оборудование. Приоритет отдается встроенным средствам защиты (п.27).

Для устойчивости значимых объектов применяются СЗИ, прошедшие обязательную сертификацию либо испытания/приемку. Выбор формы оценки определяется законодательством или решением владельца ИС (п.28).

Класс используемых СЗИ подбирается в соответствии с категорией значимости. Чем выше категория, тем жёстче требования к уровню защиты:

Категория	Защита	Класс СВТ
1	минимум 4 класс	5
2	минимум 5 класс	5
3	минимум 6 класс	5

 

Учитываются уровни доверия, определяемые по нормативам ФСТЭК. СЗИ должны соответствовать установленным требованиям, обеспечивать выполнение положений приказа № 239  (п.29).

В новых или модернизируемых объектах 1 категории граничные маршрутизаторы с доступом в интернет должны быть сертифицированы. При их отсутствии допускается оценка их функций в ходе приемки с обоснованием невозможности использования сертифицированных решений (п.29.1).

СЗИ, прошедшие испытания или приемку, обязаны соответствовать функциональным требованиям безопасности, уровню доверия (не ниже 6 для внешних СЗИ). Оценка проводится на этапе начальных испытаний, отдельно или в составе объекта. Результаты оформляются протоколом (п.29.2).

Приказ 239 ФСТЭК в действующей редакции регламентирует, какие требования устанавливаются для прикладного ПО:

1. Разработка с учётом требований безопасности: предусматривает наличие технической документации, оценку потенциальных рисков, продуманную архитектуру, функциональность.
2. Проверка на наличие уязвимостей: включает анализ исходного кода, применение техник фаззинга, динамического тестирования.
3. Обеспечение безопасной поддержки: реализуются механизмы устранения уязвимостей, выпускаются обновления, предоставляются уведомления о патчах, сроках окончания поддержки (см. п. 29.3).

Оценку соответствия программного обеспечения требованиям безопасности проводят проектные специалисты на основе предоставленных материалов от разработчика. Итоги такой проверки становятся частью проектной документации (п. 29.4).

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

Для объектов 1 и 2 категорий — средства хранения, обработки данных должны размещаться в РФ (с оговорками на филиалы и международные соглашения) (п.31).

Приказ ФСТЭК № 239 Приложение: перечень мер

Это таблица с перечнем мер, обеспечивающих безопасность значимых объектов КИИ. В ней отражены обязательные и добавочные мероприятия, сгруппированные по направлениям (например, идентификация, управление доступом, проверка, прочие), сопоставленные с категорией значимости: категории: 1 — самая высокая, 2, 3 — наименьшая значимость.

Знак «+» означает, что мера входит в обязательный базовый набор для соответствующей категории.

Пустая ячейка означает, что мера не обязательна, но может использоваться в зависимости от особенностей объекта или как компенсирующая.

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

Типовые ошибки и сложности

Даже при наличии регламента, проектной документации и выделенного бюджета защита КИИ часто «проваливается» — особенно на проверках. Расскажем, что действительно чаще всего вызывает претензии у ФСТЭК или внутренних аудиторов, и как избежать проблем.

Частые нарушения

ФСТЭК регулярно публикует итоги контрольно-надзорной деятельности. По ним видно: многие нарушения типовые и повторяются из года в год. Чаще всего проверяющие фиксируют:

• отсутствие подтверждённого категорирования объекта КИИ — система эксплуатируется как значимая, но официально в реестр не внесена;
• использование несертифицированных СЗИ, или СЗИ без актуальных обновлений;
• неполный или формальный анализ рисков — модель угроз отсутствует, устарела или не связана с реальными архитектурными решениями;
• меры защиты не соответствуют категории значимости — например, установлены средства, не предусмотренные для 1-й категории, или наоборот, применены упрощённые подходы там, где они недопустимы;
• отсутствие внутреннего контроля: нет актов проверки СЗИ, не ведутся журналы, не проверяется регистрация событий;
• формальная документация — политика безопасности есть, но она не отражает реальную работу систем.

Эти нарушения рассматриваются как несоблюдение приказа № 239. При выявлении — выносятся предписания, а в ряде случаев оформляются административные материалы.

Ошибки при реализации требований

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

• копирование перечней мероприятий без учёта специфики инфосистемы — берут шаблон с предыдущего проекта и вставляют его без изменений;
• установка СЗИ ради галочки, без их включения в эксплуатацию: межсетевой экран есть, но фильтрация не включена;
• отсутствие взаимодействия между ИТ и ИБ — требования не учитываются при изменениях инфраструктуры, что приводит к уязвимостям;
• игнорирование жизненного цикла — меры внедрены на момент запуска, но не поддерживаются в актуальном состоянии.

Также часто забывают актуализировать модель угроз при масштабировании или модернизации системы.

Как снизить риски и санкции

Избежать штрафов и предписаний можно, если внедрение вести как управляемый процесс, а не разовый проект. Несколько рекомендаций:

• вести документацию по каждому этапу — от категорирования до инструктажа пользователей;
• проверять СЗИ на соответствие требованиям ФСТЭК, по каждому типу угроз и с учётом действующих сертификатов;
• согласовывать проектные решения с регулятором при 1-й категории или при взаимодействии с ГосСОПКА — это часто обязательный шаг;
• организовать регулярный контроль и аудит: хотя бы внутренний, с фиксированием результатов;
• обучать и вовлекать пользователей — большинство инцидентов начинается с ошибок людей, а не техники.

Санкции за нарушение приказа № 239 могут быть серьёзными — вплоть до привлечения к ответственности по ст. 13.11 и 13.14 КоАП РФ, если это повлекло утечку или сбой на объекте КИИ. Но при наличии прозрачной документации, логики внедрения и внутреннего контроля такие риски минимальны.

Главное

Приказ ФСТЭК № 239 — ключевой документ по обеспечению безопасности значимых объектов КИИ. Он регулирует все этапы: от проектирования до вывода из эксплуатации.

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

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

Основу защиты составляют технические и организационные меры. Их подбирают в зависимости от категории значимости, уровня рисков и архитектуры. Важно адаптировать список под конкретную систему — просто скопировать «шаблон» нельзя.

Ключевые элементы: актуальная модель угроз, сертифицированные СЗИ, регламенты, контроль событий, обучение персонала, план реагирования.

При проверках исполнения приказа № 239 часто выявляют: отсутствие категорирования, формальный подход к модели угроз, неактуальные или неподключённые СЗИ, слабый внутренний контроль.