How To STIG a Database System

  • Article

This post is to provide a little enlightenment to folks who have never STIG'd a database system before and assume that the process is a one-time configuration. It's not. It's not even close.

STIG compliance requires:

  • One or more named Database Administrators (DBA)
  • A named Information Assurance Officer (IAO)
  • An initial system evaluation
  • A Plan of Action and Milestones (POAM) that details how and when deficiencies will be corrected
  • A full set of documentation
  • Periodic compliance activities by the DBA, some as often as daily
  • Periodic compliance activities by the IAO
  • Periodic compliance inspections by auditors
  • Irregular, surprise compliance inspections by auditors

So, you can't STIG anything by yourself. It's a team effort, and it's a permanent, on-going process.

The general process for a DBA STIGing a new system is:

  • Run a compliance-checking tool such as the DISA Security Readiness Review (SRR) script or a 3rd party tool such as Retina.
  • Put all the findings (shortcomings) into a POAM and add dates for when you expect to have each finding remediated or justified.
  • Get the POAM (including schedules) approved by the IAO.
  • Begin addressing the findings based on priority, and either correct them or provide a justification for why it must remain non-compliant.
  • Stick to the POAM schedule for corrections/justifications or get approval for deadline adjustments if needed.
  • Perform all on-going compliance checks, such as daily inspection of all SQL Server error logs, and keep the documentation up-to-date.

Note that many findings listed by the SRR script are Manual Review (MR) findings. This means its something that T-SQL can't evaluate, such as determining whether or not a written System Security Plan exists. The SRR spits out the comprehensive list of MR findings, but in some cases multiple findings can be corrected with a single action, such as creating a written System Security Plan.