Практические материалы GuardCore
Практический минимальный перечень для Windows, Linux, сетевого оборудования, СУБД, приложений, виртуализации и средств защиты.
О месте этой статьи в практическом цикле
Это вводная статья серии практических материалов по регистрации, сбору, хранению и анализу событий информационной безопасности. Она не является пошаговой инструкцией по настройке конкретной операционной системы или средства мониторинга.
Её цель – сформировать общую рабочую модель: определить источники событий в составе ИС, выделить минимальные категории журналирования, расставить приоритеты и подготовить основу для дальнейшей технической реализации.
В следующих материалах эта модель будет последовательно реализована на практике: настройка расширенного аудита Windows, централизованный сбор событий через WEF/WEC, развёртывание Sysmon, журналирование Linux с помощью auditd и rsyslog, хранение журналов и построение минимальной системы мониторинга.
Что получит читатель
После прочтения можно составить собственный перечень регистрируемых событий, распределить их по источникам, определить приоритеты и подготовить доказательства того, что журналирование действительно работает.
Почему нельзя просто включить все журналы
При настройке аудита часто выбирают один из двух крайних вариантов. Первый – регистрировать только входы пользователей и ошибки приложений. Второй – включить максимальный аудит на всех узлах и отправлять в хранилище всё подряд. Оба подхода создают проблемы.
В первом случае информации недостаточно для расследования. Можно увидеть факт неуспешного входа, но не увидеть создание новой учётной записи, запуск подозрительного процесса, изменение политики аудита или отключение антивирусной защиты. Во втором случае полезные события теряются среди технического шума, быстро растут объёмы хранения, а специалисты перестают реагировать на предупреждения.
Практическая задача состоит не в сборе максимального количества записей, а в определении такого состава событий, который позволяет:
- обнаруживать попытки несанкционированного доступа;
- видеть изменения учётных записей, прав и настроек защиты;
- восстанавливать последовательность действий при инциденте;
- контролировать работоспособность журналирования и средств защиты;
- подтверждать выполнение установленных требований безопасности.
Пункт 1.1 приложения 3 к приказу ОАЦ № 66 требует определить состав сведений о событиях информационной безопасности, подлежащих регистрации. Требование обязательно для всех классов типовых информационных систем. Сам нормативный акт не даёт универсального списка идентификаторов событий: владелец ИС должен сформировать перечень с учётом архитектуры, активов, технологий и угроз.
Три разных действия: регистрировать, собирать и контролировать
Перед составлением перечня нужно разделить три связанных, но разных процесса.
Регистрация
Источник создаёт запись о событии: операционная система, приложение, СУБД, межсетевой экран или средство защиты.
Сбор и хранение
Записи сохраняются локально либо передаются в централизованное хранилище с установленным сроком хранения.
Мониторинг
События анализируются вручную или автоматически. На критичные события создаются оповещения и начинается разбор.
Не каждое зарегистрированное событие должно немедленно создавать тревогу. Например, успешный вход пользователя обычно сохраняется для последующего анализа, а очистка журнала безопасности или включение новой административной учётной записи может требовать немедленной проверки.
Такое разделение помогает избежать главной ошибки: организация не пытается превратить каждый журнал в поток тревог, но сохраняет достаточный контекст для расследования.
Сначала определите источники событий
Перечень событий нельзя составлять в отрыве от состава ИС. Сначала следует взять структурную и логическую схемы, реестр активов и определить, какие компоненты способны формировать значимые журналы.
| Группа источников | Что может входить |
|---|---|
| Операционные системы | Windows Server, Windows 10/11, Linux, специализированные ОС. |
| Службы идентификации | Active Directory, LDAP, RADIUS, VPN, SSO, MFA. |
| Сетевое оборудование | Маршрутизаторы, коммутаторы, Wi-Fi-контроллеры, балансировщики. |
| Средства защиты | Межсетевые экраны, антивирус, EDR, DLP, WAF, IDS/IPS, СКЗИ. |
| Прикладные системы | Web-приложения, API, 1С, внутренние порталы, системы документооборота. |
| СУБД | Microsoft SQL Server, PostgreSQL, Oracle, MySQL и другие. |
| Виртуализация и облако | Гипервизоры, управляющие консоли, контейнеры, облачная панель и API. |
| Резервное копирование | Сервер резервного копирования, агенты, репозитории и задания восстановления. |
Практический критерий: если компонент позволяет получить доступ к данным, изменить конфигурацию, выдать права, отключить защиту или повлиять на доступность ИС, его события должны быть рассмотрены при формировании перечня.
Минимальные категории событий
Ниже приведён базовый набор категорий, который можно использовать как основу. Он не заменяет анализ конкретной системы, но закрывает наиболее важные сценарии.
| Категория | Что регистрировать | Зачем |
|---|---|---|
| Вход и выход | Успешные и неуспешные входы, удалённые сессии, блокировки, завершение сеансов. | Выявление подбора паролей, необычных источников и доступа вне обычного режима. |
| Учётные записи | Создание, изменение, блокировка, разблокировка и удаление записей; сброс пароля. | Контроль жизненного цикла пользователей и служебных записей. |
| Группы и права | Добавление в привилегированные группы, выдача ролей, изменение разрешений и политик доступа. | Обнаружение повышения привилегий и несанкционированного расширения прав. |
| Административные действия | Использование повышенных прав, вход под административной записью, выполнение критичных команд. | Установление исполнителя и контроль привилегированной активности. |
| Процессы и сценарии | Запуск процессов, командная строка, PowerShell, shell-скрипты, системные утилиты. | Обнаружение вредоносных действий, в том числе через штатные инструменты ОС. |
| Службы и автозапуск | Создание и изменение служб, заданий планировщика, демонов, cron и механизмов автозапуска. | Выявление закрепления злоумышленника и скрытого запуска программ. |
| Политики и конфигурация | Изменение политик аудита, межсетевых правил, настроек защиты, системного времени и конфигураций. | Выявление ослабления защиты и неконтролируемых изменений. |
| Журналы | Очистка, остановка, переполнение, изменение размера, отказ передачи и изменение настроек журналирования. | Обнаружение попытки скрыть действия и контроль полноты аудита. |
| Доступ к критичным данным | Чтение, изменение, удаление, экспорт и массовая выгрузка определённых объектов. | Контроль конфиденциальности и целостности значимой информации. |
| Сетевые соединения | Разрешённые и заблокированные соединения, VPN, удалённое администрирование, изменение сетевой конфигурации. | Выявление сканирования, обхода сегментации и нетипичных направлений обмена. |
| СЗИ | Обнаружение вредоносного ПО, отключение агента, изменение политики, сбой обновления, удаление объекта из карантина. | Контроль реальной работоспособности защитных механизмов. |
| Доступность и сбои | Перезапуск, аварийное завершение, остановка критичной службы, отказ диска, нехватка места и потеря связи. | Выявление событий, влияющих на доступность и сохранность информации. |
| Резервное копирование | Успех и ошибка задания, удаление копии, изменение расписания, запуск восстановления. | Контроль готовности к восстановлению и защита копий от удаления. |
Что регистрировать на разных типах активов
Windows и Active Directory
Для Windows следует использовать расширенную политику аудита, потому что она позволяет включать отдельные подкатегории и управлять объёмом событий точнее, чем базовая политика. В минимальный набор обычно включаются:
- успешные и неуспешные входы, включая RDP и вход с явным указанием учётных данных;
- создание, изменение, блокировка и удаление пользователей и компьютеров;
- изменение членства в административных и других security-группах;
- изменение политик аудита и прав пользователей;
- создание процессов с командной строкой;
- PowerShell Script Block Logging и при необходимости модульное журналирование;
- создание и изменение служб и заданий планировщика;
- очистка журнала безопасности и ошибки службы журналирования;
- изменения критичных объектов Active Directory;
- остановка или сбой защитных агентов.
В отдельной статье этой серии целесообразно привести конкретные подкатегории Advanced Audit Policy и Event ID. В общей статье важнее зафиксировать логику: события должны охватывать рабочие станции, серверы и контроллеры домена. Наблюдение только за контроллерами домена не показывает действия, которые начинаются на пользовательских компьютерах.
Linux
Для Linux недостаточно сохранять только сообщения systemd или syslog. Для значимых действий используется Linux Audit, который позволяет отслеживать системные вызовы, доступ к файлам и выполнение привилегированных команд.
- успешные и неуспешные SSH-входы;
- использование sudo, su и изменение привилегий;
- изменение пользователей, групп, SSH-ключей и параметров PAM;
- изменение файлов конфигурации безопасности;
- запуск критичных административных и сетевых утилит;
- создание и изменение systemd-сервисов, cron-заданий и механизмов автозапуска;
- изменение правил межсетевого экрана и сетевых настроек;
- остановка auditd, rsyslog и защитных агентов;
- переполнение раздела журналов и ошибки записи;
- доступ к определённым критичным файлам и каталогам.
Набор правил auditd необходимо тестировать. Слишком широкое правило на активном файловом сервере может создать большой поток записей и затруднить анализ.
Сетевое оборудование и межсетевые экраны
- входы в административный интерфейс и неуспешные попытки;
- изменение конфигурации и сохранение новой версии;
- изменение правил доступа, маршрутов, VLAN и VPN;
- подключение и отключение интерфейсов;
- перезапуск, сбой, переключение на резервный узел;
- разрешённые и заблокированные соединения по критичным направлениям;
- срабатывания IDS/IPS, WAF и других защитных механизмов;
- изменение времени, NTP и настроек журналирования;
- отказ передачи syslog на центральный сервер.
Необязательно централизованно хранить каждое разрешённое соединение обычной пользовательской сети. Приоритет имеют административные действия, внешние подключения, межсегментный трафик, удалённый доступ и события средств защиты.
СУБД
- успешные и неуспешные подключения;
- создание и удаление пользователей, ролей и разрешений;
- изменение структуры базы, схем, таблиц и процедур;
- изменение параметров журналирования и аудита;
- резервное копирование, восстановление и удаление копий;
- массовая выгрузка или удаление данных;
- ошибки доступа и нарушения целостности;
- остановка, перезапуск и аварийное завершение СУБД.
Регистрация всех SQL-запросов не всегда оправдана: она может существенно увеличить объём и сохранить в журналах конфиденциальные значения. Следует выбирать события и команды, которые действительно необходимы для контроля, а доступ к журналам СУБД ограничивать.
Прикладные системы, web и API
- входы, ошибки аутентификации и блокировки;
- изменение ролей, прав и параметров безопасности;
- создание, изменение, удаление и экспорт критичных данных;
- административные операции в web-панели;
- обращения к API с идентификатором пользователя или клиента;
- ошибки авторизации и попытки доступа к чужим объектам;
- изменение конфигурации приложения и интеграций;
- ошибки, влияющие на целостность и доступность;
- загрузка файлов, выполнение фоновых заданий и внешние вызовы, если они значимы для модели угроз.
Журнал приложения должен позволять установить, кто выполнил действие, над каким объектом, когда, из какой сессии и с каким результатом. Сообщение «операция выполнена» без идентификатора пользователя и объекта почти бесполезно при расследовании.
Виртуализация, контейнеры и облако
- входы в управляющую консоль и API;
- создание, клонирование, удаление и изменение ВМ или контейнеров;
- подключение дисков, сетей и внешних хранилищ;
- создание снапшотов, экспорт и миграция;
- изменение ролей и административных разрешений;
- изменение виртуальных сетей и правил доступа;
- остановка, запуск и аварийное завершение объектов;
- изменение настроек резервирования и журналирования;
- операции с ключами, секретами и сервисными учётными записями.
Какие поля должна содержать запись
Сам факт регистрации события недостаточен. Запись должна содержать контекст, позволяющий связать её с пользователем, активом и другими событиями.
- точное время и часовой пояс;
- тип события и уникальный идентификатор;
- системное имя, IP-адрес или другой идентификатор источника;
- имя пользователя, служебной записи или процесса;
- источник подключения и адрес назначения, если применимо;
- идентификатор сессии, запроса или транзакции;
- объект, над которым выполнялось действие;
- выполненная команда или операция, если это допустимо;
- результат: успех, отказ, ошибка;
- причина отказа или код ошибки;
- предыдущее и новое значение для значимых изменений, если источник это поддерживает.
Важно: командные строки, SQL-запросы и HTTP-параметры могут содержать пароли, токены и персональные данные. Перед включением подробного журналирования необходимо проверить, не создаёт ли оно новый канал утечки.
Как расставить приоритеты
Практично разделить события на три уровня. Это помогает определить, что только хранить, что регулярно просматривать и что немедленно анализировать.
| Уровень | Назначение | Примеры |
|---|---|---|
| Критичный | Немедленное оповещение и разбор. | Очистка журнала, отключение защиты, новая административная запись, изменение политики аудита, массовое удаление данных. |
| Значимый | Регулярный анализ, корреляция и выявление отклонений. | Неуспешные входы, запуск административных инструментов, изменение конфигурации, нетипичные сетевые подключения. |
| Контекстный | Хранение для восстановления хронологии. | Обычные успешные входы, завершение процессов, штатные задания, информационные сообщения сервисов. |
Одно событие может иметь разный приоритет в разных условиях. Вход администратора на контроллер домена в рабочее время может быть штатным, а вход той же записи на пользовательскую станцию ночью – основанием для немедленной проверки.
Пошаговая последовательность внедрения
- Определить границы ИС. Использовать актуальные схемы и реестр активов.
- Выделить источники журналов. Для каждого актива указать тип журнала и ответственного.
- Определить сценарии контроля. Например: подбор пароля, повышение привилегий, отключение защиты, массовый экспорт.
- Сопоставить сценарии с событиями. Указать категории, идентификаторы и необходимые поля.
- Оценить объём. Включить настройку на тестовой группе и измерить реальный поток.
- Разделить регистрацию и оповещение. Не создавать тревогу на каждый сохранённый факт.
- Настроить единое время. Без синхронизации невозможно надёжно восстановить последовательность событий.
- Проверить защиту журналов. Ограничить изменение, удаление и административный доступ.
- Провести контрольные действия. Создать тестового пользователя, выполнить неуспешный вход, изменить правило и убедиться, что события зарегистрированы.
- Утвердить перечень и пересматривать его. Обновлять после изменений архитектуры, появления новых угроз и результатов инцидентов.
Как оформить перечень
Для эксплуатации удобнее использовать таблицу, а не длинный текст в регламенте. Минимальные поля такой таблицы:
| Источник | Событие | Идентификатор | Приоритет | Действие | Срок хранения |
|---|---|---|---|---|---|
| Контроллер домена | Добавление участника в административную группу | Event ID по версии ОС | Критичный | Оповещение и проверка заявки | По принятой политике |
| Linux-сервер | Неуспешный SSH-вход | Тип сообщения/правило | Значимый | Корреляция по числу и источнику | По принятой политике |
Идентификатор события следует привязывать к конкретной версии продукта. Одинаковое по смыслу событие в разных системах может иметь разные коды, каналы и поля.
Что подготовить для проверки
- утверждённый перечень регистрируемых событий;
- связь перечня с типами активов и схемами ИС;
- настройки политик аудита и журналирования;
- параметры локальных журналов и центрального хранилища;
- подтверждение синхронизации времени;
- примеры реальных событий по каждой критичной категории;
- результаты контрольного теста регистрации и передачи;
- настройки защиты журналов от изменения и удаления;
- порядок реагирования на критичные события;
- документированную периодическую проверку полноты журналирования.
Сильное доказательство – не скриншот включённой галочки, а цепочка: правило в документе, техническая настройка, сформированное тестовое событие, его поступление в хранилище и зафиксированная реакция.
Типичные ошибки
- Перечень копируется из чужого проекта. В нём появляются отсутствующие технологии, а реальные активы остаются без контроля.
- Учитываются только серверы. Первые признаки атаки часто появляются на рабочих станциях, VPN, сетевых устройствах и web-приложениях.
- Регистрируются только ошибки. Успешное административное действие может быть важнее серии технических сбоев.
- Собирается всё без приоритизации. Полезные события теряются среди большого объёма информационных сообщений.
- Нет контроля самого журналирования. Остановка агента или переполнение диска остаются незамеченными.
- Командные строки включены без оценки данных. В журнал попадают пароли, токены или персональные данные.
- Нет синхронизации времени. События разных систем невозможно выстроить в достоверную хронологию.
- Политика включена, но не протестирована. Нужное событие не формируется из-за отсутствия дополнительной настройки объекта или приложения.
- Перечень не обновляется. После внедрения новой системы, облака или СЗИ она остаётся вне аудита.
Итоговый чек-лист
- Определены все группы источников событий в границах ИС.
- Для каждого источника назначен владелец или ответственный.
- Перечень охватывает аутентификацию, права, процессы, конфигурации, журналы, сеть, СЗИ и доступность.
- События разделены на критичные, значимые и контекстные.
- Определено, что только хранится, что анализируется и на что создаётся оповещение.
- Проверены обязательные поля и отсутствие чувствительных данных в журналах.
- Настроено единое время.
- Проведены контрольные действия и получены ожидаемые события.
- Журналы защищены от изменения и удаления.
- Перечень пересматривается после изменений и инцидентов.
Вывод
Состав событий информационной безопасности определяется не количеством доступных журналов, а задачами обнаружения и расследования. Он должен охватывать все значимые слои ИС: пользователей, операционные системы, сетевую инфраструктуру, приложения, базы данных, виртуализацию, резервное копирование и средства защиты.
Начинать следует с минимального набора, который позволяет увидеть входы, изменения прав, административные действия, запуск процессов, изменение конфигураций, отключение защиты, операции с данными и сбои. Затем набор уточняется по фактическому объёму, модели угроз и результатам эксплуатации.
Качественно выполненный пункт 1.1 – это не длинный список Event ID. Это понятная модель: какой источник создаёт событие, зачем оно нужно, где хранится, кто его анализирует и какие действия выполняются при обнаружении отклонения.
Источники
- Приказ ОАЦ № 66 в редакции приказа № 259 от 10.12.2024.
- Best practices for event logging and threat detection, ASD ACSC и международные партнёры.
- Microsoft: Advanced Audit Policy Configuration.
- Microsoft: Windows Event Forwarding для обнаружения вторжений.
- NIST SP 800-92: Guide to Computer Security Log Management.
- Red Hat Enterprise Linux 9 Security hardening: Auditing the system.
- PostgreSQL: Server Configuration and Logging.
