Зачем нужны метрики работы с инцидентами в Security Operations Center: объясняем на примере из «Властелина колец»

Одной из важных и сложных задач, решаемых центром кибербезопасности (Security Operations Center, SOC), является оценка последствий киберинцидентов (уже наступивших или тех, которые вот-вот наступят). Это позволяет присваивать инциденту приоритет и реагировать в соответствии с ним. Но куда труднее сказать, какова вероятность успешной атаки в будущем. В этой статье мы поговорим о том, как измерить этот риск с помощью метрик, какие данные нам для этого понадобятся и где их взять. А для наглядности отправимся в фэнтезийный мир Дж. Р. Р. Толкина и убедимся, что наш метод поможет и там.

Я Константин Смирнов, советник директора экспертного центра Positive Technologies. Хотя я и являюсь автором, эта статья не получилась бы без помощи моих коллег Анастасии Важениной, руководителя практики развития метапродуктов Positive Technologies, и Михаила Стюгина, руководителя направления автоматизации информационной безопасности Positive Technologies, которым я очень благодарен за их вклад и бесценную критику.

За время работы в сфере информационной безопасности мне не раз приходилось участвовать в создании SOC. Опыт таких проектов показывает, что устойчивость деятельности организации зависит (среди прочего) и от ее способности быстро обнаруживать инциденты кибербезопасности и оперативно на них реагировать. Что значит «быстро» и «оперативно»? Это и есть область применения метрик, о которых мы будем говорить. 

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

Теория и вероятности: что такое риск и инцидент в ИБ

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

С последствиями киберинцидента все более-менее понятно: можно представить сценарий реализации и оценить ущерб. Проблема заключается в том, что с оценкой вероятности наступления недопустимых событий все не так хорошо, ведь до сих пор нет надежного способа ее просчитать. Есть, например, американская компания RiskLens, которая собирает исторические данные разных инцидентов, сортирует их по индустриям и использует для моделирования рисков методом Монте-Карло. Однако в силу того, что контекст, в котором реализуются подобные риски, учитывается слабо (и он все время меняется), сложно сказать о применимости такого подхода в целом.

Можно ли оценить шансы наступления такого события, опираясь на какие-то данные? Для этого давайте рассмотрим жизненный цикла инцидента ИБ.

Жизненный цикл и метрики инцидента ИБ

Жизненный цикл инцидента хорошо определяет стандарт NIST 800-61 rev2, который учитывает следующие стадии:

1. Подготовка.

2. Идентификация инцидента.

3. Локализация угрозы.

4. Устранение угрозы.

5. Восстановление (снижение последствий реализации угрозы).

6. Действия после инцидента.

Чтобы примерно подойти к оценке вероятности наступления такого события, нужно определить, что необходимо измерять и где это фиксировать. Начать можно с того, что в любой автоматизированной системе, связанной с обработкой инцидентов, будь то Service Desk, Security Orchestration, Automation and Response (SOAR) или SIEM-решение, инцидент меняет свой статус и оставляет при этом временные метки, так называемые timestamps. Статусы отделяются друг от друга (и делятся внутри себя) вехами на схеме (обозначены флажками). Метрики, о которых мы будем говорить, — это интервалы времени между вехами. В зависимости от того, как реализован процесс реагирования на инциденты, эти метрики могут фиксироваться разным образом: вручную или автоматически. Как правило, индустриальные платформы по управлению инцидентами типа Service Now или отечественной Security Vision имеют пренастроенные статусы и возможность их кастомизировать.

Давайте же взглянем на жизненный цикл инцидента ИБ с наложенными на него вехами.

С точки зрения развития атаки можно выделить три основные метрики:

• TTA (time to attack) — время от попытки преодоления периметра до начала выполнения вредоносных действий. Под периметром можно понимать как внешний периметр для хакера вне организации, так и любой узел сети для внутреннего агента;

• TPT (threat presence time) — время присутствия злоумышленника в сети до его устранения;

• TAT (threat active time) — время активной деятельности киберпреступника до момента локализации, когда его дальнейшее продвижение внутри сети невозможно.

С точки зрения реагирования на инцидент метрики будут выглядеть так:

• TTR (time to respond) — время реагирования, которое защитники тратят на локализацию, устранение и восстановление. Здесь важно заметить, что это время отчитывается с момента, когда принято решение, что делать;

• TTC (time to contain) — время локализации (когда дальнейшее продвижение агента угрозы становится невозможным);

• QWT (queue wait time) — время ожидания в очереди (с момента регистрации инцидента до его назначения исполнителю или передачи в автоматизированную систему для обработки);

• TTQ (time to qualify) — время верификации, то есть определения легитимности обнаруженной активности (исключение ложноположительного срабатывания);

• TTI (time to investigate) — время оценки, то есть сбора информации об инциденте: его масштабе, приоритете и иных необходимых сведений для принятия решения о дальнейшем реагировании (и самого принятия решения о реагировании);

• HT (handle time) — время владения заявкой, то есть период, когда инцидент находится в руках команды реагирования.

Как получить релевантные метрики и зачем это нужно

Осталось ответить на два вопроса: зачем нам нужны эти метрики и как их получить.

Начнем с первого. Метрики нужны для принятия управленческих решений. Есть метрика, например время ожидания в очереди. Для нее назначен ключевой показатель — например, 15 минут. Превышение этого значения может свидетельствовать, например, о необходимости нарастить штат. Другой пример: верификация и оценка инцидента периодически выходят за рамки назначенных показателей. Это может свидетельствовать о том, что аналитикам не хватает данных и нужна автоматизация обогащения информации об инциденте (например, внедрение базы с данными активов и интеграция системы, обрабатывающей инциденты с этой базой).

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

Объясняем на урук-хаях

За примером долго ходить не буду. Ну что наглядно покажет нам важность метрик в процессе реагирования на инцидент? Конечно, старый добрый Толкин и экранизация его романа. Итак, объяснять будем на битве при Хельмовой Пади из фильма «Властелин колец: Две крепости».

Как вы, наверное, помните, кульминационным моментом эпизода стал взрыв созданной Саруманом бомбы. Для начала взрывное устройство было беспрепятственно пронесено под стену — хотя Теоден и Арагорн видели это, они не поняли, что происходит, и не помешали атакующим. Только когда Арагорн увидел бегущего с факелом урук-хая, он осознал угрозу и попросил Леголаса немедленно застрелить орка. Однако остановить его не удалось — бомба проделала брешь в стене, и атакующие прорвались внутрь цитадели.

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

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

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

Посмотрим на этот эпизод из фильма с точки зрения метрик реагирования на инциденты:

• Арагорн достаточно быстро увидел бегущего с факелом урук-хая, то есть события ИБ начали поступать почти сразу;

• урук-хай уже преодолел часть пути, прежде чем Арагорн начал что-то подозревать. Можно считать это первичным срабатыванием средств информационной защиты;

• урук-хай продвинулся еще дальше, и только тогда Арагорн осознал всю опасность ситуации и стал кричать Леголасу (мы можем условно сказать, что в голове Арагорна сработало корреляционное правило: «бежит орк с каким-то подозрительным горшком и факелом, опасно»). В сфере ИБ так выглядит подозрение на инцидент, которое также называют alert;

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

Подводя итог работе SOC в лице защитников крепости, мы видим, что обнаружение атаки было почти мгновенным, верификация и оценка — запоздалыми, а ответ — слишком слабым. Можно сказать, что совокупность всех шагов от обнаружения до окончания реагирования (как минимум до окончания локализации[1]) должна быть несколько меньше времени атаки. Разумеется, следует стремиться определить конкретные значения, например 10 минут на взятие в работу, а 15 — на верификацию.

Как оценить время атаки и реагирования

Время атаки можно получить минимум двумя способами:

• анализ истории аналогичных инцидентов. Для типовых инцидентов собрать информацию не составит труда, но данные о сложных атаках могут отсутствовать (тот же самый аргумент, что и в случае с методикой моделирования рисков RiskLens: не всегда исторические данные помогут спрогнозировать будущее, так как контекст киберинцидента все время меняется). Тем не менее изучение журналов поможет построить более точные предположения;

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

Остановимся на моделировании. Используя все тот же пример из «Властелина колец», вообразим, что мы смотрим на равнину перед стеной Хельмовой Пади с какой-то высокой точки. Нам сразу станет заметно, что урук-хай мог бежать по прямой: быстро, но его при этом было бы прекрасно видно. А вот тут есть еще одна тропка, неровная, но ее со стены хуже видно, там еще одна… Мысленно представим себе, что с помощью некой сверхсилы мы остановили время для всех участников битвы и заставили урук-хая бегать по этим тропкам, засекая его попытки с секундомером. В итоге мы получим некоторую совокупность маршрутов с временем прохождения. В нашем случае — маршрутов атаки и времени атаки.

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

Время реагирования

Как оценить параметры реагирования:

• анализ журналов и цепочек событий. При наличии истории инцидентов, а также фиксации заявок автоматического реагирования можно получить достаточно достоверное распределение попыток реагирования и локализации угроз;

• ручной или упрощенный анализ. Если системы автоматизации не используются, то цепочки событий придется изучать вручную. Нередки случаи, когда не фиксируются отдельные этапы обработки инцидента и есть только время открытия и закрытия событий. Тогда остается лишь интервьюировать сотрудников SOC.

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

Чтобы проиллюстрировать этот тезис, вернемся к битве при Хельмовой Пади. Расширим наш эксперимент, попросив Арагорна и Леголаса много раз повторить обнаружение и реагирование (стрельбу из лука), пока урук-хай повторяет попытки атаковать. А мы будем держать секундомер и записывать.

Итак, у нас есть множество измеренных попыток атаковать и обнаружить инцидент и отреагировать на него. Что мы с этим можем сделать?

Используем метрики для повышения уровня защиты

Сравнив две таблицы (для простоты мы сложили обнаружение и реагирование), мы получим такую картину:

 

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

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

Возвращаясь к аналогии с эпизодом из «Властелина колец»: такие результаты измерений говорят о том, что Арагорн вовремя заметил, а Леголас успел остановить урук-хая своими стрелами и орк не добежал до стены с бомбой. Это упрощенная картина, однако она вполне наглядно отражает соотношение возможностей атакующего и защитников.

Любопытный читатель, знакомый с теорией вероятности и статистикой, обоснованно возразит: сравнивать минимальные и максимальные значения диапазонов, конечно, хорошо, а как насчет сопоставить количество попыток атаки и реагирования и судить уже по этим показателям?

Да, уважаемый читатель, ты прав. Если мы возьмем совокупность времени атаки для конкретного инцидента, то все попытки атаковать и все попытки обнаружить и отреагировать (для упрощения мы не стали включать время ожидания в очереди (QWT), время верификации и оценки (TTQ и TTI), величины которых не столь важны с точки зрения иллюстрации представляемой идеи) можно представить в виде распределения на графике. Чем выше кривая от горизонтальной оси, тем чаще встречается такое значение. В нашем случае горизонтальная ось показывает время, а вертикальная — количество раз, когда атака (реагирование и обнаружение) попали в тот или иной временной диапазон. Таким образом, если мы изобразим попытки атаковать и обнаружить (отреагировать) и представим их в виде таких же распределений, то появится возможность наложить графики друг на друга.

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

Еще одним интересным приложением метрик реагирования является теория массового обслуживания, а именно использование двух следствий из теоремы Эрланга.

А. К. Эрланг в своей работе 1909 года показал, как можно рассчитать вероятность отказа в обслуживании на примере случайного трафика телефонных сетей. Его формулы позволяли установить, сколько нужно операторов, чтобы обеспечить желаемый процент соединений с заданным временем ожидания. В нашем случае, очевидно, речь идет о количестве аналитиков SOC и вычислительных мощностей, необходимых для предотвращения реализации недопустимых событий.

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

Где взять метрики работы с инцидентами для вашей компании

Обычно источником данных для метрик реагирования на инциденты является SIEM-решение или Service Desk. В этих системах фиксируется (как минимум) открытие и закрытие инцидента, несколько реже — его более полная история, в том числе переход из одного статуса в другой (например, от «В очереди» к «В работе»).

Однако для оценки времени атаки требуется (как минимум) выяснить, какие системы будут потенциальной целью. Если в организации были сформулированы недопустимые события или было проанализировано воздействие на бизнес (business impact analysis, BIA), то список таких целевых систем известен. Если же подобного перечня нет, то можно использовать косвенные данные, например:

• проанализировать воздействие инцидентов ИБ на бизнес и узнать, какие информационные системы и зависящие от них процессы особенно важны для организации;

• предположить, что может случиться с этими системами: кража, порча информации, прерывание процессов или утечка данных. Сформулировать сценарии атаки;

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

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

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

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

Метрики нужны как кислород, или Немного про MaxPatrol O2

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

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

• замедлению атаки (используя харденинг ИТ-инфраструктуры или сегментацию сети);

• повышению заметности атаки (улучшая способности организации к их обнаружению, особенно в тех местах, через которые проходят маршруты большинства атак);

• более раннему и оперативному реагированию (за счет автоматизированного анализа и приоритизации инцидентов, а также автоматизированного реагирования на них).

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

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

Мы не будем играть в игру «Найдите различия» и сразу перечислим, чем реагирование на инциденты c MaxPatrol О2 отличается от обычного:

• обнаружение и анализ инцидента — постоянный процесс. Цепочки атак обновляются по мере продвижения злоумышленника: с учетом знаний о техниках, используемых хакерами, MaxPatrol O2 актуализирует информацию об инциденте и его приоритете;

• выбор способа реагирования базируется на регулярно обновляемой информации, рекомендации постоянно релевантны. Это отражается в двух метриках, касающихся плейбуков*: TTСP (время выбора плейбука) и TTEP (время выполнения плейбука);

• инцидент оценивается в основном автоматизированным способом (базируясь на данных об ИТ-инфраструктуре и знании тактик и техник атакующего) с учетом возможного маршрута атаки;

• оценка инцидента сотрудником (частичная) на основе продвинутой визуализации цепочек (маршрутов) атак;

• проводится автоматизированное прогнозирование, к каким недопустимым событиям может привести цепочка атаки;

• для каждой цепочки атаки устанавливается уровень опасности, на основании которого аналитик SOC может сделать вывод о приоритетах в реагировании;

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

  * Плейбук (дежурная процедура, сценарий реагирования) — заранее заготовленный сценарий действий по инциденту. Например, получение данных о принадлежности хоста с определенным IP, блокировка учетной записи, закрытие порта и т. д. Плейбуки могут иметь модульную конструкцию. Для конкретного типа инцидента может разрабатываться индивидуальный плейбук, для распространенных типов инцидентов используются готовые плейбуки. Время, которые мы тратим на выбор готового плейбука или сборку нового из типовых фрагментов, мы называем «время выбора плейбука» (time to choose playbook, TTСP). Время выполнения плейбука (time to execute playbook, TTEP) означает, сколько времени отняло выполнение всех действий по плейбуку (вручную и/или автоматизированным способом). Наш продукт подбирает такие плейбуки автоматически.

Краткие выводы

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

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

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

• реагирование на инциденты может быть оценено рядом метрик, из которых две наиболее важные – время атаки и время реагирования;

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

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

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

Ну а самый важный вывод, который мы можем сделать относительно метрик инцидентов ИБ, такой: чтобы управлять, нужно измерять и делать это правильно!

---

[1] Здесь следует сделать небольшое замечание. Реагирование, согласно NIST 800-61 rev2, — это действия от начала локализации угрозы (когда она далее уже не распространяется и уже не опасна, хотя все еще здесь), включая время от начала до конца ее устранения (когда ее больше нет в нашей ИТ-инфраструктуре), до окончания восстановления (когда все опять стало, как до инцидента). Необходимым условием для успешного завершения реагирования является быстрая локализация угрозы, дальнейшие действия могут выполняться с той скоростью, которую позволяют имеющиеся в наличии ресурсы организации и приоритет инцидента.