Hi everyone, today we’re doing a deep dive into each of the Essential 8, how we can address each point at each maturity level and why this is such an incredibly important tenet of Cybersecurity. We also discuss how investing in regular backups now can be a preventative measure for recovering from a Cyber Attack. Let’s get stuck into it!
Maturity Level 1 (ML1)
ML1, ML2 and ML3 are 4 key points with the key differences between each maturity being at points 3 and 4. For ML1, they are as follows.
- “Backups of important data, software and configuration settings are performed and retained in a coordinated and resilient manner in accordance with business continuity requirements.”
- “Restoration of systems, software and important data from backups is tested in a coordinated manner as part of disaster recovery exercises.”
- “Unprivileged account can only access their own backups.”
- “Unprivileged accounts are prevented from modifying or deleting backups.”
1. Gathering your requirements
A few key terms that will get thrown around really stem from business requirements, but knowing what the jargon is, is going to be key in determining the risk appetite for the organisation.
The most important thing to note when discussing retention is how much should you keep. When looking into this, you must consider that a system is usually compromised 190 DAYS prior to the noticed attack on the system. That means if you have less retention than half a year, then you are vulnerable to complete and total data loss or paying the ransom on a cyber security event. Implementing a 3-2-1 Strategy (3 Copies of your data, 2 different forms of media, 1 offline (or WORM)) coupled with a GFS Backup can quickly increase retention of your backups without breaking the bank.
RPO – Recovery Point Objective
This is how much data an organisation can tolerate losing in any single event. For instance, if the RPO is 24 hours, then the organisations backups must run successfully every 24 hours to ensure in the event of a critical failure or ransomware attack we can recover from a restore point no more than 24 hours ago.
RTO – Recovery Time Objective
The is how quickly a full recovery operation must be able to complete. For instance, if the RTO is 48 hours, then the organisations backups and available recovery equipment must be available and able to be recovered within a 48-hour time frame. Coupled with the RPO, the organisation is looking at 3 days outage. The recovery effort may actually only be an agreed percentage of the organisation allowing it to run in a reduced capacity if that better suits organisational requirements.
MTD – Maximum Tolerable Downtime
In the RTO example above, we’re already at 3 days outage, the MTD would be how long the business can reasonably exist post Business Continuity or Disaster Recovery event without any ongoing irreparable event. So, if the MTD is 5 days, the RPO and RTO must meet objectives less than 5 days under all circumstances.
SLE – Single Loss Expectancy
The SLE is how much a single event may cost an organisation in recovery costs, e.g. If the server failed and wasn’t under warranty, then it could reasonably cost the value of the replacement physical hardware to recover. If your regular backups were in Azure for quick recovery, engaging the cloud services will begin a metered service that will carry associated costs while the systems are actively consuming Azure compute resources.
ARO – Annualised Rate of Occurrence
The ARO is how often a full backup recovery event might need to occur. You make a reasonable prediction on a complete or partial failure, e.g., 1 every 2 years and multiply that by your SLE – e.g., 0.5xSLE (e.g., 50,000) then that’s $25,000 per year that would reasonably budget into protecting your data.
2. Testing of Backups
Backup tests should be tested on implementation of a new Virtual machine (or physical) and tested monthly (e.g., Single VM restore, or File Level restore) – Tabletop Scenario run through every quarter, Parallel backup recovery (and process) should be tested every 6 months, and a full Disaster Recovery event should be tested Annually. This is a process change, and does take time, however it’s worth mentioning that an untested backup is like Schrodinger’s cat, in a pinch you want to be able to recover your data and have reasonable certainty it’s working.
3. Unprivileged Accounts can only access their own backups.
Backup systems to gather all the detail of systems connected to it, usually run from a privileged account. With that said, any time a backup job and recovery points are created, the unprivileged account is only able to create their own new jobs and can only recover data from that job.
4. Unprivileged Accounts are prevented from modifying or deleting backups.
Here is the first of a recurring theme, backups jobs and restore points cannot be deleted by the account that can create them. This change is a simple security permission change, but very important to make.
Maturity Level 2 (ML2)
Points 1 and 2 from ML1 continue to apply at all maturity levels of the Essential 8 and so will not be mentioned again. The differences from here lie within the last 2 points – I’ll highlight the key phrasing changes at each level.
- “Unprivileged accounts, and privileged accounts (excluding backup administrators), can only access their own backups.”
- “Unprivileged accounts, and privileged accounts (excluding backup administrators), are prevented from modifying or deleting backups.”
1. …and privileged accounts (excluding backup administrators) can only access their own backups.
This control extends to those privileged accounts that aren’t configured for the backup administrator role. This moves towards a Role Based Access Control (RBAC) system, where the minimum required privileges are applied at each level. Again, we see only create and restore permissions being granted to users, with the Backup Administrator being the one in control of modification and deletion. Daily backups shouldn’t be completed by a person with backup administrator privileges, the cached credential could be enough for an attacker to compromise the backups.
2. …and privileged accounts (excluding backup administrators) are prevented from modifying or deleting backups.
We prevent the modification or deletion of jobs to that of the backup administrator role. This ensures that accidental deselection of jobs cannot happen, but also means that an intruder has an additional hoop to jump through before compromising the regular backups. More layers of defence are vitally important to a security posture.
Maturity Level 3 (ML3)
Points 1 and 2 from ML1 & ML2 continue to apply at all maturity levels of the Essential 8 and so will not be mentioned again. The differences from here lie within the last 2 points – I’ll highlight the key phrasing changes at each level.
- “Unprivileged accounts, and privileged accounts (excluding backup administrators), cannot access backups.”
- “Unprivileged accounts, and privileged accounts (excluding backup BREAK GLASS ACCOUNTS), are prevented from modifying or deleting backups.”
1. …and privileged accounts (excluding backup administrators) cannot access backups.
A read only account is configured to check backups, and only a backup administrator account can be used to create new backup jobs.
2. …and privileged accounts (excluding backup break glass accounts) are prevented from modifying or deleting backups.
Secure the ability to modify or delete a backup under a specialist account, and then disable the account by default.
The perhaps easiest to understand and implement part of the essential 8. Backups are a core best practice of Information Technology and have been for years. With the emergence and prevalence of RANSOMWARE it really is the best way to ensure data and business continuity and can drastically reduce the impact of availability scenarios – combining the above backup processes with robust Data Classification and Data Archival policies and procedures can reduce those RTO times significantly.
With all of this said and done, it’s really just administrative processes – at a board level, the assurances offered by implementing strong governance and retention meeting industry requirements that will help put many a mind at ease.
For deeper discussions and guidance through your Business Continuity and Disaster Recovery requirements, please reach out to Calibre 1 – we’re happy to facilitate all shapes and sizes and tailor the most appropriate solution for you.