STIGQter STIGQter: STIG Summary: Crunchy Data PostgreSQL Security Technical Implementation Guide Version: 1 Release: 1 Benchmark Date: 20 Nov 2020:

PostgreSQL must produce audit records containing sufficient information to establish the identity of any user/subject or process associated with the event.

DISA Rule

SV-233582r617333_rule

Vulnerability Number

V-233582

Group Title

SRG-APP-000100-DB-000201

Rule Version

CD12-00-007800

Severity

CAT II

CCI(s)

Weight

10

Fix Recommendation

Note: The following instructions use the PGDATA and PGVER environment variables. See supplementary content APPENDIX-F for instructions on configuring PGDATA and APPENDIX-H for PGVER.

Logging must be enabled in order to capture the identity of any user/subject or process associated with an event. To ensure that logging is enabled, review supplementary content APPENDIX-C for instructions on enabling logging.

To enable username, database name, process ID, remote host/port and application name in logging, as the database administrator (shown here as "postgres"), edit the following in postgresql.conf:

$ sudo su - postgres
$ vi ${PGDATA?}/postgresql.conf
log_line_prefix = '< %m %u %d %p %r %a >'

Now, as the system administrator, reload the server with the new configuration:

$ sudo systemctl reload postgresql-${PGVER?}

Check Contents

Check PostgreSQL settings and existing audit records to verify a user name associated with the event is being captured and stored with the audit records. If audit records exist without specific user information, this is a finding.

First, as the database administrator (shown here as "postgres"), verify the current setting of log_line_prefix by running the following SQL:

$ sudo su - postgres
$ psql -c "SHOW log_line_prefix"

If log_line_prefix does not contain %m, %u, %d, %p, %r, %a, this is a finding.

Vulnerability Number

V-233582

Documentable

False

Rule Version

CD12-00-007800

Severity Override Guidance

Check PostgreSQL settings and existing audit records to verify a user name associated with the event is being captured and stored with the audit records. If audit records exist without specific user information, this is a finding.

First, as the database administrator (shown here as "postgres"), verify the current setting of log_line_prefix by running the following SQL:

$ sudo su - postgres
$ psql -c "SHOW log_line_prefix"

If log_line_prefix does not contain %m, %u, %d, %p, %r, %a, this is a finding.

Check Content Reference

M

Target Key

5254

Comments