Just out of curiosity, have you attempted create AD groups and run tests to see what signatures fire whenever you add / remove stuff?
That is where I would start and what to look for. Since this depends on aggregation being setup properly to account for that user and or group, I'm going to assume it's off for the sake of having the ability to view all parsed values on each log.
With that said, evaluate the logs after making a change and then focus on the specific Normalization and or SIGID being flagged to narrow your correlation or alert focus. Before moving forward, at least make sure you are capturing this in ESM logs. If not, figure out why AD isn't logging it. If you have no issue seeing the test logs, try the following:
I would look into leveraging data enrichment to view particular LDAP AD attributes unique to the "specific group" you are planning to alert against. You can use it for instance to query against an AD sAMAccountName and have it return their email, phone number, etc. Same principal applies to other AD stuff.
The steps for doing this are to setup Custom Types that you'd index (so you can return additional info in the ESM Custom Type tab) which equates to the field you'd see on the Custom Type tab in ESM Events. Basically you'd setup to be a string if you are looking to see a group.
Then setup a Data Enrichment LDAP query that looks for users in that group of interest and decide what fields to match and populate.
Then test it so when the log comes up with a custom type (Mail Admin Group User) that shows Yes, you can have it shoot an alert.
Thanks for the information. The event is being logged and I built my rule based on that data. Even though it does not pull event from AD in real time, but thats a different issue. I have included a screen shot of my rule. I have tried to put all the parameters on one line as well as having them on their own line as pictured.
I guess I am missing something in the rule logic. I am still new to writing rules in ESM.
Windows will never be real time. Basically, the receiver will query Windows datasource every minute which isn't configurable to my knowledge. The only thing with an option close to realtime will be something syslogging or pushing to SIEM vs getting pulled.
On the correlation rule, there are other screenshots that would need to be seen to totally put the pieces together on whether it's setup wrong. Can you show the main correlation screenshot and any other areas that may've had configurations? Perhaps do a show rule as well to see the aggregation settings for the SigID?
If you are seeing in ESM that the SigID # above is populating the ObjectID field with Proxy_Streaming_Media and displaying a success subtype when you are attempting to test it, you are at least on the right track knowing what to correlate on. The obvious next step yeah is getting the correlation setup right.
Sometimes scratching what you had and start baby-stepping through the rule to see how it works at each step helps. Watch it work with just a SigID first, then maybe chane to add subtype, etc.
In the ESM, when I filter on that sigID#, the object in the event is actually proxy steaming media, without the underscores. In my correlation rule, ObjectID actually references a variable called Proxy_Steaming_Media. Are these values case sensitive ? The value of the varialble is Proxy Streaming media (type string). Is there a preferred method with regards to object, variable, or watchlist ? Thanks.....
Do you know which 'Event Subtype' we should put for 'locked account' ?
I am not sure why you would want to filter off of Event Subtype for a windows account lockout. It would only tell you success, as in the user successfully locked their account...
Event ID for locked account is 43-263047400
I think(if I'm not totally wrong) that when a user is added to a group, the CN name is logged and not the User ID. This makes it harder for the correlation part since when a user is locked out it's the User ID and not the CN that is logged. Please correct me if I'm wrong.