Базовая аналитика в технологиях моделирования UEBA

Сезон 1, эпизод 2

Контекст: «Какие существуют примеры базовой аналитики UEBA в ИБ?»

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

Начинаем собирать конструктор

8ec85fb3c748546fbc46f66c83abe34c.png

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

Давайте предположим, что в некоторую песочницу попадает документ из почты. И тогда в песочнице искусственно ускоряется время… Странно, да? Дело в том, что современное вредоносное программное обеспечение часто создается атакующими с некоторым отложенным стартом. То есть вредоносный код как бы спит и проснуться он может, например, через 3 месяца. Однако, недопустимо такое количество времени ждать проверки файла — например, в корпоративных сетях документы — это часть бизнес-процесса. Именно для этого в песочнице ускоряется время, и система анализирует поведение файла. Это и есть «поведенческая аналитика сущностей».

Будем считать, что мы посмотрели, как UEBA используется в песочницах. А где он может использоваться ещё? Например, в SIEM, DLP, IDP, DCAP и EDR — можно перечислять весь набор акронимов из информационной безопасности, ради забавы их можно было бы выстроить ещё и по алфавиту.

И на этой позитивной ноте, предлагаю смело переходить к алгоритмам.

Базовая vs расширенная поведенческая аналитика

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

a139b2fc3f18dae858e577eb2048186d.png

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

1) новое/редкое действие,

2) правила и ограничения,

3) базовые линии.

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

А все остальные алгоритмы предлагаю отнести к расширенной аналитике, и этому вопросу посвятим третью статью в цикле.

Ну и немного примеров

Алгоритмы обнаружения отклонений от базовой линии

120dbe49621f01e7cef8002954185f93.png

Принцип: Фокусировка на индикатор

Индикаторов для пары событий от одной ОС может быть много, например, в Ankey ASAP для событий Windows № 4624/4625 учитываются 12 индикаторов. Их, в свою очередь, одновременно оценивают разные анализаторы (базовой линии), под капотом у которых алгоритмы, основанные на статистике и на методах классического машинного обучения (линейная регрессия, метрика косинусного расстояния и т.д.).

 Алгоритмы обнаружения нового/редкого действия

cffd1376aa6d2bbf9440c8eec754f2b1.png

Принцип: Фокусировка на событие

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

Алгоритмы обнаружения на основе правил

Примеры условий:

ЕСЛИ (тип события = "Неуспешная аутентификация" И username_in_event_1 = username_in_event_n И destination_host_in_event_1 = destination_host_in_event_n) И n >= 10 за 10 минут ТО alert "Попытка подбора пароля пользователя 'username' на хосте 'destination'"
ЕСЛИ ((тип события = "Разрешение соединения" или тип_события = "Запрет соединения") И destination_ip_in_event_1 != destination_ip_in_event_n И port_in_event_1 = port_in_event_n) И n >= 30 за 5 минут ТО alert "Cканирование сети на доступность порта port"

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

Алгоритмы формирования статистических границ (нестареющая классика)

Сюда отнесем контрольные карты в статистическом управлении процессами, настройками параметров в АСУ ТП, скоринговый балл в системах и т.п. По сути контрольные карты (КК) — это классический метод, позволяющий отслеживать изменение показателей во времени для определения стабильности объекта наблюдения. Почти 100 лет назад физик Уолтер Эндрю Шухарт продемонстрировал важность КК для повышения стабильности характеристик усилительных ламп при их изготовлении. С тех пор количество характеристик качества, которые задаются и контролируются с помощью контрольных карт резко увеличилось.

 Основные цели применения контрольных карт в информационной безопасности:

• непрерывный и последовательный контроль показателей объекта наблюдения;

• прогнозирование и понимание показателей объекта наблюдения;

• оценка последствий изменений.

Для алгоритмов в Ankey ASAP контрольные границы — это сектор, в который попадают значения при стабильном (нормальном) состоянии наблюдаемого объекта.

cb75419efc244a7f2d222990183279e6.png

На рисунке CL — базовая линия (среднее значение или медиана по объёму данных), LCL — нижняя контрольная граница, UCL — верхняя контрольная граница. Зеленым подсвечены показатели, попадающие в норму, красным — в аномалию.

В общем, как мы понимаем, алгоритмов в базовой аналитике много, примеров можно привести море, но предлагаю остановиться и по традиции подвести итоги.

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

 И вновь приглашаю вас, коллеги, товарищи,  друзья, к обсуждению.

 Как думаете:

Оправдано ли разделение аналитики на базовую и на расширенную, если да, то почему и если нет, то почему?

Как можно было бы еще систематизировать алгоритмы поведенческой аналитики?

 Пишите, буду рада дискуссии!

© Habrahabr.ru