Saturday, September 5, 2015

Malware Flagging and Reporting - SCCM, SCOM, SCSM, and SCO (part 1)

2:47 PM Posted by A , No comments
Yeah. Buckle up.

Alright. So I had this idea and given how much all of the System Center components rely on one another it stood to reason I could execute this idea of mine relatively simply. OH HOW WRONG WAS I!

Scenario: Configuration Manager (SCCM) does malware reporting/alerting (sort of). If you've configured alerting in SCCM, it sends out an email from spoofed/fake email address out to select parties you've determined. But, you also leverage Service Manager and...
  1. Really would rather have malware get flagged as an Incident and assigned out to someone to investigate or
  2. You want it in SCSM so you can continue to develop and consume all of your reporting from a single point or
  3. You want an Incident as it relates to a Configuration Item or
  4. You want to open Incident on behalf of the Primary User of the PC
All of those things are valid reasons I think you'd want to start piping this through SCSM. So I thought to myself...

"Well. This sounds easy. I'll just get the SCCM management pack for SCOM, hook 'em up, forward alerts from SCOM into SCSM. Done."

Here's the problem though. SCCM has this rule (and the following example applies to all of them) called "Malware detection alert: Malware found." and in SCCM it monitors a collection, and the SCCM alert contains the PC and malware type. When you get SCOM hooked up to monitor this alert, when the alert forwards from SCCM to SCOM. The SCOM alert description says "Please see the Configuration Manager console for more details." Which means when this gets forwarded to SCSM the Incident description says "Please see the Configuration Manager console for more details." And what's worse? Their is only ONE Affected CI in the SCSM Incident and it's your SCCM server(s).

So I'd say this is less than ideal. Because now all I've done is add unnecessary process and if anything require someone to do more work. I want ALL THE THINGS in Service Manager! Here's the harder news to digest - this isn't an accident. SCCM designed the management pack like this. So if anything it's probably a feature request that I hope this blog post drives them to implement. Alright. That's probably wishful thinking on my part.

I THINK NOT!
So before you simply give up and move on. What about this idea...

SCCM forwards alerts to SCOM. SCOM forwards the Alert into SCSM. The SCSM Incident template for this contains a SCO runbook that executes a SQL query against SCCM. The result set is the machines infected. The runbook converts the Incident to a Parent and creates Child Incidents for each infected computer.

And that's exactly what I did. No time to waste. Let's build it.


Configure SCCM to forward Malware Alerts to SCOM
If you haven't already done so. You'll need to get the SCCM management pack for SCOM installed. Then you'll need to get it configured to correctly poll these alerts.
  1. Obviously - import the management pack into SCOM
  2. Make sure you have SCOM agents deployed to SCCM server(s)
  3. Most importantly - Make sure you have enabled Agent Proxy under the Security tab on each managed SCCM server.
    1. Basically, you are saying the agents can act as a proxy (or if you prefer a "front") to SCCM managed devices. It allows SCOM to see through SCCM to it's "managed things".
Once you've done that, you may have to let SCOM/SCCM bake awhile before you start seeing the SCCM alerts show up as Not Monitored alerts inside of the SCOM view "Alerts from Configuration Manager". Once they appear though, you may wonder...

"So why aren't they monitored? They are all green. What gives?"

The reason they aren't monitored is because the SCCM management pack by default has almost everything disabled by default.

"That's lame. Why would they do that?"

Think of it this way. If it was all on by default, SCOM would vomit everywhere. If this is the first management pack you've experienced where everything is off by default your reaction may now be...

"Oh. Well. Yeah. That does make more sense."

 So how do we start monitoring these things?

Configure SCOM to listen to SCCM
Quite simple. Create an override!

1. Right click on the SCCM alert you want SCOM to monitor
2. Navigate to Open, and then Health Explorer for Alert You Selected
3. Now (left) click on "Entity Health - Malware outbreak alert..."
4. Now click Overrides
5. Select "Override the Monitor"
6. Select "For a Specific Class of the Object: ConfigMgr Alert: Malware Alert"

You should now seen your collections you monitoring in SCCM. Select the collection you want SCOM to poll from SCCM.

Finally you are placed on the Override screen...


Here you can see the Default Value for Enabled is False and we are setting the Override value to True.

If you haven't done so already in your initial setup of the SCCM management pack, now would be a good time to create a SCOM management pack to store all of your SCCM modifications. Once you've done that, save this override in your new Unsealed SCCM Management Pack for SCOM.

Repeat this process of enabling rules and saving them to your Unsealed SCCM Management Pack for SCOM for as many things as you want SCOM to monitor from SCCM.


Create a SCOM group for your SCCM Alerts
Next, let's head into the Authoring section of SCOM. Select Groups and let's create a new group called "Configuration Manager Alerts" we'll save it of course in our recently created Unsealed SCCM Management Pack for SCOM. This way our overrides and groups are stored in the same place.

Now while you can get fancy with some Dynamic membership. I'm going to use Explicit Membership and grab my Malware Alerts. Just go to Add and under the default scope of "Object" just type Malware and search.


Then just go ahead and add the rules you want (and more importantly overrode to Enabled True).


Add a new Rule to your SCOM/SCSM Subscription
Now you can open up your SCOM subscriptions and open up your SCSM connector/forwarder.
  1. Create a new Subscription
  2. Unselect all Groups and then select the one we just created - Configuration Manager Alerts
  3. Leave "Forward alerts from all targets automatically..." the default option selected.
  4. Hit Next
  5. Leave the default SCOM criteria selected
  6. Done
Now, since this is just the initial walkthrough it goes without saying (and I'm typing so that works) that you can always go back, modify, and tweak these rules beyond belief. For the purposes of this walkthrough I'm just keeping things simple.


Create the SCSM Incident Template
Next let's move into Service Manager to create an Incident template so that when our Alert gets forwarded from SCOM into SCSM we can consistently apply the same Incident. More importantly, when we go to start building reporting we have a consistent shape to our data.

1. Head into Library
2. Go to Templates
3. Create a new Incident template
4. Store the template in...well...either a management pack you already have and are keeping all of your Incident templates in or create a new Management Pack to store it in. Anyone versed in SCSM will appreciate the thought that goes into grouping your Templates into properly defined management packs. So Step 4 here is a bit open ended since everyone's SCSM environment/administration is always just a little bit different.

This new Template we'll want to assign a few things out of the gate
1. Impact
2. Urgency
3. Classification
4. Support Group and/or Assigned To - because after all that's kind of the point of this entire post of mine!

Save it. You're done in SCSM...for now.



In the next post (available here) we'll go over the crux of this entire thing...
  1. Creating the Orchestrator Runbook that converts the Incident to a Parent Incident.
  2. Queries your SCCM database for Malware Infected computers
  3. Creates Child Incidents that get attached to the Parent
  4. Adds the SCCM context to each child incident such as Affected CI, malware type, severity, etc.
  5. Define the Primary User of the Computer as the Affected User of the respective Child Incident



System Center Icons obtained from System Central Central. Here's the direct link.

0 comments:

Post a Comment