Security benchmark
A published, versioned list of system controls that a machine can be measured against. The named ones in the founding corpus, all cited by practical-linux-hardening-guide:
| Benchmark | Publisher | Character |
|---|---|---|
| CIS Benchmarks (v2.1.1) | Center for Internet Security | consensus baseline, per-platform |
| STIG (RHEL 7) | US DoD / DISA | stricter, mandated for defense systems |
| NIST standards | US NIST | control catalogues underneath much of the rest |
| PCI-DSS | payment card industry | scoped to cardholder-data environments |
| OpenSCAP | open-source implementation | the checker — automates auditing against the above |
Compliance is a measurement, not a state
The reason this is its own concept and not a footnote on system-hardening: a benchmark converts security from an argument into a score, and everything good and bad about the practice follows from that. Good, because drift becomes visible and an auditor and an engineer can look at the same number. Bad, because the number is what gets managed. Controls that are hard to measure fall out of scope, and “compliant” starts to mean “passed the checker” rather than “hard to break into” — a host can satisfy every line of CIS and still be owned through the web application it hosts, which no host benchmark inspects.
Versions matter and get stale. CIS v2.1.1 against RHEL 7 is a specific claim about a specific platform generation; both the benchmark and the OS move. Treat any hardening document’s compliance claims as dated snapshots, the same way this hub treats pricing and rankings.
The gap this corpus can’t yet see
Nothing here evaluates whether benchmark-compliant systems actually get compromised less often. That would be the measurement that matters, and neither the guide nor the benchmarks’ own publishers supply it in the founding sources. Worth an eye out for incident data that tests the assumption rather than restating it.
Related
system-hardening · practical-linux-hardening-guide · defensive-security