The Defense Information Systems Agency (DISA) is the entity responsible for maintaining the security posture of the Department of Defense (DoD) IT infrastructure. As you can imagine, this is quite an undertaking when you consider the number of IT assets used by the DoD. One of the ways DISA accomplishes this task is by developing and using what they call Security Technical Implementation Guides, or “STIGs.” These requirements encompass two areas – policy requirements for security programs and best practices for Information Assurance (IA)-enabled applications. I will focus more on the application best practices.
Background
Basically, STIGs are nothing more than alternate configurations that make commonly used applications more secure. All DoD IT assets must meet STIG compliance in some fashion before they are allowed to operate on DoD networks. The purpose of STIGs are obvious; default configurations for many applications are inadequate in terms of security, and therefore DISA felt that developing a security standard for these applications would allow various DoD agencies to utilize the same standard – or STIG – across all application instances that exist. Continuous audits using automated tools are routinely conducted and reported back to DISA Field Security Operations (FSO) to assess compliance/security posture.
STIG Versions
STIGs exist for a variety of software packages including Operating Systems, Database Applications, Open Source Software, Network Devices, Wireless Devices, Virtual Software, and, as the list continues to grow, now even include Mobile Operating Systems. Unfortunately, interpreting a STIG and how it applies to your specific IT environment can be confusing. Fortunately, the team at Segue has several years’ experience working with a variety of STIGs and can quickly review and asses new requirements and how they may or may not impact your IT operations. After this, the implementation of new STIGs becomes less risky.
STIG requirements originally came in manual form, which was essentially a downloadable PDF checklist with instructions for how to configure various aspects of an application and verify compliance. For example, a Windows Server STIG contained hundreds of individual checks, with each check given an ID number and categorized with a severity ID. CAT 1 was the most severe, and CAT 3 the least. This was a daunting process that took too much time to implement and, due to the manual nature, was not always implemented and reported properly. Eventually, DISA FSO developed the Gold Disk to eliminate this problem. The Gold Disk is essentially a scan tool that automates the verification of STIG compliance by scanning an asset, reporting results to the system administrator, and providing remediation instructions for each flaw found. This was a step in the right direction and the tool has been around for a number of years now.
The newest automated standard that DISA uses is SCAP (Security Content Automation Protocol), developed by the National Institute of Standards and Technology (NIST), which is currently the benchmark protocol widely used in the information assurance world that allows for more accurate reporting of STIG compliance. Please note that not all application STIGs have a SCAP compliant benchmark associated with them. This means that verification of compliance must still be done manually. As vendors continue adopting SCAP, this will eventually change.
STIG Implementation
The DISA FSO releases updated STIGS periodically (available @ DISA.MIL), so ensuring that you have the latest version is the first step in using any STIG. System administrators must then decide on a SCAP-compliant scanner to use. Three common scanners that are SCAP compliant are MacAfee’s Policy Auditor, Retina Network Security Scanner, and the SCAP Content Checker (developed by DISA FSO). Finally, the applicable STIG (in SCAP format) will need to be downloaded and loaded into your SCAP tool of choice. To continuously asses STIG compliance, I recommend that your security program include procedures to scan all IT assets monthly to see if any configurations have changed or that new STIG checks are in place. The SCAP Content Checker actually reports the security posture as a percentage for quick assessment. Anything above 90% is considered secure. Obviously, mission operations vary among agencies, so it is not feasible to implement every STIG requirement without impacting your IT system’s overall functionality. In other words, all IT systems will have some number of vulnerabilities that cannot be fixed due to its role (web server, database server, etc.).
DISA continues to improve the tools/resources available for DoD personnel to harden their IT assets and improve their overall security programs. For those in the Federal Government world and even the private sector, NSA has developed their own set of security guides similar to DISA’s STIGs.
The overall goal is to continue developing STIG content as the number of applications used by the DoD and the Federal Government continues to grow. As vendor adoption of SCAP becomes more widespread, this process will eventually become easier.