ГОСТ 57580.1 в банках. Почему внедрение не заканчивается?

2 часа назад

© freepik.com / AI-контент

Сторож Алексей, ведущий консультант AKTIV.CONSULTING в финансовой отрасли, за несколько лет провел более 20-ти аудитов, после чего поделился знаниями в своей статье на habr.com и рассказал о стандарте, который существует уже немало лет, а именно о том, для кого и почему ГОСТ 57580.1 вновь скоро станет актуален, а также глубоко проанализировал сами требования к управлению и обеспечению информационной безопасности (ИБ). Приводим основные аспекты из статьи Алексея Сторож.

ГОСТ 57580.1 по безопасности финансовых операций действует с 2017 года, но его продолжают «внедрять», потому что это не разовая настройка, а живая система защиты, которая меняется вместе с инфраструктурой и людьми. Даже если банк в какой-то момент привел контур к требованиям, через год появляются новые сервисы, интеграции, подрядчики, меняются правила доступа и границы систем — и соответствие приходится подтверждать заново, причем не на бумаге, а по факту работоспособности мер.

Главный двигатель «вечного внедрения» — постоянные изменения ИТ-ландшафта. Банки запускают новые каналы обслуживания, расширяют API, переходят на виртуализацию, перестраивают удаленную работу. Любая модернизация затрагивает основы защиты: доступы, сегментацию, журналирование, контроль изменений. Поэтому ГОСТ обычно не «внедряют заново», а регулярно актуализируют: уточняют, что относится к контуру финансовых операций, пересматривают границы систем и обновляют доказательства, что меры реально применяются там, где должны.

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

Третья причина — ГОСТ во многом про эксплуатацию и процессы, а не про покупку решений. Технические средства можно развернуть, но стандарт предполагает устойчивую модель: роли и ответственность, регулярные проверки, обучение, контроль изменений и корректирующие действия. Если это не встроено в ежедневную работу, защита деградирует: инвентаризация устаревает, права доступа разрастаются, события безопасности не анализируются системно, и организации приходится возвращаться к требованиям и «поднимать» то, что должно было жить в режиме постоянной эксплуатации.

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

Дополнительный фактор последних лет — подрядчики и цепочка поставок. Все больше сервисов и инфраструктуры уходит наружу: облака, дата-центры, внешняя поддержка, интеграторы, телеком, резервное копирование, SOC как сервис. Внешний контур становится частью модели риска, и при смене поставщиков или условий обслуживания соответствие приходится подтверждать заново. Параллельно развиваются связанные стандарты по киберустойчивости и операционной надежности (например, ГОСТ Р 57580.3-2022 и 57580.4-2022), расширяя практики управления рисками, восстановления и работы с поставщиками, поэтому «закрыть» тему одним проектом все сложнее.

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

Ранее RUБЕЖ cообщал, что российские банки сократили ИТ- и ИБ-аутсорсинг