DISCUSSION [NIST SP 800-171 R2]

Multifactor authentication requires the use of two or more different factors to authenticate. The factors are defined as something you know (e.g., password, personal identification number [PIN]); something you have (e.g., cryptographic identification device, token); or something you are (e.g., biometric). Multifactor authentication solutions that feature physical authenticators include hardware authenticators providing time-based or challenge response authenticators and smart cards. In addition to authenticating users at the system level (i.e., at logon), organizations may also employ authentication mechanisms at the application level, when necessary, to provide increased information security. Access to organizational systems is defined as local access or network access. Local access is any access to organizational systems by users (or processes acting on behalf of users) where such access is obtained by direct connections without the use of networks. Network access is access to systems by users (or processes acting on behalf of users) where such access is obtained through network connections (i.e., nonlocal accesses). Remote access is a type of network access that involves communication through external networks. The use of encrypted virtual private networks for connections between organization-controlled and non-organization controlled endpoints may be treated as internal networks with regard to protecting the confidentiality of information.

NIST SP 800-63-3 provides guidance on digital identities.

FURTHER DISCUSSION

Implement a combination of two or more factors of authentication to verify privileged account holders’ identity regardless of how the user is accessing the account. Implement a combination of two or more factors for non-privileged users accessing the system over a network.

The implementation of multi-factor authentication will depend on the environment and business needs. Although two-factor authentication directly on the computer is most common, there are situations (e.g., multi-factor identification for a mission system that cannot be altered) where additional technical or physical solutions can provide security. Multifactor authentication is not required for access to mobile devices such as smartphones or tablets – which are not considered to be network devices or information systems.

This practice, IA.L2-3.5.3, requires multifactor authentication for network access to nonprivileged accounts and complements five other practices dealing with remote access (AC.L2-3.1.12, AC.L2-3.1.14, AC.L2-3.1.13, AC.L2-3.1.15, and MA.L2-3.7.5:

AC.L2-3.1.12 requires the control of remote access sessions.

AC.L2-3.1.14 limits remote access to specific access control points.

AC.L2-3.1.13 requires the use of cryptographic mechanisms when enabling remote sessions.

AC.L2-3.1.15 requires authorization for privileged commands executed during a remote.

Finally, MA.L2-3.7.5 requires the addition of multifactor authentication for remote maintenance sessions.

This practice, IA.L2-3.5.3, also enhances IA.L1-3.5.2, which is a requirement for a less rigorous form of user authentication.

Example

You decide to implement multifactor authentication (MFA) to improve security of your network. Your first step is enabling MFA on VPN access to your internal network [c,d]. When users initiate remote access, they will be prompted for the additional authentication factor. Because you also use a cloud-based email solution, you require MFA for access to that resource as well [c,d]. Finally, you enable MFA for both local and network logins for the system administrator accounts used to patch and manage servers [a,b,c].

Potential Considerations

Does the system uniquely identify and authenticate users, including privileged accounts [b,c,d]?38

Copyright

Copyright 2020, 2021 Carnegie Mellon University and The Johns Hopkins University Applied Physics Laboratory LLC.

Copyright 2021 Futures, Inc.

This material is based upon work funded and supported by the Department of Defense under Contract No. FA8702-15-D-0002 with Carnegie Mellon University for the operation of the Software Engineering Institute, a federally funded research and development center, and under Contract No. HQ0034-13-D-0003 and Contract No. N00024-13-D-6400 with the Johns Hopkins University Applied Physics Laboratory LLC, a University Affiliated Research Center.

The view, opinions, and/or findings contained in this material are those of the author(s) and should not be construed as an official Government position, policy, or decision, unless designated by other documentation.

NO WARRANTY. THIS MATERIAL IS FURNISHED ON AN “AS-IS” BASIS. CARNEGIE MELLON UNIVERSITY AND THE JOHNS HOPKINS UNIVERSITY APPLIED PHYSICS LABORATORY LLC MAKE NO WARRANTIES OF ANY KIND, EITHER EXPRESSED OR IMPLIED, AS TO ANY MATTER INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR PURPOSE OR MERCHANTABILITY, EXCLUSIVITY, OR RESULTS OBTAINED FROM USE OF THE MATERIAL NOR ANY WARRANTY OF ANY KIND WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK, OR COPYRIGHT INFRINGEMENT.