What changed in EnterpriseDB Postgres Advanced Server (EPAS) STIG V2R2V2R2 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.

V-259212 in V2R2

Title

The EDB Postgres Advanced Server must provide audit record generation capability for DODDoW-defined auditable events within all EDB Postgres Advanced Server/database components.

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-259214 in V2R2

Title

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

Fix text

After creating a password verification function, configure the default profile to use it and the other required password related settings. To facilitate checking that a new password is sufficiently different from a previously used one, the dod_verify_password"DOD_verify_password" function uses the Levenshtein function, which is available as part of the PostgreSQL "fuzzystrmatch" extension. Before creating the password verification function, check whether the "fuzzystrmatch" extension is installed by executing the following SQL query as enterprisedb: SELECT extname FROM pg_extension; If "fuzzystrmatch" is not listed, execute the following SQL to install the extension as enterprisedb: CREATE EXTENSION fuzzystrmatch; With the "fuzzystrmatch" extension installed, execute the following SQL statements as enterprisedb: CREATE OR REPLACE FUNCTION sys.dod_verify_passwordDOD_verify_password(user_name varchar2, new_password varchar2, old_password varchar2) RETURN boolean IMMUTABLE IS pwd_length integer := NVL( length(new_password), 0 ); min_length integer := 15; min_lower integer := 1; min_upper integer := 1; min_numeric integer := 1; min_special integer := 1; min_diff integer := ceil(min_length::numeric / 2); cnt_lower integer := 0; cnt_upper integer := 0; cnt_numeric integer := 0; cnt_special integer := 0; cnt_diff integer := 0; i integer ; curr_char CHAR(1); BEGIN -- -- Check Length of new password -- IF ( pwd_length &lt min_length ) THEN raise_application_error(-20001, 'Password is too short. Password must be at least '||min_length||' characters long.'); END IF; -- -- Get count of each character type in new password. -- FOR i in 1..pwd_length LOOP curr_char := substr(new_password, i, 1); IF ( curr_char SIMILAR TO '[a-z]' ) THEN cnt_lower := cnt_lower + 1; ELSIF ( curr_char SIMILAR TO '[A-Z]' ) THEN cnt_upper := cnt_upper + 1; ELSIF ( curr_char SIMILAR TO '[0-9]' ) THEN cnt_numeric := cnt_numeric + 1; ELSE cnt_special := cnt_special + 1; END IF; END LOOP; -- -- Calculate Levenshtein difference between old and new password: -- cnt_diff := levenshtein( old_password, new_password ); -- Check if new password has minimum number of lowercase characters: IF cnt_lower &lt min_lower THEN raise_application_error(-20004, 'Password must contain at least '||min_lower||' lowercase character(s)'); END IF; -- Check if new password has minimum number of uppercase characters: IF cnt_upper &lt min_upper THEN raise_application_error(-20003, 'Password must contain at least '||min_upper||' uppercase character(s)'); END IF; -- Check if new password has minimum number of numeric characters: IF cnt_numeric &lt min_numeric THEN raise_application_error(-20005, 'Password must contain at least '||min_numeric||' numeric character(s)'); END IF; -- Check if new password has minimum number of special characters: IF cnt_special &lt min_special THEN raise_application_error(-20006, 'Password must contain at least '||min_special||' special character(s)'); END IF; -- Check if new password differs from old password by minimum number of required characters: IF cnt_diff &lt min_diff THEN raise_application_error(-20007, 'Password must differ from old password by at least '||min_diff||' character(s)'); END IF; RETURN true; END; ALTER FUNCTION sys.dod_verify_passwordDOD_verify_password(varchar2, varchar2, varchar2) OWNER TO enterprisedb; Next, execute the following statement (or a variant of this) to set the default profile for DODDoW standards: ALTER PROFILE DEFAULT LIMIT FAILED_LOGIN_ATTEMPTS 3 PASSWORD_LOCK_TIME 1 PASSWORD_LIFE_TIME 60180 PASSWORD_GRACE_TIME 3 PASSWORD_REUSE_TIME 180 PASSWORD_REUSE_MAX 5 PASSWORD_VERIFY_FUNCTION dod_verify_passwordDOD_verify_password; Note that the above statement assumes that the password verification function is named "dod_verify_passwordDOD_verify_password". If the function was created with a different name, update the "ALTER PROFILE" statement above as appropriate.

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 Authorizingauthorizing Officialofficial (AO)-approved. 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 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.

CCIs

CCI-004066CCI-004066,CCI-000192

V-259246 in V2R2

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 Authorizingauthorizing Officialofficial ( 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.

CCIs

CCI-004062CCI-004062,CCI-000196

V-259247 in V2R2

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-259248 in V2R2

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-259249 in V2R2

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-259250 in V2R2

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-259251 in V2R2

CCIs

CCI-003980CCI-003980,CCI-001812

V-259283 in V2R2

CCIs

CCI-003938CCI-003938,CCI-001814

V-259285 in V2R2

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.

CCIs

CCI-004895CCI-004895,CCI-002038

V-259287 in V2R2

Title

The EDB Postgres Advanced Server must only accept end entity certificates issued by DODDoW PKI or DODDoW-approved PKI Certification Authorities (CAs) for the establishment of all encrypted sessions.

Check text

Verify that the "root.crt" certificate was issued by a valid DODDoW entity. > openssl x509 -in /&ltPGDATA directory>/root.crt -text | grep -i "issuer". The default path for the PostgreSQL data directory (PGDATA) is /var/lib/edb/as&ltversion>/data, but this will vary according to local circumstances. Example: > openssl x509 -in /var/lib/edb/as15/data/root.crt -text | grep -i "issuer" If any issuers are listed that are not approved DODDoW certificate authorities, this is a finding.

Fix text

Revoke trust in any certificates not issued by a DODDoW-approved certificate authority. Contact the organization's certificate issuer and request a new certificate that is issued by a DODDoW-approved certificate authority.

Discussion

Only DODDoW-approved external PKIs have been evaluated to ensure that they have security controls and identity vetting procedures in place which 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 issuing certificates that enable adversaries to impersonate legitimate users. The authoritative list of DODDoW-approved PKIs is published at httphttps://iasecyber.disa.mil/pki-pke/interoperability. This requirement focuses on communications protection for the DBMS session rather than for the network packet.

V-259289 in V2R2