CIS Benchmarks 新增 STIG 基准文档 及 202511 更新
距离上一次收集 CIS Benchmarks 的 2025年5月已经过去了半年。
半年内 CIS Benchmarks 的变化相当不少（而且现在可以直接访问了），但最显著的变化在于下载页面一拖到底，会发现多了一大堆带有 STIG 缩写词的基准文档。
所以本篇主要是介绍新增的 CIS STIG 基准文档和已有的 CIS Benchmarks 基准文档的基本区别。至于 CIS Benchmarks 更新了什么，笔者就不啰嗦地堆内容了。
笔者：国际注册信息系统审计师、软考系统分析师、软件工程硕士
STIG 是 Secure Technical Implementation Guide 的缩写，即“安全技术实施指南”。
STIG 由美国国防信息系统局（DISA）为美国国防部（DoD）开发。它们主要面向终端环境并以操作系统为主要对象，为包括 Windows 和 Linux 在内的多种操作系统提供了一套指导方针，使用户能通过这些指南文档实现适用于不同的运行环境下可重复且安全的配置，以保护组织资产免受网络安全威胁。
由于指导具有规定性，STIG 基准测试加强了安全控制，以减少错误配置成为可被利用漏洞的可能性，并加强整体安全态势。
对应地， CIS Benchmark 基准是社区性质的安全配置标准，支持比 STIG 广泛得多的软件产品及云计算平台，且可匹配符合比如 PCI DSS、HIPAA 等行业标准的条款要求，还可以映射到美国国家标准 NIST 框架的具体要求，比如 NIST CSF 和 NIST 800-53。
由于 CIS Benchmark 同时具备可人读和可机器设置/检查的特点，在进行网络安全审计时相当有用。
必须反复强调的是，一套定义清晰、实现且广泛部署的基线配置通常能提升环境的整体安全性。不过，它们并非万无一失。即使实施得当，仍可能需要额外努力才能真正确保系统安全。
两者的本质区别在于其来源。STIG 的来源是美国军方，所以在基线的设计上具有强制性的出发点。而 CIS Benchmark 源自社区，所以它的设计是可伸缩的，对应 CIS Controls 的3种不同控制等级，还可以映射到前述的各类行业标准和美国国家标准。
如果从面向的产品/平台来看，很显然 STIG 是 CIS Benchmarks 的子集。CIS Benchmarks 越来越显得包罗万有，面向的不仅是纯粹意义上的软件，还包括 SaaS 服务平台以及封装在硬件内的固件。
对此，DISA通过发布 SRG 即 Security Requirement Guideline 安全需求指南去覆盖更广泛的产品或服务作为补充，但在内容上就并不如 STIG 或 CIS Benchmarks 那么具体。
不过也有些反例，比如 IBM WebSphere、Red Hat JBOSS 都有 STIG 内容，但没有对应的 CIS Benchmarks。
笔者写到这里不禁想起，WebSphere 和 JBOSS 都曾经是攻防演练的重灾区，软件本身的安全缺陷，STIG 执行得再到位也依然无法防御，所以还是得从根本上实现 Secure By Design。
STIG 是将配置要求转换为 SCAP 规范所定义的 XCCDF 格式的规则，可以利用支持 XCCDF 的工具查看、设置和评估。
已有开源或商业的此类工具。开源工具典型如微软开发的 PowerSTIG，或者 RedHat 开发的 Ansible Role for DISA STIG for RHEL。
CIS Benchmark 方面是CIS提供的工具 CIS-CAT，Lite版本免费但仅面向CIS Benchmark，Pro版本支持STIG。
对于中小企业而言，人工方式对照文档进行设置和检查已经足够，但对于大型企业，通过自动化工具实现基线配置和持续审计是必要的行动。
这个话题放到本文的环境属实有点特殊性。
在国内，如果抛开这些基准的来源，从客观角度看，基于企业的行业属性、IT基础设施、人力资源和预算等要素，在充分理解这些指引的基础上，无论是 STIG 抑或 CIS Benchmark，都可以因应自身的需要而采纳其指引。
始终国内依然大量部署有 Windows 或其它非国产操作系统，要进行加固，此类指引无疑是恰当的方法。
对于部署的是国产操作系统，基于安全防御的共通性，以及 Linux 开放源码体系，STIG 或者 CIS Benchmark 均可以学习其设计理念并参考使用其设置要求。而且，前文提及的 SRG 文件，也可以用于对尚未定义安全基准的新产品或平台自行开发安全基准配置时提供参考。
不过，就如做等保测评一定不可能满分一样，无论使用 STIG 抑或 CIS Benchmark，也一定不可能获得一个满分且能按预期正常运行的系统。
所以在使用前，正确理解、采纳应用和测试确认的过程是必须的，并通过这个过程，对失分点进行权衡和开发属于自己的风险缓解措施。
说回等保测评其实也是同样道理。只是现实中很多企业组织对待等保测评是典型的60分万岁心态，对失分项的处置经常是听之任之，没有针对性地制订风险缓解措施和实施持续监控。
这个问题实际是大多数国产基础软件用户企业所遇到的共同问题。但是，距离笔者去年呼吁国产操作系统厂商应共同制订可人读的加固基准已经一年，国内厂商依然鲜有提供免费且原生的基线配置和持续审计自动化工具。
即使最早实现了加入 OpenSCAP 完成适配的 Anolis OS，其 security-benchmark 项目也只有偶尔的更新，并未释出新版本。
很明显，就如笔者一直的观察，国产操作系统的厂商依然还是采取站在巨人的肩膀上的方法：
反正外面有人做了，自己拿来即可。
至于其他国产基础软件比如必然要死掉一大批的国产数据库，大部分更是连安全文档都没写好，加固基准？影子都没有。
~ 完 ~
文中内部链接：
CISecurity.org 已经拒绝中国大陆 IP 地址访问
没有遵循 Secure by Design 而建的系统，整改就是噩梦
参考链接：
CIS Benchmarks
Secure By Design
PowerSTIG
Ansible Role for DISA STIG for RHEL
CIS-CAT Lite
Anolis OS Security Benchmark
题图是十二门徒石其中位于看台左边的，为笔者自行拍摄并经AI扩图（微信公众号这940x400的尺寸要求实在怪异）。
点赞和转发都是免费的↓
本站微信订阅号：
本页网址二维码：