Расследование инцидентов безопасности с использованием Splunk
Большинство корпоративных данных – машинно-генерируемые. Корпоративные системы и технологическая инфраструктура формируют огромное количество машинных данных: лог-файлов, системных журналов, данных системных метрик и т.д.
Splunk представляет собой платформу для машинных данных. Позволяет собирать и индексировать любые машинные данные практически с любого источника, Splunk предоставляет средства для поиска, отслеживания, анализа и визуализации данных для получения полезных сведений.
Рассмотрим жизненный цикл данных в Splunk:
Для того, чтобы осуществлять какие-либо действия с данными в Splunk, необходимо их проиндексировать. После того, как данные проиндексированы, предоставляется возможность воспользоваться инструментом поиска в собранном объеме данных и проводить расследование инцидентов. В процессе исследования данных происходит формирование базы знаний: извлечение необходимых полей из данных, формирование справочников (например, текстового описания кодов событий), присвоение типов событий, тегов, создание макросов. На следующем этапе настраиваются необходимые поисковые запросы, формируются оповещения при возникновении определенных типов событий. На последнем этапе строятся необходимые аналитические отчеты, которые могут запускаться по расписанию или по запросу.
В данной статье рассмотрим процесс, происходящий на втором этапе жизненного цикла данных в Splunk, а именно процесс расследования инцидента безопасности.
Итак, в организации исчезла критически важная информация из базы данных. Нам необходимо выяснить, кто это сделал, когда, зачем, какие еще события связаны с данным инцидентом и т.д. В организации используется платформа Splunk. К ней подключены в качестве источников данных СУБД, контроллеры домена, серверы, сетевое оборудование. Собираются системные журналы и метрики, включен аудит БД, данные syslog и SNMP с сетевого оборудования и другие события.
Заходим в консоль Splunk и начинаем расследование. Изначально необходимо выяснить, от имени какой учетной записи произошло удаление из критически важной таблицы БД. Вводим в поисковую строку запрос:
Каждая дополнительная команда или ключевое слово в поисковой строке Splunk позволяет отсечь от уже отобранного объема ненужные события и в итоге получить искомый результат.
Рассмотрим последовательно каждую команду:
«host=stg-srv-sql» — выбираем все события, пришедшие с сервера БД;
«EventCode=33205» — в нашем случае, события аудита сервера БД записываются в журнал безопасности Windows; ищем все события аудита сервера MSSQL имеют код 33205;
«VeryCriticalDB» — ключевая фраза с именем БД;
«DELETE» — интересуют только события удаления.
После запуска поиска Splunk вернет нам все события, удовлетворяющие заданным нами условиям:
Мы можем просмотреть событие в «сыром» виде, значения полей, которые удалось извлечь Splunk, отобразить данные в виде таблицы и т.д. Нас интересует значение поля «session_server_principal_name». Событие удаления произвел кто-то под доменной учетной записью «lovkachev.f». У нас нет информации, кто это. Мы видим данную учетную запись первый раз.
Продолжаем расследование. Учетная запись доменная, и мы хотим узнать, кто и в какой момент времени её создал. Ввиду того, что контроллеры домена подключены к Splunk в качестве источников, мы можем сделать это с помощью того же поискового сервиса Splunk. Вводим следующий поисковый запрос:
«host=stg-ad*» — выбираем все события, пришедшие с контроллеров домена;
«Создана» — ключевая фраза, позволяющая нам отфильтровать события создания учетной записи;
«lovkachev.f» — указываем, какая учетная запись нас интересует.
Либо можно использовать в запросе значение поля кода событий 4720 (событие создания учетной записи пользователя):
Splunk вернул нам событие создание учетной записи пользователя «lovkachev.f». Просмотрев текст события, мы можем определить, кто создал данную учетную запись. А это уже знакомый нам товарищ: Бедов.Г. – администратор, который недавно конфликтовал с руководством организации.
Продолжаем расследование. Теперь нас интересует, ограничился ли злоумышленник только удалением записей из БД. Посмотрим, какие еще права предоставлялись пользователю «lovkachev.f». Найдем события добавления данной учетной записи в группы службы каталогов. Введем следующую поисковую строку:
«host=stg-ad*» — ищем события контроллеров домена;
«Добавлен член * группы» — выбираем события добавления учетной записи в группу;
«lovkachev.f» — указываем, какая учетная запись нас интересует;
«| table «Имя группы»» — формируем таблицу из значений поля «Имя группы».
Splunk сформировал нам перечень групп, в которые добавлялась учетная запись пользователя «lovkachev.f»:
Мы видим, что помимо прав на SQL сервер, учетной записи были предоставлены права на управление сетевыми устройствами (группа NetworkAdmins). Необходимо определить, не производил ли злоумышленник изменений конфигурации сетевого оборудования. Используем следующий запрос:
«sourcetype=»cisco:ios»» — ищем события от источников типа «cisco:ios»;
«lovkachev.f» — указываем, какая учетная запись нас интересует;
«sourcetype=»cisco:ios» «lovkachev.f» | table _time host message_text» — сформируем таблицу из времени события, источника и текста сообщения.
Оказывается, злоумышленник успешно зашел на сетевое устройство с IP-адресом 172.16.10.3 и произвел добавление нескольких разрешающих строк в access-list:
На этом моменте мы завершим расследование в рамках данной статьи. Но администратор безопасности мог бы продолжить: например, определить, с какой машины «lovkachev.f» подключался к БД, и просмотреть, какие процессы были запущены в рамках его сессии и т.д. Кроме того, администратор безопасности для оперативной реакции на подобные инциденты в будущем, мог бы сформировать оповещения: например, отправку письма по событию добавления пользователя в ключевые группы службы каталогов, по событиям изменения конфигурации сетевого оборудования и другим важным событиям.