A vendor-neutral framework for addressing the other 85% of vulnerabilities
by Duncan McAlynn, Cybersecurity Consultant
If your organization is like most, you likely have clearly defined processes in place for deploying newly released Microsoft security updates each month. If not, you should. We’ve only had 15 years to hone the process, dating back to when Bill Gates dropped the hammer following the massive “Melissa, I Love You” VBScript outbreak. The result of the worm was a halt to all new product development and an immediate review of existing code sets across all Microsoft products, as well as sending over 7,000 developers to security training.
In the following year, this Trustworthy Computing Initiative gave birth to what we have all come to know and love (or hate) as of Patch Tuesday. This cyclic schedule of software update releases on the second Tuesday of each month has allowed us to align our internal resources to assess applicability, test compatibility and deploy those updates in a structured manner, including obtaining any required change management board approvals.
In short, “We got this!”.
But, do we have a handle on it? Do you believe your company has a solid grasp on its patch management? Let’s look at the facts.
Per data obtained from cvedetails.com, no more than fifteen percent (15%) of all the known vulnerabilities reported over the past three-year period have affected the Microsoft platforms. By that I mean all Microsoft operating systems (both desktop and server versions), Office, Internet Explorer, Skype, Visual Studio, SQL Server, SharePoint, BizTalk, you name it. If it has had the software giant’s name associated with the vulnerable executable, it has only ranged between 8%-15% of all the reported vulnerabilities.
So, what about the other 85%? That is where all the third-party applications and non-Microsoft operating systems come into play. In most corporate environments, you’re going to have these applications like PDF readers, Internet browsers, Java-based applications, networking tools, graphics programs and the like. These software applications have update releases for new versions or security patches for existing versions. And, as the cloud becomes more and more a part of our daily lives, it becomes increasingly more important that we’re applying these third-party product updates in a timely and consistent manner to protect the attack surfaces that they are introducing because of the applications being connected to the Internet.
When I’m giving conference and user group presentations on this topic throughout the country, I tend to ask the audience “Why are you not being as diligent with patching your third-party products as you are your Microsoft updates each month?”, I hear the same reasons repeatedly. See if you can relate to them:
- “We don’t have the time”
- “We don’t have the resources”
- “We don’t have the right tools”
This is the recurring theme that I am constantly faced with and I completely understand where they are coming from. In a large-scale enterprise environment with global operations and tens of thousands of endpoints, just handling the Microsoft updates can be a vicious, never-ending cycle requiring at least one full headcount administrator to manage the pilot, user acceptance and production deployments. To illustrate this point, here is a typical approach such an organization might take for patching just Microsoft products each month:
Figure 1 – Patch Release Cycle
As you can see from the figure above, by the time one can get through the deployment cycle of a month’s batch of updates, the next months’ worth is already upon them. It’s a relentless onslaught and quite often a thankless task for the poor soul that is charged with it.
So, what is the solution for our poor SecOps engineer? An integrated solution that can help them with addressing the other 85% percent by utilizing the existing investments the organization has made in their patch management framework.
Today, most corporations worldwide are using Microsoft’s Windows Server Update Service component to be able to push out the products from Redmond. Windows Server Update Service (WSUS) is a capable solution but has its limitations. For SMBs, it’s a perfect fit – just synchronize it with WindowsUpdate.com, approve your updates and let it go. Through group policy, the endpoints receive their updates and report back their patch compliance status. Done!
Figure 2 – Windows Server Update Services
For larger, more complex corporate environments requiring more granularity of control, time of deployments, network utilization, and better reporting, WSUS can be integrated into their System Center Configuration Manager (SCCM) product to extend and enhance WSUS. It will use all the existing infrastructure investments in SCCM to improve the scalability of WSUS, provide much more control over to whom and when patches are deployed and much more comprehensive reporting capabilities.
But, back to the point of our poor SecOps guy tasked with also updating Java, Adobe Reader, Chrome, Notepad++ and the like, how is he to integrate these third-party updates into WSUS or SCCM? Thankfully, Microsoft has provided an entry-level solution accelerator named System Center Updates Publisher.
Figure 3 – System Center Updates Publisher
Despite its name, System Center Updates Publisher (SCUP), the product actually first synchronizes its catalogs from the third-party vendor’s website into WSUS, and through WSUS’ native functions, will then synchronize with SCCM. So, regardless of whether you have SCCM deployed or not, you’re able to use SCUP to integrate the following vendor update catalogs into your WSUS/SCCM environment(s):
- Adobe Acrobat 11
- Adobe Acrobat X
- Adobe Flash Player
- Adobe Reader 11
- Adobe Reader X
- Dell Business Client Updates
- Dell Server Updates
- Fujitsu Technology Solutions
- HP Client Updates
- Hewlett Packard Enterprise
Now as you may have already noticed, the list of available products is pretty slim. The reality is that Microsoft hasn’t really seen the independent software vendor (ISV) support that they had hoped to with SCUP. In fact, Adobe is the only ISV to get on board with it. The other three vendors are all hardware, providing firmware and driver updates.
So, how is one to go about fully addressing the problem at hand with the other 85%? That is a void Microsoft has intentionally left to the partner community to fill. Over the past several years a few key players have emerged to help organizations patch third-party applications by natively integrating into WSUS, SCCM or both.
What should an organization look for in a third-party patch management solution? The following table includes a list of items that I would include in any assessment or proof-of-value project for third-party patch management. I hope it will be of use to you during your evaluation process.
Table 1 – Patch Management Solution Selection Criteria
Have I missed something? Let me know. I love hearing from my readers. Otherwise, happy patching! And, patching… and patching!
About the Author
Duncan McAlynn is an award-winning InfoSec professional with 20yrs experience consulting Fortune 500s on enterprise management & security posturing. He is a published author, editor, industry columnist public presenter and has obtained a number of certifications and awards over his 20yr career, including MS-MVP, MCITP, MCSE, Security+ & the coveted CISSP.
McAlynn is also an active member in his local ISSA, ISACA & InfraGard chapters. His community project is helping small business owners work through the challenges of cybersecurity. And, most recently, he has successfully completed a comprehensive Harvard University Cybersecurity Risk Management program.
He can be reached on Twitter using @infosecwar or by secure email with SudoMail at [email protected]
