For anyone interested in compliance and hardening, here’s some links to the DOD/US GOV standards for information systems. This information is available to the public.
Security Technical Implementation Guides (STIGs)
This is a document that has recommended settings, methods, etc to make a product the most secure it can reasonably be. STIGs break things or turn off features people might be accustomed to. You have to do testing and figure out how to either make something work with STIG settings applied, or do exceptions. These are similar to Internet Security (CIS) Benchmarks.
STIG Viewer
The STIG viewer is a Java app that basically makes the list into a checklist where you can track applying settings.
SCAP
Going farther with automation, Security Content Automation Protocol (SCAP) can be used to conduct automated checked against systems to determine compliance with a setting. Install the SCAP tool, load the automated checks into it, and then take the results from SCAP tool and import them into the STIG viewer. It will knock out anything that could be checked automatically. The remaining checks would be things that are manually checked.
Compare
Here’s a good article that compares STIGs and CIS benchmarks: https://nira.com/stig-vs-cis/#:~:text=The Center for Internet Security offers a tool similar to,robust than the STIG tool.
Download STIGs for products: https://public.cyber.mil/stigs/downloads/
STIG Viewer: https://public.cyber.mil/stigs/srg-stig-tools/
Security Content Automation Protocol (SCAP) content: https://public.cyber.mil/stigs/scap/
https://public.cyber.mil/stigs/supplemental-automation-content/
I would be wary of using STIGs as a reference point for good security practices. They are notorious for being poorly-enforced in the real world, and it stems from the fact that they are written too ambiguously. Getting STIG reviewed can have wildly different results just depending on the reviewer’s interpretation of the written text. I’ve seen this first-hand in my job, where we’ve gotten dinged on specific STIGS for code that hasn’t changed in a decade, just because a reviewer decided to interpret a STIG differently than others from the past. And trying to be pro-active about complying with STIG requirements ahead of time always boils down to arguments about “well, what does the STIG MEAN here?”
I hear what you’re saying, you’re not wrong.
I would argue that the technical implementations, the ones that are about a quantified or Boolean evaluation, that’s not the case.
Sure, STIGs can be open to interpretation like any benchmark or compliance standard and are open to the reviewers personal discretion or trends in the industry.
I wouldn’t suggest that stigs are more relevant than CIS, since it’s mostly only used by federal government, but it is something to be aware of and a skill set that’s in demand.
I wouldn’t say cis, or stigs, aren’t a security practice by themselves. Security practices come from implementing good policies and evaluation, and I would suggest that the new cybersecurity framework 2.0 would help inform good security practices.
Have you never found ambiguous standards anywhere else?
