Стандарт защиты информации по Приказу ФСТЭК 117

3.1.1. Нормативное основание. Процесс реализуется в соответствии с приказом ФСТЭК России №117: п. 12–13; п. 23–26; п. 31–33. Также учитываются: Методические рекомендации ФСТЭК России по моделированию угроз безопасности информации (2021 г.); Банк данных угроз ФСТЭК России (https://bdu.fstec.ru/threat); Методический документ ФСТЭК России 2026 года.

3.1.2. Назначение процесса. Процесс направлен на формирование и поддержание в актуальном состоянии перечня актуальных угроз безопасности информации для каждой ИС Организации в целях обоснования достаточности и адекватности реализуемых мер защиты.

3.1.3. Обязательные элементы процесса. В рамках процесса обязательно обеспечивается:

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

3.1.4. Параметры. Настоящим Стандартом устанавливаются следующие параметры:

• перечень актуальных угроз определяется до ввода ИС в эксплуатацию;
• обязательному рассмотрению подлежат угрозы, включенные в Банк данных угроз ФСТЭК России;
• пересмотр угроз проводится не реже 1 раза в 2 года;
• внеплановый пересмотр осуществляется в течение 30 календарных дней при изменении архитектуры ИС, изменении состава обрабатываемой информации либо выявлении критических уязвимостей;
• перечень актуальных угроз утверждается руководителем Организации;
• срок хранения утвержденного документа не менее 5 лет;
• доля актуальных угроз, обеспеченных мерами защиты, устанавливается равной 100%.

3.1.5. Документирование. Процесс предусматривает:

• составление и актуализацию Моделей угроз безопасности информации;
• составление Актов оценки угроз безопасности информации (при необходимости);
• оценку показателей соблюдения правил выявления и оценки угроз в Протоколе (акте) периодической проверки.

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

• разработка документов по результатам оценки угроз может осуществляться уполномоченным должностным лицом Организации;
• использование типовых моделей угроз при обязательной адаптации к конкретной ИС;
• отказ от разработки полной модели угроз для небольших объектовых ИС, состоящих из типовых АРМ пользователей;
• рекомендуется привлечение лицензиата ФСТЭК России;
• при отсутствии инструментальных средств анализ уязвимостей допускается выполнять на основе официальных бюллетеней безопасности производителей программного обеспечения.

3.1.7. Критерии соответствия. Процесс считается реализованным при одновременном выполнении следующих условий:

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

3.2.1. Нормативное основание. Процесс реализуется в соответствии с приказом ФСТЭК России №117: п. 14–18 (управление доступом); п. 23–26 (применение мер защиты с учетом угроз); п. 27–30 (регистрация событий); п. 34–36 (контроль функционирования системы защиты информации). Также учитывается Методический документ ФСТЭК России 2026 года (группа мер по управлению конфигурациями и изменениями).

3.2.2. Назначение процесса. Процесс направлен на обеспечение контролируемого, документированного и воспроизводимого состояния программных, программно-аппаратных и сетевых компонентов ИС.

3.2.3. Обязательные элементы процесса. В рамках процесса обеспечивается:

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

3.2.4. Параметры. Настоящим Стандартом устанавливаются следующие параметры:

• эталонные конфигурации утверждаются Руководителем Организации;
• формируются отдельные эталоны для: серверов (физических и виртуальных); автоматизированных рабочих мест; сетевого оборудования; средств удаленного доступа;
• отклонение от эталонной конфигурации допускается только при наличии согласованного обоснования;
• соответствие эталонных конфигураций классу защищенности ИС;
• инвентаризация проводится с использованием автоматизированных систем (или в ручном режиме с применением общедоступных средств инвентаризации);
• проверка соответствия фактических конфигураций эталонным проводится не реже 1 раза в год;
• внеплановая проверка проводится в течение 10 рабочих дней после внесения изменений;
• журнал учета изменений ведется в обязательном порядке;
• срок хранения журнала изменений не менее 3 лет.

3.2.5. Документирование. Процесс предусматривает:

• ведение эталонных (типовых) конфигураций и настроек для классов компонентов (серверы, АРМ, сетевое оборудование, удалённый доступ, доступ в Интернет);
• ведение регистрации изменений в Журнале изменений и проверок конфигураций (Приложение № 1);
• оценку показателей соблюдения правил контроля конфигураций в Протоколе (акте) периодической проверки.

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

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

3.2.7. Критерии соответствия. Процесс считается реализованным при одновременном выполнении следующих условий:

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

3.3.1. Нормативное основание. Процесс реализуется в соответствии с приказом ФСТЭК России №117: п. 23–26 (учет актуальных угроз и уязвимостей); п. 27–30 (регистрация событий безопасности); п. 31–33 (оценка состояния защиты информации); п. 34–36 (контроль функционирования системы защиты информации). Также учитываются: Методика оценки уровня критичности уязвимостей программных и программно-аппаратных средств (ФСТЭК, 30.06.2025); Методика анализа защищенности информационных систем (ФСТЭК, 25.11.2025); Методический документ ФСТЭК России 2026 года (группа мер по управлению уязвимостями).

3.3.2. Назначение процесса. Процесс направлен на систематическое выявление уязвимостей, оценку их уровня критичности, а также устранение или снижение риска их эксплуатации.

3.3.3. Обязательные элементы процесса. В рамках процесса обеспечивается:

• регулярный анализ информации об уязвимостях (официальные бюллетени, базы данных, в том числе БДУ ФСТЭК);
• проведение анализа защищённости ИС;
• выявление уязвимостей инструментальными и (или) экспертными методами;
• оценка уровня критичности уязвимостей;
• установление сроков устранения;
• контроль устранения;
• документирование результатов.

3.3.4. Параметры. Настоящим Стандартом устанавливаются следующие параметры:

• Сканирование уязвимостей проводится: для серверов — не реже 1 раза в квартал; для рабочих станций — не реже 1 раза в полугодие; внепланово — при выявлении критических угроз.
• внеплановый анализ осуществляется в течение 10 рабочих дней после существенных изменений архитектуры;
• сроки устранения уязвимостей: критические устраняются не позднее 24 часов; уязвимости высокого уровня не позднее 7 календарных дней; уязвимости среднего уровня не позднее 30 календарных дней; уязвимости низкого уровня не позднее 90 календарных дней.
• для устранения уязвимостей в приоритетном порядке принимаются меры по обновлению ПО;
• при выявлении уязвимости, отсутствующей в банке данных угроз ФСТЭК России, направляется информация во ФСТЭК в течение 5 рабочих дней;
• при невозможности устранения уязвимости в установленный срок реализуются компенсирующие меры (сегментация, ограничение доступа, усиление мониторинга), обеспечивающие снижение риска;
• оценка критичности уязвимостей проводится в соответствии с Методикой оценки уровня критичности уязвимостей программных и программно-аппаратных средств.

3.3.5. Документирование. Процесс предусматривает:

• ведение регистрации уязвимостей в Журнале событий, инцидентов и уязвимостей информационной безопасности (Приложение № 2);
• составление Актов анализа защищенности (сканирование/проверка) и оценки критичности;
• составление Актов контроля устранения уязвимостей (подтверждение закрытия/компенсации);
• оценку показателей соблюдения правил управления уязвимостями в Протоколе (акте) периодической проверки.

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

• использование бесплатных инструментов анализа защищённости;
• проведение экспертного анализа при отсутствии специализированных средств;
• привлечение лицензиата ФСТЭК России не реже 1 раза в год.

3.3.7. Критерии соответствия. Процесс считается реализованным при одновременном выполнении следующих условий:

• отсутствии актуальных критических уязвимостей;
• наличии отчетов по анализу защищённости;
• соблюдении установленной периодичности.

3.4.1. Нормативное основание. Процесс реализуется в соответствии с приказом ФСТЭК России №117: п. 23–26 (применение мер защиты с учетом актуальных угроз); п. 27–30 (регистрация событий безопасности); п. 31–33 (оценка состояния защиты информации); п. 34–36 (контроль функционирования системы защиты информации). Также учитываются положения Методического документа ФСТЭК России 2026 года (группа мер по управлению обновлениями и устранению уязвимостей).

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

3.4.3. Обязательные элементы процесса. В рамках процесса обеспечивается:

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

3.4.4. Параметры. Настоящим Стандартом устанавливаются следующие параметры:

• классификация обновлений: экстренные (при активной эксплуатации уязвимости); критические; важные; плановые.
• сроки установки: экстренные — до 8 часов (при наличии технической возможности); критические — до 24 часов; важные — до 7 календарных дней; плановые — до 90 календарных дней.
• обновления должны загружаться только из доверенных источников, подлинность и целостность подтверждаются проверкой цифровой подписи, а также путем проверки контрольных сумм.

3.4.5. Документирование. Процесс предусматривает:

• ведение Журнала изменений и проверок конфигураций (Приложение № 1);
• составление Актов тестирования/оценки влияния обновлений (при применимости);
• оценку показателей соблюдения правил управления обновлениями в Протоколе (акте) периодической проверки.

3.4.6. Допустимые варианты реализации при ограниченных ресурсах. При отсутствии специализированных средств централизованного управления обновлениями допускается:

• использование встроенных механизмов ОС (Windows Update, репозитории Linux);
• ручная проверка актуальности обновлений не реже 1 раза в месяц;
• приоритизация обновления критичных систем (серверы, средства защиты).

Обязательные сроки установки и документирование сохраняются.

3.4.7. Критерии соответствия. Процесс считается реализованным при одновременном выполнении следующих условий:

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

3.5.1. Нормативное основание. Процесс реализуется в соответствии с приказом ФСТЭК России №117: п. 14–18 (идентификация и аутентификация субъектов доступа к информации); п. 19–22 (разграничение доступа к информационным ресурсам); п. 23–26 (применение мер защиты информации с учетом актуальных угроз); п. 27–30 (регистрация и анализ событий безопасности); п. 34–36 (контроль функционирования системы защиты информации). Также учитываются положения Методического документа ФСТЭК России 2026 года (группы мер по управлению доступом, защите информации при передаче, защите носителей информации, контролю действий пользователей и предотвращению несанкционированного копирования и распространения информации).

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

3.5.3. Обязательные элементы процесса. В рамках процесса обеспечивается:

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

3.5.4. Параметры. Настоящим Стандартом устанавливаются следующие параметры:

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

3.5.5. Документирование. Процесс предусматривает:

• ведение Перечня защищаемой информации;
• ведение Заявок на предоставление доступа (Приложение № 8);
• составление Актов уничтожения информации/носителей;
• оценку показателей соблюдения правил обращения с информацией ограниченного доступа в Протоколе (акте) периодической проверки.

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

• административный контроль доступа;
• запрет использования съемных носителей;
• физическое хранение документов в металлических шкафах;
• усиленный контроль со стороны руководителя подразделения.

3.5.7. Критерии соответствия. Процесс считается реализованным при одновременном выполнении следующих условий:

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

3.6.1. Нормативное основание. Процесс реализуется в соответствии с приказом ФСТЭК России №117: п. 14–18 (идентификация и аутентификация); п. 19–22 (разграничение доступа); п. 23–26 (защита инфраструктуры и сетевого взаимодействия); п. 27–30 (регистрация событий безопасности); п. 34–36 (контроль функционирования системы защиты). Также учитываются положения Методического документа ФСТЭК России 2026 года (группа мер по защите конечных устройств).

3.6.2. Назначение процесса. Процесс устанавливает обязательные требования по защите физических и виртуальных конечных устройств (рабочих станций, серверов, виртуальных машин), имеющих доступ к ИС Организации.

3.6.3. Обязательные элементы процесса. В рамках процесса обеспечивается:

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

3.6.4. Параметры. Настоящим Стандартом устанавливаются следующие параметры:

• создание учетной записи осуществляется персонализировано на основании письменной заявки;
• запрещается создание и использование общих учетных записей;
• блокирование учетной записи пользователя осуществляется: при увольнении — в день увольнения; при ограничении доступа — по заявке.
• парольная политика для пользователей: минимальная длина — не менее 12 символов; обязательное использование букв верхнего и нижнего регистра, цифр и спецсимволов; алфавит паролей не менее 70 символов; смена пароля — не реже 1 раза в 90 дней; блокировка после 5 неуспешных попыток входа на 15 минут; блокировка не позднее чем 90 дней неиспользования.
• автоматическая блокировка рабочего места при простое — не более 10 минут;
• запрещается записывать пароль на бумажные носители (кроме случаев хранения в опечатываемом сейфе у администратора безопасности);
• все конечные устройства подлежат обязательному учёту;
• доступ пользователей в BIOS (UEFI) должен быть заблокирован (при наличии технической возможности);
• антивирусная защита: использование преимущественно сертифицированного антивирусного ПО; использование централизованной антивирусной защиты (если реализуемо); автоматическое обновление баз не реже 1 раза в сутки; ежедневное сканирование критичных каталогов; полное сканирование не реже 1 раза в неделю.
• межсетевой экран на конечном устройстве должен быть включён постоянно;
• автоматическая блокировка рабочей станции при бездействии более 10 минут;
• пользователям запрещается установка программ без согласования;
• журналы безопасности хранятся не менее 6 месяцев.

3.6.5. Документирование. Процесс предусматривает:

• ведение учета конечных устройств в Журнале учета активов (Приложение № 3);
• оценку показателей соблюдения правил защиты конечных устройств в Протоколе (акте) периодической проверки.

3.6.6. Допустимые варианты реализации при ограниченных ресурсах. При отсутствии централизованной системы управления допускается:

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

3.6.7. Критерии соответствия. Процесс считается реализованным при одновременном выполнении следующих условий:

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

3.7.1. Нормативное основание. Процесс реализуется в соответствии с приказом ФСТЭК России №117: п. 14–18 (идентификация и аутентификация); п. 19–22 (разграничение доступа); п. 23–26 (защита сетевого взаимодействия); п. 27–30 (регистрация событий безопасности); п. 34–36 (контроль функционирования средств защиты). Также учитываются положения Методического документа ФСТЭК России 2026 года (группа мер по защите конечных и мобильных устройств).

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

3.7.3. Обязательные элементы процесса. В рамках процесса обеспечивается:

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

3.7.4. Параметры. Настоящим Стандартом устанавливаются следующие параметры:

• все мобильные устройства подлежат обязательному учёту в реестре;
• обязательная защита паролем или PIN-кодом: длина PIN не менее 6 цифр либо пароль не менее 12 символов; блокировка устройства после 5 неудачных попыток ввода; запрещается повторно использовать 12 последних паролей для доступа к мобильному устройству; смена пароля (PIN-кода) на мобильном устройстве — не реже 1 раза в 30 дней; автоматическая блокировка при бездействии более 5 минут.
• шифрование данных: обязательное включение встроенного шифрования диска (BitLocker, LUKS и т.п.); для служебных смартфонов — обязательное включение шифрования памяти.
• обязательная установка антивирусного ПО с ежедневным обновлением баз;
• запрещается получение root/jailbreak-доступа.
• устройства, используемые для удалённого доступа, должны поддерживать установку сертифицированных СКЗИ (при необходимости);
• проверка перечня мобильных устройств проводится не реже 1 раза в год.

3.7.5. Документирование. Процесс предусматривает:

• ведение учета мобильных устройств в Журнале учета активов (Приложение № 3);
• оценку показателей соблюдения правил защиты мобильных устройств в Протоколе (акте) периодической проверки.

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

• ведение расширенного ручного реестра устройств с фиксацией параметров безопасности;
• проведение выборочной проверки устройств не реже 1 раза в 6 месяцев;
• подписание пользователем обязательства о соблюдении требований безопасности.

При невозможности технического контроля шифрования допускается:

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

При отсутствии корпоративного антивирусного решения допускается:

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

При невозможности внедрения удалённого стирания данных допускается:

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

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

3.7.7. Критерии соответствия. Процесс считается реализованным при одновременном выполнении следующих условий:

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

3.8.1. Нормативное основание. Процесс реализуется в соответствии с приказом ФСТЭК России №117: п. 14–18 (идентификация и аутентификация); п. 19–22 (разграничение доступа); п. 23–26 (защита сетевого взаимодействия); п. 27–30 (регистрация событий безопасности); п. 34–36 (контроль функционирования средств защиты). Также учитываются требования ФСТЭК России 2022 года по обеспечению безопасности удалённого доступа и положения Методического документа ФСТЭК 2026 года (группы мер по сетевой защите и управлению доступом).

3.8.2. Назначение процесса. Процесс устанавливает обязательные требования к организации, предоставлению и контролю удалённого доступа пользователей к ИС Организации

3.8.3. Обязательные элементы процесса. В рамках процесса обеспечивается:

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

3.8.4. Параметры. Настоящим Стандартом устанавливаются следующие параметры:

• удалённый доступ пользователей (не привилегированных) осуществляется: через VPN-шлюз с устойчивыми протоколами шифрования, размещённый в защищённом сегменте; сертифицированные ФСБ России СКЗИ; ПО удалённого доступа, включённое в реестр российского ПО.
• удалённый привилегированный доступ: допускается исключительно при включённой двухфакторной аутентификации; подлежит обязательной записи сеанса (при технической возможности); разрешается на ограниченный временной интервал; требует отдельного письменного согласования.
• минимальная длина пароля — 12 символов;
• срок хранения журналов удалённых подключений — не менее 12 месяцев;
• проверка перечня лиц, имеющих удалённый доступ, проводится не реже 1 раза в 6 месяцев.

3.8.5. Документирование. Процесс предусматривает:

• ведение регистрации учетных записей с правами для удаленного доступа в Журнале учета учетных записей (Приложение № 4);
• ведение Заявок на предоставление доступа (Приложение № 8);
• оценку показателей соблюдения правил организации удаленного доступа в Протоколе (акте) периодической проверки.

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

• при отсутствии аппаратного VPN-шлюза допускается использование программного решения;
• при невозможности внедрения записи сеансов допускается усиленный контроль журналов и сокращение срока действия доступа.

3.8.7. Критерии соответствия. Процесс считается реализованным при одновременном выполнении следующих условий:

• утверждённого перечня ИС с удалённым доступом;
• подтверждения использования российского ПО;
• сертификатов на применяемые СКЗИ;
• журналов удалённых подключений;
• актов проверки прав.

3.9.1. Нормативное основание. Процесс реализуется в соответствии с приказом ФСТЭК России №117: п. 19–22 (разграничение доступа); п. 23–26 (применение мер защиты с учетом актуальных угроз); п. 27–30 (регистрация событий безопасности); п. 34–36 (контроль функционирования системы защиты информации). Также учитываются положения Методического документа ФСТЭК России 2026 года (группы мер по защите сетевой инфраструктуры и беспроводных сегментов).

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

3.9.3. Обязательные элементы процесса. В рамках процесса обеспечивается:

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

3.9.4. Параметры. Настоящим Стандартом устанавливаются следующие параметры:

• разрешенные режимы шифрования: WPA3-Enterprise; WPA2-Enterprise (при отсутствии поддержки WPA3).
• обязательная аутентификация — 802.1X (EAP-TLS или эквивалент);
• запрещенные режимы: WEP; WPA (персональный); открытые сети без аутентификации.
• для ИС 1 класса защищённости дополнительно обеспечивается сокрытие SSID (широковещательная рассылка имени сети отключена);
• беспроводная сеть должна быть размещена в отдельном VLAN;
• уровни сигналов точек доступа должны исключать возможность подключения из-за границ контролируемой зоны;
• периодичность аудита — не реже 1 раза в 6 месяцев;
• журналы подключения хранятся не менее 6 месяцев.

3.9.5. Документирование. Процесс предусматривает:

• ведение учета беспроводных точек доступа в Журнале учета активов (Приложение № 3);
• оценку показателей соблюдения правил беспроводного доступа в Протоколе (акте) периодической проверки.

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

• при отсутствии централизованного контроллера допускается использование точек доступа с локальной аутентификацией при условии соблюдения требований к шифрованию и сегментации;
• при невозможности внедрения 802.1X допускается использование уникальных сложных ключей доступа с обязательной их сменой не реже 1 раза в 3 месяца и дополнительной фильтрацией по MAC-адресам.

3.9.7. Критерии соответствия. Процесс считается реализованным при одновременном выполнении следующих условий:

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

3.10.1. Нормативное основание. Процесс реализуется в соответствии с приказом ФСТЭК России №117: п. 14–18 (идентификация и аутентификация); п. 19–22 (разграничение доступа); п. 27–30 (регистрация событий безопасности); п. 34–36 (контроль функционирования системы защиты информации). Также учитываются положения Методического документа ФСТЭК России 2026 года (группа мер по управлению доступом и управлению учетными записями).

3.10.2. Назначение процесса. Процесс предназначен для установления контролируемого порядка предоставления, использования и отзыва привилегированного доступа (административных прав) в ИС Организации.

3.10.3. Обязательные элементы процесса. В рамках процесса обеспечивается:

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

3.10.4. Параметры. Настоящим Стандартом устанавливаются следующие параметры:

• парольная политика для привилегированных учетных записей: минимальная длина: 12 символов; обязательное использование букв верхнего и нижнего регистра; обязательное использование цифр; обязательное использование специальных символов; алфавит не менее 70 символов; запрет использования персональных данных; запрет повторного использования последних 12 паролей; смена пароля не реже 1 раза в 90 календарных дней; блокировка учетной записи после 5 неуспешных попыток входа (блокировка не менее 15 минут).
• пароли хранятся в защищенном виде;
• количество параллельных сеансов — не более 2 (для ИС К1);
• встроенные учетные записи отключены или переименованы, а также их аутентификационная информация изменена;
• использование строгой аутентификации;
• сеанс администратора автоматически завершается при бездействии более 15 минут.
• все административные действия подлежат обязательной регистрации;
• журналы действий хранятся не менее 12 месяцев;
• проверка перечня администраторов проводится не реже 1 раза в 6 месяцев.

3.10.5. Документирование. Процесс предусматривает:

• ведение регистрации учетных записей привилегированных пользователей в Журнале учета учетных записей (Приложение № 4);
• ведение Заявок на предоставление доступа (Приложение № 8);
• оценку показателей соблюдения правил организации привилегированного доступа в Протоколе (акте) периодической проверки.

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

• ведение отдельного реестра администраторов;
• ручная проверка журналов не реже 1 раза в месяц.

При отсутствии технической возможности внедрения 2FA допускается:

• сокращение срока смены пароля;
• обязательная ежедневная проверка журналов;
• ограничение времени доступа по расписанию.

3.10.7. Критерии соответствия. Процесс считается реализованным при одновременном выполнении следующих условий:

• утвержденного перечня администраторов;
• наличия приказов о предоставлении привилегированного доступа;
• ведения журналов действий администраторов;
• подтверждения периодической проверки прав;
• наличия документов об отзыве доступа.

3.11.1. Нормативное основание. Процесс реализуется в соответствии с приказом ФСТЭК России №117: п. 27–30 (регистрация и анализ событий безопасности); п. 31–33 (оценка состояния защиты информации); п. 34–36 (контроль функционирования системы защиты информации). Также учитываются: Методический документ ФСТЭК России 2026 года (группа мер по управлению уязвимостями); Приказ ФСБ России от 24 июля 2018 г. № 367; Методические рекомендации и информационные сообщения Национального координационного центра по компьютерным инцидентам (НКЦКИ) ФСБ России.

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

3.11.3. Обязательные элементы процесса. В рамках процесса обеспечивается:

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

В случае необходимости организации взаимодействия с ГосСОПКА (НКЦКИ) дополнительно обеспечивается:

• регистрация Организации в качестве взаимодействующей стороны в национальном сегменте ГосСОПКА (через НКЦКИ или ведомственный центр мониторинга);
• назначение лица (лиц), ответственного за взаимодействие с ГосСОПКА;
• получение и анализ информации об угрозах, уязвимостях, индикаторах компрометации;
• доведение полученной информации до сведения администраторов ИС;
• использование полученных данных для актуализации модели угроз;
• направление сведений о компьютерных инцидентах в НКЦКИ или ведомственный центр мониторинга.

3.11.4. Параметры. Настоящим Стандартом устанавливаются следующие параметры:

• регистрируемые события включают: попытки входа (успешные и неуспешные); изменения прав доступа; изменения конфигураций; запуск и остановку сервисов; события средств защиты.
• периодичность анализа: критические события — ежедневно; обобщенный анализ — не реже 1 раза в неделю.
• срок хранения журналов: не менее 1 года для серверов; не менее 6 месяцев для рабочих станций. Время хранения может увеличиваться для систем повышенной значимости;
• срок реагирования: первичного реагирования — не более 2 часов с момента выявления; локализация инцидента высокой критичности — не более 4 часов; локализация средней критичности — не более 1 рабочего дня.
• для ИС 1 и 2 классов рекомендуется обеспечить централизованный сбор и корреляцию событий безопасности с использованием SIEM-системы;
• в случае наличия значимых объектов КИИ, а также в случае иной необходимости, организуется взаимодействие с ГосСОПКА в части обмена информацией об инцидентах.

В случае организации взаимодействия ГосСОПКА (НКЦКИ):

• регистрация в ГосСОПКА — однократно. При изменении контактных данных или ответственных лиц информация обновляется в течение 10 рабочих дней;
• периодичность получения информации — не реже 1 раза в сутки;
• сроки направления уведомлений об инцидентах: предварительное уведомление — не позднее 1 часа с момента выявления; уведомление об инциденте — не позднее 24 часов; окончательный отчёт — не позднее 3 рабочих дней с момента завершения расследования.
• формат обмена — в соответствии с требованиями НКЦКИ.

При утечке персональных данных:

• в течение 24 часов направляется уведомление о факте утечки в Роскомнадзор;
• в течение 72 часов направляются результаты внутреннего расследования;
• если с НКЦКИ заключено соглашение, такое же уведомление направляется в НКЦКИ в течение 24 часов.

3.11.5. Документирование. Процесс предусматривает:

• ведение Карточек инцидентов в системе ГосСОПКА (при взаимодействии);
• ведение Журнала событий, инцидентов и уязвимостей информационной безопасности (Приложение № 2);
• составление Актов расследования инцидентов;
• оценку показателей соблюдения правил мониторинга в Протоколе (акте) периодической проверки.

3.11.6. Допустимые варианты реализации при ограниченных ресурсах. При отсутствии специализированной SIEM-системы допускается:

• использование встроенных средств журналирования ОС;
• еженедельная ручная проверка журналов администратором;
• хранение журналов на выделенном сервере без централизованной корреляции.

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

3.11.7. Критерии соответствия. Процесс считается реализованным при одновременном выполнении следующих условий:

• включенной регистрации событий на ключевых узлах;
• подтверждения регулярного анализа;
• установленного срока хранения журналов;
• назначенного ответственного лица;
• журналов учета анализа событий.

Процесс взаимодействия с ГосСОПКА считается реализованным при наличии подтверждённой регистрации, назначении ответственного лица, соблюдении сроков уведомления.

3.12.1. Нормативное основание. Процесс реализуется в соответствии с приказом ФСТЭК России №117: п. 12–13 (организация деятельности по защите информации); п. 14–22 (управление доступом); п. 23–26 (обеспечение защиты инфраструктуры); п. 27–30 (регистрация событий безопасности); п. 34–36 (контроль функционирования системы защиты информации). Также учитываются: ГОСТ Р 56939-2024 «Защита информации. Разработка безопасного программного обеспечения. Общие требования»; Методический документ ФСТЭК России 2026 года (группа мер по управлению уязвимостями).

3.12.2. Назначение процесса. Процесс предназначен для обеспечения разработки, модернизации и сопровождения программного обеспечения с учетом требований информационной безопасности на всех этапах жизненного цикла.

3.12.3. Обязательные элементы процесса. В рамках процесса обеспечивается:

• формирование требований безопасности к разрабатываемому ПО;
• использование безопасных стандартов кодирования;
• обязательный контроль исходного кода (code review);
• проведение статического анализа уязвимостей;
• проведение динамического анализа и тестирования (для критичных систем);
• управление версиями и конфигурациями исходного кода;
• регистрацию и устранение выявленных уязвимостей;
• документирование релизов.

3.12.4. Параметры. Настоящим Стандартом устанавливаются следующие параметры:

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

3.12.5. Документирование. Процесс предусматривает:

• составление Актов проверки безопасности релиза;
• оценку показателей соблюдения правил безопасной разработки ПО в Протоколе (акте) периодической проверки.

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

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

3.12.7. Критерии соответствия. Процесс считается реализованным при одновременном выполнении следующих условий:

• утвержденных требований безопасности к ПО;
• системы контроля версий;
• отчетов анализа уязвимостей;
• журнала изменений;
• подтверждения устранения критичных уязвимостей.

3.13.1. Нормативное основание. Процесс реализуется в соответствии с приказом ФСТЭК России №117: п. 12–13 (организация деятельности по защите информации); п. 23–26 (обеспечение защиты инфраструктуры ИС); п. 27–30 (регистрация событий безопасности); п. 34–36 (контроль функционирования системы защиты). Также учитываются положения Методического документа ФСТЭК России 2026 года (группа мер по физической защите и ограничению доступа к средствам обработки информации).

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

3.13.3. Обязательные элементы процесса. В рамках процесса обеспечивается:

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

3.13.4. Параметры. Настоящим Стандартом устанавливаются следующие параметры:

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

3.13.5. Документирование. Процесс предусматривает:

• составление и актуализацию Акта определения контролируемой зоны;
• ведение Перечня защищаемых помещений;
• ведение Перечня лиц, допущенных в защищаемые помещения;
• ведение Журнала учета посещений защищаемых помещений (Приложение № 5);
• оценку показателей соблюдения правил физической защиты в Протоколе (акте) периодической проверки.

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

• при отсутствии возможности установки СКУД допускается использование механических замков повышенной взломостойкости;
• при отсутствии централизованной охраны допускается установка автономной сигнализации;
• при невозможности установки решеток допускается использование противоударных пленок или бронированных стеклопакетов.

3.13.7. Критерии соответствия. Процесс считается реализованным при одновременном выполнении следующих условий:

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

3.14.1. Нормативное основание. Процесс реализуется в соответствии с приказом ФСТЭК России №117: п. 23–26 (обеспечение устойчивости функционирования и защита сетевой инфраструктуры); п. 27–30 (регистрация событий безопасности); п. 31–33 (оценка состояния защиты информации); п. 34–36 (контроль функционирования средств защиты). Также учитываются положения Методического документа ФСТЭК России 2026 года (группы мер по обеспечению доступности и отказоустойчивости ИС).

3.14.2. Назначение процесса. Процесс предназначен для обеспечения непрерывности функционирования ИС, минимизации времени простоя при авариях, сбоях и инцидентах информационной безопасности, а также обеспечения восстановления работоспособности в установленные сроки.

3.14.3. Обязательные элементы процесса. В рамках процесса обеспечивается:

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

3.14.4. Параметры. Настоящим Стандартом устанавливаются следующие параметры:

• к критически важным ИС относятся значимые объекты критической информационной инфраструктуры, а также ИС, относящиеся к первому классу защищенности;
• интервалы времени восстановления функционирования ИС, их сегментов, выполняющих значимые функции: для ИС 1 класса — не более 24 часов с момента обнаружения нарушения функционирования; для ИС 2 класса защищенности — не более 7 календарных дней; для ИС 3 класса защищенности — не более 4 недель.
• резервное копирование: для критичных систем — ежедневно; для систем средней критичности — не реже 1 раза в неделю; конфигурации сетевого оборудования — после каждого изменения.
• резервные копии хранятся: не менее 30 календарных дней (оперативные копии); не менее 12 месяцев (архивные копии, при наличии нормативных требований).
• не менее одной копии хранится вне основной площадки или в изолированном сегменте (для критических систем — не менее двух копий на разных носителях);
• тестирование восстановления проводится не реже 1 раза в 12 месяцев;
• восстановление должно быть задокументировано Актом восстановления.

3.14.5. Документирование. Процесс предусматривает:

• ведение Журнала резервного копирования и восстановления (Приложение № 6);
• составление Актов восстановления (по факту выполнения работ);
• оценку показателей соблюдения правил непрерывности функционирования ИС в Протоколе (акте) периодической проверки.

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

• хранение резервных копий на выделенном сервере в изолированном сегменте;
• использование защищённых облачных хранилищ;
• приоритизация резервирования наиболее критичных сервисов.

3.14.7. Критерии соответствия. Процесс считается реализованным при одновременном выполнении следующих условий:

• наличие журнала выполнения резервного копирования;
• результатов тестового восстановления.

3.15.1. Нормативное основание. Процесс реализуется в соответствии с приказом ФСТЭК России №117: п. 12–13 (организация деятельности по защите информации); п. 14–18 (идентификация и аутентификация пользователей); п. 19–22 (разграничение доступа); п. 27–30 (регистрация событий безопасности); п. 34–36 (контроль функционирования системы защиты информации). Также учитываются положения Методического документа ФСТЭК России 2026 года (группа организационных мер, направленных на обеспечение осведомлённости пользователей).

3.15.2. Назначение процесса. Процесс предназначен для формирования у пользователей устойчивых навыков безопасной работы с ИС, понимания требований нормативных документов и личной ответственности за нарушение требований защиты информации.

3.15.3. Обязательные элементы процесса. В рамках процесса обеспечивается:

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

3.15.4. Параметры. Настоящим Стандартом устанавливаются следующие параметры:

• для пользователей (не привилегированных): вводный инструктаж проводится до предоставления доступа к ИС; плановое обучение проводится не реже 1 раза в 12 месяцев; продолжительность планового обучения — не менее 2 академических часов; результаты обучения пользователей хранятся не менее 3 лет.
• для привилегированных пользователей (администраторов) и ответственных за защиту информации: вводный инструктаж проводится до предоставления доступа к ИС; плановое обучение проводится в учебных центрах не реже 1 раза в 2 года; продолжительность планового обучения — не менее 72 академических часов; результаты обучения пользователей хранятся не менее 3 лет.
• тестирование пользователя: проводится не реже 1 раза в 3 года или после компьютерного инцидента; минимальный проходной балл — 70% правильных ответов; при неудовлетворительном результате проводится повторное обучение в течение 30 календарных дней;
• проведение имитационных рассылок электронных писем на служебные адреса электронной почты, иные служебные средства коммуникаций с целью оценки устойчивости пользователей к методам социальной инженерии.

3.15.5. Документирование. Процесс предусматривает:

• ведение Программы обучения/инструктажей пользователей;
• ведение Журнала проведения инструктажей и обучений (Приложение № 7);
• ведение Листов ознакомления пользователей под подпись с локальными актами;
• оценку показателей соблюдения правил повышения осведомленности пользователей в Протоколе (акте) периодической проверки.

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

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

3.15.7. Критерии соответствия. Процесс считается реализованным при одновременном выполнении следующих условий:

• утверждённой программы обучения;
• наличия журнала инструктажей;
• материалы и результаты тестирования знаний.

3.16.1. Нормативное основание. Процесс реализуется в соответствии с приказом ФСТЭК России №117: п. 14–18 (идентификация и аутентификация); п. 19–22 (разграничение доступа); п. 23–26 (защита сетевой инфраструктуры); п. 27–30 (регистрация событий безопасности); п. 31–33 (оценка состояния защиты информации); п. 34–36 (контроль функционирования средств защиты). Также учитываются положения Методического документа ФСТЭК России 2026 года (группы мер по управлению доступом, управлению конфигурациями и контролю деятельности подрядчиков).

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

3.16.3. Обязательные элементы процесса. В рамках процесса обеспечивается:

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

3.16.4. Параметры. Настоящим Стандартом устанавливаются следующие параметры:

• доступ подрядчика оформляется письменной заявкой и приказом (или распоряжением);
• срок действия доступа не превышает срок действия договора или 30 календарных дней (если иное не обосновано служебной необходимостью);
• привилегированный доступ подрядчику допускается только при наличии письменного согласования руководителя Организации;
• удалённый доступ представителей подрядных организаций разрешён только с IP-адресов, принадлежащих российским операторам связи (согласно GeoIP);
• все действия подрядчиков подлежат обязательной регистрации;
• проверка соблюдения требований подрядчиком проводится не реже 1 раза в год либо по завершении критических работ.

3.16.5. Документирование. Процесс предусматривает:

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

3.16.6. Допустимые варианты реализации при ограниченных ресурсах. При отсутствии собственных специалистов по защите информации допускается:

• включение в договор обязательства подрядчика соблюдать требования №117;
• привлечение лицензиата ФСТЭК для контроля работ подрядчика;
• проведение выборочного контроля журналов действий.

3.16.7. Критерии соответствия. Процесс считается реализованным при одновременном выполнении следующих условий:

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

3.17.1. Нормативное основание. Процесс реализуется в соответствии с приказом ФСТЭК России №117: п. 23–26 (защита сетевой инфраструктуры и сегментация); п. 27–30 (регистрация событий безопасности); п. 31–33 (оценка состояния защиты информации); п. 34–36 (контроль функционирования средств защиты). Также учитываются положения Методического документа ФСТЭК России 2026 года (группы мер по обеспечению доступности и устойчивости функционирования ИС).

3.17.2. Назначение процесса. Процесс предназначен для обеспечения устойчивости функционирования ИС при реализации распределённых атак отказа в обслуживании (DDoS), минимизации времени недоступности сервисов и предотвращения нарушения выполнения функций Организации.

3.17.3. Обязательные элементы процесса. В рамках процесса обеспечивается:

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

3.17.4. Параметры. Настоящим Стандартом устанавливаются следующие параметры:

• для внешних сервисов, доступных из сети Интернет, должны применяться: средства межсетевого экранирования с функциями защиты от DoS/DDoS; лимитирование соединений (rate limiting); фильтрация по аномальным сигнатурам трафика.
• двукратное резервирование пропускной способности каналов связи для критических сервисов;
• время реакции на признаки DDoS-атаки — не более 30 минут с момента выявления;
• максимально допустимое время недоступности критического сервиса (RTO) — не более 4 часов;
• логи сетевых событий хранятся не менее 12 месяцев (рекомендуется 3 года);
• тестирование устойчивости к нагрузке проводится не реже 1 раза в год.

3.17.5. Документирование. Процесс предусматривает:

• ведение Перечня сервисов, подлежащих защите от DDoS-атак;
• оценку угроз для внешних сервисов в Модели угроз безопасности информации;
• определение требований к защите внешних сервисов в Техническом задании на создание подсистемы информационной безопасности;
• регистрацию событий и инцидентов ИБ, связанных с DDoS-атаками в Журнале событий, инцидентов и уязвимостей информационной безопасности (Приложение № 2);
• оценку показателей соблюдения правил защиты от DDoS-атак в Протоколе (акте) периодической проверки.

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

• использование услуг провайдера связи по фильтрации DDoS-трафика;
• применение облачных сервисов защиты от DDoS;
• ручная блокировка IP-адресов при маломасштабных атаках.

3.17.7. Критерии соответствия. Процесс считается реализованным при одновременном выполнении следующих условий:

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

3.18.1. Нормативное основание. Процесс реализуется в соответствии с приказом ФСТЭК России №117: п. 23–26 (обеспечение устойчивости функционирования и защита сетевой инфраструктуры); п. 34–36 (контроль функционирования средств защиты). Также учитываются положения Методического документа ФСТЭК России 2026 года (группа мер по обеспечению защиты систем искусственного интеллекта).

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

3.18.3. Обязательные элементы процесса. В рамках процесса обеспечивается:

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

3.18.4. Параметры. Настоящим Стандартом устанавливаются следующие параметры:

• пересмотр перечня ИИ-систем — не реже 1 раза в год;
• проверка настроек безопасности ИИ-систем — не реже 1 раза в 6 месяцев;
• хранение журналов использования ИИ — не менее 1 года;
• обязательная оценка угроз до ввода ИИ в эксплуатацию;
• запрет использования несанкционированных внешних ИИ-сервисов.

3.18.5. Документирование. Процесс предусматривает:

• ведение Перечня систем искусственного интеллекта;
• оценку угроз для ИИ-систем в Модели угроз безопасности информации;
• определение требований к защите ИИ-систем в Техническом задании на создание подсистемы информационной безопасности;
• регистрацию событий и инцидентов ИБ, связанных с ИИ-системами в Журнале событий, инцидентов и уязвимостей информационной безопасности (Приложение № 2);
• оценку показателей соблюдения правил использования ИИ в Протоколе (акте) периодической проверки.

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

• допускается ведение перечня ИИ-систем в форме утвержденной таблицы;
• ручной анализ рисков без специализированных инструментов.

3.18.7. Критерии соответствия. Процесс считается реализованным при одновременном выполнении следующих условий:

• наличии утвержденного перечня ИИ-систем;
• документированной оценки угроз, связанных с ИИ;
• установленных ограничений на передачу данных;
• разграничения доступа;
• журналирования и проведения ежегодной проверки.

3.19.1. Нормативное основание. Процесс реализуется в соответствии с приказом ФСТЭК России №117: п. 31–33 (оценка состояния защиты информации, расчет показателя защищенности Кзи и показателя уровня зрелости Пзи); п. 34–36 (контроль функционирования системы защиты информации). Также учитываются методические документы ФСТЭК России, устанавливающие порядок расчета показателей Кзи и Пзи, а также Методический документ ФСТЭК России 2026 года.

3.19.2. Назначение процесса. Процесс предназначен для оценки текущего состояния защиты информации, определения показателя защищенности (Кзи) и показателя уровня зрелости (Пзи), подтверждения достаточности реализованных мер защиты и принятия управленческих решений.

3.19.3. Обязательные элементы процесса. В рамках процесса обеспечивается:

• пересмотр класса защищенности ИС;
• проведение плановой проверки реализации мер защиты;
• расчет показателя защищенности Кзи;
• расчет показателя уровня зрелости Пзи;
• оформление протокола расчета показателей;
• подготовку заключения о достаточности мер защиты;
• утверждение результатов руководителем Организации;
• направление результатов расчета в ФСТЭК России в установленный срок;
• формирование плана корректирующих мероприятий при необходимости.

3.19.4. Параметры. Настоящим Стандартом устанавливаются следующие параметры:

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

3.19.5. Документирование. Процесс предусматривает:

• ведение Плана проведения контроля;
• оценку показателей соблюдения требований по защите информации в Протоколе (акте) периодической проверки;
• разработку и утверждение Плана корректирующих мероприятий (при необходимости).

3.19.6. Допустимые варианты реализации при ограниченных ресурсах. При отсутствии профильных специалистов допускается:

• проведение оценки комиссией Организации;
• привлечение лицензиата ФСТЭК России;
• использование типовых форм самооценки на основе методических документов.

3.19.7. Критерии соответствия. Процесс считается реализованным при одновременном выполнении следующих условий:

• оформленного протокола (акта) расчета Кзи и Пзи в установленные сроки;
• своевременно переданных результатов в ФСТЭК России;
• плана корректирующих мероприятий при несоответствии Кзи и Пзи установленным целевым значениям;
• подтверждения устранения выявленных несоответствий.