[email protected] wrote:

> On a Windows machine that is running the agent, I pguibord removed user
> jszostak from the Administrators group and below is the actual windows
> event veiwer event that was logged. All is good.

>     Below you can see the actual OSSEC syslog message that was sent as
>     an email alert. Herein lies the problem. Out of this I can see
>     pguibord removed someone from the administrators group but do not
>     know who was removed and need to know. Any thoughts folks, please?

>     Received From: (JumpStation1) 172.16.15.18->WinEvtLog
>     Rule: 18114 fired (level 8) -> "Group account changed."
>     Portion of the log(s):
> 
>     WinEvtLog: Security: AUDIT_SUCCESS(637): Security: pguibord: JUMP1:
>     JUMP1: Security Enabled Local Group Member Removed:          Member
>     Name: -           Member ID:
>     %{S-1-5-21-3595745658-3963117629-2623638570-1012}     Target Account
>     Name: Administrators      Target Domain: Builtin           Target
>     Account ID: %{S-1-5-32-544}       Caller User Name: pguibord      
>     Caller Domain: JUMP1     Caller Logon ID: (0x0,0x5E3075)         
>     Privileges: -    

Hello pguibord,

The problem is with the way Windows stores and displays user names in
certain cases. What you're experiencing (I believe) is a situation where
the MMC resolves the SID for you but when OSSEC and other log management
tools read the logs using the Windows API, they get the SID. That
doesn't explain why it's only that way with certain events and
user/group fields, but that's my experience in investigating this issue.

It really is a big deal from the auditing perspective because how are
you supposed to know what actually happened? I know I can't memorize
SIDs and map them to user names in my head.

One thing you can do is run sid2user to figure out who it is. But that
doesn't help if you don't have access to the host.

As I said, this is not just a problem for OSSEC but for many log
management tools I have seen. In my opinion, it's a big problem.

I think the correct way to handle it would be to extract the log in raw
form, which is currently what's being done, so you have the correct log
for posterity (SIDs are unique and not reused), but the analysis
application should attempt to resolve the name to a human-readable name
and include it as extra data.

-- 
Michael Starks
[I] Immutable Security
http://www.immutablesecurity.com
Information Security, Privacy and Personal Liberty

Reply via email to