The simplest way to complete a DISA Secure Technical Implementation Guide (STIG) review is to start at the beginning of the checklist and work through it, one control item at a time. As you read each control, the information will be broken down into several distinct areas: metadata, content, and findings.
Each control has metadata associated with it which identifies it uniquely. This metadata is stored in the following fields, all of which are pretty much self-explanitory:
- Rule Title
- Rule Name
- Rule Version
- Rule ID
- Vulnerability ID
Each control also has a set of content fields describing the details of the potential vulnerability:
- Discussion – A high level description of the potential vulnerability and why it is of concern.
- Check Content – An explanation of how to identify the presence of the vulnerability.
- Fix Text – An explanation of how to correct the vulnerability, if it is present in your system.
Lastly, each control in a STIG checklist has several fields to contain your findings.
- Status – Indicates whether the control is not applicable to your system, open (i.e. the vulnerability was found), not a finding (i.e. the vulnerability was not found, or has not yet been reviewed.
- Comments – A general text field that should contain any general observations or feedback on the control.
- Details – The specific output of any script or evaluation action specified in the Check Content field.
- Severity Override – Allows you to redefine the severity of a particular control for your system, based on your specific situation.
- Severity Override Justification – A text field which contains the justification for the severity override.
Using common sense, work your way through the checklist, completing each test in the Check Content sections. When your system fails a test, attempt to correct the result with the instructions in the Fix Text. In cases where the fix cannot be applied or requires additional work – like creating missing documentation – then make a note in the comments to that effect. If a fix can be partially applied, or there are additional circumstances that make the results moot, note that as well; in those cases you may want to enter a specific mitigation and lower the severity of the control with the Severity Override fields.
Always remember that your goal is not necessarily to achieve a perfect compliance result. A perfect score is almost impossible with most operational systems. The STIG checklist will help you complete your lockdown to the best of your ability while highlighting areas for additional attention. That attention may be in the form of administrators or developers implementing required fixes, or it could be in the form of management (and by extension Information Assurance) formally accepting the risk of a failed control.
My experience has been that failed CAT I controls are expected to be corrected before a system can receive accreditation and certification; CAT II controls may not require immediate attention but still need a definitive plan and schedule for implementation of the fix (i.e. a Plan Of Action & Mitigation, or POA&M); CAT III control implementation may often be delayed without a POA&M, if necessary. In general, no system will attain certification or be allowed to remain on the network with outstanding CAT I findings – they must be resolved immediately or mitigated down to CAT II with a reasonable plan for short-term correction.
When your review is complete, be prepared to present the results to management. You should expect that you will be required to explain or defend any documented mitigations or failed controls.
In the event that your system is actually audited by an official inspection team, there are a couple of things to keep in mind. The first is that the inspector will have precisely zero interest in any STIG checklist you have already completed. The inspector will be there to work through any checklists from top to bottom, again. With the inspector, you will be required to run every check script, produce every required document, and answer any question that may come up. If you have already worked through the checklist yourself and have it for a reference, you will be prepared to answer all of their questions, to provide documentation immediately, and generally make life easier both for them and for you.
The second thing to consider is that inspectors almost never travel alone. If you work with a large system that is made up of many servers or applications, you may have to provide administrators that can work with a whole team of inspectors covering several servers or STIGs simultaneously. It is important that everyone involved knows how to work through the STIG process, and where to get answers for specific STIGs. Inspections almost never happen by surprise – in most cases you will have weeks or months to prepare, so use the time wisely.