Как выстроить диалог между CEO и CISO и перестать бояться инцидентов

Если директор по информационной безопасности (CISO) боится признаться в инциденте в сфере ИБ, а гендиректор (CEO) оценивает безопасность по отсутствию взломов, бизнес живет на пороховой бочке. Потому что в таком случае отношения между ними строятся на страхе. CEO боится убытков, а CISO — ответственности за инциденты. В такой атмосфере любые проблемы ИБ становятся «грязным секретом», который стараются замолчать и который потом может обернуться большой проблемой.

Главная уязвимость компании — не в софте, а в коммуникации. Чтобы руководители не скрывали проблемы, они должны быть уверены, что за ошибку их не накажут. И вместо поиска виноватых приоритетом должна стать культура прозрачности.

Тормоза для велосипеда: зачем бизнесу CISO

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

Кроме того, роль CISO важна с точки зрения независимой экспертизы. Большинство CEO не обладают глубоким пониманием кибербезопасности. В таких случаях директор по ИБ выполняет роль экспертного фильтра, который проверяет ответы «системы» (будь то ChatGPT или подчиненные), когда цена ошибки слишком высока. Особенно необходим CISO становится, когда бизнес достигает масштаба, при котором внутренние ИТ‑процессы требуют собственной безопасности. Практика показывает, что для крупных организаций полезно иметь специалистов по ИБ в пропорции около 10% от численности ИТ‑подразделения.

Значит, проблема диалога между бизнесом и безопасностью не в самой функции CISO. Тогда в чем? В двух вещах. Первая — как бизнес в целом относится к инцидентам. Вторая — в том, как выстроен и встроен процесс кибербезопасности.

Правильное отношение к инцидентам. Советы для CEO

Зачастую киберинцидент воспринимается бизнесом как преступление, за которое кто‑то должен понести наказание. На самом деле, инциденты — это часть жизни компании, неизбежная и нормальная. Проблема возникает, когда они остаются без разбора и не проводится работа над ошибками.

Встраивание безопасности в продукт. Безопасность должна быть встроена в продукт. Игнорировать эту интеграцию или полагаться только на внешние средства защиты (файерволы, WAF и т. п.) — значит оставлять систему уязвимой при атаках. Ведь если злоумышленники «пролезают» через логические дыры в приложении, никакие внешние средства защиты не смогут полностью их закрыть. Нативная безопасность, заложенная в код, избавляет компанию от необходимости тратить ресурсы на бесконечные внешние «подпорки».

Использование правильных метрик для ИБ. Необходимо правильно оценивать экономическую эффективность CISO. Настоящий индикатор его зрелости — не отсутствие атак (на количество которых он никак не может повлиять), а способность извлекать уроки и предотвращать повторение негативного сценария. Поэтому главными метриками могут быть полнота покрытия мониторингом, data‑driven оценка соответствия, скорость и качество реакции на инциденты. Например, восстановление работы системы за два часа вместо двух недель — показатель, который реально отражает эффективность процессов безопасности.

Ведение документации и отчетности. Бизнес должен регулярно просматривать отчеты о расследовании инцидентов и восстановлении от CISO. В них не обязательно должны быть все технические детали — достаточно высокоуровневого саммари: какие уроки вынесены по части повышения антихрупкости бизнеса, какие меры защиты усилены, какие процессы изменены для предотвращения повторения. Но для того, чтобы эти отчеты были полезными, подразделения компании должны предоставить CISO данные для оценки ущерба. Также его нужно включать в финансовые и управленческие процессы. А требовать от него оцифровывания рисков, не допуская к финансовым отчетам, бесполезно.

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

Совместная работа. Случаются ситуации, когда ИТ и ИБ нужно совместными усилиями решать возникающие проблемы, привлекая дополнительные ресурсы. Для этого необходимы скоординированные действия между подразделениями, и без вовлечения бизнеса это невозможно — ресурсы не освободятся вовремя, а восстановление затянется. Однако и ИТ, и ИБ нередко предпочитают действовать самостоятельно и не просить помощи коллег, опасаясь негативной реакции со стороны бизнеса. Задача CEO — обеспечить культуру поддержки, а не критики в таких ситуациях. Это будет мотивировать команды открыто говорить о проблемах и при необходимости решать их совместно, а не по отдельности.

Обучение киберграмотности. Для устранения страха и паники со стороны сотрудников необходимо их участие в регулярных обучающих программах и стресс‑тренировках. CEO и менеджмент должны понимать, что критично, а что допустимо, какие действия предпринимаются при инциденте. Кроме того, они должны знакомиться со сценариями работы под атакой, которые готовит CISO.

Как сделать так, чтобы CISO работал на бизнес, а не против него

Разговор с бизнесом вместо запугивания. Идеальный CISO — это коммуникатор, а не продавец страха. Пугая CEO киберрисками, безопасник не добьется доверия. Задача CISO — помочь бизнесу пережить реальные ситуации, возникающие при реализации рисков, и сделать это максимально прозрачно и конструктивно. Его сила проявляется в умении объяснять, что выполняемые действия — это перечень четких шагов, снижающих уровень паники и суеты, даже если инцидент уже произошел. Для него важно умение наладить правильный диалог с директором по ИТ, UX‑дизайнерами и другими подразделениями.

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

Отсюда вытекает баланс ролей. У CISO должно быть право вето на откровенно небезопасные решения, но он не может задавать тон при определении пользовательских сценариев и логики работы системы. CISO участвует в архитектурных комитетах, формулирует ограничения и оценивает риски, но не подменяет собой ИТ‑архитекторов, продукт‑менеджеров и UX‑дизайнеров. Безопасность должна встраиваться в продукт и поддерживать удобство его использования, а не навязываться ценой ухудшения пользовательского опыта.

Встраивание ИБ в процесс заранее. Типичная ошибка, которая портит отношения ИБ с бизнесом — когда безопасник возникает из ниоткуда в момент старта или релиза проекта. В такой роли он просто замедляет процесс и выглядит «врагом». Идеальный сценарий — когда безопасность перестает быть внешней «фишкой» вроде файервола, приставленного сбоку, а встроена в сам цикл разработки через SecDevOps‑практики и регулярное тестирование.

Оптимальная последовательность принятия решений такова: сначала UX‑дизайнеры и ИТ‑архитекторы формируют пользовательский опыт, затем CISO проверяет и валидирует безопасность. Первая и последняя скрипка остаются за теми, кто понимает пользовательский путь.

Разговор на языке цифр. Бизнес ориентирован на цифры (или, точнее говоря, деньги), а в кибербезопасности измерить в цифрах и деньгах можно не все и не всегда. Поэтому CISO и СЕO важно договориться, в каких цифрах (метриках) они будут оценивать SLA безопасности, чтобы это было понятно, прозрачно и релевантно текущему уровню развития компании. Иными словами, необходимо, чтобы CISO умел говорить на языке цифр.

Например, оценка рисков может начинаться с определения стоимости активов: CRM, ERP, базы данных, процессов обработки информации.

Так, данные внутри CRM — не просто программное обеспечение, а инструмент автоматизации продаж. Их потеря или компрометация удлиняет цикл продаж, увеличивает затраты на ручную обработку и может приводить к кассовым разрывам. То есть, стоимость инцидента определяется через влияние на бизнес‑процесс, а не через цену железа или отдельного сервиса.

Когда понятно, как инцидент повлияет на ценность конкретного актива, разговор с CISO становится предметным и конструктивным.

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

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