Как измерить автоматизацию ИБ

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

Автоматизация на результат и немного математики

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

Рассмотрим первый домен — «невозможность реализации НС посредством целенаправленной активности внешнего хакера»*. В нем есть множество классических ИБ-решений: одни предназначены для мониторинга и реагирования, другие позволяют реализовать превентивные меры для защиты инфраструктуры. SIEM, NTA, IRP, SOAR, SGRC, VM — перечислять можно долго.

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

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

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

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

Мы можем связать количество шагов с параметром времени и получим функцию Step(.). Тогда наше исходное выражение примет следующий вид:

Соответственно, для повышения защищенности компании первый показатель нужно увеличивать, а второй — уменьшать. Далее определим форму представления результата с левой и правой сторон выражения (см. рис. 2).

Увеличение Step(TTA) — задача средств безопасности и харденинга, которые можно объединить атрибутом before-attack. Они должны максимально усложнить хакеру путь к целевым системам. За сокращение метрики Step(TTR) отвечают решения during-attack — инструменты мониторинга и реагирования на инциденты. Чем выше их эффективность, тем меньше шагов успеет сделать хакер до локализации атаки.

Чтобы разделить эти процессы, введем параметр N:

Предположим, N = 3: это означает, что средства мониторинга и реагирования должны при любых обстоятельствах локализовать атаку менее чем за три шага хакера. Соответственно, инфраструктуру компании и систему ее защиты нужно выстраивать так, чтобы злоумышленнику потребовалось сделать как минимум четыре шага (N + 1) для реализации недопустимого события (независимо от выбранной траектории).

При этом мы можем разложить параметр TTR на составляющие. В классическом понимании TTR = TTD + TTI + TTM, где:

• TTD (Time to Detect) — время от начала атаки до обнаружения нелегитимной активности
• TTI (Time to Investigation) — время, которое необходимо для расследования нелегитимной активности.
• TTM (Time to Mitigation) — время от завершения расследования до окончания процессов реагирования. 

Этот показатель можно разделить на две метрики: время на формирование сценария реагирования (TTGP — Time to Generate Playbook) и время на выполнение операций по реагированию (TTEP — Time to Execute Playbook).

За этими метриками скрывается целый пул процессов, каждый из которых определяет конкретное решение по автоматизации в терминах результата (см. табл. 1).

Все средства автоматизации с атрибутом before-attack можно обозначить как класс решений Automated Security Hardening Control (ASHC). Отдельные инструменты помогут достичь определенного результата по входящим в него пунктам (например, VM по п. 2.2), однако этого недостаточно. Комплексный результат по атрибуту before-attack на сегодняшний день достигается только за счет работы ИТ-инженеров и ИБ-экспертов.

Практически все ИБ-решения, которые можно так или иначе ассоциировать с сенсорами (SIEM, Sandbox, NTA, EDR и др.) с точки зрения результата попадают в п. 1 с атрибутом during-attack. Некоторые классы решений позволяют достичь результатов по п. 2–4 (например, IRP/SOAR), но для заказчика этот результат нельзя назвать конечным. Готовое решение для автоматизации, которое закрывает все упомянутые процессы, можно обозначить как Automated Threat Actor Protection (ATAP).

Еще немного математики

Чтобы сформулировать индекс автоматизации ИБ, нужно декомпозировать результаты работы систем защиты в виде дерева.

Дерево результатов (см. рис. 3) позволяет нам говорить об уровне автоматизации в терминах достижения конечного результата. Введем бинарную классификацию:

• Слабая автоматизация. Результат достижим, но требует участия человека.
• Сильная автоматизация. Результат достижим без участия человека. 

Для удобства присвоим каждому результату маркер (выделены красным цветом). Например, Res_DA — это результат по атрибуту during-attack. 

На каждом участке дерева мы можем обозначить слабую автоматизацию или ее отсутствие как 0, а сильную — как 1. Для получения более точной градации нужно декомпозировать результат на составляющие. На рис. 3 приведена декомпозиция до 4-го уровня, где каждый конечный результат дает вклад 1/8 в общий результат Res.

Тогда финальный индекс автоматизации определяется суммой всех вложенных результатов — в зависимости от того, достигнута там сильная автоматизация (1) или нет (0):

Таким образом мы можем оценить степень автоматизации по всем системам, которые вносят определенный вклад в достижение цели «невозможность реализации НС посредством целенаправленной активности внешнего хакера».

Например, при полной автоматизации процесса детектирования (за счет SIEM, NTA, Sandbox и др.) индекс автоматизации IA(Res) составит 0,125. Если при этом мы также автоматизируем контроль инфраструктуры (настройка подсегментов сети, разграничение прав доступа и т. д.), уровень автоматизации вырастет до показателя 0,375.

Технологический индекс автоматизации

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

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

Нам нужно ответить на два вопроса:

1.    Что делает человек (как должна меняться деятельность оператора на каждом уровне автоматизации)?

2.    Что делает автоматизированная система (какие функции человека забирает на себя)?

Введем признаки «что делает оператор» и «что делает автоматика». С учетом того, что Res_DA подразумевает работу систем мониторинга и реагирования на инциденты, разделим каждый блок на «мониторинг» и «реагирование». В результате получим следующую классификацию (см. табл. 2).

По уровням 1–3 вопросов быть не должно, поскольку они описывают существующие классы решений. Системы 4-го уровня должны оперировать цепочками действий в привязке к рискам в инфраструктуре. Подобным решениям все еще требуется оператор, но его участие в процессе минимально (пример — MaxPatrol О2). Фактически человек получает полную картину действий хакера с заранее сгенерированным playbook. Последний, 5-й уровень, как и в стандарте SAE J3016, предполагает полный автопилот. В таких системах нет false positive, поэтому и участие оператора не потребуется.

Можно ли обойтись без автоматизации?

Чтобы ответить на этот вопрос, давайте разберем простой пример. Допустим, в компании реализован классический инцидент-менеджмент: специалисты SOC определяют ИБ-инциденты по результатам отработки корреляций в SIEM или напрямую от сенсоров. Определим пороговое значение N = 4, т. е. хакер должен сделать не более 3 шагов до локализации нелегитимной активности.

Инфраструктура в 5000 активов с подключением всех необходимых источников данных дает около 20 000 EPS, которые превращаются примерно в 2300 подозрений на инцидент в день. Как правило, в компаниях такого размера в SOC работает не более 10 аналитиков, которые не смогут расследовать все 2300 подозрений из-за нехватки времени. Поэтому группа аналитиков формирует правила приоритизации и обрабатывает только подозрения, наиболее вероятно указывающие на инцидент. В результате в работе SOC формируется слепая зона, где возникновение инцидента хоть и маловероятно, но возможно.

При наличии 10 человек в SOC слепая зона для такого объема событий среднестатистически составляет около 24%. При условии Step(TTR) < 4 атака должна быть однозначно обнаружена за три шага. Самый опасный сценарий — когда атака полностью остается в слепой зоне на этом интервале. При таком размере слепой зоны вероятность АРТ-атаки остаться невидимой составляет 1,3%. На первый взгляд, цифра может показаться незначительной, однако если учесть, что результатом будет реализация недопустимого события, а сама атака может быть не единична, становится очевидна неприемлемость подобного риска.

Чтобы сократить размер слепой зоны до 0%, аналитикам SOC нужно отрабатывать все 2300 подозрений в сутки. В среднем на анализ одного подозрения уходит 7 минут. Суммарно получаем 7 × 2300 = 16 100 минут, или около 268 часов. Чтобы обеспечить такую производительность, в SOC должно работать 50 человек (46 в смене и 4 высококвалифицированных эксперта). А масштабной корпорации с 300 000 активов потребуется 3000 специалистов. Такой SOC выглядит неприемлемо большим, к тому же на рынке просто невозможно найти столько аналитиков. Соответственно, гарантированный результат мониторинга целенаправленных атак в инфраструктуре недостижим без сильной автоматизации.