Сделка уже одобрена. Теперь позовём информ-безопасность

Мне кажется, одна из самых недооценённых проблем в управлении киберриском заключается в моменте подключения CISO.

Компания может месяцами обсуждать покупку бизнеса, запуск продукта, выбор платформы или выход на новый рынок.

Но информационную безопасность приглашают тогда, когда решение уже почти необратимо.

Сделка согласована. Архитектура утверждена. Поставщик выбран. Дата запуска объявлена клиентам.

От ИБ ожидают, что она проверит решение и сделает его безопасным.

Но у безопасности не всегда есть такая возможность.

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

Можно внедрить дополнительный контроль доступа. Гораздо сложнее устранить зависимость приобретённой компании от одного администратора или неподдерживаемой платформы.

Можно провести аудит поставщика. Но если на нём уже работают несколько критических процессов, результаты аудита не вернут компании свободу выбора.

Поэтому я считаю, что CISO должен участвовать не только в эксплуатации и защите существующих систем.

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

Речь не о праве вето.

Сильный CISO не должен отвечать на каждую инициативу фразой «слишком опасно».

Его ценность в другом: перевести технический риск на язык, которым пользуется инвестиционный или продуктовый комитет.

Не «в компании отсутствует зрелый PAM», а:

интеграция потребует дополнительного бюджета; привилегированный доступ создаёт вероятность масштабной компрометации; без изменения модели администрирования объединять инфраструктуру нельзя;

часть стоимости сделки необходимо удержать до устранения недостатков.

Не «архитектура не соответствует нашим требованиям», а: продукт невозможно безопасно масштабировать;

обновление критической библиотеки потребует остановки сервиса; изоляция клиентов не обеспечена;

обещанный срок запуска создаёт неприемлемый остаточный риск.

NIST CSF 2.0 вывел управление киберриском в отдельную функцию Govern, напрямую связывая его с корпоративным риск-менеджментом и ответственностью руководства. Европейские требования к цифровым продуктам также всё сильнее закрепляют ответственность производителя за безопасность на протяжении жизненного цикла. (NIST)

Поэтому перед одобрением сделки или продукта я бы задал три главных вопроса:

Какую цифровую зависимость мы создаём?

Сколько будет стоить безопасно владеть этим решением?

Сможем ли мы отказаться от него без остановки бизнеса?

Если эти вопросы возникают только после подписания договора, управление риском началось слишком поздно.

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

Как вы считаете: на каком этапе CISO должен подключаться к M&A или запуску нового продукта?

Сделка уже одобрена. Теперь позовём информ-безопасность | Сетка — социальная сеть от hh.ru