Please take some time to read all of the previous articles on the updated Essential Eight Maturity Model; the links are at the bottom of this article.
Many applications arrive ready to use and are often no more complex than sliding a pre-made lasagne into the oven. However, convenience can have catastrophic consequences if not prepared and managed correctly. Like forgetting to take the plastic wrap off your oven-ready lasagne, some of the features enabled by default in your applications can quickly become unpalatable.
How many of us have stories about logging into a neighbour’s wireless router with the username “admin” and the password “admin”? How often have you found systems with default protocols and services enabled like FTP, HTTP admin consoles, or SMTP with the default community name “public”? How many applications does your organisation use, from web browsers to productivity suites, to scripting languages that are open-slather, and anyone can do anything with them?
Application Hardening is an activity we should undertake when we first onboard an application to ensure it works and does so securely, limiting the system’s power to only those who should have it. Many vendors publish hardening guides for their products, and cybersecurity consultants are skilled at helping you configure systems safely and securely. Hardening is not a “set and forget” task but must be reviewed as the threat landscape changes. We recommend security testing, like penetration tests and vulnerability assessments, at least annually or after significant infrastructure changes, to help review your posture regularly.
The updates to the ACSC Maturity Model for User Application Hardening are a significant first step towards bolstering your cyber defences. And don’t forget to take your lasagne out of the oven!
Where should you start?
The ACSC published significantly updated controls in this specific Essential Eight strategy, so let’s look at what it takes to achieve the increasing Maturity Levels (ML). There’s a lot to take in: Maturity Level 1 (ML1) increased from just one to four controls, Maturity Level Two (ML2) nearly quadrupled, from three to eleven controls, and Maturity Level Three (ML3) jumped from a mere five to fourteen controls!
While an increase from nine to twenty-nine can intimidate even the sturdiest security team, you quickly realise how the controls are shared and linked between maturity levels (ML). In order to achieve ML2 you need to have actioned all ML1 controls. Where controls have rolled down through maturity levels, I’ll simply copy and paste my statements; we’ve condensed these sections for your convenience.
So, without ado; Maturity Level 1 for Application Hardening.
“Web browsers do not process Java from the internet.”
This issue is surprisingly more common than we’d think, the volume of Java updates that come along regularly is staggering. No matter how well you keep your systems up to date, the pace at which cybercriminals seem to find new ways to exploit Java is astonishing. Then again, maybe it should not surprise us because of how many devices and applications out there run on Java. The point here is that you don’t execute anything Java from an untrusted network. A good vetting and sandboxing process should work here.
“Web browsers do not process web advertisements from the Internet.”
Go ahead and say it: Spam. We all love our free content, and it feels like there is a lot less every day, with many switching to a subscription model to generate revenue. If there are no subscribers, then how do they generate revenue? Advertising, of course. Just be aware that every web ad is not innocent and annoying; cybercriminals are well-resourced and find ways to exploit even seemingly harmless advertisements. It might make things a little less visually rich and result in a few blank boxes around your page but blocking web ads can save a lot of grief.
“Internet Explorer 11 does not process content from the internet.”
I can’t entirely agree with the mention of only one specific browser here for hardening, but I have a few thoughts. Is anyone still using Internet Explorer (IE)? Yes, I see a few, but that’s primarily to support legacy applications and platforms. Many organisations use Chrome, which can be controlled via policies. Perhaps this control focuses on IE due to its legacy and its looming end of life, replaced by the Chromium-powered Edge. In short, get rid of IE altogether if you can, and that often starts with updating and replacing apps and platforms that run on IE only.
“Web browser security settings cannot be changed by users.”
From the “well, duh!” section, why bother implementing controls of any stripe when the people they’re intended to protect can ignore them? You would be surprised at how many organisations let the users decide what to execute and browse because they don’t want to deal with the whinging or the power plays of those higher up. My take is integration, enforcement, and explanation. Integrate the controls, enforce them, and explain why they exist. Just don’t be too draconian; some exceptions may need to be made for those entrusted with the ability to do so.
“Web browsers do not process Java from the internet.”
(As above, ML1) This issue is surprisingly more common than we’d think, the volume of Java updates that come along regularly is staggering. No matter how well you keep your systems up to date, the pace at which cybercriminals seem to find new ways to exploit Java is astonishing. Then again, maybe it should not surprise us because of how many devices and applications out there run on Java. The point here is that you don’t execute anything Java from an untrusted network. A good vetting and sandboxing process should work here.
“Web browsers do not process web advertisements from the Internet.”
(As above, ML1) Go ahead and say it: Spam. We all love our free content, and it feels like there is a lot less every day, with many switching to a subscription model to generate revenue. If there are no subscribers, then how do they generate revenue? Advertising, of course. Just be aware that every web ad is not innocent and annoying; cybercriminals are well-resourced and find ways to exploit even seemingly harmless advertisements. It might make things a little less visually rich and result in a few blank boxes around your page but blocking web ads can save a lot of grief.
“Internet Explorer 11 does not process content from the internet.”
(As above, ML1) I can’t entirely agree with the mention of only one specific browser here for hardening, but I have a few thoughts. Is anyone still using Internet Explorer (IE)? Yes, I see a few, but that’s primarily to support legacy applications and platforms. Many organisations use Chrome, which can be controlled via policies. Perhaps this control focuses on IE due to its legacy and its looming end of life, replaced by the Chromium-powered Edge. In short, get rid of IE altogether if you can, and that often starts with updating and replacing apps and platforms that run on IE only.
“Web browser security settings cannot be changed by users.”
(As above, ML1) From the “well, duh!” section, why bother implementing controls of any stripe when the people they’re intended to protect can ignore them? You would be surprised at how many organisations let the users decide what to execute and browse because they don’t want to deal with the whinging or the power plays of those higher up. My take is integration, enforcement, and explanation. Integrate the controls, enforce them, and explain why they exist. Just don’t be too draconian; some exceptions may need to be made for those entrusted with the ability to do so.
“Microsoft Office is blocked from creating child processes.”
Consider this control like the adult that lives vicariously through their child and expects them to live up to the expectations they could not achieve in their youth. If a program is prevented from creating a child process, you can mitigate the potential issues of runaway processes or mutated versions of the parent. This way, it does what the parent couldn’t (without the protests of going to piano practice). Although, controlling how a program executes doesn’t always stop it from creating a process that can perform all kinds of nasty deeds. If you’re going to manage an application in the name of managing risk, ensure you enact a form of digital birth control.
How? Generally through attack surface reduction rules, enabled by group policies to disable the feature.
“Microsoft Office is blocked from creating executable content.”
As brilliant as it is, Microsoft Office can still be leveraged to attack your systems and data because, like most programs, it does what we ask of it. Like many utilities, it has as much power for evil as good, including creating executable content. A simplified example was how I made batch files in a word document, swapped the extension, and voila! It’s far more complex now, but you get the idea. Consider this control as a way to limit Office to “do” instead of creating things to do.
Here’s another example. When I was a kid, my dad would ask my older brother (the Office program) to do a chore. In turn, my brother would make me (the created executable) do it deliberately wrong, so I’d get into trouble. If we had mitigated that process, my brother would have been forced to do the chore, and not me.
How? Generally through attack surface reduction rules, enabled by group policies to disable the feature.
“Microsoft Office is blocked from injecting code into other processes.”
Following on from preventing Office from creating executables, you should also ensure Office cannot interfere in other processes, which is just as effective at preventing nefarious actions from occurring. This action is a form of sabotage, so making sure Office cannot corrupt a running process is essential to maintaining the integrity of the application and validity of the data.
As an example, let’s say my dad has asked me to do a chore (the process), and I’m happily going about doing it. My older brother (the Office program) decides it would be funny for me to do it wrong and get into trouble. He tells me, “Dad said you need to do this way”. I comply and end up in strife for doing it wrong. If we use the recommended ACSC control, my brother does not interfere, and the chore is completed as initially requested. Make sense?
How? Generally through attack surface reduction rules, enabled by group policies to disable the feature.
“Microsoft Office is configured to prevent activation of OLE packages.”
By now, you understand Office is powerful and can create executables or inject code into other processes. This control prevents Office from running processes instead of creating or corrupting others.
Object Linking and Embedding (OLE) is a way to link items like documents and other objects like programs, images, scripts, etc. Typically, we’d keep specific objects separate because if they are connected, bad things can happen. It’s like crossing the terminals of a car battery, which can be catastrophic depending on the objects. If Office can connect the objects via an OLE package, something can hit the fan.
Let’s say that I see a box containing a couple of cans of paint (the OLE Package). I know that dad wants to paint his boat white with red trim. My brother (the Office program) tells me (the process) to mix the paint to save dad time. I activate the package incorrectly, and dad ends up with pink paint. So you can see why you need to prevent activation of OLE packages by Office; it all ends in tears (and a pink boat).
How? You guessed it, generally through attack surface reduction rules, enabled by group policies to disable the feature. I know this gets repetitive, but you likely already have access to the services, features, and options to make it happen.
“PDF software is blocked from creating child processes.”
We often mistake PDF software for something that just creates read-only documents or fills in forms, but how well do you understand the PDF engine under the covers? It can be powerful and complex, and every bit as capable as your favourite Microsoft Office programs at creating child processes to perform tasks, authorised or otherwise. Unless you absolutely need the capability and can strictly control it, disable it.
“ACSC or vendor hardening guidance for Microsoft Office and PDF software web browsers is implemented.”
This control is where you realise the wealth of knowledge that ACSC brings to the table and is willing to share with businesses and individuals alike. The team of cybersecurity professionals behind these hardening guides are second to none. They are not afraid to venture into the deep, dark recesses of applications to see what they can and can’t do, and also what they might or could do if modified. Remember the old joke, “that’s not a bug, it’s a feature”?
The ACSC looks for these bugs to squash before they become a feature used against you. Since this mitigation control is in the Essential Eight and deals with browsers, Office, and PDF software, you can take the advice the ACSC provides without hesitation.
“Web browser, Microsoft Office and PDF software security settings cannot be changed by users.”
In ML1, we focused on just web browsers. Returning to the “well, duh!” approach, why would you put a control in place intended to protect users, if they can just ignore it? It’s like closing a door, not locking it, and telling people not to enter. What are they going to do? That’s right! Enter (and probably steal the leftover pizza you brought for lunch, too!)
Too many organisations place blind faith in their team to do the right thing, but the expression “curiosity killed the cat” came from somewhere. In this case, it probably got Bob from Fleet Operations sacked because he did what he shouldn’t have, but also wasn’t prevented from doing with a control. Locks are generally sturdier than willpower.
Integrate the controls, enforce them, and explain why they exist. Adopt a zero-trust mentality, where exceptions are only made for those that require them and are entrusted with the responsibility.
“Blocked PowerShell script executions are logged.”
Logging is now a recurring theme throughout many of the Essential Eight strategies, increasing motivation to implement a Security Information and Events Management (SIEM) system, or better still Managed Security Operations Centre (SOC) services like those from SecurityHQ.
PowerShell is stupidly powerful in the Microsoft world and borders on omnipotent, but we have the ability to block it. While the workforce is not full of PowerShell experts, those who know the application wield considerable power and must be trusted to use it for good. Everyone else gets blocked, and you want to be sure that denial is recorded and relayed to the proper authority in the business. It’s not a Big Brother approach, and far from being Orwellian, it is just good practice to know what succeeds and fails, especially when it’s something as capable as PowerShell.
Block it, log it, report it, action it. Simple.
“Web browsers do not process Java from the internet.”
(As above, ML1) This issue is surprisingly more common than we’d think, the volume of Java updates that come along regularly is staggering. No matter how well you keep your systems up to date, the pace at which cybercriminals seem to find new ways to exploit Java is astonishing. Then again, maybe it should not surprise us because of how many devices and applications out there run on Java. The point here is that you don’t execute anything Java from an untrusted network. A good vetting and sandboxing process should work here.
“Web browsers do not process web advertisements from the Internet.”
(As above, ML1) Go ahead and say it: Spam. We all love our free content, and it feels like there is a lot less every day, with many switching to a subscription model to generate revenue. If there are no subscribers, then how do they generate revenue? Advertising, of course. Just be aware that every web ad is not innocent and annoying; cybercriminals are well-resourced and find ways to exploit even seemingly harmless advertisements. It might make things a little less visually rich and result in a few blank boxes around your page but blocking web ads can save a lot of grief.
“Internet Explorer 11 does not process content from the internet.”
(As above, ML1) I can’t entirely agree with the mention of only one specific browser here for hardening, but I have a few thoughts. Is anyone still using Internet Explorer (IE)? Yes, I see a few, but that’s primarily to support legacy applications and platforms. Many organisations use Chrome, which can be controlled via policies. Perhaps this control focuses on IE due to its legacy and its looming end of life, replaced by the Chromium-powered Edge. In short, get rid of IE altogether if you can, and that often starts with updating and replacing apps and platforms that run on IE only.
“Web browser security settings cannot be changed by users.”
(As above, ML1) From the “well, duh!” section, why bother implementing controls of any stripe when the people they’re intended to protect can ignore them? You would be surprised at how many organisations let the users decide what to execute and browse because they don’t want to deal with the whinging or the power plays of those higher up. My take is integration, enforcement, and explanation. Integrate the controls, enforce them, and explain why they exist. Just don’t be too draconian; some exceptions may need to be made for those entrusted with the ability to do so.
“Microsoft Office is blocked from creating child processes.”
(As above, ML2) Consider this control like the adult that lives vicariously through their child and expects them to live up to the expectations they could not achieve in their youth. If a program is prevented from creating a child process, you can mitigate the potential issues of runaway processes or mutated versions of the parent. This way, it does what the parent couldn’t (without the protests of going to piano practice). Although, controlling how a program executes doesn’t always stop it from creating a process that can perform all kinds of nasty deeds. If you’re going to manage an application in the name of managing risk, ensure you enact a form of digital birth control.
How? Generally through attack surface reduction rules, enabled by group policies to disable the feature.
“Microsoft Office is blocked from creating executable content.”
(As above, ML2) As brilliant as it is, Microsoft Office can still be leveraged to attack your systems and data because, like most programs, it does what we ask of it. Like many utilities, it has as much power for evil as good, including creating executable content. A simplified example was how I made batch files in a word document, swapped the extension, and voila! It’s far more complex now, but you get the idea. Consider this control as a way to limit Office to “do” instead of creating things to do.
Here’s another example. When I was a kid, my dad would ask my older brother (the Office program) to do a chore. In turn, my brother would make me (the created executable) do it deliberately wrong, so I’d get into trouble. If we had mitigated that process, my brother would have been forced to do the chore, and not me.
How? Generally through attack surface reduction rules, enabled by group policies to disable the feature.
“Microsoft Office is blocked from injecting code into other processes.”
(As above, ML2) Following on from preventing Office from creating executables, you should also ensure Office cannot interfere in other processes, which is just as effective at preventing nefarious actions from occurring. This action is a form of sabotage, so making sure Office cannot corrupt a running process is essential to maintaining the integrity of the application and validity of the data.
As an example, let’s say my dad has asked me to do a chore (the process), and I’m happily going about doing it. My older brother (the Office program) decides it would be funny for me to do it wrong and get into trouble. He tells me, “Dad said you need to do this way”. I comply and end up in strife for doing it wrong. If we use the recommended ACSC control, my brother does not interfere, and the chore is completed as initially requested. Make sense?
How? Generally through attack surface reduction rules, enabled by group policies to disable the feature.
“Microsoft Office is configured to prevent activation of OLE packages.”
(As above, ML2) By now, you understand Office is powerful and can create executables or inject code into other processes. This control prevents Office from running processes instead of creating or corrupting others.
Object Linking and Embedding (OLE) is a way to link items like documents and other objects like programs, images, scripts, etc. Typically, we’d keep specific objects separate because if they are connected, bad things can happen. It’s like crossing the terminals of a car battery, which can be catastrophic depending on the objects. If Office can connect the objects via an OLE package, something can hit the fan.
Let’s say that I see a box containing a couple of cans of paint (the OLE Package). I know that dad wants to paint his boat white with red trim. My brother (the Office program) tells me (the process) to mix the paint to save dad time. I activate the package incorrectly, and dad ends up with pink paint. So you can see why you need to prevent activation of OLE packages by Office; it all ends in tears (and a pink boat).
How? You guessed it, generally through attack surface reduction rules, enabled by group policies to disable the feature. I know this gets repetitive, but you likely already have access to the services, features, and options to make it happen.
“PDF software is blocked from creating child processes.”
(As above, ML2) We often mistake PDF software for something that just creates read-only documents or fills in forms, but how well do you understand the PDF engine under the covers? It can be powerful and complex, and every bit as capable as your favourite Microsoft Office programs at creating child processes to perform tasks, authorised or otherwise. Unless you absolutely need the capability and can strictly control it, disable it.
“ACSC or vendor hardening guidance for Microsoft Office and PDF software web browsers is implemented.”
(As above, ML2) This control is where you realise the wealth of knowledge that ACSC brings to the table and is willing to share with businesses and individuals alike. The team of cybersecurity professionals behind these hardening guides are second to none. They are not afraid to venture into the deep, dark recesses of applications to see what they can and can’t do, and also what they might or could do if modified. Remember the old joke, “that’s not a bug, it’s a feature”?
The ACSC looks for these bugs to squash before they become a feature used against you. Since this mitigation control is in the Essential Eight and deals with browsers, Office, and PDF software, you can take the advice the ACSC provides without hesitation.
“Web browser, Microsoft Office and PDF software security settings cannot be changed by users.”
(As above, ML2) In ML1, we focused on just web browsers. Returning to the “well, duh!” approach, why would you put a control in place intended to protect users, if they can just ignore it? It’s like closing a door, not locking it, and telling people not to enter. What are they going to do? That’s right! Enter (and probably steal the leftover pizza you brought for lunch, too!)
Too many organisations place blind faith in their team to do the right thing, but the expression “curiosity killed the cat” came from somewhere. In this case, it probably got Bob from Fleet Operations sacked because he did what he shouldn’t have, but also wasn’t prevented from doing with a control. Locks are generally sturdier than willpower.
Integrate the controls, enforce them, and explain why they exist. Adopt a zero-trust mentality, where exceptions are only made for those that require them and are entrusted with the responsibility.
“Blocked PowerShell script executions are logged.”
(As above, ML2) Logging is now a recurring theme throughout many of the Essential Eight strategies, increasing motivation to implement a Security Information and Events Management (SIEM) system, or better still Managed Security Operations Centre (SOC) services like those from SecurityHQ.
PowerShell is stupidly powerful in the Microsoft world and borders on omnipotent, but we have the ability to block it. While the workforce is not full of PowerShell experts, those who know the application wield considerable power and must be trusted to use it for good. Everyone else gets blocked, and you want to be sure that denial is recorded and relayed to the proper authority in the business. It’s not a Big Brother approach, and far from being Orwellian, it is just good practice to know what succeeds and fails, especially when it’s something as capable as PowerShell.
Block it, log it, report it, action it. Simple.
“Internet Explorer 11 is disabled or removed.”
At ML1 and ML2, we limited what Internet Explorer 11 can do. Notice it explicitly mentions version 11, not previous versions; IE 11 came out in 2013, so if you’re running earlier versions, you really need to address this control ASAP!
Is anyone still using IE anyway? Shocking for some, but yes, I know a few organisations are still stuck with IE because their legacy applications won’t work with a more modern browser. Keeping around legacy applications like IE 11 is just an unnecessary security risk. Sure, you can put in mitigating controls and apply a Zero Trust or Defence In-Depth Approach, but how long can you keep that up?
Internet Explorer is not sustainable. Just get rid of it as fast as humanly possible. And you get a nice jump on ML3!
“.NET Framework 3.5 (including .NET 2.0 and 3.0) is disabled or removed.”
The .NET framework has been around a long time and currently sits at version 4.7.1 as of writing. The framework itself will have been around for 20 years in February 2022, and legacy versions like 3.5 arrived in 2008, so you get the idea that it’s probably nowhere near as robust or secure as it should be. Software companies have zero interest in keeping up legacy products beyond a specific date, and cybercriminals are relentless in finding holes in legacy systems.
So, if a software vendor no longer supports an application version, and cybercriminals have finally found a way to compromise it, it only makes sense that we’ve long since upgraded, right? Wrong – this control exists in the Essential Eight because many organisations still use legacy software, often as part of production systems. Bad actors know this, so if you have legacy systems with legacy frameworks and software, don’t let your personal legacy be an avoidable data breach. Upgrade your systems and get rid of the old stuff.
“Windows PowerShell 2.0 is disabled or removed.”
This is the second mention of a legacy application at ML3, so take note of the trend. The current version is 7 (7.2 to be precise as of writing), so version 2.0 has no business being on your systems. Version 2 saw action, through service packs, on Windows XP, Vista, and Windows 7 workstation operating systems as well as Server 2003 and Server 2008R2, so yeah, it’s old. We already know how powerful PowerShell can be, so you will want to manage this risk.
Keep your environment up to date and get rid of the legacy applications. I cannot find a single reason to keep PowerShell 2.0 around.
“PowerShell is configured to use Constrained Language Mode.”
When PowerShell makes multiple appearances at ML3, you get the idea that it is serious business. PowerShell is essential to the daily operations of an IT department (and the business as a whole). Start with access to and execution of the program via Application Control, another Essential Eight strategy.
PowerShell has four language modes: FullLanguage, RestrictedLanguage, NoLanguage, and ConstrainedLanguage. The idea is to function but control the syntax and capabilities available. I’ve heard arguments that the administrators should be able to use the entire package because they paid for it (well, really, it was built in, so no), but humans being humans, we make mistakes and get tricked, so mitigating the power is just good practice. Combine this with Just in Time administration and Just Enough administration, and you get the power, but with responsibility and controls.
Rather than explain each mode, be aware that you should control PowerShell as a priority. We’re always happy to discuss further, since PowerShell is just part of the IT operations fabric. Reach out if you need a hand.
“Blocked PowerShell script executions are centrally logged and protected from unauthorised modification, and deletion monitored for signs of compromise and actioned when cyber security events are detected.”
I covered this at a high level earlier, but instead of just logging blocked attempts to execute PowerShell, this control also aims to log modifications and signs of compromise. Then the control asks you to take it further and act when detected. Sure, a lot of this can be automated (and that is the beauty of a Security Orchestration, Automation, and Response (SOAR) platform, but never undervalue the input of human analysis.
At this point, I would encourage you to engage a Managed SOC offering like SecurityHQ through Data#3. As these things take a little time to plan, implement correctly, and fine-tune to your exact environment, start the conversation today with your account manager. The return on investment is easy to quantify, but the peace of mind you gain is priceless.
No doubt you have many questions but take it one step at a time. We’re not trying to “boil the ocean” to use a tired cliché, but rather to secure your environment. Start with an Essential Eight assessment or reach out to us any time with your questions, and we’ll put you in touch with the right people to help.
Stay safe out there.
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 5 of a 9-part series. See earlier posts on:
1. Your guide to the ACSC’s Essential Eight Maturity Model
2. Essential Eight Maturity Model: Application Control
3. Essential Eight Maturity Model: Patch Applications
4. Essential Eight Maturity Model: Configure Microsoft Office Macro Settings
5. You are here.
6. Essential Eight Maturity Model: Restrict Administrative Privileges
7. Essential Eight Maturity Model: Patch Operating Systems
8. Essential Eight Maturity Model: Multi-Factor Authentication
9. Essential Eight Maturity Model: Regular Backups