Анастасия Кузнецова, Security Vision
Данное исследование было проведено в рамках проработки агентской истории для целой группы продуктов.
Продолжаем наш цикл статей о типах и методах работы сборщиков данных с конечных точек, или, как принято их называть – агентов. В первой статье мы познакомились с этой сущностью и изучили основные нюансы сбора данных с их помощью. Так как мы в рамках разработки своих продуктов занимаемся и лог-менеджментом, и сбором событий, то хочется поделиться продолжением нашей обширной аналитики в quickstart формате. Поэтому в этом выпуске подробнее разберем функционал и используемые инструменты источников на ОС Windows.
Начнем с того, что самому агенту по большей части все равно, посредством какой технологии производится сбор данных. Однако, при внедрении агентов в собственную инфраструктуру в рамках политики безопасности всегда есть какие-либо ограничения на использование тех или иных инструментов, портов и прочего. В связи с этим и рассмотрим возможные источники передачи данных для агентов.
Если мы хотим собирать данные с конечных точек на ОС Windows, то существует три основных инструмента. Первым является подсистема аудита Windows, хранящая события в формате EventLog. Это средство журналирования событий Windows, в котором регистрируются сообщения операционной системы. События делятся на несколько групп – журналов:
К тому же, некоторые приложения пишут свои собственные события в отдельную папку, к примеру:
В этой папке могут оказаться логи как процессора, так и ПО (звуковых драйверов или того же Kaspersky).
Также существуют отдельные журналы для:
-
DNS Manager
-
Failover Cluster Manager
-
IIS Access
-
Task Scheduler History
-
Windows Component Service
События системных журналов в формате EventLog уже имеют некоторую начальную нормализацию и содержат следующие поля:
-
Дата в формате: месяц, день, время и год.
-
Категория события как целое число
-
Уровень события
-
ID безопасности Windows
-
Источник Windows.
-
Ключевые слова журнала событий Windows.
-
Идентификатор событий Windows.
-
Текст сообщения
Для журналов событий существует возможность изменять права доступа на чтение, запись и очистку. В этом смысле особняком стоит журнал безопасности (Security) — право записи в него зарезервировано исключительно для локального органа безопасности Windows (LSASS). Также есть возможность добавлять типы событий в журнал Безопасности и назначать источник из зарегистрированных приложений.
Для первичной аналитики, а тем более расследования инцидентов, информации только с EventLog не всегда бывает достаточно. В связи с этим активно используется другая утилита с расширенными функциями аудита событий – Sysmon, входящий в пакет Sysinternals. По сути, она является системной службой Windows, которая отдает подробные данные о приходящих событиях, сетевых подключениях и драйверах, изменениях файлов и многом другом. Я нашла вот такую карту интересных данных, которые можно собирать с помощью Sysmon (для подробностей рекомендую заглянуть сюда.
Для обеспечения дополнительного уровня безопасности Sysmon обычно устанавливается вместе с другими решениями для защиты конечных точек, такими как традиционный антивирус, система управления событиями (SIEM) или средство обнаружения и реагирования на конечных точках (EDR). Драйвер этой службы позволяет осуществлять сбор сразу при включении устройства, т.е. до запуска основных компонентов компьютера.
Вдобавок, данный инструмент довольно хорошо описан и популярен, а значит, на просторах интернета существует множество готовых конфигураций под различные требования аудита событий.
Единственный существенный недостаток Sysmon — слабая совместимость с классом ОС Linux. Для таких ОС регистрируется только некоторая часть событий, регистрируемых в Windows системах (Event ID 1, 3, 4, 5, 9, 11, 16, 23).
Искать логи в интерфейсе «Просмотра событий» следует в журнале Applications and Services Logs\Microsoft\Windows\Sysmon. Вот пример события:
И наконец, замыкает тройку первостепенных технологий сбора событий средство Event Tracing for Windows (ETW) – трассировка событий Windows. Технология предоставляется в самой ОС по умолчанию и осуществляется на уровне ядра. ETW фиксирует журналы событий, создаваемых драйверами ядра и пользовательскими приложениями. Тот же Sysmon формирует часть своих событий на его основе. Для понимания сути ETW нам понадобится использовать несколько понятий:
· Провайдеры (providers, поставщики событий) — это приложения (например, DLL), у которых есть функции регистрации событий. Именно провайдер отслеживает состояния приложений (или системы) и отправляет события в сессию.
· Сессии (sessions, сеанс трассировки, логгер) — сущности, которые собирают события от провайдеров и передают их потребителям. Одна сессия может потреблять события от одного или нескольких провайдеров. Также сессии сортируют события между собой, чтобы передавать их нужным потребителям.
· Контроллеры (controllers) — это приложения, которые управляют сессиями. Могут создавать или удалять сессии, а также изменять их параметры.
· Потребители событий (consumers) — приложения, которые могут получать и как‑то обрабатывать события от одной или нескольких сессий, а также из файлов.
Провайдеры формируют и передают события о состояниях, происходящих внутри процессов или ядра, а потребители используют эти события для собственных целей (например, для анализа производительности). Схему процесса передачи данных вендор представляет следующим образом:
ETW в своей базовой конфигурации является простым механизмом межпроцессного взаимодействия и функционирует только локально, и в подавляющем большинстве исследований используется как «оборонительный» инструмент.
События от этого источника можно обнаружить в дереве Applications and Services Logs и Windows Logs\Security.
Если вы хотите углубиться в логику работы и базовое администрирование ETW, рекомендую изучить следующую статью, где понятным языком описаны внутренние процессы службы трассировки.
Итак, мы разобрались, откуда и с помощью чего мы можем собирать данные, но какими должны быть сами логи? Ведь, как правильно сказал комментатор под прошлой статьей известно, для корректной работы инфраструктуры и последующего анализа событий недостаточно просто собирать «все, что вижу». Так велик риск засорить процессинг устройств, и при этом сделать оперативное реагирование на события невозможным.
Так что предлагаю некоторые критерии оценки качества передаваемых данных:
-
События должны быть достоверными, то есть нужно быть уверенными, что записанные события действительно случились и что атрибуты событий являются верными;
-
Лог событий должен быть завершенным, то есть предоставлять полную картину действий;
-
У любых записываемых событий должна быть четко определенная семантика, то есть разнотипные события должны различаться.
Данная статья носит исключительно ознакомительный характер и ни в коем случае не говорит о том, какие именно средства сбора событий должны использовать именно вы. Данная статья скорее будет полезна тем, кто только погружается в аудит событий конечных устройств Windows – друзья, теперь вы знаете, куда копать дальше. А в следующей статье расскажем о журналировании в ОС класса Linux.
