Peter A Clarke

Multi factor authentication is a critical part of any cyber security. While it is becoming standard with many larger organisations it is poorly understood and even more poorly implemented. The National Institute of Science and Technology (“NIST”) has released a report on multi factor authentication for Criminal Justice Information Systems. Very specific perhaps but the contents of the report have a broader application.

The abstract provides:

Most recent cybersecurity breaches have involved compromised credentials. Migrating from single-factor to multi-factor authentication (MFA) reduces the risk of compromised credentials and unauthorized access. Both criminal and noncriminal justice agencies need to access criminal justice information (CJI); to reduce the risk of unauthorized access, the Criminal Justice Information Services (CJIS) Security Policy now requires the use of MFA when accessing CJI. This document provides practical information to agencies that are implementing MFA, reflecting on lessons learned from agencies around the country and from CJI-related technology vendors.

The report is worth reading.  Some interesting statements:

• In 2024, 46% of public safety breaches involved stolen credentials.
• MFA is a common security control used to reduce the risk of compromised credentials and unauthorized access. Traditional single-factor authentication relies solely on passwords, whereas MFA requires more than one distinct type of authentication factor for successful authentication. So, if an attacker obtains a user’s password, they still need access to the additional factor to successfully authenticate
• Though MFA enhances security, there are both monetary and user friction costs to MFA implementations. Single sign-on (SSO) and identity federation are technologies that support MFA deployments and can alleviate costs by reducing the number of credentials a user needs to manage, reducing the number of times a user needs to authenticate, and allowing users to reuse a single authentication to get access to multiple applications and/or resources
• One major aspect of deploying MFA technology is the impact on user experience and expectations. Any change in the way users authenticate can result in user friction.
• Single Sign On is also a great way to enable MFA. Applications that do not natively support MFA can be integrated with an SSO service, improving security and reducing the number of credentials users need to manage
• One important differentiator among various types of MFA is the ability for the authenticator to resist phishing attacks. Phishing attacks attempt to lure a user (usually through an email) into interacting with a counterfeit webpage or application and trick the user into revealing information (typically passwords or one-time codes) that can be used to masquerade as that user to the real web page or application
• Phishing attacks are a significant cybersecurity challenge, as they are often conducted remotely and at scale, meaning that an attacker may send a phishing email to thousands of employees, needing only to trick a single employee into providing their login information to gain unauthorized access to data and/or applications. Phishing-resistant authentication systems do not require the user to recognize an attack and make the right decision, but rather have phishing resistance built into the authentication protocol itself
• When deploying an MFA solution, agencies should ensure that the MFA implemented is integrated with the application or service that contains CJI. For example, if MFA is enforced only at the network level, such as a VPN service, but not at the application level, users might have to manage two separate credentials, MFA for the VPN and a username and password for the application. Moreover, if the application is only protected by a password, even if MFA was completed to gain network access, the application itself might be at risk of phishing attacks or a password database breach if a bad actor obtains network access. This “crunchy outside, soft inside” security model is not recommended. Ideally, CJI applications would be tied into an SSO service or directly integrated with an identity service such that the MFA completed at the network level can be enforced at the application level.
• Before implementing any MFA solution, it is critical that agencies understand the common use cases and corner cases of the user population the MFA solution is intended to support
• As with any technology change, implementing an MFA solution will result in both users and administrative staff needing support as they become familiar with new processes. Agencies should establish appropriate communication channels for their user base to work with internal IT support and/or MFA vendors to help answer questions and troubleshoot problems. Agencies should expect an initial increase in IT support and help desk calls after MFA has been deployed. Help desk and support staff should be trained to assist users with the technology, and clearly communicated processes should exist for escalating difficult cases, including processes for bringing in vendor support
• Compliance teams should be engaged early and often during any MFA deployment. Despite commonality in architectures and underlying requirements, each agency implementing MFA will likely undergo a unique process of determining how their specific MFA implementation meets compliance requirements
• Agencies should work with technology vendors, including identity service providers and message switch, VPN, and CAD/RMS vendors, to determine how they can best support an MFA solution that meets agency requirements. For any vendor offering an MFA solution, agencies should request a demonstration of the solution and all available authenticator types
• As with most technology deployments, MFA is best deployed in phases
• Agencies should consult with their vendor to determine which authenticator types—including phishing-resistant authenticators—are supported, as well as which identity federation protocols the vendor can implement
• When deploying an MFA solution, consider where users might get authentication, credential lifecycle management, and identity assertion issuance services from. In other words, decide where the IdP resides in the overarching MFA architecture, who owns and operates the IdP, and which of the services it will provide
• consider MFA architectures that minimize the number of separate MFA credentials that need to be issued to users and managed
• Consider solutions that do not require passing memorized secrets across networked systems and amongst applications. Token-based systems such as Kerberos and identity federation protocols are viable options for integrating CJI applications and/or services with other applications and identity services
• In general, seek to implement MFA once and then layer on supporting technologies such as identity federation or SSO to extend the value of that initial MFA implementation. Choosing to implement MFA at multiple points in the architecture could result in increased technology costs as well as an increased burden on users who need to manage and utilize multiple MFA credentials