С помощью аудита событий безопасности администратор может получать достоверную информацию обо всех событиях в системе, контролировать действия пользователей, и использовать информацию для выявления уязвимых мест в системе безопасности сервера или AD. В Windows такие события записываются в журнал Security операционной системы. В этой статье мы покажем, как настраивать политики аудита безопасности в Windows на примере настройки аудит доступа к файлам и папкам.
Для настройки политик аудита в Windows используется консоль настройки групповых политик. Если вы настраиваете политики для компьютеров/серверов домена, используйте Group Policy Management Console (gpmc.msc). При настройке политики аудита на отдельном сервере можно использовать консоль Local Group Policy Editor (gpedit.msc).
В консоли GPO есть две секции, в которых находятся политики аудита базовая и расширенная.
Базовая политика аудита находится в разделе Computer Configuration –> Windows Settings -> Security Settings -> Local Policies -> Audit Policy. В ней доступны следующие категории событий:
- Audit account logon events
- Audit account management
- Audit directory service access
- Audit logon events
- Audit object access
- Audit policy change
- Audit privilege use
- Audit process tracking
- Audit system events
Расширенные политики аудита находятся в секции: Computer Configuration -> Windows Settings -> Security Settings -> Advanced Audit Policy Configuration. Здесь находится 60 различных политик аудита, разделенные на 10 категорий:
- Account Logon
- Account Management
- Detailed Tracking
- DS Access
- Logon/Logoff
- Object Access
- Policy Change
- Privilege Use
- System
- Global Object Access Auditing
В большинстве случаев нужно использовать политики аудита из секции Advanced Audit Policy Configuration. Они позволяют настроить аудит более тонко и исключить ненужные события безопасности.
Прежде чем включать политики аудита в Windows рекомендуем увеличить максимальный размер журнала Security со 128 Mb (по-умолчанию в Windows Server)
Запустите консоль Event Viewer (eventvwr.msc), разверните Windows Logs и откройте свойства журнала Security. Увеличьте значение в поле Maximum log size (KB).
Теперь нужно настроить политику аудита доступа пользователей к файлам и папкам в сетевой папке. Перейдите в секцию Advanced Audit Policy -> Object Access. Откройте свойства подкатегории Audit File Share и Audit File System.
Включите политику: Configure the following audit events.
Укажите, какие события нужно записывать в журнал Security:
- Success – успешный доступ пользователя к объектам в сетевой папке
- Failure – события неуспешного доступа к папкам.
В нашем случае достаточно вести аудит только Success событий.
Теперь нужно назначить политику аудита к сетевой папке (создать системные списки управления доступом – SACL).
Откройте свойства сетевой папки, перейдите на вкладку Security -> Advanced -> Auditing tab -> Continue.
Нажмите кнопку Add -> Select a principal и добавьте субъекты – это пользователи или группы (локальные или из Active Directory), чьи действия нужно аудировать. Я добавил группы Domain Users или Everyone (это значит, я буду вести аудит доступа к сетевой папке для всех пользователей).
Далее в секции Permissions укажите, какие действия пользователей нужно записывать в журнал. Я выбрал события из категории Delete.
Сохраните изменения и обновите политики на компьютере с помощью команды:
gpupdate /force
Теперь, если любой пользователь удалит файл или папку в вашей сетевой папке, в журнале Security появится событие c EventID 4660 от источника Microsoft Windows security с Task Сategory File System: An object was deleted.
В событии указан пользователь, который удалил файл (Account Name).
Не рекомендуется включать много событий аудита сразу – это может вызвать повышенную нагрузку на компьютер. Кроме того, в большом количестве событий безопасности сложно искать.
Также вы можете управлять политиками аудита через утилиту командной строки auditpol.exe.
Чтобы вывести информацию о всех включенных политиках аудита, выполните:
auditpol /get /category:*
Чтобы включить определенную политику аудита, используется такой синтаксис:
auditpol /set /subcategory:"Registry" /success:enable
Для сброса политик аудита в исходное состояние, используется команда:
AuditPol /clear
Как настроить политики аудита Windows таким образом, чтобы охват мониторинга SOC был полноценным? Рассмотрим оптимальный список политик, а также выделим самое необходимое, отсеяв лишнее.
- Введение
- Знакомство с расширенным аудитом Windows
- Настройка политик аудита
- Усиление цифровой обороны
- Выводы
Введение
Все мы любим заворожённо читать про очередное расследование инцидента, где шаг за шагом распутывается клубок: как проник злоумышленник, какие инструменты он использовал и когда, что за процессы создавались на скомпрометированном хосте, что происходило в сети и, конечно же, кто виноват и что делать.
На практике ответы на эти вопросы находятся не всегда. Зачастую при расследовании специалисты отделов ИБ сталкиваются с тем, что аудит не настроен, логи перезаписались, отсутствует единая система хранения и анализа журналов, «перезалит» заражённый хост (популярное решение всех проблем).
Ниже мы разберём один из самых важных этапов, который нужен для того, чтобы расследование не завершилось ещё в самом начале: сбор и хранение журналов аудита. Будут рассмотрены возможности расширенного аудита ОС 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. Категории и подкатегории аудита
| Категория (Category) | Подкатегория (Subcategory) | |
| Вход учётной записи (Account Logon) | Аудит проверки учётных данных (Audit Credential Validation) | |
| Аудит службы проверки подлинности Kerberos (Audit Kerberos Authentication Service) | ||
| Аудит операций с билетами службы Kerberos (Audit Kerberos Service Ticket Operations) | ||
| Аудит других событий входа учётных записей (Audit Other Account Logon Events) | ||
| Управление учётными записями (Account Management) | Аудит управления группами приложений (Audit Application Group Management) | |
| Аудит управления учётными записями компьютеров (Audit Computer Account Management) | ||
| Аудит управления группами распространения (Audit Distribution Group Management) | ||
| Аудит других событий управления учётными записями (Audit Other Account Management Events) | ||
| Аудит управления группами безопасности (Audit Security Group Management) | ||
| Аудит управления учётными записями пользователей (Audit User Account Management) | ||
| Подробное отслеживание (Detailed Tracking) | Аудит активности DPAPI (Audit DPAPI Activity) | |
| PNP-действие аудита (Audit PNP Activity) | ||
| Аудит создания процессов (Audit Process Creation) | ||
| Аудит завершения процессов (Audit Process Termination) | ||
| Аудит событий RPC (Audit RPC Events) | ||
| Проверка изменений прав маркера (Audit Token Right Adjusted) [Windows 10 / Server 2016 и выше] | ||
| Доступ к службе каталогов DS (DS Access) | Аудит подробной репликации службы каталогов (Audit Detailed Directory Service Replication) | |
| Аудит доступа к службе каталогов (Audit Directory Service Access) | ||
| Аудит изменения службы каталогов (Audit Directory Services Changes) | ||
| Аудит репликации службы каталогов (Audit Directory Service Replication) | ||
| Вход / выход (Logon / Logoff) | Аудит блокировки учётных записей (Audit Account Lockout) | |
| Аудит заявок пользователей или устройств на доступ (Audit User / Device Claims) | ||
| Аудит расширенного режима IPsec (Audit IPsec Extended Mode) | ||
| Аудит основного режима IPsec (Audit IPsec Main Mode) | ||
| Аудит быстрого режима IPsec (Audit IPsec Quick Mode) | ||
| Аудит выхода из системы (Audit Logoff) | ||
| Аудит входа в систему (Audit Logon) | ||
| Аудит сервера политики сети (Audit Network Policy Server) | ||
| Аудит других событий входа и выхода (Audit Other Logon / Logoff Events) | ||
| Аудит специального входа (Audit Special Logon) | ||
| Доступ к объектам (Object Access) | Аудит событий, создаваемых приложениями (Audit Application Generated) | |
| Аудит служб сертификации (Audit Certification Services) | ||
| Аудит сведений об общем файловом ресурсе (Audit Detailed File Share) | ||
| Аудит общего файлового ресурса (Audit File Share) | ||
| Аудит файловой системы (Audit File System) | ||
| Аудит подключения платформы фильтрации (Audit Filtering Platform Connection) | ||
| Аудит отбрасывания пакетов платформой фильтрации (Audit Filtering Platform Packet Drop) | ||
| Аудит работы с дескрипторами (Audit Handle Manipulation) | ||
| Аудит объектов ядра (Audit Kernel Object) | ||
| Аудит других событий доступа к объектам (Audit Other Object Access Events) | ||
| Аудит реестра (Audit Registry) | ||
| Аудит съёмного носителя (Audit Removable Storage) | ||
| Аудит диспетчера учётных записей безопасности (Audit SAM) | ||
| Аудит сверки с централизованной политикой доступа (Audit Central Access Policy Staging) | ||
| Изменение политики (Policy Change) | Аудит изменения политики аудита (Audit Policy Change) | |
| Аудит изменения политики проверки подлинности (Audit Authentication Policy Change) | ||
| Аудит изменения политики авторизации (Audit Authorization Policy Change) | ||
| Аудит изменения политики платформы фильтрации (Audit Filtering Platform Policy Change) | ||
| Аудит изменения политики на уровне правил MPSSVC (Audit MPSSVC Rule-Level Policy Change) | ||
| Аудит других событий изменения политики (Audit Other Policy Change Events) | ||
| Использование привилегий (Privilege Use) | Аудит использования привилегий, не затрагивающих конфиденциальные данные (Audit Non Sensitive Privilege Use) | |
| Аудит других событий использования привилегий (Audit Other Privilege Use Events) | ||
| Аудит использования привилегий, затрагивающих конфиденциальные данные (Audit Sensitive Privilege Use) | ||
| Система (System) | Аудит драйвера IPsec (Audit IPsec Driver) | |
| Аудит других системных событий (Audit Other System Events) | ||
| Аудит изменения состояния безопасности (Audit Security State Change) | ||
| Аудит расширения системы безопасности (Audit Security System Extension) | ||
| Аудит целостности системы (Audit System Integrity) | ||
| Аудит доступа к глобальным объектам (Global Object Access Auditing) | Файловая система (File system) | |
| Реестр (Registry) |
Теперь вместо включения аудита «Доступ к объектам» мы можем очень тонко настроить его по подкатегориям. Например, мы не будем включать аудит событий «платформы фильтрации 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
| Категория | Подкатегория | Включить | Хост (DC, сервер, АРМ) | Категория (успех / отказ) |
| Account Logon | Audit Credential Validation | + | DC, сервер, АРМ | Успех и отказ |
| Audit Kerberos Authentication Service | + | DC | Успех и отказ | |
| Audit Kerberos Service Ticket Operations | + | DC | Успех и отказ | |
| Audit Other Account Logon Events | — | |||
| Account Management | Audit Application Group Management | + | DC | Успех и отказ |
| Audit Computer Account Management | + | DC | Успех | |
| Audit Distribution Group Management | + | DC | Успех | |
| Audit Other Account Management Events | + | DC, сервер, АРМ | Успех | |
| Audit Security Group Management | + | DC, сервер, АРМ | Успех | |
| Audit User Account Management | + | DC, сервер, АРМ | Успех и отказ | |
| Detailed Tracking | Audit DPAPI Activity | + | DC, сервер, АРМ | Успех и отказ |
| Audit PNP Activity | + | DC, сервер, АРМ | Успех и отказ | |
| Audit Process Creation | + | DC, сервер, АРМ | Успех | |
| Audit Process Termination | — | |||
| Audit RPC Events | — | |||
| Audit Token Right Adjusted | — | |||
| DS Access | Audit Detailed Directory Service Replication | + | DC | Успех и отказ |
| Audit Directory Service Access | + | DC | Успех и отказ | |
| Audit Directory Services Changes | + | DC | Успех и отказ | |
| Audit Directory Service Replication | + | DC | Успех и отказ | |
| Logon/Logoff | Audit Account Lockout | + | DC, сервер, АРМ | Отказ |
| Audit User / Device Claims | — | |||
| Audit IPsec Extended Mode | — | |||
| Audit IPsec Main Mode | — | |||
| Audit IPsec Quick Mode | — | |||
| Audit Logoff | + | DC, сервер, АРМ | Успех | |
| Audit Logon | + | DC, сервер, АРМ | Успех и отказ | |
| Audit Network Policy Server | — | |||
| Audit Other Logon / Logoff Events | + | DC, сервер, АРМ | Успех и отказ | |
| Audit Special Logon | + | DC, сервер, АРМ | Успех | |
| Object Access | Audit Application Generated | — | ||
| Audit Certification Services | — | |||
| Audit Detailed File Share | — | |||
| Audit File Share | — | |||
| Audit File System | + | DC, сервер, АРМ | Успех и отказ | |
| Audit Filtering Platform Connection | — | |||
| Audit Filtering Platform Packet Drop | — | |||
| Audit Handle Manipulation | — | |||
| Audit Kernel Object | — | |||
| Audit Other Object Access Events | + | DC, сервер, АРМ | Успех и отказ | |
| Audit Registry | + | DC, сервер, АРМ | Успех и отказ | |
| Audit Removable Storage | + | DC, сервер, АРМ | Успех и отказ | |
| Audit SAM | — | |||
| Audit Central Access Policy Staging | — | |||
| Policy Change | Audit Policy Change | + | DC, сервер, АРМ | Успех |
| Audit Authentication Policy Change | + | DC, сервер, АРМ | Успех | |
| Audit Authorization Policy Change | + | DC, сервер, АРМ | Успех | |
| Audit Filtering Platform Policy Change | — | |||
| Audit MPSSVC Rule-Level Policy Change | + | DC, сервер, АРМ | Успех и отказ | |
| Audit Other Policy Change Events | — | |||
| Privilege Use | Audit Non Sensitive Privilege Use | + | DC, сервер, АРМ | Успех и отказ |
| Audit Other Privilege Use Events | — | |||
| Audit Sensitive Privilege Use | + | DC, сервер, АРМ | Успех и отказ | |
| System | Audit IPsec Driver | — | ||
| Audit Other System Events | + | DC, сервер, АРМ | Успех и отказ | |
| Audit Security State Change | + | DC, сервер, АРМ | Успех | |
| Audit Security System Extension | + | DC, сервер, АРМ | Успех | |
| Audit System Integrity | — | |||
| Global Object Access Auditing | File system | — | ||
| Registry | — |
После включения описанных политик у вас будут все необходимые события для мониторинга и расследования инцидентов.
Усиление цифровой обороны
Для максимальной отдачи необходимо выполнить ещё одну настройку — включить логирование «командной строки процесса». Тогда на рабочих станциях и серверах, к которым применяется этот параметр политики, сведения из командной строки будут заноситься в журнал событий «Безопасность» (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.
Уровень сложностиСредний
Время на прочтение5 мин
Количество просмотров22K
Журналирование событий информационной безопасности является важным элементом системы защиты информации. Нам необходимо знать какое событие когда произошло, когда какой пользователь пытался зайти в систему, с какого узла, удачно или нет, и так далее. Конечно, некоторые события ИБ сохраняются в журналах ОС при использовании настроек по умолчанию, например, не/удачные входы в систему, изменения прав доступа и т. д. Однако, настроек по умолчанию и локального хранения логов недостаточно для эффективного мониторинга и реагирования на события ИБ.
В этой статье мы посмотрим, как можно организовать эффективный аудит узлов под управлением ОС Windows, а в следующей статье настроим централизованный сбор событий с нескольких узлов и попробуем с помощью Powershell автоматизировать обработку собранных событий.
Зачем нужно централизованное хранение
Локальное хранение журналов событий имеет целый ряд недостатков, не позволяющих использовать этот механизм для мониторинга событий ИБ. С точки зрения безопасности локальные журналы хранят все события только на данной машине. Пока злоумышленник пытается получить доступ и поднять привилегии на данной машине, некоторые события обличающие его действия, возможно будут сохраняться в логах, но как только он получит необходимые права, он сможет почистить журнал событий, затем заполнить его фиктивными логами, в результате чего мы не увидим событий, связанных с компрометацией узла.
Да, при очистке лога будет создано событие ‘1102 Журнал аудита был очищен’, но от этого события тоже можно избавиться, просто заполнив лог большим количеством фиктивных событий.
Так как, обычно EventLog пишется по принципу циклической записи, более старые события удаляются, и их заменяют более новые.
Ну а создать поддельные события можно с помощью того же PowerShell, используя командлет Write-EventLog.
Таким образом, локальное хранение событий это не самый лучший вариант работы с логами с точки зрения безопасности. Ну а кроме того, нам не слишком удобно анализировать журналы событий, если они хранятся только локально. Тогда необходимо подключаться к журналам событий каждой локальной машины и работать с ними локально.
Гораздо удобнее пересылать логи на отдельный сервер, где их можно централизованно хранить и анализировать. В таком случае, в процессе выполнения атаки мы можем получать события от атакуемого узла, которые точно не будут потеряны. Кроме того, даже если злоумышленник сможет очистить лог на локальной машине, на удаленном сервере все события сохраняться. Ну и если события от нескольких узлов сохраняются централизованно на одном сервере, то с ними гораздо удобнее работать, что тоже не маловажно при анализе логов.
Эффективный аудит
Мы разобрались с необходимостью централизованного мониторинга событий. Однако, еще необходимо разобраться с тем, какие именно события должны присутствовать в наших логах. С одной стороны в логах должны присутствовать важные события с точки зрения ИБ, а с другой, в нем не должно быть слишком много неинтересных событий, например постоянных обращений к каким-либо файлам или сообщений о запуске каких-либо процессов, не представляющих никакого интереса для ИБ. Таким образом, чтоб нам не потонуть в большом объеме ненужных событий и не потерять что-то действительно важное, нам необходимо грамотно настроить политики аудита.
Для настройки откроем Политики аудита (Конфигурация компьютера / Конфигурация Windows / Параметры безопасности / Локальные политики / Политика аудита (Computer Configuration / Windows Settings / Security Settings / Local Policies / Audit Policy).
Также нам потребуются расширенные политики аудита, которые можно открыть здесь: Конфигурация компьютера / Конфигурация Windows / Параметры безопасности / Конфигурация расширенной политики аудита (Computer Configuration / Windows Settings / Security Settings / Advanced Audit Policy Configuration).
Отличием политики расширенного аудита является наличие подкатегорий и теперь мы можем управлять аудитом на уровне не только категорий, но и подкатегорий. Если сравнить Политики аудита и Расширенные политики аудита, то можно заметить, что разделы в обычных политиках в свою очередь разделены на подразделы в расширенных политиках, что позволяет нам настраивать более подробные категории аудита. Так, для группы Вход учётной записи (Account Logon) мы можем настроить четыре проверки -Аудит проверки учётных данных, Аудит службы проверки подлинности Kerberos, Аудит операций с билетами службы Kerberos, Аудит других событий входа учётных записей.
Для каждого типа аудита мы можем настроить аудит событий успеха или отказа. С событиями успеха нужно быть аккуратными. Так, для того же аудита входов в систему мы рискуем получить большое количество событий успешного входа, которые по факту не будут представлять никакой ценности. Также, не стоит включать в аудите доступа к объектам, аудит событий «платформы фильтрации Windows», потому что он генерирует крайне большое количество событий (всё сетевое взаимодействие хоста). В результате мы снова рискуем получить большое количество ненужных событий. В результате срабатывания настроек политик аудита, в журнале создаются события, каждое из которых имеет собственный код.
Для эффективного аудита нам необходим сбор следующих типов событий: 4624 (Успешный вход в систему), 4647 (Выход из системы), 4625 (Неудачный вход в систему), 4778/4779 (Соединение/разъединение по RDP), 4800/4801 (Блокировка/Разблокировка рабочей станции) и некоторые другие.
При анализе событий нам важно понимать, как именно был осуществлен вход в систему или с каким кодом мы получили событие о неудачном входе в систему.
Посмотрим типы входа в систему:
2 – интерактивный
3 – сетевой (через сетевой диск)
4 – запуск по расписанию
5 – запуск сервиса
7 – разблокировка экрана
8 – сетевой (Basic Authentication в IIS)
10 – подключение по RDP
11 – вход по закешированным учетным данным
В приведенном ниже скриншоте у нас представлен вход в систему при запуске сервиса
И посмотрим, как мы можем узнать причину неудачного входа в систему
0xC0000064 — такого пользователя не существует
0xC000006A — неверный пароль
0xC0000234 — пользователь заблокирован
0xC0000072 — пользователь отключен
0xC000006F — пользователь попытался войти в систему вне установленных для него ограничений по дням недели или времени суток
0xC0000070 — ограничение рабочей станции или нарушение изолированной политики аутентификации (найдите идентификатор события 4820 на контроллере домена)
0xC0000193 — срок действия учетной записи истек
0xC0000071 — истек пароль
0xC0000133 — часы между DC и другим компьютером слишком сильно рассинхронизированы
0xC0000224 — пользователю необходимо сменить пароль при следующем входе в систему
0xc000015b Пользователю не был предоставлен запрошенный тип входа в систему (он же право входа в систему) на этом компьютере
Таким образом, по значениям данных кодов в соответствующих событиях мы можем понять, что стало причиной неудачного входа в систему или каким образом пользователь или сервис осуществили вход.
На картинке ниже представлен неудачный интерактивный вход в систему, причиной которого стало указание неверного пароля.
В следующей статье мы посмотрим, как средствами PowerShell можно извлекать различные значения из событий и делать обработку логов более “человеко-удобной.
Заключение
В этой статье мы рассмотрели виды аудита в современных версиях ОС Windows, поговорили о том, какие именно события должны собираться в системе и что означают некоторые поля в этих событиях. В следующей статье мы настроим централизованный сбор событий с нескольких источников и попробуем с помощью PowerShell настроить автоматический анализ собираемых событий.
Напоследок приглашаю вас на бесплатный вебинар, где мы узнаем, зачем нужны бэкапы и как их организовать путем сервисов в Windows.
Включаем аудит доступа к папкам и файлам в Windows
Политики аудита файловой системы Windows позволяют отслеживать все события доступа к определенным файлам и папкам на диске. С помощью политик аудита вы можете выявить события создания, чтения, изменения, удаления файлов и папок на файловой системе NTFS в Windows. Чаще всего аудит файловой используется для контроля доступа и изменений в общих сетевых папках, к которым одновременно могут обращаться несколько пользователей.
Включить политику аудита доступа к объектам файловой системы Windows
По умолчанию в Windows отключен аудит событий доступа к файлам и папкам. Включить аудит можно с помощью групповой политики. На отдельностоящем сервере для настройки политика аудита используется консоль редактора локальной групповой политики ( gpedit.msc ). Если вам нужно включить аудит сразу на множестве компьютеров в домене AD, используйте консоль управления доменными GPO ( gpmc.msc ).
- Откройте редактор GPO и перейдите в раздел Windows Settings -> Security Settings -> Advanced Audit Policy Configuration -> System Audit Policies -> Object Access;
- Откройте политику Audit File System и укажите, что вы хотите сохранять в журнал только успешные события доступа к объектам файловой системы (Configure the following audit events -> Success);
- Сохраните изменения и обновите настройки локальной групповой политики с помощью команды gpupdate /force .
Можно включить локальную политику аудита файловой системы из командной строки. Вывести доступные категории аудита:
AuditPol.exe /list /subcategory:*
Включить аудит успешных событий доступа к объектам файловой системы:
AuditPol.exe /set /subcategory:»File System» /success:enable
Вывести настройки категории аудита:
AuditPol.exe /get /category:»Object Access»
Настройка аудита событий на файлах и папках Windows
Несмотря на то, что в Windows включена политика аудита доступа к файлам и папкам, фактически событий в Event Viewer еще не попадают. Администратор должен вручную настроить параметры аудита на файлах и папках, которые нужно отслеживать.
К примеру, вы хотите отслеживать события чтения, изменения и создания файлов в каталоге C:\Docs.
- Откройте свойства папки и перейдите на вкладку Security -> Advanced -> Auditing;
- Нажмите кнопку Add и в поле Principal выберите пользователя или группы, чьи события доступа нужно отслеживать. Если нужно отслеживать доступ для всех пользователей, выберите Users (или Everyone, если нужно контролировать доступ системных процессов);
- В списке Type укажите, что нужно отслеживать только успешные событий ( Success );
- В Applies to можно указать, нужно ли применить аудит для папки, файлов, вложенных объектов (по умолчанию выбрано This folder, subfolders and files);
- В списке Advanced permissions выберите только те действия с файлами и папками, которые вы хотите отправлять в журнал аудита. Например: события чтения (List folder/read data) и изменения файлов (Create files or folders / write or append data)
- Сохраните настройки аудита.
При настройке политик аудита файловой системы старайтесь включать аудит только для тех папок и файлов, которые вам нужны. Включайте аудит только для тех файлов и событий, который вам нужны. Большое количество объектов аудита файловой системы приводит к значительному росту журнала событий Event Viewer.
Можно включить аудит для каталога с помощью PowerShell:
$Path = «C:\Docs»
$AuditChangesRules = New-Object System.Security.AccessControl.FileSystemAuditRule(‘BUILTIN\Users’, ‘Delete,DeleteSubdirectoriesAndFiles’, ‘none’, ‘none’, ‘Success’)
$Acl = Get-Acl -Path $Path
$Acl.AddAuditRule($AuditChangesRules)
Set-Acl -Path $Path -AclObject $Acl
Настройки аудита папки можно вывести с помощью PowerShell:
(Get-Acl «C:\Docs\» -Audit).Audit
Чтобы рекурсивно просканировать все каталоги и найти папки, на которых включен аудит файловой системы, воспользуйтесь таким скриптом:
$folders=Get-ChildItem «c:\docs» -Recurse |Where-Object {$_.PSIsContainer}
foreach ($folder in $folders)
{
$auditacl=(Get-Acl $folder.FullName -Audit).audit
if ($auditacl -ne «») {write-host $folder.FullName}
}
Просмотр событий аудита доступа к файлам и папкам в Windows
Теперь, если с файлами в указанной папке выполняются какие-то действия, политика аудита записывает их в Event Viewer. Чтобы просмотреть события:
-
- Запустите консоль Event Viewer ( eventvwr.msc );
- Перейдите в раздел Windows Logs -> Security и отфильтруйте лог по источнику:
Microsoft Windows security auditing , Task Category: File System ;
.
- Откройте содержимое любого события. Например в событии с EventID 4663 ( An attempt was made to access an object ) содержится информация: О пользователе, который произвел действие над файлом: Subject: Account Name:
Имя файла: Object Name:
Тип операции (изменение файла в этом случае): Accesses: WriteData (or AddFile)
Однако из за ограниченных возможностей фильтрации и поиска в событиях Event Viewer, использовать эту консоль для поиска всех операции с определенным файлом довольно неудобно.
Для вывода всех событий, связанных с определенным объектом лучше использовть PowerShell. Следующий PowerShell скрипт выведет все события доступа, связанные с указанным файлом (для получения списка событий используется производительный командлет Get-WinEvent):
$fileName = "C:\\docs\\13131.txt"
$results = Get-WinEvent -FilterHashtable @{logname='Security'; id=4663,4659} |`
Where-Object { $_.message -match $fileName -and $_.message -notmatch "Account Name:\s*machine$*"}`
foreach ($result in $results) {
$Account = $result.properties[1].Value
$objectName = $result.properties[6].Value
$accessMask = $result.properties[8].Value
if ( $accessMask -like "*00000000-*") { $accessMask=$result.properties[9].Value}
$accessMask2 = $result.properties[9].Value
$fileOperation = ""
switch -Wildcard ($accessMask) {
"*%%1538*" { $fileOperation = "READ_CONTROL" }
"*%%4416*" { $fileOperation = "ReadData (or ListDirectory)" }
"*%%4417*" { $fileOperation = "WriteData (or AddFile)" }
"*%%4418*" { $fileOperation = "AppendData (or AddSubdirectory or CreatePipeInstance)" }
"*%%4419*" { $fileOperation = "ReadEA" }
"*%%4420*" { $fileOperation = "WriteEA" }
"*%%4423*" { $fileOperation = "ReadAttributes" }
"*%%4424*" { $fileOperation = "WriteAttributes" }
"*%%4426*" { $fileOperation = "Delete" }
"*%%4428*" { $fileOperation = "ReadControl" }
"*%%4429*" { $fileOperation = "WriteDAC" }
"*%%4430*" { $fileOperation = "WriteOwner" }
"*%%4432*" { $fileOperation = "Synchronize" }
"*%%4433*" { $fileOperation = "AccessSystemSecurity" }
"*%%4434*" { $fileOperation = "MaximumAllowed" }
"*%%4436*" { $fileOperation = "GenericAll" }
"*%%4437*" { $fileOperation = "GenericExecute" }
"*%%4438*" { $fileOperation = "GenericWrite" }
"*%%4439*" { $fileOperation = "GenericRead" }
"*%%1537*" { $fileOperation = "DELETE" }
default { $fileOperation = "Unknown" }
}
Write-Host $result.Id $result.TimeCreated $Account $objectName $fileOperation
}
Вы можете отправлять собранные события аудита в вашу систему сбора логов, базу данных, текстовый лог файл или отправлять email уведомление через Send-MailMessage при доступе/модификации отслеживаемого файла.
This is the ultimate guide to Windows audit and security policy settings.
In this guide, I will share my tips for audit policy settings, password and account policy settings, monitoring events, benchmarks, and much more.
Table of contents:
- What is Windowing Auditing
- Use The Advanced Audit Policy Configuration
- Configure Audit Policy for Active Directory
- Configure Audit Policy for Workstations and Servers
- Configure Event Log Size and Retention Settings
- Recommended Password & Account Lockout Policy
- Recommended Audit Policy Settings
- Monitor These Events for Compromise
- Centralize Event Logs
- Audit Policy Benchmarks
- Planning Your Audit Policy
What is Windows Auditing?
Windows auditing is an important component of Active Directory security and helps to monitor network activity.
A Windows audit policy defines what type of events you want to keep track of in a Windows environment. For example, when a user account gets locked out or a user enters a bad password these events will generate a log entry when auditing is turned on. These audit logs are typically analyzed by an AD Audit tool to quickly spot any malicious activity on the network. An auditing policy is important for maintaining security, detecting security incidents, and meeting compliance requirements.
Use the Advanced Audit Policy Configuration
When you look at the audit policies you will notice two sections, the basic audit policy, and the advanced audit policy. When possible you should only use the Advanced Audit Policy settings located under Security Settings\Advanced Audit Policy Configuration.
The advanced audit policy settings were introduced in Windows Server 2008, it expanded the audit policy settings from 9 to 53. The advanced policy settings allow you to define a more granular audit policy and log only the events you need. This is helpful because some auditing settings will generate a massive amount of logs.
Important: Don’t use both the basic audit policy settings and the advanced settings located under Security Settings\Advanced Audit Policy Configuration. Using both can cause issues and is not recommended.
Microsoft provides the following information.
The advanced audit policy has the following categories. Each category contains a set of policies.
- Account Logon
- Account Management
- Detailed Tracking
- DS Access
- Logon/Logoff
- Object Access
- Policy Change
- Privilege Use
- System
- Global Object Access Auditing
Resources:
Threats and Countermeasures Guide: Advanced Security Audit Policy
Configure Audit Policy for Active Directory (For all Domain Controllers)
By default, there is a bare minimum audit policy configured for Active Directory. You will need to modify the default domain controller policy or create a new one.
Follow these steps to enable an audit policy for Active Directory.
Step 1: Open the Group Policy Management Console
Step 2: Edit the Default Domain Controllers Policy
Right click the policy and select edit
Step 3: Browse to the Advanced Audit Policy Configuration
Now browse to the Advanced Audit Policy Configuration
Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Advanced Audit Policy Configuration
Step 4: Define Audit Settings
Now you just need to go through each audit policy category and define the events you want to audit. See the recommended audit policy section for the recommended settings.
Configure Audit Policy on Workstations and Servers
It is highly recommended that you enable an audit policy on all workstations and servers. Most incidents start at the client device, if you are not monitoring these systems you could be missing out on important information.
To configure an audit policy for workstations and servers you will need to create a new audit policy. This will be a separate audit policy from your domain controllers. I would not apply this policy to the root of the domain, it is best to have all your workstations and servers in a separate organization unit and apply the audit policy to this OU.
You can see below I have an organizational unit called ADPRO computers. This organizational unit contains sub OUs for department workstations and a server OU for all the servers. I will create a new audit policy on the ADPRO computers OU, this policy will target all devices in this folder.
Configure Event Log Size and Retention Settings
It is important to define the security event log size and retention settings. If these settings are not defined you may overwrite and lose important audit data.
Important: The logs generated on servers and workstations from the audit policy are intended for short term retention. To keep historical audit logs for weeks, months, or years you will need to set up a centralized logging system. See the section below for recommendations.
In your audit policy, you can define the event log settings at Computer Configuration -> Policies -> Security Settings -> Event Log
Here are the recommended settings
- Maximum application log size
- 4,194,240 (kilobytes)
- Maximum Security log size
- 4,194,240 (kilobytes)
- Maximum system log size
- 4,194,240 (kilobytes)
Even with the log settings configured, you could still overwrite events in a short period of time. It all depends on your audit policy and how many users you have. If you are tracking bad password attempts for 2000 users that will generate way more events than 20 users.
Resource:
Recommended settings for event log sizes in Windows
Recommended Password and Account Lockout Policy
To successfully audit user accounts you need to ensure you have the password and account lockout policy configured. If you are auditing for account lockouts but don’t have a lockout threshold set you will never see those events.
These settings are from the MS Security baseline Windows 10 and Server 2016 document.
Password Policy
GPO location: Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Account Policies -> Password Policy
- Enforce password history
- 24
- Maximum password age
- 60
- Minimum password age
- 1
- Minimum password length
- 14
- Password must meet complexity requirements
- Enabled
- Store passwords using reversible encryption
- disabled
Account Lockout Policy
GPO location: Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Account Policies -> Account Lockout Policy
- Account lockout duration
- 15
- Account lockout threshold
- 10
- Reset lockout counter after
- 15
Resource:
Microsoft Security compliance toolkit
Recommended Audit Policy Settings
These settings are from the MS Security baseline Windows 10 and Server 2016 document.
Recommended domain controller security and audit policy settings.
GPO Policy location: Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Advanced Audit Policy Configuration
Account Logon
- Audit Credential Validation
- Success and Failure
- Audit Kerberos Authentication Services
- Not configured
- Audit Kerberos Service Ticket Operations
- Not configured
- Audit Other Account Logon Events
- Not configured
Account Management
- Audit Application Group Management
- Not configured
- Audit Computer Account Management
- Success
- Audit Distribution Group Management
- Not configured
- Audit Other Account Management Events
- Success and Failure
- Audit Security Group Management
- Success and Failure
- Audit User Account Management
- Success and Failure
Detailed Tracking
- Audit DPAPI Activity
- Not configured
- Audit Plug and Play Events
- Success
- Audit Process Creation
- Success
- Audit Process Termination
- Not Configured
- Audit RPC Events
- Not Configured
- Audit Token Right Adjected
- Not Configured
DS Access
- Audit Detailed Directory Service Replication
- Not configured
- Audit Directory Service Access
- Success and Failure
- Audit Directory Service Changes
- Success and Failure
- Audit Directory Service Replication
- Not Configured
Logon/Logoff
- Audit Account Lockout
- Success and Failure
- Audit User / Device Claims
- Not configured
- Audit Group Membership
- Success
- Audit IPsec Extended Mode
- Not configured
- Audit IPsec Main Mode
- Not configured
- Audit Logoff
- Success
- Audit Logon
- Success and Failure
- Audit Network Policy Server
- Not configured
- Audit Other Logon/Logoff Events
- Not configured
- Audit Special Logon
- Success
Object Access
- Audit Application Generated
- Not configured
- Audit Certification Services
- Not configured
- Audit Detailed File Share
- Not configured
- Audit File Share
- Not configured
- Audit File System
- Not configured
- Audit Filtering Platform Connection
- Not configured
- Audit Filtering Platform Packet Drop
- Not configured
- Audit Handle Manipulation
- Not configured
- Audit Kernal Object
- Not configured
- Audit Other Object Access Events
- Not configured
- Audit Registry
- Not configured
- Audit Removable Storage
- Success and Failure
- Audit SAM
- Not configured
- Audit Central Access Policy Staging
- Not configured
Policy Change
- Audit Audit Policy Change
- Success and Failure
- Audit Authentication Policy Change
- Success
- Audit Authorization Policy Change
- Success
- Audit Filtering Platform Policy Change
- Not configured
- Audit MPSSVC Rule-Level Policy Change
- Not Configured
- Audit Other Policy Change Events
- Not configured
Privilege Use
- Audit Non Sensitive Privilege Use
- Not configured
- Audit Other Privilege Use Events
- Not configured
- Audit Sensitive Privilege Use
- Success and Failure
System
- Audit IPsec Driver
- Success and Failure
- Audit Other System Events
- Success and Failure
- Audit Security State Change
- Success
- Audit Security System Extension
- Success and Failure
- Audit System Integrity
- Success and Failure
Global Object Access Auditing
- File System
- Not configured
- Registry
- Not configured
I recommend you download the Microsoft Security compliance toolkit. It has an Excel document with recommended security and audit settings for Windows 10, member servers, and domain controllers. I’ve also created an AD Audit Checklist for a quick reference on the recommended audit policy settings.
Centralize Windows Event Logs
When you enable a security and audit policy on all systems those event logs are stored locally on each system. When you need to investigate an incident or run audit reports you will need to go through each log individually on each computer. Another concern is what if a system crashes and you are unable to access the logs?
and… don’t forget those local logs are intended for short term storage. In large environments, those local logs will be overwritten by new events in a short period of time.
Centralizing your logs will save you time, ensure logs are available, and make it easier to report and troubleshoot security incidents. There are many tools out there that can centralize Windows event logs.
Below is a list of free and premium tools that will centralize Windows event logs. Some of the free tools require a bit of work and may require additional software to visualize and report on the logs. If you have the budget I recommend a premium tool, they are much easier to setup and saves you a ton of time.
- SolarWinds Log Analyzer (Premium tool, 30-day FREE trial)
- Windows Event Collector (Free, requires additional tools to visualize and report on data)
- ManageEngine Audit Plus – (Premium tool)
- Splunk – (Premium tool, a popular tool for analyzing various log files)
- Elastic Stack – (Free download)
Monitor These Events for Compromise
Here is a list of events you should be monitoring and reporting on.
- Logon Failures – Event ID 4624, 4771
- Successful logons – Event ID 4624
- Failures due to bad passwords – Event ID 4625
- User Account Locked out – Event ID 4740
- User Account Unlocked – Event ID 4767
- User changed password – Event ID 4723
- User Added to Privileged Group – Event ID 4728, 4732, 4756
- Member added to a group – Event ID 4728, 4732, 4756 , 4761, 4746, 4751
- Member removed from group – Event ID 4729, 4733, 4757, 4762, 4747, 4752
- Security log cleared – Event ID 1102
- Computed Deleted – Event ID 4743
Audit Policy Benchmarks
How do you know for sure if your audit policy is getting applied to your systems? How does your audit policy compare to industry best practices? In this section, I’ll show you a few ways you can audit your own systems.
Using auditpol
auditpol is a built-in command that can set and get the audit policy on a system. To view the current audit run this command on your local computer
auditpol /get /category:*
You can check these settings against what is set in your group policy to verify everything is working.
Microsoft Security Toolkit
I mention this toolkit in the recommended settings section but it is worth mentioning again. It contains a spreadsheet with the Microsoft recommended audit and security policy settings. It also includes GPO settings, a script to install, and GPO reports. It is a great reference for comparing how your audit policy stacks up against Microsoft’s recommendations.
CIS Benchmarks
CIS benchmarks have configuration guidelines for 140+ systems, including browsers, operating systems, and applications.
CIS Benchmarks
CIS CAT Pro
CIS provides a tool that can automatically check your systems settings and how it compares to its benchmarks. This is by far the best method for testing your audit policy against industry benchmarks. The pro version does require a membership, there is a free version with limited features.
CIS-CAT Pro
Planning Your Audit Policy
Here are some tips for an effective audit policy deployment.
Identify your Windows audit goals
Don’t just go and enable all the auditing settings, understand your organization’s overall security goals. Enabling all the auditing rules can generate lots of noise and could make your security efforts more difficult than they should be.
Know your Network Environment
Knowing your network, Active Directory architecture, OU design and security groups are fundamental to a good audit policy. Deploying an audit policy to specific users or assets will be challenging if you do not understand your environment or have a poor logical grouping of your resources.
Group Policy
It is best to deploy your audit policy with group policy. Group policy gives you a centralized location to manage and deploy your audit settings to users and assets within the domain.
How will you obtain event data?
You will need to decide how will event data be reviewed.
- Will the data be kept on local computers?
- Will the logs be collected on each system and put into a centralized logging system?
Resources:
Planning and deploying advanced security audit policies