Измерение влияния автоматизации

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

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

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

Если первичный анализ фишингового инцидента вручную занимал 30 минут и выполняется 200 раз в месяц:

Две метрики жизненного цикла характеризуют работу SOC:

• MTTD (среднее время обнаружения) — от момента компрометации до обнаружения. SOAR в меньшей степени влияет на этот показатель; в основном это метрика разработки средств обнаружения.
• MTTR (среднее время реагирования) — от обнаружения до локализации. Именно здесь SOAR особенно эффективен.

Отслеживайте MTTR до и после внедрения плейбука. Снижение показателя с нескольких часов до нескольких минут — самое наглядное доказательство эффективности автоматизации.

Доля автоматизации — это доля событий, полностью или частично обработанных плейбуками, по сравнению с событиями, требующими ручной работы.

Разделяйте её на категории:

• Полностью автоматизированные — закрыты без участия человека.
• С участием человека — плейбук выполнил обогащение, а человек принял решение.
• Полностью ручные — плейбук не применялся.

Рост долей полностью автоматизированных процессов и процессов с участием человека показывает расширение охвата; отсутствие роста указывает на плейбуки, которые необходимо расширить.

Скорость бессмысленна, если решения ошибочны. Сочетайте метрики эффективности с метриками качества:

• Доля ложных срабатываний при автоматическом закрытии (закрыл ли плейбук настоящую угрозу?).
• Доля повторного открытия — случаи, которые плейбук закрыл, но аналитику пришлось открыть снова.
• Доля отмены решения — как часто аналитики отклоняют рекомендованное плейбуком действие.

Быстрый плейбук с высокой долей отмен решений не экономит время, а порождает недоверие.

Некоторые показатели выглядят впечатляюще, но вводят в заблуждение. Число запусков плейбука является показательной метрикой, если эти запуски обрабатывают незначительные или дублирующиеся события.

Плейбук, срабатывающий 10 000 раз в месяц, кажется полезным, но если 9 000 из этих запусков вызваны повторными оповещениями, которые он должен был подавить, то настоящая проблема — шум на предыдущем этапе обработки, а не ценность автоматизации. Всегда связывайте показатели активности с результатами и сэкономленным временем.

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

Влияние можно определить только сравнением, поэтому необходимо исходное значение до изменений. Зафиксируйте текущие MTTR, время ручной обработки и количество часов аналитиков для каждого типа оповещений до внедрения автоматизации.

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

Руководителей интересуют риски и затраты, а не внутреннее устройство сценариев. Переводите свои показатели на их язык:

• Сэкономленные часы выражайте через высвобождённый ресурс в эквиваленте полной занятости (FTE).
• Снижение MTTR описывайте как сокращение времени присутствия атакующего в системе и риска взлома.
• Последовательность и охват проверками описывайте как готовность к соблюдению требований.

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

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

• Высокая доля ручных переопределений → логика принятия решений неверна; уточните её.
• Низкая доля автоматизации для оповещения с большим числом ложных срабатываний → кандидат на новый сценарий автоматизации.
• Сценарий автоматизации, который редко срабатывает → рассмотрите возможность вывести его из эксплуатации, чтобы сократить затраты на сопровождение.

Автоматизация никогда не бывает завершённой; измерения подсказывают, куда направить следующие инвестиции.

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

Честно оценивать ценность следует по чистому эффекту:

Измерение влияния автоматизации:

• Измеряйте, чтобы обосновывать инвестиции и находить направления для улучшения; зафиксируйте исходные значения до внедрения сценариев автоматизации.
• Отслеживайте сэкономленное время за один запуск, снижение MTTR и долю автоматизации (полностью автоматизированные, с участием человека и ручные операции).
• Сопоставляйте скорость с качеством: закрытие ложных срабатываний, долю повторно открытых инцидентов и долю ручных переопределений.
• Избегайте показателей тщеславия, таких как простые счётчики запусков; всегда связывайте активность с результатами.
• Оснащайте сценарии автоматизации телеметрией, представляйте влияние в понятиях руководства (сэкономленный ресурс в FTE, риск, связанный со временем присутствия атакующего) и запускайте цикл непрерывного улучшения.