Security Requirements Guide - Container Platform STIG V2R2

The container platform must use TLS 1.2 or greater for secure container image transport from trusted sources.

STIG ID: SRG-APP-000014-CTR-000035 | SRG: SRG-APP-000014 | Severity: medium | CCI: CCI-000068 | Vulnerability Id: V-233015

Vulnerability Discussion

The authenticity and integrity of the container image during the container image lifecycle is part of the overall security posture of the container platform. This begins with the container image creation and pull of a base image from a trusted source for child container image creation and the instantiation of the new image into a running service. If an insecure protocol is used during transmission of container images at any step of the lifecycle, a bad actor may inject nefarious code into the container image. The container image, when instantiated, then becomes a security risk to the container platform, the host server, and other containers within the container platform. To thwart the injection of code during transmission, a secure protocol (TLS 1.2 or newer) must be used. Further guidance on secure transport protocols can be found in NIST SP 800-52.

Check

Review the container platform configuration to verify that TLS 1.2 or greater is being used for secure container image transport from trusted sources.

If TLS 1.2 or greater is not being used for secure container image transport, this is a finding.

Fix

Configure the container platform to use TLS 1.2 or greater when components communicate internally or externally. The fix ensures that all communication components in the container platform are configured to utilize secure versions of TLS.

The container platform must use TLS 1.2 or greater for secure communication.

STIG ID: SRG-APP-000014-CTR-000040 | SRG: SRG-APP-000014 | Severity: medium | CCI: CCI-000068 | Vulnerability Id: V-233016

Vulnerability Discussion

The authenticity and integrity of the container platform and communication between nodes and components must be secure. If an insecure protocol is used during transmission of data, the data can be intercepted and manipulated. The manipulation of data can be used to inject status changes of the container platform, causing the execution of containers or reporting an incorrect healthcheck. To thwart the manipulation of the data during transmission, a secure protocol (TLS 1.2 or newer) must be used. Further guidance on secure transport protocols can be found in NIST SP 800-52.

Check

Review the container platform configuration to verify that TLS 1.2 or greater is being used for communication by the container platform nodes and components.

If TLS 1.2 or greater is not being used for secure communication, this is a finding.

Fix

Configure the container platform to use TLS 1.2 or greater for node and component communication.

The container platform must use a centralized user management solution to support account management functions.

STIG ID: SRG-APP-000023-CTR-000055 | SRG: SRG-APP-000023 | Severity: medium | CCI: CCI-000015 | Vulnerability Id: V-233019

Vulnerability Discussion

Enterprise environments make application account management challenging and complex. A manual process for account management functions adds the risk of a potential oversight or other error.

A comprehensive application account management process that includes automation helps to ensure accounts designated as requiring attention are consistently and promptly addressed. Examples include, but are not limited to, using automation to take action on multiple accounts designated as inactive, suspended, or terminated or by disabling accounts located in non-centralized account stores, such as multiple servers. This requirement applies to all account types, including individual/user, shared, group, system, guest/anonymous, emergency, developer/manufacturer/vendor, temporary, and service.

The application must be configured to automatically provide account management functions, and these functions must immediately enforce the organization's current account policy. The automated mechanisms may reside within the application itself or may be offered by the operating system or other infrastructure-providing automated account management capabilities. Automated mechanisms may be comprised of differing technologies, that when placed together, contain an overall automated mechanism supporting an organization's automated account management requirements.

Account management functions include: assignment of group or role membership; identifying account type; specifying user access authorizations (i.e., privileges); account removal, update, or termination; and administrative alerts. The use of automated mechanisms can include: using email or text messaging to automatically notify account managers when users are terminated or transferred; using the information system to monitor account usage; or using automated telephonic notification to report atypical system account usage.

Check

Review the container platform to determine if it is using a centralized user management system for user management functions.

If the container platform is not using a centralized user management system for user management functions, this is a finding.

Fix

Configure the container platform to use a centralized user management system for user management functions.

The container platform must automatically remove or disable temporary user accounts after 72 hours.

STIG ID: SRG-APP-000024-CTR-000060 | SRG: SRG-APP-000024 | Severity: medium | CCI: CCI-000016 | Vulnerability Id: V-233020

Vulnerability 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 DoD-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.

Check

Review the container platform configuration to determine if temporary user accounts are automatically removed or disabled after 72 hours.

If temporary user accounts are not automatically removed or disabled after 72 hours, this is a finding.

Fix

Configure the container platform to automatically remove or disable temporary user accounts after 72 hours.

The container platform must automatically disable accounts after a 35-day period of account inactivity.

STIG ID: SRG-APP-000025-CTR-000065 | SRG: SRG-APP-000025 | Severity: medium | CCI: CCI-000017 | Vulnerability Id: V-233021

Vulnerability Discussion

Attackers that are able to exploit an inactive account can potentially obtain and maintain undetected access to an application. Owners of inactive accounts will not notice if unauthorized access to their user account has been obtained. Applications need to track periods of user inactivity and disable accounts after 35 days of inactivity. Such a process greatly reduces the risk that accounts will be hijacked, leading to a data compromise.

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.

This policy does not apply to either emergency accounts or infrequently used accounts. Infrequently used accounts are local login administrator accounts used by system administrators when network or normal logon/access is not available. Emergency accounts are administrator accounts created in response to crisis situations.

Check

Determine if the container platform automatically disables accounts after a 35-day period of account inactivity.

If the container platform does not automatically disable accounts after a 35-day period of account inactivity, this is a finding.

Fix

Configure the container platform to automatically disable accounts after a 35-day period of account inactivity.

The container platform must automatically audit account creation.

STIG ID: SRG-APP-000026-CTR-000070 | SRG: SRG-APP-000026 | Severity: medium | CCI: CCI-000018 | Vulnerability Id: V-233022

Vulnerability Discussion

Once an attacker establishes access to a system, the attacker often attempts to create a persistent method of re-establishing access. One way to accomplish this is for the attacker to create a new account. Auditing of account creation is one method for mitigating this risk. A comprehensive account management process will ensure an audit trail documents the creation of application user accounts and, as required, notifies administrators and/or application when accounts are created. Such a process greatly reduces the risk that accounts will be surreptitiously created, and provides logging that can be used for forensic purposes.

To address access requirements, many application developers choose to integrate their applications with enterprise-level authentication/access/auditing 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.

Check

Review the container platform configuration to determine if audit records are automatically created upon account creation.

If audit records are not automatically created upon account creation, this is a finding.

Fix

Configure the container platform to automatically create audit records on account creation.

The container platform must automatically audit account modification.

STIG ID: SRG-APP-000027-CTR-000075 | SRG: SRG-APP-000027 | Severity: medium | CCI: CCI-001403 | Vulnerability Id: V-233023

Vulnerability Discussion

Once an attacker establishes access to a system, the attacker often attempts to create a persistent method of re-establishing access. One way to accomplish this is for the attacker to modify an existing account. Auditing of account creation is one method for mitigating this risk. A comprehensive account management process will ensure an audit trail documents the creation of application user accounts and, as required, notifies administrators and/or application when accounts are created. Such a process greatly reduces the risk that accounts will be surreptitiously created and provides logging that can be used for forensic purposes.

To address access requirements, many application developers choose to integrate their applications with enterprise-level authentication/access/auditing 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.

Check

Review the container platform configuration to determine if account modification is automatically audited.

If account modification is not automatically audited, this is a finding.

Fix

Configure the container platform to automatically audit account modification.

The container platform must automatically audit account-disabling actions.

STIG ID: SRG-APP-000028-CTR-000080 | SRG: SRG-APP-000028 | Severity: medium | CCI: CCI-001404 | Vulnerability Id: V-233024

Vulnerability Discussion

When application accounts are disabled, user accessibility is affected. Once an attacker establishes access to an application, the attacker often attempts to disable authorized accounts to disrupt services or prevent the implementation of countermeasures. Auditing account-disabling actions provides logging that can be used for forensic purposes.

To address access requirements, many application developers choose to integrate their applications with enterprise-level authentication/access/audit mechanisms meeting or exceeding 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.

Check

Review the container platform configuration to determine if account disabling is automatically audited.

If account disabling is not automatically audited, this is a finding.

Fix

Configure the container platform to automatically audit account disabling.

The container platform must automatically audit account removal actions.

STIG ID: SRG-APP-000029-CTR-000085 | SRG: SRG-APP-000029 | Severity: medium | CCI: CCI-001405 | Vulnerability Id: V-233025

Vulnerability Discussion

When application accounts are removed, user accessibility is affected. Once an attacker establishes access to an application, the attacker often attempts to remove authorized accounts to disrupt services or prevent the implementation of countermeasures. Auditing account removal actions provides logging that can be used for forensic purposes.

To address access requirements, many application developers choose to integrate their applications with enterprise-level authentication/access/audit mechanisms meeting or exceeding 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.

Check

Review the container platform configuration to determine if account removal is automatically audited.

If account removal is not automatically audited, this is a finding.

Fix

Configure the container platform to automatically audit account removal.

Least privilege access and need to know must be required to access the container platform registry.

STIG ID: SRG-APP-000033-CTR-000090 | SRG: SRG-APP-000033 | Severity: medium | CCI: CCI-000213 | Vulnerability Id: V-233026

Vulnerability Discussion

The container platform registry is used to store images and is the keeper of truth for trusted images within the platform. To guarantee the images integrity, access to the registry must be limited to those individuals who need to perform tasks to the images such as the update, creation, or deletion of images. Without this control access, images can be deleted that are in use by the container platform causing a denial of service (DoS), and images can be modified or introduced without going through the testing and validation process allowing for the intentional or unintentional introduction of containers with flaws and vulnerabilities.

Check

Review the container platform configuration to determine if least privilege and need-to-know access is being used for container platform registry access.

If least privilege and need-to-know access is not being used for container platform registry access, this is a finding.

Fix

Configure the container platform to use least privilege and need to know when granting access to the container platform registry. The fix ensures the proper roles and permissions are configured.

Least privilege access and need to know must be required to access the container platform runtime.

STIG ID: SRG-APP-000033-CTR-000095 | SRG: SRG-APP-000033 | Severity: medium | CCI: CCI-000213 | Vulnerability Id: V-233027

Vulnerability Discussion

The container platform runtime is used to instantiate containers. If this process is accessed by those persons who are not authorized, those containers offering services can be brought to a denial of service (DoS) situation, disabling a large number of services with a small change to the container platform. To limit this threat, it is important to limit access to the runtime to only those individuals with runtime duties.

Check

Review the container platform to determine if only those individuals with runtime duties have access to the container platform runtime.

If users have access to the container platform runtime that do not have runtime duties, this is a finding.

Fix

Configure the container platform to use least privilege and need to know when granting access to the container runtime. The fix ensures the proper roles and permissions are configured.

Least privilege access and need to know must be required to access the container platform keystore.

STIG ID: SRG-APP-000033-CTR-000100 | SRG: SRG-APP-000033 | Severity: medium | CCI: CCI-000213 | Vulnerability Id: V-233028

Vulnerability Discussion

The container platform keystore is used to store access keys and tokens for trusted access to and from the container platform. The keystore gives the container platform a method to store the confidential data in a secure way and to encrypt the data when at rest. If this data is not protected through access controls, it can be used to access trusted sources as the container platform breaking the trusted relationship. To circumvent unauthorized access to the keystore, the container platform must have access controls in place to only allow those individuals with keystore duties.

Check

Review the container platform to determine if only those individuals with keystore duties have access to the container platform keystore.

If users have access to the container platform keystore that do not have keystore duties, this is a finding.

Fix

Configure the container platform to use least privilege and need to know when granting access to the container keystore. The fix ensures the proper roles and permissions are configured.

The container platform must enforce approved authorizations for controlling the flow of information within the container platform based on organization-defined information flow control policies.

STIG ID: SRG-APP-000038-CTR-000105 | SRG: SRG-APP-000038 | Severity: medium | CCI: CCI-001368 | Vulnerability Id: V-233029

Vulnerability Discussion

Controlling information flow between the container platform components and container user services instantiated by the container platform must enforce organization-defined information flow policies. Example methods for information flow control are using labels and separate namespace for containers to segregate services; user permissions and roles to limit what user services are available to each user; controlling the user the services are able to execute as; and limiting inter-container network traffic and the resources containers can consume.

Check

Review the container platform to determine if approved authorizations for controlling the flow of information within the container platform based on organization-defined information flow control policies is being enforced.

If the organization-defined information flow policies are not being enforced, this is a finding.

Fix

Configure the container platform to enforce approved authorizations for controlling the flow of information within the container platform based on organization-defined information flow control policies.

The container platform must enforce approved authorizations for controlling the flow of information between interconnected systems and services based on organization-defined information flow control policies.

STIG ID: SRG-APP-000039-CTR-000110 | SRG: SRG-APP-000039 | Severity: medium | CCI: CCI-001414 | Vulnerability Id: V-233030

Vulnerability Discussion

Controlling information flow between the container platform components and container user services instantiated by the container platform must enforce organization-defined information flow policies. Example methods for information flow control are: using labels for containers to segregate services; user permissions and roles to limit what user services are available to each user; controlling the user the services are able to execute as; and limiting inter-container network traffic and the resources containers can consume.

Check

Review the container platform configuration to determine if organization-defined information flow controls are implemented.

If information flow controls are not implemented, this is a finding.

Fix

Configure the container platform to implement organization-defined information flow controls.

The container platform must enforce the limit of three consecutive invalid logon attempts by a user during a 15-minute time period.

STIG ID: SRG-APP-000065-CTR-000115 | SRG: SRG-APP-000065 | Severity: medium | CCI: CCI-000044 | Vulnerability Id: V-233031

Vulnerability Discussion

By limiting the number of failed login attempts, the risk of unauthorized system access via user password guessing, otherwise known as brute forcing, is reduced. Limits are imposed by locking the account.

Check

Review the container platform to determine if it is configured to enforce the limit of three consecutive invalid logon attempts by a user during a 15-minute time period.

If the container platform is not configured to enforce the limit of three consecutive invalid logon attempts by a user during a 15-minute time period, this is a finding.

Fix

Configure the container platform to enforce the limit of three consecutive invalid logon attempts by a user during a 15-minute time period.

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

STIG ID: SRG-APP-000068-CTR-000120 | SRG: SRG-APP-000068 | Severity: low | CCI: CCI-000048 | Vulnerability Id: V-233032

Vulnerability 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 DoD-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.

Check

Review the container platform configuration to determine if the Standard Mandatory DoD 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 DoD Notice and Consent Banner is being displayed before granting access.

If the Standard Mandatory DoD Notice and Consent Banner is not configured or is not displayed before granting access to container platform components, this is a finding.

Fix

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

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

STIG ID: SRG-APP-000069-CTR-000125 | SRG: SRG-APP-000069 | Severity: low | CCI: CCI-000050 | Vulnerability Id: V-233033

Vulnerability 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, DoD 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".

Check

Log in to the container platform components to determine if the Standard Mandatory DoD 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 DoD Notice and Consent Banner does not stay on the screen until the users acknowledge the usage and conditions, this is a finding.

Fix

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

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

STIG ID: SRG-APP-000089-CTR-000150 | SRG: SRG-APP-000089 | Severity: medium | CCI: CCI-000169 | Vulnerability Id: V-233038

Vulnerability 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 DoD-defined auditable events, the container platform must offer a mechanism to change and manage the events that are audited.

Check

Review the container platform configuration to determine if the container platform is configured to generate audit records for all DoD-defined auditable events within all components in the platform.

Generate DoD-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 DoD-defined auditable events within the components or the events are not generating audit records, this is a finding.

Fix

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

The container platform must allow only the ISSM (or individuals or roles appointed by the ISSM) to select which auditable events are to be audited.

STIG ID: SRG-APP-000090-CTR-000155 | SRG: SRG-APP-000090 | Severity: medium | CCI: CCI-000171 | Vulnerability Id: V-233039

Vulnerability Discussion

Without the capability to restrict which roles and individuals can select which events are audited, unauthorized personnel may be able to prevent the auditing of critical events. Misconfigured audits may degrade the system's performance by overwhelming the audit log. Misconfigured audits may also make it more difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one.

The list of audited events is the set of events for which audits are to be generated. This set of events is typically a subset of the list of all events for which the system is capable of generating audit records.

Check

Review the container platform to determine if the container platform is configured to allow only the ISSM (or individuals or roles appointed by the ISSM) to select which auditable events are to be audited.

If the container platform is not configured to only allow the ISSM (or individuals or roles appointed by the ISSM) to select which auditable events are to be audited, this is a finding.

Fix

Configure the container platform to only allow the ISSM (or individuals or roles appointed by the ISSM) to select which auditable events are to be audited.

The container platform must generate audit records when successful/unsuccessful attempts to access privileges occur.

STIG ID: SRG-APP-000091-CTR-000160 | SRG: SRG-APP-000091 | Severity: medium | CCI: CCI-000172 | Vulnerability Id: V-233040

Vulnerability Discussion

Without generating audit records that are specific to the security and mission needs of the organization, it would be difficult to establish, correlate, and investigate the events relating to an incident, or identify those responsible for one.

Audit records can be generated from various components within the information system (e.g., module or policy filter).

Check

Review the container platform configuration to determine if it is configured to generate audit records when successful/unsuccessful attempts are made to access privileges.

If the container platform is not configured to generate audit records on successful/unsuccessful access to privileges, this is a finding.

Fix

Configure the container platform to generate audit records when successful/unsuccessful attempts are made to access privileges occur.

The container platform must initiate session auditing upon startup.

STIG ID: SRG-APP-000092-CTR-000165 | SRG: SRG-APP-000092 | Severity: medium | CCI: CCI-001464 | Vulnerability Id: V-233041

Vulnerability Discussion

When the container platform is started, container platform components and user services can also be started. It is important that the container platform begin auditing on startup in order to handle container platform startup events along with events for container platform components and services that begin on startup.

Check

Review the container platform configuration for session audits.

Ensure audit policy for session logging at startup is enabled.

Verify events are written to the log.

Validate system documentation is current.

If the container platform is not configured to meet this requirement, this is a finding.

Fix

Configure the container platform to generate audit logs for session logging at startup. Revise all applicable system documentation.

All audit records must identify what type of event has occurred within the container platform.

STIG ID: SRG-APP-000095-CTR-000170 | SRG: SRG-APP-000095 | Severity: medium | CCI: CCI-000130 | Vulnerability Id: V-233042

Vulnerability 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, such as security incidents, that must be investigated. To make the audit data worthwhile for the investigation of events, it is necessary to know what type of event occurred.

Check

Review the container platform configuration for audit event types. Ensure audit policy for event type is enabled.

Verify records showing what type of event occurred are written to the log.

Validate system documentation is current.

If log data does not show the type of event, this is a finding.

Fix

Configure the container platform to include the event type in the log data. Revise all applicable system documentation.

The container platform audit records must have a date and time association with all events.

STIG ID: SRG-APP-000096-CTR-000175 | SRG: SRG-APP-000096 | Severity: medium | CCI: CCI-000131 | Vulnerability Id: V-233043

Vulnerability Discussion

Check

Review the container platform configuration for audit events date and time.

Ensure audit policy for event date and time are enabled.

Verify records showing event date and time are included in the log.

Validate system documentation is current.

If the date and time are not included, this is a finding.

Fix

Configure the container platform to include log date and time with the event. Revise all applicable system documentation.

All audit records must identify where in the container platform the event occurred.

STIG ID: SRG-APP-000097-CTR-000180 | SRG: SRG-APP-000097 | Severity: medium | CCI: CCI-000132 | Vulnerability Id: V-233044

Vulnerability Discussion

Check

Review the container platform configuration to determine if all audit records identify where in the container platform the event occurred.

Generate audit records and view the audit records to verify that the records do identify where in the container platform the event occurred.

If the container platform is not configured to generate audit records that identify where in the container platform the event occurred, or if the generated audit records do not identify where in the container platform the event occurred, this is a finding.

Fix

Configure the container platform to generate audit records that identify where in the container platform the event occurred.

All audit records must identify the source of the event within the container platform.

STIG ID: SRG-APP-000098-CTR-000185 | SRG: SRG-APP-000098 | Severity: medium | CCI: CCI-000133 | Vulnerability Id: V-233045

Vulnerability Discussion

Audit data is important when there are issues, to include security incidents that must be investigated. Since the audit data may be part of a larger audit system, it is important for the audit data to also include the container platform name for traceability back to the container platform itself and not just the container platform components.

Check

Review container platform audit policy configuration for logons establishing the sources of events.

Ensure audit policy is configured to generate sufficient information to resolve the source, e.g., source IP, of the log event.

Verify records showing by requesting a user access the container platform and generate log events, and then review the logs to determine if the source of the event can be established.

If the source of the event cannot be determined, this is a finding.

Fix

Configure the container platform registry, keystore, and runtime to generate the source of each loggable event. Revise all applicable system documentation.

All audit records must generate the event results within the container platform.

STIG ID: SRG-APP-000099-CTR-000190 | SRG: SRG-APP-000099 | Severity: medium | CCI: CCI-000134 | Vulnerability Id: V-233046

Vulnerability Discussion

Check

Review the container platform configuration to determine if audit records contain the audit event results.

Generate audit records and review the data to validate that the record does contain the event result.

If the container platform is not configured to generate audit records with the event result or the audit record does not contain the event result, this is a finding.

Fix

Configure the container platform to generate audit records that contain the event result.

All audit records must identify any users associated with the event within the container platform.

STIG ID: SRG-APP-000100-CTR-000195 | SRG: SRG-APP-000100 | Severity: medium | CCI: CCI-001487 | Vulnerability Id: V-233047

Vulnerability Discussion

Without information that establishes the identity of the user associated with the events, security personnel cannot determine responsibility for the potentially harmful event.

Check

Review container platform documentation and the log files on the application server to determine if the logs contain information that establishes the identity of the user or process associated with log event data.

If the container platform does not produce logs that establish the identity of the user or process associated with log event data, this is a finding.

Fix

Configure the container platform logging system to log the identity of the user or process related to the events.

All audit records must identify any containers associated with the event within the container platform.

STIG ID: SRG-APP-000100-CTR-000200 | SRG: SRG-APP-000100 | Severity: medium | CCI: CCI-001487 | Vulnerability Id: V-233048

Vulnerability Discussion

Without information that establishes the identity of the containers offering user services or running on behalf of a user within the platform associated with audit events, security personnel cannot determine responsibility for potentially harmful events.

Check

Review the container platform configuration to determine if it is configured to generate audit records that contain the component information that generated the audit record.

Generate audit records and review the data to determine if records are generated containing the component information that generated the record.

If the container platform is not configured to generate audit records containing the component information or records are generated that do not contain the component information that generated the record, this is a finding.

Fix

Configure the container platform to include the component information that generated the audit record.

The container platform must generate audit records containing the full-text recording of privileged commands or the individual identities of group account users.

STIG ID: SRG-APP-000101-CTR-000205 | SRG: SRG-APP-000101 | Severity: medium | CCI: CCI-000135 | Vulnerability Id: V-233049

Vulnerability Discussion

During an investigation of an incident, it is important to fully understand what took place. Often, information is not part of the audited event due to the data's nature, security risk, or audit log size. Organizations must consider limiting the additional audit information to only that information explicitly needed for specific audit requirements. At a minimum, the organization must audit either full-text recording of privileged commands, or the individual identities of group users, or both.

Check

Review the documentation and deployment configuration to determine if the container platform is configured to generate full-text recording of privileged commands or the individual identities of group users at a minimum.

Have a user execute a privileged command and review the log data to validate that the full-text or identity of the individual is being logged.

If the container platform is not meeting this requirement, this is a finding.

Fix

Configure the container platform to generate the full-text recording of privileged commands, or the individual identities of group users, or both.

The container platform components must provide the ability to send audit logs to a central enterprise repository for review and analysis.

STIG ID: SRG-APP-000111-CTR-000220 | SRG: SRG-APP-000111 | Severity: medium | CCI: CCI-000154 | Vulnerability Id: V-233052

Vulnerability Discussion

The container platform components must send audit events to a central managed audit log repository to provide reporting, analysis, and alert notification. Incident response relies on successful timely, accurate system analysis in order for the organization to identify and respond to possible security events.

Check

Review the configuration settings to determine if the container platform components are configured to send audit events to central managed audit log repository.

If the container platform is not configured to send audit events to central managed audit log repository, this is a finding.

Fix

Configure the container platform components to send audit logs to a central managed audit log repository.

The container platform must use internal system clocks to generate audit record time stamps.

STIG ID: SRG-APP-000116-CTR-000235 | SRG: SRG-APP-000116 | Severity: medium | CCI: CCI-000159 | Vulnerability Id: V-233055

Vulnerability Discussion

Understanding when and sequence of events for an incident is crucial to understand what may have taken place. Without a common clock, the components generating audit events could be out of synchronization and would then present a picture of the event that is warped and corrupted. To give a clear picture, it is important that the container platform and its components use a common internal clock.

Check

Review the container platform configuration files to determine if the internal system clock is used for time stamps.

If the container platform does not use the internal system clock to generate time stamps, this is a finding.

Fix

Configure the container platform to use internal system clocks to generate time stamps for log records.

The container platform must protect audit information from any type of unauthorized read access.

STIG ID: SRG-APP-000118-CTR-000240 | SRG: SRG-APP-000118 | Severity: medium | CCI: CCI-000162 | Vulnerability Id: V-233056

Vulnerability Discussion

If audit data were to become compromised, then competent forensic analysis and discovery of the true source of potentially malicious system activity is difficult if not impossible to achieve. In addition, access to audit records provides information an attacker could potentially use to his or her advantage.

To ensure the veracity of audit data, the information system and/or the application must protect audit information from any and all unauthorized access. This includes read, write, and copy access.

This requirement can be achieved through multiple methods, which will depend upon system architecture and design. Commonly employed methods for protecting audit information include least privilege permissions as well as restricting the location and number of log file repositories.

Additionally, applications with user interfaces to audit records should not allow for the unfettered manipulation of or access to those records via the application. If the application provides access to the audit data, the application becomes accountable for ensuring audit information is protected from unauthorized access.

Audit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity.

Check

Review the container platform configuration to determine where audit information is stored.

If the audit information is not protected from any type of unauthorized read access, this is a finding.

Fix

Configure the container platform to protect the storage of audit information from unauthorized read access.

The container platform must protect audit information from unauthorized modification.

STIG ID: SRG-APP-000119-CTR-000245 | SRG: SRG-APP-000119 | Severity: medium | CCI: CCI-000163 | Vulnerability Id: V-233057

Vulnerability Discussion

If audit data were to become compromised, then forensic analysis and discovery of the true source of potentially malicious system activity would be impossible to achieve.

To ensure the veracity of audit data, the information system and/or the application must protect audit information from unauthorized modification.

This requirement can be achieved through multiple methods, which will depend upon system architecture and design. Some commonly employed methods include ensuring log files receive the proper file system permissions and limiting log data locations.

Applications providing a user interface to audit data will leverage user permissions and roles identifying the user accessing the data and the corresponding rights that the user enjoys in order to make access decisions regarding the modification of audit data.

Audit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity.

Check

Review the container platform configuration to determine where audit information is stored.

If the audit log data is not protected from unauthorized modification, this is a finding.

Fix

Configure the container platform to protect the storage of audit information from unauthorized modification.

The container platform must protect audit information from unauthorized deletion.

STIG ID: SRG-APP-000120-CTR-000250 | SRG: SRG-APP-000120 | Severity: medium | CCI: CCI-000164 | Vulnerability Id: V-233058

Vulnerability Discussion

If audit data were to become compromised, then forensic analysis and discovery of the true source of potentially malicious system activity would be impossible to achieve.

To ensure the veracity of audit data, the information system and/or the application must protect audit information from unauthorized deletion. This requirement can be achieved through multiple methods, which will depend upon system architecture and design.

Some commonly employed methods include: ensuring log files receive the proper file system permissions utilizing file system protections, restricting access, and backing up log data to ensure log data is retained.

Applications providing a user interface to audit data will leverage user permissions and roles identifying the user accessing the data and the corresponding rights the user enjoys in order make access decisions regarding the deletion of audit data.

Audit information includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity. Audit information may include data from other applications or be included with the audit application itself.

Check

Review the container platform configuration to determine where audit information is stored.

If the audit log data is not protected from unauthorized deletion, this is a finding.

Fix

Configure the container platform to protect the storage of audit information from unauthorized deletion.

The container platform must protect audit tools from unauthorized access.

STIG ID: SRG-APP-000121-CTR-000255 | SRG: SRG-APP-000121 | Severity: medium | CCI: CCI-001493 | Vulnerability Id: V-233059

Vulnerability Discussion

Protecting audit data also includes identifying and protecting the tools used to view and manipulate log data. Therefore, protecting audit tools is necessary to prevent unauthorized operation on audit data.

Applications providing tools to interface with audit data will leverage user permissions and roles identifying the user accessing the tools and the corresponding rights the user enjoys in order to make access decisions regarding the access to audit tools.

Audit tools include, but are not limited to, vendor-provided and open source audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators.

Check

Review the container platform to validate container platform audit tools are protected from unauthorized access.

If the audit tools are not protected from unauthorized access, this is a finding.

Fix

Configure the container platform to protect audit tools from unauthorized access.

The container platform must protect audit tools from unauthorized modification.

STIG ID: SRG-APP-000122-CTR-000260 | SRG: SRG-APP-000122 | Severity: medium | CCI: CCI-001494 | Vulnerability Id: V-233060

Vulnerability Discussion

Protecting audit data also includes identifying and protecting the tools used to view and manipulate log data. Therefore, protecting audit tools is necessary to prevent unauthorized operation on audit data.

Applications providing tools to interface with audit data will leverage user permissions and roles identifying the user accessing the tools and the corresponding rights the user enjoys in order make access decisions regarding the modification of audit tools.

Audit tools include, but are not limited to, vendor-provided and open source audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators.

Check

Review the container platform to validate container platform audit tools are protected from unauthorized modification.

If the audit tools are not protected from unauthorized modification, this is a finding.

Fix

Configure the container platform to protect audit tools from unauthorized modification.

The container platform must protect audit tools from unauthorized deletion.

STIG ID: SRG-APP-000123-CTR-000265 | SRG: SRG-APP-000123 | Severity: medium | CCI: CCI-001495 | Vulnerability Id: V-233061

Vulnerability Discussion

Protecting audit data also includes identifying and protecting the tools used to view and manipulate log data. Therefore, protecting audit tools is necessary to prevent unauthorized operation on audit data.

Applications providing tools to interface with audit data will leverage user permissions and roles identifying the user accessing the tools and the corresponding rights the user enjoys in order make access decisions regarding the deletion of audit tools.

Audit tools include, but are not limited to, vendor-provided and open source audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators.

Check

Review the container platform to validate container platform audit tools are protected from unauthorized deletion.

If the audit tools are not protected from unauthorized deletion, this is a finding.

Fix

Configure the container platform to protect audit tools from unauthorized deletion.

The container platform must use FIPS validated cryptographic mechanisms to protect the integrity of log information.

STIG ID: SRG-APP-000126-CTR-000275 | SRG: SRG-APP-000126 | Severity: medium | CCI: CCI-001350 | Vulnerability Id: V-233063

Vulnerability Discussion

To fully investigate an incident and to have trust in the audit data that is generated, it is important to put in place data protections. Without integrity protections, unauthorized changes may be made to the audit files and reliable forensic analysis and discovery of the source of malicious system activity may be degraded. Although digital signatures are one example of protecting integrity, this control is not intended to cause a new cryptographic hash to be generated every time a record is added to a log file.

Integrity protections can also be implemented by using cryptographic techniques for security function isolation and file system protections to protect against unauthorized changes.

Check

Review the container platform configuration to determine if FIPS-validated cryptographic mechanisms are being used to protect the integrity of log information.

If FIPS-validated cryptographic mechanisms are not being used to protect the integrity of log information, this is a finding.

Fix

Configure the container platform to use FIPS-validated cryptographic mechanisms to protect the integrity of log information.

The container platform must be built from verified packages.

STIG ID: SRG-APP-000131-CTR-000280 | SRG: SRG-APP-000131 | Severity: medium | CCI: CCI-003992 | Vulnerability Id: V-233064

Vulnerability Discussion

It is important to patch and upgrade the container platform when patches and upgrades are available. More important is to get these patches and upgrades from a known source. To validate the authenticity of any patches and upgrades before installation, the container platform must check that the files are digitally signed by sources approved by the organization.

Check

Review the container platform configuration to verify it has been built from packages that are digitally signed by known and approved sources.

If the container platform was built from packages that are not digitally signed or are from unknown or nonapproved sources, this is a finding.

Fix

Rebuild the container platform from verified packages that are digitally signed by known and approved sources.

The container platform must verify container images.

STIG ID: SRG-APP-000131-CTR-000285 | SRG: SRG-APP-000131 | Severity: medium | CCI: CCI-003992 | Vulnerability Id: V-233065

Vulnerability Discussion

The container platform must be capable of validating container images are signed and that the digital signature is from a recognized and approved source approved by the organization. Allowing any container image to be introduced into the registry and instantiated into a container can allow for services to be introduced that are not trusted and may contain malicious code, which introduces unwanted services. These unwanted services can cause harm and security risks to the hosting server, the container platform, other services running within the container platform, and the overall organization.

Check

Review the container platform configuration to determine if container images are verified by enforcing image signing and that the image is signed recognized by an approved source.

If container images are not verified or the signature is not verified as a recognized and approved source, this is a finding.

Fix

Configure the container platform to verify container images are digitally signed and the signature is from a recognized and approved source.

The container platform must limit privileges to the container platform registry.

STIG ID: SRG-APP-000133-CTR-000290 | SRG: SRG-APP-000133 | Severity: medium | CCI: CCI-001499 | Vulnerability Id: V-233066

Vulnerability Discussion

To control what is instantiated within the container platform, it is important to control access to the registry. Without this control, container images can be introduced and instantiated by accident or on container platform startup. Without control of the registry, security measures put in place for the runtime can be bypassed meaning the controls of approval and testing are also bypassed. Only those individuals and roles approved by the organization can have access to the container platform registry.

Check

Review the container platform registry configuration to determine if the level of access to the registry is controlled through user privileges.

Attempt to perform registry operations to determine if the privileges are enforced.

If the container platform registry is not limited through user privileges or the user privileges are not enforced, this is a finding.

Fix

Configure the container platform to use and enforce user privileges when accessing the container platform registry.

The container platform must limit privileges to the container platform runtime.

STIG ID: SRG-APP-000133-CTR-000295 | SRG: SRG-APP-000133 | Severity: medium | CCI: CCI-001499 | Vulnerability Id: V-233067

Vulnerability Discussion

To control what is instantiated within the container platform, it is important to control access to the runtime. Without this control, container platform specific services and customer services can be introduced without receiving approval and going through proper testing. Only those individuals and roles approved by the organization can have access to the container platform runtime.

Check

Review the container platform runtime configuration to determine if the level of access to the runtime is controlled through user privileges.

Attempt to perform runtime operations to determine if the privileges are enforced.

If the container platform runtime is not limited through user privileges or the user privileges are not enforced, this is a finding.

Fix

Configure the container platform to use and enforce user privileges when accessing the container platform runtime.

The container platform must limit privileges to the container platform keystore.

STIG ID: SRG-APP-000133-CTR-000300 | SRG: SRG-APP-000133 | Severity: medium | CCI: CCI-001499 | Vulnerability Id: V-233068

Vulnerability Discussion

The container platform keystore is used to store credentials used to build a trust between the container platform and some external source. This trust relationship is authorized by the organization. If a malicious user were to have access to the container platform keystore, two negative scenarios could develop:

1) Keys not approved could be introduced and
2) Approved keys deleted, leading to the introduction of container images from sources that were never approved by the organization.

To thwart this threat, it is important to protect the container platform keystore and give access to only those individuals and roles approved by the organization.

Check

Review the container platform keystore configuration to determine if the level of access to the keystore is controlled through user privileges.

Attempt to perform keystore operations to determine if the privileges are enforced.

If the container platform keystore is not limited through user privileges or the user privileges are not enforced, this is a finding.

Fix

Configure the container platform to use and enforce user privileges when accessing the container platform keystore.

Configuration files for the container platform must be protected.

STIG ID: SRG-APP-000133-CTR-000305 | SRG: SRG-APP-000133 | Severity: medium | CCI: CCI-001499 | Vulnerability Id: V-233069

Vulnerability Discussion

The secure configuration of the container platform must be protected by disallowing changes to be implemented by non-privileged users. Changes to the container platform can introduce security risks or stability issues and undermine change management procedures. Securing configuration files from non-privileged user modification can be enforced using file ownership and permissions.

Check

Review the container platform to verify that configuration files cannot be modified by non-privileged users.

If non-privileged users can modify configuration files, this is a finding.

Fix

Configure the container platform to only allow configuration modifications by privileged users.

Authentication files for the container platform must be protected.

STIG ID: SRG-APP-000133-CTR-000310 | SRG: SRG-APP-000133 | Severity: medium | CCI: CCI-001499 | Vulnerability Id: V-233070

Vulnerability Discussion

The secure configuration of the container platform must be protected by disallowing changing to be implemented by non-privileged users. Changes to the container platform can introduce security risks and stability issues and undermine change management procedures. To secure authentication files from non-privileged user modification can be enforced using file ownership and permissions.

Examples of authentication files are keys, certificates, and tokens.

Check

Review the container platform to verify that authentication files cannot be modified by non-privileged users.

If non-privileged users can modify key and certificate files, this is a finding.

Fix

Configure the container platform to only allow authentication file modifications by privileged users.

The container platform must be configured with only essential configurations.

STIG ID: SRG-APP-000141-CTR-000315 | SRG: SRG-APP-000141 | Severity: medium | CCI: CCI-000381 | Vulnerability Id: V-233071

Vulnerability Discussion

The container platform can be built with components that are not used for the intended purpose of the organization. To limit the attack surface of the container platform, it is essential that the non-essential services are not installed.

Check

Review the container platform configuration and verify that only those components needed for operation are installed.

If components are installed that are not used for the intended purpose of the organization, this is a finding.

Fix

Identify the role the container platform is intended to play in the production environment and remove any components that are not needed or used for the intended purpose.

The container platform registry must contain only container images for those capabilities being offered by the container platform.

STIG ID: SRG-APP-000141-CTR-000320 | SRG: SRG-APP-000141 | Severity: medium | CCI: CCI-000381 | Vulnerability Id: V-233072

Vulnerability Discussion

Allowing container images to reside within the container platform registry that are not essential to the capabilities being offered by the container platform becomes a potential security risk. By allowing these non-essential container images to exist, the possibility for accidental instantiation exists. The images may be unpatched, not supported, or offer non-approved capabilities. Those images for customer services are considered essential capabilities.

Check

Review the container platform registry and the container images being stored.

If container images are stored in the registry and are not being used to offer container platform capabilities, this is a finding.

Fix

Remove all container images from the container platform registry that are not being used or contain features and functions not supported by the platform.

The container platform runtime must enforce ports, protocols, and services that adhere to the PPSM CAL.

STIG ID: SRG-APP-000142-CTR-000325 | SRG: SRG-APP-000142 | Severity: medium | CCI: CCI-000382 | Vulnerability Id: V-233073

Vulnerability Discussion

Ports, protocols, and services within the container platform runtime must be controlled and conform to the PPSM CAL. Those ports, protocols, and services that fall outside the PPSM CAL must be blocked by the runtime. Instructions on the PPSM can be found in DoD Instruction 8551.01 Policy.

Check

Review the container platform documentation and deployment configuration to determine which ports and protocols are enabled.

Verify the ports and protocols being used are not prohibited by PPSM CAL in accordance to DoD Instruction 8551.01 Policy and are necessary for the operations and applications.

If any of the ports or protocols is prohibited or not necessary for the operation, this is a finding.

Fix

Configure the container platform to disable any ports or protocols that are prohibited by the PPSM CAL and not necessary for the operation.

The container platform runtime must enforce the use of ports that are non-privileged.

STIG ID: SRG-APP-000142-CTR-000330 | SRG: SRG-APP-000142 | Severity: medium | CCI: CCI-000382 | Vulnerability Id: V-233074

Vulnerability Discussion

Privileged ports are those ports below 1024 and that require system privileges for their use. If containers are able to use these ports, the container must be run as a privileged user. The container platform must stop containers that try to map to these ports directly. Allowing non-privileged ports to be mapped to the container-privileged port is the allowable method when a certain port is needed. An example is mapping port 8080 externally to port 80 in the container.

Check

Review the container platform configuration and the containers within the platform by performing the following checks:

1. Verify the container platform is configured to disallow the use of privileged ports by containers.
2. Validate all containers within the container platform are using non-privileged ports.
3. Attempt to instantiate a container image that uses a privileged port.

If the container platform is not configured to disallow the use of privileged ports, this is a finding.

If the container platform has containers using privileged ports, this is a finding.

If the container platform allows containers to be instantiated that use privileged ports, this is a finding.

Fix

Configure the container platform to disallow the use of privileged ports by containers. Move any containers that are using privileged ports to non-privileged ports.

The container platform must uniquely identify and authenticate users.

STIG ID: SRG-APP-000148-CTR-000335 | SRG: SRG-APP-000148 | Severity: medium | CCI: CCI-000764 | Vulnerability Id: V-233075

Vulnerability Discussion

The container platform requires user accounts to perform container platform tasks. These tasks may pertain to the overall container platform or may be component-specific, thus requiring users to authenticate against those specific components. To ensure accountability and prevent unauthenticated access, users must be identified and authenticated to prevent potential misuse and compromise of the system.

Check

Review the container platform configuration to determine if users are uniquely identified and authenticated.

If users are not uniquely identified or are not authenticated, this is a finding.

Fix

Configure the container platform to uniquely identify and authenticate users.

The container platform application program interface (API) must uniquely identify and authenticate users.

STIG ID: SRG-APP-000148-CTR-000340 | SRG: SRG-APP-000148 | Severity: medium | CCI: CCI-000764 | Vulnerability Id: V-233076

Vulnerability Discussion

The container platform requires user accounts to perform container platform tasks. These tasks are often performed through the container platform API. Protecting the API from users who are not authorized or authenticated is essential to keep the container platform stable. Protection of platform and application data and enhances the protections put in place for Denial-of Service (DoS) attacks.

Check

Review the container platform configuration to determine if users are uniquely identified and authenticated before the API is executed.

If users are not uniquely identified or are not authenticated, this is a finding.

Fix

Configure the container platform to uniquely identify and authenticate users before container platform API access.

The container platform must uniquely identify and authenticate processes acting on behalf of the users.

STIG ID: SRG-APP-000148-CTR-000345 | SRG: SRG-APP-000148 | Severity: medium | CCI: CCI-000764 | Vulnerability Id: V-233077

Vulnerability Discussion

The container platform will instantiate a container image and use the user privileges given to the user used to execute the container. To ensure accountability and prevent unauthenticated access to containers, the user the container is using to execute must be uniquely identified and authenticated to prevent potential misuse and compromise of the system.

Check

Review the container platform configuration to determine if processes acting on behalf of users are uniquely identified and authenticated.

If processes acting on behalf of users are not uniquely identified or are not authenticated, this is a finding.

Fix

Configure the container platform to uniquely identify and authenticate processes acting on behalf of users.

The container platform application program interface (API) must uniquely identify and authenticate processes acting on behalf of the users.

STIG ID: SRG-APP-000148-CTR-000350 | SRG: SRG-APP-000148 | Severity: medium | CCI: CCI-000764 | Vulnerability Id: V-233078

Vulnerability Discussion

The container platform API can be used to perform any task within the platform. Often, the API is used to create tasks that perform some kind of maintenance task and run without user interaction. To guarantee the task is authorized, it is important to authenticate the task. These tasks, even though executed without user intervention, run on behalf of a user and must run with the user's authorization. If tasks are allowed to be created without authentication, users could bypass authentication and authorization mechanisms put in place for user interfaces. This could lead to users gaining greater access than given to the user putting the container platform into a compromised state.

Check

Review the container platform API configuration to determine if processes acting on behalf of users are uniquely identified and authenticated.

If processes acting on behalf of users are not uniquely identified or are not authenticated, this is a finding.

Fix

Configure the container platform API to uniquely identify and authenticate processes acting on behalf of users.

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

STIG ID: SRG-APP-000149-CTR-000355 | SRG: SRG-APP-000149 | Severity: medium | CCI: CCI-000765 | Vulnerability Id: V-233079

Vulnerability Discussion

Without the use of multifactor authentication, the ease of access to privileged functions is greatly increased.

Multifactor authentication requires using two or more factors to achieve authentication.

Factors include:
(i) something a user knows (e.g., password/PIN);
(ii) something a user has (e.g., cryptographic identification device, token); or
(iii) something a user is (e.g., biometric).

A privileged account is defined as an information system account with authorizations of a privileged user.

Network access is defined as access to an information system by a user (or a process acting on behalf of a user) communicating through a network (e.g., local area network, wide area network, or the internet).

Check

Review the container platform configuration to determine if the container platform is configured to use multifactor authentication for network access to privileged accounts.

If the container platform does not use multifactor authentication for network access to privileged accounts, this is a finding.

Fix

Configure the container platform to use multifactor authentication for network access to privileged accounts.

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

STIG ID: SRG-APP-000150-CTR-000360 | SRG: SRG-APP-000150 | Severity: medium | CCI: CCI-000766 | Vulnerability Id: V-233080

Vulnerability Discussion

To ensure accountability and prevent unauthenticated access, non-privileged 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-privileged account is any information system account with authorizations of a non-privileged 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 DoD Active Directory and utilize the DoD CAC are examples of compliant multifactor authentication solutions.

Check

Review the container platform configuration to determine if the container platform is configured to use multifactor authentication for network access to non-privileged accounts.

If the container platform does not use multifactor authentication for network access to non-privileged accounts, this is a finding.

Fix

Configure the container platform to use multifactor authentication for network access to non-privileged accounts.

The container platform must use multifactor authentication for local access to privileged accounts.

STIG ID: SRG-APP-000151-CTR-000365 | SRG: SRG-APP-000151 | Severity: medium | CCI: CCI-000765 | Vulnerability Id: V-233081

Vulnerability Discussion

To ensure accountability and prevent unauthenticated access, privileged users must utilize multifactor authentication to prevent potential misuse and compromise of the system.

Multifactor authentication is defined as using two or more factors to achieve authentication.

Factors include:
(i) Something a user knows (e.g., password/PIN);
(ii) Something a user has (e.g., cryptographic identification device, token); or
(iii) Something a user is (e.g., biometric).

A privileged account is defined as an information system account with authorizations of a privileged user.

Local access is defined as access to an organizational information system by a user (or process acting on behalf of a user) communicating through a direct connection without the use of a network.

Check

Review the container platform configuration to determine if multifactor authentication is used for local access to privileged accounts.

If multifactor authentication for local access to privileged accounts is not being used, this is a finding.

Fix

Configure the container platform to use multifactor authentication for local access to privileged accounts.

The container platform must use multifactor authentication for local access to nonprivileged accounts.

STIG ID: SRG-APP-000152-CTR-000370 | SRG: SRG-APP-000152 | Severity: medium | CCI: CCI-000766 | Vulnerability Id: V-233082

Vulnerability Discussion

To ensure accountability, prevent unauthenticated access, and prevent misuse of the system, nonprivileged users must utilize multi-factor authentication for local access.

Multifactor authentication is defined as using two or more factors to achieve authentication.

Factors include:
(i) Something a user knows (e.g., password/PIN);
(ii) Something a user has (e.g., cryptographic identification device, token); or
(iii) Something a user is (e.g., biometric).

A nonprivileged account is defined as an information system account with authorizations of a regular or nonprivileged user.

Local access is defined as access to an organizational information system by a user (or process acting on behalf of a user) communicating through a direct connection without the use of a network.

Check

Review the container platform configuration to determine if multifactor authentication is used for local access to nonprivileged accounts.

If multifactor authentication for local access to nonprivileged accounts is not being used, this is a finding.

Fix

Configure the container platform to use multifactor authentication for local access to nonprivileged accounts.

The container platform must ensure users are authenticated with an individual authenticator prior to using a group authenticator.

STIG ID: SRG-APP-000153-CTR-000375 | SRG: SRG-APP-000153 | Severity: medium | CCI: CCI-004045 | Vulnerability Id: V-233083

Vulnerability Discussion

To ensure individual accountability and prevent unauthorized access, application users must be individually identified and authenticated.

Individual accountability mandates that each user be uniquely identified. A group authenticator is a shared account or some other form of authentication that allows multiple unique individuals to access the application using a single account.

If an application allows or provides for group authenticators, it must first individually authenticate users prior to implementing group authenticator functionality.

Some applications may not need to provide a group authenticator; this is considered a matter of application design. In those instances where the application design includes the use of a group authenticator, this requirement will apply.

There may also be instances when specific user actions need to be performed on the information system without unique user identification or authentication. An example of this type of access is a web server, which contains publicly releasable information.

Check

Review the container platform configuration to determine if the container platform is configured to ensure users are authenticated with an individual authenticator prior to using a group authenticator.

If the container platform is not configured to ensure users are authenticated with an individual authenticator prior to using a group authenticator, this is a finding.

Fix

Configure the container platform to ensure users are authenticated with an individual authenticator prior to using a group authenticator.

The container platform must use FIPS-validated SHA-1 or higher hash function to provide replay-resistant authentication mechanisms for network access to privileged accounts.

STIG ID: SRG-APP-000156-CTR-000380 | SRG: SRG-APP-000156 | Severity: medium | CCI: CCI-001941 | Vulnerability Id: V-233084

Vulnerability 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 DoD 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.

Check

Review the container platform configuration to determine if the container platform is configured to use FIPS-validated SHA-1 or higher hash function to provide replay-resistant authentication mechanisms for network access to privileged accounts.

If the container platform is not configured to use FIPS-validated SHA-1 or higher hash function to provide replay-resistant authentication mechanisms for network access to privileged accounts, this is a finding.

Fix

Configure the container platform to use FIPS-validated SHA-1 or higher hash function to provide replay-resistant authentication mechanisms for network access to privileged accounts.

The container platform must implement replay-resistant authentication mechanisms for network access to nonprivileged accounts.

STIG ID: SRG-APP-000157-CTR-000385 | SRG: SRG-APP-000157 | Severity: medium | CCI: CCI-001941 | Vulnerability Id: V-233085

Vulnerability 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.

An authentication process resists replay attacks if it is impractical to achieve a successful authentication by recording and replaying a previous authentication message.

A nonprivileged account is any operating system account with authorizations of a nonprivileged user.

Techniques used to address this include protocols using nonces (e.g., numbers generated for a specific one-time use) or challenges (e.g., TLS, WS_Security). Additional techniques include time-synchronous or challenge-response one-time authenticators.

Check

Review the container platform configuration to determine if the container platform is configured to provide replay-resistant authentication mechanisms for network access to nonprivileged accounts.

If the container platform is not configured to provide replay-resistant authentication mechanisms for network access to nonprivileged accounts, this is a finding.

Fix

Configure the container platform to provide replay-resistant authentication mechanisms for network access to nonprivileged accounts.

The container platform must uniquely identify all network-connected nodes before establishing any connection.

STIG ID: SRG-APP-000158-CTR-000390 | SRG: SRG-APP-000158 | Severity: medium | CCI: CCI-000778 | Vulnerability Id: V-233086

Vulnerability Discussion

A container platform usually consists of multiple nodes. It is important for these nodes to be uniquely identified before a connection is allowed. Without identifying the nodes, unidentified or unknown nodes may be introduced, thereby facilitating malicious activity.

Check

Review the container platform configuration to determine if the container platform uniquely identifies all nodes before establishing a connection.

If the container platform is not configured to uniquely identify all nodes before establishing the connection, this is a finding.

Fix

Configure the container platform to uniquely identify all nodes before establishing the connection.

The container platform must disable identifiers (individuals, groups, roles, and devices) after 35 days of inactivity.

STIG ID: SRG-APP-000163-CTR-000395 | SRG: SRG-APP-000163 | Severity: medium | CCI: CCI-003627 | Vulnerability Id: V-233087

Vulnerability Discussion

Inactive identifiers pose a risk to systems and applications. Attackers that are able to exploit an inactive identifier can potentially obtain and maintain undetected access to the application. Owners of inactive accounts will not notice if unauthorized access to their user account has been obtained.

Applications need to track periods of inactivity and disable application identifiers after 35 days of inactivity.

Management of user identifiers is not applicable to shared information system accounts (e.g., guest and anonymous accounts). It is commonly the case that a user account is the name of an information system account associated with an individual.

To avoid having to build complex user management capabilities directly into their application, wise developers leverage the underlying OS or other user account management infrastructure (AD, LDAP) that is already in place within the organization and meets organizational user account management requirements.

Check

Review the container platform configuration to determine if the container platform is configured to disable identifiers (individuals, groups, roles, and devices) after 35 days of inactivity.

If identifiers are not disabled after 35 days of inactivity, this is a finding.

Fix

Configure the container platform to disable identifiers (individuals, groups, roles, and devices) after 35 days of inactivity.

The container platform must enforce a minimum 15-character password length.

STIG ID: SRG-APP-000164-CTR-000400 | SRG: SRG-APP-000164 | Severity: medium | CCI: CCI-004066 | Vulnerability Id: V-233088

Vulnerability Discussion

The shorter the password, the lower the number of possible combinations that need to be tested before the password is compromised.

Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks. Password length is one factor of several that helps to determine strength and how long it takes to crack a password. The shorter the password, the lower the number of possible combinations that need to be tested before the password is compromised.

Use of more characters in a password helps to exponentially increase the time and/or resources required to compromise the password.

Check

Review the container platform configuration to determine if the container platform enforces a minimum 15-character password length.

If the container platform does not enforce a 15-character password length, this is a finding.

Fix

Configure the container platform to enforce a minimum 15-character password length.

The container platform must enforce password complexity by requiring that at least one uppercase character be used.

STIG ID: SRG-APP-000166-CTR-000410 | SRG: SRG-APP-000166 | Severity: medium | CCI: CCI-004066 | Vulnerability Id: V-233090

Vulnerability Discussion

Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks.

Password complexity is one factor of several that determine how long it takes to crack a password. The more complex the password is, the greater the number of possible combinations that need to be tested before the password is compromised.

Check

Review the container platform configuration to determine if it enforces password complexity by requiring that at least one uppercase character be used.

If the container platform does not enforce password complexity by requiring that at least one uppercase character be used, this is a finding.

Fix

Configure the container platform to enforce password complexity by requiring that at least one uppercase character be used.

The container platform must enforce password complexity by requiring that at least one lowercase character be used.

STIG ID: SRG-APP-000167-CTR-000415 | SRG: SRG-APP-000167 | Severity: medium | CCI: CCI-004066 | Vulnerability Id: V-233091

Vulnerability Discussion

Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks.

Password complexity is one factor of several that determine how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised.

Check

Review the container platform configuration to determine if it enforces password complexity by requiring that at least one lowercase character be used.

If the container platform does not enforce password complexity by requiring that at least one lowercase character be used, this is a finding.

Fix

Configure the container platform to enforce password complexity by requiring that at least one lowercase character be used.

The container platform must enforce password complexity by requiring that at least one numeric character be used.

STIG ID: SRG-APP-000168-CTR-000420 | SRG: SRG-APP-000168 | Severity: medium | CCI: CCI-004066 | Vulnerability Id: V-233092

Vulnerability Discussion

Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks.

Password complexity is one factor of several that determine how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised.

Check

Review the container platform configuration to determine if it enforces password complexity by requiring that at least one numeric character be used.

If the container platform does not enforce password complexity by requiring that at least one numeric character be used, this is a finding.

Fix

Configure the container platform to enforce password complexity by requiring that at least one numeric character be used.

The container platform must enforce password complexity by requiring that at least one special character be used.

STIG ID: SRG-APP-000169-CTR-000425 | SRG: SRG-APP-000169 | Severity: medium | CCI: CCI-004066 | Vulnerability Id: V-233093

Vulnerability Discussion

Use of a complex password helps to increase the time and resources required to compromise the password. Password complexity, or strength, is a measure of the effectiveness of a password in resisting attempts at guessing and brute-force attacks.

Password complexity is one factor in determining how long it takes to crack a password. The more complex the password, the greater the number of possible combinations that need to be tested before the password is compromised.

Special characters are those characters that are not alphanumeric. Examples include ~ ! @ # $ % ^ *.

Check

Review the container platform configuration to determine if it enforces password complexity by requiring that at least one special character be used.

If the container platform does not enforce password complexity by requiring that at least one special character be used, this is a finding.

Fix

Configure the container platform to enforce password complexity by requiring that at least one special character be used.

The container platform must require the change of at least 15 of the total number of characters when passwords are changed.

STIG ID: SRG-APP-000170-CTR-000430 | SRG: SRG-APP-000170 | Severity: medium | CCI: CCI-004066 | Vulnerability Id: V-233094

Vulnerability Discussion

If the application allows the user to consecutively reuse extensive portions of passwords, this increases the chances of password compromise by increasing the window of opportunity for attempts at guessing and brute-force attacks.

The number of changed characters refers to the number of changes required with respect to the total number of positions in the current password. In other words, characters may be the same within the two passwords; however, the positions of the like characters must be different.

Check

Review the container platform configuration to determine if it requires the change of at least 15 of the total number of characters when passwords are changed.

If the container platform does not require the change of at least 15 of the total number of characters when passwords are changed, this is a finding.

Fix

Configure the container platform to require the change of at least 15 of the total number of characters when passwords are changed.

For container platform using password authentication, the application must store only cryptographic representations of passwords.

STIG ID: SRG-APP-000171-CTR-000435 | SRG: SRG-APP-000171 | Severity: medium | CCI: CCI-004062 | Vulnerability Id: V-233095

Vulnerability 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 DOD employee, member of the military, or DOD 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.

Check

Review the container platform configuration to determine if it using password authentication and stores only cryptographic representations of the passwords.

If the container platform is using password authentication and does not store only cryptographic representations of passwords, this is a finding.

Fix

Configure the container platform to store only cryptographic representations of passwords if passwords are being used for authentication.

For accounts using password authentication, the container platform must use FIPS-validated SHA-2 or later protocol to protect the integrity of the password authentication process.

STIG ID: SRG-APP-000172-CTR-000440 | SRG: SRG-APP-000172 | Severity: high | CCI: CCI-000197 | Vulnerability Id: V-233096

Vulnerability Discussion

Passwords need to be protected on entry, in transmission, during authentication, and when stored. If compromised at any of these security points, a nefarious user can use the password along with stolen user account information to gain access or to escalate privileges. The container platform may require account authentication during container platform tasks and before accessing container platform components, e.g. runtime, registry, and keystore.

During any user authentication, the container platform must use FIPS-validated SHA-2 or later protocol to protect the integrity of the password authentication process.

Check

Review the documentation and configuration to determine if the container platform enforces the required FIPS-validated encrypt passwords when they are transmitted.

If the container platform is not configured to meet this requirement, this is a finding.

Fix

Configure the container platform to transmit only encrypted FIPS-validated SHA-2 or later representations of passwords.

The container platform must enforce 24 hours (one day) as the minimum password lifetime.

STIG ID: SRG-APP-000173-CTR-000445 | SRG: SRG-APP-000173 | Severity: medium | CCI: CCI-004066 | Vulnerability Id: V-233097

Vulnerability Discussion

Enforcing a minimum password lifetime helps prevent repeated password changes to defeat the password reuse or history enforcement requirement.

Restricting this setting limits the user's ability to change their password. Passwords need to be changed at specific policy-based intervals; however, if the application allows the user to immediately and continually change their password, then the password could be repeatedly changed in a short period of time to defeat the organization's policy regarding password reuse.

Check

Review the container platform configuration to determine if it enforces 24 hours/1 day as the minimum password lifetime.

If the container platform does not enforce 24 hours/1 day as the minimum password lifetime, this is a finding.

Fix

Configure the container platform to enforce 24 hours/1 day as the minimum password lifetime.

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

STIG ID: SRG-APP-000174-CTR-000450 | SRG: SRG-APP-000174 | Severity: medium | CCI: CCI-004066 | Vulnerability Id: V-233098

Vulnerability Discussion

Any password, no matter how complex, can eventually be cracked; therefore, passwords need to be changed at specific intervals.

One method of minimizing this risk is to use complex passwords and periodically change them. If the application does not limit the lifetime of passwords and force users to change their passwords, there is the risk that the system and/or application passwords could be compromised.

This requirement does not include emergency administration accounts that are meant for access to the application in case of failure. These accounts are not required to have maximum password lifetime restrictions.

Check

Review the container platform configuration to determine if it enforces a 60-day maximum password lifetime restriction.

If the container platform does not enforce a 60-day maximum password lifetime restriction, this is a finding.

Fix

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

The container platform must map the authenticated identity to the individual user or group account for PKI-based authentication.

STIG ID: SRG-APP-000177-CTR-000465 | SRG: SRG-APP-000177 | Severity: medium | CCI: CCI-000187 | Vulnerability Id: V-233101

Vulnerability Discussion

The container platform and its components may require authentication before use. When the authentication is PKI-based, the container platform or component must map the certificate to a user account. If the certificate is not mapped to a user account, the ability to determine the identity of the individual user or group will not be available for forensic analysis.

Check

Review documentation and configuration to ensure the container platform provides a PKI integration capability that meets DoD PKI infrastructure requirements.

If the container platform is not configured to meet this requirement, this is a finding.

Fix

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

The container platform must obscure feedback of authentication information during the authentication process to protect the information from possible exploitation/use by unauthorized individuals.

STIG ID: SRG-APP-000178-CTR-000470 | SRG: SRG-APP-000178 | Severity: medium | CCI: CCI-000206 | Vulnerability Id: V-233102

Vulnerability Discussion

To prevent the compromise of authentication information such as passwords during the authentication process, the feedback from the container platform and its components, e.g., runtime, registry, and keystore, must not provide any information that would allow an unauthorized user to compromise the authentication mechanism.

Obfuscation of user-provided information when typed is a method used in addressing this risk.

Displaying asterisks when a user types in a password is an example of obscuring feedback of authentication information.

Check

Review container platform documentation and configuration to determine if any interfaces that are provided for authentication purposes display the user's password when it is typed into the data entry field.

If authentication information is not obfuscated when entered, this is a finding.

Fix

Configure the container platform to obscure feedback of authentication information during the authentication process to protect the information from possible exploitation/use by unauthorized individuals.

The container platform must provide an audit reduction capability that supports on-demand reporting requirements.

STIG ID: SRG-APP-000181-CTR-000485 | SRG: SRG-APP-000181 | Severity: medium | CCI: CCI-001876 | Vulnerability Id: V-233105

Vulnerability Discussion

The ability to generate on-demand reports, including after the audit data has been subjected to audit reduction, greatly facilitates the organization's ability to generate incident reports as needed to better handle larger-scale or more complex security incidents.

Audit reduction is a process that manipulates collected audit information and organizes such information in a summary format that is more meaningful to analysts. The report generation capability provided by the application must support on-demand (i.e., customizable, ad hoc, and as-needed) reports.

This requirement is specific to applications with audit reduction capabilities; however, applications need to support on-demand audit review and analysis.

Check

Review the container platform configuration to determine if the container platform is configured to provide an audit reduction capability that supports on-demand reporting requirements.

If the container platform is not configured to support on-demand reporting requirements, this is a finding.

Fix

Configure the container platform to support on-demand reporting requirements.

The container platform must employ strong authenticators in the establishment of non-local maintenance and diagnostic sessions.

STIG ID: SRG-APP-000185-CTR-000490 | SRG: SRG-APP-000185 | Severity: medium | CCI: CCI-000877 | Vulnerability Id: V-233106

Vulnerability Discussion

If maintenance tools are used by unauthorized personnel, they may accidentally or intentionally damage or compromise the system. The act of managing systems and applications includes the ability to access sensitive application information, such as, system configuration details, diagnostic information, user information, and potentially sensitive application data.

Non-local maintenance and diagnostic activities are those activities conducted by individuals communicating through a network, either an external network (e.g., the internet) or an internal network. Local maintenance and diagnostic activities are those activities carried out by individuals physically present at the information system or information system component and not communicating across a network connection. Typically, strong authentication requires authenticators that are resistant to replay attacks and employ multifactor authentication. Strong authenticators include, for example, PKI where certificates are stored on a token protected by a password, passphrase, or biometric.

This requirement applies to hardware/software diagnostic test equipment or tools. This requirement does not cover hardware/software components that may support information system maintenance, yet are a part of the system (e.g., the software implementing "ping," "ls," "ipconfig," or the hardware and software implementing the monitoring port of an Ethernet switch).

Check

Review the container platform configuration to determine if the container platform is configured to employ strong authenticators in the establishment of non-local maintenance and diagnostic sessions.

If the container platform is not configured to employ strong authenticators in the establishment of non-local maintenance and diagnostic sessions, this is a finding.

Fix

Configure the container platform to employ strong authenticators in the establishment of non-local maintenance and diagnostic sessions.

The application must terminate all network connections associated with a communications session at the end of the session, or as follows: for in-band management sessions (privileged sessions), the session must be terminated after 10 minutes of inactivity.

STIG ID: SRG-APP-000190-CTR-000500 | SRG: SRG-APP-000190 | Severity: medium | CCI: CCI-001133 | Vulnerability Id: V-233108

Vulnerability Discussion

Terminating an idle session within a short time period reduces the window of opportunity for unauthorized personnel to take control of a management session enabled on the console or console port that has been left unattended. In addition, quickly terminating an idle session will also free up resources committed by the managed network element.

Terminating network connections associated with communications sessions includes, for example, de-allocating associated TCP/IP address/port pairs at the operating system level, or de-allocating networking assignments at the application level if multiple application sessions are using a single, operating system level network connection. This does not mean that the application terminates all sessions or network access; it only ends the inactive session and releases the resources associated with that session.

Check

Review documentation and configuration settings to determine if the container platform is configured to close user sessions after defined conditions or trigger events are met.

If the container platform is not configured or cannot be configured to disconnect users after defined conditions and trigger events are met, this is a finding.

Fix

Configure the container platform to terminate user sessions on defined conditions or trigger events.

The container platform must separate user functionality (including user interface services) from information system management functionality.

STIG ID: SRG-APP-000211-CTR-000530 | SRG: SRG-APP-000211 | Severity: medium | CCI: CCI-001082 | Vulnerability Id: V-233114

Vulnerability Discussion

Separating user functionality from management functionality is a requirement for all the components within the container platform. Without the separation, users may have access to management functions that can degrade the container platform and the services being offered and can offer a method to bypass testing and validation of functions before introduced into a production environment.

The separation should be enforced by each component within the container platform.

Check

Review the container platform configuration to determine if management functionality is separated from user functionality.

Validate that the separation is also implemented within the components by trying to execute management functions for each component as a user.

If the container platform is not configured to separate management and user functionality or if component management and user functionality are not separated, this is a finding.

Fix

Configure the container platform and its components to separate management and user functionality.

The container platform must protect authenticity of communications sessions with the use of FIPS-validated 140-2 or 140-3 security requirements for cryptographic modules.

STIG ID: SRG-APP-000219-CTR-000550 | SRG: SRG-APP-000219 | Severity: high | CCI: CCI-001184 | Vulnerability Id: V-233118

Vulnerability Discussion

The container platform is responsible for pulling images from trusted sources and placing those images into its registry. To protect the transmission of images, the container platform must use FIPS-validated 140-2 or 140-3 cryptographic modules. This added protection defends against main-in-the-middle attacks where malicious code could be added to an image during transmission.

Check

Review the container platform configuration to determine if FIPS-validated 140-2 or 140-3 cryptographic modules are being used to protect container images during transmission.

If FIPS-validated 140-2 or 140-3 cryptographic modules are not being use, this is a finding.

Fix

Configure the container platform to use FIPS-validated 140-2 or 140-3 cryptographic modules to protect container images during transmission.

The container platform runtime must fail to a secure state if system initialization fails, shutdown fails, or aborts fail.

STIG ID: SRG-APP-000225-CTR-000570 | SRG: SRG-APP-000225 | Severity: medium | CCI: CCI-001190 | Vulnerability Id: V-233122

Vulnerability Discussion

The container platform offers services for container image orchestration and services for users. If any of these services were to fail into an insecure state, security measures for user and data separation and image instantiation could become absent. In addition, audit log protections could be relaxed allowing for investigation of what occurred could be lost. To protect services and data, it is important for the container platform to fail to a secure state if the container platform registry initialization fails, shutdown fails, or aborts fail.

Check

Review documentation and configuration to determine if the container platform runtime fails to a secure state if system initialization fails, shutdown fails, or aborts fail.

If the container platform runtime cannot be configured to fail securely, this is a finding.

Fix

Configure the container platform runtime to fail to a secure state if system initialization fails, shutdown fails, or aborts fail.

The container platform must preserve any information necessary to determine the cause of the disruption or failure.

STIG ID: SRG-APP-000226-CTR-000575 | SRG: SRG-APP-000226 | Severity: medium | CCI: CCI-001665 | Vulnerability Id: V-233123

Vulnerability Discussion

When a failure occurs within the container platform, preserving the state of the container platform and its components, along with other container services, helps to facilitate container platform restart and return to the operational mode of the organization with less disruption to mission essential processes. When preserving state, considerations for preservation of data confidentiality and integrity must be taken into consideration.

Check

Review the container platform configuration to determine if information necessary to determine the cause of a disruption or failure is preserved.

If the information is not preserved, this is a finding.

Fix

Configure the container platform to preserve information necessary to determine the cause of the disruption or failure.

The container platform runtime must isolate security functions from non-security functions.

STIG ID: SRG-APP-000233-CTR-000585 | SRG: SRG-APP-000233 | Severity: medium | CCI: CCI-001084 | Vulnerability Id: V-233125

Vulnerability Discussion

The container platform runtime must be configured to isolate those services used for security functions from those used for non-security functions. This separation can be performed using environment variables, labels, network segregation, and kernel groups.

Check

Verify container platform runtime configuration settings to determine whether container services used for security functions are located in an isolated security function such as a separate environment variables, labels, network segregation, and kernel groups.

If security-related functions are not separate, this is a finding.

Fix

Configure the container platform runtime to isolate security functions from non-security functions.

The container platform must never automatically remove or disable emergency accounts.

STIG ID: SRG-APP-000234-CTR-000590 | SRG: SRG-APP-000234 | Severity: medium | CCI: CCI-001682 | Vulnerability Id: V-233126

Vulnerability Discussion

Emergency accounts are administrator accounts that are established in response to crisis situations where the need for rapid account activation is required. Therefore, emergency account activation may bypass normal account authorization processes. If these accounts are automatically disabled, system maintenance during emergencies may not be possible, thus adversely affecting system availability.

Emergency accounts are different from infrequently used accounts (i.e., local logon accounts used by system administrators when network or normal logon/access is not available). Infrequently used accounts also remain available and are not subject to automatic termination dates. However, an emergency account is normally a different account that is created for use by vendors or system maintainers.

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.

Check

Review the container platform to determine if emergency accounts are automatically removed or disabled.

If emergency accounts are automatically removed or disabled, this is a finding.

Fix

Configure the container platform to never remove or disable emergency accounts.

The container platform must prohibit containers from accessing privileged resources.

STIG ID: SRG-APP-000243-CTR-000595 | SRG: SRG-APP-000243 | Severity: medium | CCI: CCI-001090 | Vulnerability Id: V-233127

Vulnerability Discussion

Containers images instantiated within the container platform may request access to host system resources. Access to privileged resources can allow for unauthorized and unintended transfer of information, but in some cases, these resources may be needed for the service being offered by the container. By default, containers should be denied instantiation when privileged system resources are requested and granted only after approval has been given.

When access to privileged resources is necessary for a container, a new policy for execution should be written for the container. The default behavior must not give containers privileged access to host system resources.

Examples of system resources that should be protected are kernel namespaces and host system sensitive directories such as /etc and /usr.

Check

Review documentation and configuration to determine if the container platform disallows instantiation of containers trying to access host system privileged resources.

If the container platform does not block containers requesting host system privileged resources, this is a finding.

Fix

Configure the container platform to block instantiation of containers requesting access to host system-privileged resources.

The container platform must prevent unauthorized and unintended information transfer via shared system resources.

STIG ID: SRG-APP-000243-CTR-000600 | SRG: SRG-APP-000243 | Severity: medium | CCI: CCI-001090 | Vulnerability Id: V-233128

Vulnerability Discussion

The container platform makes host system resources available to container services. These shared resources, such as the host system kernel, network connections, and storage, must be protected to prevent unauthorized and unintended information transfer. The protections must be implemented for users and processes acting on behalf of users.

Check

Review the container platform architecture documentation to find out if and how it protects the resources of one process or user (such as working memory, storage, host system kernel, network connections) from unauthorized access by another user or process.

If the container platform configuration settings do not effectively implement these protections to prevent unauthorized access by another user or process, this is a finding.

Fix

Deploy a container platform capable of effectively protecting the resources of one process or user from unauthorized access by another user or process. Configure the container platform to effectively protect the resources of one process or user from unauthorized access by another user or process. The container security solution should help the user understand where the code in the environment was deployed from, and provide controls that prevent deployment from untrusted sources or registries.

The container platform must restrict individuals' ability to launch organizationally defined denial-of-service (DoS) attacks against other information systems.

STIG ID: SRG-APP-000246-CTR-000605 | SRG: SRG-APP-000246 | Severity: medium | CCI: CCI-001094 | Vulnerability Id: V-233129

Vulnerability Discussion

The container platform will offer services to users and these services share resources available on the hosting system. To share the resources in a manner that does not exhaust or over utilize resources, it is necessary for the container platform to have mechanisms that allow developers to size there containers to provide minimum and maximum amounts. If there is no mechanism to specify limits, container services can cause DoS by over utilization.

Check

Review the container platform implementation and security documentation and components settings to determine if the information system restricts the ability of users or systems to launch organization-defined DoS attacks against other information systems or networks from the container platform.

If the container platform is not configured to restrict this ability, this is a finding.

Fix

Configure the container platform to restrict the ability of users or other systems to launch DoS attacks from the container platform components by setting resource quotas on resources such as memory, storage, and CPU utilization.

The container must have resource request limits set.

STIG ID: SRG-APP-000247-CTR-000330 | SRG: SRG-APP-000247 | Severity: medium | CCI: CCI-001095 | Vulnerability Id: V-270875

Vulnerability Discussion

Setting a container resource request limit allows the container platform to determine the best location for the container to execute. The container platform looks at the resources available and finds the location that will require the minimum resources for the container to execute. Examples of resources that can be specified are CPU, memory, and storage.

Check

Review the container platform configuration to determine that resource limits are set.

If the container platform does not enforce resource limits, this is a finding.

Fix

Configure the container platform to restrict the ability of users or other systems to launch denial-of-service (DoS) attacks from the container platform components by setting resource limits on resources such as memory, storage, and CPU utilization.

The container platform must generate error messages that provide information necessary for corrective actions without revealing information that could be exploited by adversaries.

STIG ID: SRG-APP-000266-CTR-000625 | SRG: SRG-APP-000266 | Severity: medium | CCI: CCI-001312 | Vulnerability Id: V-233133

Vulnerability Discussion

The container platform is responsible for offering services to users. These services could be across diverse user groups and data types. To protect information about the container platform, services, users, and data, it is important during error message generation to offer enough information to diagnose the error, but not reveal information that needs to be protected.

Check

Review documentation and logs to determine if the container platform writes sensitive information such as passwords or private keys into the logs and administrative messages.

If the container platform writes sensitive or potentially harmful information into the logs and administrative messages, this is a finding.

Fix

Configure the container platform to not write sensitive information into the logs and administrative messages.

The container platform must use cryptographic mechanisms to protect the integrity of audit tools.

STIG ID: SRG-APP-000290-CTR-000670 | SRG: SRG-APP-000290 | Severity: medium | CCI: CCI-001496 | Vulnerability Id: V-233142

Vulnerability Discussion

Protecting the integrity of the tools used for auditing purposes is a critical step to ensuring the integrity of audit data. Audit data includes all information (e.g., audit records, audit settings, and audit reports) needed to successfully audit information system activity.

Audit tools include, but are not limited to, vendor provided and open source audit tools needed to successfully view and manipulate audit information system activity and records. Audit tools include custom queries and report generators.

It is common for attackers to replace the audit tools or inject code into the existing tools with the purpose of providing the capability to hide or erase system activity from the audit logs.

To address this risk, audit tools must be cryptographically signed in order to provide the capability to identify when the audit tools have been modified, manipulated, or replaced. An example is a checksum hash of the file or files.

Check

Review the container platform configuration to determine if the integrity of the audit tools is protected using cryptographic mechanisms.

If audit tools are not protected through cryptographic mechanisms, this is a finding.

Fix

Configure the container platform to use cryptographic mechanisms to protect the integrity of audit tools.

The container platform must notify system administrators (SAs) and the information system security officer (ISSO) when accounts are created.

STIG ID: SRG-APP-000291-CTR-000675 | SRG: SRG-APP-000291 | Severity: medium | CCI: CCI-000015 | Vulnerability Id: V-233143

Vulnerability Discussion

Check

Review the container platform configuration to determine if system administrators and ISSO are notified when accounts are created.

If SAs and ISSO are not notified, this is a finding.

Fix

Configure the container platform to notify SAs and ISSO when accounts are created.

The container platform must notify system administrators (SAs) and the information system security officer (ISSO) when accounts are modified.

STIG ID: SRG-APP-000292-CTR-000680 | SRG: SRG-APP-000292 | Severity: medium | CCI: CCI-000015 | Vulnerability Id: V-233144

Vulnerability Discussion

When application accounts are modified, user accessibility is affected. Accounts are utilized for identifying individual users or for identifying the application processes themselves. Sending notification of account modification events to the system administrator and ISSO is one method for mitigating this risk. Such a capability greatly reduces the risk that application accessibility will be negatively affected for extended periods of time and provides logging that can be used for forensic purposes.

To address access requirements, many operating systems can be integrated with enterprise-level authentication/access/auditing mechanisms that meet or exceed access control policy requirements.

Check

Review the container platform configuration to determine if system administrators and ISSO are notified when accounts are modified.

If system administrators and ISSO are not notified, this is a finding.

Fix

Configure the container platform to notify system administrators and ISSO when accounts are modified.

The container platform must notify system administrators and ISSO for account disabling actions.

STIG ID: SRG-APP-000293-CTR-000685 | SRG: SRG-APP-000293 | Severity: medium | CCI: CCI-000015 | Vulnerability Id: V-233145

Vulnerability Discussion

When application accounts are disabled, user accessibility is affected. Accounts are utilized for identifying individual users or for identifying the application processes themselves. Sending notification of account disabling events to the system administrator and ISSO is one method for mitigating this risk. Such a capability greatly reduces the risk that application accessibility will be negatively affected for extended periods of time and provides logging that can be used for forensic purposes.

To address access requirements, many operating systems can be integrated with enterprise-level authentication/access/auditing mechanisms that meet or exceed access control policy requirements.

Check

Review the container platform configuration to determine if system administrators and ISSO are notified when accounts are disabled.

If system administrators and ISSO are not notified, this is a finding.

Fix

Configure the container platform to notify system administrators and ISSO when accounts are disabled.

The container platform must notify system administrators and ISSO for account removal actions.

STIG ID: SRG-APP-000294-CTR-000690 | SRG: SRG-APP-000294 | Severity: medium | CCI: CCI-000015 | Vulnerability Id: V-233146

Vulnerability Discussion

When application accounts are removed, user accessibility is affected. Accounts are utilized for identifying users or for identifying the application processes themselves. Sending notification of account removal events to the system administrator and ISSO is one method for mitigating this risk. Such a capability greatly reduces the risk that application accessibility will be negatively affected for extended periods of time, and provides logging that can be used for forensic purposes.

To address access requirements, many operating systems can be integrated with enterprise-level authentication/access/auditing mechanisms that meet or exceed access control policy requirements.

Check

Review the container platform configuration to determine if system administrators and ISSO are notified when accounts are removed.

If system administrators and ISSO are not notified, this is a finding.

Fix

Configure the container platform to notify system administrators and ISSO when accounts are removed.

Access to the container platform must display an explicit logout message to user indicating the reliable termination of authenticated communication sessions.

STIG ID: SRG-APP-000297-CTR-000705 | SRG: SRG-APP-000297 | Severity: low | CCI: CCI-002364 | Vulnerability Id: V-233149

Vulnerability Discussion

Access to the container platform will occur through web and terminal sessions. Any web interfaces must conform to application and web security requirements. Terminal access to the container platform and its components must provide a logout facility that terminates the connection to the component or the platform.

Check

Review documentation and configuration settings to determine if the container platform displays a logout message.

If the container platform does not display a logout message, this is a finding.

Fix

Configure the container platform components to display an explicit logout message to users.

The container platform must terminate shared/group account credentials when members leave the group.

STIG ID: SRG-APP-000317-CTR-000735 | SRG: SRG-APP-000317 | Severity: medium | CCI: CCI-004045 | Vulnerability Id: V-233155

Vulnerability Discussion

If shared/group account credentials are not terminated when individuals leave the group, the user that left the group can still gain access even though they are no longer authorized. A shared/group account credential is a shared form of authentication that allows multiple individuals to access the application using a single account. There may also be instances when specific user actions need to be performed on the information system without unique user identification or authentication. Examples of credentials include passwords and group membership certificates.

Check

Determine if the container platform is configured to terminate shared/group account credentials when members leave the group.

If the container platform does not terminated shared/group account credentials when members leave the group, this is a finding.

Fix

Configure the container platform to terminate shared/group account credentials when members leave the group.

The container platform must enforce organization-defined circumstances and/or usage conditions for organization-defined accounts.

STIG ID: SRG-APP-000318-CTR-000740 | SRG: SRG-APP-000318 | Severity: medium | CCI: CCI-002145 | Vulnerability Id: V-257291

Vulnerability Discussion

Activity under unusual conditions can indicate hostile activity. For example, what is normal activity during business hours can indicate hostile activity if it occurs during off hours.

Depending on mission needs and conditions, account usage restrictions based on conditions and circumstances may be critical to limit access to resources and data to comply with operational or mission access control requirements. Thus, the application must be configured to enforce the specific conditions or circumstances under which application accounts can be used (e.g., by restricting usage to certain days of the week, time of day, or specific durations of time).

Check

Determine if the container platform is configured to enforce organization-defined circumstances and/or usage conditions for organization-defined accounts.

If the container platform does not enforce organization-defined circumstances and/or usage conditions for organization-defined accounts, this is a finding.

Fix

Configure the container platform to enforce organization-defined circumstances and/or usage conditions for organization-defined accounts.

The container platform must automatically audit account-enabling actions.

STIG ID: SRG-APP-000319-CTR-000745 | SRG: SRG-APP-000319 | Severity: medium | CCI: CCI-002130 | Vulnerability Id: V-233157

Vulnerability Discussion

Once an attacker establishes access to an application, the attacker often attempts to create a persistent method of re-establishing access. One way to accomplish this is for the attacker to simply enable a new or disabled account. Automatically auditing account enabling actions provides logging that can be used for forensic purposes.

To address access requirements, many application developers choose to integrate their applications with enterprise-level authentication/access/auditing 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.

Check

Determine if the container platform is configured to automatically audit account-enabling actions.

If the container platform is not configured to automatically audit account-enabling actions, this is a finding.

Fix

Configure the container platform to automatically audit account-enabling actions.

The container platform must notify the system administrator (SA) and information system security officer (ISSO) of account enabling actions.

STIG ID: SRG-APP-000320-CTR-000750 | SRG: SRG-APP-000320 | Severity: medium | CCI: CCI-000015 | Vulnerability Id: V-233158

Vulnerability Discussion

Once an attacker establishes access to an application, the attacker often attempts to create a persistent method of re-establishing access. One way to accomplish this is for the attacker to simply enable a new or disabled account. Sending notification of account enabling events to the system administrator and ISSO is one method for mitigating this risk. Such a capability greatly reduces the risk that application accessibility will be negatively affected for extended periods of time and provides logging that can be used for forensic purposes.

To detect and respond to events that affect user accessibility and application processing, applications must notify the appropriate individuals so they can investigate the event.

To address access requirements, many application developers choose to integrate their applications with enterprise-level authentication/access/auditing mechanisms that meet or exceed access control policy requirements. Such integration allows the application developer to offload those access control functions and focus on core application features and functionality.

Check

Determine if the container platform is configured to notify system administrator and ISSO of account enabling actions.

If the container platform is not configured to notify the SA and ISSO of account enabling actions, this is a finding.

Fix

Configure the container platform to notify the SA and ISSO of account enabling actions.

The container platform must prevent non-privileged users from executing privileged functions to include disabling, circumventing, or altering implemented security safeguards/countermeasures.

STIG ID: SRG-APP-000340-CTR-000770 | SRG: SRG-APP-000340 | Severity: medium | CCI: CCI-002235 | Vulnerability Id: V-233162

Vulnerability Discussion

Controlling what users can perform privileged functions prevents unauthorized users from performing tasks that may expose data or degrade the container platform. When users are not segregated into privileged and non-privileged users, unauthorized individuals may perform tasks such as deploying containers, pulling images into the register, and modify keys in the keystore. These actions can introduce malicious containers and cause denial-of-service (DoS) attacks and undermine the container platform integrity. The enforcement may take place at the container platform and can be implemented within each container platform component (e.g. runtime, registry, and keystore).

Check

Review documentation to obtain the definition of the container platform functionality considered privileged in the context of the information system in question.

Review the container platform security configuration and/or other means used to protect privileged functionality from unauthorized use.

If the configuration does not protect all of the actions defined as privileged, this is a finding.

Fix

Configure the container platform to security to protect all privileged functionality. Assigning roles that limit what actions a particular user can perform are the most common means of meeting this requirement.

Container images instantiated by the container platform must execute using least privileges.

STIG ID: SRG-APP-000342-CTR-000775 | SRG: SRG-APP-000342 | Severity: medium | CCI: CCI-002233 | Vulnerability Id: V-233163

Vulnerability Discussion

Containers running within the container platform must execute as non-privileged. When a container can execute as a privileged container, the privileged container is also a privileged user within the hosting system, and the hosting system becomes a major security risk. It is important for the container platform runtime to validate the container user and disallow instantiation if the container is trying to execute with more privileges than required, as a privileged user, or is trying to perform a privilege escalation.

When privileged access is necessary for a container, a new policy for execution should be written for the container. The default behavior must not give containers privileged execution.

Examples of privileged users are root, admin, and default service accounts for the container platform.

Check

Review documentation and configuration to determine if the container platform disallows instantiation of containers trying to execute with more privileges than required or with privileged permissions.

If the container platform does not block containers requesting privileged permissions, privilege escalation, or allows containers to have more privileges than required, this is a finding.

Fix

Configure the container platform to block instantiation with no more privileges than necessary.

The container platform must audit the execution of privileged functions.

STIG ID: SRG-APP-000343-CTR-000780 | SRG: SRG-APP-000343 | Severity: medium | CCI: CCI-002234 | Vulnerability Id: V-233164

Vulnerability Discussion

Privileged functions within the container platform can be component specific or can envelope the entire container platform. Because of the nature of the commands, it is important to understand what command was executed for either investigation of an incident or for debugging/error correction; therefore, privileged function execution must be audited.

Check

Review container platform documentation and log configuration to verify the application server logs privileged activity.

If the container platform is not configured to log privileged activity, this is a finding.

Fix

Configure the container platform to log privileged activity.

The container platform must automatically lock an account until the locked account is released by an administrator when three unsuccessful login attempts in 15 minutes are exceeded.

STIG ID: SRG-APP-000345-CTR-000785 | SRG: SRG-APP-000345 | Severity: medium | CCI: CCI-002238 | Vulnerability Id: V-233165

Vulnerability Discussion

Check

Determine if the container platform is configured to automatically lock an account until the locked account is released by an administrator when three unsuccessful login attempts in 15 minutes are exceeded.

If the container platform is not configured to lock the account, this is a finding.

Fix

Configure the container platform to automatically lock an account until the locked account is released by an administrator when three unsuccessful login attempts in 15 minutes are exceeded.

The container platform must allocate audit record storage capacity in accordance with organization-defined audit record storage requirements.

STIG ID: SRG-APP-000357-CTR-000800 | SRG: SRG-APP-000357 | Severity: medium | CCI: CCI-001849 | Vulnerability Id: V-233168

Vulnerability Discussion

In order to ensure applications have a sufficient storage capacity in which to write the audit logs, applications need to be able to allocate audit record storage capacity.

The task of allocating audit record storage capacity is usually performed during initial installation of the application and is closely associated with the DBA and system administrator roles. The DBA or system administrator will usually coordinate the allocation of physical drive space with the application owner/installer and the application will prompt the installer to provide the capacity information, the physical location of the disk, or both.

Check

Review the container platform configuration to determine if audit record storage capacity is allocated in accordance with organization-defined audit record storage requirements.

If audit record storage capacity is not allocated in accordance with organization-defined audit record storage requirements, this is a finding.

Fix

Configure the container platform to allocate audit record storage capacity in accordance with organization-defined audit record storage requirements.

Audit records must be stored at a secondary location.

STIG ID: SRG-APP-000358-CTR-000805 | SRG: SRG-APP-000358 | Severity: medium | CCI: CCI-001851 | Vulnerability Id: V-233169

Vulnerability Discussion

Auditable events are used in the investigation of incidents and must be protected from being deleted or altered. Often, events that took place in the past must be viewed to understand the entire incident. For the purposes of audit event protection and recall, audit events are often off-loaded to an external storage location. The container platform must provide a mechanism to assist in the off-loading of the audit data or at a minimum, must not hinder an external process used for audit event off-loading.

Check

Verify the log records are being off-loaded to a separate system or transferred from the container platform storage location to a storage location other than the container platform itself.

The information system may demonstrate this capability using a log management application, system configuration, or other means.

If logs are not being off-loaded, this is a finding.

Fix

Configure the container platform to off-load the logs to a remote log or management server.

The container platform must provide an immediate warning to the SA and ISSO (at a minimum) when allocated audit record storage volume reaches 75 percent of repository maximum audit record storage capacity.

STIG ID: SRG-APP-000359-CTR-000810 | SRG: SRG-APP-000359 | Severity: medium | CCI: CCI-001855 | Vulnerability Id: V-233170

Vulnerability Discussion

If security personnel are not notified immediately upon storage volume utilization reaching 75 percent, they are unable to plan for storage capacity expansion.

Check

Review the container platform configuration to determine if it is configured to provide an immediate warning to the SA and ISSO (at a minimum) when allocated audit record storage volume reaches 75 percent of repository maximum audit record storage capacity.

If the container platform is not configured to provide an immediate real-time alert, this is a finding.

Fix

Configure the container platform to provide an immediate real-time alert to the SA and ISSO when allocated audit record storage volume reaches 75 percent of repository maximum audit record storage capacity.

The container platform must provide an immediate real-time alert to the SA and ISSO, at a minimum, of all audit failure events requiring real-time alerts.

STIG ID: SRG-APP-000360-CTR-000815 | SRG: SRG-APP-000360 | Severity: medium | CCI: CCI-001858 | Vulnerability Id: V-233171

Vulnerability Discussion

It is critical for the appropriate personnel to be aware if a system is at risk of failing to process audit logs as required. Without a real-time alert, security personnel may be unaware of an impending failure of the audit capability and system operation may be adversely affected.

Alerts provide organizations with urgent messages. Real-time alerts provide these messages immediately (i.e., the time from event detection to alert occurs in seconds or less).

Check

Review the container platform configuration to determine if it is configured to provide an immediate real-time alert to the SA and ISSO of all audit failure events requiring real-time alerts.

If the container platform is not configured to provide an immediate real-time alert, this is a finding.

Fix

Configure the container platform to provide an immediate real-time alert to the SA and ISSO of all audit failure events requiring real-time alerts.

All audit records must use UTC or GMT time stamps.

STIG ID: SRG-APP-000374-CTR-000865 | SRG: SRG-APP-000374 | Severity: medium | CCI: CCI-001890 | Vulnerability Id: V-233181

Vulnerability Discussion

The container platform and its components must generate audit records using either Coordinated Universal Time (UTC) or Greenwich Mean Time (GMT) time stamps or local time that offset from UTC. All the components must use the same standard so that the events can be tied together to understand what took place within the overall container platform.

Time stamps generated by the container platform and its components must include date and time.

Check

Review the container platform documentation and configuration files to determine if time stamps for log records can be mapped to UTC or GMT or local time that offsets from UTC.

If the time stamp cannot be mapped to UTC or GMT, this is a finding.

Fix

Configure the container platform to use UTC or GMT or local time that offset from UTC based time stamps for log records.

The container platform must record time stamps for audit records that meet a granularity of one second for a minimum degree of precision.

STIG ID: SRG-APP-000375-CTR-000870 | SRG: SRG-APP-000375 | Severity: medium | CCI: CCI-001889 | Vulnerability Id: V-233182

Vulnerability Discussion

To properly investigate an event, it is important to have enough granularity within the time stamps to determine the chronological order of the audited events. Without this granularity, events may be interpreted out of proper sequence, thus hobbling the investigation or causing the investigation to come to inaccurate conclusions.

Time stamps generated by the container platform include date and time. Granularity of time measurements refers to the degree of synchronization between information system clocks and reference clocks.

Check

Review the container platform documentation and configuration files to determine if time stamps for log records meet a granularity of one second.

If the time stamp cannot generate to a one-second granularity, this is a finding.

Fix

Configure the container platform to use time stamps for log records that can meet a granularity of one second.

The container platform must prohibit the installation of patches and updates without explicit privileged status.

STIG ID: SRG-APP-000378-CTR-000880 | SRG: SRG-APP-000378 | Severity: medium | CCI: CCI-003980 | Vulnerability Id: V-233184

Vulnerability Discussion

Controlling access to those users and roles responsible for patching and updating the container platform reduces the risk of untested or potentially malicious software from being installed within the platform. This access may be separate from the access required to install container images into the registry and those access requirements required to instantiate an image into a service. Explicit privileges (escalated or administrative privileges) provide the regular user with explicit capabilities and control that exceeds the rights of a regular user.

Check

Review the container platform configuration to determine if patches and updates can only be installed through accounts with privileged status.

Attempt to install a patch or upgrade using a nonprivileged user account.

If patches or updates can be installed using a nonprivileged account or the container platform is not configured to stop the installation using a nonprivileged account, this is a finding.

Fix

Configure the container platform to only allow patch installation and upgrades using privileged accounts.

The container platform runtime must prohibit the instantiation of container images without explicit privileged status.

STIG ID: SRG-APP-000378-CTR-000885 | SRG: SRG-APP-000378 | Severity: high | CCI: CCI-003980 | Vulnerability Id: V-233185

Vulnerability Discussion

Controlling access to those users and roles responsible for container image instantiation reduces the risk of untested or potentially malicious containers from being executed within the platform and on the hosting system. This access may be separate from the access required to install container images into the registry and those access requirements required to perform patch management and upgrades within the container platform. Explicit privileges (escalated or administrative privileges) provide the regular user with explicit capabilities and control that exceeds the rights of a regular user.

Check

Review the container platform runtime configuration to determine if only accounts given specific container instantiation privileges can execute the container image instantiation process.

Attempt to instantiate a container image using an account that does not have the proper privileges to execute the process.

If container images can be instantiated using an account without the proper privileges, this is a finding.

Fix

Configure the container platform runtime to prohibit the instantiation of container images without explicit container image instantiation privileges given to users.

The container platform registry must prohibit installation or modification of container images without explicit privileged status.

STIG ID: SRG-APP-000378-CTR-000890 | SRG: SRG-APP-000378 | Severity: medium | CCI: CCI-003980 | Vulnerability Id: V-233186

Vulnerability Discussion

Controlling access to those users and roles that perform container platform registry functions reduces the risk of untested or potentially malicious containers from being introduced into the platform. This access may be separate from the access required to instantiate container images into services and those access requirements required to perform patch management and upgrades within the container platform. Explicit privileges (escalated or administrative privileges) provide the regular user with explicit capabilities and control that exceeds the rights of a regular user.

Check

Review container platform registry security settings with respect to nonadministrative users' ability to create, alter, or replace container images.

If any such permissions exist and are not documented and approved, this is a finding.

Fix

Document and obtain approval for any nonadministrative users who require the ability to create, alter, or replace container images within the container platform registry. Implement the approved permissions. Revoke any unapproved permissions.

The container root filesystem must be mounted as read-only.

STIG ID: SRG-APP-000380-CTR-000340 | SRG: SRG-APP-000380 | Severity: medium | CCI: CCI-001813 | Vulnerability Id: V-270876

Vulnerability Discussion

Any changes to a container must be made by rebuilding the image and redeploying the new container image. Once a container is running, changes to the root filesystem should not be needed, thus preserving the immutable nature of the container. Any attempts to change the root filesystem are usually malicious in nature and can be prevented by making the root filesystem read-only.

Check

Review the container platform configuration to determine that the root filesystem is mounted as read-only.

If the container platform does not enforce such access restrictions, this is a finding.

Fix

Review and remove nonsystem containers previously created with read-write permissions. Configure the container platform to force the root filesystem to be mounted as read-only.

The container platform must enforce access restrictions for container platform configuration changes.

STIG ID: SRG-APP-000380-CTR-000900 | SRG: SRG-APP-000380 | Severity: medium | CCI: CCI-001813 | Vulnerability Id: V-233188

Vulnerability Discussion

Configuration changes cause the container platform to change the way it operates. These changes can be used to improve the system with added features or performance, but these configuration changes can also be used to introduce malicious features and degrade performance. To control the configuration changes made to the container platform, it is important that only authorized users are allowed, through container platform enforcement, to make configuration changes.

Check

Review documentation and configuration settings to determine if the container platform enforces access restrictions associated with changes to container platform components configuration.

If the container platform does not enforce such access restrictions, this is a finding.

Fix

Configure the container platform to enforce access restrictions associated with changes to the container platform components configuration.

The container platform must enforce access restrictions and support auditing of the enforcement actions.

STIG ID: SRG-APP-000381-CTR-000905 | SRG: SRG-APP-000381 | Severity: medium | CCI: CCI-003938 | Vulnerability Id: V-233189

Vulnerability Discussion

Auditing the enforcement of access restrictions against changes to the container platform helps identify attacks and provides forensic data for investigation for after-the-fact actions. Attempts to change configurations, components, or data maintained by a component (e.g., images in the registry, running containers in the runtime, or keys in the keystore) must be audited.

Enforcement actions are the methods or mechanisms used to prevent unauthorized changes to configuration settings. Enforcement action methods may be as simple as denying access to a file based on the application of file permissions (access restriction). Audit items may consist of lists of actions blocked by access restrictions or changes identified after the fact.

Check

Review container platform documentation and logs to determine if enforcement actions used to restrict access associated with changes to the container platform are logged.

If these actions are not logged, this is a finding.

Fix

Configure the container platform to log the enforcement actions used to restrict access associated with changes.

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

STIG ID: SRG-APP-000383-CTR-000910 | SRG: SRG-APP-000383 | Severity: medium | CCI: CCI-001762 | Vulnerability Id: V-233190

Vulnerability 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 DoD.

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-secure.

Check

Review the container platform configuration to determine if services or capabilities presently on the information system are required for operational or mission needs.

If additional services or capabilities are present on the system, this is a finding.

Fix

Configure the container platform to only utilize secure ports and protocols required for operation that have been accepted for use as per the Ports, Protocols, and Services Category Assignments List (CAL) from DISA (PPSM).

The container platform must prevent component execution in accordance with organization-defined policies regarding software program usage and restrictions, and/or rules authorizing the terms and conditions of software program usage.

STIG ID: SRG-APP-000384-CTR-000915 | SRG: SRG-APP-000384 | Severity: medium | CCI: CCI-001764 | Vulnerability Id: V-233191

Vulnerability Discussion

The container platform may offer components such as DNS services, firewall services, router services, or web services that are not required by every organization to meet their needs. Container platform components may also add capabilities that run counter to the mission or that provide users with functionality that exceeds mission requirements. To meet the requirements of an organization, the container platform must have a method to remove or disable components not required to meet the organization's mission.

Check

Review documentation and configuration setting to determine if policies, rules, or restrictions exist regarding usage of container platform components.

If no such no restrictions are in place, this is not a finding.

Identify any components the organization requires to be disabled or removed and configure the container platform according to that policy.

If the container platform components are not disabled or removed according to the organization's policy, this is a finding.

Fix

Configure the container platform so that any platform components that are not required in order to meet the organization's mission are disabled or removed. Document the components that must be disabled or removed for reference.

The container platform registry must employ a deny-all, permit-by-exception (whitelist) policy to allow only authorized container images in the container platform.

STIG ID: SRG-APP-000386-CTR-000920 | SRG: SRG-APP-000386 | Severity: medium | CCI: CCI-001774 | Vulnerability Id: V-233192

Vulnerability Discussion

Controlling the sources where container images can be pulled from allows the organization to define what software can be run within the container platform. Allowing any container image to be introduced and instantiated within the container platform may introduce malicious code and vulnerabilities to the platform and the hosting system.

The container platform registry must deny all container images except for those signed by organizational-approved sources.

Check

Review documentation and configuration settings to identify if the container platform whitelisting specifies which container platform components are allowed to execute.

Check for the existence of policy settings or policy files that can be configured to restrict container platform component execution. Demonstrate how the program execution is restricted. Look for a deny-all, permit-by-exception policy of restriction.

Some methods for restricting execution include but are not limited to the use of custom capabilities built into the application or Software Restriction Policies, Application Security Manager, or Role-Based Access Controls (RBAC).

If container platform whitelisting is not utilized or does not follow a deny-all, permit-by-exception (whitelist) policy, this is a finding.

Fix

Configure the container platform to utilize a deny-all, permit-by-exception policy when allowing the execution of authorized software.

The container platform must require users to reauthenticate when organization-defined circumstances or situations require reauthentication.

STIG ID: SRG-APP-000389-CTR-000925 | SRG: SRG-APP-000389 | Severity: medium | CCI: CCI-002038 | Vulnerability Id: V-233193

Vulnerability 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 DOD, the minimum circumstances requiring reauthentication are privilege escalation and role changes.

Check

Review documentation and configuration to determine if the container platform requires a user to reauthenticate when organization-defined circumstances or situations are met.

If the container platform does not meet this requirement, this is a finding.

Fix

Configure the container platform to require a user to reauthenticate when organization-defined circumstances or situations are met.

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

STIG ID: SRG-APP-000391-CTR-000935 | SRG: SRG-APP-000391 | Severity: medium | CCI: CCI-001953 | Vulnerability Id: V-233195

Vulnerability 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.

DoD has mandated the use of the 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.

Check

Review documentation and configuration to ensure the container platform is configured to use an approved DoD multifactor token (CAC) when accessing platform via user interfaces.

If multifactor authentication is not configured, this is a finding.

Fix

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

The container platform must prohibit the use of cached authenticators after an organization-defined time period.

STIG ID: SRG-APP-000400-CTR-000960 | SRG: SRG-APP-000400 | Severity: medium | CCI: CCI-002007 | Vulnerability Id: V-233200

Vulnerability Discussion

If cached authentication information is out of date, the validity of the authentication information may be questionable.

Check

Review the container platform configuration to determine if the platform is configured to prohibit the use of cached authenticators after an organization-defined time period.

If the container platform is not configured to prohibit the use of cached authenticators after an organization-defined time period, this is a finding.

Fix

Configure the container platform to prohibit the use of cached authenticators after an organization-defined time period.

The container platform, for PKI-based authentication, must implement a local cache of revocation data to support path discovery and validation in case of the inability to access revocation information via the network.

STIG ID: SRG-APP-000401-CTR-000965 | SRG: SRG-APP-000401 | Severity: medium | CCI: CCI-004068 | Vulnerability Id: V-233201

Vulnerability Discussion

The potential of allowing access to users who are no longer authorized (have revoked certificates) increases unless a local cache of revocation data is configured.

Check

Review the container platform configuration.

If the container platform is not implemented to use a local cache of revocation data to support path discovery and validation in case of the inability to access revocation information via the network, this is a finding.

Fix

Configure the container platform to implement a local cache of revocation data to support path discovery and validation in case of the inability to access revocation information via the network.

The container platform must accept Personal Identity Verification (PIV) credentials from other federal agencies.

STIG ID: SRG-APP-000402-CTR-000970 | SRG: SRG-APP-000402 | Severity: medium | CCI: CCI-002009 | Vulnerability Id: V-233202

Vulnerability 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. It is essential to accept PIV credentials from other federal agencies and eliminate the possibility of access being denied to authorized users.

PIV credentials are those credentials issued by federal agencies that conform to FIPS Publication 201 and supporting guidance documents. OMB Memorandum 11-11 requires federal agencies to continue implementing the requirements specified in HSPD-12 to enable agency-wide use of PIV credentials.

Check

Review the documentation and configuration to determine if the container platform accepts PIV credentials from other federal agencies.

If the container platform does not accept other federal agency PIV credentials, this is a finding.

Fix

Configure the container platform to accept PIV credentials from other federal agencies.

The container platform must audit non-local maintenance and diagnostic sessions' organization-defined audit events associated with non-local maintenance.

STIG ID: SRG-APP-000409-CTR-000990 | SRG: SRG-APP-000409 | Severity: medium | CCI: CCI-002884 | Vulnerability Id: V-233206

Vulnerability Discussion

To fully investigate an attack, it is important to understand the event and those events taking place during the same time period. Often, non-local administrative access and diagnostic sessions are not logged. These events are seen as only administrative functions and not worthy of being audited, but these events are important in any investigation and are a major tool for assessing and investigating attacks.

Check

Review the container platform to verify if the platform is auditing non-local maintenance and diagnostic sessions' organization-defined audit events.

If the container platform is not auditing non-local maintenance and diagnostic sessions' organization-defined audit events, this is a finding.

Fix

Configure the container platform to audit non-local maintenance and diagnostic sessions' organization-defined audit events.

Container platform applications and Application Program Interfaces (API) used for nonlocal maintenance sessions must use FIPS-validated keyed-hash message authentication code (HMAC) to protect the integrity of nonlocal maintenance and diagnostic communications.

STIG ID: SRG-APP-000411-CTR-000995 | SRG: SRG-APP-000411 | Severity: medium | CCI: CCI-002890 | Vulnerability Id: V-233207

Vulnerability 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 DoD 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.

Check

Validate that container platform applications and APIs used for nonlocal maintenance sessions are using FIPS-validated HMAC to protect the integrity of nonlocal maintenance and diagnostic communications.

If the sessions are not using FIPS-validated HMAC, this is a finding.

Fix

Configure the container platform applications and APIs used for nonlocal maintenance sessions to use FIPS-validated HMAC to protect the integrity of nonlocal maintenance and diagnostic communications.

The container platform must configure web management tools and Application Program Interfaces (API) with FIPS-validated Advanced Encryption Standard (AES) cipher block algorithm to protect the confidentiality of maintenance and diagnostic communications for nonlocal maintenance sessions.

STIG ID: SRG-APP-000412-CTR-001000 | SRG: SRG-APP-000412 | Severity: medium | CCI: CCI-003123 | Vulnerability Id: V-233208

Vulnerability Discussion

Without confidentiality protection mechanisms, unauthorized individuals may gain access to sensitive information via a remote access session.

Nonlocal maintenance and diagnostic activities are activities conducted by individuals communicating through either an external network (e.g., the internet) or an internal network.

Check

Validate the container platform web management tools and Application Program Interfaces (API) are configured to use FIPS-validated Advanced Encryption Standard (AES) cipher block algorithms to protect the confidentiality of maintenance and diagnostic communications for nonlocal maintenance sessions.

If the web management tools and API are not configured to use FIPS-validated Advanced Encryption Standard (AES) cipher block algorithms, this is a finding.

Fix

Configure the container platform web management tools and Application Program Interfaces (API) with FIPS-validated Advanced Encryption Standard (AES) cipher block algorithm to protect the confidentiality of maintenance and diagnostic communications for nonlocal maintenance sessions.

Vulnerability scanning applications must implement privileged access authorization to all container platform components, containers, and container images for selected organization-defined vulnerability scanning activities.

STIG ID: SRG-APP-000414-CTR-001010 | SRG: SRG-APP-000414 | Severity: medium | CCI: CCI-001067 | Vulnerability Id: V-233210

Vulnerability Discussion

In certain situations, the nature of the vulnerability scanning may be more intrusive, or the container platform component that is the subject of the scanning may contain highly sensitive information. Privileged access authorization to selected system components facilitates more thorough vulnerability scanning and protects the sensitive nature of such scanning.

The vulnerability scanning application must utilize privileged access authorization for the scanning account.

Check

Validate that scanning applications have privileged access to container platform components, containers, and container images to properly perform vulnerability scans.

If privileged access is not given to the scanning application, this is a finding.

Fix

Configure the vulnerability scanning application to have privileged access to the container platform components, containers, and container images.

The container platform must implement NSA-approved cryptography to protect classified information in accordance with applicable federal laws, Executive Orders, directives, policies, regulations, and standards.

STIG ID: SRG-APP-000416-CTR-001015 | SRG: SRG-APP-000516 | Severity: medium | CCI: CCI-002450 | Vulnerability Id: V-233211

Vulnerability Discussion

Use of weak or untested encryption algorithms undermines the purposes of utilizing encryption to protect data and images. The container platform must implement cryptographic modules adhering to the higher standards approved by the federal government since this provides assurance they have been tested and validated.

Check

Review documentation to verify that the container platform is using NSA-approved cryptography to protect classified data and applications.

If the container platform is not using NSA-approved cryptography for classified data and applications, this is a finding.

Fix

Configure the container platform to utilize NSA-approved cryptography to protect classified information.

The container platform keystore must implement encryption to prevent unauthorized disclosure of information at rest within the container platform.

STIG ID: SRG-APP-000429-CTR-001060 | SRG: SRG-APP-000429 | Severity: high | CCI: CCI-002476 | Vulnerability Id: V-233220

Vulnerability Discussion

Container platform keystore is used for container deployments for persistent storage of all its REST API objects. These objects are sensitive in nature and should be encrypted at rest to avoid any unauthorized disclosure. Selection of a cryptographic mechanism is based on the need to protect the confidentiality of organizational information. The strength of mechanism is commensurate with the security category and/or classification of the information.

Check

Review container platform keystore documentation and configuration to verify encryption levels meet the information sensitivity level.

If the container platform keystore encryption configuration does not meet system requirements, this is a finding.

Fix

Configure the container platform keystore encryption to maintain the confidentiality and integrity of information for applicable sensitivity level.

The container platform runtime must maintain separate execution domains for each container by assigning each container a separate address space.

STIG ID: SRG-APP-000431-CTR-001065 | SRG: SRG-APP-000431 | Severity: medium | CCI: CCI-002530 | Vulnerability Id: V-233221

Vulnerability Discussion

Container namespace access is limited upon runtime execution. Each container is a distinct process so that communication between containers is performed in a manner controlled through security policies that limits the communication so one container cannot modify another container. Different groups of containers with different security needs should be deployed in separate namespaces as a first level of isolation.

Namespaces are a key boundary for network policies, orchestrator access control restrictions, and other important security controls. Separating workloads into namespaces can help contain attacks and limit the impact of mistakes or destructive actions by authorized users.

Check

Review container platform runtime documentation and configuration is maintaining a separate execution domain for each executing process. Different groups of applications, and services with different security needs, should be deployed in separate namespaces as a first level of isolation.

If container platform runtime is not configured to execute processes in separate domains and namespaces, this is a finding.

If namespaces use defaults, this is a finding.

Fix

Deploy a container platform runtime capable of maintaining a separate execution domain and namespace for each executing process. Create a namespace for each containers, defining them as logical groups.

The container platform must protect against or limit the effects of all types of denial-of-service (DoS) attacks by employing organization-defined security safeguards.

STIG ID: SRG-APP-000435-CTR-001070 | SRG: SRG-APP-000435 | Severity: medium | CCI: CCI-002385 | Vulnerability Id: V-233222

Vulnerability Discussion

DoS is a condition when a resource is not available for legitimate users. When this occurs, the organization either cannot accomplish its mission or must operate at degraded capacity.

This requirement addresses the configuration of the container platform to mitigate the impact of DoS attacks that have occurred. For each container platform component, known and potential DoS attacks must be identified and solutions for each type implemented. A variety of technologies exist to limit or, in some cases, eliminate the effects of DoS attacks (e.g., limiting runtime processes or restricting the number of sessions the container platform runtime open, limiting container resources to memory and CPU).

Processes are an important indicator of security-and operations-relevant container activity. Process names and their arguments provide important visibility into a container’s activity. If an image includes non-default aliases or renamed binaries, attackers will still attempt to use well-known names.

The same malicious or unwanted activity might affect multiple deployments across different applications or environments. Staff investigating a potential incident need to find those exposures quickly.

Check

Review documentation and configuration to determine if the container platform can protect against or limit the effects of all types of DoS attacks by employing defined security safeguards against resource depletion. Examples of resource limits are on memory, storage, and CPU.

If the container platform cannot be configured to protect against or limit the effects of all types of DoS, this is a finding.

Fix

Configure the container platform to protect against or limit the effects of all types of DoS attacks by employing defined security safeguards. Safeguards such as resource limits on memory, storage, and CPU can be used.

The application must protect the confidentiality and integrity of transmitted information.

STIG ID: SRG-APP-000439-CTR-001080 | SRG: SRG-APP-000439 | Severity: high | CCI: CCI-002418 | Vulnerability Id: V-233224

Vulnerability Discussion

Without protection of the transmitted information, confidentiality and integrity may be compromised since unprotected communications can be intercepted and either read or altered.

This requirement applies only to those applications that either are distributed or can allow access to data non-locally. Use of this requirement will be limited to situations where the data owner has a strict requirement for ensuring data integrity and confidentiality is maintained at every step of the data transfer and handling process. When transmitting data, applications need to leverage transmission protection mechanisms, such as TLS, TLS VPNs, or IPsec.

Communication paths outside the physical protection of a controlled boundary are exposed to the possibility of interception and modification. Protecting the confidentiality and integrity of organizational information can be accomplished by physical means (e.g., employing physical distribution systems) or by logical means (e.g., employing cryptographic techniques). If physical means of protection are employed, then logical means (cryptography) do not have to be employed, and vice versa.

Check

Review container platform configuration to determine if it is using a transmission method that maintains the confidentiality and integrity of information during transmission.

If a transmission method is not being used that maintains the confidentiality and integrity of the data, this is a finding.

Fix

Configure the container platform to utilize a transmission method that maintains the confidentiality and integrity of information during transmission.

The container platform must maintain the confidentiality and integrity of information during preparation for transmission.

STIG ID: SRG-APP-000441-CTR-001090 | SRG: SRG-APP-000441 | Severity: medium | CCI: CCI-002420 | Vulnerability Id: V-233226

Vulnerability Discussion

Information may be unintentionally or maliciously disclosed or modified during preparation for transmission within the container platform during aggregation, at protocol transformation points, and during container image runtime. These unauthorized disclosures or modifications compromise the confidentiality or integrity of the information. When transmitting data, the container platform components need to leverage transmission protection mechanisms, such as TLS, TLS VPNs, or IPsec.

Check

Review the documentation and deployed configuration to determine if the container platform maintains the confidentiality and integrity of information during preparation before transmission.

If the confidentiality and integrity are not maintained using mechanisms such as TLS, TLS VPNs, or IPsec during preparation before transmission, this is a finding.

Fix

Configure the container platform to maintain the confidentiality and integrity of information using mechanisms such as TLS, TLS VPNs, or IPsec during preparation for transmission.

The container platform must maintain the confidentiality and integrity of information during reception.

STIG ID: SRG-APP-000442-CTR-001095 | SRG: SRG-APP-000442 | Severity: medium | CCI: CCI-002422 | Vulnerability Id: V-233227

Vulnerability Discussion

Information either can be unintentionally or maliciously disclosed or modified during reception for reception within the container platform during aggregation, at protocol transformation points, and during container image runtime. These unauthorized disclosures or modifications compromise the confidentiality or integrity of the information. When receiving data, the container platform components need to leverage protection mechanisms, such as TLS, TLS VPNs, or IPsec.

Check

Review documentation and configuration settings to determine if the container platform maintains the confidentiality and integrity of information during reception.

If confidentiality and integrity are not maintained using mechanisms such as TLS, TLS VPNs, or IPsec during reception, this is a finding.

Fix

Configure the container platform to maintain the confidentiality and integrity using mechanisms such as TLS, TLS VPNs, or IPsec during reception.

The container platform must behave in a predictable and documented manner that reflects organizational and system objectives when invalid inputs are received.

STIG ID: SRG-APP-000447-CTR-001100 | SRG: SRG-APP-000447 | Severity: medium | CCI: CCI-002754 | Vulnerability Id: V-233228

Vulnerability Discussion

Software or code parameters typically follow well-defined protocols that use structured messages (i.e., commands or queries) to communicate between software modules or system components. Structured messages can contain raw or unstructured data interspersed with metadata or control information. If attacker-supplied inputs to construct structured messages without properly encoding such messages, then the attacker could insert malicious commands or special characters that can cause the data to be interpreted as control information or metadata.

This requirement guards against adverse or unintended system behavior caused by invalid inputs, where container platform components responses to the invalid input may be disruptive or cause the container image runtime to fail into an unsafe state.

The behavior will be derived from the organizational and system requirements and includes, but is not limited to, notification of the appropriate personnel, creating an audit record, and rejecting invalid input.

Check

Review the configuration to determine if the container platform behaves in a predictable and documented manner that reflects organizational and system objectives when invalid inputs are received.

If the container platform does not meet this requirement, this is a finding.

Fix

Configure the container platform behave in a predictable and documented manner that reflects organizational and system objectives when invalid inputs are received.

The container platform must implement organization-defined security safeguards to protect system CPU and memory from resource depletion and unauthorized code execution.

STIG ID: SRG-APP-000450-CTR-001105 | SRG: SRG-APP-000450 | Severity: medium | CCI: CCI-002824 | Vulnerability Id: V-233229

Vulnerability Discussion

The execution of images within the container platform runtime must implement organizational defined security safeguards to prevent distributed denial-of-service (DDOS) and other possible attacks against the container image at runtime.

Security safeguards employed to protect memory and CPU include, for example, data execution prevention and address space layout randomization. Data execution prevention safeguards can be software-enforced. Other means of protection are to limit memory and CPU resources to a container.

Check

Review the container platform configuration to determine if safeguards are in place to protect the system memory and CPU from resource depletion and unauthorized execution.

If safeguards are not in place, this is a finding.

Fix

Configure the container platform to have safeguards in place to protect the system memory and CPU from resource depletion and unauthorized code execution.

The container platform must remove old components after updated versions have been installed.

STIG ID: SRG-APP-000454-CTR-001110 | SRG: SRG-APP-000454 | Severity: medium | CCI: CCI-002617 | Vulnerability Id: V-233230

Vulnerability Discussion

Previous versions of container platform components that are not removed from the container platform after updates have been installed may be exploited by adversaries by causing older components to execute which contain vulnerabilities. When these components are deleted, the likelihood of this happening is removed.

Check

Review container platform registry documentation and configuration to determine if organization-defined images contains latest approved vendor software image version.

If organization-defined images do not contain the latest approved vendor software image version, this is a finding.

Review container platform registry documentation and configuration to determine if organization-defined images are removed after updated versions have been installed.

If organization-defined images are not removed after updated versions have been installed, this is a finding.

Review container platform runtime documentation and configuration to determine if organization-define images are executing latest image version from the container platform registry.

If container platform runtime is not executing latest organization-defined images from the container platform registry, this is a finding.

Fix

Configure the container platform registry to update organization-defined images with current approved vendor version and remove obsolete images after updated versions have been installed. Configure the container platform runtime to execute latest organization-defined images from the container platform registry.

The container platform registry must remove old container images after updating versions have been made available.

STIG ID: SRG-APP-000454-CTR-001115 | SRG: SRG-APP-000454 | Severity: medium | CCI: CCI-002617 | Vulnerability Id: V-233231

Vulnerability Discussion

Obsolete and stale images need to be removed from the registry to ensure the container platform maintains a secure posture. While the storing of these images does not directly pose a threat, they do increase the likelihood of these images being deployed. Removing stale or obsolete images and only keeping the most recent versions of those that are still in use removes any possibility of vulnerable images being deployed.

Check

Review container platform registry documentation and configuration to determine if organization-defined images contains latest approved vendor software image version.

If organization-defined images do not contain the latest approved vendor software image version, this is a finding.

Review container platform registry documentation and configuration to determine if organization-defined images are removed after updated versions have been installed.

If organization-defined images are not removed after updated versions have been installed, this is a finding.

Review container platform runtime documentation and configuration to determine if organization-defined images are executing latest image version from the container registry.

If container platform runtime is not executing latest organization-defined images from the container platform registry, this is a finding.

Fix

The container platform registry must contain the latest images with most recent updates and execute within the container platform runtime as authorized by IAVM, CTOs, DTMs, and STIGs.

STIG ID: SRG-APP-000456-CTR-001125 | SRG: SRG-APP-000456 | Severity: medium | CCI: CCI-002605 | Vulnerability Id: V-233233

Vulnerability Discussion

Software supporting the container platform, images in the registry must stay up to date with the latest patches, service packs, and hot fixes. Not updating the container platform and container images will expose the organization to vulnerabilities.

Flaws discovered during security assessments, continuous monitoring, incident response activities, or information system error handling must also be addressed expeditiously.

Organization-defined time periods for updating security-relevant container platform components may vary based on a variety of factors including, for example, the security category of the information system or the criticality of the update (i.e., severity of the vulnerability related to the discovered flaw).

This requirement will apply to software patch management solutions that are used to install patches across the enclave and to applications themselves that are not part of that patch management solution. For example, many browsers today provide the capability to install their own patch software. Patch criticality, as well as system criticality will vary. Therefore, the tactical situations regarding the patch management process will also vary. This means that the time period utilized must be a configurable parameter. Time frames for application of security-relevant software updates may be dependent upon the Information Assurance Vulnerability Management (IAVM) process.

The container platform components will be configured to check for and install security-relevant software updates within an identified time period from the availability of the update. The container platform registry will ensure the images are current. The specific time period will be defined by an authoritative source (e.g., IAVM, CTOs, DTMs, and STIGs).

Check

Review documentation and configuration to determine if the container platform registry inspects and contains approved vendor repository latest images containing security-relevant updates within a timeframe directed by an authoritative source (IAVM, CTOs, DTMs, STIGs, etc.).

If the container platform registry does not contain the latest image with security-relevant updates within the time period directed by the authoritative source, this is a finding.

The container platform registry should help the user understand where the code in the environment was deployed from, and must provide controls that prevent deployment from untrusted sources or registries.

Fix

Configure the container platform registry to use approved vendor repository to ensure latest images containing security-relevant updates are installed.

The container platform runtime must have updates installed within the time period directed by an authoritative source (e.g., IAVM, CTOs, DTMs, and STIGs).

STIG ID: SRG-APP-000456-CTR-001130 | SRG: SRG-APP-000456 | Severity: medium | CCI: CCI-002605 | Vulnerability Id: V-233234

Vulnerability Discussion

The container platform runtime must be carefully monitored for vulnerabilities, and when problems are detected, they must be remediated quickly. A vulnerable runtime exposes all containers it supports, as well as the host itself, to potentially significant risk. Organizations should use tools to look for Common Vulnerabilities and Exposures (CVEs) vulnerabilities in the runtimes deployed, to upgrade any instances at risk, and to ensure that orchestrators only allow deployments to properly maintained runtimes.

Check

Review documentation and configuration to determine if the container platform registry inspects and contains approved vendor repository latest images containing security-relevant updates within a timeframe directed by an authoritative source (IAVM, CTOs, DTMs, STIGs, etc.).

If the container platform registry does not contain the latest image with security-relevant updates within the time period directed by the authoritative source, this is a finding.

The container platform registry should help the user understand where the code in the environment was deployed from and must provide controls that prevent deployment from untrusted sources or registries.

Fix

Configure the container platform registry to use approved vendor repository to ensure latest images containing security-relevant updates are installed within the time period directed by the authoritative source.

The organization-defined role must verify correct operation of security functions in the container platform.

STIG ID: SRG-APP-000472-CTR-001170 | SRG: SRG-APP-000472 | Severity: medium | CCI: CCI-002696 | Vulnerability Id: V-233242

Vulnerability Discussion

Without verification, security functions may not operate correctly and this failure may go unnoticed within the container platform. The container platform components must identity and ensure the security functions are still operational and applicable to the organization.

Security functions are responsible for enforcing the system security policy and supporting the isolation of code and data on which the protection is based. Security functionality includes, but is not limited to, establishing system accounts, configuring access authorizations (i.e., permissions, privileges), setting events to be audited, and setting intrusion detection parameters.

Notifications provided by information systems include, for example, electronic alerts to system administrators.

Check

Review container platform documentation and configuration verification of the correct operation of security functions, which may include the valid connection to an external security manager (ESM).

If verification of the correct operation of security functions is not performed, this is a finding.

Fix

Configure the container platform configuration and installation settings to perform verification of the correct operation of security functions.

The container platform must perform verification of the correct operation of security functions: upon system startup and/or restart; upon command by a user with privileged access; and/or every 30 days. Security functionality includes, but is not limited to, establishing system accounts, configuring access authorizations (i.e., permissions, privileges), setting events to be audited, and setting intrusion detection parameters.

STIG ID: SRG-APP-000473-CTR-001175 | SRG: SRG-APP-000473 | Severity: medium | CCI: CCI-002699 | Vulnerability Id: V-233243

Vulnerability Discussion

Without verification, security functions may not operate correctly and this failure may go unnoticed within the container platform.

Security functions are responsible for enforcing the system security policy and supporting the isolation of code and data on which the protection is based. Security functionality includes, but is not limited to, establishing system accounts, configuring access authorizations (i.e., permissions, privileges), setting events to be audited, and setting intrusion detection parameters.

Notifications provided by information systems include, for example, electronic alerts to organization-defined role.

Check

Review container platform documentation.

Verify that the container platform is configured to perform verification of the correct operation of security functions, which may include the valid connection to an external security manager (ESM), upon product startup/restart, by a user with privileged access, and/or every 30 days.

If it is not, this is a finding.

Fix

Configure the container platform to perform verification of the correct operation of security functions, which may include the connection validation, upon product startup/restart, or by a user with privileged access, and/or every 30 days.

The container platform must provide system notifications to the system administrator and operational staff when anomalies in the operation of the organization-defined security functions are discovered.

STIG ID: SRG-APP-000474-CTR-001180 | SRG: SRG-APP-000474 | Severity: medium | CCI: CCI-002702 | Vulnerability Id: V-233244

Vulnerability Discussion

If anomalies are not acted upon, security functions may fail to secure the container within the container platform runtime.

Security functions are responsible for enforcing the system security policy and supporting the isolation of code and data on which the protection is based. Security functionality includes, but is not limited to, establishing system accounts, configuring access authorizations (i.e., permissions, privileges), setting events to be audited, and setting intrusion detection parameters.

Notifications provided by information systems include, for example, electronic alerts to system administrators.

Check

Review container platform runtime documentation and configuration settings.

If the container platform is not configured to notify organization-defined information system role when anomalies in the operation of security functions as defined by site security plan are discovered, this is a finding.

Fix

Configure the container platform runtime to notify system administrator and operation staff when anomalies in the operation of the security functions as defined in site security plan are discovered.

The container platform must generate audit records when successful/unsuccessful attempts to access security objects occur.

STIG ID: SRG-APP-000492-CTR-001220 | SRG: SRG-APP-000492 | Severity: medium | CCI: CCI-000172 | Vulnerability Id: V-233252

Vulnerability Discussion

The container platform and its components must generate audit records when successful and unsuccessful access security objects occur. All the components must use the same standard so that the events can be tied together to understand what took place within the overall container platform. This must establish, correlate, and help assist with investigating the events relating to an incident, or identify those responsible.

Without audit record generation access controls levels can access by unauthorized users unknowingly for malicious intent creating vulnerabilities within the container platform.

Check

Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to access security objects.

If audit records are not generated, this is a finding.

Fix

Configure the container platform to generate audit records when successful/unsuccessful attempts to access security objects occur.

The container platform must generate audit records when successful/unsuccessful attempts to access security levels occur.

STIG ID: SRG-APP-000493-CTR-001225 | SRG: SRG-APP-000493 | Severity: medium | CCI: CCI-000172 | Vulnerability Id: V-233253

Vulnerability Discussion

Unauthorized users could access the security levels to exploit vulnerabilities within the container platform component. All the components must use the same standard so that the events can be tied together to understand what took place within the overall container platform. This must establish, correlate, and help assist with investigating the events relating to an incident, or identify those responsible.

Without audit record generation, unauthorized users can access security levels unknowingly for malicious intent creating vulnerabilities within the container platform.

Check

Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to access security levels.

If audit records are not generated, this is a finding.

Fix

Configure the container platform to generate audit records when successful/unsuccessful attempts to access security levels occur.

The container platform must generate audit records when successful/unsuccessful attempts to access categories of information (e.g., classification levels) occur.

STIG ID: SRG-APP-000494-CTR-001230 | SRG: SRG-APP-000494 | Severity: medium | CCI: CCI-000172 | Vulnerability Id: V-233254

Vulnerability Discussion

Check

Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to access categories of information.

If audit records are not generated, this is a finding.

Fix

Configure the container platform to generate audit records on successful/unsuccessful attempts to access categories of information.

The container platform must generate audit records when successful/unsuccessful attempts to modify privileges occur.

STIG ID: SRG-APP-000495-CTR-001235 | SRG: SRG-APP-000495 | Severity: medium | CCI: CCI-000172 | Vulnerability Id: V-233255

Vulnerability Discussion

Check

Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to modify privileges.

If audit records are not generated, this is a finding.

Fix

Configure the container platform to generate audit records on successful/unsuccessful attempts to modify privileges.

The container platform must generate audit records when successful/unsuccessful attempts to modify security objects occur.

STIG ID: SRG-APP-000496-CTR-001240 | SRG: SRG-APP-000496 | Severity: medium | CCI: CCI-000172 | Vulnerability Id: V-233256

Vulnerability Discussion

The container platform and its components must generate audit records when modifying security objects. All the components must use the same standard so that the events can be tied together to understand what took place within the overall container platform. This must establish, correlate, and help assist with investigating the events relating to an incident, or identify those responsible.

Without audit record generation, unauthorized users can modify security objects unknowingly for malicious intent creating vulnerabilities within the container platform.

Check

Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to modify security objects.

If audit records are not generated, this is a finding.

Fix

Configure the container platform to generate audit records when successful/unsuccessful attempts to modify security objects.

The container platform must generate audit records when successful/unsuccessful attempts to modify security levels occur.

STIG ID: SRG-APP-000497-CTR-001245 | SRG: SRG-APP-000497 | Severity: medium | CCI: CCI-000172 | Vulnerability Id: V-233257

Vulnerability Discussion

Unauthorized users could modify the security levels to exploit vulnerabilities within the container platform component. All the components must use the same standard so that the events can be tied together to understand what took place within the overall container platform. This must establish, correlate, and help assist with investigating the events relating to an incident, or identify those responsible.

Without audit record generation, unauthorized users can modify security levels unknowingly for malicious intent creating vulnerabilities within the container platform.

Check

Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to modify security levels.

If audit records are not generated, this is a finding.

Fix

Configure the container platform to generate audit records when successful/unsuccessful attempts to modify security levels.

The container platform must generate audit records when successful/unsuccessful attempts to modify categories of information (e.g., classification levels) occur.

STIG ID: SRG-APP-000498-CTR-001250 | SRG: SRG-APP-000498 | Severity: medium | CCI: CCI-000172 | Vulnerability Id: V-233258

Vulnerability Discussion

Check

Review the container platform configuration to verify audit records are generated when successful/unsuccessful attempts are made to modify categories of information.

If audit records are not generated, this is a finding.

Fix

Configure the container platform to generate audit records when successful/unsuccessful attempts are made to modify categories of information.

The container platform must generate audit records when successful/unsuccessful attempts to delete privileges occur.

STIG ID: SRG-APP-000499-CTR-001255 | SRG: SRG-APP-000499 | Severity: medium | CCI: CCI-000172 | Vulnerability Id: V-233259

Vulnerability Discussion

Check

Review the container platform configuration to verify audit records are generated when successful/unsuccessful attempts are made to delete privileges.

If audit records are not generated, this is a finding.

Fix

Configure the container platform to generate audit records when successful/unsuccessful attempts are made to delete privileges occur.

The container platform must generate audit records when successful/unsuccessful attempts to delete security levels occur.

STIG ID: SRG-APP-000500-CTR-001260 | SRG: SRG-APP-000500 | Severity: medium | CCI: CCI-000172 | Vulnerability Id: V-233260

Vulnerability Discussion

The container platform and its components must generate audit records when deleting security levels. All the components must use the same standard so that the events can be tied together to understand what took place within the overall container platform. This must establish, correlate, and help assist with investigating the events relating to an incident, or identify those responsible.

Without audit record generation, unauthorized users can delete security levels unknowingly for malicious intent creating vulnerabilities within the container platform.

Check

Review the container platform configuration to verify audit records are generated on successful/unsuccessful attempts to delete security levels.

If audit records are not generated, this is a finding.

Fix

Configure the container platform to generate audit records when successful/unsuccessful attempts to delete security levels.

The container platform must generate audit records when successful/unsuccessful attempts to delete security objects occur.

STIG ID: SRG-APP-000501-CTR-001265 | SRG: SRG-APP-000501 | Severity: medium | CCI: CCI-000172 | Vulnerability Id: V-233261

Vulnerability Discussion

Unauthorized users modify level the security levels to exploit vulnerabilities within the container platform component. All the components must use the same standard so that the events can be tied together to understand what took place within the overall container platform. This must establish, correlate, and help assist with investigating the events relating to an incident, or identify those responsible.

Without audit record generation, unauthorized users can access delete security objects unknowingly for malicious intent creating vulnerabilities within the container platform.

Check

Review the container platform configuration to determine if audit records are generated on successful/unsuccessful attempts to delete security objects occur.

If audit records are not generated, this is a finding.

Fix

Configure the container platform to generate audit records on successful/unsuccessful attempts to delete security objects occur.

The container platform must generate audit records when successful/unsuccessful attempts to delete categories of information (e.g., classification levels) occur.

STIG ID: SRG-APP-000502-CTR-001270 | SRG: SRG-APP-000502 | Severity: medium | CCI: CCI-000172 | Vulnerability Id: V-233262

Vulnerability Discussion

Check

Review the container platform configuration to determine if audit records are generated on successful/unsuccessful attempts to delete categories of information occur.

If audit records are not generated, this is a finding.

Fix

Configure the container platform to generate audit records on successful/unsuccessful attempts to delete categories of information occur.

The container platform must generate audit records when successful/unsuccessful logon attempts occur.

STIG ID: SRG-APP-000503-CTR-001275 | SRG: SRG-APP-000503 | Severity: medium | CCI: CCI-000172 | Vulnerability Id: V-233263

Vulnerability Discussion

The container platform and its components must generate audit records when successful and unsuccessful logon attempts occur. The information system can determine if an account is compromised or is in the process of being compromised and can take actions to thwart the attack. All the components must use the same standard so that the events can be tied together to understand what took place within the overall container platform. This must establish, correlate, and help assist with investigating the events relating to an incident, or identify those responsible.

Check

Review the container platform configuration for audit logon events.

Ensure audit policy for successful and unsuccessful logon events are enabled.

Verify events are written to the log.

Validate system documentation is current.

If logon attempts do not generate log records, this is a finding.

Fix

Configure the container platform registry, keystore, and runtime to generate audit log for successful and unsuccessful logon for any all accounts and services. Revise all applicable system documentation.

The container platform must generate audit record for privileged activities.

STIG ID: SRG-APP-000504-CTR-001280 | SRG: SRG-APP-000504 | Severity: medium | CCI: CCI-000172 | Vulnerability Id: V-233264

Vulnerability Discussion

The container platform components will generate audit records for privilege activities and container platform runtime, registry, and keystore must generate access audit records to detect possible malicious intent. All the components must use the same standard so that the events can be tied together to understand what took place within the overall container platform. It would be difficult to establish, correlate, and investigate events relating to an incident or identify those responsible without these activities. Audit records can be generated from various components within the container platform.

Check

Review the documentation and configuration guides to determine if the container platform generates log records for privileged activities.

If log records are not generated for privileged activities, this is a finding.

Fix

Configure the container platform to generate log records for privileged activities.

The container platform audit records must record user access start and end times.

STIG ID: SRG-APP-000505-CTR-001285 | SRG: SRG-APP-000505 | Severity: medium | CCI: CCI-000172 | Vulnerability Id: V-233265

Vulnerability Discussion

The container platform must generate audit records showing start and end times for users and services acting on behalf of a user accessing the registry and keystore. These components must use the same standard so that the events can be tied together to understand what took place within the overall container platform. This must establish, correlate, and help assist with investigating the events relating to an incident, or identify those responsible.

Check

Review the container platform configuration for audit user access start and end times.

Ensure audit policy for user access start and end times are enabled.

Verify events are written to the log.

Validate system documentation is current.

If user access start and end times do not generate log records, this is a finding.

Fix

Configure the container platform to generate audit log for user access start and end times for any all accounts and services. Revise all applicable system documentation.

The container platform must generate audit records when concurrent logons from different workstations and systems occur.

STIG ID: SRG-APP-000506-CTR-001290 | SRG: SRG-APP-000506 | Severity: medium | CCI: CCI-000172 | Vulnerability Id: V-233266

Vulnerability Discussion

The container platform and its components must generate audit records for concurrent logons from workstations perform remote maintenance, runtime instances, connectivity to the container registry, and keystore. All the components must use the same standard so the events can be tied together to understand what took place within the overall container platform. This must establish, correlate, and help assist with investigating the events relating to an incident, or identify those responsible.

Check

Review the container platform configuration for audit logon events.

Ensure audit policy for concurrent logons from different workstations and systems is enabled.

Verify events are written to the log.

Validate system documentation is current.

If concurrent logons from different workstations and systems do not generate log records, this is a finding.

Fix

Configure the container platform to generate audit log for concurrent logins from multiple workstations and systems. Revise all applicable system documentation.

The container platform runtime must generate audit records when successful/unsuccessful attempts to access objects occur.

STIG ID: SRG-APP-000507-CTR-001295 | SRG: SRG-APP-000507 | Severity: medium | CCI: CCI-000172 | Vulnerability Id: V-233267

Vulnerability Discussion

Container platform runtime objects are defined as configuration files, code, etc. This provides the ability to configure resources and software parameters prior to image execution from the container platform registry. An unauthorized user with malicious intent could modify existing objects causing vulnerabilities or attacks. It would be difficult to establish, correlate, and investigate events relating to an incident or identify those responsible without audit record generation.

Without audit record generation, unauthorized users can access objects unknowingly for malicious intent creating vulnerabilities within the container platform.

Check

Review the container platform configuration to verify that the runtime generates audit records on successful/unsuccessful access to objects.

If audit records are not generated by the runtime when objects are successfully/unsuccessfully accessed, this is a finding.

Fix

Configure the container platform runtime to generate audit records on successful/unsuccessful access to objects.

Direct access to the container platform must generate audit records.

STIG ID: SRG-APP-000508-CTR-001300 | SRG: SRG-APP-000508 | Severity: medium | CCI: CCI-000172 | Vulnerability Id: V-233268

Vulnerability Discussion

Direct access to the container platform and its components must generate audit records. All the components must use the same standard so that the events can be tied together to understand what took place within the overall container platform. This must establish, correlate, and help assist with investigating the events relating to an incident, or identify those responsible.

Check

Review the container platform configuration to determine if direct access of the container platform generates audit records.

If audit records are not generated, this is a finding.

Fix

Configure the container platform to generate audit records when accessed directly.

The container platform must generate audit records for all account creations, modifications, disabling, and termination events.

STIG ID: SRG-APP-000509-CTR-001305 | SRG: SRG-APP-000509 | Severity: medium | CCI: CCI-000172 | Vulnerability Id: V-233269

Vulnerability Discussion

Check

Review the container platform configuration to determine if the container platform is configured to generate audit records for all account creations, modifications, disabling, and termination events.

If the container platform is not configured to generate the audit records, this is a finding.

Fix

Configure the container platform to generate audit records for all account creations, modifications, disabling, and termination events.

The container runtime must generate audit records for all container execution, shutdown, restart events, and program initiations.

STIG ID: SRG-APP-000510-CTR-001310 | SRG: SRG-APP-000510 | Severity: medium | CCI: CCI-000172 | Vulnerability Id: V-233270

Vulnerability Discussion

The container runtime must generate audit records that are specific to the security and mission needs of the organization. Without audit record, it would be difficult to establish, correlate, and investigate events relating to an incident.

Check

Review the container runtime configuration to validate audit record generation for container execution, shutdown, and restart events.

If the container runtime does not generate records for container execution, shutdown and restart events, this is a finding.

Fix

Configure the container runtime to generate audit records for container execution, shutdown, and restart events.

The container platform must use a valid FIPS 140-2 approved cryptographic modules to generate hashes.

STIG ID: SRG-APP-000514-CTR-001315 | SRG: SRG-APP-000514 | Severity: medium | CCI: CCI-002450 | Vulnerability Id: V-233271

Vulnerability Discussion

The cryptographic module used must have at least one validated hash algorithm. This validated hash algorithm must be used to generate cryptographic hashes for all cryptographic security function within the container platform components being evaluated.

FIPS 140-2 precludes the use of invalidated cryptography for the cryptographic protection of sensitive or valuable data within Federal systems. Unvalidated cryptography is viewed by NIST as providing no protection to the information or data. In effect, the data would be considered unprotected plaintext. If the agency specifies that the information or data be cryptographically protected, then FIPS 140-2 is applicable. In essence, if cryptography is required, it must be validated. Cryptographic modules that have been approved for classified use may be used in lieu of modules that have been validated against the FIPS 140-2 standard.

Check

Review the container platform configuration to validate that valid FIPS 140-2 approved cryptographic modules are being used to generate hashes.

If non-valid or unapproved FIPS 140-2 cryptographic modules are being used to generate hashes, this is a finding.

Fix

Configure the container platform to use valid FIPS 140-2 approved cryptographic modules to generate hashes.

The container platform must provide the configuration for organization-identified individuals or roles to change the auditing to be performed on all components, based on all selectable event criteria within organization-defined time thresholds.

STIG ID: SRG-APP-000516-CTR-000790 | SRG: SRG-APP-000516 | Severity: medium | CCI: CCI-000366 | Vulnerability Id: V-233166

Vulnerability Discussion

Auditing requirements may change per organization or situation within and organization. With the container platform allowing an organization to customize the auditing, an organization can decide to extend or limit auditing as necessary to meet organizational requirements. Auditing that is limited to conserve resources may be extended to address certain threat situations. In addition, auditing may be limited to a specific set of events to facilitate audit reduction, analysis, and reporting. Organizations can establish time thresholds in which audit actions are changed, for example, near real-time, within minutes, or within hours.

Modifying auditing within the container platform must be controlled to only those individuals or roles identified by the organization to modify auditable events.

Check

Review documentation and configuration setting.

If the container platform does not provide the ability for users in authorized roles to reconfigure auditing at any time of the user's choosing, this is a finding.

If changes in audit configuration cannot take effect until after a certain time or date, or until some event, such as a server restart, has occurred, and if that time or event does not meet the requirements specified by the organization, this is a finding.

Fix

Deploy a container platform that provides the ability for users in authorized roles to reconfigure auditing at any time. Deploy a container platform that allows audit configuration changes to take effect within the timeframe required by the organization and without involving actions or events that the organization rules unacceptable.

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

STIG ID: SRG-APP-000516-CTR-001325 | SRG: SRG-APP-000516 | Severity: medium | CCI: CCI-000366 | Vulnerability Id: V-233273

Vulnerability Discussion

Container platform components are part of the overall container platform, offering services that enable the container platform to fully orchestrate user containers. These components may fall outside the scope of this document, but they still must be secured. Examples of such components are DNS, routers, and firewalls. These and any other services offered by the container platform must follow the appropriate STIG or SRG for the technology offered. If a STIG or SRG is not available for the technology, then best practices for the technology must be used. For example, the Cloud Native Computing Foundation (CNCF) is an open-source organization that is working on container platform best practices.

Check

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 DoD 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 DoD security configuration or implementation guidance, including SRGs, STIGs, NSA configuration guides, CTOs, and DTMs, this is a finding.

Fix

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

The container platform must be able to store and instantiate industry standard container images.

STIG ID: SRG-APP-000516-CTR-001330 | SRG: SRG-APP-000516 | Severity: medium | CCI: CCI-000366 | Vulnerability Id: V-233274

Vulnerability Discussion

Monitoring the container images and containers during their lifecycle is important to guarantee the container platform is secure. To monitor the containers and images, security tools can be put in place. To fully utilize the security tools available, using images formatted in an industry standard format should be used. This allows the tools to fully understand the images and containers. One standard being worked on by industry leaders in the container space is the Open Container Initiative (OCI). This group is developing a standard container image format.

Check

Review the container platform configuration and documentation to determine if the platform is configured to store and instantiate industry standard container images.

If the container platform cannot instantiate industry standard container images, this is a finding.

Fix

Enable the container platform to store and instantiate industry standard container image formats.

The container platform must continuously scan components, containers, and images for vulnerabilities.

STIG ID: SRG-APP-000516-CTR-001335 | SRG: SRG-APP-000516 | Severity: medium | CCI: CCI-000366 | Vulnerability Id: V-233275

Vulnerability Discussion

Finding vulnerabilities quickly within the container platform and within containers deployed within the platform is important to keep the overall platform secure. When a vulnerability within a component or container is unknown or allowed to remain unpatched, other containers and customers within the platform become vulnerability. The vulnerability can lead to the loss of application data, organizational infrastructure data, and denial of service (DoS) to hosted applications.

Vulnerability scanning can be performed by the container platform or by external applications.

Check

Review the container platform to validate continuous vulnerability scans of components, containers, and container images are being performed.

If continuous vulnerability scans are not being performed, this is a finding.

Fix

Implement continuous vulnerability scans of container platform components, containers, and container images either by the container platform or from external vulnerability scanning applications.

The container platform must prohibit communication using TLS versions 1.0 and 1.1, and SSL 2.0 and 3.0.

STIG ID: SRG-APP-000560-CTR-001340 | SRG: SRG-APP-000560 | Severity: medium | CCI: CCI-001453 | Vulnerability Id: V-233276

Vulnerability Discussion

The container platform and its components will prohibit the use of SSL and unauthorized versions of TLS protocols to properly secure communication.

The use of unsupported protocol exposes vulnerabilities to the container platform by rogue traffic interceptions, man-in-the middle-attacks, and impersonation of users or services from the container platform runtime, registry, and keystore.

The container platform and its components will adhere to NIST 800-52R2.

Check

Review the container platform configuration to determine if TLS versions 1.0 and 1.1, SSL 2.0 and 3.0 are prohibited for communication.

If communication using TLS versions 1.0 and 1.1, SSL 2.0 and 3.0 is permitted, this is a finding.

Fix

Configure the container platform to prohibit communication using TLS versions 1.0 and 1.1, SSL 2.0 and 3.0.

The container platform must validate certificates used for Transport Layer Security (TLS) functions by performing an RFC 5280-compliant certification path validation.

STIG ID: SRG-APP-000605-CTR-001380 | SRG: SRG-APP-000605 | Severity: medium | CCI: CCI-000185 | Vulnerability Id: V-233284

Vulnerability Discussion

A certification path is the path from the end entity certificate to a trusted root certification authority (CA). Certification path validation is necessary for a relying party to make an informed decision regarding acceptance of an end entity certificate and discourages the use of self-signed certificates.

Certification path validation includes checks such as certificate issuer trust, time validity, and revocation status for each certificate in the certification path. Revocation status information for CA and subject certificates in a certification path is commonly provided via certificate revocation lists (CRLs) or online certificate status protocol (OCSP) responses. Compliance checks should be in accordance to RFC 5280.

Not adhering to RFC 5280 could result in rogue certificates, session hijacks, man-in-the-middle, denial-of-service attacks, malware, and data or information manipulation.

Check

Review the container platform configuration to verify the container platform is validating certificates used for Transport Layer Security (TLS) functions by performing a RFC 5280-compliant certification path validation and that self-signed certificates are not being used.

If the container platform is not validating certificates used for TLS functions by performing an RFC 5280-compliant certification path validation, this is a finding.

If self-signed certificates are in use, this is a finding.

Fix

Configure the container platform to validate certificates used for Transport Layer Security (TLS) functions by performing an RFC 5280-compliant certification path validation and to disable the use of self-signed certificates.

The container platform must use FIPS-validated SHA-2 or higher hash function for digital signature generation and verification (non-legacy use).

STIG ID: SRG-APP-000610-CTR-001385 | SRG: SRG-APP-000610 | Severity: medium | CCI: CCI-000803 | Vulnerability Id: V-233285

Vulnerability Discussion

Without the use of digital signature, information can be altered by unauthorized accounts accessing or modifying the container platform registry, keystore, and container at runtime. Digital signatures provide non-repudiation for transactions between the components within the container platform. Without the use of approved FIPS-validated SHA-2 or higher hash function with digital signatures, the container platform cannot claim the validity of the individual or service identity and guarantee private key is kept secret. Keeping the private keys secure is vital for validating individuals or service identity prior to information exchange. The container platform must be configured to use SHA-2 or higher hash functions for digital signatures in accordance with SP 800-131Ar2.

Check

Review the container platform configuration to validate that a FIPS-validated SHA-2 or higher hash function is being used for digital signature generation and verification.

If a FIPS-validated SHA-2 or higher hash function is not being used for digital signature generation and verification, this is a finding.

Fix

Configure the container platform to use a FIPS-validated SHA-2 or higher hash function for digital signature generation and verification.

The container platform must use a FIPS-validated cryptographic module to implement encryption services for unclassified information requiring confidentiality.

STIG ID: SRG-APP-000635-CTR-001405 | SRG: SRG-APP-000635 | Severity: high | CCI: CCI-002450 | Vulnerability Id: V-233289

Vulnerability Discussion

Unvalidated cryptography is viewed by NIST as providing no protection to the information or data. In effect, the data would be considered unprotected plaintext. If the agency specifies that the information or data be cryptographically protected, then FIPS 140-2 is applicable. In essence, if cryptography is required, it must be validated. Cryptographic modules that have been approved for classified use may be used in lieu of modules that have been validated against the FIPS 140-2 standard.

Cryptographic module used must have one FIPS-validated encryption algorithm (i.e., validated Advanced Encryption Standard [AES]). This validated algorithm must be used for encryption for cryptographic security function within the container platform component and information residing in the container platform registry and keystore.

Check

Review the container platform configuration to ensure FIPS-validated cryptographic modules are implemented to encrypt unclassified information requiring confidentiality.

If FIPS-validated cryptographic modules are not being used, this is a finding.

Fix

Configure the container platform to use FIPS-validated cryptographic modules to encrypt unclassified information requiring confidentiality.

The container platform must prohibit or restrict the use of protocols that transmit unencrypted authentication information or use flawed cryptographic algorithms for transmission.

STIG ID: SRG-APP-000645-CTR-001410 | SRG: SRG-APP-000645 | Severity: high | CCI: CCI-000382 | Vulnerability Id: V-233290

Vulnerability Discussion

The use of secure ports, protocols and services within the container platform must be controlled and conform to the PPSM CAL. Those ports, protocols, and services that fall outside the PPSM CAL must be blocked by the runtime. Instructions on the PPSM can be found in DoD Instruction 8551.01 Policy.

Unsecure protocols for transmission will expose the information system data and information, making the session susceptible to manipulation, hijacking, and man-in-the middle attacks.

Check

Review the container platform configuration to verify that container platform is not using protocols that transmit authentication data unencrypted and that the container platform is not using flawed cryptographic algorithms for transmission.

If the container platform is using protocols to transmit authentication data unencrypted or is using flawed cryptographic algorithms, this is a finding.

Fix

Configure the container platform to use protocols that transmit authentication data encrypted and to use cryptographic algorithms that are not flawed.

The container platform must disable accounts when the accounts are no longer associated to a user.

STIG ID: SRG-APP-000705-CTR-000110 | SRG: SRG-APP-000705 | Severity: medium | CCI: CCI-003628 | Vulnerability Id: V-263586

Vulnerability Discussion

Disabling expired, inactive, or otherwise anomalous accounts supports the concepts of least privilege and least functionality which reduce the attack surface of the system.

Check

Verify the container platform is configured to disable accounts when the accounts are no longer associated to a user.

If the container platform is not configured to disable accounts when the accounts are no longer associated to a user, this is a finding.

Fix

Configure the container platform to disable accounts when the accounts are no longer associated to a user.

The container platform must implement the capability to centrally review and analyze audit records from multiple components within the system.

STIG ID: SRG-APP-000745-CTR-000120 | SRG: SRG-APP-000745 | Severity: medium | CCI: CCI-003821 | Vulnerability Id: V-263587

Vulnerability Discussion

Automated mechanisms for centralized reviews and analyses include Security Information and Event Management products.

Check

Verify the container platform is configured to implement the capability to centrally review and analyze audit records from multiple components within the system.

If the container platform is not configured to implement the capability to centrally review and analyze audit records from multiple components within the system, this is a finding.

Fix

Configure the container platform to implement the capability to centrally review and analyze audit records from multiple components within the system.

The container platform must alert organization-defined personnel or roles upon detection of unauthorized access, modification, or deletion of audit information.

STIG ID: SRG-APP-000795-CTR-000130 | SRG: SRG-APP-000795 | Severity: medium | CCI: CCI-003831 | Vulnerability Id: V-263588

Vulnerability Discussion

Audit information includes all information needed to successfully audit system activity, such as audit records, audit log settings, audit reports, and personally identifiable information. Audit logging tools are those programs and devices used to conduct system audit and logging activities. Protection of audit information focuses on technical protection and limits the ability to access and execute audit logging tools to authorized individuals. Physical protection of audit information is addressed by both media protection controls and physical and environmental protection controls.

Check

Verify the container platform is configured to alert organization-defined personnel or roles upon detection of unauthorized access, modification, or deletion of audit information.

If the container platform is not configured to alert organization-defined personnel or roles upon detection of unauthorized access, modification, or deletion of audit information, this is a finding.

Fix

Configure the container platform to alert organization-defined personnel or roles upon detection of unauthorized access, modification, or deletion of audit information.

The container platform must implement multifactor authentication for local; network; and/or remote access to privileged accounts; and/or nonprivileged accounts such that one of the factors is provided by a device separate from the system gaining access.

STIG ID: SRG-APP-000820-CTR-000170 | SRG: SRG-APP-000820 | Severity: medium | CCI: CCI-004046 | Vulnerability Id: V-263589

Vulnerability Discussion

The purpose of requiring a device that is separate from the system to which the user is attempting to gain access for one of the factors during multifactor authentication is to reduce the likelihood of compromising authenticators or credentials stored on the system. Adversaries may be able to compromise such authenticators or credentials and subsequently impersonate authorized users. Implementing one of the factors on a separate device (e.g., a hardware token), provides a greater strength of mechanism and an increased level of assurance in the authentication process.

Check

Verify the container platform is configured to implement multifactor authentication for local; network; and/or remote access to privileged accounts; and/or nonprivileged accounts such that one of the factors is provided by a device separate from the system gaining access.

If the container platform is not configured to implement multifactor authentication for local; network; and/or remote access to privileged accounts; and/or nonprivileged accounts such that one of the factors is provided by a device separate from the system gaining access, this is a finding.

Fix

Configure the container platform to implement multifactor authentication for local; network; and/or remote access to privileged accounts; and/or nonprivileged accounts such that one of the factors is provided by a device separate from the system gaining access.

The container platform must implement multifactor authentication for local; network; and/or remote access to privileged accounts; and/or nonprivileged accounts such that the device meets organization-defined strength of mechanism requirements.

STIG ID: SRG-APP-000825-CTR-000180 | SRG: SRG-APP-000825 | Severity: medium | CCI: CCI-004047 | Vulnerability Id: V-263590

Vulnerability Discussion

Check

Verify the container platform is configured to implement multifactor authentication for local; network; and/or remote access to privileged accounts; and/or nonprivileged accounts such that the device meets organization-defined strength of mechanism requirements.

If the container platform is not configured to implement multifactor authentication for local; network; and/or remote access to privileged accounts; and/or nonprivileged accounts such that the device meets organization-defined strength of mechanism requirements, this is a finding.

Fix

Configure the container platform to implement multi-factor authentication for local; network; and/or remote access to privileged accounts; and/or nonprivileged accounts such that the device meets organization-defined strength of mechanism requirements.

The container platform must for password-based authentication, maintain a list of commonly used, expected, or compromised passwords on an organization-defined frequency.

STIG ID: SRG-APP-000830-CTR-000190 | SRG: SRG-APP-000830 | Severity: medium | CCI: CCI-004058 | Vulnerability Id: V-263591

Vulnerability Discussion

Password-based authentication applies to passwords regardless of whether they are used in single-factor or multi-factor authentication. Long passwords or passphrases are preferable over shorter passwords. Enforced composition rules provide marginal security benefits while decreasing usability. However, organizations may choose to establish certain rules for password generation (e.g., minimum character length for long passwords) under certain circumstances and can enforce this requirement in IA-5(1)(h). Account recovery can occur, for example, in situations when a password is forgotten. Cryptographically protected passwords include salted one-way cryptographic hashes of passwords. The list of commonly used, compromised, or expected passwords includes passwords obtained from previous breach corpuses, dictionary words, and repetitive or sequential characters. The list includes context-specific words, such as the name of the service, username, and derivatives thereof.

Check

Verify the container platform is configured to maintain a list of commonly used, expected, or compromised passwords on an organization-defined frequency.

If the container platform is not configured to maintain a list of commonly used, expected, or compromised passwords on an organization-defined frequency, this is a finding.

Fix

Configure the container platform to maintain a list of commonly used, expected, or compromised passwords on an organization-defined frequency.

The container platform must for password-based authentication, update the list of passwords on an organization-defined frequency.

STIG ID: SRG-APP-000835-CTR-000200 | SRG: SRG-APP-000835 | Severity: medium | CCI: CCI-004059 | Vulnerability Id: V-263592

Vulnerability Discussion

Check

Verify the container platform is configured to update the list of passwords on an organization-defined frequency.

If the container platform is not configured to update the list of passwords on an organization-defined frequency, this is a finding.

Fix

Configure the container platform to update the list of passwords on an organization-defined frequency.

The container platform must for password-based authentication, update the list of passwords when organizational passwords are suspected to have been compromised directly or indirectly.

STIG ID: SRG-APP-000840-CTR-000210 | SRG: SRG-APP-000840 | Severity: medium | CCI: CCI-004060 | Vulnerability Id: V-263593

Vulnerability Discussion

Check

Verify the container platform is configured to update the list of passwords when organizational passwords are suspected to have been compromised directly or indirectly.

If the container platform is not configured to update the list of passwords when organizational passwords are suspected to have been compromised directly or indirectly, this is a finding.

Fix

Configure the container platform to update the list of passwords when organizational passwords are suspected to have been compromised directly or indirectly.

The container platform must for password-based authentication, verify when users create or update passwords, that the passwords are not found on the list of commonly-used, expected, or compromised passwords in IA-5 (1) (a).

STIG ID: SRG-APP-000845-CTR-000220 | SRG: SRG-APP-000845 | Severity: medium | CCI: CCI-004061 | Vulnerability Id: V-263594

Vulnerability Discussion

Check

Verify the container platform is configured to verify when users create or update passwords, that the passwords are not found on the list of commonly-used, expected, or compromised passwords in IA-5 (1) (a).

If the container platform is not configured to verify when users create or update passwords, that the passwords are not found on the list of commonly-used, expected, or compromised passwords in IA-5 (1) (a), this is a finding.

Fix

Configure the container platform to verify when users create or update passwords, that the passwords are not found on the list of commonly-used, expected, or compromised passwords in IA-5 (1) (a).

The container platform must for password-based authentication, require immediate selection of a new password upon account recovery.

STIG ID: SRG-APP-000855-CTR-000240 | SRG: SRG-APP-000855 | Severity: medium | CCI: CCI-004063 | Vulnerability Id: V-263595

Vulnerability Discussion

Check

Verify the container platform is configured to require immediate selection of a new password upon account recovery.

If the container platform is not configured to require immediate selection of a new password upon account recovery, this is a finding.

Fix

Configure the container platform to require immediate selection of a new password upon account recovery.

The container platform must for password-based authentication, allow user selection of long passwords and passphrases, including spaces and all printable characters.

STIG ID: SRG-APP-000860-CTR-000250 | SRG: SRG-APP-000860 | Severity: medium | CCI: CCI-004064 | Vulnerability Id: V-263596

Vulnerability Discussion

Check

Verify the container platform is configured to allow user selection of long passwords and passphrases, including spaces and all printable characters.

If the container platform is not configured to allow user selection of long passwords and passphrases, including spaces and all printable characters, this is a finding.

Fix

Configure the container platform to allow user selection of long passwords and passphrases, including spaces and all printable characters.

The container platform must for password-based authentication, employ automated tools to assist the user in selecting strong password authenticators.

STIG ID: SRG-APP-000865-CTR-000260 | SRG: SRG-APP-000865 | Severity: medium | CCI: CCI-004065 | Vulnerability Id: V-263597

Vulnerability Discussion

Check

Verify the container platform is configured to employ automated tools to assist the user in selecting strong password authenticators.

If the container platform is not configured to employ automated tools to assist the user in selecting strong password authenticators, this is a finding.

Fix

Configure the container platform to employ automated tools to assist the user in selecting strong password authenticators.

The container platform must protect nonlocal maintenance sessions by separating the maintenance session from other network sessions with the system by logically separated communications paths.

STIG ID: SRG-APP-000880-CTR-000290 | SRG: SRG-APP-000880 | Severity: medium | CCI: CCI-004192 | Vulnerability Id: V-263598

Vulnerability Discussion

Nonlocal maintenance and diagnostic activities are conducted by individuals who communicate through either an external or internal network.
Communications paths can be logically separated using encryption.

Check

Verify the container platform is configured to protect nonlocal maintenance sessions by separating the maintenance session from other network sessions with the system by logically separated communications paths.

If the container platform is not configured to protect nonlocal maintenance sessions by separating the maintenance session from other network sessions with the system by logically separated communications paths, this is a finding.

Fix

Configure the container platform to protect nonlocal maintenance sessions by separating the maintenance session from other network sessions with the system by logically separated communications paths.

The container platform must include only approved trust anchors in trust stores or certificate stores managed by the organization.

STIG ID: SRG-APP-000910-CTR-000300 | SRG: SRG-APP-000910 | Severity: medium | CCI: CCI-004909 | Vulnerability Id: V-263599

Vulnerability Discussion

Public key infrastructure (PKI) certificates are certificates with visibility external to organizational systems and certificates related to the internal operations of systems, such as application-specific time services. In cryptographic systems with a hierarchical structure, a trust anchor is an authoritative source (i.e., a certificate authority) for which trust is assumed and not derived. A root certificate for a PKI system is an example of a trust anchor. A trust store or certificate store maintains a list of trusted root certificates.

Check

Verify the container platform is configured to include only approved trust anchors in trust stores or certificate stores managed by the organization.

If the container platform is not configured to include only approved trust anchors in trust stores or certificate stores managed by the organization, this is a finding.

Fix

Configure the container platform to include only approved trust anchors in trust stores or certificate stores managed by the organization.

The container platform must provide protected storage for cryptographic keys with organization-defined safeguards and/or hardware protected key store.

STIG ID: SRG-APP-000915-CTR-000310 | SRG: SRG-APP-000915 | Severity: medium | CCI: CCI-004910 | Vulnerability Id: V-263600

Vulnerability Discussion

A Trusted Platform Module (TPM) is an example of a hardware-protected data store that can be used to protect cryptographic keys.

Check

Verify the container platform is configured to provide protected storage for cryptographic keys with organization-defined safeguards and/or hardware protected key store.

If the container platform is not configured to provide protected storage for cryptographic keys with organization-defined safeguards and/or hardware protected key store, this is a finding.

Fix

Configure the container platform to provide protected storage for cryptographic keys with organization-defined safeguards and/or hardware protected key store.

The container platform must synchronize system clocks within and between systems or system components.

STIG ID: SRG-APP-000920-CTR-000320 | SRG: SRG-APP-000920 | Severity: medium | CCI: CCI-004922 | Vulnerability Id: V-263601

Vulnerability Discussion

Time synchronization of system clocks is essential for the correct execution of many system services, including identification and authentication processes that involve certificates and time-of-day restrictions as part of access control. Denial of service or failure to deny expired credentials may result without properly synchronized clocks within and between systems and system components. Time is commonly expressed in Coordinated Universal Time (UTC), a modern continuation of Greenwich Mean Time (GMT), or local time with an offset from UTC. The granularity of time measurements refers to the degree of synchronization between system clocks and reference clocks, such as clocks synchronizing within hundreds of milliseconds or tens of milliseconds. Organizations may define different time granularities for system components. Time service can be critical to other security capabilities such as access control and identification and authentication depending on the nature of the mechanisms used to support the capabilities.

Check

Verify the container platform is configured to synchronize system clocks within and between systems or system components.

If the container platform is not configured to synchronize system clocks within and between systems or system components, this is a finding.

Fix

Configure the container platform to synchronize system clocks within and between systems or system components.