If you’re a federal IT pro of any sort, security is a high priority. In fact, the Defense Information Systems Agency (DISA) has a set of security regulations to provide a baseline standard for Department of Defense (DoD) networks, systems, and applications. DISA enforces hundreds of pages of detailed rules IT pros must follow to properly secure or “harden” the government computer infrastructure and systems.
If you’re responsible for a DoD network, these STIGs (Security Technical Implementation Guides) will help guide your network management, configuration, and monitoring strategies across access control, operating systems, applications, network devices, and even physical security. DISA releases new STIGs at least once every quarter. This aggressive release schedule is designed to catch as many recently patched vulnerabilities as possible and ensure a secure baseline for the component in operation.
Such detailed security guidelines are all good and well, but here’s the challenge: STIGs can present tens of thousands of rules across even the smallest agency environment. How can a federal IT pro get any sleep when so many requirements must be met on a regular basis?
The answer is automation.
First, let’s revisit STIG basics. The DoD developed STIGs, or hardening guidelines, for the most common components comprising agency systems. As of this writing, there are nearly 600 STIGs, each of which may comprise hundreds of security checks specific to the component being hardened. Agencies spend hundreds of millions of dollars annually on compliance costs when hardening those system components. As an example, a single server can cost $10,000 annually just for basic security tasks: STIG compliance, patch compliance, and system documentation.
A second challenge, in addition to the cost of meeting STIG requirements, is the number of requirements needing to be met. Agency systems may be made up of many components, each requiring STIG compliance. Remember, there are nearly 600 different versions of STIGs, some unique to a component, some targeting specific release versions of the component.
Who has the time to meet all these requirements? Wouldn’t it be great if automation could step in and solve the cost challenge while saving time by building repeatable processes?
That’s precisely what automation does:
- Automated tools for Windows servers let you test STIG compliance on a single instance, test all changes until approved, then push out those changes to other Windows servers via Group Policy Object (GPO) automation. Automated tools for Linux permit a similar outcome: test all changes due to STIG compliance and then push all approved changes as a tested, secure baseline out to other servers
- Automated network monitoring tools digest system logs in real time, creating alerts based on predefined rules, and help meet STIG requirements for Continuous Monitoring (CM) security controls while providing the defense team with actionable response guidance
- Automated device configuration tools can continuously monitor device configurations for setting changes across geographically dispersed networks, enforcing compliance with security policies and making configuration backups useful in system restoration efforts after an outage
- Automation also addresses readability. STIGs are released in XML format—not the most human-readable form for delivering data. Some newer automated STIG compliance tools generate easy-to-read compliance reports useful for both security management and technical support teams
If you’re a federal IT pro within a DoD agency, you have an increasing number of requirements to satisfy. Let automation take some of the heavy lifting when it comes to compliance, so you and your team can focus on more pressing tasks.
