Integrating Tanium and SCCM: Client Health

In my role at Tanium, I’m frequently confronted with complex IT environments. Every client situation is truly unique; however, one of the amazing things about Tanium is how well it adapts and actually thrives in chaotic enterprise networks. One aspect of this type of complexity is in the diversity of existing security and management solutions deployed.

Although Tanium ultimately can help reduce the number of siloed solutions, many products are integral to people and existing processes or simply cover use cases that Tanium doesn’t. Even when considering Tanium as a security and management platform, IT leaders must still ask themselves, “how can I maximize my current system capabilities while still reducing my FTE count and TCO?” Fortunately, Tanium not only co-exists with many existing solutions but can actually complement and make them more effective.

One such solution is Microsoft’s System Center Configuration Manager (SCCM), currently used by a number of Tanium customers. I have a unique perspective at Tanium after nearly 15 years in operations, integration and consulting roles utilizing SCCM. Though some may attempt to compare SCCM and Tanium, it’s not apples to apples. There are things that Tanium exhibits advantages in that SCCM does not and vice versa. In the case of SCCM, the integrations with Tanium actually enhance the experience: reducing the attack surface, hunting real-time threats and reducing expense through greater awareness of unknown and potentially vulnerable applications.

When Change Management Processes Fall Short

Today, we’ll focus on systems without healthy communications to a management point. There can be many reasons for this, but I’ll address a people and process problem here. In my experience, SCCM environments frequently have somewhere between 5 – 20% of non-existent or failing clients – countless organizations have systems that have already “gone missing” as soon as 6 months or a year after initial deployment. How many times have you been troubleshooting a deployment, patch or otherwise, to find that thanks to a network change, you have a new subnet that has no boundaries in SCCM, but plenty of clients? (This is by no means a knock on network engineers, but by the nature of the business, change management isn’t always properly communicated.) I’m sure it’s happened to every SCCM admin who’s been at the wheel long enough. And for those who haven’t seen this, hopefully, a light bulb just went off in your brain and you’re hustling off to fix that nagging client communication problem at a certain location. I’ll still be here when you get back.

This problem is inevitable, especially at larger scales. Even when change management processes are followed appropriately, the level of transparency begins to create obfuscation due to the noise, and things will be missed (especially a standard change such as bringing up a new subnet). Irrespective of the cause, this results in losing chunks of your SCCM clients in an instant. Unfortunately, there’s no built-in notification in SCCM, so being proactive in managing this risk is challenging – practically impossible – and the inherent risk of discovering it during a massive deployment increases exponentially.

Here is where Tanium comes in. In a matter of seconds, you can type the following question and immediately know which subnets are not being properly managed by SCCM:**

Get Tanium Client Subnet from all machines with SCCM Client Communication Days Old > 1

This immediately gives you a count of all systems in each subnet that have not communicated with SCCM in more than a day. Then it only takes a matter of minutes to fix by adding the proper boundaries and/or boundary groups into SCCM and defining sites/distribution points. Even if you don’t think you have this issue, try it out and ask the question below in your Tanium console. You’ll be surprised at what you find and what you can easily fix.

If there is a high number in a given subnet, there’s a good chance that subnet is not defined in SCCM. By default, SCCM clients should perform a policy check every 60 minutes, so if they haven’t communicated in over a day, something is wrong. Because Tanium is looking at clients that are online now, the results are not muddied by stale records from offline systems. A simple PowerShell script (using the SCCM 2012 PowerShell cmdlets) could take those subnets found in Tanium and compare against those subnets in boundary groups within SCCM, and you have your missing ranges.

Another possible approach to the same problem would be to ask the following question in Tanium to get the count of all clients in each subnet:

Get Tanium Client Subnet from all machines

If the endpoint count for a subnet in the first question matches that of the count in the second question, you’ve found an unmanaged boundary in SCCM, because it means that every online client in that subnet is not communicating with SCCM. Again, it’s a matter of minutes to fix in the SCCM console once identified using Tanium.

Add these two questions to a dashboard or even add a saved question with an associated alert via Tanium Connect to notify you if such a boundary is found, and you’ve quickly closed the loop on a big area of concern when it comes to SCCM client coverage.

Why is this important? Because SCCM is a common tool used by organizations for software and update delivery. If you lose a few hundred or a few thousand endpoints, then those assets will not be inventoried or managed. The effect here is that assets go unpatched and support calls are placed for missing requested software installs generating hours of work for such a simple root cause. The bad guys aren’t waiting for you to notice the gap in your environment, so why should you? By implementing this simple use case into practice you’ll reduce risk, man hours and help maintain a better user experience, all while keeping that fireman’s hat in the drawer a little longer.

About the Author: Greg Thomas brings broad expertise to his role as Director, Technical Account Management at Tanium, including scripting, process automation, Active Directory and SCCM design/administration/maintenance. Prior to Tanium, Greg designed, implemented, and supported technical solutions in public and private sectors as a consulting engineer.