I have run into the same challenge. I have not found a solution yet, but I think the answer is going to utilizing the "Command" and/or "Object" fields. I'll keep working at it, and let you know what I find.
I am not sure if this is the best way but the way I do this is by creating an Field Match Alarm (you could also probably do this with a correlation rule). See below.
To quickly explain, this is what this rule does.
- Check to see if the Object (how the SIEM sees the security groups) is in my list of groups that I want to check for.
- Makes sure the event in a Administrative Normalization Rule
- Verifies that the source user isn't a machine object. We did this as we were getting a lot of false positives of machine objects modifying some of the security groups we wanted to monitor. This was done using a watch list created using something like this method: McAfee KnowledgeBase - How to filter the SIEM for users ending in a dollar ($) sign
- Lastly, I wanted to filter out certain events that occurred when a user was added or removed. I only wanted to see the event of adding or removing, not that a change was made to the group itself. You could probably do this backwards and have it only be "IN" the two events of adding or removing a user but at the time I wanted to make sure I didn't miss a event if it was a different signature ID then what I was expecting.
Hopefully that made sense.
Let me know if I need to go in more detail.
Other than the Machine Usernames, did you define any other variables? (i.e. Domain/Enterprise Admin Security Groups, Administrative, and DW - Group Change Signature IDs)
Domain/Enterprise Admin Security Groups and DW - Group Change Signature ID's were just two watch lists I populated. I guess you could probably do the same with variables.
The first just contains the list of security groups that I want to filter on. administrators, domain admins, enterprise admins, for example.
The second is another watch list that contains 4 signature ID's of events that relate to making a general change to a security group. I didn't want to clutter my alerts with simply all changes to a security group, just ones where a user is removed or added. In my example my list of signature ID's I am exempting are these:
The Administrative is just something you choose when selecting a normalized rule. When you go to the Normalization tab on a filter, you find it under Authentication -> Group -> Administrative.
Edit: I am using firmware version 9.4.2 MR5 but I believe what I have done should be good going back to any 9.4 build. I believe field matching was only introduced in 9.4 but you should still be able to do this with correlation .
Drew, You definitely did the correct way, however some caveats to consider for alarming on this content.
Alarms are default to alert 1 time every 10 minutes. If you have a new domain admin joining the company and someone adds them to several security enabled groups you are monitoring, the alarm will fire 1 time every 10 minutes. If it takes them 11 minutes to add them to all security enabled groups you are monitoring, you will have the 1st group they are added to, and the 1st group they added them to at the 10min 1 sec mark.
Secondly, by default, members (added|removed) (to|from) a security enabled (local|global|enterprise?) group, these signature IDs are aggregated by signature ID first, source IP second, destination IP third by default. Each of these rules will need to be modified to aggregate on signature ID 1st, command 2nd, destination user 3rd. This will keep the events from aggregating multiple groups, multiple source users, and multiple destination users into 1 event.
Hopefully this information helps in building your rule.
I'm still trying to figure this out in my environment. I'm assuming you would first need to add the domain controller as a WMI datasource or not? I than created a dynamic watchlist to query the domain admins security group. When I go to create the alarm, for the object in filter, it doesn't show up as an available watchlist.
We did this via ACE Correlation rules, of course this has been in place since we were on version 9.1.x 2 years ago.
For example, some simple ACE correlation rules that can monitor for users being added to or removed from a particular group.
The "Privileged AD Groups" watch list has the 5 major groups (Domain Admins, Enterprise Admins, Schema Admins, DNS Admins, Administrators) as well as several custom groups. My watchlist has both mixed case, and all lowercase versions of the names, it will be nice if/when we get the option to use Case Insensitivity in Correlations and Alarms. You can use it in Views and Reports, why not Correlations and Alarms.
The "DOMAIN_CONTROLLERS_SOURCE_USER" watchlist is a list of the DC's Computer Account Names with the $ at the end.
Things you may want to include in your Alarm are the AD Group Name, as well as both the Source and Destination User, if you monitor multiple Domains, you probably want to include the Domain as well.
Thanks for sharing. One question... Should we aggregate on destination user second, followed by command? I'm asking, because I see a lot of "member added" events, where the "Command" field is blank. I'm not sure how that effects aggregation.
Thanks for sharing. Unfortunately, Security Groups aren't parsing into my ESM properly. I can't create a Domain Admins watchlist, because I can't even filter Domain Admins from a given Windows Event Log. It's in the packet data, it's just not populating any of the available fields. Apparently, the name of the security group should appear in the 'Object' field.
McAfee is troubleshooting this issue with me, but so far I've only been told that it's a bug.