Пока бизнес спит: как считать цену простоя ИТ-систем и выиграть время у кибератаки

Атака на инфраструктуру компании обычно начинается не в момент, когда все заметили. Она начинается на несколько часов раньше — ночью, пока никто не смотрит. К восьми утра сотрудники узнают о случившемся уже не от службы безопасности, а от того, что нельзя оформить заказ, склад не может отгрузить продукцию, а производство встало. 

Для пищевого предприятия час простоя ERP, WMS или других систем — это конкретная недополученная выручка, а иногда и штраф от сети или регулятора. На вебинаре Digital4food «ИТ-ландшафт под огнём: как выстроить процессы, чтобы управлять рисками и минимизировать потери» спикеры разложили этот риск по слоям:

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

Сколько стоит час простоя

Прежде чем говорить о защите, давайте посчитаем цифры. 

«Статистика по России за 2025 год: ущерб от кибератак — 1,5 трлн рублей, число инцидентов выросло в 2,5 раза, а план восстановления после сбоя есть только у 20% компаний. При этом у 45% компаний вообще нет опыта восстановления данных, а успешным оно оказывается лишь в 70% случаев — то есть в 30% восстановиться из резервной копии не получается», – Оганес Маргарян, руководитель отдела продаж «Константы»

Стоимость простоя складывается из четырёх составляющих: 

1. Потерянная выручка — это годовая выручка компании, делённая на количество рабочих часов в году и умноженная на длительность простоя. 
2. Потери производительности персонала — количество сотрудников, чья работа зависит от системы, умноженное на почасовую оплату с налогами и на время простоя — зарплата ведь начисляется, даже если люди не могут работать. 
3. Затраты на восстановление — работа своих и внешних специалистов, восстановление данных, замена оборудования и сверхурочные.
4. Косвенные потери — самые сложные для расчёта, но часто самые весомые: репутационный отток клиентов, штрафы по 152-ФЗ и 187-ФЗ, отложенный эффект (часть клиентов после сбоя просто реже возвращается) и ошибки от перехода на ручной режим работы. 

Как использовать часы, которые у вас уже есть

Кибератака не разворачивается мгновенно: чтобы получить доступ к инфраструктуре, злоумышленнику нужны часы, а иногда дни и недели — это верно даже с использованием ИИ. Разворачивание шифровальщика по всей инфраструктуре после получения доступа тоже занимает часы, а не минуты. Посмотрим на условный таймлайн: 01:30 — поиск уязвимостей, 02:17 — компрометация, 03:10 — закрепление, 04:20 — разведка, 05:30 — движение по инфраструктуре, 06:40 — отключение критических систем, 08:00 — начало рабочего дня, 08:30 — бизнес видит последствия.

Если бы служба информационной безопасности работала в режиме мониторинга 24/7, атаку можно было бы обнаружить не в 08:00 вместе со всеми, а уже в 03:00 — то есть получить порядка пяти часов на реакцию до того, как злоумышленник захватит управление и начнёт разрушение. За 15 минут после обнаружения можно заблокировать скомпрометированную учётную запись, за 30 минут — изолировать сегмент сети, за час — сохранить работоспособность критической площадки, за два часа — перевести процессы на аварийный сценарий, а за четыре часа — избежать полной остановки бизнеса.

Сергей Васильев, директор по развитию бизнеса IST, сформулировал главную мысль этого блока так:

«Задача ИБ — не только отразить кибератаку, а локализовать её и замедлить продвижение злоумышленника, чтобы бизнес успел перестроиться, а IT — сохранить максимум ресурсов. Поэтому реагирование должно идти не последовательно («сначала ИБ отбивается, потом бизнес разгребает»), а параллельно, по трём контурам сразу: 

1. ИБ сдерживает атаку и определяет, какие сегменты изолировать, 
2. IT сохраняет и восстанавливает системы, 
3. бизнес или производство запускает план обеспечения непрерывности и продолжает операционную деятельность — вручную, если нужно». 

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

Думаете, «прилететь» может только извне?

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

Подробно о том, каким образом снизить вероятность простоя систем по внутренним причинам, также подробно рассказали спикеры вебинара — руководитель департамента разработки компании Константа Ирина Правская и технический директор компании DTT Валерий Немцов.

Запись вебинара «ИТ-ландшафт под огнём: как выстроить процессы, чтобы управлять рисками и минимизировать потери» можно посмотреть на наших ресурсах: ВКонтакте, RuTube, YouTube.