Rumba and cyber security, best practices for updates.

Welcome to the 3rd Rumba blog, this week talking about updates (or patches). I’m also going to take a slightly different approach this week, thinking that I may have accidently been a bit preachy (and long) last week. I’m going to discuss why patching is important, and at the same time, so difficult, along with some strategies for how to do it well.

How much and how fast

I will be the first to say that keeping all our software up to date by installing vendor patches is crucial. Often, it’s the very cornerstone of our defences, whatever firewalls, antimalware platforms, or other tools we have are less effective if we are still vulnerable to known software defects. So… we should just patch everything we have as fast as possible, right? Well, yes… and no, probably best described as “yes but”.

There are simply a staggering number of vulnerabilities that must be considered. According to data from cvedetails.com, in the last 5 years the total annual number of published vulnerabilities has increased by 68% with almost 30,000 vulnerabilities published last year.

With the best will in the world, in most organisations it is not possible to patch everything immediately, and the steps required to deploy a patch will vary depending on the governance requirements of our organisation. Even after we find out about a new patch being available, we must consider testing, change control, and deployment and rollback plans. Like all things in cyber, we need a plan, and we need a process (Rumba anyone?). As we cannot just patch everything, we must know what to patch first.

We need to know what we’ve got… before they do.

To implement Rumba, we learn our first STEPS.

Search – We need to know what we’ve got on our network as we can’t patch it if we don’t know it’s there. As an organisations network evolves and changes over the years, it can be easy to lose track of things. Network scanning is built into some antimalware and EDR platforms. In addition, we have excellent commercial tools from vendors such as Qualys, Rapid7 and Tenable to scan our network. Not to mention, free tooling like Angry IP Scanner and Nmap. Use these tools to build a picture of your network and know what’s there. I will refer to each item found as an asset.

Test – Once we have our list of assets, we need to scan them for vulnerabilities. There are a wide variety of vulnerability scanners available, OWASP maintain a list of scanners here. Scanners can be installed locally and for internet facing services like websites, they can be run online.

Establish – Now we need to prioritise, we all have limited resources and budgets, so we need to prioritise what we do first. It would be great to be able to patch everything all at once, but as we normally can’t, our priority is on protecting our companies most valuable assets first. Although this varies widely, the Rumba principal is to follow an attacker mindset, this means our first Rumba Step is a SLOW one.

1.       Services accessible to the internet

2.       Login & identity systems

3.       Operating systems

4.       Work apps

We begin with patching the attackers way in, that’s anything directly accessible to the internet (firewalls, VPN appliances, web servers, anything exposing an API). Next, we focus on our identity systems (Active Directory domain controllers, certificate servers, PAM systems). Then we focus on Operating Systems and finally Work Applications.

Process – The final part of STEP is process, this includes required governance activities like testing, change control and deployment planning, along with the deployment and monitoring, to know that the patch has been successfully deployed.

This makes time your greatest enemy.

In Top Gun Maverick, while planning the attack, Tom Cruise says to his fellow pilots “Time is your greatest enemy”. OK, I’m paraphrasing slightly, but while we’re not flying F-18’s, the same is true for us. Once a patch is publicly announced, especially if the vulnerability being fixed is something directly accessible to the internet, i.e. Citrix Bleed, Exchange Hafnium or a VPN vulnerability, then malicious actors will begin scanning the internet for exposed systems almost immediately.  It’s a race against time, us patching against their scanning. This is also true for patch Tuesday. For the uninitiated amongst us, this is the 2nd Tuesday of each month when Microsoft release patches (there is a reason the next day is known as exploit Wednesday).

We need to ensure that our governance processes, must ensure a regular monthly process of testing, deploying, and verifying patches, for standards like UK Cyber Essential Plus, those critical patches must be deployed within 14 days. They must also be flexible enough to allow rapid testing and emergency patching, sometimes the risk of exposure of the vulnerability necessitates an emergency response.

When it comes to the actual deployment, we want to automate as much as possible.

For mobile devices, we can use our MDM Platforms like Microsoft Intune or Samsung Knox to trigger iOS or Android updates. We can use a mobile Threat Management Platform like Microsoft Defender, Jamf or Lookout to monitor mobile devices to ensure they are patched.

For laptops we can use systems like Windows Autopatch, and management platforms like Microsoft Intune, Jamf, or Kandji to trigger OS updates. We also need to ensure that anyone using a personal laptop is configured for automatic updates.

For servers running Windows, we can use vendor tools such as Microsoft SCCM or WSUS, and for those running Linux we can configure automatic updates.

In addition to all the above, we have commercial patch management systems like Ivanti, Qualys, and NinjaOne. This is the recommended approach. It is crucial that we do not forget to patch infrastructure such as VPN Gateways (Citrix Bleed!), Firewalls, Web Servers (in 2017 Equifax was breached through a vulnerability in Apache Struts). This is the main way that attackers will get in.

For endpoints, I personally prefer a tool which combines the vulnerability scanning and patch deployment together as I think it’s more seamless.

The two key takeaways for Updates are coverage and speed, knowing what we have on our network and avoiding the nightmare of missing critical patches on unknown technology, and ensuring that we can both deploy patches on a regular basis, but also very rapidly if needed. This may mean having pre-agreed processes for emergency maintenance windows and downtime.

Coming up next week, monitor, making sure someone is always watching.

I believe in our cyber security community and that by sharing and helping each other that we can all be safer. So, everything above is just my opinion, what’s yours? Please share in the comments below and stay safe.