7. TECHNICAL CONTROLS
7.3 Identification and Authentication (IA)
Identification and Authentication (IA) security controls are designed to ensure that only pre-approved and authorized personnel are granted access to information systems. IA involves designation and use of user identifiers (userID) and authentication mechanisms to verify and validate the identity of the individual seeking access. IA works in conjunction with role-based access controls to further limit exposure of information assets to only those pre-approved individuals. These controls provide access to information systems and must be carefully managed and administered.
Policy: Before allowing access to Office of Personnel Management (OPM) information systems and information, systems shall identify and authenticate users and devices, including automated system processes acting on behalf of users and devices.
7.3.1 Identification and Authentication Policy and Procedures (IA-1) The policies under this control are implemented with the OPM-wide Identification and Authentication Procedure. Operational identification and authentication procedures may be developed by program offices and operational groups where necessary. Identification and authentication procedures shall be developed and disseminated. The procedures shall be reviewed at least annually and updated as determined necessary.
7.3.2 Identification and Authentication – Organizational Users (IA-2) The information system shall uniquely identify and authenticate organizational users (or processes acting on behalf of organizational users). Organizational users include OPM employees or individuals the organization deems to have equivalent status of employees (e.g., contractors, interns, etc.). Adequate controls shall be implemented and maintained on systems to confirm user identity prior to access. The access protection measures shall provide assurance of individual accountability through identification and authentication of each information system user.
Multifactor authentication is required for network access for privileged and non-privileged accounts (Moderate and High). Local access for privileged (Moderate and High) and non-privileged (High) accounts requires multifactor authentication.
Information systems shall use authentication mechanisms that require challenges (e.g., Transport Layer Security (TLS)), and time synchronous or challenge-response one-time authenticators for network access to privileged (Moderate and High) and non-privileged (High) accounts to prevent recording and reuse of previous authentication messages (replay-resistant authentication).
OPM shall use credentials compliant with Homeland Security Presidential Directive (HSPD)-12 requirements for access. OPM accepts credentials that include both Personal Identity
Verification (PIV) cards and PIV Interoperable cards which can be trusted by the Government consistent with Federal policy guidance, Personal Identity Verification (PIV) Interoperability For Non-Federal Issuers.
OPM, in accordance with OMB Memorandum M-11-11, shall ensure:
• All new systems under development are enabled to use PIV credentials, in accordance with NIST guidelines, prior to being made operational.
• Starting in FY2012, existing physical and logical access control systems shall be
upgraded to use PIV credentials, in accordance with NIST guidelines, prior to the agency using development and technology refresh funds to complete other activities.
• Procurements for services and products involving facility or system access control shall be in accordance with HSPD-12 policy and the Federal Acquisition Regulation.
• OPM physical and logical access processes shall accept and electronically verify PIV credentials issued by other federal agencies.
Group or shared accounts for individual access are not permitted. If group accounts must be used because of technology, a waiver shall be requested and approved by the Chief Information Security Officer (CISO). Requirements for group accounts include:
• Individuals shall first authenticate using an individual authenticator prior to using a group authenticator.
• Administrator accounts, such as “root”, shall require more than one individual to have access. The number of individuals having access for a given server shall be kept to a minimum.
• Group accounts that have system-level privileges granted through group membership or programs such as “su” or “sudo” shall have a unique password. The number of
individuals having access for a given server shall be kept to a minimum.
• The password for a shared account shall be changed whenever a member no longer has a need for access or when lost or stolen.
• Auditing shall be enabled for accountability purposes (Reference AU-2).
Rationale shall be documented within the applicable System Security Plan (SSP) for user actions permitted without uniquely identifying and authenticating individuals (Reference AC-14).
Machine/process accounts used for processing or transferring information are permitted. These accounts are often embedded in application or client/server environments to perform non-interactive automated transaction processes. A common example is the requirement for web based applications to authenticate to databases and applications where data is resident. If machine/process accounts are used, the account owner and purpose of the account shall be documented in the applicable SSP.
7.3.3 Device Identification and Authentication (IA-3)
Devices (e.g., network switches / routers, servers, workstations, laptops, printers, other peripheral devices - smart phones, tablet PCs, etc.) shall be uniquely identified and
authenticated prior to accessing the OPM network by using shared known information (e.g., Media Access Control (MAC) or Transmission Control Protocol/Internet Protocol (TCP/IP) addresses) for identification on local and wide area networks. An organizational authentication solution (e.g., IEEE 802.1x and Extensible Authentication Protocol (EAP), Radius server with EAP-Transport Layer Security (TLS) authentication, Kerberos) shall be used to authenticate
devices. If a computer is not a member of the domain, it cannot communicate with the network resources because the firewall masks the internal IP addresses and protects them from spoofing, etc.
7.3.4 Identifier Management (IA-4)
System Owners (SO) shall ensure the establishment of standards for user identification naming conventions and unique account identification code requirements.
OPM users are uniquely identified by the establishment of a network account. The identity of each user is verified by the OPM Human Resources (HR) department or Contracting Officer Technical Representative (COTR). HR creates a record for each new employee and initiates the process of obtaining the employee background investigation and obtaining fingerprints. The employee’s supervisor then requests establishment of a network account using OPM IT Access Form 1665.
Information system identifiers for users and devices shall be managed by:
• Receiving authorization from a Program Supervisor to assign a user or device identifier;
• Selecting an identifier that uniquely identifies an individual or device;
• Assigning the user identifier to the intended party or the device identifier to the intended device;
• Preventing reuse of user or device identifiers permanently; and
• Disabling the user identifier after 30 calendar days of inactivity.
7.3.5 Authenticator Management (IA-5)
SOs shall ensure implementation of authenticators (e.g., passwords, tokens, biometrics, Public Key Infrastructure (PKI) certificates, key cards) that prevent unauthorized access to systems.
Users shall maintain authenticators and protect them from inadvertent disclosure. Measures to safeguard user authenticators include, for example, maintaining possession of individual authenticators, not loaning or sharing authenticators with others, and reporting lost or compromised authenticators immediately. Administration of the authentication data shall include procedures to disable lost or stolen tokens, smart cards, or passwords, and include procedures for the recovery of cryptographic keys.
Information system authenticators for users and devices shall be managed by:
• Verifying, as part of the initial authenticator distribution, the identity of the individual and/or device receiving the authenticator;
• Establishing initial authenticator content for authenticators defined by the organization;
• Ensuring that authenticators have sufficient strength of mechanism for their intended use;
• Establishing and implementing administrative procedures for initial authenticator distribution, for lost/compromised or damaged authenticators, and for revoking authenticators;
• Changing default content of authenticators upon information system installation;
• Establishing minimum and maximum lifetime restrictions and reuse conditions for authenticators (if appropriate);
• Changing/refreshing authenticators reference authentication types below;
• Protecting authenticator content from unauthorized disclosure and modification; and
• Requiring users and devices to implement specific measures to safeguard authenticators.
OPM requires Personal Identity Verification (PIV) cards to gain access to information systems in accordance with Homeland Security Presidential Directive (HSPD)-12, Federal Information Processing Standard (FIPS 201), and OMB Memorandum M-11-11 when feasible. PIV cards may use a combination of authenticator mechanisms (i.e., card holder unique identifier (CHUID), PKI certificate, or biometrics) depending upon the assurance level required.
The information system for password-based authentication shall:
• Enforce minimum password complexity of:
• At least 8 characters for non-privileged accounts; and at least 12 characters for privileged accounts
• 3 of the following 4 attributes:
o Uppercase letters (A-Z) o Lower case letters (a-z) o Numbers (0-9)
o Special characters (#, @, $, %, &, *, +, =, *, ?, {}, [], <>, :, ”)
• Enforce at least one (1) changed character when new passwords are created;
• Encrypt passwords in storage and in transmission (Passwords shall not be stored in clear text or in any easily reversible form in batch files, automatic login scripts, software macros, terminal function keys, or in any location where an unauthorized person might discover them);
• Enforce password minimum and maximum lifetime restrictions of one (1) day minimum and 60 day maximum;
• Prohibit password reuse for twenty four (24) generations;
• Lock an account after three (3) consecutive invalid login attempts (Reference AC-7).
Exceptions:
• Mainframe passwords shall be 8 characters long and shall be in alphanumeric format (any combination of numbers and/or letters).
• Blackberry passwords shall be at least 8 alphanumeric characters.
• Passwords for machine/process accounts may not expire.
Additional password management requirements include:
• Passwords shall be audited on a regular basis for compliance to ensure strength of passwords is sufficient. If a password is guessed or cracked during an audit, the user shall change it.
• Temporary passwords shall be changed upon initial login.
• The system shall provide a mechanism that notifies the user when a password change is required.
• Passwords shall not be visible on screen, hardcopy, or any other output device.
• User passwords shall not be hard-coded into software.
• When providing user identifiers (userID) and passwords to users, two different media (telephone, postal, e-mail, or a secure Web site) shall be used. One to deliver the userID, and one to deliver the password to prevent account compromise.
• Collection of userIDs and/or passwords shall not be permitted, except for purposes of authorized network, system, or security administration.
• The following list outlines additional recommendations, or safeguards for users:
• Passwords shall not contain any of the following:
o UserID or any part of your full name
o Dictionary words or common names (e.g., Betty, Fred, Rover) o Portions of associated account names (e.g., userID, login name) o Consecutive character strings (e.g., abcdef, 12345)
o Simple keyboard patterns (e.g., qwerty, asdfgh)
o Generic passwords (i.e., password cons isting of a variation of the word
"password" (e.g., P@sswOrdl))
• Shall not reveal a password over the phone to ANYONE.
• Shall not reveal a password in an email message.
• Shall not reveal a password to the Help Desk.
• Shall not discuss a password in front of others.
• Shall not hint at the format of a password (e.g., "my family name").
• Shall not reveal a password on questionnaires or security forms.
• Shall not share passwords with anyone including management, co-workers, administrative assistants, or secretaries.
• Shall not write down passwords and store in common areas (i.e., side of monitor, under keyboard, etc.). If passwords, such as emergency passwords or administrator passwords must be written down, they shall be placed in a sealed envelope and secured in a locked container.
• Shall immediately notify supervisors and the respective Help Desk if an account or password is suspected to have been compromised, and change all passwords.
Reference the LAN Complex Passwords standard for network users and the Sysplex Security Policy and Procedures for Mainframe user identification and authentication requirements.
The information system for PKI-based authentication shall:
• Validate certificates by constructing a certification path with status information to an accepted trust anchor (i.e., certificate revocation lists or online certificate status protocol responses);
• Enforce authorized access to the corresponding private key; and
• Map the authenticated identity to the user account.
The registration process to receive HSPD-12 PIV smartcards and other PKI authenticators shall be carried out in person before a designated registration authority with authorization by a designated organizational official (e.g., a supervisor).
Cardholder and PKI certificate Personal Identification Numbers (PIN) are not subject to aging criteria that are required for traditional passwords. The term “PIN” and “password” are not synonymous. National Institute of Standards and Technology (NIST) SP 800-53 control IA-5, regarding Authenticator Management, distinguishes between password expiration requirements and PKI certificate requirements. FIPS PUB 201-1 defines the logical functions for PIV credentials including:
• Proof of the identity of the cardholder to the card
• Proof of the identity of the cardholder to a remote entity (i.e., application, system) NIST SP 800-73-3, Interfaces for Personal Identity Verification–Part 2: End-Point PIV Card Application Card Command Interface is an additional reference for PIN requirements.
PINs accomplish the intent of category (1) above, validating cardholder identity to the PIV card.
Knowledge of a PIN is the means by which an individual can be authenticated to the PIV Card Application. Passwords accomplish the intent of category (2) above by validating cardholder identity to a remote entity, application, or system.
The process of PIN entry, validating a cardholder to a card or an individual to a PKI certificate, occurs locally on a number pad or cardholder controlled system. The PIN never traverses an unprotected medium, and thus significantly limits exposure. Passwords may traverse an unprotected network, and thus the use of passwords to validate cardholder identity to a remote entity, application, or system increases exposure. The increased risk of password exposure is mitigated by the use of password aging techniques. The longevity of cardholder and PKI certificate PINs far exceed that of passwords due to the significantly limited exposure to attack, and thus are not subject to the same aging criteria required for traditional passwords. However, it is a recommended best practice that cardholders periodically change their PIN.
7.3.6 Authenticator Feedback (IA-6)
Information systems shall not reveal information during the authentication process that could be used by malicious individuals to gain unauthorized access. Authenticator (e.g., password, Personal Identification Numbers (PIN), etc.) feedback shall be obscured during user login by
displaying asterisks or using a similar solution. Authenticator error messages shall not contain authenticator content requirements, user identifiers (userID) requirements, or whether or not the user has entered an incorrect userID or password upon login.
7.3.7 Cryptographic Module Authentication (IA-7)
The information system shall use mechanisms for authentication to a cryptographic module that meet the requirements of applicable federal laws, Executive Orders, directives, policies,
regulations, standards, and guidance for such authentication.
Cryptographic-based security systems may be utilized in various computer and
telecommunication applications (e.g., data storage, access control and personal identification, network communications, radio, facsimile, and video) and in various environments (e.g., centralized computer facilities, office environments, and hostile environments). The
cryptographic services (e.g., encryption, authentication, digital signature, and key management) provided by a cryptographic module are based on many factors that are specific to the
application and environment.
The focus of this control is implementing the authentication requirements contained in the applicable laws, Executive Orders, etc. (Federal Information Security Management Act (FIPS) 140-2, as amended) with regard to authentication to a cryptographic module. The control does not address using cryptography to protect the authentication session nor other uses of
cryptography. In the context of this control, it is the cryptographic module that provides authentication via means that need not involve cryptography (e.g., use of password authentication may meet the requirements of this control).
The SO shall ensure the requirements in FIPS-140-2 are reviewed as amended to determine what authentication mechanism to implement (e.g., role-based authentication, identity-based
authentication) for a cryptographic module, and apply the appropriate system configuration to ensure compliance.
7.3.8 Identification and Authentication – Non-Organizational Users (IA-8) Non-organizational users shall be identified by type, organization, agency, etc. within the system’s System Security Plan (SSP). Non-organizational users typically include individuals of the public, retired Federal employees (annuitants), non OPM Federal employees, applicants, etc.
In accordance with the E-Authentication E-Government initiative, authentication of non-organizational users accessing federal information systems may be required to protect federal, proprietary, or privacy-related information (with exceptions noted for national security systems).
Accordingly, an E-Authentication Risk Assessment is used in determining the authentication needs of the organization.
For public facing information systems, SOs shall ensure an E-Authentication Risk Assessment is conducted in accordance with applicable Office of Management and Budget (OMB)/National Institute of Standards and Technology (NIST) guidance, specifically, OMB M-04-04,
E-Authentication Guidance for Federal Agencies and NIST SP 800-63, Electronic E-Authentication Guideline. Identification and authentication technology consistent with the results of
E-Authentication Risk Assessments shall be deployed.