If you were an attacker, how would you look for vulnerabilities?
Would you work non-stop for weeks trying to hunt down something? Or would you resort to reading up on the latest patches and look for a way into something that sounds interesting—something already explained (and virtually done for you)?
When most patches are released to the public, nearly everything about a specific vulnerability or problem are disclosed. Those of us with the time and interest to probe a little probably can find why a patch was produced (here, I’m only referring to critical security patches).
10%.
That’s the amount of code on average that is produced by an in-house development team to software you or your clients are using. Nearly 21,000 known vulnerabilities were discovered from that 10% of code in the last 18 months.
Think about this for a minute. Ten-thousand security issues popping up from 10% of code.
18,000.
Another statistic I want you to think about: 18,000 hours. On average, it takes 18,000 hours and millions of dollars of work devoting to simply identifying, resolving and patching critical security issues.
What should this tell you? Without a strong patch management system that you are confident in, any effort you or your team are devoting to may be wasting you time and leaving you or your clients open to attack.
In 2019, over half of cyberattack victims acknowledged that applying a specific patch (and testing it) would have prevented the attack altogether (another 34% admitted to even knowing about the vulnerability on their network prior to the attack!).
The message I want to send home is how critical patching remains to network security. The faster you are able to apply the right patch to the right application and test that it’s working as expected, the more secure you will be.
So, what is the scope of patch management?
I like to break down patching into updating software, operating systems and applications on a specific asset. Your patch management system should bring visibility to issues on your systems, classify and prioritize missing patches on every asset in your environment (cloud or physical machines).
For the patches themselves, the software vendors typically have control over the specifics of an update. They control their own policy for what can be in a patch and how documentation communicates what a patch is doing.
When I was running my MSP, I had to get my team focused on process (and process improvement). We used the Deming Cycle to implement, evaluate and improve our processes. One of the first processes I had my proactive team look into was patch management.
Here are six ways we learned to smooth out our patch management process:
Keep an inventory of your systems—make sure you have a comprehensive list of all the software and hardware in your environment (and that of your clients). This will help you know what you will need to be looking for (defining your scope). This will make it so that you can compare known vulnerabilities to software on your inventory list to discover what matters to you.
Determine risk—determine (either from your software vendor or based on what the patch impacts) how to prioritize those vulnerabilities. While it’s probably a good idea to patch all systems, assigning risk level can help your team understand and implement patches that will be critical to your security. The more exposed a vulnerability leaves your network, the faster it should be patched.
Consolidate software versions—I know this might be a major headache, but conforming to supporting one version of a particular software makes your and your team’s life much easier (and reduces chances of error or problems with patch management). When I ran my MSP, I made a purpose to be consistent across our supported environments. In corner cases where software versioning could not be consistent, I made our client aware of the risk and put them on a special plan (with an associated cost) to maintain dated systems that were harder to support and guarantee.
Pay attention to patch announcements—keeping up with announcements is crucial. With your inventory of products, subscribe to all of those product’s security updates where patch announcements are made. Monitor each of these to a specific inbox that gets reviewed daily. Create a process to ensure that patch announcements don’t fall through the cracks!
Mitigate patch exceptions—sometimes you can’t patch right away because of dependencies from certain business applications. Make sure your patches work and acknowledge where they might not. In cases where a patch is not feasible for one reason or another, make sure to mitigate risk as much as possible. For instance, lock down permissions on a machine that could be vulnerable to a permissions escalation attack. And don’t leave servers that cannot be patched exposed to the internet. Reduce the likelihood of an exploit by modifying the network environment that equipment is in at the very least.
Test your patching before applying everywhere—I learned this lesson early on back when I helped patch environments. As you know, patches can cause problems or even bring down machines that are configured certain ways. Test your patch on a small subset of machines (or clients) before applying to everyone. Being quick to patch shouldn’t mean applying the same patch to everything at once!
Patch management needs to systematic.
If you are not following a process and improving on it every time you or your team encounter blips or issues with a specific patch application, you are creating more work and more risk. Creating a patch management process that syncs with the rest of your operations will be crucial to both growing your business and keeping everyone as secure as possible.
