За 2024 год количество кибератак на российские компании увеличилось в 2,5 раза и достигло 130 тысяч. Развитие технологий и тренд на автоматизацию приводит к постоянно увеличивающемуся количеству устройств/программных решений, соответственно растет возможный периметр атак. Как следствие – увеличивается нагрузка на аналитиков SOC. В исследовании компании Vectra AI 2024 года “State of Threat Detection and Response Research Report: The Defenders’ Dilemma” приводятся такие данные:
- ¾ аналитиков SOC (71% опрошенных) беспокоятся, что могут пропустить реальную атаку в потоке событий;
- Более половины респондентов (54%) сказали, что различные решения, которые они используют в работе, скорее увеличивают нагрузку на персонал вместо того, чтобы освобождать от рутины и облегчать работу.
Мы в исследовательском центре UDV Group задумались, как можно улучшить работу SOC и помочь аналитикам? Естественно, что при таком количестве событий и инцидентов, которые поступают в современный SOC (здесь уже можно говорить о настоящей BigData), логично использовать ML.
С помощью ML можно решать множество задач в SOC: выявление аномального поведения, построение и прогнозирование цепочек атак, поиск связанных с инцидентом событий и т.п. Мы остановимся на одной из таких задач – снижение количества ложно-положительных инцидентов на 1ой линии SOC.
Мы пока не можем настолько доверять модели, чтобы позволить ей самостоятельно решать, какой инцидент истинный, а какой – нет. И причина не в том, что модель плохая или недостаточно обучена, а в том, что модель сильно зависит от данных, которые мы в неё загружаем.
При классификации инцидентов модель может ошибаться по ряду причин:
- Не все данные, на которые ориентируется аналитик при принятии решения, попадают в модель;
- Данные меняются – на защищаемых объектах меняются пользователи, роли, политики безопасности, инфраструктура и т.д.;
- Есть вероятность некорректной экспертной оценки данных, на которых обучалась модель.
Поэтому мы решили сконцентрироваться на приоритизации – подсветить аналитику потенциально наиболее опасные инциденты, тем самым сократив время на их обработку. Если модель посчитает, что инцидент вероятно истинный, то он будет перемещен в начало очереди в IRP, и аналитик обработает его быстрее. Дополнительно модель дает комментарий, почему она дала инциденту именно такую оценку.
Модуль приоритизации позволяет:
- Обрабатывать потенциально более опасные инциденты в первую очередь;
- Окончательное решение оставить за аналитиком и не переживать о пропуске реального инцидента;
- Опираться не только на оценку модели, но и на её интерпретацию этой оценки.
Как модуль встроен в процесс обработки инцидента?
Инцидент из SIEM приходит в SOAR. SOAR отправляет запрос по API в модуль приоритизации (FP-Service на схеме). Модель оценивает инцидент и возвращает оценку обратно в SOAR, и далее инцидент с оценкой и дополнительной информацией поступает в IRP к аналитику.
Как происходит обучение модели?
Для обучения модели мы используем CatBoost — библиотеку на базе градиентного бустинга, т.е. алгоритма ансамблевого машинного обучения, в котором каждое следующее дерево обучается на ошибках предыдущего. Деревья учатся на инцидентах, размеченных аналитиком. Дополнительно к разметке «ложный/ истинный инцидент» у нас есть разметка по легитимности: может быть ложный инцидент, который является легитимным действием пользователя или администратора (например, сотрудник несколько раз ошибся при вводе пароля, и возник инцидент «Подбор пароля»). Такие инциденты мы причисляем к истинным, так как на практике для уточнения легитимности инцидента аналитик обращается к заказчику, а у модели этих данных нет, она работает только с признаками события (см. рисунок).
Как проходит онлайн классификация инцидентов?
Инцидент с привязанными к нему событиями приходит в систему, события проходят через модель, которая оценивает их и дает финальную оценку инцидента, например, «Инцидент ложный с вероятностью 0,82».
Предварительные результаты
CatBoost достаточно хорошо разделяет ложные/истинные инциденты (см. гистограмму на рисунке – в зоне неопределенности практически нет инцидентов). Чем ближе к границам 0 или 1, где 0=модель уверена, что инцидент ложный, а 1=модель уверена, что инцидент истинный, тем меньше ошибок. Аналитику оценка выдается в текстовом виде:
- Ложный инцидент
- Истинный инцидент
- Вероятно ложный инцидент
- Вероятно истинный инцидент Не определена
Если вероятность попала в диапазон 0,4-0,6, модель не дает свою оценку, чтобы не ухудшить результаты работы аналитика.
Как это выглядит в интерфейсе специалиста?
Интерфейс аналитика в IRP
К инциденту привязано несколько событий со своей оценкой, и средняя оценка по всем событиям выдается как финальная для инцидента. Кроме того, можно посмотреть значения признаков, с которыми модель раньше не встречалась. Аналитику важно знать, какие признаки событий модель видит впервые, так как обучение идет на исторических данных, а события иногда приходят от новых пользователей, с новых хостов и т.д.
Дополнительно для помощи аналитику мы предоставляем интерпретацию оценки с помощью модуля SHAP. Данный инструмент показывает, какие именно признаки в инциденте и насколько сильно свидетельствуют о принадлежности его к ложному или истинному случаю.
Результаты работы модуля за несколько месяцев
Мы использовали стандартные метрики «ложный/истинный инцидент» без учета зоны неопределенности «скорее ложный/скорее истинный»: при вероятности больше 0,5 – считали инцидент истинным, если меньше – ложным. Поэтому модель здесь ошибается чаще. Плюс провалы на графике чаще всего были вызваны небольшим количеством инцидентов. Например, если за неделю у нас было 10-20 инцидентов, из которых 2 были определены неправильно, метрика сильно падала.
Дополнительно при оценке результатов надо учитывать, что разметка для обучения может быть некорректной – одни и те же действия пользователя даются с разными статусами, их легитимность может быть указана в качестве комментария в текстовом поле, а модель ориентируется только на первые 2 стандартных поля (статус инцидента и статус легитимности). Это также может вызывать провал метрик.
Проблемы применения
| Проблема | Решение |
|---|---|
|
Некорректные статусы закрытия инцидента Заказчиком |
Дополнительная проверка аналитиком статусов с большим расхождением оценки модели и оценки аналитика Организационная работа с Заказчиком |
|
Отсутствие необходимой информации в признаках, которые использует модель, для отдельных правил корреляции |
Постоянный анализ метрик качества работы модели и исключение обработки инцидентов для соответствующих правил корреляции Анализ дополнительных признаков |
|
Наличие в новых инцидентах значений признаков, которые не встречались на этапе обучения модели |
Постоянное периодическое дообучение модели Предоставление аналитику информации о неизвестных значениях признаков Исключение инцидента из обработки моделью, если количество неизвестных признаков велико / признаки являются критичными |
Заключение
В качестве заключения подытожим, на что обратить внимание при самостоятельной разработке модуля приоритизации:
- Если вы получаете разметку от заказчика – согласовать с заказчиком формат, чтобы он соответствовал задаче модели и учитывал нюансы бизнес-процесса. В нашем случае, без дополнительного поля о легитимности мы бы не смогли качественно обучить модель.
- Обращать внимание на кейсы, когда модель сильно разошлась в оценке инцидента с аналитиком.
- Для обучения модели нужен достаточный набор размеченных инцидентов. Лучше всего делать отдельную модель для каждого правила корреляции, но если по этому правилу будут единичные инциденты, то модели будет не на чем учиться. Поэтому мы обучали модель на всех инцидентах, без привязки к правилу корреляции. Но в теории, если набрать достаточно статистики по этим правилам, то можно будет для каждого правила разобрать статус инцидента, по которому это правило сработало. Эта проблема также решается постоянным контролем метрик качества работы модели.
- Новые признаки у событий и новые события: модель необходимо периодически дообучать, и предоставлять аналитику данные, какие признаки были неизвестными. Если таких признаков окажется больше половины события, то от предсказания модели лучше отказаться, потому что результат скорее всего будет недостоверным.
В следующих публикациях расскажем ещё о двух примерах практического применения ML в SOC: выявление аномалий в последовательности событий и создании цифрового ассистента аналитика SOC. Подписывайтесь на нашу рассылку, чтобы не пропустить новые публикации.
