Introducing the Security Monitoring Management Pack for SCOM (updated May 2018)
Disclaimer: Due to changes in the MSFT corporate blogging policy, I’m moving all of my content to the following location. Please reference all future content from that location. Thanks.
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 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.
Comments
- Anonymous
May 17, 2017
I was considering performing the same/similar but focus on Sysmon and it's log only. Any feedback if that would be a worthwhile endeavor? I understand 'it depends', but thought I would comment.- Anonymous
May 17, 2017
That's something I've looked into as well, for the record, with hopes of gleaning something out of it that could be useful. Biggest issue I see is what is being collected with sysmon and how big that log is and how that affects the local agent.. Likewise, you would want to know what you're looking for. That's probably the hardest part. I don't see why it wouldn't be doable though.
- Anonymous
- Anonymous
February 20, 2019
Nathan,First of all, thank you creating this MPIt looks like that GPO Guid in alert is not correct for all the events.could you please suggest if i am missing something...