Иногда прилетают любопытные запросы на проект по теме SOC, в целом характеризующие зрелость положение дел на рынке SOC-ов. Можно выделить несколько интересных типов подобных обращений, но сегодня поговорим об одном из них: выдать предложение услуги SOC, исходя из развернутых инструментов ИБ, т.е. у заказчика куплены такие-то свистоперделки, но ими никто не пользуется и поэтому ценность, обещанная при обосновании бюджета никак не наступает, и очевидное решение тут - приделать к этим инструментам команду от подрядчика. Описанная проблема носит системный характер, поэтому давайте поразбираемся в этой ситуации, и многие, сколько я себя помню, так и не решаемые, проблемы, типа обоснования инвестиций в ИБ, нехватки ресурсов, ROI и неоправданности ожиданий и т.п., станут понятнее.
1. Проблема "Инструмент в поисках процесса" - заказчик купил дорогой инструмент (может, с помощью вендора или ввиду "моды"), не имея ответа на принципиальные вопросы:
- Какую конкретную бизнес-проблему это решает? Не техническую, а именно бизнес-проблему: снижение риска утечки данных, выполнение требований регулятора, сокращение времени простоя бизнеса и т.п.
- Какие процессы SOC (обнаружение и расследование, реагирование, управление поверхностью атаки и т.п.) будут завязаны на эти инструменты?
- Кто и как будет использовать выходные данные, и как они будут отражаться на бизнес-уровень, чтобы ценность для бизнеса была налицо?
В итоге мы получаем инструмент, который не интегрирован в бизнес-процессы управления ИБ в компании. В целом, эта ситуация весьма частотна. Когда-то давно я занимался безопасностью SAP (отголоски того прошлого), и еще тогда я обнаружил причину вечности проектов внедрения SAP (внедрение переходит в бесконечную "поддержку", когда новые\модифицированные функциональные модули постоянно заливаются в прод). SAP, будучи системой автоматизации бизнеса, как и любая другая автоматизация (ИИ-автоматизация - не исключение), должна ложиться на хорошо документированный и внедренный бизнес-процесс, а если последнего нет, нет и объективных критериев успешности автоматизации (очевидно, ведь объекта автоматизации, автоматизируемого бизнес-процесса, формально почти нет). Однако, ситуация еще хуже, так как существует поверье, что порядок в бизнес-процессах можно навести в рамках самого проекта автоматизации. Отчасти это так, и я непосредственно принимал участие в подобных проектах (например, внедряя IAM удалось упорядочить управление доступом), но успех здесь зависит от состава команды (это точно тема для другой статьи), и для нашего случая совсем неприменимо, ибо запрос на проект звучит как необходимость выдать стоимость команды, речи о том, что нужно полностью построить SOC, нет.
2. Отсутствие стратегии и архитектуры безопасности - скорее всего инструменты были куплены точечно, а не как часть целостной архитектуры безопасности, поэтому:
- Возможно [частичное] дублирование функционала разных решений.
- Насколько хорошо они интегрируются между собой, может, вопрос интеграции в разы сложнее проектов внедрения.
- Сюда же вопрос "единого окна", ибо смотреть в единое окно или в N разных консолей - абсолютно разная стоимость.
В целом, я не против кусочно-заплаточного подхода к ИБ, и не раз убеждался, что он работает на практике, но при отсутствии первого пункта, давшего название всей статье, наш заплаточный подход представляет собой просто этапность продолжительного во времени внедрения инструментов, автоматизирующих существующие бизнес-процессы, потребность в конкретных решениях здесь первична и налицо, мы дозрели до них, инструменты не покупались "впрок", чтобы потом вокруг них строить всю нашу ИБ.
3. Экономическая неэффективность. Здесь вроде бы понятно: заказчик заплатил CapEx и платит OpEx за решения, которыми не пользуется. Глубинная проблема в том, что ценность от инструмента извлекается не из факта его наличия, а из результата его использования в контексте бизнес-процессов. Так как бизнес-процессов [почти] нет, то и ценности не будет, да и опыт подсказывает, что подрядчик в такой ситуации не поможет, ну или задачи проекта будут совсем другого характера и стоимость такого проекта будет совсем другая, а с учетом того, что скоуп не определен (~ построение бизнес-процессов, в которые могли бы вписаться такие-то решения ИБ), не определена и стоимость такого проекта: бесконечный объем проекта приводит к бесконечной его стоимости и продолжительности (выше история про бесконечные проекты SAP)
4. Техдолг и скрытые затраты. Развернутые, но не используемые решения часто имеют устаревшие версии, неправильно сконфигурированы (например, все по умолчанию), не покрывают всю целевую инфраструктуру. В общем случае, чем сложнее решение, тем больше возможностей по его конфигурации, а тонкая настройка требует постоянного тюнинга. В условиях, когда решением не пользуются, чем больше времени прошло с момента внедрения, тем ближе перспектива конфигурирования с трудоемкостью, сравнимой с повторным внедрением.
Ну а что же делать потенциальному подрядчику в таком проекте? Грубый план может выглядеть примерно следующим образом:
Этап 1. Провести текущую оценку зрелости или в общем случае аудит, который покажет в каком состоянии инструменты и технологии вообще, процессы, люди, какие сервисы от SOC ожидает бизнес и как эти сервисы встраиваются в корпоративные бизнес-процессы.
Этап 2. Если результат нужен прямо сейчас, то предложить MDR или SOC-as-a-Service, а параллельно инициировать проект по построению процессов SOC в целевой архитектуре. В рамках проекта построения SOC надо:
- Запланировать закрытие техдолга по части конфигурации решений, отмеченного выше.
- Понять целевую гибридную структуру: какие задачи будут выполняться внешним поставщиком, какие - внутренней командой, расписать RACI, заонбордить внутреннюю команду.
- Договориться с Бизнесом о бизнес-показателях SOC, чтобы сразу технические метрики спроектировать так, чтобы можно было объективно оценить ценность для бизнеса. И технические метрики надо тоже разработать, очевидно, чтобы понять делаем ли мы по-прежнему правильные вещи правильно.
Если кратко подытожить эту статью, то проблема все та же: сначала возникает процесс, потом потребность в инструменте и только потом инструмент. Идти от инструмента в ряде случаев можно, но это сложнее, а, следовательно, вероятность успеха ниже. Если мы хотим через внедрение инструмента повысить зрелость процессов, то и здесь не стоит сначала приобретать инструмент, ибо пока он будет простаивать, мы будем терять ресурсы на его обслуживание.
