Essential Eight Maturity Model: Patch Applications

By Information Assurance Specialist at Data^#3 Limited

On July 12, 2021, the Australian Cyber Security Centre (ACSC) updated the Essential Eight Strategies to keep pace with the current threat landscape. The new model is more cohesive, thorough and addresses many key omissions from previous versions. As further proof that stagnation equals vulnerability, I am delighted with the changes, and I think you will find tremendous value in implementing the Essential Eight in your organisation.

We were inevitably following a path of mandatory implementation of the Essential Eight, especially if you conduct business with the government, particularly at the federal level in Australia. Many organisations, private enterprise and public sector, have undertaken programs to at least assess their maturity and, to some extent, implement the controls outlined within each strategy.

Please take some time to read all of my articles on the updated Essential Eight Maturity Model; the links are at the bottom of this article.

In a previous article, I wrote about the maturity model in the context of Application Control.

In this article, I look at the updated Essential Eight Maturity Model regarding one of the more critical (and often overlooked) strategies: patching the applications your business relies on to operate.

Let’s get to it, shall we?

Patch Applications

Where should you start?

Depending on your approach, you should have an accurate and current inventory of applications and their dependencies within your organisations, and a database of the same is critical. This way, you can quickly verify versions, support, compatibility, and maintenance requirements since not all applications are maintained the same. Some are updated several times a week, while others receive updates quarterly or less in line with major or minor updates.

If I may, I suggest avoiding updating to the latest versions simply because they exist unless they are the latest stable releases. Stable is the word here because I often see updates made available that cause more problems than they solve, so why do the job of a cybercriminal for them? In any case, a good starting point after ascertaining the accuracy of your inventory is reviewing the processes and tools used to keep your systems up to snuff.

The current version of the Essential Eight Maturity Model also promotes achieving a consistent level of maturity across all strategies (i.e. all at level 1) before moving towards higher maturity levels. This promotion is due to the more integrated nature of the controls that compose the strategies. It also shows how achieving the objectives and dependencies of the lower levels expedites achieving those at the higher levels. Besides, neglecting one at the expense of another was a recipe for disaster when we would cherry-pick strategies to focus on.

In one instance, I saw an organisation so hung up on achieving Maturity Level Three with Application Control that they neglected both Application Hardening and Application Patching (also Essential Eight strategies) and ended up the victims of a data breach. So, that said, let’s look at keeping your applications up-to-date and (mostly) free of holes.

As I do with my other articles, I skip Maturity Level Zero because it implies you have done zero towards patching applications. While you may not currently stand at a Maturity Level One, odds are you do at least some patching, perhaps ad hoc or sporadically, when the mood strikes. Or when you have nothing else to do (but how rare is that, right?)

Patch Applications: Maturity Level One

The previous Maturity Model only had two controls, but the current model advocates for a practical approach with more controls that integrate and are achievable with a reasonable amount of effort. I found previous Maturity Models vague, so it’s refreshing to see a more risk management-driven approach.

“Patches, updates or vendor mitigations for security vulnerabilities in internet-facing services are applied within two weeks of release, or within 48 hours if an exploit exists.”

The old approach allowed for “within one month”, but seriously, we’re talking about patching vulnerabilities here. Why leave the door open that long? These highlight “internet-facing” systems and generously gives you two whole weeks unless (and this is a big unless) an exploit exists. I don’t know about you, but I treat all internet-facing vulnerabilities as exploitable because we don’t receive notice from cybercriminals when they find a hole. It’s like a rat politely informing you that you left the back door open before coming in to eat your biscuits.

“Patches, updates or vendor mitigations for security vulnerabilities in office productivity suites, web browsers and their extensions, email clients, PDF software, and security products are applied within one month of release.”

I think my advice for the above stands and that a whole month is a bit too long, but hey, this is Maturity Level One, so if all you’re after is a check of approval, then, as a rational person, I suspect that you’ll be vetting the updates and applying them as soon as practical. The productivity applications like those mentioned in control are the common targets of many exploits because Operating Systems are getting a bit tougher to compromise — but still vulnerable.

“A vulnerability scanner is used at least daily to identify missing patches or updates for security vulnerabilities in internet-facing services.”

You have no idea how happy I was to see this control added. While daily scans may be cumbersome for a larger organisation, using a cloud-based service like Tenable.io is the perfect way to achieve this. I also highly recommend Tenable as the go-to solution for vulnerability scanning and, after working with Tenable since the late ’90s, I stand behind my recommendation 100%.

The benefit here is that since cloud-based vulnerability scanners, like Tenable.io, update their scanning rules and plugins up to several times a day, constantly scanning for exploits can inform you long before it gets exploited by a malicious third-party. Every day my inbox fills with scan results, and on occasion, I see something new; you better believe I’m straight onto the phone to the impacted client.

“A vulnerability scanner is used at least fortnightly to identify missing patches or updates for security vulnerabilities in office productivity suites, web browsers and their extensions, email clients, PDF software, and security products.”

This control is the second part of the vulnerability management solution: internal scanning. The previous control covers the public face while this one tackles the internal face. An on-premises scanner can be in your office or data centre, your colocation services provider, or a third-party hosting organisation. This system may reside within a cloud tenant like Microsoft Azure. As a private, internal system, the vulnerability scanner assumes a trusted identity and performs in-depth scans of private network systems. For specific use cases like mobile devices (think laptops since many of us work from home) can involve a client installed on those systems that report back into the management portal.

I recommend using Tenable Nessus, connected into either Tenable.io (cloud) or Tenable.sc (on-premises) to cover the internal scanning. For clients, look no further than Nessus Agents. Of course, scanning is one thing — doing something with that information is quite another, but please start with a vulnerability scanning solution. This service is close to my heart, so for any advice, please reach out to me directly.

“Internet-facing services, office productivity suites, web browsers and their extensions, email clients, PDF software, Adobe Flash Player, and security products that are no longer supported by vendors are removed.”

Ah, the circle of life. Before I break into a song featuring hits from The Lion King, I need to ask if you have a lifecycle management plan for your applications. Once they outlive their useful life and are no longer supported or upgradable, they should be quietly put out to pasture or deleted. I understand that we often have vital applications to operations but ask yourself if the risk they pose is worth it or if there are other means you can mitigate security incidents to hang onto them.

Long story short, if it presents a risk from system loss to lateral movement intrusion, you should get rid of it. Once you get Maturity Level One under wraps for this and the other seven strategies, we can look at bumping it up to Maturity Level Two.

Patch Applications: Maturity Level Two

“Patches, updates or vendor mitigations for security vulnerabilities in internet-facing services are applied within two weeks of release, or within 48 hours if an exploit exists.”

(As above, ML1) The old approach allowed for “within one month”, but seriously, we’re talking about patching vulnerabilities here. Why leave the door open that long? These highlight “internet-facing” systems and generously gives you two whole weeks unless (and this is a big unless) an exploit exists. I don’t know about you, but I treat all internet-facing vulnerabilities as exploitable because we don’t receive notice from cybercriminals when they find a hole. It’s like a rat politely informing you that you left the back door open before coming in to eat your biscuits.

(As above, ML1) I think my advice for the above stands and that a whole month is a bit too long, but hey, this is Maturity Level One, so if all you’re after is a check of approval, then, as a rational person, I suspect that you’ll be vetting the updates and applying them as soon as practical. The productivity applications like those mentioned in control are the common targets of many exploits because Operating Systems are getting a bit tougher to compromise — but still vulnerable.

“A vulnerability scanner is used at least daily to identify missing patches or updates for security vulnerabilities in internet-facing services.”

(As above, ML1) You have no idea how happy I was to see this control added. While daily scans may be cumbersome for a larger organisation, using a cloud-based service like Tenable.io is the perfect way to achieve this. I also highly recommend Tenable as the go-to solution for vulnerability scanning and, after working with Tenable since the late ’90s, I stand behind my recommendation 100%.

(As above, ML1) This control is the second part of the vulnerability management solution: internal scanning. The previous control covers the public face while this one tackles the internal face. An on-premises scanner can be in your office or data centre, your colocation services provider, or a third-party hosting organisation. This system may reside within a cloud tenant like Microsoft Azure. As a private, internal system, the vulnerability scanner assumes a trusted identity and performs in-depth scans of private network systems. For specific use cases like mobile devices (think laptops since many of us work from home) can involve a client installed on those systems that report back into the management portal.

(As above, ML1) Ah, the circle of life. Before I break into a song featuring hits from The Lion King, I need to ask if you have a lifecycle management plan for your applications. Once they outlive their useful life and are no longer supported or upgradable, they should be quietly put out to pasture or deleted. I understand that we often have vital applications to operations but ask yourself if the risk they pose is worth it or if there are other means you can mitigate security incidents to hang onto them.

Once you achieve Maturity Level One, the focus becomes building upon the foundation you created and bolstering your defences with additional controls. Applications used by various organisations vary wildly, but at the core of these applications is keeping them working well and securing the information they store, process, and transmit.

“Patches, updates or vendor mitigations for security vulnerabilities in internet-facing services are applied within two weeks of release, or within 48 hours if an exploit exists.”

Anything that faces the internet should be considered an attack vector (I would argue any system presents an attack vector) and must be adequately secured.

In planning my approach, I treat all vulnerabilities as though they have active exploits and assess what my mitigating controls are and what the likelihood of an attack is and consider what happens if an attack is successful.

Patching remains one of the best approaches and doing so with the latest stable releases of applications and their patches.

As per my note above in Maturity Level One, consider as many angles as possible when assessing threat vectors and, better still, engage experts to provide advice on what you should be patching and when, aligned with the priorities and objectives of the organisation. Suppose an isolated test network has a vulnerability rated high, but a critical production network has a vulnerability rated medium. In that case, you probably consider that rebuilding a test network is less of a priority, should it get breached. Yet to be fair, a test network shouldn’t exist in an exploitable environment anyway because despite containing non-production data, it does contain information about how your systems operate. Why do you think car manufacturers are so protective of prototypes?

“Patches, updates or vendor mitigations for security vulnerabilities in other applications are applied within one month.”

While this makes sense in principle, I encounter few organisations that update their applications monthly, let alone more frequently. Even though these systems may not be internet-facing, remember that two of the three threat actors tend to be internal: malicious insiders and well-intended insiders. Just because malicious outsiders cannot access or exploit a system doesn’t mean it’s safe. Still, if you can update applications monthly, it’s far better than some businesses that only do so every few months. Or years. Don’t laugh — they exist. And you might be one of them.

“A vulnerability scanner is used at least daily to identify missing patches or updates for security vulnerabilities in internet-facing services.”

I refer to my earlier points about implementing a vulnerability management solution like Tenable, including the cloud-based platform Tenable.io or the on-premises solution Tenable.sc along with Tenable Nessus as the internal scanner. Tenable has a cool new offering called Tenable.ep (for Exposure Platform) that is one of their best to date.

“A vulnerability scanner is used at least weekly to identify missing patches or updates for security vulnerabilities in office productivity suites, web browsers and their extensions, email clients, PDF software, and security products.”

Continuing from the last point, you can take your vulnerability management platform to the next level by looking at Tenable Lumin for advanced analytics and Tenable.ad for in-depth vulnerability management of your directory services. With many businesses relying on Microsoft Active Directory as their source of truth, it should be considered in-scope of any vulnerability management solution.

“A vulnerability scanner is used at least fortnightly to identify missing patches or updates for security vulnerabilities in other applications.”

If it’s on your network, it should be in scope for any vulnerability management solution. I should mention that vulnerability scanning and management is a full-time job in and of itself, so consider engaging a managed security services provider (MSSP) to look after this for you. Instead of a large CapEx hit, just pay for an MSSP tenant for the same benefits.

A MSSP can offer a services wrapper to manage your platform for those of you who prefer to own their vulnerability management solution. Check out our SOC partner SecurityHQ for just such an offering.

Refer to my earlier points under Maturity Level One for this. If it’s not supported, can’t be updated, and patches are no longer available, your vulnerability footprint is growing daily, and there is little you can do to stop it. Your best option is replacement or upgrading (or even decommissioning altogether), and to buy a little time, you may consider additional mitigation techniques.

Once you achieve Maturity Level Two across the board of all eight strategies, you can make the final summit push to the peak and Maturity Level Three.

Patch Applications: Maturity Level Three

“Patches, updates or vendor mitigations for security vulnerabilities in internet-facing services are applied within two weeks of release, or within 48 hours if an exploit exists.”

“A vulnerability scanner is used at least daily to identify missing patches or updates for security vulnerabilities in internet-facing services.”

“Patches, updates or vendor mitigations for security vulnerabilities in internet-facing services are applied within two weeks of release, or within 48 hours if an exploit exists.”

(As above, ML2) Anything that faces the internet should be considered an attack vector (I would argue any system presents an attack vector) and must be adequately secured.

Patching remains one of the best approaches and doing so with the latest stable releases of applications and their patches.

(As above, ML2) As per my note above in Maturity Level One, consider as many angles as possible when assessing threat vectors and, better still, engage experts to provide advice on what you should be patching and when, aligned with the priorities and objectives of the organisation. Suppose an isolated test network has a vulnerability rated high, but a critical production network has a vulnerability rated medium. In that case, you probably consider that rebuilding a test network is less of a priority, should it get breached. Yet to be fair, a test network shouldn’t exist in an exploitable environment anyway because despite containing non-production data, it does contain information about how your systems operate. Why do you think car manufacturers are so protective of prototypes?

“Patches, updates or vendor mitigations for security vulnerabilities in other applications are applied within one month.”

(As above, ML2) While this makes sense in principle, I encounter few organisations that update their applications monthly, let alone more frequently. Even though these systems may not be internet-facing, remember that two of the three threat actors tend to be internal: malicious insiders and well-intended insiders. Just because malicious outsiders cannot access or exploit a system doesn’t mean it’s safe. Still, if you can update applications monthly, it’s far better than some businesses that only do so every few months. Or years. Don’t laugh — they exist. And you might be one of them.

“A vulnerability scanner is used at least daily to identify missing patches or updates for security vulnerabilities in internet-facing services.”

(As above, ML2) I refer to my earlier points about implementing a vulnerability management solution like Tenable, including the cloud-based platform Tenable.io or the on-premises solution Tenable.sc along with Tenable Nessus as the internal scanner. Tenable has a cool new offering called Tenable.ep (for Exposure Platform) that is one of their best to date.

(As above, ML2) Continuing from the last point, you can take your vulnerability management platform to the next level by looking at Tenable Lumin for advanced analytics and Tenable.ad for in-depth vulnerability management of your directory services. With many businesses relying on Microsoft Active Directory as their source of truth, it should be considered in-scope of any vulnerability management solution.

“A vulnerability scanner is used at least fortnightly to identify missing patches or updates for security vulnerabilities in other applications.”

(As above, ML2) If it’s on your network, it should be in scope for any vulnerability management solution. I should mention that vulnerability scanning and management is a full-time job in and of itself, so consider engaging a managed security services provider (MSSP) to look after this for you. Instead of a large CapEx hit, just pay for an MSSP tenant for the same benefits.

A MSSP can offer a services wrapper to manage your platform for those of you who prefer to own their vulnerability management solution. Check out our SOC partner SecurityHQ for just such an offering.

(As above, ML2) Refer to my earlier points under Maturity Level One for this. If it’s not supported, can’t be updated, and patches are no longer available, your vulnerability footprint is growing daily, and there is little you can do to stop it. Your best option is replacement or upgrading (or even decommissioning altogether), and to buy a little time, you may consider additional mitigation techniques.

“Patches, updates or vendor mitigations for security vulnerabilities in internet-facing services are applied within two weeks of release, or within 48 hours if an exploit exists.”

Internet-facing means it’s more vulnerable than the average network. Enough said, as I’ve covered this one in the previous sections.

Patch. Your Systems. And their dependencies, too.

“Patches, updates or vendor mitigations for security vulnerabilities in other applications are applied within one month.”

Consider automating patch deployment as much as possible. You’ll be thankful you did. May I also suggest logging everything so you have a record of all activity.

“A vulnerability scanner is used at least daily to identify missing patches or updates for security vulnerabilities in internet-facing services.”

Vulnerability management is so fashionable right now, and thankfully, it will never go out of style!

Be sure to schedule the scans and reports and to set up email and SMS notifications. Better still, look at a MSSP like Data^#3 powered by SecurityHQ.

“A vulnerability scanner is used at least fortnightly to identify missing patches or updates for security vulnerabilities in other applications.”

The more you know, the better positioned you are to defend the castle. Be sure to act on the findings, and if you’re not sure, get the right people involved.

“Applications that are no longer supported by vendors are removed.”

I couldn’t state it any more bluntly.

Where to from here?

If you have any further questions on application patching reach out to Data^#3 any time, or ask us about an Essential Eight assessment, we’ll put you in touch with the right people that can help. Next in our blogs series for the ACSC’s Essential Eight Maturity Model is Restricting Administrative Privileges. Until then, stay safe out there.

Essential Eight Adoption Assessment

Using the ACSC recommendations as a framework, Data^#3 has built an Essential Eight Assessment to help organisations understand and improve their security posture.

The Essential Eight Assessment is a 5-day engagement, conducted by a Data^#3 Information Assurance Specialist, including up to 2 days spent onsite with the customer.

This is blog 3 of a 9-part series. See earlier posts on: