Есть ли уникальная информация или другие причины, по которым событие Windows «Сообщение» не следует отбрасывать?
Возможно, показывая свое невежество, но есть ли причина держать Message из события Windows при загрузке в систему журналов?
Возможно ли, что они состоят из данных из других атрибутов для локализации / удобочитаемости и могут быть отброшены без потери важных данных?
Не знаю, подходящее ли это место для чтения, но этот кажется, указывает на этот случай?
Объем:
Только заботьтесь о Microsoft-ых событиях. Если какой-то случайный человек теоретически мог бы написать свое собственное событие с уникальными данными в поле сообщения через PowerShell или другие специальные средства, меня это не волнует.
Контекст:
Поглощение в систему регистрации, и message полевые завалы хранения значительно. Как правило, подробности о значении события хорошо документированы или могут быть изучены в локальной системе при создании инструментов для предоставления данных после их доставки в систему журналов, без message
Спасибо!
Похоже, что поле сообщения, по крайней мере, для предопределенной схемы событий, можно отбросить.
Спасибо josh_p за указание на этот блог
Пример, показывающий, как составлено поле сообщения для определенного идентификатора события:
( Get-WinEvent -ListProvider Microsoft-Windows-GroupPolicy ).Events |
Where-Object {$_.Id -eq 5314}
В области ИТ-безопасности может быть интересно отключить сбор части «Сообщение» при сборе событий в SIEM,. Это уменьшит размер передаваемых данных, а также снизит нагрузку на сервер-сборщик.
При использовании функции сборщика событий Windows (WEC) можно отключить сбор «сообщений», переключившись с «RenderedText"(то есть с полным" Сообщением ") в оптимизированный режим"События»(без« Сообщение ») в настройках подписки. Это показано на изображении ниже в« ContentFormat ».
