Сезон 1 эпизод 3-й контекст: «Пример расширенной аналитики UEBA в ИБ».

Эта статья по сути заключительная в теме про UEBA в информационной безопасности, то есть ранее были еще публикации: Статья 1, Статья 2.

Итак, переходя к разговорам о расширенной аналитике, обращаю ваше внимание, на то, что такая аналитика, как я считаю, недостаточно часто используется в решениях по информационной безопасности. И в общем, на рынке даже есть решения, у которых расширенной аналитики нет совсем, вроде правил и корреляции достаточно. Но, по моему мнению, это связано с ограничениями, накладываемыми ресурсами, в том числе и на разработку такой системы. Успешная реализация возможна тогда, когда допустим компания разработчик создала хорошую основу, и ныряет с головой в Data Science (в науку, в развитие технологий, в общем куда-то туда ныряет да). И/или компания привлекает к разработке экспертов, с прокаченными компетенциями и использует ими накопленный опыт.

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

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

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

Для статьи в качестве примера я выбрала только один анализатор из расширенной аналитики (анализатор терминальных команд), и постараюсь рассказать о нем в контексте поведенческой аналитики (модуль UEBA Ankey ASAP). Но отмечу, что ранее о нем подробно рассказали мои коллеги еще в прошлом году. Просто про другие анализаторы с расширенной аналитикой можно отдельно писать серии статей, и я этим и планирую заняться в будущем. А сейчас все-таки давайте рассмотрим ограничимся простым примером.

Анализатор обнаружения LotL-атак (терминальных команд)

Анализатор создавался для обнаружения LotL-атак, реализация которых входит в совершенно разные по типу кейсы: детектирование инсайдера, обнаружение скомпрометированного устройства с бекдором или признаки шифровальщика.

По сути LotL атака (Living off the Land - жить за счет земли - популярный термин в сообществе Red team.) – это злоупотребление возможностями уже существующих инструментов в системе. Термин «Living off the Land» был введен на конференции DerbyCon3 в 2013 году и с тех пор завоевал большую популярность в сообществе этичных хакеров, став часто используемым и популярным приемом. Опасность атак типа LotL заключается в том, что их нельзя обнаружить посредством сравнения сигнатур или проверки прав, часто такая атака не оставляет следов в виде вредоносных файлов и системы мониторинга, построенные на базовой аналитике, не создают алерты или инциденты.

За 10 лет существования термина эксперты со всего мира создали много разных классификаторов, алгоритмов и моделей машинного обучения. Вдохновителем для нашей команды экспертов и разработчиков анализатора терминальных команд послужило открытое решение от Adobe Security Team (далее – публичная модель), которое было опубликовано в конце 21 года.

На вход в публичную модель подается выполняемая команда на устройстве, включая все её аргументы, далее из этой команды извлекаются признаки, а затем с помощью предобученных моделей выполняется классификация и команде присваивается одно из трех значений – good, bad, neutral. Предложенный в публичной модели алгоритм классификации, основан на методе Random Forest (это алгоритм машинного обучения), он показал наилучшие результаты по точности и по времени обучения, по мнению Adobe Security Team. В качестве дополнительной меры, на основе справочника плохих команд далее производится поиск паттерна, и, если схожесть команд достигает определенной степени, команда признается плохой. Их решение было тиражировано и проверено другими экспертами в разных концах земного шара.

Для обучения свой модели необходимо собрать набор данных (датасет) с терминальными командами. Датасет должен состоять примерно на 98% из хороших команд и на 2% из плохих. У Adobe есть набор данных по Linux командам, он содержит 1609 плохих команд и почти 24 миллионов хороших. Но, и это ожидаемо, сам датасет они не раскрывают, предоставляя только обученную модель, и это как бы кот в мешке. Принцип работы анализатора терминальных команд Adobe Security Team показан на рисунке 1.

Рисунок 1. Схема решения от Adobe Security Coordination Center[2]

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

Мы собрали свои наборы данных, добились ускорения в обработке, минимум до 400 EPS для входящего потока на одном экземпляре анализатора. Результат выявления плохой команды регистрируется в виде алерта в Ankey ASAP и, если алерт входит в группу инцидентов (а там своя магия группировок), тогда создается еще и карточка инцидента. Принцип работы анализатора терминальных команд Ankey ASAP показан на рисунке 2.

Рисунок 2. Схема анализатора терминальных команд от Ankey ASAP

И теперь мы уже просто пополняем новыми данными и дообучаем наш анализатор. Например, во втором квартале 2023 мы взяли статью о 64 способах запуска Mimikatz и научили наш анализатор терминальных команд обнаруживать 57 способов, еще 7 способов закроем в ближайшее время. А потом еще добавили кое-что из характерных терминальных команд из жизни шифровальщиков и т.д. И это удобно, когда есть своя модель и ее можно дообучать, так и процесс улучшения не прекращается. Злоумышленники придумывают новые подходы, мы тестируем, наблюдаем (у нас создан свой киберполигон) и потом улучшаем классификатор.

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

Компании‑разработчику необходимо, как минимум, иметь ресурсы, чтобы преодолеть ограничения:

1.1. Технические требования:

1.1.1. Киберполигон для создания наборов данных с атаками;

1.1.2. Сценарии и автоматизированные скрипты для нормального поведения («фон» при имитации атак);

1.1.3. Сценарии и автоматизированные скрипты для атак;

1.1.4. Средства защиты информации с архитектурой, поддерживающей алгоритмы обработки потоков данных.

1.2. Профессиональные требования:

1.2.1. Специалисты науки о данных (Data Science);

1.2.2. Дата-инженеры (Data engineer).

1.2.3 Этичные хакеры (эксперты по Информационной безопасности);

И тогда создание программных компонентов с расширенной аналитикой в технологиях моделирования UEBA становится не тривиальной задачей для бизнеса. С другой стороны, государству и бизнесу необходимо защищаться. Хакеры, кибер-террористы, инсайдеры усиливаются и довооружаются за счет ИИ, количество атак и их уровень растет, объем утечек и компрометации всего, и вся просто запредельный. Так что, расширенная аналитика очень нужна, а без UEBA сегодня сложно представить результативный инфобез, согласны?

Расширенная аналитика в технологиях моделирования UEBA