Деньги — универсальный язык

Сколько бы CISO ни говорили топ-менеджменту про уязвимости, устаревшие системы, 0-day-атаки и APT-группировки, как правило, все это вызывает лишь сдержанное и молчаливое понимание. Но стоит рассказать о реальных инцидентах с известными потерями, а затем провести аналогию с собственными продуктами («Мы можем потерять 1,5 млрд руб. за 48 часов простоя») — и сразу появляется дискурс для обсуждения как бюджета ИБ, так и кросс-функциональных задач по повышению киберустойчивости компании.

Так происходит не потому, что менеджмент не понимает значимости безопасности — ИБ-риски уже несколько лет стабильно входят в топ-3 приоритетов современного CEO. Просто он мыслит иначе: для бизнеса риск — это про деньги, выручку, клиентов, затраты, EBITDA или репутацию (которая тоже считается через деньги).

Многие CISO и руководители ИБ-служб застревают где-то посередине: вроде уже не чистые технари, но и до полноценного места за столом, где говорят на языке финансов и бизнес-метрик, пока не дошли. И это проблема... Поэтому так важно использовать в качестве моста для диалога именно экономику реальных и потенциальных инцидентов. Не идеальный, не всегда удобный, но вполне рабочий вариант.

Экономика киберинцидента

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

Динамика тоже важна: ущерб растет нелинейно, с резким ускорением в активной фазе и длинным хвостом последствий (что требует раздельного учета для исключения системного занижения оценки). Такая структура позволяет связать технические метрики с финансовыми показателями, определить точки управленческого воздействия и обосновать инвестиции.

Давайте рассмотрим основные фазы инцидента.

1. До обнаружения

На этом этапе злоумышленники проводят разведку, подготовку, закрепление и крадут учетные данные. Ущерб зачастую минимален или почти незаметен, тем не менее эта фаза важна для оценки масштаба инцидента и моделирования предотвращенного ущерба (в случае раннего обнаружения атаки). Здесь важно показать, что раннее обнаружение позволяет значительно снизить ущерб. 

2. Активная фаза

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

Технически инцидент может быть связан с разными видами кибератак, например:

• недоступность сервисов в результате DDoS-атаки;
• шифрование или удаление данных (ransomware/APT-атаки);
• компрометация учетных записей сотрудников или клиентов;
• публикация утечки данных.

Влияние на бизнес также может быть выражено в разных формах:

• нарушение или полная недоступность пользовательских сценариев;
• приостановка или отмена транзакций и платежей;
• нарушение различных SLA;
• деградация техподдержки из-за нагрузки или отсутствия релевантных сценариев.

Активная фаза достаточно проста с точки зрения оценки, поскольку в основном несет прямые потери:

• потери выручки: легко оценить в отклонениях от нормального сценария «неделя к неделе» или «месяц к месяцу»;
• затраты на реагирование: сверхурочные часы для ИТ-, ИБ- и бизнес-подразделений, привлечение внешней экспертизы (например, форензика), подрядчиков или перенаправление пользователей на резервные площадки.

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

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

Примеры базовых метрик:

• AR/ARPU — средний доход на пользователя.
  • Если известен ARPU за месяц, то в случае деградации сервиса на протяжении шести часов для 2000 пользователей, ущерб составит:
    Ущерб = ARPU/730 (ср. количество часов в месяце) * 6 (часов недоступности) * 2000 (затронутых инцидентом пользователей).
    Обычно ARPU считается как интегрированный показатель и не разбивается по сервисам. В этом случае можно либо брать показатель «как есть» (считая, что сервисы сильно связаны и потери суммируются), либо вводить экспертный коэффициент для каждого продукта/сервиса в границах инцидента.
• Валовая маржа — выручка за вычетом себестоимости.
  • Не все сервисы одинаково маржинальны, некоторые не приносят прибыли — это нужно учитывать при подсчете ущерба.

3. Восстановление 

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

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

С точки зрения оценки данный этап прозрачен, поскольку основная часть затрат носит прямой характер. Главное здесь — полнота учета.

4. Постинцидент

Фаза, о которой часто забывают: она может длиться месяцами или даже годами и сложнее всего поддается оценке. Что происходит после того, как инцидент купирован, а все сервисы восстановлены? Компания сталкивается с разнообразными последствиями, например:

• отток клиентов (рассчитывается как дельта от базы);
• снижение NPS (влияет на метрику стоимости привлечения и удержания клиента);
• выплата компенсаций (зависит от ущерба клиентам, но при большом числе пострадавших даже небольшая компенсация каждому приводит к значительным расходам);
• штрафы и судебные издержки;
• и многое другое (например, затраты на маркетинг, скидки, рост страхования и стоимости кредитования и т. д.).

Потери на этом этапе могут быть больше, чем все остальные вместе взятые.

Модель ущерба и расчет

Для примера представим среднюю телеком-компанию, столкнувшуюся с шифровальщиком, что привело к частичной остановке биллинга.

Входные данные:

• Выручка в день: 100 млн руб.
• Доля затронутых сервисов: 30%.
• Длительность простоя: 2 дня. 

А теперь считаем...

Прямые потери:

• 100 млн × 30% × 2 дня = 60 млн руб. (потери выручки).

Реагирование:

• Подрядчики: 15 млн руб. (форензика, реагирование, анализ защищенности).
• Внутренние ресурсы: 25 млн руб. (оплата переработок ИТ-, ИБ- и бизнес-подразделений).

Итого: 40 млн руб.

Пост-инцидент:

• Отток клиентов (1% базы): 300 млн руб. (в годовом выражении).
• Рост стоимости привлечения: 100 млн руб.

Итого: 400 млн руб.

Общий ущерб:

~ 500 млн руб.

Отмечу, что я описал довольно оптимистичный сценарий — без регуляторных штрафов, утечек данных и с достаточно быстрым восстановлением (что говорит о высокой зрелости ИТ-процессов в компании).