You need to be VERY careful when doing this. We don't have *ANY* rules or monitors which examine the Security Event log in any Microsoft MP for a *good* reason.
If your datasource is not written correctly - you can pretty much take a Domain Controller to its knees. The reason being - is that "param 3" is probably not even text in reality. If it references an AD artifact (OU, Group, Account, etc...) then in reality it is a GUID. What event viewer does - is make an LSASS call to AD to resolve the unique guid into human readable text (the display name of your group in AD). If you aren't careful - you will have SCOM inspect EVERY SINGLE event in the security event log for a param 3, and try to resolve the name of whatever is in there. I have seen customers take their domain controllers to 100% CPU from LSASS.exe process when they do this. The way to keep this from happening is to make sure "first failure" in effect, and for that to be SIMPLE. Don't use multiple AND/OR statements. This can cause the order to be processed differently. For this reason, I recommend having super simple criteria for rules against the security event log. In your case, I'd make a different rule for each event ID, and param 3. Why even include Event Source? Every single event in the Security event log already has the same source, doesn't it? If it isn't part of the equation - get rid of it! So your rules would be: Event ID = 1 Param3 = TestGroup [cid:[email protected]] And then repeat for each additional event ID in a separate rule. If you don't mind taking a risk and doing some testing - you can match on a regex [cid:[email protected]] You can also do something similar in the console - but I strongly recommend against it for security events: [cid:[email protected]] Because the "param3" is now FIRST in the list, and this is where I have seen the heartache. From: [email protected] [mailto:[email protected]] On Behalf Of Orlebeck, Geoffrey Sent: Wednesday, July 27, 2016 1:42 PM To: '[email protected]' <[email protected]> Subject: [msmom] Event Detection Help: I am attempting this for the first time and I'm not sure the best approach: I am writing a rule to alert based on EventSource and Parameter 3 and multiple Event IDs. The part that I'm stumbling on is using AND/OR logic if EventSource and Params/Param[3] are an AND statement while EventID is an 'or' statement within the 'and' expression. The formula would look like this: * ( ( Event Source Equals Microsoft-Windows-Security-Auditing ) AND ( Parameter 3 Equals TestGroup ) AND (( Event ID Equals 1 ) OR ( Event ID Equals 2 ) OR ( Event ID Equals 3 ) )) EventSource and Parameter 3 will always be static, but I want to alert whether the EventID is 1, 2, or 3. When I create a Rule within the SCOM console, it doesn't look like I can do a grouped OR expression within an AND expression. Please correct me if I'm wrong. The other way I thought of accomplishing this is via VSAE defining multiple data sources (one for each Event ID). However, once I filled them out it complained about not have condition detection. I have never worked with Condition Detection, so I referenced this link (https://msdn.microsoft.com/en-us/library/ee533928.aspx<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fmsdn.microsoft.com%2fen-us%2flibrary%2fee533928.aspx&data=01%7c01%7ckevin.holman%40microsoft.com%7c10e7333742ce4a4cf13308d3b64e95c0%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=vc9UjU9NvScVI5ZmgtWUiTJlJX%2bHucG1q%2bxJNZpHB4o%3d>). It now makes sense why a condition detection is needed with multiple data sources. The issue I'm up against is not knowing which Module Type I need for the condition detection. How do you know which one is appropriate? Is MSDN the only resource or are there others out there? I've been looking for examples online but the only examples I find do not match the AND/OR logic above. Are either of these approaches the preferred method? Or is there a better way I am not aware of? Any help is appreciated. Thank you. -Geoff Confidentiality Notice: This is a transmission from Community Hospital of the Monterey Peninsula. This message and any attached documents may be confidential and contain information protected by state and federal medical privacy statutes. They are intended only for the use of the addressee. If you are not the intended recipient, any disclosure, copying, or distribution of this information is strictly prohibited. If you received this transmission in error, please accept our apologies and notify the sender. Thank you.
