How To STIG a Database System

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.