The ACSC Essential Eight Maturity Model
By now, many of you have read my wealth of blogs on LinkedIn, Medium, CoFoundersTown, CISO Platform, and formerly on Peerlyst. You know I have a particular fondness for one specific topic: The Australian Cyber Security Centre (ACSC) Strategies to Mitigate Cyber Security Incidents. One of the elements closest to me is the “Essential Eight” and how it can help your cybersecurity defensive posture with regards to the plethora of threats and exploits we deal with daily.
ACSC has developed a maturity model to help define your current level of maturity against a set of criteria which, increasingly, more organisations, both government and commercial, are adopting. In this article, I’ll review the Essential Eight controls, their maturity levels, and provide some commentary around how we can bolster our defences and examine a few more angles commonly overlooked.
The Essential Eight is not a product nor a solution that can be boxed up and sold, but rather a set of strategies upon which an organisation can define its cybersecurity framework. Interestingly, many of us already have a lot of the pieces needed to get started on our quest for a more mature cybersecurity posture and improved protection.
There are three official maturity levels, from one to three, and two more unofficial levels: Zero, and above three. Maturity Level Zero means that no controls that conform to the mitigation strategy exist. However, I often find we are all doing something that meets each of these controls, even if it isn’t either obvious or complete. As for a maturity level more significant than three, that is a custom level tailored for an individual organisation by the ACSC. I’ll speculate on what some of these could be in each section below.
Using the ACSC terminology, “Maturity Level One: Partly aligned with the intent of the mitigation strategy”, “Maturity Level Two: Mostly aligned with the intent of the mitigation strategy”, and “Maturity Level Three: Fully aligned with the intent of the mitigation strategy”.
Let’s look at each of the strategies, shall we?
Until earlier this year, we called this one “Application Whitelisting” but to be fair, switching the terminology to control from whitelisting makes more sense because it’s about more than just the whitelist. Methods of controlling applications are accessible in more ways, such as leveraging your endpoint protection system, and even to some degree via application controls on firewalls.
Maturity Level 0: The absence of any application control is unlikely as we’re all likely doing some basic things that control who can access applications and programs, like restricting it to specific groups or users, preventing users from installing applications, or Group Policy Objects (GPOs) that modify file paths and enforce mandatory controls for applications in use in environments, from the biggest, heaviest applications to the smallest libraries and plug-ins. If your domain does not implement any of these types of controls, now is the time to start!
Maturity Level 1: Application control is implemented on all workstations and servers to restrict the execution of executables to an approved set. While this does not explicitly mention other platforms like mobile devices, one must always consider anywhere an application can execute, even in networking devices through a shell since even they run operating systems full of programs and code.
Maturity Level 2: As above for workstations and servers, but with the addition of software libraries, scripts and installers. These elements are logical inclusions for a more mature posture since many applications rely on software libraries (like DLL files) and other dependencies and plug-ins. Scripts essentially act to execute programs, and controlling installers can prevent unsanctioned applications from being installed to begin with.
Maturity Level 3: As above, but with Microsoft’s latest recommended block rules are implemented to prevent application control bypasses. These block rules are quite comprehensive and perhaps more palatable than wading through elements like the CIS Controls.
Beyond Level 3: In more extensive, more complex environments, application control can become nightmarish unless you have dedicated resources to manage it, so the involvement of a managed services team may be ideal. At a practical level, always be sure to give users what they need to do their jobs, but nothing more, and to avoid undue hindrance of productivity. It is possible to have too much security!
Some of you have attended my session in the past, where I spoke of the most significant challenges I discovered while doing assessments. These included too many layers, a lack of integration between those layers, a lack of visibility, and human error. These apply to Application Control as much as to do any of the other controls in this list. If you need help, ask.
Thankfully, a lot is possible by leveraging your existing investment, such as Group Policy Objects (GPOs) in Microsoft Active Directory. Here, you can enforce registry key changes, file paths (like forbidding execution from the “Downloads” folder), and file and folder permissions. Sometimes it’s easier to keep people from accessing the application in the first place over trying to manage what they do with it once they get there. This name change is why “control” makes more sense than “whitelisting”, right?
The lesson here is that you don’t need to break the bank to leverage one of the most effective mitigation strategies in application control; planning and getting the right help is all you need to start getting the most out of your existing investments.
Applications are the reason technology exists in the first place. These are “things” made to do “other things” for us. Humans developed technology, so human error is innate. Finding and fixing faults can often be a cat and mouse game with threat actors, whether they are malicious outsiders, malicious insiders, or well-intended insiders. Quite frankly, the last group scare me the most. Patching applications is a must-do regardless of how much or how little technology you have.
Maturity Level 0: It’s unlikely to find an organisation that does not patch its applications at least once in a while, but we do see them now and then. While they often do a pretty good job of updating the operating systems of servers and workstations, the applications that do all the heavy lifting get overlooked. I find many applications are installed with defaults and left that way until they fail or get compromised. Remember it’s always “when”, not “if”! Considering the applications are the place where your essential data processes, it only makes sense to keep them updated. Sadly, this is not always the case.
Maturity Level 1: Security vulnerabilities in applications and drivers assessed as extreme risk are patched, updated or mitigated within one month of the security vulnerabilities being identified by vendors, independent third parties, system managers or users. Applications that are no longer supported by vendors with patches or updates for security vulnerabilities are updated or replaced with vendor-supported versions.
Where I encounter the most confusion is regarding the assessment of the vulnerabilities. Businesses believe that all vulnerabilities must be patched or updated within one month. That creates a lot of overhead at times, and we can feel like we are always updating. By definition of what is “extreme risk”, I look at two factors. First is the Common Vulnerability Scoring System (CVSS) within the Common Vulnerabilities and Exposure (CVE), and the second is the likelihood of exploitation in the context of the customer’s environment.
The CVSS for “Critical” is a score from 9.0 to 10.0. Then I consider how difficult this is to exploit and the likelihood. I never say “impossible”, only “improbable” so no mitigation is absolute or perfect. Suppose the risk exists on a public-facing server or a system readily accessible. In that case, I prioritise it above the same hazard that may exist on an isolated network with strict controls and limited access. Still a threat? Sure! This process is why I always invest the time to not just understand the danger, but likelihood and impact, and hence my love of matrixes.
Outside of the “extreme risk”, patch and update as a matter of priority for higher risk, followed by your routine maintenance for lower risks. Just keep your systems updated to their current, stable releases. Those that are no longer supported or updated must be shown the door (or the delete button, as it were) since we often make the mistake of subscribing to an “if it ain’t broke, don’t fix it” mindset.
Maturity Level 2: Everything here is the same as Maturity Level 1, but the timeline halves from within one month to within two weeks. Everything else applies as well, especially updating or replacing unsupported systems.
Maturity Level 3: As above, so below. Everything applies, but the timeline significantly reduces to within 48 hours of the security vulnerabilities being identified by vendors, independent third parties, system managers or users. At this level of maturity, ACSC also recommends an automated mechanism is used to confirm and record that deployed application and driver patches or updates have been installed, applied successfully and remain in place.
The challenge becomes deploying even just the critical updates within 48 hours. How often can you drop everything and get everything done in a couple of days? If it’s difficult in a smaller business, imagine the challenge for a large enterprise! And then, of course, there are the applications that don’t reside in a traditional server/client environment like network infrastructure, network-connected devices and the ever-expanding world of the Internet of Things (IoT).
Beyond Level 3:
When you think about it, automation just makes sense regardless of your maturity level. Patching and updating applications can be one of the most time-consuming things your administrators do. The challenge becomes covering highly heterogeneous environments with multiple vendors, platforms, and management solutions. In a pure Windows environment, this is easy enough but not every application you use is Windows, let alone compatible with Microsoft to be updated. An investment in a class-leading orchestration and automation suite may be the answer, but I’d urge you to seek out specialised consultants to help you. Hey, I might just know a few!
Configure Microsoft Office Macro Settings
Maturity Level 0: Level 0, in this instance, is improbable unless you have ultimately and deliberately disabled all macro-related controls in your environment. Newer versions of Office have some fairly decent, albeit basic, macro controls by default. Still, I would encourage you to verify any macro-related settings within your Office products or your Active Directory Group Policy Objects (GPOs)
Maturity Level 1: Microsoft Office macros are allowed to execute, but only after prompting users for approval. Users cannot change Microsoft Office macro security settings.
While I agree with preventing users from changing the macro security settings, I disagree with leaving the choice up to them. I guess we can look at it from the perspective that we’re giving them an option and is an excellent case to ensure you deliver adequate cybersecurity awareness training and tools to equip your users to make smart choices.
Maturity Level 2: users cannot change Microsoft Office macro security settings, but also only signed Microsoft Office macros are allowed to execute and Microsoft Office macros in documents originating from the Internet are blocked.
At this point, we ensure that permitted macros are signed, so it makes a good case for leveraging your Microsoft Public Key Infrastructure (PKI) services via certificate authorities. In this instance, “Public” may be misleading if it’s only used internally, but you get the idea why certificates are essential. Considering its inclusion in Windows Server platforms, leveraging certificate services is a good idea (if you’re not already). Establishing code signing can be tricky, so if you’re not confident, engage some expert help.
The other addition is common sense (which feels quite rare these days). NOT executing macros originating from the Internet is just good practice. Funnily enough, we don’t hesitate to download and execute random scripts and programs. I would suggest establishing a reliable vetting process in isolation to try these things out first.
Maturity Level 3: In addition to blocking macros from the Internet and preventing users from changing settings, we add another element. Microsoft Office macros are only allowed to execute in documents from Trusted Locations where write access is limited to personnel whose role is to vet and approve macros.
This element takes control of macros even further and even borders on Application Control by leveraging trusted locations and restricting who can run them. It sounds complicated, but if your AD infrastructure is reliable and well maintained along with the policies, putting this in play shouldn’t be too difficult. It may be harder to educate the workforce and then designate a role to someone to perform the vetting. On this note, always assign these roles to groups rather than individuals — eliminate any single points of failure. You know, the whole “hit by a bus” thing?
Earlier I mentioned signing and using certificates. If you want to start code signing (and it can expand well beyond just macros), you can also look at using trusted third-party certificates from a public CA. This way, you and anyone you share macros with should trust them by default because of the way Windows trusts specific CAs by default.
A word of caution, though. Even malicious code can be signed this way, so always do your research and testing first!
Beyond Level 3: Controlling macros beyond level 3 is nebulous at best, but what I would suggest is considering macros outside of Microsoft. While Microsoft likely makes up the vast majority of your systems and those of your peers, many programs rely on macros that cannot be controlled by GPOs and a Microsoft CA. Many organisations use non-Microsoft solutions for their productivity suite, so they must be equally mindful of the attack vector macros can present.
User Application Hardening
Maturity Level 0: A maturity level of 0 is one I often encounter in this strategy because many individuals and organisations simply install systems to the point they work and then forget about them until they don’t anymore. Default usernames and passwords, default configuration elements, legacy cryptographic components for “backwards compatibility”, default, unused, and insecure services and more are a sure-fire way to earn a maturity level 0. Even the most essential things like turning off unused services and changing the administrator passwords can help you on your way to a more mature security posture.
Maturity Level 1: Web browsers are configured to block or disable support for Flash content. This mechanism is a pretty basic control, yet enough to begin basic hardening as per the maturity model. Considering many applications are web-driven these days, a secure browser is a great place to start.
Maturity Level 2: In addition to blocking Flash, Level 2 adds Web browsers are configured to block web advertisements, and Web browsers are configured to block Java from the Internet. Again, there is a heavy focus on web browsers, but I do agree with Java being a risk. At least in this regard, it blocks public Java and web advertisements. The problem can be that some browsers may not work correctly, and you must be cautious with so many applications relying on Java. It’s about drawing a hard line between the internal, trusted and the external, untrusted zones and what can execute in each.
Maturity Level 3: In addition to blocking or at the very least controlling Flash, Java, and ads, we now add in two controls focused on Microsoft Office: Microsoft Office is configured to disable support for Flash content, and Microsoft Office is configured to prevent activation of Object Linking and Embedding packages.
As is the case with Office Macros, further controlling what Office can do is essential since our productivity suites are where we spend a lot of time creating and managing content and data. That said, we may be lulled into a false sense of security if we do all of the elements mentioned in Maturity Level 3 at a superficial level. The maturity model is not absolute, and there are a lot of things to consider with even the briefest sentences.
Beyond Level 3: Achieving a maturity level beyond three may take considerable effort, but my thinking is that you harden all user applications beyond just Office and browsers. To me, we should set every single user application within reason to be secure but without unduly hindering productivity. You will find that most vendors issue “hardening guides” on how to adequately secure their products for your environment.
Still, I would encourage you to engage a cybersecurity expert to assist in hardening your environment lest you set it to where it is unusable or counterproductive.
Restrict Administrative Privileges
Maturity Level 0: Does everyone in your environment have administrator access to their local devices like workstations and laptops? Does everyone know the admin password to network devices and accounts? Laugh if you want, but I do still find this frequently. Even though you may have administrator and user accounts, not correctly managing privileged and non-privileged access is an excellent way to earn a maturity level of 0.
Maturity Level 1: Privileged access to systems, applications and information is validated when first requested. Policy security controls are used to prevent privileged users from reading emails, browsing the web and obtaining files via online services.
The first part makes sense, especially if you think of it in the context of Single Sign-On (SSO). You log in as an administrator and remain as such as long as you’re using it or until a session expires, kind of like “Just In Time Administration”. I have seen this one presented differently in that someone only gets checked the first time they request access and then retain the rights permanently — kind of like putting someone into a privileged group when they change roles but then never revoking the rights when they leave it.
The second part, however, seems very rare. Many administrators and other privileged accounts are often no different to regular user accounts and have email, web access, and the ability to download (and execute files). While downloading files is often needed, you shouldn’t need an admin account for email, and even web access is subjective (downloading patches and other essential pieces is a given at times — you need the ability to do so.
This risk is why I recommend having separate accounts for business as usual and privileged access. Think of it as damage control. If a regular user gets breached, it may be easier to contain than an administrator being compromised.
Maturity Level 2: Privileged access to systems, applications and data repositories is validated when first requested and revalidated on an annual or more frequent basis. This approach is more favourable and allows for more granular control. Even privileged accounts do not need access to everything, hence the inclusion of data repositories. I also like the annual or more frequent basis. One thing I recommend in every assessment we perform is to review privileged accounts. Always ask, “do they still need admin rights and why?”. Also, ask if others may need their rights increases. Give your team the rights they need to do their job, but no more than the absolute minimum required. As above, prevent access to email, web, and file downloads (some exceptions are needed as I mentioned earlier for administration tasks)
Maturity Level 3: Privileged access to systems, applications and data repositories is validated when first requested and revalidated on an annual or more frequent basis. Privileged access to systems, applications and data repositories is limited to that required for personnel to undertake their duties. Technical security controls are used to prevent privileged users from reading emails, browsing the web and obtaining files via online services.
This maturity level includes the principal of least privilege, so always think about “Just Enough Administration” and “Just In Time Administration”. It’s probably a perfect place to begin implementing The Zero Trust Model and start from the most influential accounts. It is also interesting that at this level, “Technical Controls” get a mention. This criticality is now at a stage where we need to start watching each other closely and using controls that can are technical and enforced. This protection can get into the world of Data Loss Prevention (DLP) solutions and heavy logging and auditing of privileged accounts (which you should be doing anyway)
Beyond Level 3: Controlling administrator rights in your environment is critical. While we often focus on the malicious outsiders, consider what kind of damage malicious insiders and well-intended insiders can do with the power to make changes unchecked. Review your privileged accounts regularly, but also look at the rights every user has near and ask if they need it and why. Invest in a directory-services integrated privileged access management (PAM) solution which can even include an integrated password vault solution with separate clients for administrators and users alike. We all have to manage our credentials well as they are very much the keys to the kingdom.
Patch Operating Systems
Maturity Level 0: While it may sound inconceivable, there are organisations out there that just don’t patch their operating systems. These systems can be out of date and even out of date from when they were installed if the latest patches were never installed, and this was more common when we used portable media that may have sat on a shelf for months before purchase. This practice is not restricted to servers and workstations; virtually anything connected to your network has an operating system, and almost all of them have patches available that never see the light of day.
Reasons vary from lack of resources to systems that run legacy systems that will “break” if updated, to a lack of automation for many systems, to pure ignorance. The fact remains that vulnerabilities in systems where patches are published but not applied are a common attack vector. As a cybercriminal, if I am aware of a vulnerability in a system because it has been published, that is one of the things I will look for when trying to exploit a system. Remember that “the bad guys” monitor these published vulnerabilities just as much (if not more) than those that seek to stop them.
Maturity Level 1: Security vulnerabilities in operating systems and firmware assessed as extreme risk are patched, updated or mitigated within one month of the security vulnerabilities being identified by vendors, independent third parties, system managers or users. Operating systems for workstations, servers and ICT equipment that are no longer supported by vendors with patches or updates for security vulnerabilities are updated or replaced with vendor-supported versions.
It is important to remember that these are the vulnerabilities rated by the CVSS as between 9.0 and 10.0 and should receive your focus and attention above the others (which you should address in priority order after taking care of the extreme risks first). This point is where I would ask if you have a review and verification process along with change management to address these and we’re always willing to help you in this regard if you need assistance.
The second part of this deals more with the lifecycle of operating systems. If it is unsupported and can’t be patched, it is a risk. You must upgrade, replace, or remove it from your environment. It is very frustrating to see legacy systems hanging on just because they run an application that cannot be upgraded, or it breaks every time the supporting structure is updated. I would suggest investing in securing it because you can only imagine the strife if it is compromised by an unsupported OS and the collateral damage upon other systems.
When I think about it, maturity level 1 is almost a free pass; indeed we can address extreme risks in less than a month? I realise that not every system can be arbitrarily updated and restarted, but weigh up your options carefully. If the impacted system is that critical you can’t restart it or patch it within a month, is it acceptable to leave it exposed to a known vulnerability that long? I didn’t think so.
Maturity Level 2: Security vulnerabilities in operating systems and firmware assessed as extreme risk are patched, updated or mitigated within two weeks of the security vulnerabilities being identified by vendors, independent third parties, system managers or users. Operating systems for workstations, servers and ICT equipment that are no longer supported by vendors with patches or updates for security vulnerabilities are updated or replaced with vendor-supported versions.
As is the case for level 1, my thinking applies for level 2. Applying critical patches within two weeks should be possible if you have a well-defined process in place for doing so and if not, maybe it is time to revisit the tactical and strategic patching method you use. Sometimes it can take a couple of weeks to find a suitable window to patch and restart systems (if a reboot is needed) but use the time available to thoroughly test and vet the patches.
Maturity Level 3: Security vulnerabilities in operating systems and firmware assessed as extreme risk are patched, updated or mitigated within 48 hours of the security vulnerabilities being identified by vendors, independent third parties, system managers or users. An automated mechanism is used to confirm and record that deployed operating system and firmware patches or updates have been installed, applied successfully and remain in place. Operating systems for workstations, servers and ICT equipment that are no longer supported by vendors with patches or updates for security vulnerabilities are updated or replaced with vendor-supported versions.
At this stage, we’re endeavouring to apply critical patches and updates within 48 hours of becoming aware of them, and that is no easy task. To operate at a maturity level of 3 at this stage takes a lot of effort and a well-defined process. To that end, I appreciate how automation has been included. You can only imagine the frantic attempt to be level 3 maturity without a degree of automation, and even the smallest environments would struggle to adhere. Orchestration and Automation solutions are a must-have, and if you have already invested in a system to help with patching like Microsoft Configuration Manager, it may be time to review, refine, and streamline the processes.
Beyond Level 3: Adopting a maturity level beyond level 3 is subjective. Do we now include high risks in the categorisation? Maybe we need to expand the coverage to include all network-attached devices like routers, switches, firewalls, IoT, and more. What about mobile devices? Mobile Device Management solutions can help here with regards to phones and tablets. What about Operational Technology (OT) devices? Be sure to seek out expert advice and consult with the ACSC about any advanced advice and maturity.
Maturity Level 0: This is one of the more frequent levels of maturity I find with regards to this control. Many organisations simply have not implemented MFA for a verity of reasons from cost to complexity, and more often than not, end-user resistance. The rationale varies but if often due to MFA being seen as “one more step” that slows them down, especially if they have to do it multiple times a day, or they do not want to put a business app on their device. Regardless of your situation, you should weigh up the costs and benefits of implementing MFA. If user credentials are a common attack vector, then perhaps the additional layer of security is well warranted.
Maturity Level 1: Multi-factor authentication is used to authenticate all users of remote access solutions. Multi-factor authentication uses at least two of the following authentication factors: passwords, Universal 2nd Factor security keys, physical one-time password tokens, biometrics, smartcards, mobile app one-time password tokens, SMS messages, emails, voice calls or software certificates.
I am fully supportive of using MFA for any remote access, especially right now during a pandemic with so many of us still working from home. It is not necessarily just about your connection to the office, but also about your connectivity to remote services, and cloud-based services can be considered in this category as well. At a minimum, I recommend implementing MFA for remote access and we’re often connecting from places of questionable security like our home offices.
Before you question my mention of home offices, can you say that your home office is as secure as your corporate office? In some cases, it may be but think about it. You connect to a consumer-grade wireless network that doesn’t secure access with certificates or another device-level authentication. You probably have several non-work-related devices connected to the web like home theatres and “smart” home tech. Then there are all the other members of your household connected to the network doing goodness knows what. That, and we often work on content for a business that nobody outside of the company needs access to.
Maturity Level 2: Multi-factor authentication is used to authenticate all users of remote access solutions. Multi-factor authentication is used to authenticate all privileged users and any other positions of trust. Multi-factor authentication uses at least two of the following authentication factors: passwords, Universal 2nd Factor security keys, physical one-time password tokens, biometrics, smartcards or mobile app one-time password tokens.
I’m also very supportive of this maturity level as it now adds “privileged users and any other positions of trust”. That is often viewed as administrators, but should also include those with access to finance or HR data and senior executives that yield a lot of power along with their executive assistants. Your position within the company should not grant you security exemptions. If anything, additional security controls should be used. No matter the power we wield, we are still human and can make mistakes. MFA may be the safety net needed.
Interestingly, as the levels of maturity increase, the options for MFA seem to decrease. At level 2, we remove SMS Messages, Voice Calls, and Software Certificates. Removing SMS makes sense, although so many “secure” applications seem to still use it. Voice calls can be subject to vishing, although I’m of a mixed opinion about removing software certificates as they can always be pretty secure when done right.
Maturity Level 3: Multi-factor authentication is used to authenticate all users of remote access solutions. Multi-factor authentication is used to authenticate all privileged users and any other positions of trust. Multi-factor authentication is used to authenticate all users when accessing essential data repositories. Multi-factor authentication uses at least two of the following authentication factors: passwords, Universal 2nd Factor security keys, physical one-time password tokens, biometrics or smartcards.
Level 3 goes a step further and applies MFA to important data repositories. What constitutes “important” is subjective but clearly, it is valuable information, so I’d venture it is sensitive data like medical or highly-sensitive personal information. It can also be valuable intellectual property, and other data not intended for more than a select few individuals, groups, or organisations. It requires more overhead to implement and maintain but can be worth the investment. It’s kind of how your Personal Vault functions within your Microsoft OneDrive account and guarded by another layer of defence.
As is the case for maturity level 2, additional elements for MFA have been removed like mobile app one-time password tokens. Considering how popular apps are like Microsoft Authenticator and Google Authenticator, it will be interesting to see how businesses achieve level 3 maturity is these options are not permitted.
Beyond Level 3: Venturing beyond level 3, maturity for MFA can become too complicated for many of us and create too much cost and overhead. While it may sound secure in principle by adding an extra layer of defence in more places, it can quickly become too cumbersome to manage and create too much user resistance. People are very inventive at creating work-around to accomplish what they want to do. I would suggest consulting with experts to ascertain the best placement of MFA within your environment to balance the security with usability and functionality.
Maturity Level 0: Very rare is the occasion where I encounter an environment where absolutely nothing is backed up, but they are out there. It scares me to think an entire business could cease to exist with something as simple as a computer crash or a hard drive failure. Thankfully, for the cost these days, cloud storage is an option although we must be aware that not everything we put into the cloud is backed up by default; always verify this with your cloud services provider. Even things like replication to another computer, to another datacentre, or even using the old-school removable media method can get you a level 1 maturity level.
Individuals are appalling when it comes to backing up their data. Bad things can and do happen to personal tech, so please always back up your devices. In this regard, also make sure anything work-related you use remains stored in a location that is backed up by the business. That and the company must ensure it reviews what it backs up, from where, and why.
Maturity Level 1: Backups of important information, software and configuration settings are performed monthly. Backups are stored for between one to three months. Partial restoration of backups is tested on an annual or more frequent basis.
This level of maturity is not difficult to achieve, and the debate becomes what is “important”. You will have to sort that out, but in essence, it’s the data you need to function and be profitable. You should also ensure that you backup your infrastructures like the configuration of network devices, snapshots of servers, mobile devices, and more. Even if you preserve your data, without a system to run it on, it becomes useless. Downtime isn’t always about the tie to restore the data, but also the environment it runs in. Monthly backups may be too much of a stretch, but at least it’s a start. It’s also probably OK for an environment that doesn’t change much.
The other points include data retention, and we often find we need something from some time ago for reference or because we just didn’t need it until now. Figuring out what is essential is just as critical as how long to hang on to it. How often have you disposed of a part that was just laying around only to find that you need it once it’s gone?
And for what it’s worth, test your backup solution. You need to know the data will be there when it must. It’s also an excellent way to figure out if you’re missing anything that should be backed up. An attack vector I have seen is to disrupt backups or replicas so that when the primary is attacked, the backup is invalid or non-existent.
Maturity Level 2: Backups of important information, software and configuration settings are performed weekly. Backups are stored offline, or online but in a non-rewritable and non-erasable manner. Backups are stored for between one to three months.
Full restoration of backups is tested at least once. Partial restoration of backups is tested on a bi-annual or more frequent basis.
Maturity level 2 increases the frequency from monthly to weekly, but we may find that even that is not enough to adequately capture all our essential information. Even losing a week of work can be catastrophic, let alone a month! Storing data offline is still pretty standard, but I don’t know too many people who always “take the tapes home at night”. Instead, it’s more likely contracted to a data storage specialist who keeps them in a secure facility and facilitates the media rotation. I am starting to see more use of read-only replicas at a separate datacentre or in the cloud, which can be as effective and more readily available when needed.
Interestingly, full backups should be tested at least once at this level, but I would push for full backups tested at least annually. As the world changes, so do our need for disaster recovery and business continuity solutions. Partial restoration bi-annually should be possible for most of us, so maturity level 2 should be reasonably achievable if we’re not there already (and many I have assessed positively are)
Maturity Level 3: Backups of important information, software and configuration settings are performed at least daily. Backups are stored offline, or online but in a non-rewritable and non-erasable manner. Backups are stored for three months or greater. Full restoration of backups is tested at least once when initially implemented, and each time fundamental information technology infrastructure changes occur. Partial restoration of backups is tested on a quarterly or more frequent basis.
Maturity Level 3 makes good sense by pushing for daily backups, especially for a busy environment with a lot of data and changes. Again, offline storage is mentioned, but retention increases to beyond three months. Many I have spoken with maintain backups for years and, depending on your obligations for record retention, it may have a defined time that may extend up to a decade or more. Always be aware of your data retention obligations.
Testing backups after changes is always a good idea as the changes may impact what and how much data is backed up, where it is stored, and when it is backed up. Always be sure to align and adjust your backup (and by extension, DR/BCP) whenever you make changes. Quarterly testing is a good idea, and, if you have the time and resources, even monthly.
Beyond Level 3: Achieving a maturity level beyond 3 with backups is possible if you start including systems and services beyond servers and workstations, like network device configuration (or even backups of virtual appliances) plus Internet of Things (IoT) devices. For organisations with OT systems, be sure that this data is backed up and given the same criticality OT devices themselves have. I would suggest speaking with backup and disaster recovery experts about the best way to safeguard your systems and data. Anything can (and does) happen and as we move to be an increasingly digital population failing to preserve our data can quickly cease or very existence in all but the most basic analogue sense.
Overall, achieving a level of maturity against the ACSC Essential Eight is undoubtedly possible, and is often achievable by leveraging the technology you already own. There is no such thing as an all-in-one Essential Eight Solution” because of its part of a greater Information Assurance Ecosystem composed of technical and administrative controls. The Essential Eight is not the be-all and end-all of your cybersecurity journey, but its adoption and alignment is a great start. Ask the right questions and get the right people involved. We’re always happy to help
Stay safe out there.
Disclaimer: The thoughts and opinions presented on this blog are my own and not those of any associated third party. The content is provided for general information, educational, and entertainment purposes and does not constitute legal advice or recommendations; it must not be relied upon as such. Appropriate legal advice should be obtained in actual situations. All images, unless otherwise credited, are licensed through Shutterstock