On 18/10/14 06:13, MauMau wrote:
>
> [requirement]
> 10.2.3 Verify access to all audit trails is logged.
>
> Malicious users often attempt to alter audit logs to
> hide their actions, and a record of access allows
> an organization to trace any inconsistencies or
> potential tampering of the logs to an individual
> account. Having access to logs identifying
> changes, additions, and deletions can help retrace
> steps made by unauthorized personnel.
>
> [my comment]
> I'm totally unsure how this can be fulfilled.
>
This is more matter of configuration of the whole system than something
pg_audit itself needs to care about (see my answer to 10.5).
>
> [requirement]
> 10.3 Record at least the following audit
> trail entries for all system components for
> each event:
> 10.3.4 Verify success or failure indication is included in log
> entries.
> 10.3.5 Verify origination of event is included in log entries.
>
> [my comment]
> This doesn't seem to be fulfilled because the failure of SQL statements
> and the client address are not part of the audit log entry.
>
You can add it to the log_line_prefix though.
>
> [requirement]
> 10.5 Secure audit trails so they cannot
> be altered.
> 10.5 Interview system administrators and examine system
> configurations and permissions to verify that audit trails are
> secured so that they cannot be altered as follows:
> 10.5.1 Only individuals who have a job-related need can view
> audit trail files.
> Adequate protection of the audit logs includes
> strong access control (limit access to logs based
> on “need to know” only), and use of physical or
> network segregation to make the logs harder to
> find and modify.
> Promptly backing up the logs to a centralized log
> server or media that is difficult to alter keeps the
> logs protected even if the system generating the
> logs becomes compromised.
> 10.5.2 Protect audit trail files from
> unauthorized modifications.
>
> [my comment]
> I don't know how to achieve these, because the DBA (who starts/stops the
> server) can modify and delete server log files without any record.
>
Logging can be setup in a way that it's not even stored on the server
which DBA has access to. DBA can turn off logging (and the plugin)
altogether or change logging config but we'd get the shutdown log when
that happens so 10.2.2 and 10.2.6 will be fulfilled in that case I think.
-- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training &
Services