Четверг, 14:30. Сидим с аудитором в переговорной регионального банка - второй день оценки соответствия ГОСТ Р 57580. Аудитор открывает раздел «Управление доступом» и задаёт простой вопрос: «Покажите журнал пересмотра прав доступа за последний квартал». Тишина. ИТ-директор смотрит на CISO, CISO - на системного администратора. Журнала нет. Есть тикеты в Jira на предоставление доступа, но ни одного на пересмотр или отзыв. Итоговая оценка по блоку упала с 0.85 до 0.41 за час. Один пропущенный процесс - и весь блок в «частичном несоответствии».
Ситуация до боли знакомая: организации тратят месяцы на технические меры, а проваливаются на процессных. Ниже - разбор того, какие требования ИБ в финансовых организациях реально проверяются, где ломается соответствие и как перевести регуляторный язык в задачи для SOC и ИТ.
Карта регуляторных требований: кто кому должен
Первое, что делает CISO финансовой организации (или должен делать) - определяет, какие нормативные акты к нему применимы. Область действия зависит от типа лицензии, объёма операций и статуса значимости.| Тип организации | ГОСТ Р 57580.1 | Положение 683-П | Положение 719-П | PCI DSS | ФЗ-187 (КИИ) |
|---|---|---|---|---|---|
| Системно значимый банк | Усиленный (ур. 1) | Да | Да | При обработке карт | Да |
| Банк (не системно значимый) | Стандартный (ур. 2) | Да | Да | При обработке карт | По результатам категорирования |
| НФО (крупная страховая, НПФ) | Стандартный (ур. 2) | Нет (684-П) | Нет | При обработке карт | По результатам категорирования |
| Платёжный агрегатор (БПА) | Стандартный (ур. 2) | Нет (683-П - только для кредитных организаций) | Да (через статус БПА) | Да | По результатам категорирования |
Системно значимые кредитные организации обязаны реализовать усиленный уровень защиты (уровень 1) по ГОСТ Р 57580.1. Остальные кредитные организации - стандартный (уровень 2). Минимальный уровень (уровень 3) для кредитных организаций Положением 683-П не допускается - только стандартный или усиленный.
Момент, который русскоязычные обзоры стабильно упускают: положение 683-П Банк России и ГОСТ 57580 - не взаимозаменяемые документы. 683-П предъявляет требования организационного характера (ежегодный пентест, ОУД4, уведомление об инцидентах), а ГОСТ Р 57580.1 - детальный каталог технических и организационных мер. Положение 683-П ссылается на ГОСТ как на базис оценки соответствия, но добавляет обязательства поверх. Положение 719-П регулирует защиту информации при переводах денежных средств и распространяется на участников платёжной системы - его область действия пересекается с 683-П, но не совпадает полностью.
Если банк обрабатывает данные платёжных карт международных платёжных систем - параллельно применяется PCI DSS. По данным Dun & Bradstreet (август 2024), 75% европейских compliance-лидеров зафиксировали рост нагрузки на комплаенс на 35% за последний год, и финансовый сектор - в авангарде. Российский рынок не исключение: требования Банка России к информационной безопасности множатся, и задача CISO - не просто «соответствовать», а выстроить процесс, который закрывает несколько стандартов одновременно.
ГОСТ Р 57580 требования - что реально проверяет аудитор
Методика оценки и пороговые значения
ГОСТ Р 57580.1 определяет базовый состав мер, ГОСТ Р 57580.2 - методику оценки. Аудитор работает по 57580.2: каждая мера оценивается от 0 (не реализована) до 1 (полностью реализована), с промежуточными значениями 0.25, 0.5, 0.75.Итоговая оценка - взвешенная сумма по направлениям и процессам защиты информации. ГОСТ Р 57580.2 определяет пять уровней соответствия (от нулевого до четвёртого): четвёртый уровень - R ≥ 0.85, третий - 0.7 ≤ R < 0.85, второй - 0.5 ≤ R < 0.7 и т.д. Для усиленного уровня защиты (уровень 1) требуется четвёртый уровень соответствия (R ≥ 0.85), для стандартного (уровень 2) - не ниже третьего (R ≥ 0.7). Не дотянулись - пишете план remediation.
На практике это выглядит так: банк может закрыть 95% мер по антивирусной защите и управлению уязвимостями, но провалить логирование - и получить общее «частичное несоответствие». Опытные аудиторы это знают и целенаправленно идут в слабые блоки.
Пять процессов, где финансовые организации стабильно теряют баллы
По опыту участия в оценках соответствия ГОСТ Р 57580 - от региональных банков до системно значимых - пять процессов вызывают проблемы с завидной регулярностью:Управление доступом (процесс 7). Формальные политики существуют, но регулярный пересмотр прав не ведётся. Аудитор просит не политику, а журнал пересмотра с датой, ответственным и результатом. В терминах MITRE ATT&CK это покрытие техники Valid Accounts (T1078, Initial Access / Persistence) - избыточные или скомпрометированные учётные записи остаются активными месяцами. Типичная картина: сотрудник уволился полгода назад, а его аккаунт в АБС жив и здоров.
Регистрация событий безопасности (процесс 5). Логи собираются, но не централизованно. SIEM есть, правила корреляции - из коробки, без адаптации. Аудитор проверяет: логируются ли попытки неудачной аутентификации, изменения привилегий, доступ к критичным системам. Если SIEM собирает только Windows Event Log с контроллеров домена, а АБС и ДБО пишут в файл на локальном диске - оценка падает. И правильно падает: какой смысл в SIEM, если он видит половину инфраструктуры?
Управление инцидентами. Процедура есть в виде документа, но table-top exercises не проводились. Аудитор спрашивает: «Когда последний раз отрабатывали инцидент по плану?» Ответ «никогда» или «при внедрении два года назад» - оценка 0.25.
Защита от вредоносного кода. Антивирус установлен, но исключения из сканирования настроены слишком широко (каталоги АБС, базы данных). Нет контроля подключения съёмных носителей на АРМ операторов. Бухгалтер приносит флешку из дома - и никто об этом не узнаёт.
Управление уязвимостями. Сканирование проводится (MaxPatrol, Nessus), результаты не обрабатываются в рамках SLA. Отчёт на 200 страниц ложится в папку до следующего аудита. Аудитор проверяет: есть ли реестр выявленных уязвимостей, зафиксированы ли сроки устранения, закрыты ли критические из предыдущего отчёта. Спойлер: обычно нет.
PCI DSS соответствие банка: пересечение с ГОСТ 57580
Что закрывается одновременно, а что - нет
Для банков, обрабатывающих данные карт, PCI DSS сертификация применяется параллельно с оценкой соответствия ГОСТ Р 57580. Контроли частично пересекаются, но методология оценки принципиально отличается.| Область контроля | ГОСТ Р 57580.1 (процесс) | PCI DSS 4.0 (требование) | Что проверяется на практике |
|---|---|---|---|
| Сегментация сети | Процесс 3 (защита внутренних сетей) | Req 1 (Network Security Controls) | VLAN/firewall между CDE и общей сетью |
| Управление доступом | Процесс 7 | Req 7-8 (Access, Authentication) | MFA, парольная политика, пересмотр прав |
| Логирование | Процесс 5 | Req 10 (Log and Monitor) | Централизация логов, retention 12+ мес |
| Уязвимости | Процесс 6 | Req 6 (Secure Systems) | Сканирование, патч-менеджмент, ОУД4 |
| Шифрование | Процесс 4 | Req 3-4 (Protect Data) | Шифрование PAN, TLS, управление ключами |
| Тестирование | Требование 683-П | Req 11 (Test Security) | Пентест, ASV-сканирование |
Если банк прошёл PCI DSS сертификацию - значительная часть мер ГОСТ 57580.1 уровня 2 уже закрыта: сегментация, логирование, управление доступом. Но ГОСТ предъявляет дополнительные требования к документированию процессов, распределению ролей и организационным мерам, которых в PCI DSS нет в таком объёме. Проще говоря: PCI DSS спрашивает «сделано ли?», ГОСТ добавляет «а где бумага, что это делается регулярно?».
Обратная ситуация: организация, прошедшая оценку ГОСТ 57580 на уровень 2, частично покрывает требования PCI DSS, но без ASV-сканирования, специфических требований к CDE-сегментации и детальных правил работы с PAN (Primary Account Number). PCI DSS QSA-аудитор будет проверять именно эти зоны.
Положение 683-П и оценка соответствия: ОУД4 и уведомление об инцидентах
Анализ уязвимостей ПО по ОУД4
Положение 683-П Банк России обязывает кредитные организации проводить анализ уязвимостей прикладного ПО, используемого для приёма электронных сообщений клиентов (ДБО, мобильные приложения, личные кабинеты). Оценочный уровень доверия - не ниже ОУД4 по ГОСТ Р ИСО/МЭК 15408.ОУД4 предполагает методическую разработку с детальным проектированием, систематическое тестирование и формальный анализ архитектуры. На практике: организация привлекает лицензированную лабораторию ФСТЭК для анализа исходного кода, фаззинг-тестирования и оценки архитектуры ПО.
А вот тут начинается боль. Банк обновляет ДБО три раза в квартал, каждое обновление формально требует переоценки. Стоимость одной оценки сопоставима с небольшим пентест-проектом. Распространённая практика - оценка раз в год на стабильную версию, промежуточные релизы покрываются внутренним анализом уязвимостей. По документам подход спорный, но разъяснений ЦБ по частоте переоценки при итеративной разработке на момент написания нет. Так и живём.
Уведомление об инцидентах: сроки, форматы, ответственность
Требования Банка России к информационной безопасности и ФЗ-187 о безопасности КИИ формируют двойную обязанность по уведомлению:FinCERT (ЦБ) - уведомление о компьютерных инцидентах, связанных с переводами денежных средств без согласия клиента. Формат согласован с Банком России.
ГосСОПКА (НКЦКИ / ФСБ) - для субъектов КИИ. Сроки уведомления: 3 часа для значимых объектов КИИ, 24 часа для иных объектов субъектов КИИ (Приказ ФСБ №367).
Для SOC это означает: playbook'и настраиваются не только на detection и containment, но и на notification. Пропущенный срок уведомления - отдельное нарушение, которое фиксируется при проверке. Шаблон уведомления FinCERT должен быть заполнен и согласован заранее, а не составляться в 3 ночи, когда инцидент уже в разгаре и все бегают с горящими глазами.
От требований к detection: маппинг на MITRE ATT&CK и SIEM-правила
Главный gap русскоязычных материалов по комплаенсу информационной безопасности - отсутствие моста между регуляторным требованием и конкретным правилом детектирования. Все пишут «надо логировать», никто не пишет «что именно ловить». Ниже - маппинг требований ГОСТ 57580 и 683-П на техники MITRE ATT&CK с примерами того, что должен фиксировать SIEM.Чеклист подготовки к аудиту информационной безопасности банка
Готовый чеклист для передачи ИТ-подразделению и SOC перед оценкой соответствия ГОСТ Р 57580. Формат рассчитан на трекинг в Jira или Confluence.Управление доступом:
- Журнал пересмотра прав за последний квартал (дата, ответственный, результат)
- Реестр привилегированных учётных записей - актуализирован не позднее 30 дней
- MFA для удалённого доступа к критичным системам - подтверждение настройки
- Документ: порядок предоставления, изменения и отзыва прав доступа
- Сбор логов аутентификации со ВСЕХ систем в scope (АБС, ДБО, AD, VPN)
- Срок хранения - не менее установленного внутренней политикой (для совместимости с PCI DSS - 12 мес)
- Перечень правил корреляции в SIEM с привязкой к процессам ГОСТ 57580
- Журнал обработки алертов за последний месяц (кто, время реакции, результат)
- Документированная процедура реагирования
- Протокол последнего table-top exercise (дата, участники, выявленные пробелы)
- Шаблон уведомления FinCERT - заполнен и согласован
- Контактный лист эскалации - актуален, мобильные номера ответственных
- Отчёт сканирования (MaxPatrol / Nessus) с датой не позднее 30 дней
- Реестр уязвимостей с SLA: критические - 5 рабочих дней, высокие - 15, средние - 30
- Подтверждение устранения критических уязвимостей из предыдущего отчёта
- Заключение по анализу уязвимостей клиентского ПО ДБО
- Перечень ПО в scope: версии и даты последнего анализа
- Процедура change management - документирована и действует
За три года участия в оценках выполнения ГОСТ 57580 финансовыми организациями одна ошибка повторяется с упорством, достойным лучшего применения. Организации воспринимают оценку соответствия как экзамен, к которому нужно подготовиться за две недели до прихода аудитора. Мер в усиленном уровне - более 400. Закрыть их за две недели физически невозможно, и начинается бумажная косметика: политики пишутся задним числом, журналы пересмотра прав «восстанавливаются» по тикетам из Jira, протоколы table-top exercises оформляются по памяти. Аудиторы, которые прошли десяток проверок, видят это мгновенно - по датам в метаданных файлов, по отсутствию перекрёстных ссылок между документами. Не пытайтесь.
Работает один подход: compliance как процесс, не как проект. Ежеквартальный пересмотр прав - в календаре. Ежемесячный разбор алертов SIEM - в трекере задач. Полугодовой table-top exercise - в плане обучения. Когда аудитор приходит, ему показывают не специально подготовленную папку, а рабочий процесс. Разница в итоговом балле - 0.15-0.2 по блокам, а это часто означает разницу между «соответствует» и «частичное несоответствие».
И ещё один факт, о котором не говорят вслух: «частичное несоответствие» - не конец света. Это план remediation, сроки и повторная проверка. Регулятор ценит прозрачность выше идеальной картинки. Паника не оправдана, если есть работающий процесс с задокументированными пробелами и реалистичным планом их закрытия.
Если у вас другой SIEM-стек и нужно адаптировать Sigma-правила под требования ГОСТ 57580 - на codeby.net обсуждаем конкретные конфигурации и подходы к маппингу для разных платформ.
