Для чего необходим аудит системы windows

Как настроить политики аудита Windows таким образом, чтобы охват мониторинга SOC был полноценным? Рассмотрим оптимальный список политик, а также выделим самое необходимое, отсеяв лишнее.

1. Введение
2. Знакомство с расширенным аудитом Windows
3. Настройка политик аудита
4. Усиление цифровой обороны
5. Выводы

Введение

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

На практике ответы на эти вопросы находятся не всегда. Зачастую при расследовании специалисты отделов ИБ сталкиваются с тем, что аудит не настроен, логи перезаписались, отсутствует единая система хранения и анализа журналов, «перезалит» заражённый хост (популярное решение всех проблем).

Ниже мы разберём один из самых важных этапов, который нужен для того, чтобы расследование не завершилось ещё в самом начале: сбор и хранение журналов аудита. Будут рассмотрены возможности расширенного аудита ОС Windows и его настройка.

Знакомство с расширенным аудитом Windows

Речь пойдёт о настройках для систем Microsoft Windows Vista / Server 2008 и выше. Начиная с указанных операционных систем компания Microsoft сделала шаг вперёд в понимании аудита и управления им. Так появился расширенный аудит. Теперь администраторы и специалисты по информационной безопасности могут управлять аудитом на уровне не только категорий, но и подкатегорий.

Давайте подробнее остановимся на них. Откроем оснастку локальной групповой политики, используя команду «gpedit.msc» (или через «secpol.msc»). Для групповых политик всё будет аналогично, только все действия будут выполняться через «gpmc.msc».

Полный путь к настройкам аудита выглядит следующим образом: Конфигурация компьютера / Конфигурация Windows / Параметры безопасности / Локальные политики / Политика аудита (Computer Configuration / Windows Settings / Security Settings / Local Policies / Audit Policy).

Рисунок 1. Политика аудита

Расширенный аудит, в свою очередь, находится здесь: Конфигурация компьютера / Конфигурация Windows / Параметры безопасности / Конфигурация расширенной политики аудита (Computer Configuration / Windows Settings / Security Settings / Advanced Audit Policy Configuration).

Рисунок 2. Конфигурация расширенной политики аудита

Ниже на рисунке видно, как они коррелируют между собой.

Рисунок 3. Корреляция аудита и расширенного аудита

В общей сложности нам доступны 10 политик и 60 подкатегорий.

Таблица 1. Категории и подкатегории аудита

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

Включим аудит файловой системы, реестра, съёмного носителя и других событий доступа к объектам, а всё остальное оставим в выключенном состоянии (параметр «Не настроено»).

Рисунок 4. Пример настройки аудита доступа к объектам через подкатегории

События аудита могут иметь значение «Успех и отказ», изображённое на рис. 4, или поддерживать только одно из двух состояний. Например, аудит создания процессов (Event ID 4688: A new process has been created) может быть только «успешным» (рис. 5).

Рисунок 5. Аудит создания процессов регистрирует успешные события

Если вы не знаете, нужна ли вам та или иная политика аудита, то ознакомиться с их описанием тоже очень легко. Оно есть на вкладке «Пояснение» соответствующей политики.

Рисунок 6. Вкладка с описанием политики

Для некоторых политик аудита дополнительно нужно настраивать системные списки управления доступом (SACL). Это в первую очередь касается файлового аудита и аудита реестра (альтернатива — использовать весьма специфичную политику «Аудит доступа к глобальным объектам»).

Например, чтобы отслеживать изменения в файле «hosts», откроем его свойства и перейдём в настройки аудита: «Безопасность» -> «Дополнительно» -> «Аудит». Добавим субъект аудита: выбираем группу «Все». Тип аудита — «Успех». Ставим галочки напротив записи данных, удаления, смены разрешений и смены владельца.

Рисунок 7. Настройка SACL

Если в вашей компании уже существуют различные групповые политики с настройками аудита, но вы хотите начать использовать расширенный аудит и подкатегории, то для этого случая Microsoft учла и ввела новую политику, которая называется «Аудит: принудительно переопределяет параметры категории политики аудита параметрами подкатегории политики аудита (Windows Vista или следующие версии)» (Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings). По умолчанию она включена. Проверить состояние политики можно здесь: Конфигурация компьютера / Конфигурация Windows / Параметры безопасности / Локальные политики / Параметры безопасности (Computer Configuration / Windows Settings / Security Settings / Local Policies / Security Options).

Рисунок 8. Принудительное переопределение параметров политики аудита

Дополнительно вы можете управлять политиками аудита через инструмент командной строки «auditpol.exe».

Рисунок 9. Использование инструмента auditpol

Настройка политик аудита

Очень часто можно услышать совет: «давайте включим все политики». Это, конечно, — «путь джедая», но, как показывает практика, не все джедаи добрались до финала.

Для большинства сценариев мониторинга нет острой необходимости включать всё. Это излишне. Включая все политики, вы можете получить гигантский поток событий, в котором очень легко «утонуть». В большой инфраструктуре с несколькими тысячами Windows-хостов поток событий может исчисляться десятками тысяч EPS (событий в секунду). Это порождает другую, не менее сложную задачу: как этим управлять, где это хранить, как обрабатывать.

Предлагаем рассмотреть оптимальный список политик, который может вам понадобиться. Также стоит обратить внимание на то, что фактически настроек две (и, соответственно, существуют две различные GPO). Первая — исключительно для контроллеров домена, так как часть событий (например, ID 4768: A Kerberos authentication ticket (TGT) was requested) фиксируется исключительно на них. Вторая — для рядовых серверов и АРМ пользователей.

Таблица 2. Рекомендуемые настройки аудита Windows

После включения описанных политик у вас будут все необходимые события для мониторинга и расследования инцидентов.

Усиление цифровой обороны

Для максимальной отдачи необходимо выполнить ещё одну настройку — включить логирование «командной строки процесса». Тогда на рабочих станциях и серверах, к которым применяется этот параметр политики, сведения из командной строки будут заноситься в журнал событий «Безопасность» (Security) с ID 4688.

Рисунок 10. Журналирование командной строки процесса

Требования к версии ОС: не ниже Windows Server 2012 R2, Windows 8.1. Данная функциональность также доступна и на ОС Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012 после установки обновления KB 3004375.

Путь к политике: Конфигурация компьютера / Административные шаблоны / Система / Аудит создания процессов (Computer Configuration / Administrative Templates / System / Audit Process Creation). Имя: «Включать командную строку в события создания процессов» (Include command line in process creation events).

Рисунок 11. Путь к аудиту создания процессов

Включаем политику, выставив соответствующее значение, и нажимаем «Применить» (Apply).

Рисунок 12. Настройка «Включать командную строку в события создания процессов» 

После включения этой политики в журнале событий «Безопасность» (Security) в событиях с кодом 4688 появится дополнительное значение «Командная строка процесса» (Process Command Line), где будет отображаться тело исполняемой команды.

В примере ниже демонстрируется, как это поможет заглянуть чуть глубже. На первый взгляд в событии происходит запуск легитимного процесса «opera_autoupdate.exe», но вот строка «Process Command Line» больше похожа на запуск утилиты «mimikatz». Без активированной политики «Включать командную строку в события создания процессов» мы этого не зафиксируем.

Рисунок 13. Детектирование mimikatz

Укрепим нашу оборону и полным журналированием работы самого мощного инструмента ОС Windows — PowerShell. Для этого необходима версия PowerShell 5.0 или выше.

PowerShell 5.0 / 5.1 предустановлен в Windows 10, Windows Server 2016 и Windows Server 2019. Для остальных операционных систем необходимо обновить модуль Windows Management Framework.

Список поддерживаемых ОС:

• Windows Server 2012 R2
• Windows Server 2012
• Windows Server 2008 R2 SP1
• Windows 8.1
• Windows 8
• Windows 7 SP1

Скачайте с сайта Microsoft соответствующую версию, выполните установку и перезагрузку хоста. Также обязательным требованием является наличие Microsoft .NET Framework 4.5 или выше.

Включим регистрацию блоков сценариев PowerShell через соответствующую политику. Она находится по следующему пути: Административные шаблоны / Компоненты Windows / Windows PowerShell (Administrative Templates / Windows Components / Windows PowerShell). Имя: «Включить регистрацию блоков сценариев PowerShell» (Turn on PowerShell Script Block Logging)

Рисунок 14. Путь к аудиту Windows PowerShell

Включаем политику и нажимаем «Применить» (Apply). При этом устанавливать галочку напротив поля «Регистрация начала или остановки вызова блоков сценариев» (Log script block invocation start / stop events) не нужно. Данная функция увеличивает количество регистрируемых событий, которые не несут полезной информации.

Рисунок 15. Включить регистрацию блоков сценариев PowerShell

После включения этой политики PowerShell будет регистрировать в журнале событий трассировки Microsoft-Windows-PowerShell/Operational с кодом события 4104 все блоки сценариев, в том числе — путь, тело скрипта и все используемые командлеты.

Рисунок 16. Пример регистрируемого события 4104

Хорошей практикой является увеличение размера самих журналов, даже если вы используете SIEM или сервер сборщика событий (Windows Event Collector). Например, журнал «Безопасность» (Security) по умолчанию имеет размер 20 МБ. При настроенном аудите на типичном АРМ этого объёма хватит на журналирование нескольких дней, на сервере — нескольких часов, а на контроллере домена 20 МБ не хватит ни на что.

Рекомендуем для всех основных журналов следующие объёмы:

• журнал «Установка» (Setup) — не менее 10 МБ,
• журнал «Система» (System) — не менее 50 МБ,
• журнал «Приложение» (Application) — не менее 50 МБ,
• журнал «Безопасность» (Security) — не менее 200 МБ (для контроллера домена — не менее 500 МБ).

При этом оставляем функцию перезаписи старых событий (по умолчанию она активирована).

Рисунок 17. Настройка хранения журналов аудита

Выводы

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

В дальнейшем важно будет обеспечить централизованный сбор и хранение журналов в SIEM-системе, настройку корреляционных правил, киберразведку (Threat Intelligence), проведение активных испытаний безопасности в формате Red / Blue Team.

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

Политика аудита

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

Для запуска введите его название в строке поиска.

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

События входа и выхода

Например, в категории «аудит входа в систему» можно включить фиксацию успешных или неудачных попыток входа в систему.

При анализе журнала вы сможете посмотреть пытались ли злоумышленники зайти в операционную систему. Если да, тогда, сколько было попыток и были ли успешные попытки.

Проверим, как это работает.  Я включу оба типа событий.

Учет ведется для каждой учетной записи, в том числе при попытке войти на рабочую станцию, которая находится в контроллере домена.

Теперь я попробую ввести неверный пароль, пытаясь зайти под одним пользователем. А затем совершить удачную попытку входа под другим пользователем.

Я ввел несколько раз неправильный пароль, пытаясь зайти под одной учетной записью, а затем зашел под своей учетной записью.

Для просмотра событий нужно открыть приложение просмотр событий.

Затем выбрать пункт меню журналы Windows –> Безопасность. В журнале будут отображены неудачные и удачные попытки входа в систему.

Кликнув на событие, вы можете просмотреть его свойства и подробности.

Существуют следующие типы входов операционную систему Windows.

События администрирования

Вернемся к приложению локальная политика безопасности. Рассмотрим аудит управления учетными записями.

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

Для примера я включил оба типа событий.

Затем я изменил тип учетной записи – сделал пользователя администратором.

В журнале безопасности появилась соответствующая запись.

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

Аудит изменения политики

Данный параметр фиксирует события связанные с изменением политик аудита. Разберемся на примере. Я включил оба типа событий.

После чего я добавил пользователя Local use в свойства прав архивация файлов и каталогов.

Теперь в журнале безопасности мы видим соответствующую запись об изменении прав пользователя.

Попробуйте выполнить какие-либо действия с политиками и отследить их в журнале безопасности операционной системы.

Аудит использования привилегий

Аудит использования привилегий фиксирует события связанные с применением пользователем назначенных ему привилегий.

Например, у пользователя есть привилегия на изменение системного времени. Включите тип события успех в аудите.

Измените системное время.

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

Аудит событий операционной системы

Для аудита событий происходящих с операционной системой (например, отключение элементов безопасности системы) предназначен параметр аудит системных событий.

Я включу аудит событий с типом успех. Затем очищу журнал аудита событий.

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

Аудит доступа пользователя к объектам

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

Я включу аудит двух типов событий.

Этот вид аудита в операционной системе Windows доступен только для файловой системы NTFS. При этом аудит доступен, если включить его в самом объекте.

Для примера я создам текстовый фал. Для настройки нужно перейти в его свойства -> безопасность -> дополнительно -> аудит. Далее следует добавить субъект и разрешения.

Я установил тип успех на чтение и выполнение этого файла.

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

Управление журналом аудита

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

Что бы выдать права для работы с журналом пользователю необходимо войти под учетной записью администратора в локальную политику безопасности и добавить пользователя в список учетных записей «Управление аудитом и журналом безопасности».

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

На этом короткое руководство по аудиту событий безопасности в операционной системе Windows закончено.

Если у вас возникли вопросы – задавайте их в комментариях к данной заметке.

Уважаемые друзья, в предыдущих публикациях мы говорили об основах информационной безопасности, законодательстве по защите персональных данных и критической информационной инфраструктуры, безопасности в кредитно-финансовой сфере, а также провели анализ основных стандартов по управлению рисками информационной безопасности и обсудили системы класса IRP, предназначенные для автоматизации реагирования на инциденты ИБ. Как мы знаем, при обработке инцидентов детальный анализ событий безопасности с устройств является одним из ключевых этапов. В данной публикации мы рассмотрим настройку подсистемы аудита ОС Windows, принципы анализа и централизованного сбора журналов аудита с Windows-устройств и их пересылку в SIEM-систему IBM QRadar, а также покажем, как можно с помощью штатных средств Windows и утилиты Sysmon настроить простейшую систему реагирования на инциденты ИБ. Вперед!

Для решения задачи обработки инцидентов ИБ логично рассуждать, что чем больше данных (логов, событий безопасности) мы собираем, храним и анализируем, тем проще нам будет в дальнейшем не только оперативно среагировать на инцидент, но и расследовать обстоятельства произошедших атак для поиска причин их возникновения. При этом большое количество данных для обработки имеет и очевидный минус: нас может просто «засыпать» сообщениями, алертами, уведомлениями, поэтому необходимо выбрать самые значимые с точки зрения ИБ события и настроить соответствующие политики аудита. Microsoft предлагает использовать бесплатный набор утилит и рекомендаций (Baselines) в своем наборе Microsoft Security Compliance Toolkit, в котором в том числе приведены и рекомендуемые настройки аудита для контроллеров домена, рядовых серверов и рабочих станций. Кроме рекомендаций вендора можно обратиться еще к документам CIS Microsoft Windows Server Benchmark и CIS Microsoft Windows Desktop Benchmark, в которых, в числе прочего, указаны рекомендуемые экспертами политики аудита для, соответственно, серверных и десктопных версий ОС Windows. Однако зачастую выполнение абсолютно всех рекомендаций неэффективно именно по причине потенциального появления большого количества «шумящих», малозначительных с точки зрения ИБ событий, поэтому в настоящей статье мы сначала приведем список наиболее полезных и эффективных (с нашей точки зрения) политик аудита безопасности и соответствующих типов событий безопасности ОС Windows.

Напомню, что в ОС Microsoft Windows, начиная с Microsoft Windows Server 2008 и Vista, используется достаточно продвинутая система аудита, настраиваемая при помощи конфигурирования расширенных политик аудита (Advanced Audit Policy Configuration). Не стоит забывать о том, что как только на устройствах будут включены политики расширенного аудита, по умолчанию старые «классические» политики аудита перестанут быть эффективными, хотя данное поведение может быть переопределено в групповой политике «Аудит: принудительно переопределяет параметры категории политики аудита параметрами подкатегории политики аудита (Windows Vista или следующие версии))» (Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings).

Политики аудита Windows

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

Кроме описанных выше настроек, имеет смысл также контролировать появление в журнале безопасности события с EventID=1102, которое формируется сразу после очистки журнала безопасности, что может говорить о вредоносной активности. Более того, разумно будет включить в каталоге «Конфигурация компьютера — Конфигурация Windows — Параметры безопасности — Локальные политики — Параметры безопасности» политику «Сетевая безопасность: ограничения NTLM: исходящий трафик NTLM к удаленным серверам» в значение «Аудит всего». После этого EventID=8001 в журнале Microsoft-Windows-NTLM/Operational будет содержать информацию об автоматической аутентификации на веб-ресурсах с учетной записью пользователя. Следующим шагом станет allow list с перечнем веб-ресурсов, которые легитимно могут запрашивать учетные записи, а указанную политику можно будет перевести в режим блокировки. Это не позволит вредоносным ресурсам получать NTLM-хэши пользователей, которые кликнули на ссылку из фишингового письма.

Обратим внимание и на то, что подсистема журналирования Windows весьма гибка и позволяет настроить аудит произвольных папок и веток реестра — следует лишь выбрать критичные для ИТ-инфраструктуры объекты аудита и включить данные опции.

Настройка Windows Event Forwarding, интеграция с IBM QRadar

Настроив необходимые параметры аудита, перейдем к решению вопроса автоматизации сбора журналов аудита и их централизованного хранения и анализа. Штатный механизм Windows Event Forwarding, который работает из коробки с Microsoft Windows Server 2008 / Vista и старше, позволяет осуществлять централизованный сбор журналов аудита на устройстве-коллекторе (не ниже Windows Server 2008 и Vista, но все же рекомендуется использовать выделенный Windows Server 2012R2 и старше) с устройств-источников с применением функционала WinRM (Windows Remote Management, использует протокол WS-Management) и использованием т.н. «подписок» на определенные события (набор XPath-выражений, о которых мы поговорим далее, для выбора интересующих журналов и событий на источнике). События с удаленных устройств могут быть как запрошены коллектором (режим Pull/Collector initiated), так и отправлены самим источником (режим Push/Source computer initiated). Мы рекомендуем использовать последний режим, поскольку в режиме Push служба WinRM слушает входящие соединения только на коллекторе, а на клиентах-источниках WinRM не находится в режиме прослушивания и лишь периодически обращается к коллектору за инструкциями, что уменьшает поверхность потенциальной атаки на конечные устройства. По умолчанию для шифрования трафика от источников к коллектору, принадлежащих одному Windows-домену, используется Керберос-шифрование SOAP-данных, передаваемых через WinRM (режим HTTP-Kerberos-session-encrypted), при этом HTTP-заголовки и соответствующие метаданные передаются в открытом виде. Другой опцией является использование HTTPS с установкой SSL-сертификатов на приемнике и источнике, при этом они могут не принадлежать одному домену. При дальнейшем изложении будем считать, что мы работаем в одном домене и используем настройку по умолчанию.

Рассмотрев концепцию пересылки логов с Windows-устройств, перейдем непосредственно к настройке нашей связки: источник событий -> сервер-коллектор -> утилита IBM WinCollect -> SIEM-система IBM QRadar.

Для включения сервиса сбора логов следует выполнить нижеописанные шаги:

 1. На сервере-коллекторе выполнить команду winrm qc, ответить согласием на оба последующих вопроса (включение службы WinRM и прослушивание порта TCP:5985 для входящих соединений от источников). Следует учесть, что выполнение команды winrm qc одновременно включает Windows Remote Shell (WinRS) и разрешает принимать входящие соединения для удаленного управления через функционал WinRS. Отключить WinRS можно либо через политику «Конфигурация компьютера / Административные шаблоны / Компоненты Windows / Удаленная оболочка Windows / Разрешить доступ к удаленной оболочке -> Запретить» (Computer Configuration / Administrative Templates / Windows Components / Windows Remote Shell / Allow Remote Shell Access -> Disabled), либо командой winrm set winrm/config/winrs @{AllowRemoteShellAccess=»false»}

2. На сервере-коллекторе выполнить команду wecutil qc, согласиться на включение службы «Сборщик событий Windows» (Windows Event Collector). При этом в Windows Firewall создается разрешающее правило для входящих соединений на коллектор по TCP:5985.

3. На источниках событий следует включить службу WinRM: установить «Тип запуска» в значение «Автостарт» и запустить «Службу удаленного управления Windows» (Windows Remote Management (WS-Management)).

4. Проверить состояние службы WinRM на сервере-колекторе можно командой winrm enumerate winrm/config/listener, в результате выполнения которой отобразятся настройки порта и список локальных IP-адресов, на которых прослушиваются соединения по TCP:5985. Команда winrm get winrm/config покажет подробные настройки службы WinRM. Переконфигурировать настройки можно либо непосредственно через утилиту winrm, либо через групповые политики по пути «Конфигурация компьютера / Административные шаблоны / Компоненты Windows / Удаленное управление Windows» (Computer Configuration / Administrative Templates / Windows Components / Windows Remote Management).

5. На источниках событий требуется предоставить доступ к журналам аудита службе WinRM путем включения встроенной учетной записи NT AUTHORITYNETWORK SERVICE (SID S-1-5-20) в локальную группу BUILTINEvent Log Readers («Читатели журнала событий»). После этого необходимо перезапустить «Службу удаленного управления Windows» (WinRM) и службу «Журнал событий Windows» (EventLog).

6. Затем следует создать и применить конфигурацию групповой политики для источников, в которой будет указана конфигурация и адрес сервера-коллектора. Требуется включить политику «Конфигурация компьютера / Административные шаблоны / Компоненты Windows / Пересылка событий / Настроить адрес сервера…» (Computer Configuration / Administrative Templates / Windows Components / Event Forwarding / Configure the server address…) и указать адрес сервера-коллектора в следующем формате:

Server=http://servername.domain.local:5985/wsman/SubscriptionManager/WEC,Refresh=60

где 60 – частота обращения (в секундах) клиентов к серверу за новыми инструкциями по пересылке журналов. После применения данной настройки на устройствах-источниках следует сделать перезапуск службы WinRM.

7. Далее создаем и применяем конфигурацию подписки на сервере-коллекторе: открываем оснастку управления журналами аудита (eventvwr.msc) и находим внизу раздел «Подписки» (Subscriptions). Нажимаем правой кнопкой мыши и выбираем «Создать подписку», задаем имя подписки. Далее выбираем опцию «Инициировано исходным компьютером» (Source Computer Initiated, это означает предпочтительный режим Push). Нажимаем на кнопку «Выбрать группы компьютеров» (Select Computer Groups), выбираем из Active Directory те устройства или их группы, которые должны будут присылать логи на коллектор. Далее, нажимаем «Выбрать события» (Select Events) и вводим XPath-запрос (пример для сбора журналов Security):

<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">*</Select>
  </Query>
</QueryList>

8. В итоге, клиенты должны иметь активные сетевые соединения по TCP:5985 с сервером-коллектором. На сервере-коллекторе в eventvwr.msc в свойствах «Подписки» можно будет увидеть список клиентов-источников, а пересланные события будут находиться в разделе «Журналы Windows – Перенаправленные события» (Windows Logs – Forwarded Events) на сервере-коллекторе.

9. Далее решаем задачу пересылки собранных на сервере-коллекторе логов с источников в SIEM систему IBM QRadar. Для этого нам потребуется установить на сервере-коллекторе утилиту IBM WinCollect.

Рекомендуем использовать управляемый (Managed) режим работы WinCollect для упрощения его администрирования. Для того, чтобы отправляемые через WinCollect агрегированные события корректно обрабатывались в IBM QRadar, нам следует воспользоваться рекомендациями IBM и на сервере-коллекторе с установленной утилитой WinCollect перевести формат пересылаемых событий в RenderedText, а также сменить их локаль на EN-US командой wecutil ss SubscriptionName /cf:RenderedText /l:en-US  (где SubscriptionName — имя подписки, заданное в п.7 выше). Кроме того, необходимо обеспечить сетевую доступность между сервером-коллектором с установленным WinCollect и нодами IBM QRadar по TCP:8413 и TCP/UDP:514.

10. После установки утилиты WinCollect на сервер-коллектор, в самой SIEM-системе IBM QRadar нужно будет добавить этот сервер в список источников (тип источника Microsoft Security Event Log, в поле Target Destination в выпадающем списке лучше выбрать вариант с TCP-syslog-подключением, отметить check-box Forwarded Events).

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

Утилита Sysmon

Кроме задействования штатного функционала подсистемы журналирования, можно воспользоваться и официальной бесплатной утилитой Sysmon из пакета Microsoft Windows Sysinternals, которая существенно расширяет и дополняет возможности мониторинга ОС. Данная утилита дает возможность проводить аудит создания файлов, ключей реестра, процессов и потоков, а также осуществлять мониторинг загрузки драйверов и библиотек, сетевых подключений, WMI-событий и именованных каналов. Из особо полезных функций отметим возможность утилиты показывать родительский процесс и командную строку процесса, отображать значение хэш-сумм при событиях создания процесса и загрузки драйверов и библиотек с указанием наличия и действительности цифровой подписи. Несложным путем можно автоматизировать сравнение полученных хэш-сумм с индикаторами компрометации (IoCs, Indicator of Compromise) из данных фидов CyberThreat Intelligence, а также использовать приложение QVTI для IBM QRadar, с помощью которого хэши запускаемых файлов автоматически проверяются через сервис VirusTotal. Еще одной приятной опцией является возможность создания XML-конфигураций, в которых можно предельно четко указать объекты контроля и настройки работы Sysmon. Одними из наиболее продвинутых и детальных вариантов XML-конфигураций, с нашей точки зрения, являются конфиги  https://github.com/ion-storm/sysmon-config и https://github.com/SwiftOnSecurity/sysmon-config .

Установка Sysmon предельно проста и также может быть легко автоматизирована:

1. Дистрибутив скачивается с https://docs.microsoft.com/en-us/sysinternals/downloads/sysmon

Все исполняемые файлы подписаны.

2. Создается или скачивается по приведенным выше ссылкам xml-файл с конфигурацией Sysmon.

3. Установка sysmon для x64 производится командой:

C:foldersysmon64.exe -accepteula -i C:foldersysmonconfig-export.xml , где sysmonconfig-export.xml – файл конфигурации, sysmon64.exe  –  файл-установщик.

Поддерживается запуск установки из сетевой папки.

4. После установки создается журнал Microsoft-Windows-Sysmon/Operational , размер которого мы сразу рекомендуем увеличить как минимум до 100 Мб.

Перезапуск устройства не требуется, Sysmon работает в виде сервиса, его исполняемый файл находится в C:Windowssysmon64.exe . По нашим подсчетам, footprint на конечной системе даже при использовании максимально детального конфига Sysmon не превышает 5-10% ЦПУ и около 100 Мб ОЗУ.

XPath-запросы

Наконец, выполнив необходимые настройки файлов журналов Windows, перейдем непосредственно к поиску интересующей информации. Заметим, что в случае включения всех рекомендованных политик аудита ИБ сами журналы событий становятся достаточно объемными, поэтому поиск по их содержимому может быть медленным (этих недостатков лишены специализированные решения, предназначенные в том числе для быстрого поиска информации — Log Management и SIEM-системы). Отметим также, что по умолчанию не все журналы Windows отображаются к графической оснастке (eventvwr.msc), поэтому в данной оснастке следует перейти в меню «Вид» и отметить check-box  «Отобразить аналитический и отладочный журналы».

Итак, поиск по журналам аудита будем осуществлять с помощью встроенного редактора запросов XPath (XPath queries). Открыв интересующий нас журнал, например, журнал безопасности Windows (вкладка «Журналы Windows» -> «Безопасность» / Security), нажатием правой кнопки мыши на имени журнала выберем пункт «Фильтр текущего журнала». Нам откроется графический редактор поисковых запросов, при этом для наиболее продуктивной работы следует открыть вторую вкладку открывшегося окна с названием XML, отметив внизу check-box «Изменить запрос вручную». Нам будет предложено изменить XML-текст (по сути, XPath запрос) в соответствии с нашими критериями поиска.

Результат запроса будет также представляться в различных формах, но для лучшего понимания и получения детального контента в конкретном событии рекомендуем переключиться на вкладку  «Подробности», а там выбрать radio-button  «Режим XML», в котором в формате  «ключ-значение» будут представлены данные события безопасности.

Приведем несколько полезных XPath запросов с комментариями.

1. Поиск по имени учетной записи в журнале Security — возьмем для примера имя Username:

<QueryList>
<Query Id="0" Path="Security">
<Select Path="Security">*[EventData[Data[@Name='TargetUserName']='Username']]
</Select>
</Query>
</QueryList>

 2. Поиск по значению конкретного свойства события в журнале Sysmon — возьмем для примера поиск событий, в которых фигурировал целевой порт 443:

<QueryList>
  <Query Id="0" Path="Microsoft-Windows-Sysmon/Operational">
    <Select Path="Microsoft-Windows-Sysmon/Operational">*[EventData[Data[@Name='DestinationPort'] = '443']]</Select>
  </Query>
</QueryList>

3. Произведем поиск сразу по двум условиям — возьмем для примера событие входа с EventID=4624 и имя пользователя Username:

<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">
*[System[(EventID=4624)]] 
and 
*[EventData[Data[@Name='TargetUserName']='Username']]
</Select>
  </Query>
</QueryList>

4. Поиск по трем условиям — дополнительно укажем Logon Type = 2, что соответствует интерактивному входу в ОС:

<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">
*[System[(EventID=4624)]] 
and 
*[EventData[Data[@Name='TargetUserName']='Username']] 
and
*[EventData[Data[@Name='LogonType']='2']]
</Select>
  </Query>
</QueryList>

5. Рассмотрим функционал исключения из выборки данных по определенным критериям — это осуществляется указанием оператора Suppress с условиями исключения. В данном примере мы исключим из результатов поиска по фактам успешного входа (EventID=4624) все события, которые имеют отношения к системным учетным записям (SID S-1-5-18/19/20) с нерелевантным для нас типам входа (Logon Type = 4/5), а также применим функционал задания условий поиска с логическим оператором  «ИЛИ», указав не интересующие нас имя процесса входа (Advapi) и методы аутентификации (Negotiate и NTLM):

<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">*[System[(EventID=4624)]]</Select>
<Suppress Path="Security">*[EventData[(Data[@Name='TargetUserSid'] and (Data='S-1-5-18' or Data='S-1-5-19' or Data='S-1-5-20') and Data[@Name='LogonType'] and (Data='4' or Data='5'))]]
or
*[EventData[(Data[@Name='LogonProcessName'] and (Data='Advapi') and Data[@Name='AuthenticationPackageName'] and (Data='Negotiate' or Data='NTLM'))]]
</Suppress>
  </Query>
</QueryList>

IRP-система штатными средствами Windows

Как мы увидели, встроенный функционал подсистемы журналирования Windows позволяет весьма гибко осуществлять поиск по зафиксированным событиям аудита ИБ, комбинируя различные условия поиска. Однако, у Windows есть еще одна интересная «фишка», которая позволяет использовать сформированные описанным выше образом правила поиска событий — мы говорим про создание задач с определенным триггером в «Планировщике заданий» Windows, что также является штатным функционалом ОС.

Как мы знаем, задачи в ОС Windows могут выполнять совершенно разные функции, от запуска диагностических и системных утилит до обновления компонент прикладного ПО. В задаче можно не только указать исполняемый файл, который будет запущен при наступлении определенных условий и триггеров, но и задать пользовательский PowerShell/VBS/Batch-скрипт, который также будет передан на обработку. В контексте применения подсистемы журналирования интерес для нас представляет функционал гибкой настройки триггеров выполнения задач. Открыв  «Планировщик заданий» (taskschd.msc), мы можем создать новую задачу, в свойствах которой на вкладке  «Триггеры» мы увидим возможность создать свой триггер. При нажатии на кнопку  «Создать» откроется новое окно, в котором в drop-down списке следует выбрать вариант  «При событии», а в открывшейся форме отображения установить radio-button  «Настраиваемое». После этих действий появится кнопка  «Создать фильтр события», нажав на которую, мы увидим знакомое меню фильтрации событий, на вкладке XML в котором мы сможем задать произвольное поисковое условие в синтаксисе XPath-запроса.

Например, если мы хотим выполнять некоторую команду или скрипт при каждом интерактивном входе в систему пользователя Username, мы можем задать в качестве триггера задачи следующее поисковое выражение, уже знакомое нам по примеру выше:

<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">
*[System[(EventID=4624)]] 
and 
*[EventData[Data[@Name='TargetUserName']='Username']] 
and 
*[EventData[Data[@Name='LogonType']='2']]
</Select>
  </Query>
</QueryList>

 Другой пример: оповещение администратора при подозрительном обращении к системному процессу lsass.exe, который хранит в своей памяти NTLM-хэши и Керберос-билеты пользователей Windows, что может говорить об использовании утилиты Mimikatz или аналогичных ей:

<QueryList>
  <Query Id="0" Path="Microsoft-Windows-Sysmon/Operational">
    <Select Path="Microsoft-Windows-Sysmon/Operational">
*[System[(EventID=10)]] 
and 
*[EventData[Data[@Name='TargetImage']='C:WindowsSystem32lsass.exe']] 
and 
*[EventData[(Data[@Name='GrantedAccess'] and (Data='0x1010' or Data='0x1038'))]]
</Select>
  </Query>
</QueryList>

 Таким образом, при условии работоспособности системы журналирования событий Windows можно не только детально и глубоко анализировать все произошедшее на устройстве, но и выполнять произвольные действия при появлении в журнале ОС событий, отвечающих условиям XPath-запроса, что позволяет выстроить целостную систему аудита ИБ и мониторинга событий безопасности штатными средствами ОС. Кроме того, объединив рекомендованные политики аудита информационной безопасности, утилиту Sysmon с детально проработанными конфигами, запрос данных из TI-фидов, функционал XPath-запросов, пересылку и централизацию событий с помощью Windows Event Forwarding, а также настраиваемые задачи с гибкими условиями выполнения скриптов, можно получить фактически  бесплатную (по цене лицензии на ОС) систему защиты конечных точек и реагирования на киберинциденты, используя лишь штатный функционал Windows.

В статье рассмотрим то, как мы можем проводить аудит безопасности системы Windows. Узнаем как настроить и смотреть логи связанные с аудитом.

Привилегии связанные с аудитом

С аудитом доступа связаны две привилегии:

• SeSecurityPrivilege — необходима для управления журналом событий безопасности и для просмотра или настройки SACL.
• SeAuditPrivilege — позволяет процессам, вызывать системные службы аудита для успешного генерирования записей аудита.

Настройка политики аудита

Настройка политики аудита осуществляется из оснастки “Локальная политика безопасности” (secpol.msc).

Схема работы аудита

LSASS отправляет сообщения SRM, чтобы проинформировать его о политике аудита в ходе инициализации системы, а потом при изменениях политики. В свою очередь LSASS получает события аудита от SRM, добавляет дополнительную информацию и отправляет их регистратору событий (Event Logger).

Записи аудита передаются от SRM к подсистеме безопасности LSASS одним из двух способов:

• если запись аудита невелика (меньше чем максимальный размер сообщения ALPC), она отправляется как ALPC-сообщение;
• ну а если запись аудита имеет большой размер, SRM использует общую память, чтобы сообщение было доступно LSASS, и просто передает указатель в ALPC-сообщении.

Аудит доступа к объекту

Аудит доступа к объекту по умолчанию выключен, как и другие политики аудита. Чтобы понаблюдать за тем, как работает аудит доступа к объекту, выполните следующие действия. В проводнике перейдите к файлу, к которому у вас есть доступ и откройте свойства этого файла, затем перейдите на вкладку “Безопасность“:

Там нажмите кнопку “Дополнительно” и перейдите на вкладку “Аудит“.

Затем нажмите кнопки “Продолжить” и “Добавить” и в открывшимся окне нажмите на ссылку “Выберите субъект“:

В открывшимся окне впишите логин своего пользователя и нажмите кнопку “Проверить имя“. Если ввели логин верно, то в списке пользователей отобразиться имя вашего пользователя:

Теперь нажмите на кнопку “ОК“, и выставьте все флажки в области “Особые разрешения” и ещё раз нажмите на кнопку “ОК“:

Затем нажмите ещё два раза на кнопку “ОК“, чтобы закрыть дополнительные параметры безопасности и свойства файла.

Дальше запустите оснастку secpol.msc и перейдите в “Локальные политики“. Там откройте “Аудит доступа к объектам” и поставьте флажок “Успех“, затем нажмите “ОК“:

Итак, политику аудита мы включили и на файле аудит настроили. Теперь откройте файл, запишите в него что нибудь и закройте сохранив изменения. Затем откройте журнал “eventvwr.exe” и перейдите в “Журналы Windows / Безопасность“:

Найдите событие с кодом 4656 — это и есть доступ к вашему файлу:

В событии вы увидите:

• ИД безопасности — это ваша учетная запись.
• Тип объекта — File.
• Имя объекта — путь к файлу.
• Имя процесса — путь к файлу программы (System32notepad.exe).
• Ключевые слова — Аудит успеха.
• И другую информацию.

Глобальная политика аудита

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

Чтобы посмотреть краткую информацию о командах для настройки и запроса политики глобального аудита выполните:

>auditpol /resourceSACL

Чтобы посмотреть глобальные списки SACL для файловой системы и для реестра выполните такие команды:

>auditpol /resourceSACL /type:File /view
>auditpol /resourceSACL /type:Key /view

Для установки аудита всех файлов с доступом на запись (FW) выполните:

> auditpol.exe /resourceSACL /set /type:File /user:<username> /success /failure /access:FW

В примере выше вместо имени пользователя можно ввести группу.

Чтобы выключить глобальный аудит, включенный предыдущей командой, выполните:

> auditpol.exe /resourceSACL /remove /type:File /user:<username>

Конфигурация расширенной политики аудита

В оснастке “Локальная политика безопасности” можно настроить конфигурацию расширенной политики аудита:

В этой конфигурации настройка политики аудита выполняется более тонко. Например, включение “Аудита доступа к объектам” рассматриваемое выше включало аудит для разных объектов. А тут можно выбрать тип объектов:

А “Аудит доступа к глобальным объектам” включает или отключает глобальные SACL, которые мы включали ранее из командной строки:

При включении “Аудита доступа к глобальным объектам” этот параметр нужно будет настроить, указав пользователей для аудита и тип доступа, в общем то что мы делали в командной строке выше:

Вернуться к оглавлению

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #