В течение последних 10 лет центры оперативного управления информационной безопасности (Security Operation Center, SOC) и аналитики оперировали такими понятиями как индикаторы компрометации (Indicators of Compromise, IoC), сигнатуры, пороговые (threshold-based) признаки проникновения или попыток проникновения в попытке угнаться за темпом постоянно меняющихся угроз. Это было проигрышное противостояние.

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

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

Часто можно услышать вопрос о том, что отличает UBA от традиционных подходов, основанных на SIEM.

Основывайся на предыдущем поведении.

На наш взгляд, ответ – это история. Существует старое высказывание, которое гласит: «Если вы не помните прошлое, вы будете обречены повторять его». Тоже самое можно сказать и о традиционном SIEM подходе, который заключается в наблюдении в реальном времени за множеством несвязанных событий: удаление или копирование файлов, неуспешные попытки входа, сигнатуры вредоносных программ или чрезмерное число запросов на подключение с определенного IP адреса.

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

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

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

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

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

уведомление, когда пользователь работал с редко используемой информацией в необычное время суток – 4AM и день – воскресенье, а потом послал электронное письмо на почтовый ящик, относящийся к заграничному провайдеру;
уведомление, когда пользователь генерирует события неуспешного входа в систему в то время, когда он обычно не работает;
уведомление, когда пользователь копирует файлы из домашнего каталога другого пользователя, а затем перемещает эти файлы на USB носитель.

Пример работы правила UBA

Причина, по которой UBA настолько эффективна, заключается в том, что она не зависит только от сигнатурной или статической пороговой аналитики.

Давайте рассмотрим это на примере.

В компании отделу безопасности было предложено следить за деятельностью электронной почты всех своих 1000 сотрудников. Невозможно? – Возможно.

Мы можем понять суть проблемы, сосредоточившись только на 5 пользователях (0,5% всех пользователей). Сначала мы применяем традиционную аналитику и просматриваем их активность в электронной почте (ниже) в течение недели.

Рассматривая этот отчет, вы можете решить расследовать активность пользователей, которые отправили большее число писем, верно?

Вы быстро узнаете, что Molly, которая отправила 90 писем в пятницу, связана с маркетинговой командой, и ее работа связана с рассылкой материалов клиентам по электронной почте за день.
Ложное направление!

Затем вы решаете взять в качестве порогового значения среднее число отправленных писем по всем пользователям за каждый день. Для данных, указанных выше, средний объем электронной почты, отправленный пользователем в любой день, равен 17.

Если бы вы создали правило, которое уведомляет, когда пользователь отправляет более 17 писем за день, вы получили бы 6 предупреждений в течение этого периода времени. Четыре из этих предупреждений вернут вас к Molly.

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

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

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

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

Это можно было бы более точно перевести как «уведомление, когда пользователь отклоняется на два или более стандартных отклонения от среднего значения» (колонка AVG+2SD).

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

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

Определение аномалий с использованием анализа поведения пользователей