An example of how to filter what security data goes to OMS

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.

 

For details on how to determine what is causing the most usage in OMS and an example of how to filter what is collected see the full blog post available at: http://blogs.catapultsystems.com/cfuller/archive/2016/02/19/an-example-of-how-to-filter-what-security-data-goes-to-oms/

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.