In the event of a system failure, the DBMS must preserve any information necessary to determine cause of failure and any information necessary to return to operations with least disruption to mission processes.

Overview

Finding ID	Version	Rule ID	IA Controls	Severity
V-224177	EP11-00-005600	SV-224177r879641_rule		Medium

Description
Failure to a known state can address safety or security in accordance with the mission/business needs of the organization. Failure to a known secure state helps prevent a loss of confidentiality, integrity, or availability in the event of a failure of the information system or a component of the system. Preserving information system state information helps to facilitate system restart and return to the operational mode of the organization with less disruption of mission/business processes. Since it is usually not possible to test this capability in a production environment, systems should either be validated in a testing environment or prior to installation. This requirement is usually a function of the design of the IDPS component. Compliance can be verified by acceptance/validation processes or vendor attestation. At all times, Postgres maintains a write ahead log (WAL) in the pg_wal/ subdirectory of the cluster's data directory. The log records every change made to the database's data files. This log exists primarily for crash-safety purposes: if the system crashes, the database can be restored to consistency by “replaying” the log entries made since the last checkpoint. Under the covers, Postgres uses fsync system calls to help ensure that modified database information held in memory is written to disk. To support certain specialized use cases where crash recovery is not as important as system performance, Postgres provides an fsync parameter that can be set to "off" to disable the use of fsync. By default, this parameter is set to "on" and except for the rare use cases should not be set to "off". To support being able to determine what may have caused a database failure, Postgres inherently logs failures.

Description

Failure to a known state can address safety or security in accordance with the mission/business needs of the organization. Failure to a known secure state helps prevent a loss of confidentiality, integrity, or availability in the event of a failure of the information system or a component of the system. Preserving information system state information helps to facilitate system restart and return to the operational mode of the organization with less disruption of mission/business processes. Since it is usually not possible to test this capability in a production environment, systems should either be validated in a testing environment or prior to installation. This requirement is usually a function of the design of the IDPS component. Compliance can be verified by acceptance/validation processes or vendor attestation. At all times, Postgres maintains a write ahead log (WAL) in the pg_wal/ subdirectory of the cluster's data directory. The log records every change made to the database's data files. This log exists primarily for crash-safety purposes: if the system crashes, the database can be restored to consistency by “replaying” the log entries made since the last checkpoint. Under the covers, Postgres uses fsync system calls to help ensure that modified database information held in memory is written to disk. To support certain specialized use cases where crash recovery is not as important as system performance, Postgres provides an fsync parameter that can be set to "off" to disable the use of fsync. By default, this parameter is set to "on" and except for the rare use cases should not be set to "off". To support being able to determine what may have caused a database failure, Postgres inherently logs failures.

STIG	Date
EDB Postgres Advanced Server v11 on Windows Security Technical Implementation Guide	2024-01-24

Details

Check Text ( C-25850r495549_chk )
To check whether fsync() has been enabled for the EDB Postgres Advanced Server cluster, connect to the database as a database superuser using psql and execute the following psql command: SHOW fsync If the parameter is set to "off" and this setting has not been documented as approved with justification, this is a finding.

Fix Text (F-25838r495550_fix)
To set the fsync parameter to "on", connect to the database as a database superuser using psql and execute the following SQL commands: ALTER SYSTEM SET fsync = on; SELECT pg_reload_conf();