从攻防演练想到的：如果信息系统原生就有网络安全功能
本篇属于专业领域的随想，部分源自自己过往的软件工程过程实践，其它则是网络安全与信息系统如何相互支撑实现的想法。
笔者：国际认证信息系统审计师、软考系统分析师、软件工程硕士
攻防演练靶标是甲方内部的信息系统。网络安全三同步要求，信息系统和网络安全要同步规划、同步建设和同步使用。但到了具体实践，信息系统的建设过程也就是软件工程过程的分析设计实现三部曲，和网络安全依然存在隔阂。
软件工程相关理论体系发展了几十年，已经非常完整和全面，可以说只有没实施好的项目，没有理论覆盖不到的细分领域。但在网络安全角度看，以设计促安全（Secure By Design）的理念，尚未能与软件工程过程密切结合。
笔者认为，以设计促安全在信息系统的具体建设上，需要开发商能理解网络安全合规要求，先于甲方提出便已设计和实现网络安全管理相关功能。
这同样是信息系统审计所要求的：控制措施需要与信息系统直接集成，以确保控制措施的有效性。
所以我就从用户密码管理、日志管理、授权管理、环境管理和软件供应链管理五个方面设想了一下。?
随着等级保护的推行，信息系统大多都按等保要求对用户密码管理功能进行了必要的改造。但必要的改造并不等于全面改造，更多地只是在应付而已。
从真正有效地做好用户密码管理出发，有必要在信息系统实现以下用户密码管理相关的安全功能：
信息系统应该为每个新用户都创建互不相同的强密码作为默认密码。但实际情况多是创建新用户时信息系统统一给相同的弱密码，导致系统管理员要督促用户更改密码，如果漏改其后果已经不用我说了。
很多信息系统默认的用户密码规则刚好满足等保要求，但从强度上看仍然存在不足。某些信息系统甚至不具备可调整加强用户密码规则的设置。
究其原因，除了应付之外，还包括试图避免在信息系统的部署阶段，用户因为信息系统对密码的要求太复杂而引起的反感，影响部署和验收。
但这应该是甲方网络安全管理责任部门负责的用户教育工作。
具体功能设计，可参考我上一篇公众号文章内容：
创建密码时仅按强度规则检查强度，没有考虑更广泛的比如已泄露密码的排查功能。
具体功能设计同样是参考我上一篇公众号文章内容，在信息系统中实现和 HIBP 这样的密码泄露检查服务对接，在用户设置密码的同时检查密码是否曾经存在于已泄露密码的范围内并拦阻用户设置。
具体功能设计，全部在我上上一篇公众号文章中：
如果信息系统自带了弱密码排查功能，那可以100%肯定非常有用。
但就我所知，目前没有哪一个信息系统做了这个功能。如果读者知道哪个厂商的什么系统有这个功能，又或者自己做的系统已经实现了这个功能，欢迎留言告诉我。
日志有如记叙文，时间地点人物事情摆流水账而已。只是细节足够详尽的流水账也不是容易写的。我之前曾就日志这个话题写了不少文章，例如：
可以用“日志”作为关键字在本公众号/网站内搜索。
如果信息系统的日志不足以完整描述甚至复现用户操作过程，安全人员就只能靠浩如烟海的中间件日志甚至数据库 SQL 日志进行异常分析和排查入侵。但是：
如果安全人员不了解业务，不了解信息系统内的业务逻辑，分析这些日志就等于看天书。
笔者使用 MySQL 和 MariaDB 加起来二十年，一直都启用 General Log 日志功能，把数据库输出的 SQL 日志配合到自己开发的业务信息系统日志，可以清晰地还原和观察用户的业务操作过程，从中分析出异常情况。
相信懂行的读者看到这里会有大量的想法，还会发散到关于 Binary Log，Audit Log 甚至 SELinux等，我另外找个时间会再写写。
但我这种做法不是大多数甲乙方能配合实现的事情，更多地只能是甲方内部开发才能实现。因为输出日志导致的性能压力、日志内容的解析和格式化、和业务逻辑的联动分析等等都是事，能配合到这个程度的乙方基本上就是甲方自己了。
所以，综合上述情况，信息系统本身能直接提供完整、详细的日志是完全有必要的：
用户的登录日志是最基本的日志了。典型地，登录时间，IP，用户名称这老三样都有，但缺失的是和用户环境有关的完整信息。举个例子是比如缺失了记录用户浏览器的 User Agent String（以下简称 Agent）。
Agent 虽然可以伪造，但大多数攻击者并不会频繁修改自己的 Agent。而且，如果用户某时点的 Agent 和他平时的 Agent 不同，尤其是不具备逻辑关系，这就有可能是出现了身份盗用入侵的情况。
什么逻辑关系？比如用户长期用 Firefox，在某个三更半夜的时点改用 Microsoft Edge 还重度操作，这就很可疑了。
需要指出的是 Agent 只是用户环境其中的一个参数，完整记录还需要有其他信息，而且还会有其他因素影响，比如用户 IP 就可能会受到反向代理、防篡改设备等影响。这里不详细说了。
操作内容就是记叙文的“事情”了。用户登录后，进入了什么功能，执行了什么操作，增删改查了哪项数据（记录主键），这些信息如果有被日志记录，且相比中间件日志、数据库日志能更适合阅读，那就可以还原出用户操作过程的整体轮廓。
结合用户授权情况，就可以进行异常排查。
如果甲方已经实施了数据分类分级保护，且实施到了业务数据而不只是停留在人员信息，那么信息系统能否利用数据分类分级信息对重要和核心数据的更改实现更加详细的日志记录？
尤其是，能否记录到重要和核心数据更改前和更改后的情况，支持可回溯的数据变更审计？
围绕日志本身，信息系统如果提供了足够丰富的管理操作功能，包括基本的日志滚动、备份、统计、分析、异常排查等，那就能一定程度上省下系统管理员自己设计的各种因地制宜措施，并充分发挥日志的作用。
比如，能否统计出哪个用户在什么时间范围访问了哪些重要或核心数据的清单？
有兴趣可以看看笔者在 2008 年就已经自行开发实现的数据分类分级和异常排查：
信息系统能否直接把日志通过 SYSLOG 协议发送给日志机？其实这一点都不难，也只是做不做而已。
但反过来要日志机去采集信息系统日志，这就真的是勉为其难。实施起来，甲方人员不想碰，乙方人员叫苦不迭。
RBAC 相信专业读者都耳熟能详了吧，但基于 RBAC 深入做授权管理，基本上不存在的，甚至有些信息系统的开发人员连授权矩阵都不懂，这就难保信息系统中会出现授权漏洞－－甲方自己内部管理混乱的除外。
那么，信息系统有否提供和授权相关的安全管理功能，各位信息系统管理员是否全靠EXCEL表手工进行分析排查，或者反正没辙了于是高高挂起呢？
简单说就是某个用户拥有不应该属于其实际承担的角色的授权。
对于一些死扣 RBAC 做授权管理的信息系统，这种情况会表现为信息系统内存在大量随意定义的、权限极少的角色，然后某些用户拥有大量的角色。对于另外一些授权机制相对灵活的信息系统，通常表现为用户的权限清单未能呈现为多个角色的合集。
这些情况都不一定是不允许的：取决于甲方自己内部管理条块化是否足够清晰。
但信息系统的授权管理，需要能直接地反馈出此类情况。
数据分类分级又来了：能访问到重要或核心数据的权限，就应该归类为敏感授权。
信息系统对敏感授权应该有专门的管理能力，比如能汇总给出具有该类授权的用户清单，以及批量撤销授权等。
矛盾授权这个概念基本上没人提，因为这是和业务逻辑紧密关联的，脱离业务就无从谈起。
但从业务角度，这比数据分类分级的敏感授权更重要。数据分类分级引申出来的敏感授权排查目的依然是数据资产保护，而矛盾授权却是直接颠覆了业务逻辑，皮之不存毛将焉附。
什么叫矛盾授权？
比如某用户拥有不相容的岗位角色和授权，违反了职责分离这一基本的内控要求，也没有必要的授权文件支撑这一情况，这要么是被外部入侵篡改，要么就是内部存在舞弊，都是必须引起高度警惕的。
信息系统与其部署运行的环境形成了一个整体，这是信息系统审计的整体观，但在网络安全的实践中经常割裂两者，主要还是因为网络安全运维服务和业务运行逻辑相互分离导致，且这个局面短时间内是难以改变的。
不过，信息系统本身是这个整体中能动性最大的成份，如果信息系统自己能对部署运行环境进行检查和管理，那即使不是从根本上解决问题，也能极大地减少了因部署运行环境存在问题而导致的网络安全风险。
要检查的内容可以包括:
这对于移动端应用软件已经纳入到等保测评范围，但服务端部署的系统后端实际同样需要这样的要求。
防篡改手段虽然可行，但始终是旁路手段，从第一性原则出发，信息系统自身具备完整性检查的能力更为有效。
运行环境情况比较复杂，举个例子：
典型的正常设置下，信息系统应配置为非 ROOT 用户运行，文件和目录的拥有者为非 ROOT 用户，访问权限应为 644，除此之外的都是特定设置。
运行环境的检查，就需要实现对进程、文件和目录的拥有者，以及文件和目录的访问权限进行检查，确认是否符合上述正常和特定设置。
正常和特定设置是否被篡改，虽可以由系统管理员编写脚本实现定期检查或通过其它第三方软硬件手段实现检查和触发告警等行为，但如果信息系统本身能进行检查告警甚至实现联动，那依然会比任何其他方法都更准确。
因为只有系统的开发者才能精准知道什么才是最正确的设置。
正常情况下，对信息系统的访问路径应该是确定的，但攻击者总要想办法绕过访问路径上设置的关卡，在避免触发告警的情况下接触和利用信息系统。如果信息系统本身能对访问来源进行溯源，对于偏离了正常路径的访问来源给出告警，这同样会比任何第三方手段要有效。
太专业就不展开了，只表达一个观点：
软件供应链管理不能只定位于外围信息，不能只聚焦于 CI/CD 环节，应该带入到成品软件中，实现软件供应链的全过程主动跟踪管理。
只是，SBOM 还没几个开发商能在开发过程中自动化生成，SPDX 规范仍在发展，国家标准《网络安全技术 软件物料清单数据格式》也只是刚刚公开征求意见，可见这还有很长的路要走。
本站微信订阅号：
本页网址二维码：