I've noticed that while the Windows Event Viewer shows fairly human
readable information in audit records, like this audit log section:
Access Reasons: READ_CONTROL: Granted by
D:(A;ID;0x1200a9;;;BU)
SYNCHRONIZE: Granted by
D:(A;ID;0x1200a9;;;BU)
ReadData (or ListDirectory): Granted by
D:(A;ID;0x1200a9;;;BU)
ReadEA: Granted by D:(A;ID;0x1200a9;;;BU)
ReadAttributes: Granted by
D:(A;ID;0x1200a9;;;BU)
that the underlying XML of the same Windows log entry is full of %% codes
in place of human readable terms, like this:
<Data Name="AccessReason">%%1538: %%1801 D:(A;ID;0x1200a9;;;BU)
%%1541: %%1801 D:(A;ID;0x1200a9;;;BU)
%%4416: %%1801 D:(A;ID;0x1200a9;;;BU)
%%4419: %%1801 D:(A;ID;0x1200a9;;;BU)
%%4423: %%1801 D:(A;ID;0x1200a9;;;BU)
</Data>
Would it be plausible to have the OSSEC Windows agent render this content using
the same facility that the Windows Event Viewer does, before sending the event
along to the OSSEC server?
I use OSSEC agents to convey Windows logs back to my OSSEC server for analysis
and stashing into my ELK system. While I will probably do textual search and
replace on the ELK side to resolve this issue for now, it strikes me there
would be broader benefit to the OSSEC Windows community if the OSSEC agent
itself were to render "Access List" and "Access Reason" elements of Windows
audit log records in the same way that the Windows Event Viewer does.
Thanks for listening,
Kevin
--
---
You received this message because you are subscribed to the Google Groups
"ossec-list" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
