None Computing title General Application (GAPP) Security Requirements Guide version 1 releaseinfo Release: 0.1 Vuln_Num V-288135 Rule_ID SV-288135r1252910_rule Severity high Rule_Title The application must use an approved DoW Enterprise Identity, Credential, and Access Management (E-ICAM) solution to uniquely identify and authenticate organizational users (or processes acting on behalf of organizational users). Vuln_Discuss To ensure accountability and prevent unauthenticated access, organizational users must be identified and authenticated to prevent potential misuse and compromise of the system. This is typically accomplished via the use of a user store, which is either local (OS-based) or centralized (LDAP, Active Directory) in nature. However, DODI 8520.03 now requires that applications use an approved DoW E-ICAM solution whenever the ICAM solution addresses information system needs. Where the ICAM solution has been evaluated and found to not meet the needs of information system owners, information system owners must reevaluate decisions to use locally managed solutions (LDAP, Active Directory) and transition to DoW enterprise ICAM solutions to the maximum extent possible as the E-ICAM solutions mature. Check_Content Review application documentation and configuration settings to determine if the application is using an approved E-ICAM solution to authenticate organizational users. If an approved E-ICAM solution is not being used, this is a finding. Note: If the site is currently using an enterprise solution (AAA Server) and has documented their plans to move to an approved E-ICAM solution, the severity of this control can be reduced to a CAT III. Fix_Text Configure the application to use an approved E-ICAM solution to uniquely identify and authenticate organizational users. Not_Reviewed Vuln_Num V-288136 Rule_ID SV-288136r1252911_rule Severity high Rule_Title The application must use multifactor authentication (MFA). Vuln_Discuss Without the use of MFA, the ease of access to privileged functions is greatly increased. MFA requires the use of 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). The current DoW multifactor solution is the common access card (CAC). Other DoW or authorizing official (AO)-approved solutions may be implemented. Check_Content Review application documentation and configuration settings to determine if the application is using an approved MFA solution to authenticate organizational users. If an approved MFA solution is not being used, this is a finding. Fix_Text Configure the application to use an approved MFA solution to uniquely identify and authenticate organizational users. Not_Reviewed Vuln_Num V-288137 Rule_ID SV-288137r1252644_rule Severity high Rule_Title Local accounts must be removed after multifactor authentication (MFA) is configured. It is permissible for an emergency ("break glass") or service account to remain if absolutely required by the application. In this case, the associated complexity requirements apply. Vuln_Discuss Without the use of MFA, the ease of access to privileged functions is greatly increased. MFA requires the use of 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). The current DoW multifactor solution is the common access card (CAC). Other DoW or authorizing official (AO)-approved solutions may be implemented. To ensure MFA is used, access to local accounts must be removed. Check_Content Navigate to the local account configuration function within the application. Verify no local accounts exist. Otherwise, this is a finding. If a break glass or service account remains, this must be documented and approved by the AO. Otherwise, this is a finding. Fix_Text Navigate to the local account configuration function within the application and remove all local accounts. For break glass or service accounts, apply the appropriate password complexity per policy. Not_Reviewed Vuln_Num V-288138 Rule_ID SV-288138r1252971_rule Severity medium Rule_Title The application must use a SHA 2-384 or higher hash function to provide replay-resistant authentication mechanisms for network access to all accounts. Vuln_Discuss 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 DoW Public Key Infrastructure (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_Content Navigate to the cryptography configuration for the application's authentication mechanism. SHA 2-384 (or higher) must be used for hashing purposes. If the application's authentication mechanism is not configured to use SHA 2-384 (or higher) for hashing purposes, this is a finding. Fix_Text Navigate to the cryptography configuration for the application's authentication mechanism. Configure the authentication mechanism to use SHA 2-384 (or higher) for hashing purposes. Not_Reviewed Vuln_Num V-288139 Rule_ID SV-288139r1252649_rule Severity medium Rule_Title The application must disable identifiers (individuals, groups, roles, and devices) after 35 days of inactivity. Vuln_Discuss 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 must 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, developers leverage the underlying OS or other user account management infrastructure (AD, LDAP) already in place within the organization that meets organizational user account management requirements. Check_Content Navigate to the account configuration function within the application. Verify the application is configured to disable all identifiers after 35 days (or less) of inactivity. Otherwise, this is a finding. If a break glass or service account remains, this must be documented and approved by the authorizing official (AO). Otherwise, this is a finding. Fix_Text Navigate to the account configuration function within the application. Configure a policy to disable all identifiers after 35 days (or less) of inactivity. If a break glass or service account remains, this must be documented and approved by the AO. Otherwise, this is a finding. Not_Reviewed Vuln_Num V-288140 Rule_ID SV-288140r1252972_rule Severity medium Rule_Title When using Public Key Infrastructure (PKI)-based authentication for user access, the application must validate certificates by constructing a certification path (which includes status information) to an accepted trust anchor. Vuln_Discuss Without path validation, an informed trust decision by the relying party cannot be made when presented with any certificate not already explicitly trusted. To meet this requirement, the information system must create trusted channels between itself and remote trusted authorized IT product (e.g., syslog server) entities that protect the confidentiality and integrity of communications. The information system must create trusted paths between itself and remote administrators and users that protect the confidentiality and integrity of communications. A trust anchor is an authoritative entity represented via a public key and associated data. It is most often used in the context of public key infrastructures, X.509 digital certificates, and DNSSEC. However, applications that do not use a trusted path are not approved for nonlocal and remote management of DoW information systems. Use of SSHv2 to establish a trusted channel is approved. Use of FTP, TELNET, HTTP, and SNMPV1 is not approved since they violate the trusted channel rule set. Use of web management tools that are not validated by common criteria may also violate trusted channel rule set. When there is a chain of trust, usually the top entity to be trusted becomes the trust anchor; it can be, for example, a certification authority (CA). A certification path starts with the subject certificate and proceeds through a number of intermediate certificates up to a trusted root certificate, typically issued by a trusted CA. This requirement verifies that a certification path to an accepted trust anchor is used for certificate validation and that the path includes status information. Path validation is necessary for a relying party to make an informed trust decision when presented with any certificate not already explicitly trusted. Status information for certification paths includes certificate revocation lists or online certificate status protocol responses. Validation of the certificate status information is out of scope for this requirement. Check_Content Review the application documentation and deployed configuration to determine whether the application's PKI authentication mechanism validates constructing a certification path (which includes status information) to an accepted trust anchor. If the certification path to an accepted trust anchor cannot be verified for PKI authentication, this is a finding. Fix_Text Configure the application's PKI authentication mechanism such that an accepted trust anchor can be verified. Not_Reviewed Vuln_Num V-288141 Rule_ID SV-288141r1252008_rule Severity medium Rule_Title The application, when using PKI-based authentication, must enforce authorized access to the corresponding private key. Vuln_Discuss If the private key is discovered, an attacker can use the key to authenticate as an authorized user and gain access to the network infrastructure. The cornerstone of the PKI is the private key used to encrypt or digitally sign information. If the private key is stolen, this will lead to the compromise of the authentication and nonrepudiation gained through PKI because the attacker can use the private key to digitally sign documents and pretend to be the authorized user. Both the holders of a digital certificate and the issuing authority must protect the computers, storage devices, or whatever they use to keep the private keys. Check_Content Review the application documentation and deployed configuration to determine whether the application's PKI authentication mechanism enforces authorized access to its corresponding private key. If the application's PKI authentication mechanism does not enforce authorized access to its corresponding private key, this is a finding. Fix_Text Configure the application's PKI authentication mechanism to enforce authorized access to its corresponding private key. Not_Reviewed Vuln_Num V-288142 Rule_ID SV-288142r1252912_rule Severity medium Rule_Title The application must map the authenticated identity to the individual user or group account for Public Key Infrastructure (PKI)-based authentication. Vuln_Discuss Without mapping the certificate used to authenticate to the user account, the ability to determine the identity of the individual user or group will not be available for forensic analysis. Check_Content Review the application documentation and deployed configuration to determine whether the application's PKI authentication mechanism maps the authenticated identity to the individual user or group account. If the application's PKI authentication mechanism does not map the authenticated identity to the individual user or group account, this is a finding. Fix_Text Configure the application's PKI authentication mechanism to map the authenticated identity to the individual user or group account. Not_Reviewed Vuln_Num V-288143 Rule_ID SV-288143r1252014_rule Severity medium Rule_Title The application must prohibit the use of cached authenticators after 12 hours. Vuln_Discuss If cached authentication information is out of date, the validity of the authentication information may be questionable. NIST SP 800-63B defines the value for the termination of cached authenticators. Check_Content Review application server documentation and deployed configuration to ensure the application prohibits the use of cached authenticators after an organization-defined time period. If the application does not prohibit the use of cached authenticators after an organization-defined time period, this is a finding. Fix_Text Configure the application to prohibit the use of cached authenticators after an organization-defined time period. Not_Reviewed Vuln_Num V-288144 Rule_ID SV-288144r1253072_rule Severity medium Rule_Title The application must only allow the use of DoW-approved (or other authorizing official [AO]-approved) Public Key Infrastructure (PKI)-established certificate authorities (CAs) for verification of the establishment of protected sessions. Vuln_Discuss Untrusted CAs can issue certificates, but they may be issued by organizations or individuals that seek to compromise DoW systems or by organizations with insufficient security controls. If the CA used for verifying the certificate is not a DoW-approved CA, trust of this CA has not been established. The DoW will only accept PKI certificates obtained from a DoW-approved internal or external certificate authority. Reliance on CAs for the establishment of secure sessions includes, for example, the use of Transport Layer Security (TLS) certificates. This requirement focuses on communications protection for the application session rather than for the network packet. This requirement applies to applications that use communications sessions. This includes, but is not limited to, web-based applications and service-oriented architectures (SOAs). Check_Content Navigate to the CA configuration section of the application. If the application is using CAs that are not DoW approved (or otherwise AO approved), this is a finding. Fix_Text Navigate to the CA configuration section of the application. Configure the application to use CAs that are DoW approved (or otherwise AO approved). Not_Reviewed Vuln_Num V-288145 Rule_ID SV-288145r1252020_rule Severity medium Rule_Title The application must employ identity providers and authorization servers to manage user, device, and nonperson entity (NPE) identities, attributes, and access rights supporting authentication and authorization decisions in accordance with organization-defined identification and authentication policy using organization-defined mechanisms. Vuln_Discuss Identity providers, both internal and external to the organization, manage the user, device, and NPE authenticators and issue statements, often called identity assertions, attesting to identities of other systems or systems components. Authorization servers create and issue access tokens to identified and authenticated users and devices that can be used to gain access to system or information resources. For example, single sign-on (SSO) provides identity provider and authorization server functions. Authenticator management (to include credential management) is covered by IA-05. Check_Content Review the application documentation and deployed configuration to determine whether the application employs identity providers and authorization servers to manage user, device, and NPE identities, attributes, and access rights supporting authentication and authorization decisions in accordance with organization-defined identification and authentication policy using organization-defined mechanisms. If the application does not employ identity providers and authorization servers to manage user, device, and NPE identities, attributes, and access rights supporting authentication and authorization decisions in accordance with organization-defined identification and authentication policy using organization-defined mechanisms, this is a finding. Fix_Text Configure the application to employ identity providers and authorization servers to manage user, device, and NPE identities, attributes, and access rights supporting authentication and authorization decisions in accordance with organization-defined identification and authentication policy using organization-defined mechanisms. Not_Reviewed Vuln_Num V-288146 Rule_ID SV-288146r1252023_rule Severity medium Rule_Title The application must generate, manage, and protect from disclosure and misuse the cryptographic keys that protect access tokens. Vuln_Discuss Identity assertions and access tokens are typically digitally signed. The private keys used to sign these assertions and tokens are protected commensurate with the impact of the system and information resources that can be accessed. Check_Content Review the application documentation and deployed configuration to determine whether the application generates, manages, and protects from disclosure and misuse the cryptographic keys that protect access tokens. If the application does not generate, manage, and protect from disclosure and misuse the cryptographic keys that protect access tokens, this is a finding. Fix_Text Configure the application to generate, manage, and protect from disclosure and misuse the cryptographic keys that protect access tokens. Not_Reviewed Vuln_Num V-288147 Rule_ID SV-288147r1252026_rule Severity medium Rule_Title The application must protect the private keys used to sign assertions and tokens commensurate with the impact of the system and information resources that can be accessed. Vuln_Discuss This includes verification of digital signatures protecting identity assertions and access tokens, as well as included metadata. Metadata includes information about the access request such as information unique to user, system or information resource being accessed, or the transaction itself such as time. Protected system and information resources could include connected networks, applications, and Application Programming Interfaces (APIs). Check_Content Review the application documentation and deployed configuration to determine whether the application protects the private keys used to sign assertions and tokens commensurate with the impact of the system and information resources that can be accessed. If the application does not protect the private keys used to sign assertions and tokens commensurate with the impact of the system and information resources that can be accessed, this is a finding. Fix_Text Configure the application to protect the private keys used to sign assertions and tokens commensurate with the impact of the system and information resources that can be accessed. Not_Reviewed Vuln_Num V-288148 Rule_ID SV-288148r1252654_rule Severity medium Rule_Title The application must generate assertions in accordance with organization-defined identification and authentication policy. Vuln_Discuss In the context of authentication, an assertion is a verifiable statement from an Identity Provider (IdP) to a Relying Party (RP) that contains information about an end-user, including their authentication status and other relevant details. An assertion is essentially a message or document that the IdP (like a website or service that handles logins) sends to the RP (the application or service the user is trying to access) to confirm that a user has been authenticated. Assertions typically include information about: - User identity: The user's name, email, or other identifying attributes. - Authentication status: Whether the user has successfully logged in and the method used (e.g., password, multifactor authentication [MFA]). - Time of authentication: When the user was authenticated. - Attributes: Other relevant user data, like roles, permissions, or department affiliations. Check_Content Review the application documentation and deployed configuration to determine whether the application generates assertions in accordance with organization-defined identification and authentication policy. If the application does not generate assertions in accordance with organization-defined identification and authentication policy, this is a finding. Fix_Text Configure the application to generate assertions in accordance with organization-defined identification and authentication policy. Not_Reviewed Vuln_Num V-288149 Rule_ID SV-288149r1252655_rule Severity medium Rule_Title The application must issue assertions in accordance with organization-defined identification and authentication policy. Vuln_Discuss In the context of authentication, an assertion is a verifiable statement from an Identity Provider (IdP) to a Relying Party (RP) that contains information about an end-user, including their authentication status and other relevant details. An assertion is essentially a message or document that the IdP (like a website or service that handles logins) sends to the RP (the application or service the user is trying to access) to confirm that a user has been authenticated. Assertions typically include information about: - User identity: The user's name, email, or other identifying attributes. - Authentication status: Whether the user has successfully logged in and the method used (e.g., password, multifactor authentication [MFA]). - Time of authentication: When the user was authenticated. - Attributes: Other relevant user data, like roles, permissions, or department affiliations. Check_Content Review the application documentation and deployed configuration to determine whether the application issues assertions in accordance with organization-defined identification and authentication policy. If the application does not issue assertions in accordance with organization-defined identification and authentication policy, this is a finding. Fix_Text Configure the application to issue assertions in accordance with organization-defined identification and authentication policy. Not_Reviewed Vuln_Num V-288150 Rule_ID SV-288150r1252656_rule Severity medium Rule_Title The application must refresh assertions in accordance with organization-defined identification and authentication policy. Vuln_Discuss In the context of authentication, an assertion is a verifiable statement from an Identity Provider (IdP) to a Relying Party (RP) that contains information about an end-user, including their authentication status and other relevant details. An assertion is essentially a message or document that the IdP (like a website or service that handles logins) sends to the RP (the application or service the user is trying to access) to confirm that a user has been authenticated. Assertions typically include information about: - User identity: The user's name, email, or other identifying attributes. - Authentication status: Whether the user has successfully logged in and the method used (e.g., password, multifactor authentication [MFA]). - Time of authentication: When the user was authenticated. - Attributes: Other relevant user data, like roles, permissions, or department affiliations. Check_Content Review the application documentation and deployed configuration to determine whether the application refreshes assertions in accordance with organization-defined identification and authentication policy. If the application does not refresh assertions in accordance with organization-defined identification and authentication policy, this is a finding. Fix_Text Configure the application to refresh assertions in accordance with organization-defined identification and authentication policy. Not_Reviewed Vuln_Num V-288151 Rule_ID SV-288151r1252657_rule Severity medium Rule_Title The application must revoke assertions in accordance with organization-defined identification and authentication policy. Vuln_Discuss In the context of authentication, an assertion is a verifiable statement from an Identity Provider (IdP) to a Relying Party (RP) that contains information about an end-user, including their authentication status and other relevant details. An assertion is essentially a message or document that the IdP (like a website or service that handles logins) sends to the RP (the application or service the user is trying to access) to confirm that a user has been authenticated. Assertions typically include information about: - User identity: The user's name, email, or other identifying attributes. - Authentication status: Whether the user has successfully logged in and the method used (e.g., password, multifactor authentication [MFA]). - Time of authentication: When the user was authenticated. - Attributes: Other relevant user data, like roles, permissions, or department affiliations. Check_Content Review the application documentation and deployed configuration to determine whether the application revokes assertions in accordance with organization-defined identification and authentication policy. If the application does not revoke assertions in accordance with organization-defined identification and authentication policy, this is a finding. Fix_Text Configure the application to revoke assertions in accordance with organization-defined identification and authentication policy. Not_Reviewed Vuln_Num V-288152 Rule_ID SV-288152r1252658_rule Severity medium Rule_Title The application must time-restrict assertions in accordance with organization-defined identification and authentication policy. Vuln_Discuss In the context of authentication, an assertion is a verifiable statement from an Identity Provider (IdP) to a Relying Party (RP) that contains information about an end-user, including their authentication status and other relevant details. An assertion is essentially a message or document that the IdP (like a website or service that handles logins) sends to the RP (the application or service the user is trying to access) to confirm that a user has been authenticated. Assertions typically include information about: - User identity: The user's name, email, or other identifying attributes. - Authentication status: Whether the user has successfully logged in and the method used (e.g., password, multifactor authentication [MFA]). - Time of authentication: When the user was authenticated. - Attributes: Other relevant user data, like roles, permissions, or department affiliations. Check_Content Review the application documentation and deployed configuration to determine whether the application time-restricts assertions in accordance with organization-defined identification and authentication policy. If the application does not time-restrict assertions in accordance with organization-defined identification and authentication policy, this is a finding. Fix_Text Configure the application to time-restrict assertions in accordance with organization-defined identification and authentication policy. Not_Reviewed Vuln_Num V-288153 Rule_ID SV-288153r1252659_rule Severity medium Rule_Title The application must audience-restrict assertions in accordance with organization-defined identification and authentication policy. Vuln_Discuss In the context of authentication, an assertion is a verifiable statement from an Identity Provider (IdP) to a Relying Party (RP) that contains information about an end-user, including their authentication status and other relevant details. An assertion is essentially a message or document that the IdP (like a website or service that handles logins) sends to the RP (the application or service the user is trying to access) to confirm that a user has been authenticated. Assertions typically include information about: - User identity: The user's name, email, or other identifying attributes. - Authentication status: Whether the user has successfully logged in and the method used (e.g., password, multifactor authentication [MFA]). - Time of authentication: When the user was authenticated. - Attributes: Other relevant user data, like roles, permissions, or department affiliations. Check_Content Review the application documentation and deployed configuration to determine whether the application audience-restricts assertions in accordance with organization-defined identification and authentication policy. If the application does not audience-restrict assertions in accordance with organization-defined identification and authentication policy, this is a finding. Fix_Text Configure the application to audience-restrict assertions in accordance with organization-defined identification and authentication policy. Not_Reviewed Vuln_Num V-288154 Rule_ID SV-288154r1252047_rule Severity medium Rule_Title The application must generate access tokens in accordance with organization-defined identification and authentication policy. Vuln_Discuss An access token is a piece of data that represents the authorization granted to a user or NPE to access specific systems or information resources. Access tokens enable controlled access to services and resources. Properly managing the lifecycle of access tokens, including their issuance, validation, and revocation, is crucial to maintaining confidentiality of data and systems. Restricting token validity to a specific audience (e.g., an application or security domain), and restricting token validity lifetimes are important practices. Access tokens are revoked or invalidated if they are compromised, lost, or are no longer needed to mitigate the risks associated with stolen or misused tokens. Check_Content Review the application documentation and deployed configuration to determine whether the application generates access tokens in accordance with organization-defined identification and authentication policy. If the application does not generate access tokens in accordance with organization-defined identification and authentication policy, this is a finding. Fix_Text Configure the application to generate access tokens in accordance with organization-defined identification and authentication policy. Not_Reviewed Vuln_Num V-288155 Rule_ID SV-288155r1252914_rule Severity medium Rule_Title The application must issue access tokens in accordance with organization-defined identification and authentication policy. Vuln_Discuss An access token is a piece of data that represents the authorization granted to a user or nonperson entity (NPE) to access specific systems or information resources. Access tokens enable controlled access to services and resources. Properly managing the lifecycle of access tokens, including their issuance, validation, and revocation, is crucial to maintaining confidentiality of data and systems. Restricting token validity to a specific audience (e.g., an application or security domain), and restricting token validity lifetimes are important practices. Access tokens are revoked or invalidated if they are compromised, lost, or are no longer needed to mitigate the risks associated with stolen or misused tokens. Check_Content Review the application documentation and deployed configuration to determine whether the application issues access tokens in accordance with organization-defined identification and authentication policy. If the application does not issue access tokens in accordance with organization-defined identification and authentication policy, this is a finding. Fix_Text Configure the application to issue access tokens in accordance with organization-defined identification and authentication policy. Not_Reviewed Vuln_Num V-288156 Rule_ID SV-288156r1252915_rule Severity medium Rule_Title The application must refresh access tokens in accordance with organization-defined identification and authentication policy. Vuln_Discuss An access token is a piece of data that represents the authorization granted to a user or nonperson entity (NPE) to access specific systems or information resources. Access tokens enable controlled access to services and resources. Properly managing the lifecycle of access tokens, including their issuance, validation, and revocation, is crucial to maintaining confidentiality of data and systems. Restricting token validity to a specific audience (e.g., an application or security domain), and restricting token validity lifetimes are important practices. Access tokens are revoked or invalidated if they are compromised, lost, or are no longer needed to mitigate the risks associated with stolen or misused tokens. Check_Content Review the application documentation and deployed configuration to determine whether the application refreshes access tokens in accordance with organization-defined identification and authentication policy. If the application does not refresh access tokens in accordance with organization-defined identification and authentication policy, this is a finding. Fix_Text Configure the application to refresh access tokens in accordance with organization-defined identification and authentication policy. Not_Reviewed Vuln_Num V-288157 Rule_ID SV-288157r1252916_rule Severity medium Rule_Title The application must revoke access tokens in accordance with organization-defined identification and authentication policy. Vuln_Discuss An access token is a piece of data that represents the authorization granted to a user or nonperson entity (NPE) to access specific systems or information resources. Access tokens enable controlled access to services and resources. Properly managing the lifecycle of access tokens, including their issuance, validation, and revocation, is crucial to maintaining confidentiality of data and systems. Restricting token validity to a specific audience (e.g., an application or security domain), and restricting token validity lifetimes are important practices. Access tokens are revoked or invalidated if they are compromised, lost, or are no longer needed to mitigate the risks associated with stolen or misused tokens. Check_Content Review the application documentation and deployed configuration to determine whether the application revokes access tokens in accordance with organization-defined identification and authentication policy. If the application does not revoke access tokens in accordance with organization-defined identification and authentication policy, this is a finding. Fix_Text Configure the application to revoke access tokens in accordance with organization-defined identification and authentication policy. Not_Reviewed Vuln_Num V-288158 Rule_ID SV-288158r1252917_rule Severity medium Rule_Title The application must time-restrict access tokens in accordance with organization-defined identification and authentication policy. Vuln_Discuss An access token is a piece of data that represents the authorization granted to a user or nonperson entity (NPE) to access specific systems or information resources. Access tokens enable controlled access to services and resources. Properly managing the lifecycle of access tokens, including their issuance, validation, and revocation, is crucial to maintaining confidentiality of data and systems. Restricting token validity to a specific audience (e.g., an application or security domain), and restricting token validity lifetimes are important practices. Access tokens are revoked or invalidated if they are compromised, lost, or are no longer needed to mitigate the risks associated with stolen or misused tokens. Check_Content Review the application documentation and deployed configuration to determine whether the application time-restricts access tokens in accordance with organization-defined identification and authentication policy. If the application does not time-restrict access tokens in accordance with organization-defined identification and authentication policy, this is a finding. Fix_Text Configure the application to time-restrict access tokens in accordance with organization-defined identification and authentication policy. Not_Reviewed Vuln_Num V-288159 Rule_ID SV-288159r1253074_rule Severity medium Rule_Title The application must audience-restrict access tokens in accordance with organization-defined identification and authentication policy. Vuln_Discuss An access token is a piece of data that represents the authorization granted to a user or nonperson entity (NPE) to access specific systems or information resources. Access tokens enable controlled access to services and resources. Properly managing the lifecycle of access tokens, including their issuance, validation, and revocation, is crucial to maintaining confidentiality of data and systems. Restricting token validity to a specific audience (e.g., an application or security domain), and restricting token validity lifetimes are important practices. Access tokens are revoked or invalidated if they are compromised, lost, or are no longer needed to mitigate the risks associated with stolen or misused tokens. Check_Content Review the application documentation and deployed configuration to determine whether the application audience-restricts access tokens in accordance with organization-defined identification and authentication policy. If the application does not audience-restrict access tokens in accordance with organization-defined identification and authentication policy, this is a finding. Fix_Text Configure the application to audience-restrict access tokens in accordance with organization-defined identification and authentication policy. Not_Reviewed Vuln_Num V-288160 Rule_ID SV-288160r1252661_rule Severity medium Rule_Title The application must automatically remove or disable temporary user accounts after 72 hours. Vuln_Discuss 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 DoW-defined time period of 72 hours. To address access requirements, many application developers choose to integrate their applications with enterprise-level authentication/access 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_Content Navigate to the account configuration function within the application. Verify the application is configured to automatically remove or disable temporary user accounts after 72 hours. Otherwise, this is a finding. Fix_Text Navigate to the account configuration function within the application. Configure a policy to automatically remove or disable temporary user accounts after 72 hours. Not_Reviewed Vuln_Num V-288161 Rule_ID SV-288161r1252663_rule Severity medium Rule_Title The application must automatically disable accounts after a 35-day period of account inactivity. Vuln_Discuss 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_Content Navigate to the account configuration function within the application. Verify the application is configured to disable accounts after a 35-day period of account inactivity. Otherwise, this is a finding. Fix_Text Navigate to the account configuration function within the application. Configure a policy to disable accounts after a 35-day period of account inactivity. Not_Reviewed Vuln_Num V-288162 Rule_ID SV-288162r1252665_rule Severity medium Rule_Title The application must enforce the limit of three consecutive invalid logon attempts by a user during a 15-minute time period. Vuln_Discuss 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_Content Navigate to the account configuration function within the application. Verify the application is configured to enforce the limit of three consecutive invalid logon attempts by a user during a 15-minute time period. Otherwise, this is a finding. Fix_Text Navigate to the account configuration function within the application. Configure a policy to enforce the limit of three consecutive invalid logon attempts by a user during a 15-minute time period. Not_Reviewed Vuln_Num V-288163 Rule_ID SV-288163r1252668_rule Severity medium Rule_Title The application must enforce a minimum 15-character password length. Vuln_Discuss 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_Content Navigate to the account configuration function within the application. Verify the application is configured to enforce a minimum 15-character password length. Otherwise, this is a finding. Fix_Text Navigate to the account configuration function within the application. Configure a policy to enforce a minimum 15-character password length. Not_Reviewed Vuln_Num V-288164 Rule_ID SV-288164r1252670_rule Severity medium Rule_Title The application must enforce password complexity by requiring that at least one uppercase character be used. Vuln_Discuss 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_Content Navigate to the account configuration function within the application. Verify the application is configured to enforce password complexity by requiring that at least one uppercase character be used. Otherwise, this is a finding. Fix_Text Navigate to the account configuration function within the application. Configure a policy to enforce password complexity by requiring that at least one uppercase character be used. Not_Reviewed Vuln_Num V-288165 Rule_ID SV-288165r1252672_rule Severity medium Rule_Title The application must enforce password complexity by requiring that at least one lowercase character be used. Vuln_Discuss 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_Content Navigate to the account configuration function within the application. Verify the application is configured to enforce password complexity by requiring that at least one lowercase character be used. Otherwise, this is a finding. Fix_Text Navigate to the account configuration function within the application. Configure a policy to enforce password complexity by requiring that at least one lowercase character be used. Not_Reviewed Vuln_Num V-288166 Rule_ID SV-288166r1252674_rule Severity medium Rule_Title The application must enforce password complexity by requiring that at least one numeric character be used. Vuln_Discuss 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_Content Navigate to the account configuration function within the application. Verify the application is configured to enforce password complexity by requiring that at least one numeric character be used. Otherwise, this is a finding. Fix_Text Navigate to the account configuration function within the application. Configure a policy to enforce password complexity by requiring that at least one numeric character be used. Not_Reviewed Vuln_Num V-288167 Rule_ID SV-288167r1252676_rule Severity medium Rule_Title The application must enforce password complexity by requiring that at least one special character be used. Vuln_Discuss 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_Content Navigate to the account configuration function within the application. Verify the application is configured to enforce password complexity by requiring that at least one special character be used. Otherwise, this is a finding. Fix_Text Navigate to the account configuration function within the application. Configure a policy to enforce password complexity by requiring that at least one special character be used. Not_Reviewed Vuln_Num V-288168 Rule_ID SV-288168r1252678_rule Severity medium Rule_Title The application must require the change of at least 50 percent of the characters when passwords are changed. Vuln_Discuss 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_Content Navigate to the account configuration function within the application. Verify the application is configured to enforce password complexity by requiring the change of at least 50 percent of the characters when passwords are changed. Otherwise, this is a finding. Fix_Text Navigate to the account configuration function within the application. Configure a policy to enforce password complexity by requiring the change of at least 50 percent of the characters when passwords are changed. Not_Reviewed Vuln_Num V-288169 Rule_ID SV-288169r1252681_rule Severity medium Rule_Title The application must enforce 24 hours/one day as the minimum password lifetime. Vuln_Discuss 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 must 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_Content Navigate to the account configuration function within the application. Verify the application is configured to enforce 24 hours/one day as the minimum password lifetime. Otherwise, this is a finding. Fix_Text Navigate to the account configuration function within the application. Configure a policy to enforce 24 hours/one day as the minimum password lifetime. Not_Reviewed Vuln_Num V-288170 Rule_ID SV-288170r1252683_rule Severity medium Rule_Title The application must enforce a 60-day maximum password lifetime restriction. Vuln_Discuss 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, which are meant for access to the application in case of failure. These accounts are not required to have maximum password lifetime restrictions. Check_Content Navigate to the account configuration function within the application. Verify the application is configured to enforce a 60-day maximum password lifetime restriction. Otherwise, this is a finding. Fix_Text Navigate to the account configuration function within the application. Configure a policy to enforce a 60-day maximum password lifetime restriction. Not_Reviewed Vuln_Num V-288171 Rule_ID SV-288171r1252098_rule Severity medium Rule_Title The application must obscure feedback of authentication information during the authentication process to protect the information from possible exploitation/use by unauthorized individuals. Vuln_Discuss To prevent the compromise of authentication information such as passwords during the authentication process, the feedback from the information system must not provide any information that would allow an unauthorized user to compromise the authentication mechanism. Obfuscation of user-provided information when typed into the system is a method used in addressing this risk. For example, displaying asterisks when a user types in a password is an example of obscuring feedback of authentication information. Check_Content Review the application documentation and deployed configuration to determine whether the applications authentication mechanism obscures the feedback of authentication information during the authentication process. If the applications authentication mechanism does not obscure the feedback of authentication information during the authentication process, this is a finding. Fix_Text Navigate to the authentication configuration function within the application. Configure the applications authentication mechanism to obscure the feedback of authentication information during the authentication process. Not_Reviewed Vuln_Num V-288172 Rule_ID SV-288172r1252685_rule Severity medium Rule_Title The application must automatically disable temporary and emergency accounts after 72 hours. Vuln_Discuss Emergency accounts are administrator accounts 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 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_Content Navigate to the account configuration function within the application. Verify the application is configured to disable temporary and emergency accounts after 72 hours. Otherwise, this is a finding. Fix_Text Navigate to the account configuration function within the application. Configure a policy to disable temporary and emergency accounts after 72 hours. Not_Reviewed Vuln_Num V-288173 Rule_ID SV-288173r1252687_rule Severity medium Rule_Title The application must terminate shared/group account credentials when members leave the group. Vuln_Discuss 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_Content Navigate to the account/role configuration function within the application. Verify the application is configured to terminate shared/group account credentials when members leave the group. Otherwise, this is a finding. Fix_Text Navigate to the account/role configuration function within the application. Configure a policy to terminate shared/group account credentials when members leave the group. Not_Reviewed Vuln_Num V-288174 Rule_ID SV-288174r1252689_rule Severity medium Rule_Title The application must automatically lock the account until the locked account is released by an administrator when three unsuccessful login attempts in 15 minutes are exceeded. Vuln_Discuss 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_Content Navigate to the account configuration function within the application. Verify the application is configured to automatically lock the account until the locked account is released by an administrator when three unsuccessful login attempts in 15 minutes are exceeded. Otherwise, this is a finding. Fix_Text Navigate to the account configuration function within the application. Configure a policy to automatically lock the account until the locked account is released by an administrator when three unsuccessful login attempts in 15 minutes are exceeded. Not_Reviewed Vuln_Num V-288175 Rule_ID SV-288175r1252691_rule Severity medium Rule_Title The application must disable accounts when the accounts have expired. Vuln_Discuss 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_Content Navigate to the account configuration function within the application. Verify the application is configured to disable accounts when the accounts have expired. Otherwise, this is a finding. Fix_Text Navigate to the account configuration function within the application. Configure a policy to disable accounts when the accounts have expired. Not_Reviewed Vuln_Num V-288176 Rule_ID SV-288176r1252693_rule Severity medium Rule_Title The application must disable accounts when the accounts are no longer associated to a user. Vuln_Discuss 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_Content Navigate to the account configuration function within the application. Verify the application is configured to disable accounts when the accounts are no longer associated to a user. Otherwise, this is a finding. Fix_Text Navigate to the account configuration function within the application. Configure a policy to disable accounts when the accounts are no longer associated to a user. Not_Reviewed Vuln_Num V-288177 Rule_ID SV-288177r1252695_rule Severity medium Rule_Title The application must disable accounts when the accounts are in violation of organizational policy. Vuln_Discuss 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_Content Navigate to the account configuration function within the application. Verify the application is configured to disable accounts when the accounts are in violation of organizational policy. Otherwise, this is a finding. Fix_Text Navigate to the account configuration function within the application. Configure a policy to disable accounts when the accounts are in violation of organizational policy. Not_Reviewed Vuln_Num V-288178 Rule_ID SV-288178r1252698_rule Severity medium Rule_Title For accounts using password authentication, the application must use FIPS-validated cryptographic algorithms defined in CNSSP 15 Annex B to protect the integrity and confidentiality of the password authentication process. Vuln_Discuss Passwords must be protected at all times, and encryption is the standard method for protecting passwords. If passwords are not encrypted, they can be plainly read (i.e., clear text) and easily compromised. The information system must specify the hash algorithm used for authenticating passwords. Implementation of this requirement requires configuration of FIPS-approved cipher block algorithm and block cipher modes for encryption (e.g., SHA-384). This requirement applies to all accounts, including authentication server; Authorization, Authentication, and Accounting (AAA); and local accounts such as the root account and the account of last resort. This requirement only applies to components where this is specific to the function of the device (e.g., TLS VPN or ALG). This does not apply to authentication for the purpose of configuring the device itself (management). Check_Content Review the application documentation and deployed configuration to determine whether the application's authentication mechanism uses FIPS-validated cryptographic algorithms defined in CNSSP 15 Annex B to protect the integrity and confidentiality of the password authentication process. If the application's authentication mechanism does not uses FIPS-validated cryptographic algorithms defined in CNSSP 15 Annex B to protect the integrity and confidentiality of the password authentication process, this is a finding. Fix_Text Navigate to the authentication configuration function within the application. Configure the application's authentication mechanism to use FIPS-validated cryptographic algorithms defined in CNSSP 15 Annex B to protect the integrity and confidentiality of the password authentication process. Not_Reviewed Vuln_Num V-288179 Rule_ID SV-288179r1252701_rule Severity medium Rule_Title For accounts using password authentication, the application must store only cryptographic representations of passwords. Vuln_Discuss Passwords must 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 must 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 DoW employee, member of the military, or DoW 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 (e.g., SHA-384) 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_Content Review the application documentation and deployed configuration to determine whether the application's authentication mechanism stores only cryptographic representations of passwords. If the application's authentication mechanism does not store only cryptographic representations of passwords, this is a finding. Fix_Text Navigate to the authentication configuration function within the application. Configure the application's authentication mechanism to store only cryptographic representations of passwords. Not_Reviewed Vuln_Num V-288180 Rule_ID SV-288180r1252704_rule Severity medium Rule_Title The application must, for password-based authentication, maintain a list of commonly used, expected, or compromised passwords on an organization-defined frequency. Vuln_Discuss Password-based authentication applies to passwords regardless of whether they are used in single-factor or multifactor 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_Content Review the application documentation and deployed configuration to determine whether the application's authentication mechanism maintains a list of commonly used, expected, or compromised passwords on an organization-defined frequency. If the application's authentication mechanism does not maintain a list of commonly used, expected, or compromised passwords on an organization-defined frequency, this is a finding. Fix_Text Navigate to the authentication configuration function within the application. Configure the application's authentication mechanism to maintain a list of commonly used, expected, or compromised passwords on an organization-defined frequency. Not_Reviewed Vuln_Num V-288181 Rule_ID SV-288181r1252707_rule Severity medium Rule_Title The application must, for password-based authentication, update the list of known passwords on an organization-defined frequency. Vuln_Discuss Password-based authentication applies to passwords regardless of whether they are used in single-factor or multifactor 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_Content Review the application documentation and deployed configuration to determine whether the application's authentication mechanism updates the list of known passwords on an organization-defined frequency. If the application's authentication mechanism does not maintain a list of commonly used, expected, or compromised passwords on an organization-defined frequency, this is a finding. Fix_Text Navigate to the authentication configuration function within the application. Configure the application's authentication mechanism to update the list of known passwords on an organization-defined frequency. Not_Reviewed Vuln_Num V-288182 Rule_ID SV-288182r1252710_rule Severity medium Rule_Title The application must, for password-based authentication, update the list of passwords when organizational passwords are suspected to have been compromised directly or indirectly. Vuln_Discuss Password-based authentication applies to passwords regardless of whether they are used in single-factor or multifactor 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_Content Review the application documentation and deployed configuration to determine whether the application's authentication mechanism update the list of passwords when organizational passwords are suspected to have been compromised directly or indirectly. If the application's authentication mechanism does not update the list of passwords when organizational passwords are suspected to have been compromised directly or indirectly, this is a finding. Fix_Text Navigate to the authentication configuration function within the application. Configure the application's authentication mechanism to update the list of passwords when organizational passwords are suspected to have been compromised directly or indirectly. Not_Reviewed Vuln_Num V-288183 Rule_ID SV-288183r1252920_rule Severity medium Rule_Title The application 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). Vuln_Discuss Password-based authentication applies to passwords regardless of whether they are used in single-factor or multifactor 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_Content Review the application documentation and deployed configuration to determine whether the application's authentication mechanism verifies 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 application's authentication mechanism does not 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_Text Navigate to the authentication configuration function within the application. Configure the application's authentication mechanism 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). Not_Reviewed Vuln_Num V-288184 Rule_ID SV-288184r1252716_rule Severity medium Rule_Title The application must, for password-based authentication, store passwords using an approved salted key derivation function, preferably using a keyed hash. Vuln_Discuss Password-based authentication applies to passwords regardless of whether they are used in single-factor or multifactor 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_Content Review the application documentation and deployed configuration to determine whether the application's authentication mechanism stores passwords using an approved salted key derivation function, preferably using a keyed hash. If the application's authentication mechanism does not store passwords using an approved salted key derivation function, preferably using a keyed hash, this is a finding. Fix_Text Navigate to the authentication configuration function within the application. Configure the application's authentication mechanism to store passwords using an approved salted key derivation function, preferably using a keyed hash. Not_Reviewed Vuln_Num V-288185 Rule_ID SV-288185r1252719_rule Severity medium Rule_Title The application must, for password-based authentication, require immediate selection of a new password upon account recovery. Vuln_Discuss Password-based authentication applies to passwords regardless of whether they are used in single-factor or multifactor 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_Content Review the application documentation and deployed configuration to determine whether the application's authentication mechanism requires immediate selection of a new password upon account recovery. If the application's authentication mechanism does not require immediate selection of a new password upon account recovery, this is a finding. Fix_Text Navigate to the authentication configuration function within the application. Configure the application's authentication mechanism to require immediate selection of a new password upon account recovery. Not_Reviewed Vuln_Num V-288186 Rule_ID SV-288186r1252722_rule Severity medium Rule_Title The application must, for password-based authentication, allow user selection of long passwords and passphrases, including spaces and all printable characters. Vuln_Discuss Password-based authentication applies to passwords regardless of whether they are used in single-factor or multifactor 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_Content Review the application documentation and deployed configuration to determine whether the application's authentication mechanism allows user selection of long passwords and passphrases, including spaces and all printable characters. If the application's authentication mechanism does not allow user selection of long passwords and passphrases, including spaces and all printable characters, this is a finding. Fix_Text Navigate to the authentication configuration function within the application. Configure the application's authentication mechanism to require user selection of long passwords and passphrases, including spaces and all printable characters, this is a finding. Not_Reviewed Vuln_Num V-288187 Rule_ID SV-288187r1252725_rule Severity medium Rule_Title The application must, for password-based authentication, employ automated tools to assist the user in selecting strong password authenticators. Vuln_Discuss Password-based authentication applies to passwords regardless of whether they are used in single-factor or multifactor 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_Content Review the application documentation and deployed configuration to determine whether the application's authentication mechanism employs automated tools to assist the user in selecting strong password authenticators. If the application's authentication mechanism does not employ automated tools to assist the user in selecting strong password authenticators, this is a finding. Fix_Text Navigate to the authentication configuration function within the application. Configure the application's authentication mechanism to employ automated tools to assist the user in selecting strong password authenticators, this is a finding. Not_Reviewed Vuln_Num V-288188 Rule_ID SV-288188r1252728_rule Severity medium Rule_Title The application must, for password-based authentication, enforce organization-defined composition and complexity rules. Vuln_Discuss Password-based authentication applies to passwords regardless of whether they are used in single-factor or multifactor 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_Content Review the application documentation and deployed configuration to determine whether the application's authentication mechanism enforces organization-defined composition and complexity rules. If the application's authentication mechanism does not enforce organization-defined composition and complexity rules, this is a finding. Fix_Text Navigate to the authentication configuration function within the application. Configure the application's authentication mechanism to enforce organization-defined composition and complexity rules. Not_Reviewed Vuln_Num V-288189 Rule_ID SV-288189r1252731_rule Severity medium Rule_Title The application must limit the number of concurrent sessions to a maximum number of three for all accounts and/or account types. Vuln_Discuss Application management includes the ability to control the number of users and user sessions that use an application. Limiting the number of allowed users and sessions per user is helpful in limiting risks related to denial-of-service (DoS) attacks. This requirement may be met via the application or by using information system session control provided by a web server with specialized session management capabilities. If it has been specified that this requirement will be handled by the application, the capability to limit the maximum number of concurrent single user sessions must be designed and built into the application. This requirement addresses concurrent sessions for information system accounts and does not address concurrent sessions by single users via multiple system accounts. The maximum number of concurrent sessions must be defined based upon mission needs and the operational environment for each system. Check_Content Review the application documentation and deployed configuration to determine whether the application's authentication mechanism limits the number of concurrent sessions to a maximum number of three for all accounts and/or account types. If the application's authentication mechanism does not limit the number of concurrent sessions to a maximum number of three for all accounts and/or account types, this is a finding. Fix_Text Navigate to the authentication configuration function within the application. Configure the application's authentication mechanism to limit the number of concurrent sessions to a maximum number of three for all accounts and/or account types. Not_Reviewed Vuln_Num V-288190 Rule_ID SV-288190r1252155_rule Severity medium Rule_Title The application must terminate all network connections associated with a communications session at the end of the session, or no more than 15 minutes of inactivity. Vuln_Discuss 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_Content Review the application documentation and deployed configuration to determine whether the application terminates all network connections associated with a communications session at the end of the session, or no more than 15 minutes of inactivity. If the application does not terminate all network connections associated with a communications session at the end of the session, or no more than 15 minutes of inactivity, this is a finding. Fix_Text Configure the application to terminate all network connections associated with a communications session at the end of the session, or no more than 15 minutes of inactivity. Not_Reviewed Vuln_Num V-288191 Rule_ID SV-288191r1252921_rule Severity medium Rule_Title The application must invalidate session identifiers upon user logout or other session termination. Vuln_Discuss Captured sessions can be reused in replay attacks. Applications that use communications sessions must invalidate session identifiers (IDs) upon user logout or other session termination limits to prevent adversaries from capturing and continuing to employ previously valid session IDs. This includes, but is not limited to, web-based applications and service-oriented architectures (SOAs). Session IDs are tokens generated by web applications to uniquely identify an application user's session. Applications will make application decisions and execute business logic based on the session ID. Unique session IDs are the opposite of sequentially generated session IDs that can be easily guessed by an attacker. Unique session IDs help to reduce predictability of said identifiers. When a user logs out, or when any other session termination event occurs, the application must terminate the user session to minimize the potential for an attacker to hijack that user session. Note: This only applies to communications protection for the application session not the network packet. Check_Content Review the application documentation and deployed configuration to determine whether the application invalidates session identifiers upon user logout or other session termination. If the application does not invalidate session identifiers upon user logout or other session termination, this is a finding. Fix_Text Configure the application to invalidate session identifiers upon user logout or other session termination. Not_Reviewed Vuln_Num V-288192 Rule_ID SV-288192r1252161_rule Severity medium Rule_Title Applications must recognize only system-generated session identifiers (IDs). Vuln_Discuss Applications use sessions and session IDs to control application behavior and user access. If an attacker can guess the session ID, or can inject or manually insert session information, the session may be compromised. Unique session IDs address man-in-the-middle attacks, including session hijacking or insertion of false information into a session. If the attacker is unable to identify or guess the session information related to pending application traffic, they will have more difficulty in hijacking the session or otherwise manipulating valid sessions. This requirement focuses on communications protection for the application session rather than for the network packet. This requirement applies to applications that use communications sessions. This includes, but is not limited to, web-based applications and service-oriented architectures (SOAs). Check_Content Review the application documentation and deployed configuration to determine whether the application recognizes only system-generated session IDs. If the application does not recognize only system-generated session IDs, this is a finding. Fix_Text Configure the application to recognize only system-generated session IDs. Not_Reviewed Vuln_Num V-288193 Rule_ID SV-288193r1253076_rule Severity medium Rule_Title The application must generate unique session identifiers using a FIPS-validated Random Number Generator (RNG) based on the Deterministic Random Bit Generators (DRBG) algorithm. Vuln_Discuss Sequentially generated session identifiers (IDs) can be easily guessed by an attacker. Employing the concept of randomness in the generation of unique session IDs helps to protect against brute-force attacks to determine future session identifiers. Unique session IDs address man-in-the-middle attacks, including session hijacking or insertion of false information into a session. If the attacker is unable to identify or guess the session information related to pending application traffic, they will have more difficulty in hijacking the session or otherwise manipulating valid sessions. The DRBGs Hash_DRBG, HMAC_DRBG, and CTR_DRBG are recommended for use with RNGs. This is applicable to devices that use a web interface for device management. Check_Content Review the application documentation and deployed configuration to determine whether the application generates unique session identifiers using a FIPS-validated RNG based on the DRBG algorithm. If the application does not generate unique session identifiers using a FIPS-validated RNG based on the DRBG algorithm, this is a finding. Fix_Text Configure the application to generate unique session identifiers using a FIPS-validated RNG based on the DRBG algorithm. Not_Reviewed Vuln_Num V-288194 Rule_ID SV-288194r1252926_rule Severity medium Rule_Title Applications requiring user access authentication must provide a logout function for user-initiated communication sessions. Vuln_Discuss If a user cannot explicitly end an application session, the session may remain open and be exploited by an attacker; this is referred to as a zombie session. Information resources to which users gain access via authentication include, for example, local workstations, databases, and password-protected websites/web-based services. However, for some types of interactive sessions including, for example, file transfer protocol (FTP) sessions, information systems typically send logout messages as final messages prior to terminating sessions. Check_Content Review the application documentation and deployed configuration to determine whether the application provides a logout function for user-initiated communication sessions. If the application does not provide a logout function for user-initiated communication sessions, this is a finding. Fix_Text Configure the application to provide a logout function for user-initiated communication sessions. Not_Reviewed Vuln_Num V-288195 Rule_ID SV-288195r1252170_rule Severity medium Rule_Title The application must display an explicit logout message to users indicating the reliable termination of authenticated communications sessions. Vuln_Discuss If a user cannot explicitly end an application session, the session may remain open and be exploited by an attacker; this is referred to as a zombie session. Users must be aware of whether or not the session has been terminated. Information resources to which users gain access via authentication include, for example, local workstations, databases, and password-protected websites/web-based services. Logout messages for web page access, for example, can be displayed after authenticated sessions have been terminated. However, for some types of interactive sessions including, for example, file transfer protocol (FTP) sessions, information systems typically send logout messages as final messages prior to terminating sessions. Check_Content Review the application documentation and deployed configuration to determine whether the application displays an explicit logout message to users indicating the reliable termination of authenticated communications sessions. If the application does not display an explicit logout message to users indicating the reliable termination of authenticated communications sessions, this is a finding. Fix_Text Configure the application to display an explicit logout message to users indicating the reliable termination of authenticated communications sessions. Not_Reviewed Vuln_Num V-288196 Rule_ID SV-288196r1252173_rule Severity medium Rule_Title The application must require users to reauthenticate when organization-defined circumstances or situations require reauthentication. Vuln_Discuss Without reauthentication, users may access resources or perform tasks for which they do not have authorization. When applications provide the capability to change security roles or escalate the functional capability of the application, it is critical the user reauthenticate. In addition to the reauthentication requirements associated with session locks, organizations may require reauthentication of individuals and/or devices 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 DoW, the minimum circumstances requiring reauthentication are privilege escalation and role changes. Check_Content Review the application documentation and deployed configuration to determine whether the application requires users to reauthenticate when organization-defined circumstances or situations require reauthentication. If the application does not require users to reauthenticate when organization-defined circumstances or situations require reauthentication, this is a finding. Fix_Text Configure the application to require users to reauthenticate when organization-defined circumstances or situations require reauthentication. Not_Reviewed Vuln_Num V-288197 Rule_ID SV-288197r1252733_rule Severity medium Rule_Title The application must automatically audit account creation. Vuln_Discuss Once an attacker establishes access to a system, the attacker often attempts to create a persistent method of reestablishing access. One way to accomplish this is for the attacker to simply 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 owners exists. 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 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_Content Review the application documentation and deployed configuration to determine whether the application's authentication mechanism audits account creation. If the application's authentication mechanism does not audit account creation, this is a finding. Fix_Text Configure the application to automatically audit account creation. Not_Reviewed Vuln_Num V-288198 Rule_ID SV-288198r1252973_rule Severity medium Rule_Title The application must automatically audit account modifications to include disabling/removal actions and attempts to access privileges. Vuln_Discuss Once an attacker establishes access to a system, the attacker often attempts to create a persistent method of reestablishing access. One way to accomplish this is for the attacker to simply 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 owners it exists. 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 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_Content Review the application documentation and deployed configuration to determine whether the application's authentication mechanism audits account modifications to include disabling/removal actions, and attempts to access privileges. If the application's authentication mechanism does not audit account modifications to include disabling/removal actions and attempts to access privileges, this is a finding. Fix_Text Navigate to the authentication configuration function within the application. Configure the application's authentication mechanism to audit account modifications to include disabling/removal actions, and attempts to access privileges. Not_Reviewed Vuln_Num V-288199 Rule_ID SV-288199r1252738_rule Severity medium Rule_Title The application must reveal error messages only to the information system security officer (ISSO), information system security manager (ISSM), if assigned, and/or security personnel as appropriate. Vuln_Discuss Only authorized personnel must be aware of errors and the details of the errors. Error messages are an indicator of an organization's operational state or can identify the application. Additionally, personally identifiable information (PII) and operational information must not be revealed through error messages to unauthorized personnel or their designated representatives. The structure and content of error messages must be carefully considered by the organization and development team. The extent to which the information system is able to identify and handle error conditions is guided by organizational policy and operational requirements. Check_Content Review the application documentation and deployed configuration to determine whether the application reveals error messages only to the ISSO/ISSM, if assigned, and/or security personnel as appropriate. If the application does not reveal error messages only to the ISSO/ISSM, if assigned, and/or security personnel as appropriate, this is a finding. Fix_Text Navigate to the authentication configuration function within the application. Configure the application to only reveal error messages to the ISSO, information ISSM, if assigned, and/or security personnel as appropriate. Not_Reviewed Vuln_Num V-288200 Rule_ID SV-288200r1252741_rule Severity medium Rule_Title In the event of an audit processing failure, the application must alert the information system security officer (ISSO), information system security manager (ISSM) at a minimum (if assigned) and/or security personnel as appropriate. Vuln_Discuss 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 this notification, the security personnel may be unaware of an impending failure of the audit capability and system operation may be adversely affected. Audit processing failures include software/hardware errors, failures in the audit capturing mechanisms, and audit storage capacity being reached or exceeded. This requirement applies to each audit data storage repository (i.e., distinct information system component where audit records are stored), the centralized audit storage capacity of organizations (i.e., all audit data storage repositories combined), or both. Check_Content Review the application documentation and deployed configuration to determine whether the application's alerting mechanism alerts the ISSO/ISSM at a minimum (if assigned) and/or security personnel as appropriate. If the application's alerting mechanism does not audit alerts the ISSO/ISSM at a minimum (if assigned) and/or security personnel as appropriate, this is a finding. Fix_Text Navigate to the alerting function configuration within the application. Configure the application to alert the ISSO and ISSM, at a minimum, in the event of audit processing failure. Not_Reviewed Vuln_Num V-288201 Rule_ID SV-288201r1252929_rule Severity medium Rule_Title The application must generate error messages that only provide the information necessary for corrective actions without revealing information that could be exploited. Vuln_Discuss Any application providing too much information in error messages risks compromising the data and security of the application and system. The structure and content of error messages must be carefully considered by the organization and development team. Organizations carefully consider the structure/content of error messages. The extent to which information systems are able to identify and handle error conditions is guided by organizational policy and operational requirements. Information that could be exploited by adversaries includes erroneous logon attempts with passwords entered by mistake as the username, mission/business information that can be derived from (if not stated explicitly by) information recorded, and personal information such as account numbers, social security numbers, and credit card numbers. Check_Content Review the application documentation and deployed configuration to determine if error messages generated by the application only provide the information necessary for corrective actions without revealing information that could be exploited. If error messages contain information that could be exploited, this is a finding. Fix_Text Configure that application to only provide the information necessary for corrective actions without revealing information that could be exploited. Not_Reviewed Vuln_Num V-288202 Rule_ID SV-288202r1252930_rule Severity medium Rule_Title The application must notify system administrators (SAs) and the information system security officer (ISSO) when accounts are created. Vuln_Discuss Once an attacker establishes access to an application, the attacker often attempts to create a persistent method of reestablishing access. One way to accomplish this is for the attacker to simply create a new account. Sending notification of account creation events to the SA and ISSO is one method for mitigating this risk. 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_Content Review the application documentation and deployed configuration to determine whether the application's alerting mechanism notifies SAs and the ISSO when accounts are created. If the application's alerting mechanism does not notify SAs and the ISSO when accounts are created, this is a finding. Fix_Text Navigate to the alerting function configuration within the application. Configure the application's alerting mechanism to notify SAs and the ISSO when accounts are created. Not_Reviewed Vuln_Num V-288203 Rule_ID SV-288203r1252747_rule Severity medium Rule_Title The application must notify system administrators (SAs) and the information system security officer (ISSO) when accounts are modified to include disabling and removal actions. Vuln_Discuss When application accounts are modified, user accessibility is affected. Accounts are used 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 also 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_Content Review the application documentation and deployed configuration to determine whether the application's alerting mechanism notifies SAs and the ISSO when accounts are modified to include disabling and removal actions. If the application's alerting mechanism does not notify SAs and the ISSO when accounts are modified to include disabling and removal actions, this is a finding. Fix_Text Navigate to the alerting function configuration within the application. Configure the application's alerting mechanism to notify SAs and the ISSO when accounts are modified to include disabling and removal actions. Not_Reviewed Vuln_Num V-288204 Rule_ID SV-288204r1252932_rule Severity medium Rule_Title The application must allow only the information system security manager (ISSM), or individuals or roles appointed by the ISSM, to select which auditable events are to be audited. Vuln_Discuss 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_Content Review the application documentation and deployed configuration to determine whether the application's auditing mechanism allows only the ISSM, or individuals or roles appointed by the ISSM, to select which auditable events are to be audited. If the application's auditing mechanism does not allow only the ISSM, or individuals or roles appointed by the ISSM, to select which auditable events are to be audited, this is a finding. Fix_Text Navigate to the auditing function configuration within the application. Configure the application's auditing mechanism to allow only the ISSM, or individuals or roles appointed by the ISSM, to select which auditable events are to be audited. Not_Reviewed Vuln_Num V-288205 Rule_ID SV-288205r1252753_rule Severity medium Rule_Title The application must initiate session auditing upon startup. Vuln_Discuss If auditing is enabled late in the startup process, the actions of some start-up processes may not be audited. Some audit systems also maintain state information only available if auditing is enabled before a given process is created. Check_Content Review the application documentation and deployed configuration to determine whether the application's auditing mechanism initiates session auditing upon startup. If the application's auditing mechanism does not initiate session auditing upon startup, this is a finding. Fix_Text Navigate to the auditing function configuration within the application. Configure the application's auditing mechanism to initiate session auditing upon startup. Not_Reviewed Vuln_Num V-288206 Rule_ID SV-288206r1252756_rule Severity medium Rule_Title The application must produce audit records containing descriptions of the audit events. Vuln_Discuss Without information about the outcome of events, security personnel cannot make an accurate assessment as to whether an attack was successful or if changes were made to the security state of the system. Event outcomes can include indicators of event success or failure and event-specific results (e.g., event descriptions such as what type of event occurred). As such, they also provide a means to measure the impact of an event and help authorized personnel to determine the appropriate response. Organizations log system accesses associated with applying configuration changes to ensure that configuration change control is implemented and to support after-the-fact actions should organizations discover any unauthorized changes. Check_Content Review the application documentation and deployed configuration to determine whether the application's auditing mechanism produces audit records containing descriptions of the audit events. If the application's auditing mechanism does not produce audit records containing descriptions of the audit events, this is a finding. Fix_Text Navigate to the auditing function configuration within the application. Configure the application's auditing mechanism to produce audit records containing descriptions of the audit events. Not_Reviewed Vuln_Num V-288207 Rule_ID SV-288207r1252759_rule Severity medium Rule_Title The application must produce audit records containing information to establish when (date and time) the events occurred. Vuln_Discuss Without information about the outcome of events, security personnel cannot make an accurate assessment as to whether an attack was successful or if changes were made to the security state of the system. Event outcomes can include indicators of event success or failure and event-specific results (e.g., data and time of the event). As such, they also provide a means to measure the impact of an event and help authorized personnel to determine the appropriate response. Organizations log system accesses associated with applying configuration changes to ensure configuration change control is implemented and to support after-the-fact actions should organizations discover any unauthorized changes. Check_Content Review the application documentation and deployed configuration to determine whether the application's auditing mechanism produces audit records containing information to establish when (date and time) the events occurred. If the application's auditing mechanism does not produce audit records containing information to establish when (date and time) the events occurred, this is a finding. Fix_Text Navigate to the auditing function configuration within the application. Configure the application's auditing mechanism to produce audit records containing information to establish when (date and time) the events occurred. Not_Reviewed Vuln_Num V-288208 Rule_ID SV-288208r1252762_rule Severity medium Rule_Title The application must produce audit records containing information to establish source and destination addresses. Vuln_Discuss Without information about the outcome of events, security personnel cannot make an accurate assessment as to whether an attack was successful or if changes were made to the security state of the system. Event outcomes can include indicators of event success or failure and event-specific results (e.g., source and destination addresses). As such, they also provide a means to measure the impact of an event and help authorized personnel to determine the appropriate response. Organizations log system accesses associated with applying configuration changes to ensure configuration change control is implemented and to support after-the-fact actions should organizations discover any unauthorized changes. Check_Content Review the application documentation and deployed configuration to determine whether the application's auditing mechanism produces audit records containing information to establish source and destination addresses. If the application's auditing mechanism does not produce audit records containing information to establish source and destination addresses, this is a finding. Fix_Text Navigate to the auditing function configuration within the application. Configure the application's auditing mechanism to produce audit records containing information to establish source and destination addresses. Not_Reviewed Vuln_Num V-288209 Rule_ID SV-288209r1252765_rule Severity medium Rule_Title The application must produce audit records that contain information to establish success indicators, fail indicators, and enforcement actions. Vuln_Discuss Without information about the outcome of events, security personnel cannot make an accurate assessment as to whether an attack was successful or if changes were made to the security state of the system. Event outcomes can include indicators of event success or failure and event-specific results (e.g., the security state of the information system after the event occurred). As such, they also provide a means to measure the impact of an event and help authorized personnel to determine the appropriate response. Organizations log system accesses associated with applying configuration changes to ensure configuration change control is implemented and to support after-the-fact actions should organizations discover any unauthorized changes. Check_Content Review the application documentation and deployed configuration to determine whether the application's auditing mechanism produces audit records that contain information to establish success indicators, fail indicators, and enforcement actions. If the application's auditing mechanism does not produce audit records that contain information to establish success indicators, fail indicators, and enforcement actions, this is a finding. Fix_Text Navigate to the auditing function configuration within the application. Configure the application's auditing mechanism to produce audit records that contain information to establish success indicators, fail indicators, and enforcement actions. Not_Reviewed Vuln_Num V-288210 Rule_ID SV-288210r1252768_rule Severity medium Rule_Title The application must generate audit records containing information that establishes the identity of any individual or process associated with the event. Vuln_Discuss Without information that establishes the identity of the subjects (i.e., users or processes acting on behalf of users) associated with the events, security personnel cannot determine responsibility for the potentially harmful event. Event identifiers (if authenticated or otherwise known) include, but are not limited to, user database tables, primary key values, user names, or process identifiers (PIDs). Check_Content Review the application documentation and deployed configuration to determine whether the application's auditing mechanism generates audit records containing information that establishes the identity of any individual or process associated with the event. If the application's auditing mechanism does not generate audit records containing information that establishes the identity of any individual or process associated with the event, this is a finding. Fix_Text Navigate to the auditing function configuration within the application. Configure the application's auditing mechanism to generate audit records containing information that establishes the identity of any individual or process associated with the event. Not_Reviewed Vuln_Num V-288211 Rule_ID SV-288211r1252771_rule Severity medium Rule_Title The application must protect audit information from any type of unauthorized read access. Vuln_Discuss 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 their 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 must 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_Content Review the application documentation and deployed configuration to determine whether the application's auditing mechanism protects audit information from any type of unauthorized read access. If the application's auditing mechanism does not protect audit information from any type of unauthorized read access, this is a finding. Fix_Text Navigate to the auditing function configuration within the application. Configure the application's auditing mechanism to protect audit information from any type of unauthorized read access. Not_Reviewed Vuln_Num V-288212 Rule_ID SV-288212r1252974_rule Severity medium Rule_Title The application must protect audit information from unauthorized modification. Vuln_Discuss If audit data were to become compromised, then forensic analysis and discovery of the true source of potentially malicious system activity is 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 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_Content Review the application documentation and deployed configuration to determine whether the application's auditing mechanism protects audit information from unauthorized modification. If the application's auditing mechanism does not protect audit information from unauthorized modification, this is a finding. Fix_Text Navigate to the auditing function configuration within the application. Configure the application's auditing mechanism to protect audit information from unauthorized modification. Not_Reviewed Vuln_Num V-288213 Rule_ID SV-288213r1252933_rule Severity medium Rule_Title The application must protect audit information from unauthorized deletion. Vuln_Discuss If audit data were to become compromised, then forensic analysis and discovery of the true source of potentially malicious system activity is 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 using 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 to 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_Content Review the application documentation and deployed configuration to determine whether the application's auditing mechanism protects audit information from unauthorized deletion. If the application's auditing mechanism does not protect audit information from unauthorized deletion, this is a finding. Fix_Text Navigate to the auditing function configuration within the application. Configure the application's auditing mechanism to protect audit information from unauthorized deletion. Not_Reviewed Vuln_Num V-288214 Rule_ID SV-288214r1252934_rule Severity medium Rule_Title The application must protect audit tools from unauthorized access. Vuln_Discuss 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 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_Content Review the application documentation and deployed configuration to determine whether the application's auditing mechanism protects audit tools from unauthorized access. If the application's auditing mechanism does not protect audit tools from unauthorized access, this is a finding. Fix_Text Navigate to the auditing function configuration within the application. Configure the application's auditing mechanism to protect audit tools from unauthorized access. Not_Reviewed Vuln_Num V-288215 Rule_ID SV-288215r1252783_rule Severity medium Rule_Title The application must automatically audit account enabling actions. Vuln_Discuss Once an attacker establishes access to an application, the attacker often attempts to create a persistent method of reestablishing 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_Content Review the application documentation and deployed configuration to determine whether the application's auditing mechanism audits account enabling actions. If the application's auditing mechanism does not audit account enabling actions, this is a finding. Fix_Text Navigate to the auditing function configuration within the application. Configure the application's auditing mechanism to audit account enabling actions. Not_Reviewed Vuln_Num V-288216 Rule_ID SV-288216r1252786_rule Severity medium Rule_Title The application must record time stamps for audit records that meet a granularity of one second for a minimum degree of precision. Vuln_Discuss Without sufficient granularity of time stamps, it is not possible to adequately determine the chronological order of records. Time stamps generated by the application include date and time. Granularity of time measurements refers to the degree of synchronization between information system clocks and reference clocks. Check_Content Review the application documentation and deployed configuration to determine whether the application's auditing mechanism records time stamps for audit records that meet a granularity of one second for a minimum degree of precision. If the application's auditing mechanism does not record time stamps for audit records that meet a granularity of one second for a minimum degree of precision, this is a finding. Fix_Text Navigate to the auditing function configuration within the application. Configure the application's auditing mechanism to record time stamps for audit records that meet a granularity of one second for a minimum degree of precision. Not_Reviewed Vuln_Num V-288217 Rule_ID SV-288217r1252789_rule Severity medium Rule_Title The application must generate audit records when successful/unsuccessful attempts to access security objects occur. Vuln_Discuss Without generating audit records 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_Content Review the application documentation and deployed configuration to determine whether the application's auditing mechanism generates audit records when successful/unsuccessful attempts to access security objects occur. If the application's auditing mechanism does not generate audit records when successful/unsuccessful attempts to access security objects occur, this is a finding. Fix_Text Navigate to the auditing function configuration within the application. Configure the application's auditing mechanism to generate audit records when successful/unsuccessful attempts to access security objects occur. Not_Reviewed Vuln_Num V-288218 Rule_ID SV-288218r1252792_rule Severity medium Rule_Title The application must generate audit records when successful/unsuccessful attempts to access security levels occur. Vuln_Discuss Without generating audit records 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_Content Review the application documentation and deployed configuration to determine whether the application's auditing mechanism generates audit records when successful/unsuccessful attempts to access security levels occur. If the application's auditing mechanism does not generate audit records when successful/unsuccessful attempts to access security levels occur, this is a finding. Fix_Text Navigate to the auditing function configuration within the application. Configure the application's auditing mechanism to generate audit records when successful/unsuccessful attempts to access security levels occur. Not_Reviewed Vuln_Num V-288219 Rule_ID SV-288219r1252795_rule Severity medium Rule_Title The application must generate audit records when successful/unsuccessful attempts to access categories of information (e.g., classification levels) occur. Vuln_Discuss Without generating audit records 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_Content Review the application documentation and deployed configuration to determine whether the application's auditing mechanism generates audit records when successful/unsuccessful attempts to access categories of information (e.g., classification levels) occur. If the application's auditing mechanism does not generate audit records when successful/unsuccessful attempts to access categories of information (e.g., classification levels) occur, this is a finding. Fix_Text Navigate to the auditing function configuration within the application. Configure the application's auditing mechanism to generate audit records when successful/unsuccessful attempts to access categories of information (e.g., classification levels) occur. Not_Reviewed Vuln_Num V-288220 Rule_ID SV-288220r1252798_rule Severity medium Rule_Title The application must generate audit records when successful/unsuccessful attempts to modify privileges occur. Vuln_Discuss Without generating audit records 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_Content Review the application documentation and deployed configuration to determine whether the application's auditing mechanism generates audit records when successful/unsuccessful attempts to modify privileges occur. If the application's auditing mechanism does not generate audit records when successful/unsuccessful attempts to modify privileges occur, this is a finding. Fix_Text Navigate to the auditing function configuration within the application. Configure the application's auditing mechanism to generate audit records when successful/unsuccessful attempts to modify privileges occur. Not_Reviewed Vuln_Num V-288221 Rule_ID SV-288221r1252801_rule Severity medium Rule_Title The application must generate audit records when successful/unsuccessful attempts to modify security objects occur. Vuln_Discuss Without generating audit records 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_Content Review the application documentation and deployed configuration to determine whether the application's auditing mechanism generates audit records when successful/unsuccessful attempts to modify security objects occur. If the application's auditing mechanism does not generate audit records when successful/unsuccessful attempts to modify security objects occur, this is a finding. Fix_Text Navigate to the auditing function configuration within the application. Configure the application's auditing mechanism to generate audit records when successful/unsuccessful attempts to modify security objects occur. Not_Reviewed Vuln_Num V-288222 Rule_ID SV-288222r1252804_rule Severity medium Rule_Title The application must generate audit records when successful/unsuccessful attempts to modify security levels occur. Vuln_Discuss Without generating audit records 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_Content Review the application documentation and deployed configuration to determine whether the application's auditing mechanism generates audit records when successful/unsuccessful attempts to modify security levels occur. If the application's auditing mechanism does not generate audit records when successful/unsuccessful attempts to modify security levels occur, this is a finding. Fix_Text Navigate to the auditing function configuration within the application. Configure the application's auditing mechanism to generate audit records when successful/unsuccessful attempts to modify security levels occur. Not_Reviewed Vuln_Num V-288223 Rule_ID SV-288223r1252807_rule Severity medium Rule_Title The application must generate audit records when successful/unsuccessful attempts to modify categories of information (e.g., classification levels) occur. Vuln_Discuss Without generating audit records 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_Content Review the application documentation and deployed configuration to determine whether the application's auditing mechanism generates audit records when successful/unsuccessful attempts to modify categories of information (e.g., classification levels) occur. If the application's auditing mechanism does not generate audit records when successful/unsuccessful attempts to modify categories of information (e.g., classification levels) occur, this is a finding. Fix_Text Navigate to the auditing function configuration within the application. Configure the application's auditing mechanism to generate audit records when successful/unsuccessful attempts to modify categories of information (e.g., classification levels) occur. Not_Reviewed Vuln_Num V-288224 Rule_ID SV-288224r1252810_rule Severity medium Rule_Title The application must generate audit records when successful/unsuccessful attempts to delete privileges occur. Vuln_Discuss Without generating audit records 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_Content Review the application documentation and deployed configuration to determine whether the application's auditing mechanism generates audit records when successful/unsuccessful attempts to delete privileges occur. If the application's auditing mechanism does not generate audit records when successful/unsuccessful attempts to delete privileges occur, this is a finding. Fix_Text Navigate to the auditing function configuration within the application. Configure the application's auditing mechanism to generate audit records when successful/unsuccessful attempts to delete privileges occur. Not_Reviewed Vuln_Num V-288225 Rule_ID SV-288225r1252813_rule Severity medium Rule_Title The application must generate audit records when successful/unsuccessful attempts to delete security levels occur. Vuln_Discuss Without generating audit records 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_Content Review the application documentation and deployed configuration to determine whether the application's auditing mechanism generates audit records when successful/unsuccessful attempts to delete security levels occur. If the application's auditing mechanism does not generate audit records when successful/unsuccessful attempts to delete security levels occur, this is a finding. Fix_Text Navigate to the auditing function configuration within the application. Configure the application's auditing mechanism to generate audit records when successful/unsuccessful attempts to delete security levels occur. Not_Reviewed Vuln_Num V-288226 Rule_ID SV-288226r1252816_rule Severity medium Rule_Title The application must generate audit records when successful/unsuccessful attempts to delete security objects occur. Vuln_Discuss Without generating audit records 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_Content Review the application documentation and deployed configuration to determine whether the application's auditing mechanism generates audit records when successful/unsuccessful attempts to delete security objects occur. If the application's auditing mechanism does not generate audit records when successful/unsuccessful attempts to delete security objects occur, this is a finding. Fix_Text Navigate to the auditing function configuration within the application. Configure the application's auditing mechanism to generate audit records when successful/unsuccessful attempts to delete security objects occur. Not_Reviewed Vuln_Num V-288227 Rule_ID SV-288227r1252819_rule Severity medium Rule_Title The application must generate audit records when successful/unsuccessful attempts to delete categories of information (e.g., classification levels) occur. Vuln_Discuss Without generating audit records 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_Content Review the application documentation and deployed configuration to determine whether the application's auditing mechanism generates audit records when successful/unsuccessful attempts to delete categories of information (e.g., classification levels) occur. If the application's auditing mechanism does not generate audit records when successful/unsuccessful attempts to delete categories of information (e.g., classification levels) occur, this is a finding. Fix_Text Navigate to the auditing function configuration within the application. Configure the application's auditing mechanism to generate audit records when successful/unsuccessful attempts to delete categories of information (e.g., classification levels) occur. Not_Reviewed Vuln_Num V-288228 Rule_ID SV-288228r1252822_rule Severity medium Rule_Title The application must generate audit records when successful/unsuccessful logon attempts occur. Vuln_Discuss Without generating audit records 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_Content Review the application documentation and deployed configuration to determine whether the application's auditing mechanism generates audit records when successful/unsuccessful logon attempts occur. If the application's auditing mechanism does not generate audit records when successful/unsuccessful logon attempts occur, this is a finding. Fix_Text Navigate to the auditing function configuration within the application. Configure the application's auditing mechanism to generate audit records when successful/unsuccessful logon attempts occur. Not_Reviewed Vuln_Num V-288229 Rule_ID SV-288229r1252825_rule Severity medium Rule_Title The application must generate audit records for privileged activities or other system-level access. Vuln_Discuss Without generating audit records 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_Content Review the application documentation and deployed configuration to determine whether the application's auditing mechanism generates audit records for privileged activities or other system-level access. If the application's auditing mechanism does not generate audit records for privileged activities or other system-level access, this is a finding. Fix_Text Navigate to the auditing function configuration within the application. Configure the application's auditing mechanism to generate audit records for privileged activities or other system-level access. Not_Reviewed Vuln_Num V-288230 Rule_ID SV-288230r1252936_rule Severity medium Rule_Title The application must generate audit records showing starting and ending time for user access to the system. Vuln_Discuss Without generating audit records 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_Content Review the application documentation and deployed configuration to determine whether the application's auditing mechanism generates audit records showing starting and ending time for user access to the system. If the application's auditing mechanism does not generate audit records showing starting and ending time for user access to the system, this is a finding. Fix_Text Navigate to the auditing function configuration within the application. Configure the application's auditing mechanism to generate audit records showing start and end times for user access to the system. Not_Reviewed Vuln_Num V-288231 Rule_ID SV-288231r1252831_rule Severity medium Rule_Title The application must generate audit records when concurrent logons from different workstations occur. Vuln_Discuss Without generating audit records 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_Content Review the application documentation and deployed configuration to determine whether the application's auditing mechanism generates audit records when concurrent logons from different workstations occur. If the application's auditing mechanism does not generate audit records when concurrent logons from different workstations occur, this is a finding. Fix_Text Navigate to the auditing function configuration within the application. Configure the application's auditing mechanism to generate audit records when concurrent logons from different workstations occur. Not_Reviewed Vuln_Num V-288232 Rule_ID SV-288232r1252834_rule Severity medium Rule_Title The application must generate audit records when successful/unsuccessful accesses to objects occur. Vuln_Discuss Without generating audit records 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_Content Review the application documentation and deployed configuration to determine whether the application's auditing mechanism generates audit records when successful/unsuccessful accesses to objects occur. If the application's auditing mechanism does not generate audit records when successful/unsuccessful accesses to objects occur, this is a finding. Fix_Text Navigate to the auditing function configuration within the application. Configure the application's auditing mechanism to generate audit records when successful/unsuccessful accesses to objects occur. Not_Reviewed Vuln_Num V-288233 Rule_ID SV-288233r1252837_rule Severity medium Rule_Title The application must generate audit records for all direct access to the information system. Vuln_Discuss Without generating audit records 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_Content Review the application documentation and deployed configuration to determine whether the application's auditing mechanism generates audit records for all direct access to the information system. If the application's auditing mechanism does not generate audit records for all direct access to the information system, this is a finding. Fix_Text Navigate to the auditing function configuration within the application. Configure the application's auditing mechanism to generate audit records for all direct access to the information system. Not_Reviewed Vuln_Num V-288234 Rule_ID SV-288234r1252840_rule Severity medium Rule_Title The application must generate audit records for all account creations, modifications, disabling, and termination events. Vuln_Discuss Without generating audit records 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_Content Review the application documentation and deployed configuration to determine whether the application's auditing mechanism generates audit records for all account creations, modifications, disabling, and termination events. If the application's auditing mechanism does not generate audit records for all account creations, modifications, disabling, and termination events, this is a finding. Fix_Text Navigate to the auditing function configuration within the application. Configure the application's auditing mechanism to generate audit records for all account creations, modifications, disabling, and termination events. Not_Reviewed Vuln_Num V-288235 Rule_ID SV-288235r1252843_rule Severity medium Rule_Title The application must generate audit records for all load, unload, and restart events, and also for all program initiations. Vuln_Discuss Without generating audit records 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_Content Review the application documentation and deployed configuration to determine whether the application's auditing mechanism generates audit records for all module load, unload, and restart events and, also for all program initiations. If the application's auditing mechanism does not generate audit records for all module load, unload, and restart events and, also for all program initiations, this is a finding. Fix_Text Navigate to the auditing function configuration within the application. Configure the application's auditing mechanism to generate audit records for all module load, unload, and restart events and, also for all program initiations. Not_Reviewed Vuln_Num V-288236 Rule_ID SV-288236r1252938_rule Severity medium Rule_Title When baseline configurations are changed in an unauthorized manner the application must alert the information system security officer (ISSO)/information system security manager (ISSM), and rollback the unauthorized change. Vuln_Discuss Unauthorized changes to the baseline configuration could make the system vulnerable to various attacks or allow unauthorized access to the system. Changes to information system configurations can have unintended side effects, some of which may be relevant to security. Detecting such changes and providing an automated response can help avoid unintended, negative consequences that could ultimately affect the security state of the application. Examples of security responses include, but are not limited to the following: halting application processing; halting selected application functions; or issuing alerts/notifications to organizational personnel when there is an unauthorized modification of a configuration item. This requirement pertains to Configuration Management and Infrastructure as Code (IaC) types of applications, and can otherwise be considered Not Applicable. Check_Content Review the application documentation and deployed configuration to determine whether the application's alerting mechanism notifies the ISSO/ISSM, and rolls back the unauthorized change, when baseline configurations are changed in an unauthorized manner. If the application's alerting mechanism does not notify the ISSO/ISSM, and rolls back the unauthorized change, when baseline configurations are changed in an unauthorized manner, this is a finding. Fix_Text Navigate to the alerting function configuration within the application. Configure the application's alerting mechanism to notify the ISSO/ISSM and undo the unauthorized change when baseline configurations are changed in an unauthorized manner. Not_Reviewed Vuln_Num V-288237 Rule_ID SV-288237r1252487_rule Severity medium Rule_Title Applications performing maintenance functions must restrict use of these functions to authorized personnel only. Vuln_Discuss Security-related issues can arise from software brought into the information system specifically for diagnostic and repair actions (e.g., a software packet sniffer installed on a system to troubleshoot system traffic, or a vendor installing or running a diagnostic application to troubleshoot an issue with a vendor-supported system). If maintenance tools are used by unauthorized personnel, they may accidentally or intentionally damage or compromise the system. This requirement addresses security-related issues associated with maintenance tools used specifically for diagnostic and repair actions on organizational information systems. Maintenance tools can include hardware, software, and firmware items. Maintenance tools are potential vehicles for transporting malicious code, either intentionally or unintentionally, into a facility and subsequently into organizational information systems. Maintenance tools can include, for example, hardware/software diagnostic test equipment and hardware/software packet sniffers. 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_Content If the application is not a maintenance application, this requirement is Not Applicable. Review the maintenance application documentation and deployed configuration to determine whether performance of maintenance functions is restricted to authorized personnel only. If the maintenance application does not restrict maintenance functions to authorized personnel only, this is a finding. Fix_Text Configure the maintenance application to restrict the performance of maintenance functions to authorized personnel only. Not_Reviewed Vuln_Num V-288238 Rule_ID SV-288238r1252299_rule Severity medium Rule_Title Applications used for nonlocal maintenance sessions must audit organization-defined audit events for nonlocal maintenance and diagnostic sessions. Vuln_Discuss If events associated with nonlocal administrative access or diagnostic sessions are not logged and audited, a major tool for assessing and investigating attacks would not be available. This requirement addresses auditing-related issues associated with maintenance tools used specifically for diagnostic and repair actions on organizational information systems. 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_Content If the application is not a maintenance application, this requirement is Not Applicable. Review the application's documentation and deployed configuration to determine whether the auditing mechanism generates organization-defined audit records for nonlocal maintenance and diagnostic sessions. If the application's auditing mechanism does not generate audit records for nonlocal maintenance and diagnostic session organization-defined audit events, this is a finding. Fix_Text Navigate to the auditing function configuration within the application. Configure the application's auditing mechanism to generate organization-defined audit records for nonlocal maintenance and diagnostic sessions. Not_Reviewed Vuln_Num V-288239 Rule_ID SV-288239r1252941_rule Severity medium Rule_Title Applications used for nonlocal maintenance sessions must protect nonlocal maintenance sessions by separating the maintenance session from other network sessions by either physically separated communications paths or logically separated communications paths based upon encryption. Vuln_Discuss Privileged access contains control and configuration information that must not be mixed with normal operational or user traffic, so additional protections are necessary. This is maintained by using separate, dedicated management interfaces and networks with additional protections or by using encryption. Nonlocal 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. 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). The application can meet this requirement through leveraging a cryptographic module. Check_Content If the application is not a maintenance application, this requirement is Not Applicable. Review the maintenance application documentation and deployed configuration to determine whether the nonlocal maintenance sessions are protected by separating the maintenance session from other network sessions by either physically separated communications paths or logically separated communications paths based upon encryption. If the maintenance application does not protect nonlocal maintenance sessions by separating the maintenance session from other network sessions by either physically separated communications paths or logically separated communications paths based upon encryption, this is a finding. Fix_Text Configure the maintenance application to protect nonlocal maintenance sessions by separating the maintenance session from other network sessions by either physically separated communications paths or logically separated communications paths based upon encryption. Not_Reviewed Vuln_Num V-288240 Rule_ID SV-288240r1252944_rule Severity medium Rule_Title Applications 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. Vuln_Discuss Unapproved mechanisms used for authentication to the cryptographic module are not verified; therefore, cannot be relied on to provide confidentiality or integrity, and DoW 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-3-validated will have an HMAC that meets specification; however, the option must be configured for use as the only message authentication code used to authenticate 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_Content If the application is not a maintenance application, this requirement is Not Applicable. If the maintenance application does not use FIPS-validated keyed HMAC to protect the integrity of nonlocal maintenance and diagnostic communications, this is a finding. Fix_Text Configure the maintenance application to use FIPS-validated keyed HMAC to protect the integrity of nonlocal maintenance and diagnostic communications. Not_Reviewed Vuln_Num V-288241 Rule_ID SV-288241r1252308_rule Severity medium Rule_Title Applications used for nonlocal maintenance sessions must verify remote disconnection at the termination of nonlocal maintenance and diagnostic sessions. Vuln_Discuss If the remote connection is not closed and verified as closed, the session may remain open and be exploited by an attacker; this is referred to as a zombie session. Remote connections must be disconnected and verified as disconnected when nonlocal maintenance sessions have been terminated and are no longer available for use. Check_Content If the application is not a maintenance application, this requirement is Not Applicable. Review the maintenance application documentation and deployed configuration to determine whether remote session disconnection occurs at the termination of nonlocal maintenance and diagnostic sessions. If the maintenance application does not, upon the termination of nonlocal maintenance and diagnostic sessions, remotely disconnect the session, this is a finding. Fix_Text Configure the maintenance application to remotely disconnect the session upon the termination of nonlocal maintenance and diagnostic sessions. Not_Reviewed Vuln_Num V-288242 Rule_ID SV-288242r1252848_rule Severity medium Rule_Title The application must retain the Standard Mandatory DoW Notice and Consent Banner on the screen until users acknowledge the usage conditions and take explicit actions to log on for further access. Vuln_Discuss The banner must be acknowledged by the user prior to allowing the user access to the application. 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, DoW 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_Content Navigate to the logon banner configuration function within the application. Verify the application retains the Standard Mandatory DoW Notice and Consent Banner on the screen until users acknowledge the usage conditions and take explicit actions to log on for further access. Otherwise, this is a finding. Fix_Text Navigate to the logon banner configuration function within the application. Configure the application to retain the Standard Mandatory DoW Notice and Consent Banner on the screen until users acknowledge the usage conditions and take explicit actions to log on for further access. Not_Reviewed Vuln_Num V-288243 Rule_ID SV-288243r1252491_rule Severity medium Rule_Title The publicly accessible application must display the Standard Mandatory DoW Notice and Consent Banner before granting access to the application. Vuln_Discuss Display of a standardized and approved use notification before granting access to the publicly accessible application ensures privacy and security notification verbiage used is consistent with applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance. System use notifications are required only for access via logon interfaces with human users and are not required when such human interfaces do not exist. The banner must be formatted in accordance with DTM-08-060. Use the following verbiage for desktops, laptops, and other devices accommodating banners of 1300 characters: "You are accessing a U.S. Government (USG) Information System (IS) that is provided for USG-authorized use only. By using this IS (which includes any device attached to this IS), you consent to the following conditions: -The USG routinely intercepts and monitors communications on this IS for purposes including, but not limited to, penetration testing, COMSEC monitoring, network operations and defense, personnel misconduct (PM), law enforcement (LE), and counterintelligence (CI) investigations. -At any time, the USG may inspect and seize data stored on this IS. -Communications using, or data stored on, this IS are not private, are subject to routine monitoring, interception, and search, and may be disclosed or used for any USG-authorized purpose. -This IS includes security measures (e.g., authentication and access controls) to protect USG interests--not for your personal benefit or privacy. -Notwithstanding the above, using this IS does not constitute consent to PM, LE or CI investigative searching or monitoring of the content of privileged communications, or work product, related to personal representation or services by attorneys, psychotherapists, or clergy, and their assistants. Such communications and work product are private and confidential. See User Agreement for details." Use the following verbiage for operating systems that have severe limitations on the number of characters that can be displayed in the banner: "I've read & consent to terms in IS user agreem't." Check_Content Navigate to the logon banner configuration function within the publicly accessible application. Verify the publicly accessible application retains the Standard Mandatory DoW Notice and Consent Banner on the screen until users acknowledge the usage conditions and take explicit actions to log on for further access. Otherwise, this is a finding. Fix_Text Navigate to the logon banner configuration function within the publicly accessible application. Configure the publicly accessible application to retain the Standard Mandatory DoW Notice and Consent Banner on the screen until users acknowledge the usage conditions and take explicit actions to log on for further access. Not_Reviewed Vuln_Num V-288244 Rule_ID SV-288244r1252851_rule Severity high Rule_Title The application must off-load audit records onto a central logging system at least every seven days. Vuln_Discuss DoW mandates the centralization of event logging to allow security personnel to rapidly visualize data from many sources to spot trends and complex attacks on enterprise assets. The Central Log Server Security Requirements Guide (SRG) supports this goal by providing the technical security policies, requirements, and implementation details for applying security concepts to Security Information and Event Management servers (SIEMs), syslog servers, Network Management Systems (NMSs), and other event-based aggregation and monitoring applications that are part of the events logging, notification, monitoring, and analysis functions in the enterprise. The scope of this document includes applications that leverage aggregated audit logs collected from firewalls, routers, servers, applications, and databases to visualize, monitor, notify, and alert based on identified thresholds. Log management includes log collection/aggregation, secure storage, normalization, event analysis, reporting, and notification/alert generation. Current DoW requirements state that the organization must store the primary log records on a log server (e.g., syslog, SIEM, events server) on a different host than the operating system host being audited. This requirement helps ensure that a compromise of the information system being audited does not also result in a compromise of the audit records. DoW also requires centralized management and configuration of the content to be captured in audit records generated by devices and hosts in the enterprise. Thus, there is a requirement for a central log management, analysis, and reporting function that allows management and configuration of log (events) records. Check_Content Review the application documentation and deployed configuration to determine whether the application's auditing mechanism off-loads audit records onto a central logging system at least every seven days. If the application's auditing mechanism does not off-load audit records onto a central logging system at least every seven days, this is a finding. Fix_Text Navigate to the auditing function configuration within the application. Configure the application's auditing mechanism to off-load audit records onto a central logging system at least every seven days. Not_Reviewed Vuln_Num V-288245 Rule_ID SV-288245r1252945_rule Severity high Rule_Title The application must use FIPS-validated cryptographic algorithms defined in CNSSP 15 Annex B to generate cryptographic hashes. Vuln_Discuss CNSSP 15 specifies the use of public standards for cryptographic protocol and algorithm interoperability to protect National Security Systems (NSS). Based on National Security Memorandum (NSM)-10 and the threat of quantum computing on traditional public key cryptography, NSS must begin to transition to new algorithms for several cryptographic services that are the bedrock for cybersecurity assurances. The policy updates the set of authorized algorithms to provide quantum resistance, removing those that do not provide adequate security in a post-quantum ecosystem and replacing them with other standardized, widely available algorithms to ensure a strong cybersecurity posture into the future. CNSSP 15 Annex B contains a table of NIST cryptographic algorithms approved by NSA to protect NSS. This requirement pertains to Zero Trust. Check_Content Review the application documentation and deployed configuration to determine whether the application's cryptography mechanism uses FIPS-validated cryptographic algorithms defined in CNSSP 15 Annex B to generate cryptographic hashes. If the application's cryptography mechanism does not use FIPS-validated cryptographic algorithms defined in CNSSP 15 Annex B to generate cryptographic hashes, this is a finding. Fix_Text Navigate to the cryptography configuration within the application. Configure the application's cryptography mechanism to use FIPS-validated cryptographic algorithms defined in CNSSP 15 Annex B to generate cryptographic hashes. Not_Reviewed Vuln_Num V-288246 Rule_ID SV-288246r1252946_rule Severity high Rule_Title The application must use Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) cryptographic algorithms. Vuln_Discuss Use of improperly configured or lower-assurance equipment and solutions could compromise high-value information. CNSA 2.0 is the NSA's next-generation cybersecurity standard designed to protect National Security Systems (NSS) from the impending threat of quantum computing. It phases out vulnerable legacy algorithms (like RSA and ECC) in favor of quantum-resistant post-quantum cryptography (PQC) selected from NIST standards. This requirement pertains to Zero Trust. Check_Content Review the application documentation and deployed configuration to determine whether the application's cryptography mechanism uses CNSA 2.0 cryptographic algorithms. If the application's cryptography mechanism does not use CNSA 2.0 cryptographic algorithms, this is a finding. Fix_Text Navigate to the cryptography configuration within the application. Configure the application's cryptography mechanism to use CNSA 2.0 cryptographic algorithms. Not_Reviewed Vuln_Num V-288247 Rule_ID SV-288247r1252860_rule Severity high Rule_Title The application must use FIPS-validated SHA-2 or higher hash function for digital signature generation and verification. Vuln_Discuss Without cryptographic integrity protections, information can be altered by unauthorized users without detection. To protect the integrity of the authenticator and authentication mechanism used for the cryptographic module used by the network device, the application, operating system, or protocol must be configured to use one of the following hash functions for hashing the password or other authenticator in accordance with SP 800-131Ar1: SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, SHA-512/256, SHA3-224, SHA3-256, SHA3-384, and SHA3-512. For digital signature verification, SP800-131Ar1 allows SHA-1 for legacy use where needed. Check_Content Review the application documentation and deployed configuration to determine whether the application's cryptography mechanism uses FIPS-validated SHA-2 or higher hash function for digital signature generation and verification. If the application's cryptography mechanism does not use FIPS-validated SHA-2 or higher hash function for digital signature generation and verification, this is a finding. Fix_Text Navigate to the cryptography configuration within the application. Configure the application's cryptography mechanism to use FIPS-validated SHA-2 or higher hash function for digital signature generation and verification. Not_Reviewed Vuln_Num V-288248 Rule_ID SV-288248r1252947_rule Severity high Rule_Title The application must use a FIPS-validated cryptographic module to provision digital signatures. Vuln_Discuss FIPS 140-3 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-3 is applicable. 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-3 standard. Provisioning of digital signatures pertains to certificate authority or Public Key Infrastructure (PKI)-type applications that generate certificates (e.g., OpenSSL, code signing applications, etc.); otherwise, this requirement is considered Not Applicable. The cryptographic module used must have at least one validated digital signature function. This validated hash algorithm must be used to generate digital signatures for all cryptographic security function within the product being evaluated. This requirement pertains to Zero Trust. Check_Content Review the application documentation and deployed configuration to determine whether the application's cryptography mechanism uses a FIPS-validated cryptographic module to provision digital signatures. If the application's cryptography mechanism does not use a FIPS-validated cryptographic module to provision digital signatures, this is a finding. Fix_Text Navigate to the cryptography configuration within the application. Configure the application's cryptography mechanism to use a FIPS-validated cryptographic module to provision digital signatures. Not_Reviewed Vuln_Num V-288249 Rule_ID SV-288249r1252866_rule Severity high Rule_Title The application must implement cryptographic mechanisms to prevent unauthorized modification of information at rest. Vuln_Discuss Applications handling data requiring data-at-rest protections must employ cryptographic mechanisms to prevent unauthorized disclosure and modification of the information at rest. Selection of a cryptographic mechanism is based on the need to protect the integrity of organizational information. The strength of the mechanism is commensurate with the security category and/or classification of the information. Organizations have the flexibility to either encrypt all information on storage devices (i.e., full disk encryption) or encrypt specific data structures (e.g., files, records, or fields). Check_Content Review the application documentation and deployed configuration to determine whether the application's cryptography mechanism prevents unauthorized modification of information at rest. If the application's cryptography mechanism does not prevent unauthorized modification of information at rest, this is a finding. Fix_Text Navigate to the cryptography configuration within the application. Configure the application's cryptography mechanism to prevent unauthorized modification of information at rest. Not_Reviewed Vuln_Num V-288250 Rule_ID SV-288250r1252948_rule Severity medium Rule_Title The application must use FIPS-validated cryptographic algorithms defined in CNSSP 15 Annex B to protect the integrity and confidentiality of remote access sessions. Vuln_Discuss Without confidentiality protection mechanisms, unauthorized individuals may gain access to sensitive information via a remote access session. Remote access is access to DoW nonpublic information systems by an authorized user (or an information system) communicating through an external, nonorganization-controlled network. A block cipher mode is an algorithm that features the use of a symmetric key block cipher algorithm to provide an information service, such as confidentiality or authentication. AES is the FIPS-validated cipher block cryptographic algorithm approved for use in DoW. For an algorithm implementation to be listed on a FIPS 140-3 cryptographic module validation certificate as an approved security function, the algorithm implementation must meet all the requirements of FIPS 140-3 and must successfully complete the cryptographic algorithm validation process. Currently, NIST has approved the following confidentiality modes to be used with approved block ciphers in a series of special publications: ECB, CBC, OFB, CFB, CTR, XTS-AES, FF1, FF3, CCM, GCM, KW, KWP, and TKW. This requirement pertains to Zero Trust. Check_Content Review the application documentation and deployed configuration to determine whether the application's cryptography mechanism uses FIPS-validated cryptographic algorithms defined in CNSSP 15 Annex B to protect the integrity and confidentiality of remote access sessions. If the application's cryptography mechanism does not use FIPS-validated cryptographic algorithms defined in CNSSP 15 Annex B to protect the integrity and confidentiality of remote access sessions, this is a finding. Fix_Text Navigate to the cryptography configuration within the application. Configure the application's cryptography mechanism to use FIPS-validated cryptographic algorithms defined in CNSSP 15 Annex B to protect the integrity and confidentiality of remote access sessions. Not_Reviewed Vuln_Num V-288251 Rule_ID SV-288251r1252949_rule Severity medium Rule_Title The application must monitor remote access methods. Vuln_Discuss Remote access applications, such as those providing remote access to network devices and information systems which lack automated capabilities, increase risk and makes remote user access management difficult, at best. Remote access is access to DoW nonpublic information systems by an authorized user (or an information system) communicating through an external, nonorganization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless. Automated monitoring of remote access sessions allows organizations to detect cyberattacks and also ensure ongoing compliance with remote access policies by auditing connection activities of remote access applications, such as VPN clients on a variety of information system components (e.g., servers, workstations, notebook computers, smart phones, and tablets). Check_Content Review the application documentation and deployed configuration to determine whether the application's remote access mechanism monitors remote access methods. If the application's remote access mechanism does not monitor remote access methods, this is a finding. Fix_Text Navigate to the remote access configuration within the application. Configure the application's remote access mechanism to monitor remote access methods. Not_Reviewed Vuln_Num V-288252 Rule_ID SV-288252r1252950_rule Severity medium Rule_Title The application must control remote access methods. Vuln_Discuss Remote access applications, such as those providing remote access to network devices and information systems which lack automated capabilities, increase risk and makes remote user access management difficult, at best. Remote access is access to DoW nonpublic information systems by an authorized user (or an information system) communicating through an external, nonorganization-controlled network. Remote access methods include, for example, dial-up, broadband, and wireless. Remote access applications must be capable of taking enforcement action if the audit reveals unauthorized activity. Automated control of remote access sessions allows organizations to ensure ongoing compliance with remote access policies by enforcing connection rules of remote access applications on a variety of information system components (e.g., servers, workstations, notebook computers, smart phones, and tablets). Check_Content Review the application documentation and deployed configuration to determine whether the application's remote access mechanism controls remote access methods. If the application's remote access mechanism does not control remote access methods, this is a finding. Fix_Text Navigate to the remote access configuration within the application. Configure the application's remote access mechanism to control remote access methods. Not_Reviewed Vuln_Num V-288253 Rule_ID SV-288253r1252951_rule Severity high Rule_Title The application must use TLS 1.2 or greater to protect the confidentiality and integrity of all remote access sessions. Vuln_Discuss Using older unauthorized versions or incorrectly configuring protocol negotiation makes the gateway vulnerable to known and unknown attacks that exploit vulnerabilities in this protocol. This requirement applies to Transport Layer Security (TLS) gateways (also known as Secure Sockets Layer [SSL] gateways), web servers, and web applications and is not applicable to VPN devices. Application protocols such as HTTPS and DNSSEC use TLS as the underlying security protocol and thus are in scope for this requirement. NIST SP 800-52 provides guidance for client negotiation on either DoW-only or public-facing servers. Check_Content Review the application documentation and deployed configuration to determine whether the application's remote access mechanism uses TLS 1.2 or greater to protect the confidentiality and integrity of all remote access sessions. If the application's remote access mechanism does not use TLS 1.2 or greater to protect the confidentiality and integrity of all remote access sessions, this is a finding. Fix_Text Navigate to the remote access configuration within the application. Configure the application's remote access mechanism to use TLS 1.2 or greater to protect the confidentiality and integrity of all remote access sessions. Not_Reviewed Vuln_Num V-288254 Rule_ID SV-288254r1252952_rule Severity high Rule_Title The application must use FIPS-validated cryptographic algorithms defined in Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) to protect the confidentiality and integrity of transmitted information. Vuln_Discuss 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 are either distributed or that can allow access to data nonlocally. 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 Transport Layer Security (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_Content Review the application documentation and deployed configuration to determine whether the application's cryptography mechanism uses FIPS-validated cryptographic algorithms defined in CNSA 2.0 to protect the confidentiality and integrity of transmitted information. If the application's cryptography mechanism does not use FIPS-validated cryptographic algorithms defined in CNSA 2.0 to protect the confidentiality and integrity of transmitted information, this is a finding. Fix_Text Navigate to the cryptography configuration within the application. Configure the application's cryptography mechanism to use FIPS-validated cryptographic algorithms defined in CNSA 2.0 to protect the confidentiality and integrity of transmitted information. Not_Reviewed Vuln_Num V-288255 Rule_ID SV-288255r1253077_rule Severity high Rule_Title The application must use FIPS-validated cryptographic algorithms defined in CNSA 2.0 to protect the integrity and confidentiality of nonlocal maintenance and diagnostic communications. Vuln_Discuss 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 are either distributed or can allow access to data nonlocally. 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_Content Review the application documentation and deployed configuration to determine whether the application's cryptography mechanism uses FIPS-validated cryptographic algorithms defined in CNSA 2.0 to protect the integrity and confidentiality of nonlocal maintenance and diagnostic communications. If the application's cryptography mechanism does not use FIPS-validated cryptographic algorithms defined in CNSA 2.0 to protect the integrity and confidentiality of nonlocal maintenance and diagnostic communications, this is a finding. Fix_Text Navigate to the cryptography configuration within the application. Configure the application's cryptography mechanism to use FIPS-validated cryptographic algorithms defined in CNSA 2.0 to protect the integrity and confidentiality of nonlocal maintenance and diagnostic communications. Not_Reviewed Vuln_Num V-288256 Rule_ID SV-288256r1252887_rule Severity high Rule_Title The application must prohibit client negotiation to TLS 1.1, TLS 1.0, SSL 2.0, or SSL 3.0. Vuln_Discuss Using older unauthorized versions or incorrectly configuring protocol negotiation makes the gateway vulnerable to known and unknown attacks that exploit vulnerabilities in this protocol. This requirement applies to Transport Layer Security (TLS) gateways (also known as Secure Sockets Layer [SSL] gateways), web servers, and web applications. Application protocols such as HTTPS and DNSSEC use TLS as the underlying security protocol and thus are in scope for this requirement. NIST SP 800-52 provides guidance for client negotiation, either on DoW-only or on public-facing servers. Check_Content Review the application documentation and deployed configuration to determine whether the application's cryptography mechanism prohibits client negotiation to TLS 1.1, TLS 1.0, SSL 2.0, or SSL 3.0. If the application's cryptography mechanism does not prohibit client negotiation to TLS 1.1, TLS 1.0, SSL 2.0, or SSL 3.0, this is a finding. Fix_Text Navigate to the cryptography configuration within the application. Configure the application's cryptography mechanism to prohibit client negotiation to TLS 1.1, TLS 1.0, SSL 2.0, or SSL 3.0. Not_Reviewed Vuln_Num V-288257 Rule_ID SV-288257r1252890_rule Severity medium Rule_Title The application must use FIPS-validated cryptographic algorithms defined in CNSSP 15 Annex B for authentication to a cryptographic module. Vuln_Discuss A software-based cryptographic module is a program or library that performs cryptographic operations—such as encryption, decryption, hashing, and key generation—entirely in software on a general-purpose processor. It operates within a defined "cryptographic boundary" separating the security functions from the rest of the operating system. To protect the integrity of the authenticator and authentication mechanism used for the cryptographic module used by the network device, the application, operating system, or protocol must be configured to use one of the following hash functions for hashing the password or other authenticator in accordance with SP 800-131Ar1: SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224, SHA-512/256, SHA3-224, SHA3-256, SHA3-384, and SHA3-512. Applications also include HMAC, KDFs, Random Bit Generation, and hash-only applications (e.g., hashing passwords and computing checksums). Separate requirements for configuring applications and protocols used by each product (e.g., SNMPv3, SSH, NTP, and other protocols and applications that require server/client authentication) are required to implement this requirement. Check_Content Review the application documentation and deployed configuration to determine whether the application's cryptography mechanism uses FIPS-validated cryptographic algorithms defined in CNSSP 15 Annex B for authentication to a cryptographic module. If the application's cryptography mechanism does not use FIPS-validated cryptographic algorithms defined in CNSSP 15 Annex B for authentication to a cryptographic module, this is a finding. Fix_Text Navigate to the cryptography configuration within the application. Configure the application's cryptography mechanism to use FIPS-validated cryptographic algorithms defined in CNSSP 15 Annex B for authentication to a cryptographic module. Not_Reviewed Vuln_Num V-288258 Rule_ID SV-288258r1252892_rule Severity medium Rule_Title The application must validate certificates used for Transport Layer Security (TLS) functions by performing RFC 5280-compliant certification path validation. Vuln_Discuss A certificate's 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. 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. Check_Content Review the application documentation and deployed configuration to determine whether the application validates certificates used for TLS functions by performing RFC 5280-compliant certification path validation. OSCP is used to accomplish this. If the application does not validate certificates used for TLS functions by performing RFC 5280-compliant certification path validation, this is a finding. Fix_Text Configure the application to validate certificates used for TLS functions by performing RFC 5280-compliant certification path validation. Not_Reviewed Vuln_Num V-288259 Rule_ID SV-288259r1252954_rule Severity medium Rule_Title The application, 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. Vuln_Discuss Without configuring a local cache of revocation data, there is the potential to allow access to users who are no longer authorized (users with revoked certificates). Online certificate status protocol (OCSP) is preferred over certificate revocation lists (CRLs). If OCSP is used, this requirement is not applicable. Check_Content CRL must only be used as a fallback if an OSCP function is not available. Review the application documentation and deployed configuration to determine whether the application, for PKI-based authentication, implements a local cache of revocation data to support path discovery and validation in case of the inability to access revocation information via the network. If the application does not, for PKI-based authentication, 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, this is a finding. Fix_Text For PKI-based authentication without OSCP, configure the application 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. Not_Reviewed Vuln_Num V-288260 Rule_ID SV-288260r1252975_rule Severity medium Rule_Title The application must, for public key-based authentication, implement a local cache of revocation data to support path discovery and validation. Vuln_Discuss Public key cryptography is a valid authentication mechanism for individuals, machines, and devices. For Public Key Infrastructure (PKI) solutions, status information for certification paths includes certificate revocation lists or certificate status protocol responses. For personal identity verification (PIV) cards, certificate validation involves the construction and verification of a certification path to the Common Policy Root trust anchor, which includes certificate policy processing. Implementing a local cache of revocation data to support path discovery and validation also supports system availability in situations where organizations are unable to access revocation information via the network. Online certificate status protocol (OCSP) is preferred over certificate revocation lists (CRLs). If OCSP is used this requirement is not applicable. Check_Content CRL must only be used as a fallback if an OSCP function is not available. Review the application documentation and deployed configuration to determine whether the application, for public key-based authentication, implements a local cache of revocation data to support path discovery and validation. If the application does not, for public key-based authentication, implement a local cache of revocation data to support path discovery and validation, this is a finding. Fix_Text For public key-based authentication without OSCP, configure the application to implement a local cache of revocation data to support path discovery and validation. Not_Reviewed Vuln_Num V-288261 Rule_ID SV-288261r1252368_rule Severity medium Rule_Title The application must include only approved trust anchors in trust stores or certificate stores managed by the organization. Vuln_Discuss 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. Online certificate status protocol (OCSP) is preferred over certificate revocation lists (CRLs). If OCSP is used this requirement is not applicable. Check_Content CRL must only be used as a fallback if an OSCP function is not available. Review the application documentation and deployed configuration to determine whether the application includes only approved trust anchors in trust stores or certificate stores managed by the organization. If the application does not include only approved trust anchors in trust stores or certificate stores managed by the organization, this is a finding. Fix_Text Configure the application to include only approved trust anchors in trust stores or certificate stores managed by the organization. Not_Reviewed Vuln_Num V-288262 Rule_ID SV-288262r1252957_rule Severity medium Rule_Title The application must enforce a role-based access control (RBAC) policy over defined subjects and objects. Vuln_Discuss RBAC is an access control policy that restricts information system access to authorized users. Without these security policies, access control and enforcement mechanisms will not prevent unauthorized access. Organizations can create specific roles based on job functions and the authorizations (i.e., privileges) to perform needed operations on organizational information systems associated with the organization-defined roles. When users are assigned to the organizational roles, they inherit the authorizations or privileges defined for those roles. RBAC simplifies privilege administration for organizations because privileges are not assigned directly to every user (which can be a significant number of individuals for mid- to large-size organizations) but are instead acquired through role assignments. RBAC can be implemented either as a mandatory or discretionary form of access control. This requirement pertains to Zero Trust. Check_Content Navigate to the user/role configuration function within the application. The role-based hierarchical structure must be defined by the authorizing official (AO) (or otherwise appointed personnel). 1. Verify at least two roles exist in the structure. 2.Verify at least one user is assigned to each role. Otherwise, this is a finding. Fix_Text Navigate to the user/role configuration function within the application. The role-based hierarchical structure must be defined by the AO (or otherwise appointed personnel). 1. Create at least two roles in the structure. 2. Assign at least one user to each role. Not_Reviewed Vuln_Num V-288263 Rule_ID SV-288263r1252958_rule Severity medium Rule_Title The application must separate user functionality (including user interface services) from information system management functionality. Vuln_Discuss Application management functionality includes functions necessary for administration and requires privileged user access. Allowing nonprivileged users to access application management functionality capabilities increases the risk that nonprivileged users may obtain elevated privileges. The separation of user functionality from information system management functionality is either physical or logical and is accomplished by using different computers, different central processing units, different instances of the operating system, different network addresses, different TCP/UDP ports, virtualization techniques, combinations of these methods, or other methods, as appropriate. An example of this type of separation is observed in web administrative interfaces that use separate authentication methods for users of any other information system resources. This may include isolating the administrative interface on a different security domain and with additional access controls. This requirement pertains to Zero Trust. Check_Content Review the application documentation and deployed configuration to determine whether user functionality (including user interface services) is separated from information system management functionality. If the application's user functionality (including user interface services) is not separated from information system management functionality, this is a finding. Fix_Text Navigate to the cryptography configuration within the application. Configure the application to separate user functionality (including user interface services) from information system management functionality. Not_Reviewed Vuln_Num V-288264 Rule_ID SV-288264r1252959_rule Severity medium Rule_Title The application must dynamically associate security attributes with organization-defined subjects in accordance with organization-defined security policies as information is created and combined. Vuln_Discuss If the application does not dynamically reconfigure the data security attributes as data is created and combined, there is the possibility that the security attributes will not correctly reflect the data with which they are associated. Security attributes are abstractions representing the basic properties or characteristics of an entity (e.g., subjects and objects) with respect to safeguarding information. These attributes are typically associated with internal data structures (e.g., data records, buffers, files) within the application and are used to enable the implementation of access control and flow control policies, reflect special dissemination, handling, or distribution instructions, or support other aspects of the information security policy. Organizations define the security attributes of their data (e.g., classified, CUI). When data is created and/or combined, data security attributes defined by organizational policy must be dynamically created and/or updated to reflect the potential change in data sensitivity and characteristics. Dynamic association of security attributes is appropriate whenever the security characteristics of information changes over time. Security attributes may change, for example, due to information aggregation issues (i.e., the security characteristics of individual information elements are different from the combined elements), changes in individual access authorizations (i.e., privileges), and changes in the security category of information. This requirement pertains to Zero Trust. Check_Content Review the application documentation and deployed configuration to determine whether the application dynamically associates security attributes with organization-defined subjects in accordance with organization-defined security policies as information is created and combined. If the application does not dynamically associate security attributes with organization-defined subjects in accordance with organization-defined security policies as information is created and combined, this is a finding. Fix_Text Configure the application to dynamically associate security attributes with organization-defined subjects in accordance with organization-defined security policies as information is created and combined. Not_Reviewed Vuln_Num V-288265 Rule_ID SV-288265r1252960_rule Severity medium Rule_Title The application must enforce approved authorizations for controlling the flow of information within the system based on organization-defined information flow control policies. Vuln_Discuss A mechanism to detect and prevent unauthorized communication flow must be configured or provided as part of the system design. If information flow is not enforced based on approved authorizations, the system may become compromised. Information flow control regulates where information is allowed to travel within a system and between interconnected systems. The flow of all system information must be monitored and controlled so it does not introduce any unacceptable risk to the systems or data. Application-specific examples of enforcement occur in systems that employ rule sets or establish configuration settings that restrict information system services, or message-filtering capability based on message content (e.g., implementing key word searches or using document characteristics). Applications providing information flow control must be able to enforce approved authorizations for controlling the flow of information within the system in accordance with applicable policy. This requirement pertains to Zero Trust. Check_Content Review the application documentation and deployed configuration to determine whether the application enforces approved authorizations for controlling the flow of information within the system based on organization-defined information flow control policies. If the application does not enforce approved authorizations for controlling the flow of information within the system based on organization-defined information flow control policies, this is a finding. Fix_Text Configure the application to enforce approved authorizations for controlling the flow of information within the system based on organization-defined information flow control policies. Not_Reviewed Vuln_Num V-288266 Rule_ID SV-288266r1252961_rule Severity medium Rule_Title The application must enforce approved authorizations for controlling the flow of information between interconnected systems based on organization-defined information flow control policies. Vuln_Discuss A mechanism to detect and prevent unauthorized communication flow must be configured or provided as part of the system design. If information flow is not enforced based on approved authorizations, the system may become compromised. Information flow control regulates where information is allowed to travel within a system and between interconnected systems. The flow of all application information must be monitored and controlled so it does not introduce any unacceptable risk to the systems or data. Application-specific examples of enforcement occur in systems that employ rule sets or establish configuration settings that restrict information system services, or provide a message filtering capability based on message content (e.g., implementing key word searches or using document characteristics). Applications providing information flow control must be able to enforce approved authorizations for controlling the flow of information between interconnected systems in accordance with applicable policy. This requirement pertains to Zero Trust. Check_Content Review the application documentation and deployed configuration to determine whether the application enforces approved authorizations for controlling the flow of information between interconnected systems based on organization-defined information flow control policies. If the application does not enforce approved authorizations for controlling the flow of information between interconnected systems based on organization-defined information flow control policies, this is a finding. Fix_Text Configure the application to enforce approved authorizations for controlling the flow of information between interconnected systems based on organization-defined information flow control policies. Not_Reviewed Vuln_Num V-288267 Rule_ID SV-288267r1252386_rule Severity medium Rule_Title The application must associate organization-defined security attributes with information exchanged between information systems. Vuln_Discuss If security attributes are not associated with the information being transmitted between systems, access control policies and information flows that depend on these security attributes will not function, and unauthorized access may result. Security attributes are values associated with data content/structure and source/destination objects. These attributes are bound to the user and data objects and may include information about the data's purpose, creator, origin, access restrictions, access permissions, or classification. Specific security attributes used depend on the application or technology context. However, these attributes are used in information systems to implement security policy for access control and flow control for users, data, and traffic. Security attributes may be explicitly or implicitly associated with the information contained within the information system. This requirement applies to those applications that transmit or receive data between information systems. Check_Content Review the application documentation and deployed configuration to determine whether the application associates organization-defined security attributes with information exchanged between information systems. If the application does not associate organization-defined security attributes with information exchanged between information systems, this is a finding. Fix_Text Configure the application to associate organization-defined security attributes with information exchanged between information systems. Not_Reviewed Vuln_Num V-288268 Rule_ID SV-288268r1252962_rule Severity medium Rule_Title The application must dynamically associate security attributes with organization-defined objects in accordance with organization-defined security policies as information is created and combined. Vuln_Discuss If the application does not dynamically reconfigure the data security attributes as data is created and combined, there is the possibility that the security attributes will not correctly reflect the data with which they are associated. Security attributes are abstractions representing the basic properties or characteristics of an entity (e.g., subjects and objects) with respect to safeguarding information. These attributes are typically associated with internal data structures (e.g., data records, buffers, and files) within the application and are used to enable the implementation of access control and flow control policies, reflect special dissemination, handling or distribution instructions, or support other aspects of the information security policy. Organizations define the security attributes of their data (e.g., classified and CUI). When data is created and/or combined, data security attributes defined by organizational policy must be dynamically created and/or updated to reflect the potential change in data sensitivity and characteristics. Dynamic association of security attributes is appropriate whenever the security characteristics of information changes over time. Security attributes may change due to information aggregation issues (i.e., the security characteristics of individual information elements are different from the combined elements); changes in individual access authorizations (i.e., privileges); or changes in the security category of information. This requirement pertains to Zero Trust. Check_Content Review the application documentation and deployed configuration to determine whether the application dynamically associates security attributes with organization-defined objects in accordance with organization-defined security policies as information is created and combined. If the application does not dynamically associate security attributes with organization-defined objects in accordance with organization-defined security policies as information is created and combined, this is a finding. Fix_Text Configure the application to dynamically associate security attributes with organization-defined objects in accordance with organization-defined security policies as information is created and combined. Not_Reviewed Vuln_Num V-288269 Rule_ID SV-288269r1252963_rule Severity medium Rule_Title The application must uniquely identify and authenticate source points by organization, system, application, and/or individual for information transfer. Vuln_Discuss Attribution is a critical component of a security concept of operations. The ability to identify source and destination points for information flowing in information systems allows the forensic reconstruction of events when required, and encourages policy compliance by attributing policy violations to specific organizations/individuals. Successful domain authentication requires that information system labels distinguish among systems, organizations, and individuals involved in preparing, sending, receiving, or disseminating information. This requirement applies to applications that transfer information between different security domains (e.g., multilevel security). This requirement pertains to Zero Trust. Check_Content Review the application documentation and deployed configuration to determine whether the application uniquely identifies and authenticates source points by organization, system, application, and/or individual for information transfer. If the application does not uniquely identify and authenticate source points by organization, system, application, and/or individual for information transfer, this is a finding. Fix_Text Configure the application to uniquely identify and authenticate source points by organization, system, application, and/or individual for information transfer. Not_Reviewed Vuln_Num V-288270 Rule_ID SV-288270r1252964_rule Severity medium Rule_Title The application must implement organization-defined mechanisms or techniques to bind security attributes to transmitted information. Vuln_Discuss Cryptographic mechanisms and techniques can provide strong security and privacy attribute binding to transmitted information to help ensure the integrity of such information. This requirement pertains to Zero Trust. Check_Content Review the application documentation and deployed configuration to determine whether the application implements organization-defined mechanisms or techniques to bind security attributes to transmitted information. If the application does not implement organization-defined mechanisms or techniques to bind security attributes to transmitted information, this is a finding. Fix_Text Configure the application to implement organization-defined mechanisms or techniques to bind security attributes to transmitted information. Not_Reviewed Vuln_Num V-288271 Rule_ID SV-288271r1252965_rule Severity medium Rule_Title The application must attach data tags containing organization-defined authorized processing to organization-defined elements of personally identifiable information (PII). Vuln_Discuss Data tags support the tracking and enforcement of authorized processing by conveying the types of processing that are authorized along with the relevant elements of PII throughout the system. Data tags may also support the use of automated tools. This requirement pertains to Zero Trust. Check_Content Review the application documentation and deployed configuration to determine whether the application attaches data tags containing organization-defined authorized processing to organization-defined elements of PII. If the application does not attach data tags containing organization-defined authorized processing to organization-defined elements of PII, this is a finding. Fix_Text Configure the application to attach data tags containing organization-defined authorized processing to organization-defined elements of PII. Not_Reviewed Vuln_Num V-288272 Rule_ID SV-288272r1252966_rule Severity medium Rule_Title The application must attach data tags containing organization-defined processing purposes to organization-defined elements of personally identifiable information (PII). Vuln_Discuss Data tags support the tracking of processing purposes by conveying the purposes along with the relevant elements of PII throughout the system. By conveying the processing purposes in a data tag along with the personally identifiable information as the information transits a system, a system owner or operator can identify whether a change in processing would be compatible with the identified and documented purposes. Data tags may also support the use of automated tools. This requirement pertains to Zero Trust. Check_Content Review the application documentation and deployed configuration to determine whether the application attaches data tags containing organization-defined processing purposes to organization-defined elements of PII. If the application does not attach data tags containing organization-defined processing purposes to organization-defined elements of PII. Fix_Text Configure the application to attach data tags containing organization-defined processing purposes to organization-defined elements of PII. Not_Reviewed Vuln_Num V-288273 Rule_ID SV-288273r1252967_rule Severity medium Rule_Title The application must enforce attribute-based access control policy over defined subjects and objects based upon organization-defined attributes to assume access permissions. Vuln_Discuss Attribute-based access control is an access control policy that restricts system access to authorized users based on specified organizational attributes (e.g., job function, identity), action attributes (e.g., read, write, delete), environmental attributes (e.g., time of day, location), and resource attributes (e.g., classification of a document). Organizations can create rules based on attributes and the authorizations (i.e., privileges) to perform needed operations on the systems associated with organization-defined attributes and rules. When users are assigned to attributes defined in attribute-based access control policies or rules, they can be provisioned to a system with the appropriate privileges or dynamically granted access to a protected resource. This requirement pertains to Zero Trust. Check_Content Review the application documentation and deployed configuration to determine whether the application enforces attribute-based access control policy over defined subjects and objects based upon organization-defined attributes to assume access permissions. If the application does not enforce attribute-based access control policy over defined subjects and objects based upon organization-defined attributes to assume access permissions, this is a finding. Fix_Text Configure the application to enforce attribute-based access control policy over defined subjects and objects based upon organization-defined attributes to assume access permissions. Not_Reviewed Vuln_Num V-288274 Rule_ID SV-288274r1252407_rule Severity medium Rule_Title The application must identify prohibited mobile code. Vuln_Discuss Decisions regarding the employment of mobile code within applications are based on the potential for the code to cause damage to the system if used maliciously. Mobile code is defined as software modules obtained from remote systems, transferred across a network, and then downloaded and executed on a local system without explicit installation or execution by the recipient. DoW has identified prohibited mobile code in Department of Defense Instruction (DODI) 8552.01 as: all Category 1X mobile code, unsigned Category 1A mobile code, Category 2 mobile code that violates usage requirements, all Emerging Technologies mobile code (all mobile code technologies, systems, platforms, or languages whose capabilities and threat level have not yet undergone a risk assessment and been assigned to a risk category), and all mobile code that downloads via an email body or email attachment that executes automatically when the user opens the email body or attachment. Usage restrictions and implementation guidance apply to both the selection and use of mobile code installed, downloaded, or executed on all endpoints (e.g., servers, workstations, and smart phones). This requirement applies to applications that execute, evaluate, or otherwise process mobile code (e.g., web applications, browsers, and antivirus applications). Check_Content Review the application documentation and deployed configuration to determine whether the application identifies prohibited mobile code. If the application does not identify prohibited mobile code, this is a finding. Fix_Text Configure the application to identify prohibited mobile code. Not_Reviewed Vuln_Num V-288275 Rule_ID SV-288275r1252410_rule Severity medium Rule_Title The application must prompt the user for action prior to executing mobile code. Vuln_Discuss Mobile code can cause damage to the system. It can execute without explicit action from, or notification to, a user. Actions enforced before executing mobile code include, for example, prompting users prior to opening email attachments and disabling automatic execution. This requirement applies to mobile code-enabled software, which is capable of executing one or more types of mobile code. Check_Content Review the application documentation and deployed configuration to determine whether the application prompts the user for action prior to executing mobile code. If the application does not prompt the user for action prior to executing mobile code, this is a finding. Fix_Text Configure the application to prompt the user for action prior to executing mobile code. Not_Reviewed Vuln_Num V-288276 Rule_ID SV-288276r1252413_rule Severity medium Rule_Title The application must prevent the execution of prohibited mobile code. Vuln_Discuss Decisions regarding the employment of mobile code within organizational information systems are based on the potential for the code to cause damage to the system if used maliciously. Mobile code is defined as software modules obtained from remote systems, transferred across a network, and then downloaded and executed on a local system without explicit installation or execution by the recipient. Actions enforced before executing mobile code include, for example, prompting users prior to opening email attachments and disabling automatic execution. Usage restrictions and implementation guidance apply to both the selection and use of mobile code installed, downloaded, or executed on all endpoints (e.g., servers, workstations, and smart phones). This requirement applies to applications that execute, evaluate, or otherwise process mobile code (e.g., web applications, browsers, and antivirus applications). Check_Content Review the application documentation and deployed configuration to determine whether the application prevents the execution of prohibited mobile code. If the application does not prevent the execution of prohibited mobile code, this is a finding. Fix_Text Configure the application to prevent the execution of prohibited mobile code. Not_Reviewed Vuln_Num V-288277 Rule_ID SV-288277r1252416_rule Severity medium Rule_Title The application must block, quarantine, and/or alert administrators when prohibited mobile code is identified. Vuln_Discuss Decisions regarding the employment of mobile code within organizational information systems are based on the potential for the code to cause damage to the system if used maliciously. Mobile code is defined as software modules obtained from remote systems, transferred across a network, and then downloaded and executed on a local system without explicit installation or execution by the recipient. DoW has defined the corrective actions to be taken when prohibited mobile code is identified in Department of Defense Instruction (DODI) 8552.01, "Use of Mobile Code Technologies in DOD Information Systems". DoW has identified prohibited mobile code in DODI 8552.01 as: all Category 1X mobile code, unsigned Category 1A mobile code, Category 2 mobile code that violates usage requirements, all Emerging Technologies mobile code (all mobile code technologies, systems, platforms, or languages whose capabilities and threat level have not yet undergone a risk assessment and been assigned to a risk category), and all mobile code that downloads via an email body or email attachment that executes automatically when the user opens the email body or attachment. Usage restrictions and implementation guidance apply to both the selection and use of mobile code installed, downloaded, or executed on all endpoints (e.g., servers, workstations, and smart phones). This requirement applies to applications that execute, evaluate, or otherwise process mobile code (e.g., web applications, browsers, and antivirus applications). Corrective actions when unacceptable mobile code is detected include, for example, blocking, quarantine, or alerting administrators. Blocking includes, for example, preventing transmission of word processing files with embedded macros when such macros have been defined to be unacceptable mobile code. Check_Content Review the application documentation and deployed configuration to determine whether the application blocks, quarantines, and/or alerts administrators when prohibited mobile code is identified. If the application does not block, quarantine, and/or alert administrators when prohibited mobile code is identified, this is a finding. Fix_Text Configure the application to block, quarantine, and/or alert administrators when prohibited mobile code is identified. Not_Reviewed Vuln_Num V-288278 Rule_ID SV-288278r1252419_rule Severity medium Rule_Title The application must prevent the download of prohibited mobile code. Vuln_Discuss Decisions regarding the employment of mobile code within organizational information systems are based on the potential for the code to cause damage to the system if used maliciously. Mobile code is defined as software modules obtained from remote systems, transferred across a network, and then downloaded and executed on a local system without explicit installation or execution by the recipient. Usage restrictions and implementation guidance apply to both the selection and use of mobile code installed, downloaded, or executed on all endpoints (e.g., servers, workstations, and smart phones). This requirement applies to applications that execute, evaluate, or otherwise process mobile code (e.g., web applications, browsers, and antivirus applications). Check_Content Review the application documentation and deployed configuration to determine whether the application prevents the download of prohibited mobile code. If the application does not prevent the download of prohibited mobile code, this is a finding. Fix_Text Configure the application to prevent the download of prohibited mobile code. Not_Reviewed Vuln_Num V-288279 Rule_ID SV-288279r1252422_rule Severity medium Rule_Title The application must prevent the automatic execution of mobile code in, at a minimum, office applications, browsers, email clients, mobile code runtime environments, and mobile agent systems. Vuln_Discuss Mobile code can cause damage to the system. It can execute without explicit action from, or notification to, a user. Preventing automatic execution of mobile code includes, for example, disabling auto execute features on information system components. This requirement applies to mobile code-enabled software that is capable of executing one or more types of mobile code. Check_Content Review the application documentation and deployed configuration to determine whether the application prevents the automatic execution of mobile code in, at a minimum, office applications, browsers, email clients, mobile code runtime environments, and mobile agent systems. If the application does not prevent the automatic execution of mobile code in, at a minimum, office applications, browsers, email clients, mobile code runtime environments, and mobile agent systems, this is a finding. Fix_Text Configure the application to prevent the automatic execution of mobile code in, at a minimum, office applications, browsers, email clients, mobile code runtime environments, and mobile agent systems. Not_Reviewed Vuln_Num V-288280 Rule_ID SV-288280r1252425_rule Severity medium Rule_Title Applications scanning for malicious code must scan all media used for system maintenance prior to use. Vuln_Discuss There are security-related issues arising from software brought into the information system specifically for diagnostic and repair actions (e.g., a software packet sniffer installed on a system to troubleshoot system traffic, or a vendor installing or running a diagnostic application to troubleshoot an issue with a vendor supported system). If, upon inspection of media containing maintenance diagnostic and test programs, organizations determine that the media contain malicious code, the incident is handled consistent with organizational incident handling policies and procedures. This requirement addresses security-related issues associated with maintenance tools used specifically for diagnostic and repair actions on organizational information systems. Maintenance tools can include hardware, software, and firmware items. Maintenance tools are potential vehicles for transporting malicious code, either intentionally or unintentionally, into a facility and subsequently into organizational information systems. Maintenance tools can include, for example, hardware/software diagnostic test equipment and hardware/software packet sniffers. 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_Content Review the anti-malware application documentation and deployed configuration to determine whether all media used for system maintenance is scanned prior to use. If the anti-malware application does not scan all media used for system maintenance prior to use, this is a finding. Fix_Text Configure the anti-malware application to scan all media used for system maintenance prior to use. Not_Reviewed Vuln_Num V-288281 Rule_ID SV-288281r1252428_rule Severity medium Rule_Title The application must automatically update malicious code protection mechanisms whenever new releases are available in accordance with organizational configuration management policy. Vuln_Discuss Malicious code includes viruses, worms, Trojan horses, and spyware. The code provides the ability for a malicious user to read from and write to files and folders on a computer's hard drive. Malicious code may also be able to run and attach programs, which may allow the unauthorized distribution of malicious mobile code. Once this code is installed on endpoints within the network, unauthorized users may be able to breach firewalls and gain access to sensitive data. This requirement applies to applications providing malicious code protection. Malicious code protection mechanisms include, but are not limited to, antivirus and malware detection software. Malicious code protection mechanisms (including signature definitions and rule sets) must be updated when new releases are available. Check_Content Review the anti-malware application documentation and deployed configuration to determine whether malicious code protection mechanisms are automatically updated whenever new releases are available in accordance with organizational configuration management policy. If the anti-malware application automatically update malicious code protection mechanisms whenever new releases are available in accordance with organizational configuration management policy, this is a finding. Fix_Text Configure the anti-malware application to automatically update malicious code protection mechanisms whenever new releases are available in accordance with organizational configuration management policy. Not_Reviewed Vuln_Num V-288282 Rule_ID SV-288282r1252431_rule Severity medium Rule_Title The application must configure malicious code protection mechanisms to perform periodic scans of the information system every seven days. Vuln_Discuss Malicious code protection mechanisms include, but are not limited to, antivirus and malware detection software. To minimize potential negative impact to the organization that can be caused by malicious code, it is imperative that malicious code is identified and eradicated. Malicious code includes viruses, worms, Trojan horses, and spyware. It is not enough to simply have the software installed; this software must periodically scan the system to search for malware on an organization-defined frequency. This requirement applies to applications providing malicious code protection. Check_Content Review the anti-malware application documentation and deployed configuration to determine whether periodic scans of the information system are performed every seven days. If the anti-malware application malicious code protection mechanisms are not configured to perform periodic scans of the information system every seven days, this is a finding. Fix_Text Configure the anti-malware application to perform periodic scans of the information system every seven days. Not_Reviewed Vuln_Num V-288283 Rule_ID SV-288283r1252434_rule Severity medium Rule_Title The application must be configured to perform real-time malicious code protection scans of files from external sources at endpoints as the files are downloaded, opened, or executed in accordance with organizational security policy. Vuln_Discuss Malicious code protection mechanisms include, but are not limited to, antivirus and malware detection software. To minimize potential negative impact to the organization that can be caused by malicious code, it is imperative that malicious code is identified and eradicated. Malicious code includes viruses, worms, Trojan horses, and spyware. It is not enough to simply have the software installed; this software must periodically scan the system to search for malware on an organization-defined frequency. This requirement applies to applications providing malicious code protection. Check_Content Review the anti-malware application documentation and deployed configuration to determine whether real-time malicious code protection scans are performed on files from external sources at endpoints as the files are downloaded, opened, or executed in accordance with organizational security policy. If the anti-malware application malicious code protection mechanisms are not configured to perform periodic real-time malicious code protection scans on files from external sources at endpoints as the files are downloaded, opened, or executed in accordance with organizational security policy, this is a finding. Fix_Text Configure the anti-malware application to perform real-time malicious code protection scans on files from external sources at endpoints as the files are downloaded, opened, or executed in accordance with organizational security policy. Not_Reviewed Vuln_Num V-288284 Rule_ID SV-288284r1252437_rule Severity medium Rule_Title The application must be configured to block and quarantine malicious code upon detection. Vuln_Discuss Malicious code protection mechanisms include, but are not limited to, antivirus and malware detection software. To minimize potential negative impact to the organization that can be caused by malicious code, it is imperative that malicious code is identified and eradicated. Applications providing this capability must be able to perform actions in response to detected malware. Responses include blocking, quarantining, deleting, and alerting. Other technology- or organization-specific responses may also be employed to satisfy this requirement. Malicious code includes viruses, worms, Trojan horses, and spyware. This requirement applies to applications providing malicious code protection. Check_Content Review the anti-malware application documentation and deployed configuration to determine whether malicious code is blocked and quarantined upon detection. If the anti-malware application malicious code protection mechanisms are not configured to block and quarantine malicious code upon detection, this is a finding. Fix_Text Configure the anti-malware application to block and quarantine malicious code upon detection. Not_Reviewed Vuln_Num V-288285 Rule_ID SV-288285r1252440_rule Severity medium Rule_Title The application must implement nonsignature-based malicious code detection mechanisms. Vuln_Discuss Nonsignature-based detection mechanisms provide safeguards against malicious code for which signatures do not yet exist or for which existing signatures may not be effective. These mechanisms include, for example, the use of heuristics to detect, analyze, and describe the characteristics or behavior of malicious code, or file reputation services that are updated more frequently than traditional signature-based detection mechanisms. Malicious code for which signature-based detection mechanisms may not be effective include polymorphic malicious code (i.e., code that changes signatures when it replicates). This requirement does not preclude the use of signature-based detection mechanisms. This requirement applies to applications providing malicious code protection. Check_Content Review the anti-malware application documentation and deployed configuration to determine whether nonsignature-based malicious code detection mechanisms are implemented. If the anti-malware application does not implement nonsignature-based malicious code detection mechanisms, this is a finding. Fix_Text Configure the anti-malware application to implement nonsignature-based malicious code detection mechanisms. Not_Reviewed Vuln_Num V-288286 Rule_ID SV-288286r1253078_rule Severity medium Rule_Title The application must configure malicious code protection mechanisms to send alerts to organization-defined personnel in response to malicious code detection. Vuln_Discuss System entry and exit points include firewalls, remote access servers, workstations, electronic mail servers, web servers, proxy servers, notebook computers, and mobile devices. Malicious code includes viruses, worms, Trojan horses, and spyware. Malicious code can also be encoded in various formats contained within compressed or hidden files or hidden in files using techniques such as steganography. Malicious code can be inserted into systems in a variety of ways, including by electronic mail, the world-wide web, and portable storage devices. Malicious code insertions occur through the exploitation of system vulnerabilities. A variety of technologies and methods exist to limit or eliminate the effects of malicious code. Malicious code protection mechanisms include both signature- and nonsignature-based technologies. Nonsignature-based detection mechanisms include artificial intelligence techniques that use heuristics to detect, analyze, and describe the characteristics or behavior of malicious code and to provide controls against such code for which signatures do not yet exist or for which existing signatures may not be effective. Malicious code for which active signatures do not yet exist or may be ineffective includes polymorphic malicious code (i.e., code that changes signatures when it replicates). Nonsignature-based mechanisms also include reputation-based technologies. In addition to the above technologies, pervasive configuration management, comprehensive software integrity controls, and anti-exploitation software may be effective in preventing the execution of unauthorized code. Malicious code may be present in commercial off-the-shelf software as well as custom-built software and could include logic bombs, backdoors, and other types of attacks that could affect organizational mission and business functions. In situations where malicious code cannot be detected by detection methods or technologies, organizations rely on other types of controls, including secure coding practices, configuration management and control, trusted procurement processes, and monitoring practices to ensure software does not perform functions other than the functions intended. Organizations may determine that, in response to the detection of malicious code, different actions may be warranted. For example, organizations can define actions in response to malicious code detection during periodic scans, the detection of malicious downloads, or the detection of maliciousness when attempting to open or execute files. Check_Content Review the anti-malware application documentation and deployed configuration to determine whether alerts are sent to organization-defined personnel in response to malicious code detection. If the anti-malware application malicious code protection mechanisms are not configured send alerts to organization-defined personnel in response to malicious code detection, this is a finding. Fix_Text Configure the anti-malware application to send alerts to organization-defined personnel in response to malicious code detection. Not_Reviewed Vuln_Num V-288287 Rule_ID SV-288287r1252977_rule Severity medium Rule_Title The application that implements spam protection mechanisms must be updated automatically. Vuln_Discuss Originators of spam messages are constantly changing their techniques to defeat spam countermeasures; therefore, spam software must be constantly updated to address the changing threat. A manual update procedure is labor intensive and does not scale well in an enterprise environment. This risk may be mitigated by using an automatic update capability. Spam protection mechanisms include, for example, signature definitions, rule sets, and algorithms. Check_Content Review the anti-malware application documentation and deployed configuration to determine whether spam protection mechanisms are updated automatically. If the anti-malware application spam protection mechanisms are not configured to be updated automatically, this is a finding. Fix_Text Configure the anti-malware application spam protection mechanisms to update automatically. Not_Reviewed Vuln_Num V-288288 Rule_ID SV-288288r1252449_rule Severity medium Rule_Title The application must prevent the installation of patches, service packs, or application components without verification the software component has been digitally signed using a certificate recognized and approved by the organization. Vuln_Discuss Changes to any software components can have significant effects on the overall security of the application. Verifying software components have been digitally signed using a certificate recognized and approved by the organization ensures the software has not been tampered with and that it has been provided by a trusted vendor. Accordingly, patches, service packs, or application components must be signed with a certificate recognized and approved by the organization. Verifying the authenticity of the software prior to installation validates the integrity of the patch or upgrade received from a vendor. This ensures the software has not been tampered with and that it has been provided by a trusted vendor. Self-signed certificates are disallowed by this requirement. The application must not have to verify the software again. This requirement does not mandate DoW certificates for this purpose; however, the certificate used to verify the software must be from an approved certificate authority (CA). Check_Content Review the application documentation and deployed configuration to determine whether the application prevents the installation of patches, service packs, or application components without verification the software component has been digitally signed using a certificate recognized and approved by the organization. If the application does not prevent the installation of patches, service packs, or application components without verification the software component has been digitally signed using a certificate that is recognized and approved by the organization, this is a finding. Fix_Text Configure the application to prevent the installation of patches, service packs, or application components without verification the software component has been digitally signed using a certificate that is recognized and approved by the organization. Not_Reviewed Vuln_Num V-288289 Rule_ID SV-288289r1252452_rule Severity medium Rule_Title The application must remove organization-defined software components after updated versions have been installed. Vuln_Discuss Previous versions of software components that are not removed from the information system after updates have been installed may be exploited by adversaries. Some information technology products may remove older versions of software automatically from the information system. Check_Content Review the application documentation and deployed configuration to determine whether the application removes organization-defined software components after updated versions have been installed. If the application does not remove organization-defined software components after updated versions have been installed, this is a finding. Fix_Text Configure the application to remove organization-defined software components after updated versions have been installed. Not_Reviewed Vuln_Num V-288290 Rule_ID SV-288290r1252494_rule Severity high Rule_Title The application must install security-relevant software updates within 30 days unless the time period is directed by an authoritative source (e.g., IAVM, CTOs, DTMs, STIGs). Vuln_Discuss Security flaws with software applications are discovered daily. Vendors are constantly updating and patching their products to address newly discovered security vulnerabilities. Organizations (including any contractor to the organization) are required to promptly install security-relevant software updates (e.g., patches, service packs, and hot fixes). 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 software 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 also 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 used 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 application will be configured to check for and install security-relevant software updates within an identified time period from the availability of the update. The specific time period will be defined by an authoritative source (e.g., IAVM, CTOs, DTMs, and STIGs). Check_Content Review the application documentation and deployed configuration to determine whether the application installs security-relevant software updates within 30 days unless the time period is directed by an authoritative source (e.g., IAVM, CTOs, DTMs, STIGs). If the application does not install security-relevant software updates within 30 days unless the time period is directed by an authoritative source (e.g., IAVM, CTOs, DTMs, STIGs), this is a finding. Fix_Text Configure the application to install security-relevant software updates within 30 days unless the time period is directed by an authoritative source (e.g., IAVM, CTOs, DTMs, STIGs). Not_Reviewed Vuln_Num V-288291 Rule_ID SV-288291r1252458_rule Severity medium Rule_Title The application must implement cryptographic mechanisms to authenticate organization-defined software or firmware components prior to installation. Vuln_Discuss Unauthorized modifications to software or firmware may be indicative of a sophisticated, targeted cyberattack. Cryptographic authentication includes, for example, verifying that software or firmware components have been digitally signed using certificates recognized and approved by organizations. Code signing is an effective method to protect against malicious code. Check_Content Review the application documentation and deployed configuration to determine whether the application implements cryptographic mechanisms to authenticate organization-defined software or firmware components prior to installation. If the application does not implement cryptographic mechanisms to authenticate organization-defined software or firmware components prior to installation, this is a finding. Fix_Text Configure the application to install security-relevant software updates within 30 days unless the time period is directed by an authoritative source (e.g., IAVM, CTOs, DTMs, STIGs). Not_Reviewed Vuln_Num V-288292 Rule_ID SV-288292r1252461_rule Severity medium Rule_Title The application must disable organization-defined functions, ports, protocols, and services (within the application) deemed unnecessary and/or nonsecure. Vuln_Discuss Removal of unneeded or nonsecure functions, ports, protocols, and services mitigate the risk of unauthorized connection of devices, unauthorized transfer of information, or other exploitation of these resources. The organization must perform a periodic scan/review of the application (as required by CCI-000384) and disable functions, ports, protocols, and services deemed to be unneeded or nonsecure. Check_Content Review the application documentation and deployed configuration to determine whether the application disables organization-defined functions, ports, protocols, and services (within the application) deemed unnecessary and/or nonsecure. If the application does not disable organization-defined functions, ports, protocols, and services (within the application) deemed unnecessary and/or nonsecure, this is a finding. Fix_Text Configure the application to disable organization-defined functions, ports, protocols, and services (within the application) deemed unnecessary and/or nonsecure. Not_Reviewed Vuln_Num V-288293 Rule_ID SV-288293r1252464_rule Severity medium Rule_Title The application must prohibit or restrict the use of protocols that transmit unencrypted authentication information or use flawed cryptographic algorithms for transmission. Vuln_Discuss Using older unauthorized versions or incorrectly configuring protocol negotiation makes the gateway vulnerable to known and unknown attacks that exploit vulnerabilities in this protocol. If unsecured protocols (lacking cryptographic mechanisms) are used for the transmission of data, the contents of the data becomes vulnerable to known and unknown attacks that exploit vulnerabilities in this protocol. Examples of unsecured protocols include HTTP, FTP, NTLM, Telnet, etc. Check_Content Review the application documentation and deployed configuration to determine whether the application prohibits or restricts the use of protocols that transmit unencrypted authentication information or uses flawed cryptographic algorithms for transmission. If the application does not prohibit or restrict the use of protocols that transmit unencrypted authentication information or use flawed cryptographic algorithms for transmission, this is a finding. Fix_Text Configure the application to prohibit or restrict the use of protocols that transmit unencrypted authentication information or use flawed cryptographic algorithms for transmission. Not_Reviewed Vuln_Num V-288294 Rule_ID SV-288294r1252897_rule Severity medium Rule_Title The application must use the system clock. Vuln_Discuss 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_Content Navigate to the time configuration function within the application. Verify the application is configured use to the system (operating system) clock. Otherwise, this is a finding. Fix_Text Navigate to the time configuration function within the application. Configure the application to use the system (operating system) clock. Not_Reviewed Vuln_Num V-288295 Rule_ID SV-288295r1252470_rule Severity high Rule_Title The application must be a version supported by the vendor. Vuln_Discuss Unsupported software and systems must not be used because fixes to newly identified bugs will not be implemented by the vendor. The lack of support can result in potential vulnerabilities. Software and systems at unsupported servicing levels or releases will not receive security updates for new vulnerabilities, which leaves them subject to exploitation. When maintenance updates and patches are no longer available, software is no longer considered supported and must be upgraded or decommissioned. Check_Content Review the application documentation and deployed configuration to determine whether the version the application running on the system is supported by the vendor. If the version of the application running on the system is not supported by the vendor, this is a finding. Fix_Text Upgrade to a supported version of the application. Not_Reviewed Vuln_Num V-288296 Rule_ID SV-288296r1252473_rule Severity medium Rule_Title The application must be configured to disable nonessential functions. Vuln_Discuss It is detrimental for applications to provide, or install by default, functionality exceeding requirements or mission objectives. These unnecessary functions or services are often overlooked and therefore, may remain unsecured. They increase the risk to the platform by providing additional attack vectors. Applications are capable of providing a wide variety of functions and services. Some of the functions and services, provided by default, may not be necessary to support essential organizational operations (e.g., key missions, functions). Examples of nonessential functions include, but are not limited to, advertising software or browser plug-ins not related to requirements or providing a wide array of functionality not required for every mission, but cannot be disabled. Check_Content This requirement can be used as a bucket to disable functions within an application deemed unnecessary for the DoW mission. Review the application documentation and deployed configuration to determine whether the application is configured to disable nonessential functions. If the application does not disable nonessential functions, this is a finding. Fix_Text Configure the application to disable nonessential functions. Not_Reviewed Vuln_Num V-288297 Rule_ID SV-288297r1252970_rule Severity medium Rule_Title The application must be configured in accordance with the security configuration settings based on DoW security configuration or implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs. Vuln_Discuss Configuring the application to implement organizationwide security implementation guides and security checklists ensures compliance with federal standards and establishes a common security baseline across DoW that reflects the most restrictive security posture consistent with operational requirements. Configuration settings are the set of parameters that can be changed that affect the security posture and/or functionality of the system. Security-related parameters are those parameters impacting the security state of the application, including the parameters required to satisfy other security control requirements. Check_Content This is a placeholder for best-practice security configurations not addressed via the other IA Controls and CCIs in this document. These instances are rare, and this must only be used in a STIG when a better control match cannot be found and best security practices are being leveraged. If this control is not required, this requirement is Not Applicable. Fix_Text Tie the pertinent requirement to an appropriate IA control. Not_Reviewed