**Update: 23 April 2021 – MFA text requirement change**
The time finally came for multifactor authentication in DoD. The DoD finally put their feet down on securing account access. For all devices/products coming into DoD (especially through DoDIN testing), will be held to account for the Network Device Management (NDM) Security Requirements Guide (SRG). Details are here:
Network Device Management Security Requirements Guide :: Version 4, Release: 1 Benchmark Date: 23 Apr 2021
Rule Title: The network device must be configured to use DoD PKI as multi-factor authentication (MFA) for interactive logins.
Discussion: Multi-factor authentication (MFA) is when two or more factors are used to confirm the identity of an individual who is requesting access to digital information resources. Valid factors include something the individual knows (e.g., username and password), something the individual has (e.g., a smartcard or token), or something the individual is (e.g., a fingerprint or biometric). Legacy information system environments only use a single factor for authentication, typically a username and password combination. Although two pieces of data are used in a username and password combination, this is still considered single factor because an attacker can obtain access simply by learning what the user knows. Common attacks against single-factor authentication are attacks on user passwords. These attacks include brute force password guessing, password spraying, and password credential stuffing. MFA, along with strong user account hygiene, helps mitigate against the threat of having account passwords discovered by an attacker. Even in the event of a password compromise, with MFA implemented and required for interactive login, the attacker still needs to acquire something the user has or replicate a piece of user’s biometric digital presence.Private industry recognizes and uses a wide variety of MFA solutions. However, DoD public key infrastructure (PKI) is the only prescribed method approved for DoD organizations to implement MFA. For authentication purposes, centralized DoD certificate authorities (CA) issue PKI certificate key pairs (public and private) to individuals using the prescribed x.509 format. The private certificates that have been generated by the issuing CA are downloaded and saved to smartcards which, within DoD, are referred to as common access cards (CAC) or personal identity verification (PIV) cards. This happens at designated DoD badge facilities. The CA maintains a record of the corresponding public keys for use with PKI-enabled environments. Privileged user smartcards, or “alternate tokens”, function in the same manner, so this requirement applies to all interactive user sessions (authorized and privileged users).
Note: This requirement is used in conjunction with the use of a centralized authentication server (e.g., AAA, RADIUS, LDAP), a separate but equally important requirement. The MFA configuration of this requirement provides identification and the first phase of authentication (the challenge and validated response, thereby confirming the PKI certificate that was presented by the user). The centralized authentication server will provide the second phase of authentication (the digital presence of the PKI ID as a valid user in the requested security domain) and authorization. The centralized authentication server will map validated PKI identities to valid user accounts and determine access levels for authenticated users based on security group membership and role. In cases where the centralized authentication server is not utilized by the network device for user authorization, the network device must map the authenticated identity to the user account for PKI-based authentication.
Check Text: Verify the network device is configured to use DoD PKI as MFA for interactive logins. Evidence of successful configuration is usually indicated by a prompt for the user to insert a smartcard. If the smartcard is already inserted, the network device will prompt the user to enter the corresponding PIN which unlocks the certificate keystore on the smartcard. If the network device is not configured to use DoD PKI as MFA for interactive logins, this is a finding. If the PKI authenticated user is not mapped to the effective local user account this is a finding .Note: Alternative MFA solutions for network devices with basic user interfaces (e.g., L2 switch with only SSH access) have been evaluated by the DoD Privileged User Working Group (PUWG). Current alternatives include RSA SecureID tokens and YubiKey One Time Password (OTP) tokens. To use an alternative MFA solution, a business case and risk assessment must be presented to the Authorizing Official (AO) for review and acceptance. AOs may choose to accept the risk of using one of these alternatives in a target environment based on the business case that was presented. If so, it is the responsibility of the AO to determine if the risk should be downgraded to a CAT II or a CAT III based on the risk assessment of the target environment.
If DoD PKI is not used but the network device makes use of an alternative FIPS 140-2 compliant, Cryptographic Module Validation Program (CMVP) validated OTP password solution, then this requirement can be downgraded to a CAT III.Note: Other mitigation strategies which have not been evaluated by the DoD PUWG may include the use of one or more industry solutions. One-time password/PIN/passcodes (OTP), one-time URLs, time-based tokens, and biometrics are examples of such solutions. While AOs may choose to accept the risk of using these alternatives on a case-by-case basis, for DoD the risk of using these alternatives should never be mitigated below a CAT II.
Note: This requirement is not applicable to the emergency account of last resort nor for service accounts (non-interactive users). Examples of service accounts include remote service brokers such as AAA, syslog, etc.
I’m a Product Vendor – How Does This Effect Me?
You need to provide support for it. DoD prefers you use PKI smartcard authentication (e.g. Common Access Cards (CACs). In fact, there is broad support now in general purpose software like Apache HTTPD, Microsoft IIS Server, etc. However, if your device/product only really supplies a command line interface (CLI), CAC authentication isn’t possible for you right now. This means you only have a few more resources: Bring Your Own MFA, or integrate with COTS MFA solutions. Entrust, RSA SecurID, and others all have their multifactor tokens enterprises have been using for decades. However, if the organization you are selling your product to does not have that capability – you force them to buy one.
Or you can brew your own. However, the easiest way would be to get in contact with us ASAP! We have a pre-configured solution that will solve all your problems. The only requirements for your device are as follows: you must obtain your own Yubikey tokens, your product must have a RADIUS or TACACS+ client, and the organization has connection to an active directory environment to use for admin user account authorization. Tachyon Dynamics offers the following solution – Yubikey and Red Hat Enterprise Linux 6.9 appliance to all of its former, current, and future clients. Take a look at the details of this offering here.
I’m a DoD Enterprise – How Does This Effect Me?
You will need to implement it. All DoD enterprises have known that 2-factor and multifactor authentication has been a requirement for them (for over 15 years now) to use on everything from their network devices, routers, switches, firewall, and host and server operating systems. The difference now is that this SRG could be held as an item that will be reviewed in a Command Cyber Readiness Inspection (CCRI). As like DoD APL testing, a CCRI can highlight CAT 1s as well. Meaning, the enterprises’ authority to operate (ATO) may be in jeopardy.
What Now?
First thing you need to do is find out the capabilities of your software, application, and products for multifactor authentication. As previously stated, if your application sits on general purpose operating systems like Microsoft Windows Server 2008+ or Red Hat Enterprise Linux 6.9+, then you should work on integrating DoD PKI CAC authentication – as this is the most preferred option in DoD.
However, if CAC authentication is not feasible, get in contact with us and see how we can help.