Multi-factor authentication and verification

What is MFA and business process verification?

Multi-factor authentication provides an extra level of authentication for your sensitive accounts and can protect your organisation from unauthorised access, business email compromise, and security incidents.

Business process verification is about making sure you have processes in place to verify sensitive changes, such as password resets or changing where your organisation pays money to.

One of the most common types of cyber security incidents are invoice scams, which can have high financial, operational, and legal impacts. You might be on the receiving end of these scams, or your email might be compromised and be sending these scams out without your knowledge. 

Most of the unauthorised access in these scenarios comes down to a single, weak password.

Preventing these common invoice scams, and other fraud or high value account compromises, starts with adding a second layer to your authentication and verification processes. 

This means requiring more than just a password to access your accounts, such as your email. It also means verifying high-value requests through a second channel, such as a phone call or in-person. 

Both steps allow you to validate that the request or action has come from the right person.

How to set up MFA on your critical business systems

Follow the steps below for advice on setting up multi-factor authentication (MFA) on business-critical systems in your organisation.

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.

To identify your high-risk systems, you will need to understand:

• 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), and
• who manages the system (for example, is it developed and managed by your organisation, or is it a SaaS-type model?).

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

• virtual private network (VPN) or virtual private server (VPS),
• webmail,
• financial systems,
• critical business applications,
• version control and private code repositories,
• social media, and
• 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 software as a service (SaaS) system, you 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

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,
• is easy to use, and 
• fits your needs. 

The methods available usually fall into three categories. We recommend that 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,
• key fobs that generate a one-time password (OTP), and
• smartphone apps that generate an 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 the systems you use but don’t own or manage

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.

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. The 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. The 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.

An 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 to get this OTP from you.

Enabling MFA on systems you manage

If you manage the system, it’s likely that you can configure and change the authentication methods used. This may be the same for any administrative services you use. Follow these steps to set MFA up on your managed systems.

Decide on the type of MFA method you want to use

Research available authentication modules. There are several 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.

Harden your 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. 

Configure 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. 

Centralised logging

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 people use it and who may have accidentally or intentionally turned it off.

How to implement business process verification

Business process verification is about making sure you have processes in place to verify sensitive changes, such as password resets or changing where your organisation pays money to.

Below are the steps you must consider when implementing this control.

Identify your organisation’s high-risk events

Your organisation is going to have a lot of business processes. The first step of implementing this control is to understand what processes are used, so you can prioritise the ones that involve sensitive data, access, or financials.

Start off by making a list of internal business processes that carry high risk. High risk includes any process failures that could have a large impact to your organisation, such as a payment not being received, a payment being paid into the wrong account, or loss of access to an account that holds sensitive data. One of the most common incidents you need to be on the watch for are invoice scams, where payment details are changed after an invoice is sent – causing you or your customers to pay the wrong person.

To start preparing a list of high-risk processes, you need to consider processes requested verbally, in-person, or digitally (over email or social media).

That list can include:

• requesting a password request,
• making or changing re-occurring payments,
• assigning administrative access, and
• requesting sensitive information (for example customer or employee information).

For each of these processes, you need to identify:

• who within the organisation normally carries out these actions, or who has access to perform these actions,
• what is considered normal (or business as usual) for these processes, and
• how many of these requests are received on a regular basis.

Identifying what is “normal” may require you to sit down with those process owners and talk through a few examples. For example, if your organisation receives a lot of password resets due to the size of your organisation, you will need to consider this when designing an out-of-band verification process. If you don’t design it with what normal looks like, you run the risk of creating a process that will be actively avoided so people can get on with their day-to-day jobs.

Add or design a second level of verification

Once you have a list of your processes that are important to your organisation, you can start configuring a second layer of controls based on those with higher risk.

Implementing a second level of verification is more straightforward compared to multi-factor authentication as it tends to focus less on technology and more on manual processes.

Each high-risk business process on your list will need to be re-designed to include:

• a way of contacting the requester through a different channel to verify their request,
• having an escalation point in case it can’t be verified (for example the user’s manager or system owner), and
• an incident response process if the verification process fails.

A different channel needs to be either:

• a publicly listed channel (such as a phone number listed on an official website or social media profile),
• an internal directory, or
• a private channel where you have spoken directly with someone before (such as a saved SMS or phone number in your phone).

An important step of designing this control is to test it with a small group of people first. That way you can validate how often the process must be carried out, and how much additional time it adds to the process. The wider team may need additional training or tools to perform this process and should be prioritised and rolled out before the new process gets put into place.

Monitoring and recording events

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

For your business processes, you will want to make sure that each verification failure is treated as a high priority security event and therefore needs to be actioned quickly.

Once an incident is recorded, the response steps should include:

• letting anyone else who performs the process know about the request event (in the event it happens again), and
• flagging the request with the system or process owner so they can take any additional actions (such as flagging the user account or contacting the bank).

How to measure success

There are multiple ways to configure multi-factor authentication (MFA) for your systems, and a two-step verification process may look similar across organisations. 

We have split the goals of this control down into two areas, systems and business processes.

Systems

• All internet-facing, administrative services, and other business-critical systems require users to enable MFA to access the system. Users are not able to access these systems without MFA.
• The MFA methods you use don't have known vulnerabilities and aren't deprecated by standard setting bodies, such as the National Institute of Standards and Technology (NIST).
• For systems your organisation owns and manages, the MFA authentication module you use is kept up to date. Any related dependencies of the module are also kept up to date. The infrastructure the module runs on is hardened (unused ports are blocked and it is patched).
• Logs are recorded and stored in a central location to capture:
  • changes to MFA configurations and policies, and
  • suspicious, denied, or bypassed authentication attempts.

Business processes

• You know which teams or people in your organisation receive external requests, or have access to data, to make payment or to make changes.
• You have a process that these internal staff follow to verify all requests in a separate communication channel before they are made.
• You report and record all security events and unauthorised requests as part of your organisation's security incident management process.
• You communicate attempts at scams or fraud to other staff so they can be on the lookout for similar activity.
• You communicate attempts at scams or fraud to other staff so they can be on the lookout for similar activity.

For processes, you will want to make sure that each verification failure is treated as a high priority security event and therefore needs to be actioned quickly. Once an incident is recorded, the response steps should include:

• letting anyone else who performs the process know about the request event (in the event it happens again), and
• flagging the request with the system or process owner so they can take any additional actions (such as flagging the user account or contacting the bank).

Key takeaways

• There are multiple options when it comes to MFA, and some might not fit with how you and your employees operate. Involving your staff in the implementation process, understanding what works for them, and having them test different options is a great way to tackle training as well as drive positive engagement by having them involved from the start.
• Like onboarding staff to using multi-factor authentication, you can involve staff in implementing your business verification process to make sure it is fit for use. For example, your service desk teams will have the most experience when it comes to managing password resets. Password resets are an important process that needs to be verified before they are actioned. Your service desk team would make a great addition to a control implementation team because they can provide all the options to verify a caller's identity given the tools they have access to.
• Enforcing an additional factor of authentication to a system will depend on who manages the system. If it is a system you manage, you will have more flexibility to find a solution. If you use a third-party system, such as a Software-as-a-Service (SaaS) tool, you won't be able to change this. If there are no options available for a system that needs to have MFA, alternative systems should be considered when weighing up your options.
• Some MFA methods are easier to bypass, like codes sent by SMS, and are considered deprecated by the information security industry. Notifications sent over SMS can be intercepted and sent to an unauthorised person. If a notification by SMS is the only method available, it is better than not having it at all.
• Review the methods that are available as some are better than others. Methods using one-time passwords (OTP) through a mobile app are vulnerable to phishing or social engineering. Universal 2nd Factor (U2F) and using physical security keys is recommended.
• MFA fatigue is a tactic that attackers can use to get around this security measure. Essentially an attacker will bombard a target with MFA challenges in the hopes that the target will eventually allow the challenge to stop the notifications coming through. It is important to make users aware that if they have not attempted to log in but are prompted with MFA challenge, this could be an indication that someone is attempting to gain unauthorised access to the account and the account needs to be secured immediately.

Related information

Centralised logging

See all the Critical Controls