Multi-factor authentication and verification

When logging into systems or performing high value transactions, it is important to authenticate and verify the action or request is coming from the right person.

Summary

CERT NZ sees many incidents where attackers social engineer their way to money, data, and access. One of the most common incidents is invoice scams, which can have a 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. 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.

Purpose

Additional verification is required when authenticating to business-critical systems (such as administrative or internet-facing accounts), and when carrying out sensitive requests (such as payment and data changes).

Measuring 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 broke 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 Multi-Factor Authentication | NIST.
    National Institute of Standards and Technology (NIST) External Link
  • 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

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

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 methods available, 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), 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.

Advice for implementation

There are two implementation guides for this control. One is focused on technical implementation of MFA on IT systems, the other around verification of sensitive business processes.

Implementing multi-factor authentication

Implementing business process verification