First published on TECHNET on Jan 18, 2011
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.
