Чтобы схватить хакера, нужно понимать: во время атаки он зачастую использует те же инструменты, что и системный администратор (а заодно и рядовые пользователи сети). Значит, при поиске нелегитимной активности стоит обращать внимание не на запуск редких и специализированных утилит — гораздо важнее, кто и где ими пользуется. Как правило, это приводит к заметному снижению числа ложных срабатываний.
В нашем NTA-продукте PT NAD (PT Network Attack Discovery) реализован автоматизированный механизм профилирования хостов. Он наблюдает за сетевой активностью через призму атомарных детектов, при этом экспертные правила обнаружения атак дополняются адаптивной логикой машинного обучения. Давайте разберемся, как все устроено.
Работа с данными
Среди множества данных о сетевых сессиях, проходящих через PT NAD (в среднем — более 7 ТБ в сутки), нам нужно выделить информацию, которая характеризует сетевые действия пользователей. В этом нам помогут атомарные детекты.
Атомарное событие — это неделимое событие на хосте, например, открытие порта или авторизация с новым логином. Иными словами, их нельзя представить в виде совокупности других событий. При разработке соответствующих атомарных детектов мы полагаемся на помощь экспертов, которые анализируют разные виды вредоносной деятельности. Отметим, что подобные события могут происходить и в рамках легитимной активности пользователей, но в этом случае они будут предсказуемы (ведь в устоявшейся сети на узлах совершаются примерно одни и те же действия). При этом резкие изменения в поведении хоста послужат сигналом: вероятно, там происходит что-то аномальное. Не факт, что это злоумышленник — возможно, инженеры переносят хост в другую сеть или перепрофилируют под другие задачи. Тем не менее, если на сервере бухгалтерии начинается активность, свойственная системным администраторам, мы должны об этом знать.
Рассмотрим, как формулируются правила, на примере события new_port:
- Если на узле внутри сети открыт порт, который ранее был закрыт, и пользователь с ip1 идет туда впервые, но при этом пользователь с ip3 туда уже ходил, система не фиксирует атомарное событие.
- Если пользователь с ip1 впервые идет по протоколу HTTP на порт 80 ip2 и до этого туда уже ходил пользователь с ip3, но по протоколу TLS, система фиксирует атомарное событие.
Последовательность событий для абстрактного хоста Х будет выглядеть следующим образом (см. рис. 1).
На рис. 1 показаны атомарные события и разница во времени между их наступлением: на хосте найден новый баннер для клиента, затем идет серия резолвов доменных имен и фиксируется передача исполняемого файла.
Решение задачи
Какую информацию мы можем извлечь из последовательности атомарных событий? В первую очередь саму их последовательность :) Благодаря этому мы сможем обучить статистический алгоритм: он будет предсказывать следующее наиболее вероятное событие с учетом имеющейся истории и сравнивать с фактически произошедшим. Если случившееся в реальности событие маловероятно, мы можем с определенной долей уверенности утверждать, что на хосте происходит нечто аномальное.
Теперь чуть подробнее про статистическую модель. В качестве baseline для формирования первичных признаков используется марковская цепь. Это представление данных, в котором вся полученная во время обучения информация сжимается до таблицы размера NxN (где N — количество рассматриваемых в системе атомарных событий). На пересечении строки и столбца указывается вероятность события (см. табл. 1).
% | Executable files | New client banner | New connection | New login | New open port | Resolve unusual dns | SSH tunnel |
| Executable files | 0.0 | 0.0 | 0.00 | 0.00 | 0.0 | 0.00 | 0.0 |
| New client banner | 0.0 | 0.0 | 0.00 | 0.00 | 0.0 | 0.00 | 0.0 |
| New connection | 0.0 | 0.0 | 97.92 | 0.69 | 0.0 | 1.39 | 0.0 |
| New login | 0.0 | 0.0 | 0 | 100.00 | 0.0 | 0 | 0.0 |
| New open port | 0.0 | 0.0 | 0.00 | 0.00 | 0.0 | 0.00 | 0.0 |
| Resolve unusual DNS | 0.0 | 0.0 | 2.06 | 75.00 | 0.0 | 97.94 | 0.0 |
| SSH tunnel | 0.0 | 0.0 | 0.00 | 0.00 | 0.0 | 0.00 | 0.0 |
Сумма значений по горизонтали дает единицу — это и есть вероятности возникновения определенных пар алертов. Соответственно, при получении на инференсе цепочки событий (см. рис. 2) мы можем посмотреть на соседние алерты и вычислить вероятность перехода. Используя табл. 1, получаем: [97.92, 1.39, 97,94, 97.94]. Далее мы можем агрегировать данные, чтобы получить нужное нам значение.
Но возникает проблема: алерты, которые приходят через одну секунду и через неделю, для такого алгоритма равноценны. Одна и та же цепочка событий может быть мирной или злодейской — разница лишь во времени их наступления. Значит, нам нужно отделить зерна от плевел.
Для решения этой задачи мы можем воспользоваться тем же статистическим алгоритмом (марковской цепью), но придется немного его модифицировать. Прежде всего берем каждый хост и строим матрицу среднего времени перехода между состояниями — см. табл. 2 (NaN означает, что данных по указанной паре нет).
| % | Executable files | New connection | New login | New open port | Resolve unusual DNS | SSH tunnel |
| Executable files | NaN | NaN | NaN | NaN | NaN | NaN |
| New connection | NaN | 111.766 | 2161.000 | NaN | 13.5 | NaN |
| New login | NaN | NaN | 1080.875 | NaN | NaN | NaN |
| New open port | NaN | NaN | NaN | NaN | NaN | NaN |
| Resolve unusual DNS | NaN | 126.0 | NaN | NaN | 0.0 | NaN |
| SSH tunnel | NaN | NaN | NaN | NaN | NaN | NaN |
Далее переходим к вероятностям: это позволит оценивать аномальность хоста по двум критериям — самой последовательности событий и разницe во времени между алертами. Идея проста: чем разница во времени между алертами ближе к среднему значению, тем более ожидаемо атомарное событие.
Например, для последовательности событий на рис 2. делаем следующее:
- Вычитаем по модулю из фактического значения (493.0s) средние значения по нужной строчке таблицы (определяется исходящим типом алерта, у нас это new_connection). Получаем: [NaN, 381.235, 1668, NaN, 479.5, NaN].
- Берем обратное значение для всей строчки таблицы, чтобы «поощрить» маленькие значения (читай — небольшое отклонение от среднего). Получаем: [NaN, 0.0026, 0.000599, NaN, 0.0020, NaN].
- Нормируем (например, сигмоидой). Получаем: [NaN, 0.50009617, 0.11521446, NaN, 0.38468936, NaN].
- Остается взять значение из второго столбца, поскольку мы рассматриваем переход из new_connection в new_connection.
- Повторяем для всех пар в цепочке и усредняем значения.
Визуализация
При работе на потоке описанный выше механизм строит графики, где ось X — время, а ось Y — предсказуемость хоста (высокий график — более ожидаемое поведение, и наоборот). Разные хосты обозначены разными цветами (см. рис. 3).
Кроме того, у нас есть исторические данные по хостам и сети в целом, поэтому мы можем оперировать несколькими графиками для каждого хоста (см. рис. 4)
***
Остается главный вопрос: «Что делать с этими графиками?» :) Как минимум показать экспертам и разобраться, почему мы получили именно такие данные. Также можно установить пороговые значения и посылать в интерфейс PT NAD алерты, если предсказуемость хостов опустится ниже заданного уровня. Наконец, самый интересный вариант — еще больше автоматизировать процесс с помощью ML :) Например, можно взять графовые модели и автоэнкодеры, обучить исключительно на легитимном трафике и посылать алерты, когда происходит нечто аномальное.
P. S. Клиффхэнгера не будет, но это многосерийный фильм, так что продолжение следует… :)
