Блог

Рост требований к кибербезопасности

2025-11-28 15:01

Почему бизнес вдруг «проснулся» по части кибербезопасности

Фраза «кибербезопасность — задача не только айтишников, но и бизнеса» звучит уже лет десять. Но только к 2024–2025 году она стала не лозунгом, а реальностью.
Сразу несколько факторов сошлись в одной точке:
  • регуляторы ужесточили правила (NIS2 в ЕС, обновления 187-ФЗ и подзаконки в РФ, отраслевые приказы ФСТЭК и Банка России);
  • инвесторы и страховщики начали смотреть на киберриски так же серьёзно, как на финансовые показатели;
  • кибератаки стали бить не только по данным, но и по физической инфраструктуре, останавливая заводы, логистику, энергетику;
  • внутри компаний вырос запрос на предсказуемость: бизнесу нужен не «нулевой риск» (его не бывает), а понятные правила игры и подтверждённая устойчивость.
Результат — требования к кибербезопасности перестали быть «рекомендациями» и всё чаще превращаются в жёсткие обязательства с персональной ответственностью руководства.
И это уже не только про НАТО, ЕС или США. Россия, страны СНГ, Азия — везде появляются свои аналоги NIS2, DORA, законов о защите критической инфраструктуры.

Регуляторы: от «best effort» к «обязан и ответишь лично»

Если раньше формулировка звучала как «организация должна предпринимать разумные меры по защите», то сейчас логика такая:
  • обязан иметь формализованный риск-ориентированный подход — от реестра активов до моделей угроз;
  • обязан внедрить набор минимальных мер (управление уязвимостями, журналирование, резервное копирование, управление доступом, обучение персонала, план реагирования и восстановления);
  • обязан отчитываться об инцидентах в жёсткие сроки и в конкретные органы;
  • руководство несёт персональную ответственность — от штрафов до запрета занимать руководящие должности (эта логика уже работает в рамках NIS2 и постепенно просачивается в национальные подходы).
В ЕС NIS2 распространяется не только на классическую «критическую инфраструктуру», но и на:
  • цифровую инфраструктуру;
  • производство важной продукции;
  • поставщиков управляемых услуг (в том числе облачных, MSP/MSSP).
Важно: требования распространяются и на компании вне ЕС, если они оказывают услуги внутри Союза. Аналогичный вектор есть и в других регионах: если ты в цепочке поставок — будь добр, соответствуй.
В России тренд схожий: расширяется перечень значимых объектов КИИ, усиливается контроль со стороны регуляторов, под требования попадает всё больше ИТ- и промышленных систем, которые раньше жили «в тени».

Почему ИБ перестала быть «файрволом и антивирусом»

Раньше вопросы кибербезопасности сводились к трём вещам:
  1. «У нас стоит антивирус»
  2. «У нас есть фаервол»
  3. «Мы никому не говорим наши пароли»
В 2025-м этого даже формально недостаточно.
Требования идут по нескольким линиям:

1. Управление жизненным циклом

От проектирования до вывода из эксплуатации. Стандарты вроде IEC 62443 и ISO 27001 требуют, чтобы безопасность учитывалась на всех этапах:
  • при выборе архитектуры;
  • при разработке ПО (DevSecOps, безопасная разработка);
  • при эксплуатации (патчи, управление уязвимостями, контроль изменений);
  • при выводе системы из эксплуатации (чтобы данные не «утекли» вместе со списанной железкой).

2. Supply chain security — безопасность цепочек поставок

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

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

Появляются требования по типу:
  • внутренний мониторинг сетевого трафика (пример — INSM в энергетике ЕС);
  • обязательные журналы событий и их хранение;
  • XDR/SIEM/SOC не как «хотелка», а как обязательный элемент для определённых категорий компаний.
Идея простая: если ты не видишь, что происходит в сети и на конечных точках — ты не выполняешь минимальный уровень киберустойчивости.

Давление со стороны инвесторов, страховщиков и клиентов

Раньше основной мотив внедрять ИБ был «regulatory driven» — «так требует закон/отраслевой регулятор».
Теперь к требованиям государства добавились три новых игрока:

1. Инвесторы и акционеры

Крупные фонды и банки всё чаще оценивают киберриски как часть ESG-повестки и операционной устойчивости. Вопросы типа:
  • есть ли у компании формализованная стратегия кибербезопасности;
  • как быстро вы можете восстановиться после инцидента;
  • проводите ли вы киберучения;
  • есть ли независимая оценка (аудит, сертификация по ISO 27001 и т.п.).
Это не просто любопытство. От ответов зависит стоимость капитала и решения о долгосрочных инвестициях.

2. Страховые компании

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

3. Клиенты и партнёры

В договорах всё чаще появляются требования уровня:
  • «подрядчик обязан соответствовать ISO 27001 / NIS2 / отраслевым стандартам»;
  • «подрядчик обязан уведомлять о киберинцидентах в течение N часов»;
  • «подрядчик обязан пройти аудит ИБ по чек-листу заказчика до начала работ».
По сути, требования к кибербезопасности становятся пропуском в цепочку поставок. Если компания не готова — её просто не пустят к серьёзным проектам.

Технологический ответ: Zero Trust, XDR и безопасная разработка

Повышение требований — это не только про бумагу. Без технологической базы они невыполнимы.

Zero Trust

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

XDR, SIEM, SOC

Когда в требованиях пишут «организация обязана обеспечивать мониторинг и регистрацию событий ИБ», это автоматически приводит к:
  • внедрению централизованного логирования;
  • использованию SIEM/XDR для корреляции событий;
  • созданию или аутсорсингу SOC (Security Operations Centre).
Не обязательно строить гигантский центр. Но отсутствие управляемого процесса мониторинга и реагирования всё чаще расценивается как невыполнение базовых требований.

Безопасная разработка (DevSecOps)

Особенно жёстко требования растут там, где компания сама разрабатывает продукты и сервисы:
  • регуляторы и клиенты ожидают secure by design;
  • нужны процессы SAST/DAST, SCA (анализ опенсорс-компонент);
  • требуется управление уязвимостями по всему стэку.
В 2025 году уже редко спрашивают «у вас есть безопасная разработка?». Гораздо чаще — «как именно вы это делаете?» и «покажите, пожалуйста, результаты».

Рост требований в промышленности и OT

Отдельный пласт — кибербезопасность промышленной автоматизации (OT, АСУ ТП).
Здесь к общим требованиям добавляются отраслевые:
  • IEC 62443 (кибербезопасность АСУ ТП);
  • национальные стандарты и ГОСТ Р в сфере автоматизации;
  • требования к объектам КИИ и отраслевые регламенты (энергетика, транспорт, связь).
Ключевые сдвиги:
  • подключение АСУ ТП к IT-сетям и облакам сделало их полноправной частью поля киберугроз;
  • регуляторы требуют разделения IT и OT-сетей, зон безопасности, контроля удалённого доступа;
  • для оборудования всё чаще запрашивают сертификацию по кибербезопасности, а не только по электробезопасности и помехоустойчивости.
Характерный пример подхода — современные решения уровня MasterSCADA 4D + ПЛК СТАБУР: поддержка шифрования, аутентификации, централизованного управления правами, журналирования действий. Это уже не «приятные бонусы», а ответ на конкретные регуляторные и отраслевые требования.

Киберустойчивость вместо иллюзии «полной защиты»

Ещё один важный сдвиг в требованиях: от «надо защититься от всех атак» к «надо уметь жить даже под атаками».
Регуляторы, инвесторы и клиенты всё чаще спрашивают:
  • как быстро вы выявляете инцидент;
  • сколько времени нужно на локализацию;
  • как быстро можете восстановить критичные сервисы;
  • проводите ли вы киберучения и отрабатываете ли сценарии «частично недоступной инфраструктуры».
То есть в требования входит бизнес-непрерывность (BCP/DRP) как часть кибербезопасности. Просто фаервол и антивирус проблему уже не решают.

Что это всё означает для инженерной и промышленной компании

Если свести рост требований к практическим шагам, получится вполне конкретный список.
Компаниям приходится:
  • формировать формальные политики и процессы ИБ (не только «добрые практики»);
  • назначать ответственных на уровне руководства, включать ИБ в повестку совета директоров;
  • внедрять минимум технических средств: сегментация, MFA, резервное копирование, мониторинг;
  • учитывать требования к ИБ при выборе оборудования (ПЛК, SCADA, сети, панели оператора);
  • доказывать соответствие — аудитами, сертификацией, отчётами.
Да, это затраты. Да, это бумага. Но в 2025-м стало очевидно: отсутствие формализованной кибербезопасности стоит дороже. И не только из-за штрафов, но и из-за потери контрактов, партнёров и доверия рынка.