What changed in Container Platform Security Requirements Guide V2R5V2R5 changes

Discussion

If temporary user accounts remain active when no longer needed or for an excessive period, these accounts may be used to gain unauthorized access. To mitigate this risk, automated termination of all temporary user accounts must be set upon account creation. Temporary user accounts are established as part of normal account activation procedures when there is a need for short-term accounts without the demand for immediacy in account activation. If temporary user accounts are used, the application must be configured to automatically terminate these types of accounts after a DoDDoW-defined period of 72 hours. To address access requirements, many application developers choose to integrate their applications with enterprise-level authentication/access mechanisms that meet or exceed access control policy requirements. Such integration allows the application developer to off-load those access control functions and focus on core application features and functionality.

V-233020 in V2R5

Title

The container platform must display the Standard Mandatory DoDW Notice and Consent Banner before granting access to platform components.

Check text

Review the container platform configuration to determine if the Standard Mandatory DoDDoW Notice and Consent Banner is configured to be displayed before granting access to platform components. Log in to the container platform components and verify that the Standard Mandatory DoDDoW Notice and Consent Banner is being displayed before granting access. If the Standard Mandatory DoDDoW Notice and Consent Banner is not configured or is not displayed before granting access to container platform components, this is a finding.

Fix text

Configure the container platform to display the Standard Mandatory DoDW Notice and Consent Banner before granting access to container platform components.

Discussion

The container platform has countless components where different access levels are needed. To control access, the user must first log in to the component and then be presented with a DoDDoW-approved use notification banner before granting access to the component. This guarantees privacy and security notification verbiage used is consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance.

V-233032 in V2R5

Title

The container platform must retain the Standard Mandatory DoDDoW Notice and Consent Banner on the screen until users acknowledge the usage and conditions and take explicit actions to log on for further access.

Check text

Log in to the container platform components to determine if the Standard Mandatory DoDDoW Notice and Consent Banner remains on the screen until users acknowledge the usage and conditions and take explicit actions to log on for further access. If the Standard Mandatory DoDDoW Notice and Consent Banner does not stay on the screen until the users acknowledge the usage and conditions, this is a finding.

Fix text

Configure the container platform to retain the Standard Mandatory DoDDoW Notice and Consent Banner on the screen until users acknowledge the usage and conditions and take explicit actions to log on for further access.

Discussion

The banner must be acknowledged by the user prior to allowing the user access to any container platform component. This provides assurance that the user has seen the message and accepted the conditions for access. If the consent banner is not acknowledged by the user, DoDDoW will not be in compliance with system use notifications required by law. To establish acceptance of the application usage policy, a click-through banner at application logon is required. The application must prevent further activity until the user executes a positive action to manifest agreement by clicking on a box indicating "OK".

V-233033 in V2R5

Title

The container platform must generate audit records for all DoDW-defined auditable events within all components in the platform.

Check text

Review the container platform configuration to determine if the container platform is configured to generate audit records for all DoDDoW-defined auditable events within all components in the platform. Generate DoDDoW-defined auditable events within all the components to determine if the events are being audited. If the container platform is not configured to generate audit records for all DoDDoW-defined auditable events within the components or the events are not generating audit records, this is a finding.

Fix text

Configure the container platform to generate audit records for all DoDW-defined auditable events within all the components of the container platform.

Discussion

Within the container platform, audit data can be generated from any of the deployed container platform components. This audit data is important when there are issues, including security incidents that must be investigated. To make the audit data worthwhile for the investigation of events, it is necessary to have the appropriate and required data logged. To handle the need to log DoDDoW-defined auditable events, the container platform must offer a mechanism to change and manage the events that are audited.

V-233038 in V2R5

Title

The container platform must use multifactor authentication for network access to non-privileged accounts.

Discussion

To ensure accountability and prevent unauthenticated access, non-privilegednonprivileged users must utilize multifactor authentication to prevent potential misuse and compromise of the system. Multifactor authentication uses two or more factors to achieve authentication. Factors include: (i) Something you know (e.g., password/PIN); (ii) Something you have (e.g., cryptographic identification device, token); or (iii) Something you are (e.g., biometric). A non-privilegednonprivileged account is any information system account with authorizations of a non-privilegednonprivileged user. Network access is any access to an application by a user (or process acting on behalf of a user) where said access is obtained through a network connection. Applications integrating with the DoDDoW Active Directory and utilize the DoDDoW common access card (CAC) are examples of compliant multifactor authentication solutions.

V-233080 in V2R5

Discussion

A replay attack may enable an unauthorized user to gain access to the application. Authentication sessions between the authenticator and the application validating the user credentials must not be vulnerable to a replay attack. Anti-replay is a cryptographically based mechanism; thus, it must use FIPS-approved algorithms. An authentication process resists replay attacks if it is impractical to achieve a successful authentication by recording and replaying a previous authentication message. Note that the anti-replay service is implicit when data contains monotonically increasing sequence numbers and data integrity is assured. Use of DoDDoW PKI is inherently compliant with this requirement for user and device access. Use of Transport Layer Security (TLS), including application protocols such as HTTPS and DNSSEC, that use TLS/SSL as the underlying security protocol is also compliant. Configure the information system to use the hash message authentication code (HMAC) algorithm for authentication services to Kerberos, SSH, web management tool, and any other access method.

V-233084 in V2R5

Discussion

Passwords need to be protected at all times, and encryption is the standard method for protecting passwords. If passwords are not encrypted, they can be plainly read and easily compromised. Use of passwords for authentication is intended only for limited situations and should not be used as a replacement for two-factor common access card (CAC)-enabled authentication. Examples of situations where a user ID and password might be used include: - When the user does not use a CAC and is not a current DODDoW employee, member of the military, or DODDoW contractor. - When a user has been officially designated as temporarily unable to present a CAC for some reason (lost, damaged, not yet issued, broken card reader) (i.e., Temporary Exception User) and to satisfy urgent organizational needs must be temporarily permitted to use user ID/password authentication until the problem with CAC use has been remedied. - When the application is publicly available and or hosting publicly releasable data requiring some degree of need-to-know protection. If the password is already encrypted and not a plaintext password, this meets this requirement. Implementation of this requirement requires configuration of FIPS-approved cipher block algorithm and block cipher modes for encryption. This method uses a one-way hashing encryption algorithm with a salt value to validate a user's password without having to store the actual password. Performance and time required to access are factors that must be considered, and the one-way hash is the most feasible means of securing the password and providing an acceptable measure of password security. Verifying the user knows a password is performed using a password verifier. In its simplest form, a password verifier is a computational function that is capable of creating a hash of a password and determining if the value provided by the user matches the hash. A more secure version of verifying a user knowing a password is to store the result of an iterating hash function and a large random salt value as follows: H0 = H(pwd, H(salt)) Hn = H(Hn-1,H(salt)) In the above, "n" is a cryptographically-strong random [*3] number. "Hn" is stored along with the salt. When the application wishes to verify that the user knows a password, it simply repeats the process and compares "Hn" with the stored "Hn". A salt is essentially a fixed-length cryptographically strong random value. Another method is using a keyed-hash message authentication code (HMAC). HMAC calculates a message authentication code via a cryptographic hash function used in conjunction with an encryption key. The key must be protected as with any private key. This requirement applies to all accounts including authentication server, AAA, and local account, including the root account and the account of last resort.

V-233095 in V2R5

Title

The container platform must enforce a 6180-day maximum password lifetime restriction.

Check text

Review the container platform configuration to determine if it enforces a 60180-day maximum password lifetime restriction. If the container platform does not enforce a 60180-day maximum password lifetime restriction, this is a finding.

Fix text

Configure the container platform to enforce a 6180-day maximum password lifetime restriction.

V-233098 in V2R5

Check text

Review documentation and configuration to ensure the container platform provides a PKI integration capability that meets DoDDoW PKI infrastructure requirements. If the container platform is not configured to meet this requirement, this is a finding.

Fix text

Configure the container platform to utilize the DoDW Enterprise PKI infrastructure.

V-233101 in V2R5

Title

All non-essential, unnecessary, and unsecure DoDW ports, protocols, and services must be disabled in the container platform.

Discussion

To properly offer services to the user and to orchestrate containers, the container platform may offer services that use ports and protocols that best fit those services. The container platform, when offering the services, must only offer the services on ports and protocols authorized by the DoDDoW. To validate that the services are using only the approved ports and protocols, the organization must perform a periodic scan/review of the container platform and disable functions, ports, protocols, and services deemed to be unneeded or non-securenonsecure.

V-233190 in V2R5

Discussion

Controlling user access is paramount in securing the container platform. During a user's access to the container platform, events may occur that change the user's access and which require reauthentication. For instance, if the capability to change security roles or escalate privileges is implemented, it is critical the user reauthenticate. In addition to the reauthentication requirements associated with change in security roles or privilege escalation, organizations may require reauthentication of individuals in other situations, including (but not limited to) the following circumstances: (i) When authenticators change; (ii) When roles change; (iii) When security categories of information systems change; (iv) When the execution of privileged functions occurs; (v) After a fixed period of time; or (vi) Periodically. Within the DODDoW, the minimum circumstances requiring reauthentication are privilege escalation and role changes.

V-233193 in V2R5

Title

The container platform must be configured to use multi-factor authentication for user authentication.

Check text

Review documentation and configuration to ensure the container platform is configured to use an approved DoDDoW multifactor token (CAC) when accessing platform via user interfaces. If multifactor authentication is not configured, this is a finding.

Fix text

Configure the container platform to accept standard DoDW multifactor token-based credentials when users interface with the platform.

Discussion

Controlling access to the container platform and its components is paramount in having a secure and stable system. Validating users is the first step in controlling the access. Users may be validated by the overall container platform or they may be validated by each component. To standardize and reduce the risks of unauthorized access, the use of multifactor token-based credentials is the preferred method. DoDDoW has mandated the use of the common access card (CAC) to support identity management and personal authentication for systems covered under HSPD 12, as well as a primary component of layered protection for national security systems.

V-233195 in V2R5

Discussion

Unapproved mechanisms that are used for authentication to the cryptographic module are not verified, and therefore cannot be relied on to provide confidentiality or integrity, and DoDDoW data may be compromised. Nonlocal maintenance and diagnostic activities are activities conducted by individuals communicating through either an external network (e.g., the internet) or an internal network. Currently, HMAC is the only FIPS-approved algorithm for generating and verifying message/data authentication codes in accordance with FIPS 198-1. Products that are FIPS 140-2 validated will have an HMAC that meets specification; however, the option must be configured for use as the only message authentication code used for authentication to cryptographic modules. Separate requirements for configuring applications and protocols used by each product (e.g., SNMPv3, SSHv2, NTP, and other protocols and applications that require server/client authentication) are required to implement this requirement. The SSHv2 protocol suite must be mandated in the product because it includes layer 7 protocols such as SCP and SFTP that can be used for secure file transfers.

V-233207 in V2R5

Title

Container platform components must be configured in accordance with the security configuration settings based on DoDDoW security configuration or implementation guidance, including SRGs, STIGs, NSA configuration guides, CTOs, and DTMs.

Check text

Review the container platform configuration to determine the services offered by the container platform and validate that any services that are offered are configured in accordance with the security configuration settings based on DoDDoW security configuration or implementation guidance, including SRGs, STIGs, NSA configuration guides, CTOs, and DTMs. If container platform services are not configured in accordance with the security configuration settings based on DoDDoW security configuration or implementation guidance, including SRGs, STIGs, NSA configuration guides, CTOs, and DTMs, this is a finding.

Fix text

Configure container services in accordance with the security configuration settings based on DoDDoW security configuration or implementation guidance, including SRGs, STIGs, NSA configuration guides, CTOs, and DTMs.

V-233273 in V2R5