Thanks for the reply Laurenz. Of course the first thing that I thought of to prevent man-in-the-middle was SSL. However, I also like to try to address the issue in a way that seems to get at what they are intending. It seemed to me that they wanted to do some configuration within the database related to session IDs.
Regarding what is meant by "security configuration", I couldn't say for sure. These guides are very much open to interpretation. In any case your answers are helpful. Thanks again!On Fri, Feb 12, 2016 at 3:02 AM, Albe Laurenz <laurenz.albe@xxxxxxxxxx> wrote:
Lesley Kimmel wrote:
> I'm working to secure a PosgreSQL database according to a DoD security guide. It has many very generic
> requirements that get more toward the internal architecture of the system that wouldn't be apparent to
> the average admin. I was hoping someone might have some insight to the following requirements:
>
>
> a) The DBMS must maintain the authenticity of communications sessions by guarding against man-in-the-
> middle attacks that guess at Session ID values.
You can have that if you use SSL encryption which is available in PostgreSQL:
http://www.postgresql.org/docs/current/static/ssl-tcp.html
It uses that widely-used OpenSSL software, so an encrypted database connection
is as safe from man-in-the-middle attacks as OpenSSL is.
> b) Check DBMS settings and vendor documentation to verify the DBMS properly handles transactions in
> the event of a system failure. The consistent state must include a security configuration that is at
> least as restrictive as before the system failure. This must be guaranteed.
I don't understand what is meant by "security configuration" here.
Is that defined somewhere?
PostgreSQL handles system failures well, it uses a "Write Ahead Log" (WAL) to record
transactions as they get committed. In the case of a system failure, the
recovery process starts at the latest checkpoint (known consistent state) before the
failure and exactly replays all WAL logged committed transactions up to the point of
the crash:
http://www.postgresql.org/docs/current/static/wal-intro.html
After crash recovery, the database is in the same state as it was after the last
successful transaction.
The (unrecovered) database files of a crashed database are no less secure than
any file system backup is.
Yours,
Laurenz Albe
