Могут ли журналы содержать пароли и персональные данные?

Да, поэтому сбор журналов нужно проектировать с учётом защиты данных. Чувствительная информация может попасть в командные строки, HTTP-параметры, PowerShell-транскрипты и прикладные журналы. До подключения источников определите, какие поля следует маскировать, какие данные не нужно передавать вовсе и кто имеет право искать или выгружать записи. Исходные события можно сохранять для расследований, но только в защищённом хранилище и с учётом утверждённого маскирования или исключения полей. Если хранить оригинал нельзя, в нормализованной записи допустимо оставить устойчивую ссылку на него, при условии что исходная запись остаётся защищённой и доступной весь требуемый срок. Не размещайте секреты в полях исключений, описаниях правил корреляции и уведомлениях.

Что будет, если коллектор журналов недоступен?

Недоступность коллектора не означает, что все события будут доставлены после восстановления связи. В WEF повторная доставка работает в рамках поддерживаемого механизма, однако локальный журнал источника может перезаписать старые записи. У агентов локальная очередь ограничена доступным диском и заданными лимитами. Риск пропуска есть и при API-экспорте: он зависит от механизма чтения, задержки и обработки ошибок. Проверьте поведение заранее на тестовом источнике: кратковременно остановите компонент доставки или временно закройте путь к тестовому коллектору по согласованной процедуре. Затем восстановите связь и сравните число тестовых записей до, во время и после сбоя. Если обнаружены потери или переполнение, уменьшите поток событий, увеличьте поддерживаемый буфер либо пересмотрите архитектуру и срок удержания локальных журналов.

Нужно ли хранить исходные журналы после нормализации?

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

Почему нельзя связывать события только по имени пользователя?

Потому что одинаковые имена могут существовать в разных доменах, локальных системах и приложениях. Для связи событий предпочтительнее использовать SID или UID, идентификаторы сессии, процесса либо уникальный ID запроса. IP-адрес и временное окно применяйте только как дополнительные условия с учётом NAT и расхождения часов.

Централизованный сбор журналов безопасности серверов

Q: Как проверить безопасность сервера?

Частично — проверку стоит начать с инвентаризации критичных активов, сценариев обнаружения и владельцев реакции. Централизованные журналы помогают выявлять входы, привилегированные действия, изменения учётных записей, запуск процессов и отключение аудита. При тревоге сначала проверьте исходные события, актив и учётную запись, а не выполняйте немедленную блокировку.

Q: Нужно ли сразу блокировать учётную запись по тревоге?

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

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

Логи могут содержать секреты и персональные данные

Командные строки, параметры HTTP-запросов, PowerShell-транскрипты и журналы приложений иногда содержат пароли, токены, адреса электронной почты и иные чувствительные данные. До массового сбора определите, какие поля маскировать или не передавать, кто может искать и выгружать записи, а также срок их хранения. Не помещайте секреты в поля исключений, описания правил и уведомления.

Сначала определите сценарии и владельцев реакции

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

Подготовьте область сбора

Результат этого этапа — согласованный список источников, сценариев, сроков хранения и ответственных, по которому можно настраивать коллектор.

1
Инвентаризируйте активы и источники
Составьте таблицу: имя хоста, роль, среда, ОС, владелец, критичность, способ доставки и нужные журналы. Включите не только Linux и Windows, но и веб-серверы, базы данных, средства резервного копирования, службы каталогов и шлюзы доступа. Ожидаемый результат — для каждого критичного сервиса известны хотя бы один системный и один прикладной источник событий. Если владелец или роль неизвестны, не назначайте автоматическую реакцию на события этого актива до уточнения.
2
Опишите первые сценарии обнаружения
Для каждого сценария запишите: какие события нужны, поля связи, временное окно, получателя уведомления, первичную проверку и условия исключения. Начните с входов, привилегированных действий, создания учётных записей, запуска процессов и отключения аудита. Ожидаемый результат — правило можно объяснить одной фразой и проверить безопасным тестовым действием.
3
Определите хранение и допустимую потерю
Для каждого класса журналов задайте требуемый срок оперативного поиска, срок архивного хранения, необходимость репликации и допустимое поведение при переполнении очереди или диска. Оценку строят по измеренным среднему и пиковому потоку событий, размеру исходных и нормализованных записей, периоду хранения, числу копий и запасу на всплески. Не используйте универсальную норму гигабайтов на сервер: нагрузка существенно меняется от роли хоста и включённого аудита.
4
Назначьте порядок реакции
Для каждого приоритета определите канал уведомления, время подтверждения, ответственного и действие при отсутствии ответа. Например, первичная проверка должна включать просмотр исходных событий, проверку актива и учётной записи, а не немедленную блокировку. Ожидаемый результат — получатель тревоги понимает, что проверить и кому передать подтверждённый инцидент информационной безопасности.

Где искать более широкий контекст

Централизованные логи — одна из частей проверки. План «как проверить безопасность сервера» и приоритеты базовой защиты собраны в статье «Базовая защита сервера: как составить security baseline».

Соберите приоритетные события Linux, Windows и сервисов

Один журнал не заменяет другой. Журнал аутентификации Linux показывает попытки входа, но обычно не даёт полной картины запуска процессов. auditd фиксирует выбранные действия ядра и процессов, а systemd journal — сообщения служб и системы. В Windows Журнал безопасности Windows, Operational-каналы PowerShell и журналы приложений также дополняют друг друга. Набор политик аудита, конкретные Windows Event ID и условия их появления рассматриваются в аудите Windows Server, а правила Linux Audit — в аудите безопасности Linux.

Минимальный стартовый набор источников

Среда	Что собрать в первую очередь	Для чего нужно
Linux	События SSH, PAM и локальных входов; сообщения sudo; systemd journal системных и критичных служб	Неудачные и успешные входы, административные действия, перезапуски и ошибки сервисов
Linux	События Linux Audit: запуск процессов, изменения учётных записей и групп, привилегированные действия, изменение конфигурации аудита	Связь субъекта, процесса и результата действия; сохранение аудиторского следа
Windows	Security Event Log: входы и неудачные входы, использование специальных привилегий, создание процессов, изменения учётных записей и политики аудита, очистка журнала	Входы, повышение привилегий, создание и запуск программ, признаки ослабления аудита
Windows	PowerShell Operational и поддерживаемое журналирование команд; System и Application для критичных служб	Исполнение скриптов, ошибки службы, остановка агентов и неожиданные перезапуски
Серверные сервисы	Журналы веб-сервера, VPN или удалённого доступа, базы данных, службы каталогов, резервного копирования и панели управления	Аутентификация в приложении, административные изменения, ошибки доступа, источник клиентского запроса

Исходные записи должны оставаться доступны

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

Выберите механизм доставки событий

Поддерживаемые ОС, журнальные каналы, форматы, агенты, шифрование, взаимная аутентификация и локальная буферизация зависят от коллектора или SIEM и его версии. То же относится к возможности читать systemd journal, syslog и события auditd. Перед внедрением сверяйте возможности именно выбранной версии с официальным руководством производителя; названия экранов, статусов и параметров конфигурации не универсальны.

Выбор транспорта по типичной задаче

Механизм	Когда подходит	Что проверить до внедрения	Ограничение
Syslog от службы или Linux-сборщика	Сервис уже пишет syslog или нужен простой сбор системных сообщений	Поддержку TCP или защищённого транспорта, формат сообщений, очереди на источнике, сохранение исходного имени хоста	Не все журналы и поля Linux Audit или journal передаются без дополнительного разбора
Агент Linux	Нужны несколько источников, чтение journal и auditd, локальная очередь, обогащение метаданными или взаимная аутентификация	Права агента, нагрузку, порядок обновления, поведение при недоступности коллектора, защиту его учётных данных	Агент становится компонентом, который нужно сопровождать и контролировать
Пересылка событий Windows	Преимущественно Windows-среда, где достаточно подписок на каналы Event Log без отдельного агента	Режим подписки, WinRM, права источника и коллектора, размер и удержание локальных журналов, состояние подписок	Сохранность при долгой недоступности зависит от удержания исходных записей и настроек доставки; это не бесконечная очередь
Агент SIEM или EDR	Нужны расширенные каналы, нормализация на узле, локальный буфер или единая политика с другими источниками	Поддерживаемые каналы, права, защищённый транспорт, лимиты очередей, контроль версии и ротацию учётных данных	Состав и семантика собираемых полей зависят от продукта
API или экспорт сервиса	Приложение работает в облаке, на управляемой платформе либо предоставляет собственный API журналов	Ограничения API, курсор или закладки чтения, частоту запросов, полноту полей и обработку ошибок	Задержка и риск пропуска зависят от механизма экспорта

Windows Event Forwarding поддерживает подписки, инициируемые источником, и подписки, инициируемые коллектором. В типичной доменной схеме часто выбирают вариант, когда источники сами подключаются к коллектору: это уменьшает число входящих подключений к серверам. Для работы WEF обычно требуется служба Windows Remote Management на источнике и настроенный Windows Event Collector на коллекторе; права на чтение выбранных каналов и доступ к Security log зависят от канала, политики и учётной записи подписки. Требования и порядок настройки сверяйте с официальной документацией Microsoft по Windows Event Forwarding для вашей версии Windows и выбранного типа подписки.

Недоступный коллектор не означает гарантированную сохранность

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

Подключите источник и подтвердите доставку

Сначала подключите по одному Linux- и Windows-серверу каждого типового профиля. Массовое развёртывание начинайте только после проверки полей, задержки и поведения при сбое связи.

1
Проверьте время и имя Linux-хоста
Убедитесь, что источник использует синхронизированное время, имеет стабильное имя хоста и отправляет его вместе с событием. Ожидаемый результат — время синхронизировано, а имя хоста соответствует инвентаризации. При ошибке времени сначала исправьте NTP или другой настроенный механизм синхронизации: корреляция по времени при расхождении часов ненадёжна.
2
Настройте поддерживаемый маршрут Linux-сборщика
Включите в выбранном агенте или syslog-сборщике чтение нужных источников: системного журнала, журнала аутентификации, journal и при необходимости Linux Audit. Настройте защищённую доставку и локальную очередь, если эти функции поддерживает выбранная версия. Ожидаемый результат — в коллектор приходит тестовая запись с именем хоста, исходным источником и временем. Если часть записей не приходит, сравните фильтры сборщика, права его процесса и локальный журнал до отправки.
3
Подготовьте Windows-коллектор и источник
В WEF включите и проверьте службу коллектора, создайте подписку на нужные каналы в выбранном режиме, затем настройте источник согласно официальному руководству Microsoft для вашей схемы. Для агентского сбора установите поддерживаемый агент с минимально необходимыми правами. Ожидаемый результат — источник отображается активным, а тестовое событие доступно на коллекторе или в SIEM. Если источник неактивен, проверьте службу WinRM или агента, разрешение на чтение канала, доверие и сетевой путь.
4
Сверьте локальное и центральное событие
Создайте безопасное тестовое событие: контролируемый неудачный вход в тестовую учётную запись, перезапуск некритичной тестовой службы или запись тестового сообщения приложением. Найдите исходную запись на сервере и её копию в центральном хранилище. Ожидаемый результат — совпадают источник, время с известным смещением, хост и устойчивый идентификатор либо набор полей, позволяющий сопоставить записи. При расхождении не включайте правило: сначала исправьте парсер, часовую синхронизацию или маршрутизацию.
5
Проверьте восстановление после краткого сбоя
На тестовом источнике кратковременно остановите только компонент доставки либо временно запретите путь к тестовому коллектору по согласованной процедуре, затем восстановите связь. Сверьте количество тестовых записей до, во время и после сбоя. Ожидаемый результат — известное поведение очереди и видимая диагностика задержки. Если записи потеряны или очередь переполняется, уменьшите поток, увеличьте поддерживаемый буфер либо пересмотрите архитектуру и срок удержания локальных журналов.

Проверка времени и состояния синхронизации на Linux с systemd. В выводе должны быть корректные локальное и универсальное время, часовой пояс и признак синхронизации; точные поля зависят от дистрибутива.

timedatectl status

Проверка состояния Linux Audit на хосте, где установлен auditd. Для запроса нужны права root или эквивалентные административные полномочия. Команда должна показать состояние подсистемы; при отсутствии команды или службы используйте документацию дистрибутива и статью [«Аудит безопасности Linux»](/baza-znaniy/praktika/audit-bezopasnosti-linux).

sudo auditctl -s

check-wef.ps1

Get-Service WinRM, Wecsvc | Select-Object Name, Status, StartType
wecutil es
Get-WinEvent -LogName ForwardedEvents -MaxEvents 5 |
  Select-Object TimeCreated, ProviderName, Id, MachineName

Выполняйте пример на Windows Event Collector в PowerShell-сессии с административными или эквивалентными делегированными правами. Он проверяет службы WinRM и Windows Event Collector, выводит подписки коллектора и последние пересланные записи. Канал ForwardedEvents характерен для типичной конфигурации WEF, но способ отображения и параметры подписки зависят от Windows и её настройки. Если служба остановлена, нет подписок или в канале нет записей после теста, проверьте конфигурацию подписки, права и журналы событий WEF на источнике и коллекторе.

Нормализуйте поля, сохраняя контекст

Событие аудита пригодно для расследования, если его можно связать с субъектом, объектом и результатом. Приводите разнородные записи к общей схеме, но не подменяйте исходные значения: например, храните отдельно оригинальное имя пользователя и нормализованный идентификатор учётной записи.

Характеристика	Значение
Время	Время события в UTC или с явным часовым поясом или смещением; время приёма отдельно; сведения о синхронизации часов при их наличии
Актив	Стабильный идентификатор, имя хоста, роль, среда, критичность, IP-адреса — с учётом того, что адрес может меняться
Источник события	ОС, канал или файл журнала, провайдер, приложение, версия схемы или парсера
Субъект	Учётная запись, домен или область, UID или SID при наличии, тип учётной записи, идентификатор сессии
Действие и объект	Операция, процесс или сервис, командная строка с учётом маскирования, родительский процесс, файл, ресурс или целевая учётная запись
Сеть	Исходный и целевой IP-адрес, порт, протокол, направление — если источник действительно предоставляет эти поля
Результат	Успех, отказ, код ошибки, причина или статус, если они доступны
Исходная запись и трассировка	Исходная запись в защищённом хранилище либо ссылка, по которой она остаётся доступной весь установленный срок; идентификатор события, время приёма и информация о маршруте доставки

ХарактеристикаВремя

ЗначениеВремя события в UTC или с явным часовым поясом или смещением; время приёма отдельно; сведения о синхронизации часов при их наличии

ХарактеристикаАктив

ЗначениеСтабильный идентификатор, имя хоста, роль, среда, критичность, IP-адреса — с учётом того, что адрес может меняться

ХарактеристикаИсточник события

ЗначениеОС, канал или файл журнала, провайдер, приложение, версия схемы или парсера

ХарактеристикаСубъект

ЗначениеУчётная запись, домен или область, UID или SID при наличии, тип учётной записи, идентификатор сессии

ХарактеристикаДействие и объект

ЗначениеОперация, процесс или сервис, командная строка с учётом маскирования, родительский процесс, файл, ресурс или целевая учётная запись

ХарактеристикаСеть

ЗначениеИсходный и целевой IP-адрес, порт, протокол, направление — если источник действительно предоставляет эти поля

ХарактеристикаРезультат

ЗначениеУспех, отказ, код ошибки, причина или статус, если они доступны

ХарактеристикаИсходная запись и трассировка

ЗначениеИсходная запись в защищённом хранилище либо ссылка, по которой она остаётся доступной весь установленный срок; идентификатор события, время приёма и информация о маршруте доставки

Не склеивайте события по одному только имени пользователя: одинаковое имя может существовать в разных доменах, локальных системах и приложениях. Для идентификации предпочитайте SID или UID при наличии, идентификатор сессии, идентификатор процесса и уникальный ID запроса. Исходный IP-адрес и временное окно используйте как дополнительные условия корреляции, учитывая NAT, смену адресов и возможное расхождение часов. Поля AUID, UID и тонкая настройка Linux Audit требуют отдельного разбора в статье «Аудит безопасности Linux».

Внедрите первые правила корреляции и оповещения

Корреляция событий безопасности связывает сигналы по времени, хосту, учётной записи, IP-адресу, сессии и другим устойчивым полям. Несколько совпавших сигналов — причина проверки, но не доказательство компрометации: легитимная автоматизация, тестирование или ошибка конфигурации могут давать похожую картину.

Первые сценарии: правило должно вести к конкретной проверке

Сценарий	Источники	Поля для связи	Условие тревоги	Первичное действие
Перебор паролей	Linux SSH/PAM, Windows Security, журналы VPN или приложения	Учётная запись, исходный IP, хост или сервис, время	Серия неудачных аутентификаций в согласованном окне с учётом штатных ошибок	Проверить актив, IP, целевую учётную запись, блокировки и последующие успешные входы
Успешный вход после неудач	Те же журналы аутентификации	Учётная запись, источник, тип входа, сессия, время	Успех после связанной серии неудач в пределах выбранного окна	Подтвердить владельца учётной записи и легитимность источника; при риске передать на дальнейший разбор
Привилегированное действие	sudo, Linux Audit, Windows Security, журналы управления сервисом	Учётная запись, сессия, процесс, хост, объект, результат	Использование административных прав вне ожидаемого контекста или на критичном активе	Сверить заявку, окно обслуживания, владельца и исходную команду или действие
Создание или изменение учётной записи	Linux Audit и журналы управления пользователями; Windows Security; служба каталогов	Кто выполнил действие, новая учётная запись, хост или домен, время	Создана учётная запись, изменена группа или выданы привилегии без ожидаемого контекста	Проверить автора, роль новой учётной записи, членство в группах и связанное изменение
Подозрительный запуск процесса	Linux Audit, systemd journal, Windows Security и PowerShell	Хост, пользователь, процесс и родительский процесс, командная строка, хеш при наличии	Запуск из необычного пути, неожиданным сервисом или с опасной комбинацией аргументов по локальной политике	Открыть исходную команду, родительский процесс, пользователя и историю активности на хосте
Очистка журнала или остановка аудита	Windows Security/System, systemd journal, Linux Audit, журналы агента	Хост, учётная запись, сервис, время, результат	Очистка защищаемого журнала, отключение аудита, остановка сборщика или изменение его конфигурации	Проверить, было ли изменение согласовано; сохранить доступные записи и оценить период возможной потери наблюдаемости

Пороги не универсальны

Количество неудачных входов, длина временного окна и список «подозрительных» команд зависят от сервиса и штатной активности. Точные Event ID, условия генерации и различия Windows-каналов сверяйте с документацией Microsoft и статьёй «Аудит Windows Server: Security Log, Advanced Audit Policy и PowerShell». Синтаксис корреляции, временных окон, дедупликации, исключений и приоритизации зависит от SIEM и его версии.

Настройте полезные оповещения

Цель — не максимальное число тревог, а уведомления, на которые назначенный получатель может реагировать.

1
Задайте приоритет по последствиям и уверенности
Учитывайте критичность актива, привилегии учётной записи, надёжность источника, число связанных сигналов и возможный ущерб. Высокий приоритет оправдан, когда действие опасно само по себе либо затрагивает критичный актив. Ожидаемый результат — у каждого правила есть объяснимый приоритет и получатель.
2
Добавьте дедупликацию
Объединяйте повторяющиеся тревоги по сценарию, активу, учётной записи, источнику и ограниченному окну времени. Уведомление должно показывать число объединённых событий и последнее время наблюдения. Ожидаемый результат — одна серия однотипных ошибок создаёт один инцидентный контекст, а не сотни сообщений.
3
Вносите allowlist только с владельцем и сроком
Используйте allowlist для конкретной утверждённой автоматизации, сервисной учётной записи, административного IP или окна работ. Запись должна содержать причину, владельца, область действия и дату пересмотра. Не исключайте целиком критичный хост, весь диапазон адресов или все действия администратора: это убирает наблюдаемость вместо снижения шума.
4
Опишите содержимое тревоги
Добавьте приоритет, затронутый актив, краткое описание условия, время, учётную запись, источник, ссылку на исходные события и первичное действие. Ожидаемый результат — аналитик может начать проверку без ручного поиска базового контекста.
5
Пересмотрите ложные тревоги
Каждое ложноположительное срабатывание разбирайте по причине: недостаток поля, неверная группировка, слишком широкое условие или неучтённая штатная операция. Исправляйте правило или добавляйте узкое исключение, затем повторяйте безопасный тест. Если тревоги остаются без разбора, временно сократите набор правил до тех, для которых есть владелец реакции.

Защитите канал, коллектор и хранение

Центральное хранилище журналов — критичный актив: атакующий, получивший право менять или удалять записи, может скрыть следы. Разделяйте роли администратора платформы, оператора источников и пользователя поиска там, где это поддерживает продукт; выдавайте минимальные права. Ограничьте административный доступ к коллектору и хранилищу, ведите аудит изменений правил, учётных данных и политик хранения.

Используйте шифрование при передаче и аутентификацию источника и коллектора, если это поддерживается выбранным механизмом. Поддерживаемые криптографические параметры, сертификаты и порядок ротации реквизитов определяются продуктом и его версией.
Храните учётные данные агентов и закрытые ключи отдельно от обычных конфигураций; ограничьте их чтение процессом агента и администраторами, которым это действительно нужно. Для сертификатов контролируйте защиту от подмены, срок действия, цепочку доверия и порядок замены.
Разделите оперативное хранилище для поиска, архив и резервные копии. Для записей, требующих повышенной защиты, применяйте поддерживаемые механизмы неизменности или контроля удаления и регулярно проверяйте, что они работают.
Настройте мониторинг свободного места, скорости поступления, отставания обработки, возраста локальных очередей, ошибок парсинга и отсутствия событий от критичных источников.
Заранее определите действие при нехватке диска: остановка приёма, контролируемая ротация менее ценных данных, расширение хранилища или переключение на резервный узел. Не оставляйте это на усмотрение компонента по умолчанию.

Неизменность не отменяет резервирование и контроль доступа

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

Проверьте конвейер без атаки на продуктивной системе

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

Проведите приёмочную проверку

1
Создайте матрицу тестов
Для каждого правила запишите безопасное действие, ожидаемые исходные события, ожидаемую нормализованную запись, правило и ожидаемое уведомление. Пример: один намеренно неверный вход в тестовую учётную запись должен появиться в локальном и центральном журнале, но не обязательно вызвать тревогу перебора.
2
Проверьте отдельные источники
Выполните безопасное действие на Linux и Windows: тестовый неудачный вход, согласованное создание тестовой локальной учётной записи с последующим удалением либо перезапуск тестовой службы. Ожидаемый результат — исходные события появляются в нужных каналах и содержат требуемые поля. Если локального события нет, сначала исправьте политику аудита, а не правило SIEM.
3
Проверьте нормализацию и поиск
Найдите центральную запись по имени хоста, учётной записи, времени и исходному идентификатору. Сверьте часовой пояс, результат операции, источник и ссылку на оригинал. Ожидаемый результат — записи разных ОС можно найти общими полями, при этом исходные данные доступны для проверки.
4
Проверьте корреляцию и подавление
Создайте согласованную последовательность нескольких тестовых событий, достаточную для выбранного правила, затем повторите её в пределах окна дедупликации. Ожидаемый результат — появляется одна тревога с исходными событиями и счётчиком повторов либо иное заранее определённое поведение. Если уведомлений слишком много или нет вовсе, корректируйте поля связи и окно на тестовых данных.
5
Проверьте операционную реакцию
Передайте тестовое уведомление назначенному получателю. Он должен открыть исходные события, определить актив и выполнить описанное первичное действие. Ожидаемый результат — фиксируются время получения, результат триажа и необходимые улучшения правила. Если получатель не понимает, что делать, доработайте текст тревоги и порядок эскалации.
6
Проверяйте здоровье регулярно
Добавьте регулярную проверку: есть ли свежие события от каждого критичного источника, не растёт ли задержка, достаточно ли места, действуют ли сертификаты и учётные данные, не изменились ли правила и сроки хранения. Ожидаемый результат — потеря наблюдаемости сама становится видимым событием, а не обнаруживается только во время расследования.

При подтверждённом признаке взлома не ограничивайтесь обработкой тревоги в коллекторе: порядок изоляции, сохранения артефактов и восстановления описан в статье «Сервер взломали: изоляция, артефакты и первые действия».

Термины в статье

Allowlist: Allowlist — перечень разрешающих записей или правил: система допускает только те субъекты, объекты, действия или значения, которые им соответствуют.
SIEM: SIEM — класс систем централизованного сбора, нормализации и корреляции событий безопасности для выявления инцидентов, расследования и отчётности.
auditd: auditd — служба Linux Audit, принимающая от ядра сообщения аудита, в том числе отобранные по правилам, и записывающая их в журнал для расследований, анализа доступа и проверки соответствия.
Аудиторский след: Аудиторский след — упорядоченный по времени набор записей о действиях и изменениях, позволяющий установить, кто, когда, над чем и с каким результатом выполнил операцию, а также откуда поступил запрос.
Журнал аудита: Журнал аудита — защищаемая совокупность записей о значимых действиях и изменениях с указанием времени, субъекта, объекта, результата и контекста для расследования и контроля.
Журнал аутентификации: Журнал аутентификации — набор записей о попытках подтверждения личности, их результатах и данных, необходимых для расследования и контроля доступа.
Журнал безопасности Windows: Журнал безопасности Windows — системный журнал событий, фиксирующий результаты аудита входов, доступа к объектам, изменений политик и привилегий в Windows.
Инцидент информационной безопасности: Инцидент информационной безопасности — выявленное или обоснованно подозреваемое событие, нарушающее политику защиты либо создающее угрозу конфиденциальности, целостности или доступности.
Корреляция событий безопасности: Корреляция событий безопасности — анализ связанных записей из одного или нескольких источников для выявления общей цепочки действий, аномалии или признаков инцидента.
Критичность актива: Критичность актива — оценка важности ИТ-актива для бизнеса по последствиям его отказа, компрометации или недоступности, определяющая приоритет защиты и восстановления.
Ложноположительное срабатывание: Ложноположительное срабатывание — результат контроля безопасности, ошибочно отмечающий безопасное событие, файл или конфигурацию как угрозу либо нарушение.
Пересылка событий Windows: Пересылка событий Windows — механизм доставки записей журналов Windows с источников на сервер-коллектор по подпискам, без установки отдельного агента сбора.
Событие аудита: Событие аудита — действие, попытка действия или изменение состояния, регистрируемое системой согласно политике аудита для последующей проверки.
Событие безопасности: Событие безопасности — наблюдаемое действие или изменение состояния системы либо сети, значимое для защиты; оно может быть штатным, связанным с ошибкой или подозрительным.
Триаж инцидента: Триаж инцидента — первичная оценка события безопасности для подтверждения инцидента, определения его приоритета, масштаба, потенциального ущерба и необходимых действий реагирования.
Централизованное журналирование: Централизованное журналирование — сбор и хранение журналов разных систем в общем сервисе для унифицированного поиска, контроля целостности и анализа.