Представьте: совет директоров собирается на квартальное заседание, CISO выводит на экран слайд — все индикаторы зелёные, аудит пройден, пентест не выявил критичных уязвимостей, ISO 27001 подтверждён. Через два месяца компанию шифрует ransomware, и выясняется, что зелёный цвет означал лишь то, что проверяли не то и не там. Знакомая картина? Если вы руководитель или отвечаете за ИБ, вы наверняка сталкивались с этим разрывом между отчётом и реальностью.
Проблема в том, что комплаенс и регулярный пентест — это минимальный порог, а не гарантия. Настоящая защита строится на оценке рисков в финансовых терминах, непрерывном тестировании и метриках, привязанных к бизнес-целям. В этой статье разберём, почему так происходит, где чаще всего ошибаются и какие вопросы стоит задать вместо очередного «всё под контролем».
Миф 1: «Прошли аудит и получили сертификат — теперь мы защищены»
ISO 27001, PCI DSS, SOC 2 — эти стандарты проверяют наличие процессов и документации, а не фактическую устойчивость к атакам. Аудитор смотрит, есть ли политика паролей, проводится ли обучение, ведутся ли логи. Но он не проверяет, насколько сложно злоумышленнику пройти от точки входа до критичных данных. Компания может идеально соответствовать стандарту и при этом иметь плоскую сеть, слабую сегментацию и учётные записи с избыточными правами.
Откуда берётся заблуждение: сертификат удобен для отчёта перед регулятором и клиентами. Он создаёт ощущение контроля, но не отвечает на вопрос «что произойдёт, если нас атакуют завтра». В результате ресурсы уходят на поддержание бумажной части, а не на снижение реального риска.
Чем грозит: типичный сценарий — успешная атака через вектор, который не входил в скоуп аудита, и последующие вопросы совета директоров, почему «сертифицированная» компания потеряла данные. Ответ «мы же прошли аудит» не работает.
Миф 2: «Ежегодный пентест закрывает вопрос тестирования»
Пентест раз в год — это фотография состояния безопасности на конкретную дату. За оставшиеся 11 месяцев инфраструктура меняется: выкатываются новые сервисы, меняются конфигурации, появляются новые уязвимости. Атакующий не ждёт следующего аудита.
Что происходит на практике: пентест проводится силами внешнего подрядчика, который работает по стандартному чек-листу. Он находит несколько средних уязвимостей, вы их закрываете, отчёт подшивается в папку. Через полгода выходит критический патч, но его установка задерживается из-за регламента, а новый вектор атаки (например, через цепочку поставок) вообще не проверялся.
Что делать вместо этого: перейти к непрерывному тестированию. Это может быть внутренняя команда red team, которая работает по модели постоянного противодействия, или комбинация автоматизированных сканеров с регулярными ручными проверками. Важно, чтобы тестирование охватывало не только периметр, но и внутреннюю сеть, облачные конфигурации, API и цепочку поставок ПО. Кстати, о том, как превратить вывод сканеров в работающий план атак, а не в формальный отчёт, хорошо рассказано в материале LLM против сканера: как превратить вывод nmap и Burp в работающий план пентеста, а не в выдуманный отчёт по CVE.
Миф 3: «Риски ИБ — это техническая проблема, пусть безопасники с ней и разбираются»
Пока ИБ говорит на языке уязвимостей и техник атак, бизнес не понимает, сколько стоит тот или иной риск. А без этого невозможно приоритизировать защиту и обосновать бюджет. CISO, который приходит к совету директоров с отчётом «обнаружено 143 уязвимости, 12 критичных», получает в ответ «ну так исправьте». А если он говорит: «Риск утечки клиентской базы через этот сервис оценивается в 30 млн ₽ прямых потерь и до 100 млн ₽ репутационных, вероятность — средняя, стоимость устранения — 2 млн ₽», разговор становится предметным.
Как это работает: количественная оценка рисков в финансовых терминах. Не «высокий/средний/низкий», а ожидаемые потери (ALE — annualized loss expectancy). Для этого нужно оценить вероятность события (на основе исторических данных, статистики по отрасли, моделирования угроз) и потенциальный ущерб (штрафы, простои, упущенная выручка, стоимость восстановления). Подход не идеально точный, но он даёт цифру, с которой можно работать.
Типичная ошибка: использовать только качественные шкалы («высокий риск») — они не позволяют сравнить риск с затратами на его устранение. В результате деньги тратятся на то, что громче звучит, а не на то, что сильнее снижает ожидаемые потери.
Миф 4: «Бюджет на безопасность — это просто процент от ИТ-бюджета»
Многие компании определяют бюджет на ИБ как фиксированную долю от ИТ-бюджета (например, 5–10%) или от выручки. Это удобно для планирования, но не связано с реальными рисками. В результате одни направления перефинансированы, другие — недофинансированы.
Что происходит, когда бюджет считают «от процента»: CISO не может обосновать дополнительное финансирование, потому что нет привязки к рискам. Вместо этого он просит «ещё денег на безопасность», и это звучит как «дайте, потому что надо». Совет директоров, который не видит связи между затратами и снижением риска, либо отказывает, либо сокращает бюджет при первом удобном случае.
Как надо: строить бюджет от рисков. Сначала количественно оцениваем риски, затем определяем, какие меры дадут наибольшее снижение ожидаемых потерь на рубль затрат. Такой подход позволяет показать возврат на инвестиции в безопасность (ROSI). Например, внедрение многофакторной аутентификации для удалённого доступа стоит 500 тыс. ₽ в год, а снижает вероятность крупной утечки на 30% при потенциальном ущербе 20 млн ₽. Ожидаемая экономия — 6 млн ₽ в год, ROSI — 1100%. С такой цифрой можно идти к финансовому директору.
Миф 5: «CISO — это технический эксперт, который разбирается в безопасности»
Технические знания необходимы, но недостаточны. Современный CISO — это бизнес-лидер, который понимает стратегию компании, умеет говорить на языке финансов и управлять изменениями. Он отвечает не за «безопасность», а за управление киберрисками как частью бизнес-рисков.
Где ломается: технически сильный специалист, назначенный CISO, продолжает фокусироваться на уязвимостях и инструментах, упуская коммуникацию с советом директоров, выстраивание отношений с бизнес-подразделениями и управление бюджетом. В результате его предложения не находят поддержки, а инициативы буксуют.
Что помогает: развитие навыков в области финансов, стратегии, коммуникации. Этому не учат на технических курсах по безопасности. Здесь нужен другой подход — например, executive-программы, которые моделируют реальные ситуации из практики CISO: как защитить бюджет, как объяснить совету директоров необходимость инвестиций, как выстроить отношения с другими руководителями.
Как выбрать путь в CISO: самостоятельный или структурированный
Если вы хотите перейти на роль CISO или уже занимаете её и хотите усилить стратегические навыки, есть несколько путей.
Самостоятельное обучение: книги, статьи, конференции. Плюсы: дёшево, гибко. Минусы: нет обратной связи, нет системы, легко упустить важные аспекты (например, финансовую оценку рисков или коммуникацию с советом директоров). Ошибки на реальной работе могут стоить дорого.
Практика под руководством ментора: наставник из числа действующих CISO может дать ценные советы, но найти такого ментора сложно, а его время ограничено. Кроме того, нет структурированной программы, всё зависит от опыта ментора.
Структурированные executive-программы: дают систематизированные знания, разбор кейсов, обратную связь по вашим решениям. Стоят дороже, но экономят время и снижают риск ошибок. Например, CISO Executive Program — Chief Information Security Officer построен вокруг практических артефактов: стратегии безопасности, бюджета, презентации для совета директоров, плана реагирования на инциденты. Это не просто теория — вы создаёте документы, которые сможете использовать в своей работе.
Кому подходит структурированный путь: тем, кто готов инвестировать время и деньги в переход на executive-уровень, кто уже имеет технический бэкграунд и хочет развить стратегические и коммуникационные навыки.
Кому не подходит: тем, кто ищет только технические знания по безопасности (лучше идти на курсы по пентесту или архитектуре), а также тем, кто не готов работать над soft skills и финансовой грамотностью.
Чек-лист вопросов для совета директоров вместо отчёта «всё зелёное»
Вместо того чтобы показывать зелёные дашборды, задайте эти вопросы себе и совету директоров. Они помогут выявить реальные пробелы.
- Какие наши критичные бизнес-процессы и как они защищены? Не «какие системы», а именно бизнес-процессы: обработка заказов, платежи, работа с клиентскими данными.
- Какова ожидаемая финансовая потеря от реализации трёх наиболее вероятных сценариев атак? Нужны конкретные цифры, а не «высокий риск».
- Как часто мы тестируем защиту и насколько тесты приближены к реальным действиям атакующих? Ежегодный пентест — это минимум, а не максимум.
- Как мы управляем рисками цепочки поставок? Знаем ли мы, какие компоненты использует наше ПО и насколько им можно доверять?
- Какие метрики безопасности мы отслеживаем и как они связаны с бизнес-целями? Например, время обнаружения и реагирования на инциденты, доля критичных уязвимостей, закрытых в срок.
- Какой у нас план на случай кризиса и кто принимает решения? Проверяли ли мы его на учениях?
- Достаточно ли инвестиций в безопасность для покрытия наших рисков? И как мы измеряем эффективность этих инвестиций?
Эти вопросы переводят разговор из плоскости «техническая безопасность» в плоскость управления бизнес-рисками. И именно на них должен уметь отвечать современный CISO.
Если вы хотите системно разобраться в этих вопросах и научиться строить защиту, основанную на рисках, а не на формальном комплаенсе, обратите внимание на CISO Executive Program — Chief Information Security Officer. Программа построена вокруг практических артефактов: стратегии безопасности, бюджета, презентации для совета директоров и плана реагирования на инциденты. Вы не просто изучите теорию — вы создадите документы, которые сможете применить в своей работе.