What changed in Database Security Requirements Guide V4R6V4R6 changes

Discussion

Authentication with a DODDoW-approved PKI certificate does not necessarily imply authorization to access the DBMS. To mitigate the risk of unauthorized access to sensitive information by entities that have been issued certificates by DODDoW-approved PKIs, all DODDoW systems, including databases, must be properly configured to implement access control policies. Successful authentication must not automatically give an entity access to an asset or security boundary. Authorization procedures and controls must be implemented to ensure each authenticated entity also has a validated and current authorization. Authorization is the process of determining whether an entity, once authenticated, is permitted to access a specific asset. Information systems use access control policies and enforcement mechanisms to implement this requirement. Access control policies include identity-based policies, role-based policies, and attribute-based policies. Access enforcement mechanisms include access control lists, access control matrices, and cryptography. These policies and mechanisms must be employed by the application to control access between users (or processes acting on behalf of users) and objects (e.g., devices, files, records, processes, programs, and domains) in the information system. This requirement is applicable to access control enforcement applications, a category that includes database management systems. If the DBMS does not follow applicable policy when approving access, it may be in conflict with networks or other applications in the information system. This may result in users either gaining or being denied access inappropriately and in conflict with applicable policy. This requirement also applies to Zero Trust initiatives.

V-206521 in V4R6

Title

The DBMS must provide audit record generation capability for DoDW-defined auditable events within all DBMS/database components.

Fix text

Deploy a DBMS that supports the DoDW minimum set of auditable events. Configure the DBMS to generate audit records for at least the DoDW minimum set of events.

Discussion

Without the capability to generate audit records, 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 DBMS (e.g., process, module). Certain specific application functionalities may be audited as well. 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. DoDDoW has defined the list of events for which the DBMS will provide an audit record generation capability as the following: (i) Successful and unsuccessful attempts to access, modify, or delete privileges, security objects, security levels, or categories of information (e.g., classification levels); (ii) Access actions, such as successful and unsuccessful logon attempts, privileged activities, or other system-level access, starting and ending time for user access to the system, concurrent logons from different workstations, successful and unsuccessful accesses to objects, all program initiations, and all direct access to the information system; and (iii) All account creation, modification, disabling, and termination actions. Organizations may define additional events requiring continuous or ad hoc auditing.

V-206523 in V4R6

Title

If DBMS authentication, using passwords, is employed, the DBMS must enforce the DODoW standards for password complexity and lifetime.

Check text

If DBMS authentication, using passwords, is not employed, this is not a finding. If the DBMS is configured to inherit password complexity and lifetime rules from the operating system or access control program, this is not a finding. Review the DBMS settings relating to password complexity. Determine whether the following rules are enforced. If any are not, this is a finding. a. minimum of 15 characters, including at least one of each of the following character sets: - Uppercase. - Lowercase. - Numerics. - Special characters (e.g., ~ ! @ # $ % ^ & * ( ) _ + = - ' [ ] / ? > &lt). b. Minimum number of characters changed from previous password: 50 percent of the minimum password length; that is, eight. Review the DBMS settings relating to password lifetime. Determine whether the following rules are enforced. If any are not, this is a finding. a. Password lifetime limits for interactive accounts: Minimum 24 hours, maximum 60180 days. b. Password lifetime limits for noninteractive accounts: Minimum 24 hours, maximum 365 days. c. Number of password changes before an old one may be reused: Minimum of five.

Fix text

If the use of passwords is not needed, configure the DBMS to prevent their use if it is capable of this; if it is not, institute policies and procedures to prohibit their use. If the DBMS can inherit password complexity rules from the operating system or access control program, configure it to do so. Otherwise, use DBMS configuration parameters and/or custom code to enforce the following rules for passwords: a. Minimum of 15 characters, including at least one of each of the following character sets: - Uppercase. - Lowercase. - Numerics. - Special characters (e.g., ~ ! @ # $ % ^ & * ( ) _ + = - ' [ ] / ? > &lt). b. Minimum number of characters changed from previous password: 50 percent of the minimum password length; that is, eight. c. Password lifetime limits for interactive accounts: Minimum 24 hours, maximum 60180 days. d. Password lifetime limits for non-interactive accounts: Minimum 24 hours, maximum 365 days. e. Number of password changes before an old one may be reused: Minimum of five.

Discussion

OS/enterprise authentication and identification must be used (SRG-APP-000023-DB-000001). Native DBMS authentication may be used only when circumstances make it unavoidable; and must be documented and authorizing official (AO-) approved. The DODDoW standard for authentication is DODDoW-approved Public Key Infrastructure (PKI) certificates. Authentication based on user ID and password may be used only when it is not possible to employ a PKI certificate, and requires AO approval. In such cases, the DODDoW standards for password complexity and lifetime must be implemented. DBMS products that can inherit the rules for these from the operating system or access control program (e.g., Microsoft Active Directory) must be configured to do so. For other DBMSs, the rules must be enforced using available configuration parameters or custom code.

V-206555 in V4R6

Discussion

The DODDoW standard for authentication is DODDoW-approved Public Key Infrastructure (PKI) certificates. Authentication based on user ID and password may be used only when it is not possible to employ a PKI certificate, and requires authorizing official (AO) approval. In such cases, database passwords stored in clear text, using reversible encryption, or using unsalted hashes would be vulnerable to unauthorized disclosure. Database passwords must always be in the form of one-way, salted hashes when stored internally or externally to the DBMS.

V-206556 in V4R6

Discussion

The DoDDoW standard for authentication is DoDDoW-approved PKI certificates. Authentication based on User ID and Password may be used only when it is not possible to employ a PKI certificate, and requires authorizing official (AO) approval. In such cases, passwords need to be protected at all times, and encryption is the standard method for protecting passwords during transmission. DBMS passwords sent in clear text format across the network are vulnerable to discovery by unauthorized users. Disclosure of passwords may easily lead to unauthorized access to the database.

V-206557 in V4R6

Title

The DBMS, when utilizing Public Key Infrastructure (PKI)-based authentication, must validate certificates by performing RFC 5280-compliant certification path validation.

Discussion

The DoDDoW standard for authentication is DoDDoW-approved PKI certificates. 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. Database Management Systems that do not validate certificates by performing RFC 5280-compliant certification path validation are in danger of accepting certificates that are invalid and/or counterfeit. This could allow unauthorized access to the database.

V-206558 in V4R6

Title

The DBMS must enforce authorized access to all Public Key Infrastructure (PKI) private keys stored/utilized by the DBMS.

Discussion

The DoDDoW standard for authentication is DoDDoW-approved PKI certificates. PKI certificate-based authentication is performed by requiring the certificate holder to cryptographically prove possession of the corresponding private key. If the private key is stolen, an attacker can use the private key(s) to impersonate the certificate holder. In cases where the DBMS-stored private keys are used to authenticate the DBMS to the system’s clients, loss of the corresponding private keys would allow an attacker to successfully perform undetected man in the middle attacks against the DBMS system and its clients. Both the holder of a digital certificate and the issuing authority must take careful measures to protect the corresponding private key. Private keys should always be generated and protected in FIPS 140-2- or 140-3- validated cryptographic modules. All access to the private key(s) of the DBMS must be restricted to authorized and authenticated users. If unauthorized users have access to one or more of the DBMS's private keys, an attacker could gain access to the key(s) and use them to impersonate the database on the network or otherwise perform unauthorized actions.

V-206559 in V4R6

Title

The DBMS must map the Public Key Infrastructure (PKI)-authenticated identity to an associated user account.

Discussion

The DoDDoW standard for authentication is DoDDoW-approved PKI certificates. Once a PKI certificate has been validated, it must be mapped to a DBMS user account for the authenticated identity to be meaningful to the DBMS and useful for authorization decisions.

V-206560 in V4R6

Discussion

The DoDDoW standard for authentication is DoDDoW-approved PKI certificates. Normally, with PKI authentication, the interaction with the user for authentication will be handled by a software component separate from the DBMS, such as ActivIdentity ActivClient. However, in cases where the DBMS controls the interaction, this requirement applies. To prevent the compromise of authentication information such as passwords and PINs during the authentication process, the feedback from the system must not provide any information that would allow an unauthorized user to compromise the authentication mechanism. Obfuscation of user-provided authentication secrets when typed into the system is a method used in addressing this risk. Displaying asterisks when a user types in a password or a smart card PIN is an example of obscuring feedback of authentication secrets. This calls for review of applications, which will require collaboration with the application developers. It is recognized that in many cases, the database administrator (DBA) is organizationally separate from the application developers, and may have limited, if any, access to source code. Nevertheless, protections of this type are so important to the secure operation of databases that they must not be ignored. At a minimum, the DBA must attempt to obtain assurances from the development organization that this issue has been addressed, and must document what has been discovered.

V-206561 in V4R6

Discussion

The DODDoW standard for authentication of an interactive user is the presentation of a Commoncommon Accessaccess Cardcard (CAC) or other physical token bearing a valid, current, DODDoW-issued Public Key Infrastructure (PKI) certificate, coupled with a Personal Identification Number (PIN) to be entered by the user at the beginning of each session and whenever reauthentication is required. 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 DODDoW, the minimum circumstances requiring reauthentication are privilege escalation and role changes.

V-206600 in V4R6

Title

The DBMS must only accept end entity certificates issued by DODDoW Public Key Infrastructure (PKI) or DODDoW-approved PKI Certification Authorities (CAs) for the establishment of all encrypted sessions.

Check text

If the DBMS will accept non-DODoW approved PKI end-entity certificates, this is a finding.

Fix text

Revoke trust in any certificates not issued by a DODDoW-approved certificate authority. Configure the DBMS to accept only DODDoW and DODDoW-approved PKI end-entity certificates.

Discussion

Only DODDoW-approved external PKIs have been evaluated to ensure that they have security controls and identity vetting procedures in place that are sufficient for DODDoW systems to rely on the identity asserted in the certificate. PKIs lacking sufficient security controls and identity vetting procedures risk being compromised and risk issuing certificates that enable adversaries to impersonate legitimate users. The authoritative list of DODDoW-approved PKIs is published at https://www.cyber.mil/pki-pke. This requirement focuses on communications protection for the DBMS session rather than for the network packet.

V-206603 in V4R6

Title

The DBMS must be configured in accordance with the security configuration settings based on DoDDoW security configuration and implementation guidance, including STIGs, NSA configuration guides, CTOs, DTMs, and IAVMs.

Check text

Review the DBMS documentation and configuration to determine if the DBMS is configured in accordance with DoDDoW security configuration and implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs and IAVMs. If the DBMS is not configured in accordance with security configuration settings, this is a finding.

Fix text

Configure the DBMS in accordance with DoDDoW security configuration and implementation guidance, including STIGs, NSA configuration guides, CTOs, and DTMs and IAVMs.

Discussion

Configuring the DBMS to implement organization-wide security implementation guides and security checklists ensures compliance with federal standards and establishes a common security baseline across DoDDoW that reflects the most restrictive security posture consistent with operational requirements. In addition to this SRG, sources of guidance on security and information assurance exist. These include NSA configuration guides, CTOs, DTMs, and IAVMs. The DBMS must be configured in compliance with guidance from all such relevant sources.

V-206643 in V4R6