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.
Nestled low on the Essential Eight list is a control that we’d put right at the top. We often joke that if everybody did multi-factor authentication, we’d be out of a job – and like all good humour, it contains a sizeable element of truth. Done well, multi-factor authentication makes life very hard for hackers.
So, why is multi-factor authentication (MFA) such a key area? The truth is, humans are not very good at creating and recalling passwords. In today’s increasingly digital age, we’re expected to create an enormous amount of passwords, and thus we aren’t likely to remember each one. People tend to reuse passwords, follow a theme, or write them down. How many of you are looking at a post-it note of passwords stuck to your monitor right now? And once we have a password firmly established in memory, we really don’t like to change it.
Those passwords, the easily remembered and the unchanged since 2010, are often compromised. They end up in databases of email addresses and passwords on the dark web, where hackers can buy them and try their luck. If you’re feeling brave, you can visit https://haveibeenpwned.com/ to learn if your email address or mobile number has been involved in a hack, to see if your passwords are on those databases, and to explore just how big the problem has become.
MFA makes those databases far less useful to hackers – not only do they need to know something (the email and password combination), but access is also dependent on something you have or something you are. This is the trifecta of a perfect MFA strategy; users should authenticate with two of the following three attributes:
We have a couple of critiques on the controls for MFA, so let’s get stuck in the maturity model.
“Multi-factor authentication is used by an organisation’s users if they authenticate to their organisation’s internet-facing services.”
You won’t be surprised that first off the rank in terms of MFA maturity is securing internet-facing services. Of course, they tend to carry the highest risk so it’s best to address these first. Your VPNs and remote access environments, cloud services from non-corporate networks – are all a likely first port of call for any malicious actor looking for an opportunity, much like a car thief will check the doors of your shiny new set of wheels before they attract attention by smashing a window.
Whichever way a user accesses your environment, you want them to use MFA at least once.
“Multi-factor authentication is used by an organisation’s users if they authenticate to third-party internet-facing services that process, store or communicate their organisation’s sensitive data.”
Prioritising sensitive data is also logical. It is important to be clear within your organisation about what is considered sensitive data and where it resides.
There are multiple options for implementing MFA. When considering MFA for sensitive data, rather than use authentication services from third-party SaaS providers like Google Authenticator, your organisation should consider authenticating users internally via federated identity. This causes less interruption to users and reduces the chance of people creating increasingly weak passwords in an effort to remember them all.
“Multi-factor authentication (where available) is used by an organisation’s users if they authenticate to third-party internet-facing services that process, store or communicate their organisation’s non-sensitive data.”
This control is the same as the last, however it addresses non-sensitive data traversing third-party, internet-facing services.
I do find the inclusion of “where possible” interesting. It’s worth pointing out that some legacy applications won’t directly support MFA, but there are ways to work around this, such as cloaking the app to wrap MFA around it or by only enabling access when users are connected to VPN.
“Multi-factor authentication is enabled by default for non-organisational users (but users can choose to opt out) if they authenticate to an organisation’s internet-facing services.”
Ideally, you want all users to be protected – organisational and non-organisational, and if MFA is the default setting, most are far more likely to leave it in place.
What are some types of non-organisational users that warrant MFA?
In fact, we were doing an Essential Eight assessment in a school recently and we had discovered that their parent portal was secured by a username and password only. This meant that their system that stores sensitive data about children and their families, was one of the weak points of the organisation’s security. It can often take a fresh pair of eyes and the opportunity to focus outside the day-to-day tasks of the IT department to pick up on such oversights.
“Multi-factor authentication is used by an organisation’s users if they authenticate to their organisation’s internet-facing services.”
(As above, ML1) You won’t be surprised that first off the rank in terms of MFA maturity is securing internet-facing services. Of course, they tend to carry the highest risk so it’s best to address these first. Your VPNs and remote access environments, cloud services from non-corporate networks – are all a likely first port of call for any malicious actor looking for an opportunity, much like a car thief will check the doors of your shiny new set of wheels before they attract attention by smashing a window.
Whichever way a user accesses your environment, you want them to use MFA at least once.
“Multi-factor authentication is used by an organisation’s users if they authenticate to third-party internet-facing services that process, store or communicate their organisation’s sensitive data.”
(As above, ML1) Prioritising sensitive data is also logical. It is important to be clear within your organisation about what is considered sensitive data and where it resides.
There are multiple options for implementing MFA. When considering MFA for sensitive data, rather than use authentication services from third-party SaaS providers like Google Authenticator, your organisation should consider authenticating users internally via federated identity. This causes less interruption to users and reduces the chance of people creating increasingly weak passwords in an effort to remember them all.
“Multi-factor authentication (where available) is used by an organisation’s users if they authenticate to third-party internet-facing services that process, store or communicate their organisation’s non-sensitive data.”“]
(As above, ML1) This control is the same as the last, however it addresses non-sensitive data traversing third-party, internet-facing services.
I do find the inclusion of “where possible” interesting. It’s worth pointing out that some legacy applications won’t directly support MFA, but there are ways to work around this, such as cloaking the app to wrap MFA around it or by only enabling access when users are connected to VPN.
“Multi-factor authentication is enabled by default for non-organisational users (but users can choose to opt out) if they authenticate to an organisation’s internet-facing services.”
(As above, ML1) Ideally, you want all users to be protected – organisational and non-organisational, and if MFA is the default setting, most are far more likely to leave it in place.
What are some types of non-organisational users that warrant MFA?
In fact, we were doing an Essential Eight assessment in a school recently and we had discovered that their parent portal was secured by a username and password only. This meant that their system that stores sensitive data about children and their families, was one of the weak points of the organisation’s security. It can often take a fresh pair of eyes and the opportunity to focus outside the day-to-day tasks of the IT department to pick up on such oversights.
“Multi-factor authentication is used to authenticate privileged users of systems.”
It would be nice to think that admins with access to your databases are infallible, alas they are in fact human, and they unfortunately make mistakes. The stakes are higher with admin access, and we’d argue that this control should be included in Maturity Level One, as it’s an absolute essential.
“Multi-factor authentication uses either: something users have and something users know, or something users have that is unlocked by something users know or are.”
This is another control that we would argue should be in Maturity Level One, as this describes true MFA. It is important to be clear that some technologies often referred to as multi-factor authentication don’t truly fit this criteria. For example, there are blurred lines between something you have and know when it comes to codes sent via SMS or email, both of which can be compromised. Truly, if you want to do MFA, this is the starting point.
“Successful and unsuccessful multi-factor authentications are logged.”
Again, another very basic control. All authentications, successful or not, should be in your logs anyway.
“Multi-factor authentication is used by an organisation’s users if they authenticate to their organisation’s internet-facing services.”
(As above, ML1) You won’t be surprised that first off the rank in terms of MFA maturity is securing internet-facing services. Of course, they tend to carry the highest risk so it’s best to address these first. Your VPNs and remote access environments, cloud services from non-corporate networks – are all a likely first port of call for any malicious actor looking for an opportunity, much like a car thief will check the doors of your shiny new set of wheels before they attract attention by smashing a window.
Whichever way a user accesses your environment, you want them to use MFA at least once.
“Multi-factor authentication is used by an organisation’s users if they authenticate to third-party internet-facing services that process, store or communicate their organisation’s sensitive data.”
(As above, ML1) Prioritising sensitive data is also logical. It is important to be clear within your organisation about what is considered sensitive data and where it resides.
There are multiple options for implementing MFA. When considering MFA for sensitive data, rather than use authentication services from third-party SaaS providers like Google Authenticator, your organisation should consider authenticating users internally via federated identity. This causes less interruption to users and reduces the chance of people creating increasingly weak passwords in an effort to remember them all.
“Multi-factor authentication (where available) is used by an organisation’s users if they authenticate to third-party internet-facing services that process, store or communicate their organisation’s non-sensitive data.”
(As above, ML1) This control is the same as the last, however it addresses non-sensitive data traversing third-party, internet-facing services.
I do find the inclusion of “where possible” interesting. It’s worth pointing out that some legacy applications won’t directly support MFA, but there are ways to work around this, such as cloaking the app to wrap MFA around it or by only enabling access when users are connected to VPN.
“Multi-factor authentication is enabled by default for non-organisational users (but users can choose to opt out) if they authenticate to an organisation’s internet-facing services.”
(As above, ML1) Ideally, you want all users to be protected – organisational and non-organisational, and if MFA is the default setting, most are far more likely to leave it in place.
What are some types of non-organisational users that warrant MFA?
In fact, we were doing an Essential Eight assessment in a school recently and we had discovered that their parent portal was secured by a username and password only. This meant that their system that stores sensitive data about children and their families, was one of the weak points of the organisation’s security. It can often take a fresh pair of eyes and the opportunity to focus outside the day-to-day tasks of the IT department to pick up on such oversights.
“Multi-factor authentication is used to authenticate privileged users of systems.”
(As above, ML2) It would be nice to think that admins with access to your databases are infallible, alas they are in fact human, and they unfortunately make mistakes. The stakes are higher with admin access, and we’d argue that this control should be included in Maturity Level One, as it’s an absolute essential.
“Multi-factor authentication uses either: something users have and something users know, or something users have that is unlocked by something users know or are.”
(As above, ML2) This is another control that we would argue should be in Maturity Level One, as this describes true MFA. It is important to be clear that some technologies often referred to as multi-factor authentication don’t truly fit this criteria. For example, there are blurred lines between something you have and know when it comes to codes sent via SMS or email, both of which can be compromised. Truly, if you want to do MFA, this is the starting point.
“Successful and unsuccessful multi-factor authentications are logged.”
(As above, ML2) Again, another very basic control. All authentications, successful or not, should be in your logs anyway.
“Multi-factor authentication is used to authenticate users accessing important data repositories.”
While ‘important’ is undefined in the Essential Eight, we’d say anything business critical or sensitive tops the list. For this control to be effective, you need to have visibility of all locations that data is stored, both on-premises and in cloud services.
That, of course, can be easier said than done in today’s era. There’s every chance that, along with known locations like databases, Teams and SharePoint, you have users who turn to Dropbox and similar apps. There are, then, some extra steps to this control – first, decide on a definition of ‘important data’ in your organisation; second, uncover all data repositories (if you perform an annual IT assessment, your IT partner will be able to help); and third, implement MFA to protect that data.
“Multi-factor authentication is verifier impersonation resistant and uses either: something users have and something users know, or something users have that is unlocked by something users know or are.”
This seems to be much the same as we already covered in Maturity Level Two – if someone steals the thing you know, such as a password, they are still stumped if they cannot also steal the thing you have, such as a token. If you are following these core principals of MFA, then by nature your strategy is resistant to impersonation.
“Successful and unsuccessful multi-factor authentications are centrally logged and protected from unauthorised modification and deletion, monitored for signs of compromise, and actioned when cyber security events are detected.”
If your MFA solution is properly implemented, everything will be logged, so that you can monitor for signs of compromise. And of course, you don’t want the average user to have access to edit or delete those records.
Not every unsuccessful login attempt means compromise – people forget passwords, cats walk onto keyboards at critical moments. It is worth using some simple logic here. If someone normally works from Sydney but the login attempt was from Moscow, call their boss to check if they are in the country. It might be a false positive – for example, someone put their VPN on to watch a streaming service from overseas, then forgot, so they appear to be in a different geography. Still, if that foreign login appeared only a couple of hours after a login in their usual location, there’s every chance there’s an issue, as that user simply can’t physically be in Sydney and Moscow only 3 hours apart.
User behaviour analytics aren’t mentioned in the Essential Eight, but I’d suggest this really should be a Level Three Maturity MFA control. It can be a very effective approach to filter through the many alerts.
Like any technology, multi-factor authentication is always evolving, so what worked a few years ago may no longer offer the level of security you need. Randomly generated passwords from a key fob have seen their heyday. SMS, once considered adequate in delivering a secondary authentication code, is now problematic – especially given the ease of compromising Android devices, which are full of malware. When biometric options mature, it is likely that MFA will become more seamless. There are early biometric peripherals available to enhance your MFA strategy such as the YubiKey from Yubico.
Review your MFA strategy regularly to ensure your security is top notch, but also that the user experience you offer your staff makes security as invisible as possible.
Want to know more about the Essential Eight maturity levels? Check out our other blogs, or chat with the Data#3 security practice.
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 8 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. Essential Eight Maturity Model: User Application Hardening
6. Essential Eight Maturity Model: Restrict Administrative Privileges
7. Essential Eight Maturity Model: Patch Operating Systems
8. You are here.
9. Essential Eight Maturity Model: Regular Backups