Implementing multi-factor authentication

Below are steps you can follow to identify which systems would most benefit from configuring MFA.

Identify your organisation’s high risk systems

The first step of implementing this control is to understand what systems your organisation uses, so you can prioritise the ones that involve sensitive data, access, or financials.

For identifying your high risk systems, you will need to identify:

• what systems are being used
• who uses them (for example internal staff, internal administrators, or external customers and clients)
• how they are accessed (for example internet accessible, or internal network only)
• what data is kept in these systems (for example personal information, customer or payment data)
• who manages the system (for example it is developed and managed by your organisation, or it is a SaaS-type model)

The systems that hold sensitive data, are used by administrator-level users or are accessible over the internet. These should be prioritised on your list for MFA. To get you started, that list should include:

• VPN
• Webmail
• Financial systems
• Critical business applications
• Version control and private code repositories
• Social media
• Cloud services (for example services that are used to manage infrastructure or document storage)

Once you have a prioritised list of systems that require MFA, you will need to check if it is configurable. If it is a SaaS-type system, you are a user of a system and have no control over authentication configurations. You will be reliant on the vendor providing this functionality. 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.

Configure an additional level of authentication

Configure an additional level of authentication. Once you have a list of your systems, you can start configuring MFA based on those with higher risk.

When you configure MFA, you will usually find a few options. It will be important to pick an option that has a high-level of security, usability, and fits your needs. The methods available usually fall into three categories. We recommend the two methods you use come from different 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 (For example, FIDO2 leverages common devices for authentication, like authenticating via a biometric input on your mobile device) FIDO2  External Link
  • 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. 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 options that system supports.

Enabling MFA on systems you use

Using MFA will protect you when using various accounts or systems. Check with the system owner or vendor what MFA methods are available. You can even go the extra mile and request MFA  is set up for each individual account. This becomes important for critical systems such as your main identity provider accounts (like Microsoft 365 or GSuite).

If a system doesn’t provide MFA, a second option could be to integrate the system with your main identity provider. This is especially the case for Software-as-a-Service (SaaS) systems that allow for Single Sign-On (SSO), rather than MFA. This way you can have MFA set up for your main SSO identity provider, and add extra protection to your SaaS accounts.

More details and benefits of using a central identity provider

Some systems may not have MFA or SSO configurations available.  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.

1. Risk 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.
2. Risk 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 that receives the SMS notifications and attempt to transfer that number to a SIM card under their control. This is an attack that is more targeted and requires more time and effort from an attacker.

A OTP that needs to be entered into a system is 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 an attempt to get this OTP from you.

Enabling MFA on systems you manage

If you manage the system, it’s likely that you have the ability to configure and change the authentication methods used. This may be the same for any administrative services you use. This process would include:

1. 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.
2. Hardening the servers. When implementing any authentication modules, make sure the infrastructure used is hardened to remove unused ports, services, and accounts and add any missing patches. More details about these can be found in our other critical controls.
3. 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.

Centralised logging

CERT NZ's Critical Controls

Report and monitor security events

After you have a second-level of authentication in place for your prioritised systems, it is important to perform monitoring.

Your systems and authentication servers should send logs to a central logging server, and alerts should be configured to track potential security incidents. These logs can help with:

• Unauthorised access. At a minimum you should log and alert 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 from 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 accidentally or intentionally turned it off.