References: 
 <CALhHtcCHiUUJ0qPO=5CU+n7gPry2vybZ+3gqxrE4_ctB2PK5PQ@mail.gmail.com>
User-agent: mu4e 1.5.8; emacs 27.1.91
From: Tim Cross <theophilusx@gmail.com>
To: pgsql-admin@lists.postgresql.org
Subject: Re: Audit preparation list
Date: Mon, 15 Feb 2021 19:31:15 +1100
In-reply-to: 
 <CALhHtcCHiUUJ0qPO=5CU+n7gPry2vybZ+3gqxrE4_ctB2PK5PQ@mail.gmail.com>
Message-ID: <87eehhbsrs.fsf@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk


Yambu <hyambu@gmail.com> writes:

> Hello
>
> If auditing on our postgres instance is to be done , what are the things we
> should make sure that we fix or correct to make sure we pass the audit?

First thing to note is that most decent audits are not a binary
pass/fail type situation. Auditors will almost always find someting
which could be improved. Auditing is a risk management process and will
typically report risks on some scale, such as high, medium or low. These
values are typically determined by a combination of likelihood,
impact and controls (mitigation).

Doing things to 'pass' the audit is the wrong approach. An audit is a
good opportunity for an external review of your policies, procedures and
systems. If changes need to be made to 'pass' the audit, they are likely
changes which should be done to protect the business.

The sort of information an auditor will require depends a lot on the
type of audit and the type of business being audited. For example, the
priorities and risks in a medical clinic are very different to those in
a credit processing centre. Without more details about the type of
business and type of audit, it is difficult to provide any precise
information. Generally, the auditor will provide some details on what
they will be wanting to see prior to the audit.

One thing auditors typically want to see are your policies and
procedures. Auditors hate 'ad hoc' processes - processes which are not
documented and where it assumed all those executing the process just
'know' what to do. They also want to see that policies and processes are
reviewed and updated regularly.

You might think that as a DBA or a developer, you don't need to worry
about policies and procedures. This is probably incorrect. Typically,
there will be policies and procedures covering things like change
management (who, what when), access controls, disaster recovery and business continuity
plans (backup, restore, what to do in a disaster and what to do to keep
the business running while the disaster recovery process executes -
noting that 'disaster' is not just flood, fire, etc. A disaster is
anything which would prevent the business from operating for an extended
period of time and can also include things like cyber attack, data
breaches etc), monitoring and application of security patches etc.

The first audit, which this sounds like it might be, should really be
seen as an information gather process that will identify areas of
policy and procedures which can be improved. The more important audit is
the second and later audits, which will show how much progress has been
made towards achieving those improvements.

Note also that it is common for the auditor to get things incorrect
initially. In good audits, there will be a review stage where you are
given the opportunity to clarify, correct and provide additional context
for the initial findings.

The biggest challenge with an audit is providing the information with
sufficient detail to assist the auditory to understand matters, but not
with so much information they become overwhelmed or draw misleading
conclusions. Often, volunteering information can be a bad idea. Provide
everything asked for and provide it as clearly and concisely as
possible, but don't try to guess at what they want and add additional
information which has not been requested.

Of course, some auditors are better than others. An audit can be a
stressful experience. With luck, you will get an experienced and well
trained professional. Hopefully, your management isn't trying to save
money by going cheap!

--
Tim Cross