The Security and Audit solution in OMS provides some incredible information including account authentications, logon failures, event log cleanings, suspicious executables and more. These counters also provide trend information (see the accounts authenticated example below where the value is 19 and the trend is downward 4). This solution allows you to dig into all of the security log data which has been collected to provide very granular information and to provide queries which report on conditions such as failed logons. For more details see Microsoft’s online documentation at: https://technet.microsoft.com/en-us/library/mt484109.aspx.
While the Security and Audit solution provides excellent information it also has to gather a whole lot of data to make that happen (if you want to see how much data is out there, open up your security event log files on a domain controller for an example of how much data). One of the approaches to limit the amount of data which is being collected is to target the solution to only the systems which you want to collect the data from. By default OMS collects this data from every system which you enable the OMS functionality on once the Security and Audit solution is in place. I discussed this approach in the blog post: Targeting OMS solutions to specific systems in Operations Manager. This works well if what you need to do is to simply restrict systems from sending data into OMS for the Security and Audit solution while leaving other systems still reporting data.
One of my lab systems runs on the free tier for OMS (if you haven’t seen that there is a free tier of OMS, please stop reading now and go and create a workspace to try this at https://www.microsoft.com/en-us/server-cloud/operations-management-suite/trial.aspx). The OMS trial gives you up to 500 MB per day with a seven day retention for Log analytics (including the Security and Audit solution discussed above), plus 500 minutes of IT automation per month, plus virtual machine DR for the first 31 days.
My free tier lab example went beyond its 500 MB per day limits recently as shown in the two figures below.
Once the 500 MB limit is reached, data processing no longer occurs and indexing does not occur. This is extremely relevant as we need this data for a variety of reasons including for examples of server monitoring which I have been discussing in recently blog post series at:
This can of course be resolved by changing from the free tier to a paid tier by changing your tier using the button in the top right comer shown below.
Determining what is causing the most usage within the Solutions in OMS:
However, for my lab environment I wanted to dig in and see what was really using my 500 MB per day of data. To check on this I started from the graphic below (usage per Solution available in the bottom left corner of the OMS UI).
Drilling into this tile provides the daily usage, usage per solution and service-level agreement information. Within my lab environment it is easy to see that the top users of data are the security solution and the wiredata solution (with security representing 87% of the data collected in my environment).
Using the Log Search functionality we can use a query like this to see all security data which is being gathered:
This shows us how many security events are gathered and more importantly in my example it shows the most common account which was generating the most data.
In the example above we can see that the SQL account is driving more security data to be collected than all of the other top accounts listed. In my lab environment this is a service account which is used to run an application.
Using Operations Manager to filter what security data is provided to OMS:
Please note: The idea of removing a specific account from gathering audit data is most likely NOT a good idea in a production environment. This example is just to show how you can keep a lab environment under your usage thresholds and to show how similar approaches could be leveraged to more effectively target what security data you do and do not want collected by OMS. A more complex example (which I will likely blog on later) would be to choose to gather only specific security event ID’s based upon your auditing requirements.
Microsoft provided a great blog post on how to do much more granular targeting for security information gathered by OMS if you are in an Operations Manager integrated environment (thank you to Daniele Muscetta!). Their blog post is available at: http://blogs.technet.com/b/momteam/archive/2014/08/27/anatomy-of-an-event-collection-rule-for-advisor-preview-advanced-targeting.aspx. Please see their blog post for the sample management pack which I used in this blog, and for details on how security information is gathered via OMS.
For my example, the goal was to not send any security information from the account identified above (!SQL). To do so, I used the new rule types which were created in the Microsoft blog post.
And I had it exclude any security events which included the account name shown below. (Please note, I do know it is not recommended to match on string content on the EventDescription field for a rule. This was just a simple example. For details on how to better target this see Kevin’s article at http://blogs.technet.com/b/kevinholman/archive/2008/04/22/using-event-description-as-criteria-for-a-rule.aspx).
The next step was to stop the original collection rule from continuing to collect all security information. To do this I set the enabled flag to false as an override on the existing “Collect Security Events” rule.
Finally, I enabled the new rule which I created called creatively enough “Collect everything other than !SQL items”.
To test if this is working, I waited until the next morning and ran a query to see if any information was being gathered by the account in question (!SQL) in the last hour. An example query is shown below:
Type=SecurityEvent Computer=”AllInOneOMTP3.CloudAzure.pvt” (Account=”<domain\account>”) AND TimeGenerated>NOW-1HOUR
No records were returned which was a good sign. The next step was to query and see if event logs entries were still being gathered outside of this account. A query like the following can check that:
Type=SecurityEvent AND TimeGenerated>NOW-1HOUR
The graphic below shows the updated usage for my environment once security collection for this account was no longer occurring.
Summary: Your knowledge of Operations Manager can be extremely helpful in changing the behavior of how OMS works. This example shows how the removal of some specific security information can greatly decrease the amount of data which is being collected by a solution. For more details on how you can use your Operations Manager skills in OMS, check out my upcoming session at MMS 2016: “Using your OM skills to hack OMS”