Jim/Kevin: Thank you very much for the input. I backed out the MP as a just in
case measure.
The goal is to know when a user is added/removed from particularly sensitive AD
groups within our domain. I know many places leverage syslog or SIEM
capabilities. We do not currently have either so I thought I could leverage the
investment we've already made into SCOM, but I can clearly see I was going
about executing this very poorly.
Based on your example, I imagine the logic flow to be the agent ignores
non-matching EventIDs first (which filters out the majority of events
immediately). If an EventID matches it would then process Paramater 3 by making
the call to AD and ignore/alert based on that evaluation. While that's
obviously better than calling against every event, I can understand why that is
still far from ideal.
In this instance, would it be better to use a Rule to run PowerShell script
based on a time interval? For a crude example using 5mins, something like this:
$Time = (Get-Date).AddMinutes(-5)
$Events = Get-WinEvent -FilterHashtable @{ LogName = "Security"; ID = 4728;
StartTime = $Time}
Otherwise do people just not use SCOM for such use cases? I don't want to fall
victim to the "when you only have a hammer..." trap. So if SCOM is just
ill-suited, I will look at alternatives. I appreciate any opinions on the
above...and for saving me from a potential headache.
-Geoff
From: [email protected] [mailto:[email protected]] On
Behalf Of Kevin Holman
Sent: Wednesday, July 27, 2016 12:28 PM
To: [email protected]
Subject: [msmom] RE: Event Detection Help:
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]>
[mailto:[email protected]] On Behalf Of Orlebeck, Geoffrey
Sent: Wednesday, July 27, 2016 1:42 PM
To: '[email protected]'
<[email protected]<mailto:[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://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253a-252f-252fmsdn.microsoft.com-252fen-2Dus-252flibrary-252fee533928.aspx-26data-3D01-257c01-257ckevin.holman-2540microsoft.com-257c10e7333742ce4a4cf13308d3b64e95c0-257c72f988bf86f141af91ab2d7cd011db47-257c1-26sdata-3Dvc9UjU9NvScVI5ZmgtWUiTJlJX-252bHucG1q-252bxJNZpHB4o-253d&d=CwMFAg&c=GtV7VYka8XzFJya76SH24R7OU_QKFTyBlklHoDMCjFY&r=WF1NZuUqAd1bRIxLFT_0wz8npqTRKjPr3_qzGO_dTx_Q3Taym2JWM42n-cKyG-6W&m=ASMa0kReDbusQXG5vvbSn_rajc5CR1y6LpoxBuPnsVs&s=56Gey1UN28QPryOaDNirVknZZvebEuS0JrfnL3t8woE&e=>).
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.
