Fortunately, NIST and other security frameworks point to either of two publicly available configuration
standards, the Security Technical Implementation Guides (STIGs) or the CIS^ Benchmarks.
STIGs and CIS
The STIGs, published by the Defense Information Systems Agency, a support agency for the Department
of Defense (DoD), outline hundreds of pages of detailed rules that must be followed to properly secure
or “harden” the DoD computing infrastructure.
Although STIGs are mandatory for DoD agencies, any civilian agency and even commercial companies
are welcome to use the STIGs.
For most commercial organizations, however, CIS is the security standard of choice. Originally formed
in 2000, CIS^ Center for Internet Security, Inc. is a nonprofit organization with a mission is to “identify,
develop, validate, promote, and sustain best practice solutions for cyber defense.”
CIS employs a closed crowdsourcing model to identify and refine effective security measures, with
individuals developing recommendations that are shared with the community for evaluation through a
consensus decision-making process.
“Most organizations need a starting point that works today and that they can explain in simple language
to their board on what needs to be done, and that is really where the CIS Benchmarks and CIS Critical
Security Controls provide is that starting point,” says Curtis W. Dukes, Executive Vice President &
General Manager of the Best Practices and Automation Group at CIS.
Although there are minor differences between the STIGs and CIS Benchmarks, the two overlap and are
pretty much interchangeable, says Brian Hajost of SteelCloud, an expert in automated security control
compliance.
However, implementation of either STIG or CIS Benchmarks can be a challenge if the process isn’t
automated in some manner, due to the disparate requirements and configurations of networks.
Changes to security settings can also have unintended consequences. When the configuration settings
of an application are re-configured, it can cause the installed application to “break,” meaning it won’t
install and/or run properly.
“If the same security policies and configurations could be implemented on all systems, compliance would
be a rather easy exercise,” explains Hajost. “All applications respond to security policies differently.
Because configuration settings have the potential to ‘break’ applications, the settings for each system,
therefore, have to be uniquely adapted or tuned to each application in the operational environment.”