Filter Which Security Events SCOM Sends To OMS
We recently enabled the Security and Audit solution for a customer in OMS – and in one day had 18GB of data uploaded. While the solution is very valuable, the price tag for storage was going to be a little high. However, the solution by default simply uploads EVERY event from the monitored servers’ Security log – and we don’t need all that data! The following is an example of how to edit what information gets uploaded to OMS.
I’m following up on the work done by Cameron Fuller presented here: An Example of How to Filter What Security Data Goes To OMS . In his example he used the Write Action that sent data up through the SCOM Management Server – but because of the volume of data the Security log can produce, OMS uses a separate Write Action called the High Volume Direct Channel Cloud Event Collection Write Action. This allows the agent to bundle and send the event data direct to OMS instead of sending it through the management server. This is by default the way OMS already gathers all Security events.
First – we want to disable the existing rules that collect ALL the Security events – In SCOM we load the Rules tab, scope objects to Windows Computer, and look for the rule Collect Security Events.
Notice that there are TWO rules with this label. If we dive into each rule to examine their configuration, we find that the rule from the Threat Event Collection management pack is already filtered to specific set of event IDs – we’ll leave that one alone for now. We need to disable the one from the Security Event Collection management pack – this one collects EVERY event from the security log.
Next, we create a new Event Collection Rule. The setup matches the rule we just disabled – target at Windows Computer, disabled by default. Under the criteria, we target the Security log and include the event IDs we want to collect.
I have a handy little cheat sheet with common event IDs – I simply included all of the relevant ones to my regular expression – here is the list of IDs I included in this rule:
|Built-In Administrator Changes||632|633|636|637|
|Password Change Attempts||627|628|4723|4724|
|User Accounts Created or Deleted||624|630|4720|4726|
|Audit Log Failure||516|4612|
|Audit Log Clear||517|1102|
After creating the rule, we examine it’s properties – under Configuration we find the common event collection responses –
Normally we don’t even pay attention to these – it’s what SCOM does with the data behind the scenes. We want to CHANGE what we are doing with the data – but if we choose ADD here we only have two options, and neither are what we want to do. We could load this rule in a tool that allows us more flexibility in authoring, or export the management pack and edit the XML (which I did, and it worked!) – but there’s something even easier.
First – download the management pack found here: SCOM Team Blog – This management pack creates two templates that are added to your SCOM console. Now you can create the above rule, but include the write-action that will send the alert to OMS via the high-volume channel.
We can choose the rule type that says “choose ‘Security’ log with this”, and create the same rule as described above. When we look at the properties of this rule, we now see the new write-action.
Our final step – override the rule to on for the group “Microsoft System Center Advisor Monitoring Server Group”.
We see a remarkable difference in the volume of data collected – in our customer environment we went from 18GB to 1GB. Further filtering out the successful logon events got us down to 400MB, which even allows us to run this in the free tier!
Thanks for the idea to improve on Cameron Fuller’s original idea go out to Tao Yang – his advice set us down this path originally…