Олег Гомазков: «Если пожара не было пять лет, это не значит, что можно уволить пожарных»
О том, как CFO считает киберриски, какие расходы на ИБ нельзя сокращать даже в кризис, как оценивать стоимость бездействия и унаследованные риски при M&A, а также почему соблюдение требований еще не означает защищенность, IT-World поговорил с Олегом Гомазковым.
За 15+ лет в CFO-позициях вы прошли через несколько экономических циклов. Как, на ваш взгляд, меняется подход к защите бюджета на кибербезопасность в кризис и в период роста - и какие ИБ-инвестиции вы считаете недопустимым сокращать даже при жестком дефиците бюджета?
В период роста разумный режим финансирования ИБ — это режим инвестиций. Покупаются тяжелые платформенные решения (SIEM, XDR), финансируются архитектурные перестройки, обучение. Бюджет растет опережающими темпами, а его защита производится через метрику Time-to-Market: задержка на месяц из-за недостаточной автоматизации ИБ-проверок обойдется бизнесу куда дороже, чем сама автоматизация.
В кризис логика меняется кардинально. CFO должен сократить затраты ради ликвидности. Но полностью сокращать затраты на ИБ смертельно опасно - нужна переориентация на режим «оптимальной достаточности».
В кризис первое правило простое. Нужно отказаться от абстрактных рисков типа «нас могут взломать». Каждая строка бюджета защищается через TCOR (Total Cost of Risk) и величину прямого финансового ущерба. Вопрос ставится жестко. Если мы отключим эту подписку сегодня, через сколько дней остановится наш процессинг или склад и сколько миллионов чистой прибыли мы потеряем в первые сутки простоя?
Второй принцип касается долгосрочных проектов. Их можно заморозить, а при необходимости перевести бюджет в сервисную модель (MSSP) для помесячной оплаты из операционного потока (OpEx) только за то, что реально защищает бизнес сейчас.
Три статьи расходов я бы всё же не трогал.
Threat Intelligence и сигнатурные обновления (патчи). Новые уязвимости появляются ежедневно. Экономия здесь означает накопление цепочки эксплойтов, которая рано или поздно пробьет периметр.
Резервное копирование и восстановление. Инфраструктура бэкапов - вопрос выживания. В кризис инцидент ИБ плюс потеря данных могут реально обнулить весь бизнес за часы.
Ключевой инженерный костяк. Можно урезать консультантов, отменить обучение, заморозить наем. Но нельзя снижать зарплаты архитекторам, которые знают все нюансы вашей системы. Если они уходят в разгар кризиса, восстановление при инциденте может стать невероятно сложным, а замена на рынке будет стоить в разы больше.
Когда CISO и CFO обосновывают один и тот же бюджет, они обычно апеллируют к разным категориям риска - операционному и финансовому. В чем, по вашему опыту, конфликт этих логик и как его снять на уровне совета директоров?
Конфликт между CISO и CFO — это не конфликт людей, это архитектурный конфликт двух разных языков.
Как правило, CISO думает бинарно: «система либо защищена, либо нет». Он видит дыры в защите и говорит: «Если не закроем, нас взломают». Вполне логично.
CFO оперирует категориями эффективности использования капитала, окупаемости и альтернативных издержек. Для него ИБ-бюджет — это безвозвратное изъятие денег из оборотного капитала, которое снижает маржинальность бизнеса прямо сейчас.
На совете директоров CISO — параноик, CFO — циник, готовый рискнуть жизнеспособностью компании ради красивого отчета.
Чтобы снять это противоречие и защитить бюджет на совете директоров, необходимо перевести операционные риски ИБ на единственный язык, который понимает бизнес, - язык денег.
На практике я бы сделал три вещи.
Сначала нужно монетизировать операционный простой. CISO перестает говорить о взломах и начинает говорить о цене часа простоя ключевого процесса. Если падает биллинг, компания теряет 5 млн упущенной выручки в час, плюс 1 млн рублей штрафов от регулятора, плюс 500 тыс. рублей на оплату простоя сотрудников. SLE (цена одного удара) = 6,5 млн рублей/час. Теперь это финансовая метрика, которую понимает CFO.
Дальше стоит перейти к матрице TCOR (Total Cost of Risk) вместо абстрактного ROI. На совет директоров выносится прозрачная математика. «Ожидаемые годовые потери при текущей защите - 20 млн рублей. Новое решение стоит 5 млн рублей в год и снижает риск до минимума. Чистая выгода - сбережение 15 млн рублей».
Третий шаг заключается в разделении бюджета на две несвязанные корзины. Корзина А («право на жизнь») — это расходы, без которых компания может остановить свою деятельность (например, КИИ, соблюдение лицензионных требований). Этот бюджет не обсуждается с точки зрения рентабельности, CFO просто акцептует его как неизбежный OpEx. Корзина Б («управление рисками») - затраты, которые оцениваются через формулу экономической целесообразности (модифицированный NPV > 1).
Конфликт исчезает, как только CISO говорит не «нас могут взломать», а «я предлагаю застраховать 50 млн возможного убытка за 5 млн инвестиций, вот расчет вероятности». В этот момент CFO из оппонента превращается в союзника.
ROSI как формула хорошо работает на бумаге, но на практике упирается в оценку вероятности инцидента. Какую модель вы используете для калибровки вероятности, если у компании нет собственной статистики инцидентов - экспертные оценки, отраслевые бенчмарки, актуарные таблицы?
Формула ROSI разбивается, как только финансисты требуют обосновать переменную вероятности (ARO). Например, почему шанс взлома составляет именно 20%, а не 5%. Чтобы ответить обоснованно и оставить эту строку бюджета нетронутой, можно использовать комбинированную модель с тремя жесткими фильтрами.
Сначала смотрим на отраслевые показатели. Не придумываем вероятность. Берем статистику киберстраховщиков и отчеты ИБ-лабораторий (например, Positive Technologies, «Лаборатория Касперского»). Если в ритейле или финтехе 40% компаний сталкивались с шифровальщиками в прошлом году, базовая ARO для нас = 0,4 (атака раз в 2,5 года).
Затем калибруем ее по результатам пентеста. Базовая статистика — это «средняя температура». Чтобы адаптировать ее под вашу компанию, нужно применить инженерные метрики, полученные в ходе аудита. Мы берем результаты последнего теста на проникновение и оценку защищенности. Вероятность корректируется через повышающий или понижающий коэффициент K_инж.
При высоком риске K_инж = 1,5–2,0. Пентестеры проникли во внутреннюю сеть за 3 часа; на периметре висят незакрытые критические уязвимости (CVE уровня High/Critical); ушедший зарубежный софт остался без обновлений. Это значит, что ваша компания уязвимее, чем в среднем по рынку.
При контролируемом риске K_инж = 0,5–0,8. Периметр чист; настроена строгая двухфакторная аутентификация; критические патчи ставятся в течение 48 часов. Вы защищены лучше рынка.
Третья опора, FAIR-методология. Раскладываем вероятность на две компоненты.
TEF (Threat Event Frequency) показывает, как часто вас пытаются атаковать. Смотрим на логи сканирований портов и фишинговых писем.
Vulnerability показывает вероятность успеха при текущем уровне защиты.
В итоге формула получается такой:
ARO = базовая отраслевая × коэффициент уязвимости × коэффициент рынка
А можете показать такой расчет на цифрах?
Допустим, базовая отраслевая частота успешных атак ARO_базовая = 0,4.
Инженерный аудит показывает, что из-за отсутствия обновлений на NGFW коэффициент уязвимости K_инж = 1,5.
По прогнозам аналитиков коэффициент роста активности хакеров в этом году K_рынок = 1,2.
Тогда ARO_прогноз = 0,4 × 1,5 × 1,2 = 0,72 (72% вероятность инцидента в год, то есть 1 критический инцидент раз в 1,4 года).
С этой цифрой, подкрепленной пентест-отчетом и отраслевой статистикой, любой CFO согласится работать.
Если совет всё еще сомневается, применяем анализ чувствительности: показываем ROSI для трех сценариев (пессимистичный, реалистичный, консервативный). Если даже при консервативном ARO = 0,1 (атака раз в 10 лет) формула ROSI показывает эффективность > 1, у CFO не останется аргументов для отказа.
Если сравнивать risk-based подход с compliance-based - где проходит грань, после которой compliance-подход начинает маскировать реальную незащищенность?
Грань проходит в точке смены главного «клиента» департамента ИБ. Вместо внутреннего бизнеса им становится внешний аудитор или регулятор. Одновременно с этим рождается «бумажная безопасность».
Какие признаки показывают, что это уже «бумажная безопасность»?
Первый признак я бы назвал метрикой «наличие» вместо «качества». Risk-based подход оценивает через TCO и способность выдержать пиковую нагрузку. Compliance-подход останавливается на строчке в акте «система куплена и установлена». При этом система работает на 10%, правила не настроены, инженерам некогда в нее заглядывать.
Второй признак появляется, когда закупают под требования государства, а не под угрозы. В risk-based вы разворачиваете WAF, потому что интернет-магазин под постоянными сканированиями. В compliance вы покупаете сертифицированный софт, потому что компания подпадает под КИИ. Вендор выбирается не по стресс-тестам, а по наличию сертификатов.
Третий признак связан со слепотой к Shadow IT и человеческому фактору. В risk-based архитекторы видят, какими облаками пользуются разработчики, где хранят файлы. В compliance компания имеет идеальные, подписанные регламенты ИБ. Но они настолько жесткие и неудобные для реальной работы, что сотрудники начинают их массово обходить, пересылать коммерческие данные в личных мессенджерах или выгружать базы данных на незащищенные личные устройства. На бумаге - полный порядок, в реальности - критическая утечка данных.
Четвертый признак связан с отношением к пентестам. В risk-based тест на проникновение — это Red Team, которая нападает любой ценой. Цель - взломать систему, показать CFO цену простоя (SLE). В compliance пентест превращается в формальный аудит по чек-листу. Проверяющим показывают только идеальные участки сети, чтобы они быстро подписали отчет.
Совет видит зеленые отчеты о прохождении всех проверок и думает, что компания в безопасности. Но реальная атака бьет не по чек-листам регулятора. Хакеры ищут живые архитектурные ошибки, сырой код, необученный персонал. И когда находят, бумажная защита оказывается «мыльным пузырем», обходясь компании в колоссальные убытки.
Для меня правильная стратегия состоит в том, чтобы использовать compliance как нижнюю границу, а risk-management как надстройку. Правило простое. Мы обязаны выполнить требования государства (compliance), чтобы продолжить работу бизнеса. Но мы обязаны настроить и усилить эти системы, чтобы сохранить бизнес при реальной атаке (risk-based).
Можете привести пример из своей практики, когда перевод ИБ-риска в финансовые показатели изменил решение руководства или совета директоров по инвестициям в безопасность? Какие показатели оказались наиболее убедительными?
Таких примеров много, и в основном они однотипны. Но я заметил интересную тенденцию. Перевод ИБ-риска в финансовые показатели на протяжении последних 15 лет воспринимался бизнесом по-разному, от полного игнорирования («взломы - это где-то далеко и не про нас») до крайне внимательного изучения в последние годы. Самым понятным и принимаемым оказался «расчет цены одного удара». Вместо термина «взлом» рассчитывалась полная остановка основного бизнес-процесса (например, автоматизированной системы отгрузки) на 24 часа. В расчет входили три вещи.
Во-первых, прямые потери маржинальной прибыли от простоя.
Во-вторых, штрафы по контрактам перед контрагентами за срыв сроков.
И, наконец, в-третьих, фиксированные издержки на содержание простаивающего персонала и мощностей.
В итоге риск получал конкретную стоимость - например, десятки миллионов рублей за каждые сутки простоя. Вкупе с обоснованной вероятностью наступления события итоговая стоимость наглядно продемонстрировала, что внедрение новой системы защиты, включая скрытые расходы на инжиниринг и железо, в 3–4 раза ниже, чем ежегодный ущерб от потенциального простоя.
Когда бюджет режут и нужно выбирать между инвестициями - какой единый критерий сравнения вы используете?
Универсальный критерий — это модифицированный NPV на рубль инвестиций, или Risk-Adjusted Profitability Index (RAPI).
Этот показатель уравнивает «доходные» проекты бизнеса и «защитные» проекты ИБ/ИТ, переводя их в единую плоскость - сколько чистой стоимости компании приносит или сохраняет один вложенный рубль.
Для бизнес-проектов в числитель идет классический NPV - чистый приток реальных денег от проекта за 3 года. Для ИБ- и ИТ-проектов в числитель идет предотвращенный ущерб (ALE) - реальные деньги, которые компания гарантированно не потеряет на простоях, авариях и штрафах регуляторов за те же 3 года.
Можете показать, как RAPI работает на простом примере?
Допустим, есть дефицит в 10 млн рублей, а запросы на 30 млн. Маркетинговый проект требует 10 млн и дает NPV прибыли 15 млн, его RAPI составляет 1,5. Резервные копии требуют те же 10 млн, но ALE спасенных данных составляет 30 млн, поэтому RAPI равен 3,0. Логистический проект за 10 млн дает NPV экономии 11 млн и RAPI 1,1.
Проект Б имеет наивысший приоритет (RAPI = 3,0) - ценность сохранения бизнеса в кризис превосходит маржинальность новой рекламы. Проект В вычеркивается первым.
В кризис все проекты ранжируются по убыванию RAPI.
Единственное исключение, когда проект с низким RAPI принимается вне очереди, — это compliance: если отсутствие системы ведет к немедленному отзыву лицензии, приостановлению деятельности или уголовной ответственности. Во всех остальных случаях — это чистая математика RAPI.
Как вы считаете cost of inaction, если последствия (репутационные, регуляторные) плохо поддаются денежной оценке?
Плохо поддающиеся оценке последствия — это иллюзия. За ней скрывается нежелание копать до уровня бизнес-процессов. В корпоративных финансах все последствия имеют цену, потому что они влияют на кэшфлоу и ликвидность.
Я использую метод прокси-метрик и сценарный анализ.
Если начать с репутационного ущерба, какие прокси-метрики вы используете?
Сначала смотрим на коэффициент оттока клиентов. При утечке базы клиентов часть пользователей уходит к конкурентам. Берем худший кейс отрасли (3–5% оттока), умножаем на текущую базу и на LTV (пожизненную ценность клиента). Ущерб = база × 0,03 × LTV.
Затем на рост стоимости привлечения. После скандала привлекать новых клиентов дороже. Закладываем 20–30% увеличения стоимости на 6 месяцев восстановления.
Еще один маркер, ужесточение условий от поставщиков. Контрагенты требуют 100% предоплату вместо рассрочки. Считаем стоимость кассового разрыва, краткосрочного кредита или недополученных процентов от банковских депозитов.
А как вы раскладываете регуляторный риск?
Первый сценарий связан с прямым штрафом. Если выручка 10 млрд рублей, потенциальный штраф (1–3% за утечку ПДн) = 100–300 млн. Умножаем на ARO.
Второй сценарий связан с экстренным устранением предписаний. Если регулятор найдет нарушения, он не просто выпишет штраф, он выдаст предписание устранить их в жесткий срок (например, 30 дней). Оборудование и ПО придется покупать по завышенным ценам, а инженеры, скорее всего, будут работать по двойным тарифам. Стоимость бездействия = разница между плановым внедрением сейчас и экстренным по двойному тарифу потом.
Третий сценарий связан с приостановкой деятельности, отзывом лицензии или принудительной приостановкой работы сервиса регулятором до устранения уязвимостей. Цена = потеря выручки за каждый день запрета.
Из этих данных я собираю итоговый расчет cost of inaction. В нем не будет слова «репутация», только финансовые последствия для каждого сценария.
Когда совет директоров видит, что «абстрактный» регуляторный риск в критическом сценарии — это потеря конкретной прибыли из-за оттока, дискуссия о необходимости инвестиций в ИБ становится конструктивной.
При due diligence в сделках M&A какие 2–3 пункта в ИБ-профиле компании для вас критичны настолько, что могут повлиять на цену сделки или ее структуру?
Нужно смотреть на ИБ-профиль компании-цели не как на чек-лист, а как на источник скрытых обязательств и рисков обесценения актива.
Самый опасный риск состоит в том, что вы покупаете компанию, которая уже взломана. Ее интеллектуальная собственность слита, в инфраструктуре закрепились злоумышленники.
Проверять здесь нужно логи за 6–12 месяцев, искать бэкдоры и аномальную активность, смотреть даркнет на предмет утечек кода или баз данных.
Если это подтверждается, цена сделки может быть снижена. Также могут быть прописаны обязательства продавца компенсировать убытки, если риск реализуется после сделки.
Второй риск связан с регуляторной токсичностью. Жесткое законодательство (оборотные штрафы, требования КИИ, ЦБ) превращает это в финансовую бомбу.
Здесь проверяем соответствие требованиям ФСТЭК, ФСБ, ЦБ, 152-ФЗ, наличие аттестатов на КИИ и то, соблюдаются ли требования регуляторов реально или только на бумаге.
Для покупателя это означает незапланированный CapEx на приведение в соответствие сразу после сделки. Сумма потенциального оборотного штрафа (1–3% от выручки) вычитается из стоимости актива.
Третий риск связан с технологическим тупиком. Инфраструктура завязана на зарубежных вендоров и решения, недоступные в России, или на полностью самописный софт без API.
Здесь я бы смотрел, какова доля недоступного после санкций оборудования, насколько сложна интеграция с вашей экосистемой и можно ли мигрировать данные без полной перестройки.
Дальше считается 3-летний TCO миграции и импортозамещения. Если бо́льшую часть софта нужно переписывать, стоимость полной модернизации вычитается из покупной цены.
Как, на ваш взгляд, должен меняться подход CFO к оценке киберриска при M&A: достаточно ли проверить соответствие требованиям и наличие средств защиты, или необходимо оценивать потенциальный финансовый ущерб от унаследованных рисков?
Классический подход, ограничивающийся проверкой чек-листа, - это финансовая халатность. Компания может иметь идеальный аудит по 152-ФЗ, но при этом внутри уже есть бэкдоры, СЗИ работают неправильно или парализуют производительность серверов.
При оценке киберриска я бы смотрел на три категории унаследованного ущерба.
Первая категория связана с финансовым долгом за безопасность. Это стоимость приведения ИБ-инфраструктуры компании-цели к вашим стандартам, 3-летний TCO импортозамещения, переписывания правил, интеграции сетей. Зачем платить за технологическую отсталость продавца.
Вторая категория, математическое ожидание унаследованного инцидента. Сколько компания потеряет, если унаследованная уязвимость сработает сразу после сделки? Считаем цену одного дня простоя компании-цели и умножаем на вероятность взлома (ARO), скорректированную по результатам технического аудита. При критичном риске часть суммы замораживается на эскроу-счете на 1–2 года, или прописываются индемнити. Деньги выплачиваются только если инцидент не произойдет.
Третья категория связана с риском того, что утечка или кража данных произошла до закрытия сделки, но об этом станет известно лишь спустя время после сделки.
При due diligence важны не галочки, важен ответ на вопрос: сколько денег нам нужно вложить в ИБ этого актива в первый же день после покупки, чтобы он не сгорел от первой атаки?
Только когда ИБ-риски переведены в плоскость снижения стоимости или изменения структуры платежей, вы защищаете капитал акционеров от унаследованных угроз.
Переход субъектов КИИ на отечественные решения — это для CFO капитальные затраты с понятным ROI или скорее вынужденные расходы без прямой экономической отдачи? Как вы это аргументируете совету директоров?
Это вынужденные расходы без прямой экономической отдачи. Попытка применить коммерческий ROI - самообман, который профессиональный совет сразу определит.
Однако это не «безвозвратная потеря денег». Это капитальные вложения в сохранение права на ведение бизнеса и радикальное снижение риска катастрофического убытка.
На чем строится аргументация перед советом директоров?
Первый аргумент связан с регуляторным ультиматумом. Невыполнение требований по импортозамещению к сроку — это не только штраф, но и возможная приостановка деятельности предприятия до устранения нарушений. Для завода, банка или энергокомпании один день остановки — это мгновенный кассовый разрыв. Затраты на миграцию — это просто входной билет, чтобы компания вообще могла работать.
Второй аргумент — защита менеджмента от уголовной ответственности. Нарушение правил эксплуатации КИИ влечет уголовную ответственность контролирующих лиц (ст. 274.1 УК). Переход на отечественные СЗИ - необходимость и доказательство должной осмотрительности.
Третий аргумент заключается в том, что вместо ROI мы считаем стоимость бездействия (cost of inaction). Берем цену полной остановки КИИ-сегмента на 48 часов при успешной атаке (учитывая уязвимости необновляемого иностранного ПО) и умножаем на вероятность инцидента. Годовой ожидаемый ущерб (ALE) будет в 3–4 раза выше стоимости миграции. Бюджет одобряется потому, что затраты (CapEx) на импортозамещение дешевле, чем финансовая катастрофа при взломе незащищенной КИИ.
А где здесь можно оптимизировать расходы?
Начать стоит с жесткого профилирования КИИ-контура. Не нужно сразу замещать всю инфраструктуру - только объекты, официально признанные значимой КИИ. На них идет целевой бюджет. Остальной ИТ-контур, в зависимости от имеющегося бюджета, переводится на open source или базовые решения.
Отдельно нужно зафиксировать скрытый TCO. В бюджет нужно закладывать повышающий коэффициент (минимум 1,8) на совместимое железо и работу сертифицированных интеграторов.
Перед советом позиция звучит так. «У проекта нет рыночной окупаемости. Но это инвестиция в непрерывность. Без этих 50 млн либо приостановят деятельность, либо получим фатальный взлом на 300 млн убытков и уголовную ответственность. Проект экономически безальтернативен».
Какую одну системную ошибку в логике обоснования ИБ-бюджета вы видите чаще всего - даже у опытных CFO?
Я думаю, главная ошибка — это линейная экстраполяция прошлых рисков на будущие периоды. «Ошибка выжившего».
Например: «В последние 5 лет мы тратили на ИБ копейки, и нас не взломали. Значит, текущий уровень защиты достаточен, новый многомиллионный проект - это паранойя».
Экономико-инженерная суть ошибки проста. Финансовый директор относится к софту как к станку: если работал вчера, будет работать и завтра. В ИБ всё иначе.
Если работать на ПО без обновлений, вероятность взлома растет экспоненциально с каждым днем. Отсутствие инцидентов — это не заслуга старой защиты, это просто везение. Завтра хакеры обнаружат уязвимость нулевого дня, и накопленный за 5 лет риск реализуется одномоментно.
Второй фактор: CFO видит ИБ-бюджет как константу. Но киберриск — это переменная, напрямую привязанная к ландшафту внешних угроз. Если геополитическая напряженность растет, а количество целевых атак на вашу отрасль увеличивается в 3 раза, то сохранение вчерашнего бюджета = кратное падение защищенности.
Кибербезопасность - это управление неопределенностью, а не покупка оборудования. Главная ошибка CFO - думать, что, если пожара не было 5 лет, можно уволить пожарных. Эффективный финансовый директор оценивает ИБ-бюджет не по исторической ретроспективе, а по стоимости предотвращенного ущерба в текущую секунду.
Как, по вашему прогнозу, изменится подход крупных компаний к бюджетированию кибербезопасности в ближайшие 3–5 лет: станет ли risk-based подход стандартом управления, или ИБ по-прежнему будут финансировать преимущественно через compliance и реакцию на инциденты?
По моему прогнозу, в ближайшие 3–5 лет подход крупных компаний к бюджетированию кибербезопасности трансформируется в гибридную модель, где risk-based подход станет ключевым стандартом управления.
Финансирование исключительно через реакцию на инциденты уйдет в прошлое из-за неприемлемой стоимости ликвидации последствий, а соответствие требованиям окончательно перейдет из категории «бумажного» аудита в категорию жесткого финансового риска.
Почему вы считаете, что такой переход уже начался?
Комплаенс перестал быть списком формальных галочек. Принятие и ужесточение законов об оборотных штрафах за утечки персональных данных (до 1–3% от годовой выручки) и введение персональной уголовной ответственности за сбои на объектах КИИ изменили экономику процесса. Выполнение требований регулятора теперь напрямую означает защиту от катастрофического изъятия оборотного капитала. CFO больше не могут игнорировать затраты на комплаенс, так как цена нарушения превышает стоимость построения эффективной риск-ориентированной защиты.
Индустрия окончательно переходит от качественных оценок («высокий / низкий риск») к количественному анализу киберрисков в деньгах (методологии типа FAIR). Крупный бизнес внедряет GRC-системы (Governance, Risk, and Compliance) для автоматического пересчета технических уязвимостей в финансовые метрики, прежде всего цену единичного простоя (SLE) и ожидаемые годовые потери (ALE). Бюджет ИБ защищается перед советом директоров наравне с кредитными или валютными рисками через понятный индекс рентабельности инвестиций (RAPI).
Бизнес уже не воспринимает ИБ как непонятную черную дыру и понял ее критическую важность. Вместе с пониманием пришло осознание, что 100% защиты не существует, компания гарантированно будет атакована. Режим «тушения пожаров» экономически неэффективен, так как средняя стоимость простоя enterprise-инфраструктуры растет экспоненциально.
Поэтому бюджеты смещаются с покупки классических средств защиты (антивирусы, файрволы) на системы резервного копирования, автоматического реагирования (SOAR/XDR) и непрерывности бизнеса. Цель инвестиций - гарантировать, что после успешной атаки ядро бизнеса восстановится за 15 минут, а не за трое суток. Бизнес видит и понимает это.
Если всё-таки разложить будущий ИБ-бюджет по долям, как это будет выглядеть?
Если очень грубо, около 30% уйдет на базовый комплаенс (обязательный OpEx), то есть фиксированный налог на ведение бизнеса, закрывающий требования государства.
Около 50% составит динамический risk-based (инвестиционный CapEx/OpEx), капитал, направляемый строго в те бизнес-процессы, где цена простоя или утечки максимальна.
Еще 20% придется на передачу рисков (киберстрахование и MSSP), то есть сервисную модель для оптимизации внутренних ресурсов и разделения финансовых рисков с подрядчиками.
Иными словами, крупные компании перестанут покупать «безопасность» ради процесса. Они будут бюджетировать прогнозируемую устойчивость своего финансового потока к цифровым угрозам.
Опубликовано 17.09.2026
