1.4　建立监控审计

全面安全评估发现存在大量高危安全风险。因为过去吃够了安全的苦头，而且根据现在的《安全事件定级标准》，业务方也必须承担安全责任，所以各个团队都在整改过程中给予了良好的支持与配合，大量高危风险得以快速消除，M公司的安全事故发生频率明显降低。随之而来的，就是公司各个层面对我的信任程度越来越高，这是我第一次在M公司体会到了安全的存在感！

但是我却越来越忐忑不安，因为我知道，当前消除的大部分是那些看得见的安全事故，至于那些看不见的事故，它们现在有没有发生、在哪儿发生、造成了什么影响，依然一无所知。它们就像悬在头顶的达摩克利斯之剑，随时可能掉下来，让用户和公司承受无法衡量的损失。

要发现这些看不见的风险，就必须建立安全监控审计体系。

安全的监控是一套很复杂的体系，造成这种“复杂”的原因主要有3点。一是新型的攻击往往不具备已知的特征，这会导致监控审计系统难以识别，比如有大量的 0day 攻击可以成功绕过监控；二是即使成功识别了攻击，监控审计系统也难以判断这次攻击是否造成了影响，需要干涉处理，比如传统的 IDS 每天会产生海量的信息，但实际需要处理的极少；三是即使某条信息可以被判定为绝对正常，但是把各个环节的信息进行关联分析，依然可以定性为攻击行为，比如一次精密的APT攻击就可能在单个环节上极其隐蔽。这种复杂性在短期内可能无法被彻底解决——尽管市面上已经存在很多优秀的安全产品，它们在这方面取得了很多进步，但是在安全监控召回率和准确率（或者说漏报率、误报率）的平衡上依然还有很长的路要走。

面对这样的复杂性，公司在建立安全监控审计体系的时候，应该注意什么呢？

首先，要尽可能全面地收集各类数据，为后续关联分析做好准备。

其次，要尽可能避免盲目设置告警，减少在无效告警排查工作上浪费的时间和精力。

再次，要尽可能保证日志不可篡改，防止外部攻击者或者内部恶意员工清除作恶证据。

最后，要尽可能利用安全评估的过程和结果验证监控审计体系的有效性，并持续优化和完善监控能力。

一套基本合格的安全监控审计体系，我认为至少应该覆盖如表 1.8 所示的监测点。

确定了监控审计体系的第一步，接下来需要考虑谁来做、怎么做的问题。一个如此庞大的工程不可能由安全工程师独立完成。为了方便与各个团队沟通具体的协作内容，我先梳理了一下当前阶段需要协作的具体工作，如表 1.9 所示。

在梳理基础监控审计体系建设协同工作的时候，我放弃了两种类型的工作。

一种是需要在服务器安装部署本地 Agent 的工作。因为在大多数情况下，出于对系统稳定性的考虑，运维人员会比较排斥在生产服务端安装非业务、非运维功能的 Agent，即使勉强同意，也难免要经历极其漫长的选型、测试、灰度和上线过程。这对“救火”阶段的帮助不大，而且极易在各种运维故障中引发猜疑和冲突。

另一种是类似 IPS、WAF 的串联部署（无论是物理串联还是逻辑串联）。这类设备的上线需要执行网络割接操作。在一个复杂的网络环境下，这类设备可能需要分布式部署在多个位置，而多次的割接操作可能会带来更大的故障风险。与此同时，这类设备通常存在大量的误报情况，因此在上线后依然需要经历很长的观测期才可以启动阻断策略，那时候“救火”阶段已经过去了。当然，如果网络攻击对企业的影响已经达到了极其严重的程度，并且企业暂时不具备快速评估整改的能力，那么这时候可以考虑和接受一定的误报，上线 IPS 和 WAF 等阻断式入侵防护系统，快速提升整体安全。

小贴士

与业务方沟通安全协同工作时，需要尽可能划分阶段并清晰、全面地向业务方阐述需求，这样更有利于对方进行资源协调和任务排期。想到什么就告诉业务方需要做什么，已经达成一致的内容反复变来变去，所有任务不分轻重缓急一概催着要结果，这些都是极其影响合作但又特别常见的现象。所以，建议先自己打一张表，想清楚这个阶段到底要做什么、谁来做。

对于工作而言，不同的分工有不同的业务目标，所以跨团队协作中的一些分歧并没有对错之分，优秀的负责人应该清楚地认识到这点，避免分歧扩大成冲突，影响后续合作。所以，对于一些阻力大但是见效时间长的工作，可以适当往后缓一缓。

接下来，我正式启动了第一阶段的工作。

• 在互联网、办公网部署网络扫描工具，监控生产网边界的访问控制规则的有效性，确保没有未经授权的 IP、端口和服务对外开放。
• 在生产网部署漏洞扫描工具，监控操作系统、数据库、中间件和应用程序的已知漏洞。为了避免过度扫描引发故障，我严格限制了扫描速度，只启用可以远程利用的高危漏洞插件，并且关闭了其中的破坏性扫描插件。
• 在生产网边界部署 IDS 和仅开启旁路监听的 WAF，监控针对生产网的攻击事件。因为无效报警太多且当前没有值班人员，所以 IDS 只开启新近 0day 的攻击报警，WAF 只开启请求响应匹配后大概率确定入侵成功（机制类似于漏洞扫描器）的报警。至于全部记录信息，采用定期集中分析的形式统一检查。
• 在生产网和办公网内部部署异常流程分析工具，监控恶意网络通信和异常流量波动，及时发现木马病毒、挖矿脚本、APT攻击和大规模数据外传等异常情况。
• 部署白盒代码审计工具，联动代码仓库和发布系统，监控支付、用户信息等重点业务的代码变化情况及安全隐患。
• 在生产网和办公网边界部署堡垒机，要求所有生产操作必须经过堡垒机执行，监控、记录全部的生产操作行为。
• 部署日志分析工具，并在第一期实现以下分析能力。
  • 重点接口访问量异常监控，比如支付、提现、订单、个人信息等，这类接口如果出现访问量激增，大概率是出现了安全漏洞或被“薅羊毛”。
  • 与工单流程不匹配的敏感操作监控，比较容易实现的包括但不限于账号变更、数据库导出、网络变化、重启关机操作。
  • 特定敏感数据的异常查询监控，比如 DBA 执行的 SQL 语句中特定包含了某个用户的密码、地址信息，或者技术员工通过应用后台查询了某个用户的详细资料等，这种情况极少出现在正常工作中。
  • 在与对外服务和内部重要系统相关的用户登录、申诉、找回密码等接口处部署基本的撞库、暴力破解和异常登录行为监控，这是一个水涨船高的业务安全对抗过程。
• 部署内容安全检测与过滤系统，严格防范色情、反动和低俗信息。
• 在办公终端部署防病毒程序，降低与病毒、木马、间谍程序和勒索软件相关的风险。
• 如果条件允许，部署一套 SIEM（security information and event management，安全信息和事件管理）工具进行关联分析和事件挖掘。

基本上我们可以找到与以上各项工作相关的开源项目或商业解决方案，当然也可以自研，至于具体采用哪种方式，需要根据安全的预算情况、业务的发展规模和团队的实际能力综合决定。

一般在时间紧迫、团队能力不足的情况下，大部分企业会优先选择商业解决方案来支撑前期需求。但是归根到底，选择开源方案、商业方案还是自己开发方案，取决于企业对此项安全需求的评估，选择可以承担成本的方案中最优的，才是最重要的。