STIGQter STIGQter: STIG Summary: Crunchy Data Postgres 16 Security Technical Implementation Guide Version: 1 Release: 3 Benchmark Date: 01 Jul 2026:

PostgreSQL must generate audit records when unsuccessful accesses to objects occur.

DISA Rule

SV-261963r1000894_rule

Vulnerability Number

V-261963

Group Title

SRG-APP-000507-DB-000357

Rule Version

CD16-00-011900

Severity

CAT II

CCI(s)

Weight

10

Fix Recommendation

Configure PostgreSQL to produce audit records when unsuccessful attempts to access objects occur.

All errors and denials are logged if logging is enabled. To ensure logging is enabled, see the instructions in the supplementary content APPENDIX-C.

Check Contents

Note: The following instructions use the PGDATA and PGLOG environment variables. Refer to APPENDIX-F for instructions on configuring PGDATA and APPENDIX-I for PGLOG.

As the database administrator (shown here as "postgres"), create a schema, test_schema, create a table, test_table, within test_schema, and insert a value:

$ sudo su - postgres
$ psql -c "CREATE SCHEMA test_schema"
$ psql -c "CREATE TABLE test_schema.test_table(id INT)"
$ psql -c "INSERT INTO test_schema.test_table(id) VALUES (0)"

Create a role "bob" and attempt to SELECT, INSERT, UPDATE, and DROP from the test table:

$ psql -c "CREATE ROLE BOB"
$ psql -c "SET ROLE bob; SELECT * FROM test_schema.test_table"

$ psql -c "SET ROLE bob; INSERT INTO test_schema.test_table VALUES (0)"
$ psql -c "SET ROLE bob; UPDATE test_schema.test_table SET id = 1 WHERE id = 0"
$ psql -c "SET ROLE bob; DROP TABLE test_schema.test_table"
$ psql -c "SET ROLE bob; DROP SCHEMA test_schema"

As the database administrator (shown here as "postgres"), review PostgreSQL/database security and audit settings to verify that audit records are created for unsuccessful attempts at the specified access to the specified objects:

$ sudo su - postgres
$ cat ${PGDATA?}/${PGLOG?}/<latest_log>
2024-03-30 17:23:41.254 EDT postgres postgres ERROR: permission denied for schema test_schema at character 15
2024-03-30 17:23:41.254 EDT postgres postgres STATEMENT: SELECT * FROM test_schema.test_table;
2024-03-30 17:23:53.973 EDT postgres postgres ERROR: permission denied for schema test_schema at character 13
2024-03-30 17:23:53.973 EDT postgres postgres STATEMENT: INSERT INTO test_schema.test_table VALUES (0);
2024-03-30 17:24:32.647 EDT postgres postgres ERROR: permission denied for schema test_schema at character 8
2024-03-30 17:24:32.647 EDT postgres postgres STATEMENT: UPDATE test_schema.test_table SET id = 1 WHERE id = 0;
2024-03-30 17:24:46.197 EDT postgres postgres ERROR: permission denied for schema test_schema
2024-03-30 17:24:46.197 EDT postgres postgres STATEMENT: DROP TABLE test_schema.test_table;
2024-03-30 17:24:51.582 EDT postgres postgres ERROR: must be owner of schema test_schema
2024-03-30 17:24:51.582 EDT postgres postgres STATEMENT: DROP SCHEMA test_schema;

If any of the above steps did not create audit records for SELECT, INSERT, UPDATE, and DROP, this is a finding.

Vulnerability Number

V-261963

Documentable

False

Rule Version

CD16-00-011900

Severity Override Guidance

Note: The following instructions use the PGDATA and PGLOG environment variables. Refer to APPENDIX-F for instructions on configuring PGDATA and APPENDIX-I for PGLOG.

As the database administrator (shown here as "postgres"), create a schema, test_schema, create a table, test_table, within test_schema, and insert a value:

$ sudo su - postgres
$ psql -c "CREATE SCHEMA test_schema"
$ psql -c "CREATE TABLE test_schema.test_table(id INT)"
$ psql -c "INSERT INTO test_schema.test_table(id) VALUES (0)"

Create a role "bob" and attempt to SELECT, INSERT, UPDATE, and DROP from the test table:

$ psql -c "CREATE ROLE BOB"
$ psql -c "SET ROLE bob; SELECT * FROM test_schema.test_table"

$ psql -c "SET ROLE bob; INSERT INTO test_schema.test_table VALUES (0)"
$ psql -c "SET ROLE bob; UPDATE test_schema.test_table SET id = 1 WHERE id = 0"
$ psql -c "SET ROLE bob; DROP TABLE test_schema.test_table"
$ psql -c "SET ROLE bob; DROP SCHEMA test_schema"

As the database administrator (shown here as "postgres"), review PostgreSQL/database security and audit settings to verify that audit records are created for unsuccessful attempts at the specified access to the specified objects:

$ sudo su - postgres
$ cat ${PGDATA?}/${PGLOG?}/<latest_log>
2024-03-30 17:23:41.254 EDT postgres postgres ERROR: permission denied for schema test_schema at character 15
2024-03-30 17:23:41.254 EDT postgres postgres STATEMENT: SELECT * FROM test_schema.test_table;
2024-03-30 17:23:53.973 EDT postgres postgres ERROR: permission denied for schema test_schema at character 13
2024-03-30 17:23:53.973 EDT postgres postgres STATEMENT: INSERT INTO test_schema.test_table VALUES (0);
2024-03-30 17:24:32.647 EDT postgres postgres ERROR: permission denied for schema test_schema at character 8
2024-03-30 17:24:32.647 EDT postgres postgres STATEMENT: UPDATE test_schema.test_table SET id = 1 WHERE id = 0;
2024-03-30 17:24:46.197 EDT postgres postgres ERROR: permission denied for schema test_schema
2024-03-30 17:24:46.197 EDT postgres postgres STATEMENT: DROP TABLE test_schema.test_table;
2024-03-30 17:24:51.582 EDT postgres postgres ERROR: must be owner of schema test_schema
2024-03-30 17:24:51.582 EDT postgres postgres STATEMENT: DROP SCHEMA test_schema;

If any of the above steps did not create audit records for SELECT, INSERT, UPDATE, and DROP, this is a finding.

Check Content Reference

M

Target Key

5598