NIST SP 800-171 Family: Identification and Authentication

Act now, to prioritize the implementation of robust identification and authentication measures. Your organization’s security, reputation, and success depend on it. Don’t wait until it’s too late; act now to safeguard your future.

Downloadable Checklist Here

Introduction to Identification and Authentication

The guidance found in Identification and Authentication (IA), a family of controls in the NIST SP 800-171 program is used to secure controlled unclassified information (CUI) in a business system by requiring they implement robust identification and authentication methods to preserve the confidentiality, integrity, and availability of information within the business system.

Below are the IA controls which represent a focus on securing CUI. Although these controls were originally crafted to secure CUI, their implementation is a benefit to security with respect to any kind of data, in any kind of system.

3.5.1 Identify system users and processes acting on behalf of users and devices
3.5.2 Authenticate (or verify) the identities of users, processes, or devices
3.5.3 Use multifactor authentication for local and network access
3.5.4 Employ replay-resistant authentication mechanisms for network access
3.5.5 Prevent reuse of identifiers for a defined period
3.5.6 Disable identifiers after a defined period of inactivity
3.5.7 Enforce a minimum password complexity
3.5.8 Prohibit password reuse for a specified number of generations
3.5.9 Allow temporary password use for system logons with an immediate change to a permanent password
3.5.10 Store and transmit only cryptographically-protected passwords
3.5.11 Obscure feedback of authentication information

Crucial steps of securing a business system are identifying entities requesting access to the system, and repeatedly authenticating the identity of the entity requesting access. The IA controls focusing on these steps include the 3.5.1 control, focusing on identifying users, devices, or processes accessing the system, the 3.5.2 control, focusing on authenticating users, devices, or processes accessing the system, and the 3.5.3 control, which emphasizes the benefits of employing multiple authentication methods.

Redcliffe Labs, a diagnostic and diagnosis lab with several locations in India, may have suffered serious consequences resulting from a failure to implement the 3.5.2 IA control concerning authentication. The company had unknowingly made public a non-password protected, 7 TB database containing over 12 MM medical records consisting of extremely detailed and private medical information about millions of patients, as well as internal business documents, logging records, and even Redcliffe Labs’ mobile application and development files. Such a blunder may result in a loss of the public’s trust in one of India’s most widely used medical diagnostic and diagnosis labs. Redcliffe Labs also has no way of knowing who accessed the database, a clear failure to implement the 3.5.1 control concerning identification. In addition, the company has no way of knowing when the database was accessed, or the frequency of access, which (repeated access) would call for the implementation of the 3.5.3 control concerning multiple authentication methods (1). These mistakes made by Redcliffe Labs may culminate in millions of instances of medical fraud, misuse of medial information, potentially providing bad actors with means of bribery, blackmail, or ransom, among other unfortunate possibilities.

A software company, SolarWinds, was the victim of one of the most impactful cyber attacks in recent years, affecting thousands of companies using SolarWinds software—even multiple departments of the U.S. government. In SolarWinds’ attempt to implement an authentication method for access to their update server, a password, the company displayed gross negligence as seen by the careless inclusion of the password “solarwinds123” on the publicly available GitHub account of a SolarWinds employee (2). Proper implementation of the 3.5.2 control concerning the use of authentication methods requires confidentiality when necessary. Meaning, when an authentication method is used to verify an identity found according to the 3.5.1 control concerning identification of users, devices, and processes, the information provided by the user which is compared against the correct value by the system must stay confidential, or it is useless. This applies to all authentication methods, not just passwords like “solarwinds123”. Allowing the public to view authentication credentials to verify legitimacy of access requests to the SolarWinds update server is one of the biggest, most unfortunate, mistakes the company could have made. Had SolarWinds at least implemented the 3.5.3 control concerning multi-factor authentication, it may have mitigated the situation since attackers would have needed more than the password for update server access to get into the system. Examples include requiring the update server access requester to be in a certain location, scan a physical card, provide a security token, provide a biometric identifier, etc. Once the details of the vulnerabilities leading to the incident were exposed to the world, SolarWinds took a critical hit to their reputation as a secure and responsible software company, and all of SolarWinds’ business partners and customers (numbering at nearly 18,000) at the time of the incident were adversely affected as well considering the wide-spread, deep reliance on SolarWinds software (3).

Learn from Redcliffe Labs and SolarWinds by using the checklist below as guidance for implementation of the 3.5.1, 3.5.2, and 3.5.3 IA controls, so your business and reputation can stay secure and in good standing respectively.

References

“>*If you don’t receive your checklist shortly, check your spam folder*

← NIST SP 800-171 Family: Incident Response