Какой должна быть политика аудита

Данный вопрос является одним из наиболее сложных вопросов, которые приходится решать администратору Windows. Дело в том, что политика аудита настолько сильно связана с особенностями эксплуатации конкретного экземпляра операционной системы, что сформулировать эталонную политику аудита просто невозможно. Более того, даже для конкретного экземпляра операционной системы нельзя сформулировать адекватную политику аудита " на все времена". Политика аудита должна постоянно меняться, реагируя на изменения в конфигурации операционной системы и на зарегистрированные опасные события.

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

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

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

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

· Обязательна необходимость регистрации использования субъектами опасных привилегий.

· Успешные попытки внесения изменений в список пользователей должны регистрироваться в любом случае. Неуспешные попытки внесения таких изменений в Windows регистрироваться не могут.

· Изменения в политике безопасности должны регистрироваться обязательно.

· Регистрировать системные события в большинстве случаев нецелесообразно.

· Регистрировать запуск и завершение процессов имеет смысл только в том случае, когда есть обоснованные подозрения, что операционная система атакована вирусом, получившим права администратора.

Обычно фиксируют в журнале безопасности следующие важные (для анализа безопасности) события аудита:

Категория аудита ID события Описание

Регистрация 528 Успешная регистрация

538 Пользователь завершил сеанс системы

540 Успешная регистрация по сети

Учетная запись 560 Объект открыт

624 Создана учетная запись пользователя

632 Добавлен объект Security Enabled Global Group Member

636 Добавлен объект Security Enabled Local Group Member

642 Учетная запись пользователя изменена

644 Учетная запись пользователя заблокирована

645 Учетная запись компьютера создана

660 Добавлен объект Security Enabled Universal Group Member

675 Процесс аутентификации неудачен (только для Kerberos)

676 Запрос на билет аутентификации неудачен

(только для Kerberos)

680 Аутентификация NTLM (статус failed или successful)

681 Сбой при регистрации

Система 512 Windows стартовала

517 Журнал аудита очищен

Использование 577 Privileged Service Called (надо обратить внимание на права

привилегий пользователя в описании прав пользователя - т. е. на SeSystemTimePrivilege)

Изменение политики 612 Изменение политики аудита