Три слона, на которых держится логирование в Windows
Анастасия Кузнецова, Security Vision
Данное исследование было проведено в рамках проработки агентской истории для целой группы продуктов.
Продолжаем наш цикл статей о типах и методах работы сборщиков данных с конечных точек, или, как принято их называть — агентов. В первой статье мы познакомились с этой сущностью и изучили основные нюансы сбора данных с их помощью. Так как мы в рамках разработки своих продуктов занимаемся и лог-менеджментом, и сбором событий, то хочется поделиться продолжением нашей обширной аналитики в quickstart формате. Поэтому в этом выпуске подробнее разберем функционал и используемые инструменты источников на ОС Windows.
Начнем с того, что самому агенту по большей части все равно, посредством какой технологии производится сбор данных. Однако, при внедрении агентов в собственную инфраструктуру в рамках политики безопасности всегда есть какие-либо ограничения на использование тех или иных инструментов, портов и прочего. В связи с этим и рассмотрим возможные источники передачи данных для агентов.
Если мы хотим собирать данные с конечных точек на ОС Windows, то существует три основных инструмента. Первым является подсистема аудита Windows, хранящая события в формате EventLog. Это средство журналирования событий Windows, в котором регистрируются сообщения операционной системы. События делятся на несколько групп — журналов:
К тому же, некоторые приложения пишут свои собственные события в отдельную папку, к примеру:
В этой папке могут оказаться логи как процессора, так и ПО (звуковых драйверов или того же Kaspersky).
Также существуют отдельные журналы для:
События системных журналов в формате 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.
