Below are steps you can follow to identify which systems would most benefit from configuring MFA.
Identify ways users can authenticate
Review the systems your organisation uses to understand the different ways a user can authenticate. This will help you identify:
- what systems are being used
- who uses them (for example all staff, or administrative IT staff)
- how they are accessed (for example internet accessible, or internal network only)
- if MFA is needed.
You should prioritise setting up MFA for high-risk systems, such as internet-facing systems and administrative systems.
Internet-facing systems are reachable over the internet and are considered high risk because anyone can attempt to authenticate. This includes systems that all staff use such as:
- version control and code repositories (like GitHub)
- social media
- cloud services.
Administrative services are used to manage your organisation’s software or hardware, such as internet-exposed services like SSH and RDP. Access to these systems should be limited to your system administrators or IT teams.
If you're implementing MFA in an organisation with a lot of systems, focus on getting these high risk systems protected. Then consider the rest. You also want to consider any regulations or standards that may require you to have MFA configured, such as PCI standards.
Once you have identified the systems that need MFA, check if it is available. If you are a user of a system and have no control over authentication configurations, you will be reliant on the system owner or vendor providing this functionality. This is the case for most cloud services. If you manage the system and have control over authentication configurations, you will have to implement your own authentication module to handle new methods of authentication.
If systems you currently use don't support MFA, consider your alternatives. Look for other solutions that meet your business needs and also support MFA. This should be a requirement of any new cloud service you procure.
Work out which of the methods available fit your needs best. The methods fall into three categories:
- Something you know – This includes things like passwords, passphrases, PINs, or knowledge-based questions. On their own, these are weak forms of authentication as an attacker can steal a copy of it. They are usually easy to guess, where people use default or commonly used passwords, or easy to find, where people use non-unique or poorly stored/written down passwords.
- Something you have – This includes hardware devices that store keys, provide one-time passwords (OTP), or produce push notifications. There are multiple options, listed below in preferred order:
- universal 2nd factor (U2F) security key devices (like a YubiKey)
- smartphone apps that provide a user with an approve/deny push notification.
- key fobs that generate a OTP
- smartphone apps that generate a OTP
- Something you are – This includes biometric checks, such as fingerprint or face scans. This type of authentication is gaining popularity, especially with the latest smart phones from Samsung and Apple. This relies on the accuracy of the biometric scan and the uniqueness of the values and is not a secure authentication method on its own (single factor).
Which methods are available to you depends on who manages the system and what configurations they have available.
Enabling it on systems you use
If you’re a consumer of a system, you will need to enable MFA. Ask the system owner or vendor what MFA methods are available, for example Google Accounts offers OTP over smart phone app, push notifications to smart phone, and U2F. In some cases, you could also set up policies for your organisation’s account that forces all users to use MFA on their individual accounts.
Some systems may not have MFA available, and you should re-consider using the system as MFA configurations would have to be implemented by the system owner or vendor.
If there are several methods available to use, avoid ones that are easy to bypass, like OTP over SMS. If weaker authentication methods are your only option, it’s better than not having MFA at all. This is because the situation presents two different risks. For example, with OTP over SMS:
- Risk that an attacker gets unauthorised access to your account because they were able to brute force your password. This is an attack that is easy to automate and is low cost/low effort to an attacker. Using OTP over SMS removes you from the “low hanging fruit” pool of users.
- Risk that an attacker gets unauthorised access to your account because they are able get your OTP and your password. They can do this by identifying the number the gets the SMS notifications and attempt to transfer that phone number to a SIM card under their control. This is an attack that is more targeted and requires more time/effort from an attacker.
OTP that need to be entered into a system are not flawless as it requires you to transpose the number from your device to the system. Attackers can use phishing pages or social engineering in attempt to get this OTP from you.
Before setting a policy that forces MFA across the system, make sure the users are notified and prepared. Most systems have how-to guides online to make this process easier. If you provide the information and explanation to your users upfront, it will make the implementation process easier for everyone. It will also allow you to address any concerns they may have upfront, such as use of a personal phone for using work-related apps or security concerns if their phone is lost.
Enabling it on systems you manage
If you manage the system, you likely have the ability to configure and change the authentication methods used. This is likely the case for any administrative services you use. This process would include:
- Deciding on the type of MFA method you want to use and researching the available authentication modules. There are a number of pluggable authentication modules (PAM) and guides available online if you want to use security key devices or smart phone apps. There could be costs involved, including hardware devices or app subscriptions, which also need to be considered with the technical, infrastructure requirements.
- Hardening the servers. When implementing any authentication modules, make sure the infrastructure used is hardened to remove unused ports, services, and accounts and to add any missing patches. More details about these can be found in our other critical controls.
- Configuring logs. Authentication and server logs should be configured and sent to a central log server. The data in these logs can provide valuable information about the security of your authentication server and your users. More details about this can be found on our advice on configuring critical controls.
Monitor use of MFA
After you have MFA configured on all your prioritized systems, it is important to configure monitoring. The logs should be sent to a central logging server and alerts configured to track potential security incidents. These logs can help with:
- Unauthorised access – At a minimum you should be logging and alerting on any authentication failures. This could include multiple failed OTP attempts or denied push notifications. Some authentication logs will allow you to see where the user is authenticating from. Alerts can be configured to help identify logins form suspicious or unusual locations.
- Uptake and use – If your users can enable MFA configurations themselves, this will allow you to see how many users have it configured and which users may have accidently or intentionally turned it off.