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?"
cybersecurity
An umbrella community for all things cybersecurity / infosec. News, research, questions, are all welcome!
Community Rules
- Be kind
- Limit promotional activities
- Non-cybersecurity posts should be redirected to other communities within infosec.pub.
Enjoy!
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?