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

Нет видимости облаков — покупаем платформу.

Много уязвимостей — добавляем сканер.

Слишком много событий — внедряем автоматизацию.

Проблема в том, что не каждый дефицит контроля является дефицитом технологии.

Иногда компании не хватает владельца процесса. Иногда — актуальных данных об активах. Иногда — полномочий остановить опасное изменение. Иногда — договорённости между ИБ, разработкой и инфраструктурой.

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

В результате security stack расширяется, а управляемость не растёт.

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

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

Особенно опасен эффект ложной уверенности.

У руководства появляется внушительный список средств защиты, зелёные дашборды и отчёты о миллионах обработанных событий. Формально контроль существует.

Но способен ли SOC выделить действительно критичный сигнал?

Связаны ли результаты сканирования с бизнес-критичностью систем?

Кто отвечает за устранение проблемы?

Может ли команда доказать, что вероятность или воздействие риска изменились?

Если ответов нет, технология создаёт видимость активности, но не обязательно результат.

Моя позиция достаточно жёсткая:

средство защиты без владельца, процесса, качественных данных и понятного lifecycle не является полноценным контролем.

Перед закупкой я бы сначала рассматривал четыре решения:

Buy — приобрести новый продукт, если подтверждён реальный разрыв в контролях.

Build — разработать собственное решение, если сценарий специфичен и организация готова поддерживать полный жизненный цикл.

Integrate — улучшить существующий stack, данные и процессы.

Retire — отказаться от инструмента, который не снижает значимый риск или дублирует другие платформы.

Последний вариант используется реже всего.

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

Полезный вопрос для ежегодной ревизии:

если бы этого инструмента сегодня не было, стали бы мы покупать его снова?

Если нет, прошлые инвестиции не должны быть единственной причиной продолжать эксплуатацию.

Я не считаю, что security stack должен быть маленьким. Я считаю, что он должен быть управляемым.

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

В противном случае ещё один инструмент делает функцию ИБ не сильнее, а сложнее.

А сложность, которой никто не управляет, сама становится риском.

Сталкивались ли вы с продуктами, которые создавали больше сигналов, отчётности и ручной работы, чем реального снижения риска?