Как ГОСТ Р 57580.1 помогает нефинансовым организациям: защита без лишних трат и бумажной волокиты
ENG
Перейти в Дзен
Мнение, Технологии

Как ГОСТ Р 57580.1 помогает нефинансовым организациям: защита без лишних трат и бумажной волокиты

Дарья Жерлица

Дарья Жерлица

Эксперт по информационной безопасности «Сайбер Бизнес Консалтинг»

Российский рынок информационной безопасности по итогам 2025 года превысил 400 млрд рублей, увеличившись, по оценке TAdviser, на 20–25%. При этом совокупный объём ИТ-рынка, по данным «Квадранта Технологий», впервые за два года показал отрицательную динамику: минус 3%, снизившись до 3 трлн рублей. Компании тратят на киберзащиту всё больше средств, но без хорошо выстроенной системы эти расходы не складываются в эффективно работающий механизм.

Изображение от freepik

Давайте порассуждаем о том, как выстроить защиту по стандарту Банка России ГОСТ Р 57580.1, даже если вы — не банк. Поговорим о том, как и какие уровни защиты необходимо выбрать, как убедиться, что бюджет не потрачен впустую, и зачем нефинансовым компаниям следовать правилам, разработанным для банков, — то есть сосредоточимся на вопросах, которые приходится решать каждому второму заказчику в области ИБ.

Почему банковский стандарт вышел за рамки банков

ГОСТ Р 57580.1 создавался для кредитных и некредитных финансовых организаций и содержит 408 организационных и технических мер защиты. Для банков поэтапное выполнение требований стандарта стало обязательным ещё в 2021 году, это проверяет Банк России. Для всех остальных компаний документ носит рекомендательный характер.

Правда, ситуация меняется. В ноябре 2025 года Банк России разослал финансовым организациям письма, обязывающие требовать от поставщиков ИТ- и ИБ-услуг соответствия стандарту ГОСТ 57580.1, а в феврале 2026-го уже были проведены первые проверки крупнейших финансовых организаций. Это значит, что облачные провайдеры, интеграторы, дата-центры и внешние службы техподдержки, чтобы не потерять заказчиков, теперь вынуждены соответствовать этим банковским требованиям. По данным AKTIV.CONSULTING, крупнейшие отечественные облачные провайдеры уже превентивно прошли сертификацию.

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

Минимальный уровень защиты не спасает

Стандарт описывает три уровня защиты: минимальный, стандартный и усиленный. Разница между ними — в том, организованы ли вокруг инструментов управляемые процессы.

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

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

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

Усиленный уровень добавляет ещё один слой защиты — непрерывный мониторинг и быстрое реагирование на инциденты в режиме реального времени.

Четыре шага, которые превращают защиту из простого набора инструментов в эффективную систему

В основе стандарта лежит цикл Деминга — PDCA (Plan-Do-Check-Act): планируй, делай, проверяй, совершенствуй. Это не абстрактная схема, а рабочий инструмент, который помогает избежать типичных ошибок.

Планируй

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

Делай

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

Проверяй

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

Совершенствуй

Четвёртая ошибка — считать внедрение средств защиты разовой задачей. Внешние угрозы меняются быстрее, чем регуляторные требования, так что компания, которая не корректирует свои меры защиты с учётом возникающих рисков, через год оказывается с системой, защищающей только от прошлогодних угроз.

Отдельная важная задача — бесперебойность

Параллельно с ГОСТ 57580.1 существует ГОСТ 57580.4 — стандарт обеспечения операционной надёжности. Если первый описывает, как защитить данные, то второй — как добиться, чтобы при атаке или сбое бизнес не останавливался.

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

Стандарт учит выделять «критичные активы» и управлять их жизненным циклом. Он описывает, какие именно системы и компоненты обеспечивают работу бизнеса, контролируя изменения и проводя регулярные тесты на проникновение. Компании, которые внедряют практику «легального взлома», имеют все шансы закрыть обнаруженные уязвимости до того, как ими воспользуются злоумышленники. Регулярность таких проверок можно установить, ориентируясь на банковские практики, где оценку соответствия стандарту, согласно Положению Банка России № 683-П, проходят не реже одного раза в два года, а тесты на проникновение — ежегодно. Это особенно важно при подключении к финансовым информационным системам — там такая периодичность становится обязательной.

Что является самым важным для компаний вне финансового сектора

ГОСТ Р 57580.1 следует воспринимать не как нормативную нагрузку на бизнес, а как каталог лучших практик, который позволяет вам не заниматься изобретением велосипеда. Вот три шага, с которых стоит начать работу по укреплению киберзащиты вашей компании.

  1. Провести инвентаризацию активов и определить, что именно критично для бизнеса. Без этого выбор мер защиты превращается в гадание на кофейной гуще.
  2. Реализовать стандартный уровень защиты, который включает управление инцидентами и мониторинг. Минимальный уровень не даёт видимости атак, а усиленный — избыточен для большинства компаний, которые не относятся к КИИ.
  3. Встроить проверку эффективности киберзащиты в регулярные бизнес-процессы. Тот язык, на котором ИБ разговаривает с бизнесом, — это метрики времени реакции на инциденты, их частота, а также результаты тестов на проникновение. Без таких метрик бюджет на информационную безопасность рискует быть потраченным впустую.

Вступивший в силу в марте 2026 года для государственных информационных систем приказ ФСТЭК №117 также требует доказательств эффективности принятых мер, а не только факта их наличия. ГОСТ 57580.1 описывает методологию сбора таких доказательств, и, на наш взгляд, это как раз тот случай, когда регуляторные требования разных ведомств чётко работают в одном направлении на повышение устойчивости бизнеса.

Следите за нашими новостями в удобном формате
Перейти в Дзен

Предыдущая статьяСледующая статья