Introducing the Security Monitoring Management Pack for SCOM (updated May 2020)

For those of you who haven’t met me or visited my blog, I’ve worked in SCOM now for the better part of 5 years.  I’ve also done a lot of work in IT Security.  About a year and a half ago, I was able to attend a training class about the anatomy of a Cyber Attack. I had the privilege of listening to a number of Microsoft’s best Cyber Security engineers speak on the types of events that attackers generated that were going undetected.  It was an incredibly interesting presentation, and what I came away with was the simple fact that most hackers leave a trail of bread crumbs during the process of compromising an organization.  I’m not sure on the latest statistics, but at that time it was noted than attacker is in an organization on average for about 250 days before they are found.  What is more surprising is that they often are not the ones to discover it.  Organizations that prioritize security spend large amounts of money on big data tools like Splunk or OMS in conjunction with SCOM and Azure PowerBI, but these take an extensive time investment, training, and in some cases rare resources, and that’s before considering that you actually have to know what you’re looking for.

Enter this Management Pack.  Myself, Brad Watts, and Lynne Taggart have been quietly working on a management pack that will provide real time notifications to events that are worth investigation.  Many organizations have SCOM, and when it comes to reading logs, SCOM is a very good tool.  As I’ve demonstrated in this space, setting up rules to do this takes minutes.  I’ve spent a good chunk of the year working with our security professionals to determine what exactly to look for.  To be clear, this is not a foolproof management pack.  It is another defense in depth strategy that can help an organization to determine if they are breached, potentially catching the attacker before data loss occurs.  It will not catch every intrusion, so please do not assume that putting this in makes you secure.  It is 100% dependent on good alert management process, a subject that I have written extensively.  With that said, main goal in this design was to keep alert noise down to a minimum.  The hope is that very little of this will fire out of the box.  If this MP is generating alerts, they should be investigated.

As for use, do not simply wait for an email.  That strategy rarely works with SCOM monitoring.  Someone needs to be responsible for checking the views in this MP on a daily basis and responding to anything there.  It’s designed mostly with rules for the purpose of allowing a security team the ability to respond quickly.  Some normal business activities (such as adding a user to a local admin group) will get detected.  That is fine, as this should not happen often. The thought behind this though is that a security team member could contact and verify that this did in fact happen.

Finally, I want to note that I’m always interested in adding to this.  My criteria will be a bit different as my main goal is to make sure this isn’t noisy.  I don’t want to alert for the sake of alerting.  My goal is to track items that either rarely occur or should not occur in an environment.  But if you have an idea, please add it in the comments section, and if we need to communicate, reach out to your TAM, or you can reach out to me on LinkedIn.

You can find a public download here.

Related Articles:

Please use this space for public feature requests. Note you can hit me up on linked in as well.

You can find the May 2018 change log here.

You can find the May 2019 change log here.

You can find the May 2020 change log here.

You can find the summary information and all future changes here.

You can find the GPO information to this management pack here.

You can find a write up on Windows Event Forwarding here.

You can find a write up on noise here.

You can find a write up on post configuration tasks here.

You can find a write up on AppLocker information here.

You can find a real world example of how this detected an attack here.  I would also note, somewhat selfishly, that if by chance you have used this management pack and it has allowed you to get a better grip on securing your operations or even detecting an attack, please reach out to me on linked in.  Success stories are very valuable for keeping this project going, and they will remain confidential.

Last, I’d like to note that this is the first revision of this management pack, and that I would like to add more features to it over time. Additional reports is something I’d like to see in the shorter term, and ideas from users are always welcome.  Feel free to add comments or reach out to me on LinkedIn.

Special Thanks to all of these individuals who have contributed to this management pack in some capacity:

Lynne Taggart, Brad Watts, Kevin Holman, Henry Parks, Greg Cottingham, Kurt Falde, Jessica Payne, Cameron Fuller, Pete Zerger, Kevin Greene, Matthew Long, Bob Cornelissen, Dieter Wijckmans, Flemming Riis, and John Joyner.

7 thoughts on “Introducing the Security Monitoring Management Pack for SCOM (updated May 2020)

  1. Thanks for creating & sharing this MP. had a quick qst on the available Reports. Is there an easy way to add an extra filter for selecting the domain name for each of the Reports.By default I only see Start Date and End Date.


    • I would have to write that into the reports. Presumably that info is in the collected events, so I think it could be done. SCOM reporting is a what you see is what you get… good idea. If you have PowerBI desktop or something like that, you could try starting with that query and going from there.

      Liked by 1 person

  2. It seems like your MP detets GPO managed changes in the security settings.
    we have GPO’s that set the local admin groups, and they run, every 90 minutes or so, and this MP detects, proberly as it should be, but that generates alot of noise.
    How do we filter that out, so these GPO added users are not showing up in the alert window every time there is a GPO refresh.


    • That makes sense. You’re forcing local admin membership, so I wouldn’t be surprised at all if that alerted. If there’s something unique about a GPO based change, I could re-write the rule to account for that. Otherwise, you’ll probably want to turn that one off.


      • I will see if I can find anything unique about it and report back. I’m sure we arent the only ones setting local admins wirh GPO 🙂


      • I think, if we could just have some goup names in the override, for the rule to ignore, that would solve the issue, that way the monitor would just ignore say Domain admins, for the most part it would solve it, although our setup as different admin groups for different customers, in a shared domain. with group names like this

        It could be done, but we would need around 60 overrides, not optimal, unless a wildcard can be used 🙂
        I also think it would require less work on your part, although I really wouldnt know 🙂

        I will keep looking if there is some unique to GPO added local admins.


      • hit me up on linked in… I’m curious which rules in particular are generating alerts. I’m pretty sure a group name could be overridable… it would be depend on what is in the XML.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s