Beyond compliance: DISA STIGs’ role in cybersecurity

If you look at any best practice guidance, regulation or standards around effective IT security out on the market today, you will see that it advises organizations to ensure their computing systems are configured as securely as possible and monitored for changes. 

To many, the Security Technical Implementation Guides from the Defense Information Systems Agency  represent a questionable exercise in compliance.  Yet the STIGs play a real and important role in helping prevent cyber attacks for both the federal government and commercial organizations.

The DISA STIGs comprise a library of documents that explain very specifically how computing devices should be configured to maximize security.  Today, there are over 400 STIGs, each describing how a specific application, operating system, network device or smartphone should be configured.  The Windows 2008 STIG, for example, defines the sort of message users should receive when they log into their systems, the minimum password length allowed for any user and how often users must change their passwords.

But the STIGs are just one standard that organizations can use to secure their systems.  While the Department of Defense is required to follow the STIGs (with certain exceptions), there are other standards such as the Center for Internet Security (CIS) Standards and U.S. Government Configuration Baseline (USGCB) that are also available. 

Following a secure standard, whether it be one of the ones mentioned above, or one more suited for your organization, is critical in getting rid of the easy vectors hackers use to launch attacks.  The press is filled with story after story about successful attacks that leveraged system misconfigurations.  One such attack at MBIA, the nation’s largest bond insurer, was perpetrated due to a misconfiguration on a company server. 

Implementing secure configurations are a no-brainer for many reasons -- one of the biggest is that  you take the target off your back, as your organization no longer represents the easiest score.  If there are countless others that haven’t bothered  to  implement basic security standards, why would a hacker spend time on someone who has?   It's a cyber-spin on the old saying:  You don’t need to outrun the bear if you can outrun the person you next to you.

Fortunately, there is probably a good set of standards publicly available for any kind of organization.  By looking at the various standards, you can probably adopt one to suit your specific needs. And keep in mind that nobody is going to be able to follow every standard 100 percent.  Certain exceptions can be made, so long as those exceptions can be justified and the risk understood and assumed. 

Probably the hardest part about implementing a standard such as a STIG is knowing how well that standard is being followed at any given point.  Networks naturally change all the time, and it’s the job of the IT security team to know if any of the changes have impacted the organization’s security posture.  So the ability to monitor systems for continued adherence with a standard is just as important as having one to begin with. 

What makes this part so challenging is that you need a tool to translate the configuration of a system, into a quantifiable assessment against the standard.  Knowing that the minimum password length is 10 doesn’t do the IT security team any good unless they know that the actual configuration is less than the predefined standard, representing a security risk. And this assessment needs to take place continuously.  This mapping of the configuration against a standard continuously is the great challenge being faced by many today. 

In order for a tool to automatically determine the compliance level of networked systems against the STIGs, three things must occur:

• The tool must know the configuration of the systems on the network.
• The tool must know what the compliance standard should be.
• The the tool must be able to match the actual configuration against the compliance standard and report the deltas.  

Tools exist today that automate this capability, making this part of the process much easier.  

Getting a system’s configuration can be easier said than done, however.  While there are a great many tools out there to collect a system’s configurations, what you’ll find more often than not is that many tools are agent-based, meaning they rely on agents deployed on endpoints to collect the data.  That means you must go through the pain of deploying agents on systems.  Additionally, agent-based solutions will do nothing for systems where you can’t deploy agents, such as in medical devices, switches, routers, firewalls, etc. If you want to monitor those systems, you’ll need an agentless approach.  But again, just collecting the data is a third of the battle.  

If a tool is going to translate that configuration data into useful compliance data, it needs to have an internal database of the STIGs.  That means the tool must know what the STIGs are expecting so it can map the actual configuration accordingly.  If you want to automate the STIG checks, look for a tool that will have a large database of STIGs that covers as many of your systems as possible.  

Finally, success depends on getting useful compliance information out of the system.  This can be done by way of static reports that show a list of systems out of compliance with an explanation as to why. You can also employ a dashboard that lets a user drill down into compliance details, or alerts that notify IT managers when devices are no longer compliant or drop below a certain threshold of compliance.

Automating STIG compliance can help government IT managers cut the amount of work required for manual checks, give them a continuous view of compliance across the enterprise – and get the target off their backs.