Действия

Проект ГОСТ » История » Редакция 3

« Предыдущее | Редакция 3/5 (Разница(diff)) | Следующее »
С. Антошкин, 16.06.2026 18:04

Новые редакции¶

Содержание
Новые редакции
ГОСТ Р 57580.1
ГОСТ Р 57580.2

ГОСТ Р 57580.1¶

Предисловие¶

Проект окончательной редакции ГОСТ Р 57580 вышел в конце 2025 года. Синхронно с обновлением 57580.1 17 года может выйти и ГОСТ Р 57580.2 взамен версии 2018 года. Если 57580.1 — это что проверяем, то 57580.2 — как проверяем и как оформляем результат.

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

Расширение области применения¶

Действующий стандарт охватывает кредитные организации, НФО (ст. 76.1 ФЗ о ЦБ) и субъекты НПС. Проект добавляет две новые категории:

Иностранные банки, осуществляющие деятельность на территории РФ через филиалы.
Лица, оказывающие профессиональные услуги на финансовом рынке, в том числе информационные услуги (ст. 76.9-5 ФЗ о ЦБ) — это прежде всего инфраструктурные провайдеры финрынка: операторы финансовых платформ, информационные агентства, поставщики данных.

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

Базовый состав мер теперь охватывает не только финансовые услуги, но и профессиональные услуги на финансовом рынке — понятие, которого в 2017 году не существовало в тексте стандарта.

Контейнеризация как полноценный объект защиты¶

Наиболее значимое техническое изменение — введение контейнеризации в качестве самостоятельного объекта регулирования наравне с виртуализацией.

В 2017 году Процесс 7 назывался «Защита среды виртуализации» и о контейнерах не упоминал вовсе. В проекте процесс переименован в «Защита сред виртуализации и контейнеризации», а его содержание переработано с нуля.

Новые термины, введённые в раздел 3:

3.33 контейнер — изолированная программная среда на основе ядра ОС с технологией контейнеризации (адаптировано из Приказа ФСТЭК №118/2022).
3.39 операционная система с технологией контейнеризации — ОС с установленными средствами контейнеризации.
3.40 средства контейнеризации — программные средства для создания, управления и функционирования контейнеров.
Расширены 3.34–3.36: образы и информационный обмен теперь охватывают виртуальные машины и контейнеры совместно.

Уровень системной инфраструктуры (п. 6.2) дополнен явным указанием на «ОС с технологией контейнеризации и средства контейнеризации» как самостоятельные объекты учёта.

Принципиально новые меры по контейнеризации в таблице 42 (Процесс 7):

Мера	Содержание	Уровень 3	Уровень 2	Уровень 1
ЗСВ.13	Запрет совмещения функций: создание контейнеров / предоставление доступа / управление настройками средств контейнеризации	Н	Т	Т
ЗСВ.15	Запрет запуска контейнеров с привилегированными учётными записями ОС	Т	Т	Т
ЗСВ.16	Ограничения на использование периферии и МНИ внутри контейнера	Н	Т	Т
ЗСВ.24	Запрет подключения одной ОС с контейнеризацией к сегментам разных контуров безопасности	Н	Т	Т
ЗСВ.30	Изоляция пространств имён контейнеров (PID, IPC, User, UTS, Net, Mount)	Н	Т	Т
ЗСВ.31	Ограничение доступа контейнеров к ресурсам аппаратной платформы и системным вызовам ядра	Н	Н	Т
ЗСВ.41	Встроенное сканирование уязвимостей при создании, установке и хранении образов контейнеров	Н	Т	Т

Мера ЗСВ.15 (запрет привилегированных контейнеров) установлена как обязательная для всех трёх уровней — это одна из немногих мер, не имеющих послаблений даже на минимальном уровне защиты.

Также включены меры по регистрации событий (ЗСВ.42–ЗСВ.53), охватывающие операции с контейнерами, средствами контейнеризации и ОС наравне с виртуальными машинами.

Переработка управления уязвимостями (Процесс 3)¶

В 2017 году Процесс 3 был построен по принципу «контролируй отсутствие уязвимостей» применительно к конкретным типам информационного взаимодействия (между сегментами контуров, с Интернетом, к ресурсам во внутренних сетях и т.д.). Стандарт не вводил никакой классификации уязвимостей и не требовал структурированного процесса управления ими.

Проект полностью перестраивает архитектуру Процесса 3, вводя цикл управления уязвимостями с явным разграничением по критичности:

Мера	Содержание	Уровень 3	Уровень 2	Уровень 1
ЦЗИ.1	Определение правил выявления, оценки критичности и порядка устранения уязвимостей	О	О	О
ЦЗИ.2	Поиск уязвимостей в БДУ ФСТЭК, публичных базах разработчиков ПО и исследователей ИБ	О	О	О
ЦЗИ.6	Устранение/нейтрализация уязвимостей критического уровня	Т	Т	Т
ЦЗИ.7	Устранение/нейтрализация уязвимостей высокого уровня	Т	Т	Т
ЦЗИ.8	Устранение/нейтрализация уязвимостей среднего уровня	Т	Т	Т
ЦЗИ.9	Устранение/нейтрализация уязвимостей низкого уровня	Т	Т	Т
ЦЗИ.10	Контроль устранения (нейтрализации) уязвимостей	О	Т	Т

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

Кроме того, явно указано, что сканирование и анализ охватывает в том числе ПО операционных систем с технологией контейнеризации и ПО внутри контейнеров.

Регистрация добавляет меру ЦЗИ.37 — обязательная фиксация фактов устранения (нейтрализации) уязвимостей на всех уровнях защиты. В 2017 году аналогичного требования не было.

Удалённый доступ¶

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

Проект переименовывает процесс в «Защита информации при осуществлении удалённого доступа» и расширяет охват на любые устройства — мобильные и стационарные. Это согласуется с реальной практикой: значительная доля удалённого доступа осуществляется с корпоративных ноутбуков и даже стационарных АРМ через VPN.

Существенные изменения в составе мер:

Мера ЗУД.7 теперь требует многофакторной аутентификации субъектов при удалённом доступе на всех трёх уровнях защиты (в 2017 году требование МФА при удалённом доступе для уровня 3 было выражено иначе и менее категорично).
Добавлена мера ЗУД.12 — обязательное выделение отдельного сегмента контура безопасности для подключения устройств удалённого доступа. В 2017 году сегментация применительно к удалённому доступу явно не требовалась.
Мера ЗУД.15 — закрепление устройств удалённого доступа за конкретными субъектами — добавлена как организационная мера на всех уровнях.
Мера ЗУД.6 — регистрация операций удалённого доступа — стала обязательной для всех трёх уровней.
Понятие «мобильное (переносное) устройство» в системе мер заменено на «устройство, с использованием которого осуществляется удалённый доступ» — технологически нейтральная формулировка.

Методология выбора мер: переход к документируемому процессу¶

В 2017 году алгоритм выбора мер описывался в п. 6.3 как последовательность: выбор базового состава → адаптация (исключение неприменимых) → дополнение нормативными требованиями. Документирование этого процесса стандартом прямо не требовалось.

Проект переработал п. 6.3, добавив:

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

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

Параллельно в Направление Планирование (раздел 8) добавлена мера ПЗИ.6 — документирование мер по восстановлению отказавших технических средств ЗИ. Требование сопрягается с мерами обеспечения доступности, которые ранее описывались менее конкретно.

Структурные изменения¶

Убрано Приложение Б (2017) — «Состав и содержание организационных мер, связанных с обработкой ПДн». Требования по ПДн исключены из стандарта полностью: они достаточно детально регулируются 152-ФЗ и нормативной базой ФСТЭК/ФСБ, дублирование было избыточным.

Перестроена нормативная база терминологии: из раздела 2 убраны ГОСТ 34.003 и ГОСТ Р ИСО/МЭК 15408-3, добавлены ГОСТ Р 57580.3 (риск-менеджмент), ГОСТ Р 59853, ГОСТ Р 58833. Это отражает созревание семейства стандартов 57580.x как самостоятельной экосистемы.

Терминология риска последовательно переведена с «операционного риска, связанного с нарушением безопасности информации» на «риск реализации информационных угроз». Понятие согласовано с ГОСТ Р 57580.3 и явно увязывает стандарт с риск-ориентированным подходом ЦБ.

Введено право единого контура (п. 6.7): организация вправе применять один контур безопасности для всех своих объектов информатизации — за исключением объектов, для которых нормативными актами ЦБ предусмотрена обязательная раздельная оценка соответствия по ГОСТ Р 57580.2. Это снижает административную нагрузку для организаций с однородной инфраструктурой.

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

Контентный анализ (ПУИ.7) теперь явно требует применения в том числе к графическим файлам — сканам документов и снимкам экрана, которые содержат конфиденциальную информацию в растровом виде. Это означает требование к DLP-решениям поддерживать OCR в режиме контентного контроля.

Влияние изменений на участников рынка¶

Кредитные организации и системно значимые НФО¶

Для тех, кто уже работает с действующей редакцией на уровне 1 или 2, основная нагрузка — перестройка документации и расширение технического охвата:

Пересмотр ОРД по управлению уязвимостями: необходимо ввести классификацию по критичности (критические/высокие/средние/низкие), регламент нейтрализации и контроль исполнения. Организации, которые использовали CVSS и БДУ ФСТЭК де-факто, смогут легализовать существующие практики — стандарт теперь явно ссылается на эти источники.
Инвентаризация контейнерных сред: необходимо провести аудит использования Docker, containerd, Kubernetes и аналогов, включить объекты в реестр объектов информатизации, сформировать модель угроз для контейнерной инфраструктуры. Для организаций, уже внедривших контейнеры в продуктивные среды (а таких большинство крупных банков), это означает ретроспективный разрыв между фактическим состоянием и формальными требованиями.
Документирование выбора мер: существующие матрицы применимости мер, как правило, не содержат обязательного обоснования каждого исключения. Придётся переработать структуру внутренних документов по ЗИ.
DLP-системы: необходимо проверить поддержку OCR для контентного анализа графических файлов, а также расширить политики на контроль мессенджеров и средств ВКС как потенциальных каналов утечки.

Финтех-компании и операторы финансовых платформ¶

Для этой категории проект означает принципиально новый регуляторный периметр: они не были прямыми субъектами стандарта в 2017 году, теперь могут стать ими через нормативные акты ЦБ.

Необходимо отслеживать новые нормативные акты ЦБ, которые включат ссылку на данный стандарт для операторов финансовых платформ и профессиональных участников рынка.
Контейнерная инфраструктура, характерная для финтеха, с высокой вероятностью потребует существенной доработки: требования к изоляции пространств имён (ЗСВ.30), запрет привилегированных контейнеров (ЗСВ.15), встроенное сканирование образов (ЗСВ.41) — типовые пробелы для организаций, пришедших из DevOps-культуры.
Требования к удалённому доступу с обязательной МФА (ЗУД.7) и выделенным сегментом (ЗУД.12) затронут организации с распределёнными командами и BYOD-практиками.

Вендоры СЗИ¶

DLP-вендоры: требование контентного анализа графических файлов (OCR) переходит из категории «конкурентное преимущество» в категорию «базовое требование» для сертифицированных продуктов.
Поставщики решений для контейнеризации: меры ЗСВ.30, ЗСВ.31, ЗСВ.41 создают спрос на интегрированные решения класса CNAPP или отдельные продукты для управления безопасностью контейнеров с поддержкой отечественной нормативной базы.
MDM/UEM-вендоры: расширение области Процесса 8 на все устройства удалённого доступа, а не только мобильные, означает необходимость поддержки унифицированного управления разнородными устройствами в рамках единого решения.
Сканеры уязвимостей: явная ссылка на БДУ ФСТЭК (ЦЗИ.2) создаёт регуляторный стимул для интеграции с этой базой как обязательным источником, а не опциональным.

ГОСТ Р 57580.2¶

Переопределение независимости проверяющей организации¶

Это одно из наиболее значимых изменений для рынка аудита.

2018: Проверяющая организация должна быть независимой «от организаций, осуществлявших или осуществляющих оказание услуг проверяемой организации в области реализации информатизации и защиты информации (в части внедрения и/или сопровождения систем, средств, процессов информатизации и защиты информации)».

Проект: Формулировка принципиально сужена — конфликт интересов возникает только при оказании услуг «по поставке и пусконаладочной работе средств ЗИ, ресурсов доступа или объектов доступа за период проведения проверки и входящих в область оценки».

Практические последствия:

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

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

Новый термин «полнота реализации» и его влияние на оценку 0/1¶

В действующей редакции оценка выбора мер (E_МЗИ) принимает значения 0 или 1, а критерии их присвоения не раскрыты — вопрос трактовки фактически оставался на усмотрение проверяющей группы.

Проект вводит в раздел 3 новый термин:

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

Одновременно в п. 6.10.1 расширены основания для выставления оценки «0»:

Редакция 2018

Проект

«не выбрана при отсутствии у проверяемой организации свидетельств выбора»

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

«выбрана при предъявлении проверяемой организацией свидетельств выбора»

«выбрана при предъявлении свидетельств выбора в виде фактического применения»

Ключевое следствие этого простого наличия внутреннего документа с выбором меры теперь недостаточно для получения оценки «1». Требуется доказательство фактического применения — конфигурационные данные, журналы, результаты наблюдений. Это закрывает практику «бумажного» аудита, когда оценка выставлялась на основании приказов и регламентов без технической верификации.

Кроме того, добавлено требование к отчёту: «в отчёте о проведении оценки соответствия необходимо зафиксировать критерии выставления оценок» — отдельно для E_МЗИ, E_МОУ и E_МАС. Это требование к воспроизводимости результатов, которого в 2018 году не было.

Изменение формулы итоговой оценки¶

В редакции 2018 года итоговая оценка R вычисляется по формуле:

bc. R = (ΣE_i + E_AC) / (T+1) − 0,01·Z

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

В проекте логика изменена: если ЖЦ АС не оценивается, значение E_AC принимается равным нулю, а знаменатель остаётся T+1. Формально это понижает R в ситуациях, когда оценка ЖЦ исключена из области — организации теряют «бонус» от сокращения области оценки.

Второе изменение касается многоконтурных организаций. В 2018 году для случая нескольких контуров с разными уровнями ЗИ формулы агрегирования (9–12) применялись только к оценке процессов. В проекте аналогичный механизм агрегирования с теми же весовыми коэффициентами явно распространён и на E_AC, с добавлением формулы для случая одинаковых уровней ЗИ в нескольких контурах (среднее арифметическое). В 2018 году этот случай не был нормирован.

5. Расширение перечня нарушений ЗИ (Приложение Б)¶

Перечень нарушений (Приложение Б) влияет на итоговый R напрямую: каждый выявленный пункт снижает оценку на 0,01. В 2018 году перечень содержал 19 пунктов, проект добавляет 5 новых:

№	Новое нарушение
Б.20	Непроведение или некорректное проведение (без обоснования границ и модели угроз) тестирования на проникновение и анализа уязвимостей
Б.21	Отсутствие реализации требований к защите информации при осуществлении удалённого доступа
Б.22	Выявление на момент проверки фактов отсутствия реализации выбранных (запланированных к реализации) мер ЗИ (для каждой установленной меры)
Б.23	Несоблюдение порядка устранения (нейтрализации) уязвимостей критичного и высокого уровня
Б.24	Нарушение порядка выбора мер ЗИ, предусмотренного п. 6.3 ГОСТ Р 57580.1

Б.20 закрывает ситуацию формального проведения петеста без привязки к актуальной модели угроз и реальным границам области. Это прямо связано с требованиями нового Процесса 3 в 57580.1, где тестирование на проникновение стало явным элементом управления уязвимостями.

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

Б.23 прямо отражает переход 57580.1 к процессу управления уязвимостями с классификацией по критичности. Отсутствие своевременного патчинга критичных и высоких уязвимостей теперь снижает итоговый R.

Б.24 — нарушение методологии, а не технической реализации: если организация не задокументировала выбор мер с обоснованием исключений (как теперь требует п. 6.3 57580.1), это само по себе является зафиксированным нарушением.

Ужесточение требований к оформлению отчёта¶

Раздел 8 проекта содержит несколько существенных новшеств по сравнению с 2018 годом.

Электронная форма отчёта¶

В 2018 году отчёт оформлялся исключительно на бумажном носителе (прошивка нитью, печать, подписи). Проект допускает электронный отчёт, при условии:

формат, не допускающий редактирования (PDF/A или аналог);
подписание усиленной квалифицированной электронной подписью руководителя проверяющей организации и руководителя проверяющей группы;
обеспечение возможности проверки юридической значимости ЭП в течение не менее 5 лет.

Это практически значимое изменение: при дистанционных проверках или обмене с ЦБ электронная форма снимает логистические барьеры. Однако требование УКЭП добавляет инфраструктурные требования к проверяющим организациям.

Новые обязательные разделы отчёта¶

Добавлено два новых обязательных элемента содержания отчёта (п. 8.2):

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

Детализация обоснования компенсирующих мер¶

В 2018 году отчёт должен был содержать «обоснование применения компенсирующих мер» — без требований к содержанию этого обоснования. Проект устанавливает обязательный состав такого обоснования (п. 6.12):

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

Это требования, сопоставимые со структурой Risk Acceptance / Compensating Controls в международных стандартах (PCI DSS, ISO 27001). На практике это означает существенный рост трудоёмкости документирования каждой компенсирующей меры.

Форма листов для сбора свидетельств¶

В 2018 году форма листов (Приложение А) содержала 4 столбца: мера, источник свидетельств, ФИО предоставившего, подписи. В проекте добавлен отдельный столбец для ФИО и должности члена проверяющей группы — разделение подтверждения со стороны проверяемого и со стороны проверяющего. Незначительное изменение, но важное с точки зрения персональной ответственности членов проверяющей группы.

Влияние проверяющие организации¶

Наиболее ощутимые последствия новооведений:

Смягчение ограничений по независимости позволяет компаниям, ранее участвовавшим в проектах по внедрению СЗИ, претендовать на роль проверяющей организации при условии раскрытия этих фактов в отчёте. Для крупных системных интеграторов, имеющих аудиторские подразделения, это снимает часть прежних барьеров.
Обязательное раскрытие конфликтов интересов одновременно создаёт репутационный риск: заказчик ЦБ получит явную информацию о связях аудитора с проверяемой организацией.
Требование фиксировать критерии выставления оценок означает необходимость разработать и задокументировать внутренние методические стандарты оценки для каждой категории мер. Без этого результаты проверки технически не соответствуют новой редакции стандарта.
Электронный формат отчёта требует инфраструктуры УКЭП и процессов обеспечения долгосрочной верификации ЭП (не менее 5 лет).
Детализированное обоснование компенсирующих мер существенно увеличивает трудоёмкость оценки для организаций с нетиповыми ИТ-архитектурами.

Файлы (0)

Обновлено С. Антошкин 3 дня назад · 5 изменени(я, ий)