网络安全及信息化 - 评论及随笔

安全加固必须要有可人读的基准文本而不是傻瓜式的黑箱工具

作者：Sender Su  来源：本站原创  发布日期：2024-11-04  最后修改日期：2024-11-04

继续说加固基准。

要讨论加固基准，绕不开 CIS 编制的CIS Benchmarks，因为很长时间内，CIS Benchmarks 是唯一成体系的基础设施加固实践指南。

参照 CIS 编制加固基准的组织过程，国内也需要有类似的组织建立一个社区化的平台，召集和组织志愿者研讨、开发、编写和发布各种加固基准，以及发掘加固基准的深入应用，比如自动化的加固和检查工具等。

而不是现在（就以国产操作系统为例），普遍更时兴的做法：

给系统管理员弄个黑箱工具，“一键加固”。

有必要先提一下 CIS Benchmarks 的编制过程是如何组织的。

CIS Benchmarks 的编制是基于“共识”的指导作用，每项基准均由该主题下的专家组以通过协商获得一致意见的审查过程创建的。

专家组也可称为建立共识的参与者，每位参与者都从各自不同背景的视角提供意见，这些个人背景包括咨询、软件开发、审计和合规、安全研究、运营、政府和法律。

每项 CIS 加固基准都要经过两个阶段的共识审查：

第一阶段发生在加固基准的初始开发阶段。在此阶段，主题专家组召开会议，讨论、创建和测试加固基准的工作草案，在对建议的加固基准内容达成共识之前进行充分的讨论。

第二阶段在加固基准草案发布之后开始。在此阶段，所有由互联网社区提供的反馈都将由共识团队进行审查，确定反馈内容是否纳入加固基准。

由此，经过修改补充的加固基准草案在最终审定后完成并作为正式版本发布。

加固并不仅限于操作系统，但操作系统的加固必然是其他基础软件以至信息系统整体加固的前提，所以本文的出发点是操作系统加固。

在具体讨论之前，有必要先强调加固基准所具有的一些特性：

1）可解释，由网络安全研究理论支撑

2）可对齐，符合多种安全管理框架或合规要求

3）可执行，是具体过程的文字描述

4）可审计，执行结果能在事后查阅比对

所以笔者强调基准文本比黑箱工具更重要，最关键的理由就是：

CIS Benchmarks 可以和 CIS Critical Controls 其中的技术控制措施匹配，并再匹配到其他网络安全管理框架或合规要求。所以，加固基准是网络安全管理框架或合规要求的具体实践，他们之间是强相关的。

国内的合规要求主要就是等级保护。

可以说，国内相当一部分系统管理员都是因为等保测评的强制性而系统地接触并实践信息系统加固这件事。

但通读等保测评的标准就会发现，等保测评的要求是抽象和概念性的，具体到某个基础软件比如操作系统，该设置什么配置项，不可能写在等保的标准要求中。

也即，在标准要求也就是测评项目和具体加固操作之间，需要有系统性的匹配关系。仅此一点，就决定了必须通过文本描述的方式，从人读的角度给出加固基准。

网络安全审计这件事在等保标准里面是很明确要求进行的一项工作，笔者之前也写了不少，比如：

《等级保护的审计管理员究竟如何定位？》

《等级保护的审计管理员责任大吗？》

《甲方需要实施持续的网络安全审计》

系统加固和持续的安全审计是维护合规性状态的重要措施，而网络安全审计的独立性是审计结论是否有效的重中之重。熟悉审计工作的读者都知道，采集审计证据的工具，也需要是独立的。

没有可人读的加固基准文本，就没有开发采集审计证据工具所必须的指引性文件。

尤其是，如果厂家提供的黑箱加固工具，同时被系统管理员和审计管理员使用于加固和审计：

这还审个毛线。

顶多就只能审有没有执行了“一键”，无法落实究竟“一键”的真实结果如何。

所以这不仅没有可审的意义，甚至连这个工具具体干了什么都不一定说得清楚，因为有些国产操作系统厂家的加固工具尚不完善，输出日志内容不齐全或干脆空白。

绝大多数信息系统都是由多个厂商提供的不同组件构成，任何组件都可能会发生版本更新，再叠加上信息系统本身会随着新功能不断增加而滚动更新的特点，信息系统运行环境的复杂性是持续发散不收敛，直至 EOL 为止。

所以，没有经过仔细研究整体环境要求并进行适配设置的“一键式”黑箱工具，加固后导致信息系统运行出错甚至根本运行不起来，是可预期会产生的副作用。

就如 CIS Benchmarks，也强调在应用加固措施之前应先做好评估，否则有可能导致被加固的对象停止服务响应。

不明确的加固指引极容易导致错误的安全配置，而安全配置错误是典型网络安全问题。

著名的 OWASP 组织多次将安全配置错误列入其10大最危险风险清单中：2013年、2017年的清单中该项位于第6位，在2021年发布的当前最新版本清单中提升至第5位。

要解决安全配置错误问题，基于安全基准实施配置并持续审计是最有效的做法。

文档化的安全基准，可以让 DevSecOps 团队自主地把风险缓解和控制措施有计划和条理地分配、集成到信息系统的开发和运营阶段，并通过持续监控，确保实际配置与安全基准或者基于安全基准自定义的规则相一致。

反观一键式的黑箱工具，对 DevSecOps 过程没有任何帮助。

其实，本文只是表明笔者对现状：《国产化替代：操作系统厂商需要加快制订加固基准》感到无奈的态度，这是起因于：《CISecurity.org 已经拒绝中国大陆 IP 地址访问》，而之前收集整理的安全基准及加固工具目录估计最终还是无米之炊：

国产操作系统安全基准及加固工具目录

https://gitee.com/SenderSu/China_OS_Security_Benchmarks

作为知识性的附录，按从底到顶再到面，列举加固措施的六种主要类别如下：

• 操作系统加固

• 数据库加固

• 服务器整体加固

• 信息系统软件加固

• 网络加固

• 端点加固

 

每一类加固措施的主要实践大致包括：

1）操作系统加固

• 配置自动化的补丁更新

• 记录系统日志，定期审查日志记录中的可疑情况

• 角色分离、最小化权限分配

2）数据库加固

• 严控特权用户账户

• 配置和审计特权操作日志

• 加密数据流甚或数据库

• 按需配置数据访问日志

3）服务器整体加固

• 配置固件更新和限制访问固件界面

• 其他基础软件加固（比如中间件服务器）

• 网络访问控制确保为最低权限

• 自动化运维代理软件的访问控制

• 物理隔离和安全托管

4）信息系统软件加固

• 贯彻以设计促安全的开发原则

• 强制实施 MFA 身份验证，禁止默认密码

• 特权角色分离和最小化授权

• 实施安全编码实践并定期进行安全代码审查

 5）网络加固

• 严控设备的特权用户账号

• 设备特权账号角色分离和最小化授权

• 定期巡检和升级网络设备固件

• 配置和维持安全设备自身软件和防护规则的自动更新

• 按业务要求合理配置安全设备的规则并进行有效性测试

• 确保设备的日志得到完整记录并定期审计异常情况

6）端点加固

• 控制特权账户的使用

• 精简不必要的端点服务

• 限制对端点的远程访问

• 配置记录特权操作日志并定期审计异常情况

• 强制实施本地存储加密

本栏目相关

本站微信订阅号：

本页网址二维码：