Question

安全运营工具包括支撑安全运维框架实现的 SIEM 平台、安全事件处理标准化流程工具 ITIL、安全控制自动化工具三部分：

·SIEM 平台，负责安全信息的统一收集和存储、基于检测规则的异常检测和告警。

·ITIL 平台，负责接收 SIEM 平台发送过来的安全事件信息，并据此产生 ITIL 工单，推送给安全运营人员处理和关闭。

·安全控制自动化工具，负责根据 SIEM 平台下发的安全控制指令进行自动化操作。例如，检测发现有外部攻击源，通过下发自动化指令实现防火墙或 IPS 封禁该攻击源；检测发现某主机有可疑进程，通过安全客户端收集该进程文件样本信息进一步手动分析；检测发现办公内网某用户计算机上有个可疑的非人工操作，疑似程序自动操作，可通过安全客户端提示用户手工确认等。

SIEM 平台、ITIL 平台目前市面上成熟的产品不少，但安全控制自动化工具目前商业化程度不高。

1.检测规则

如果有合适的检测规则，SIEM 是个非常强大的工具，可以检测其他安全工具无法捕获的安全事件。通常 SIEM 的检测规则有三类：

（1）检测条件规则。满足单一特定检测条件则触发告警。例如，服务器主机登录来源非堡垒机地址，满足该条件则告警。该类型规则最简单，主要依靠安全 Sensor 的监测能力和规则过滤能力。是攻击就一定有异常，关键是怎么总结提炼出异常的特征加以检测，比如，Ayazero 在《互联网企业高级安全》一书中提到的检测攻击提权，“某个高权限（system?uid=0）进程（bash?cmd.exe?）的父进程为低权限”，是一个总结提炼异常特征加以检测的很好案例。

（2）跨平台安全监测信息关联检测。最典型的规则为基于资产脆弱性的攻击告警，如，关联分析漏洞扫描和入侵检测告警信息进行关联检测。再比如防火墙 permit 日志中有连接 ArcOSI 中定义的恶意 IP 地址信息。

该类型规则在跨平台系统监测信息之间进行关联，可以衍生出很多脑洞大开的检测规则。比如，检测安全违规行为，检测数据泄密，甚至人员可能离职等。这类规则检测效果的好坏取决于两点—一是安全 Sensor 的类型尽可能多，单个 Sensor 能监测维度尽可能广；二是规则设计者的检测思维，最好就像攻击者思维一样，需要脑洞大开，需要从“猥琐”处着眼。

（3）针对长时间缓慢低频度攻击的检测规则。大部分的安全工具是以孤立方式识别潜在的安全事件，例如，IDS 监测到某台工作站发出的可疑流量，然后从其他 20 台工作站上监测到同类流量，在 IDS 管理面板上，每个事件被当作单独事件处理（有些 IDS 厂商有高级功能），在 SIEM 中可以编写规则，根据事件发生的频率触发不同的告警，如果在几分钟内从 IDS 传来 21 次类似的事件可以触发一条规则。如果攻击者采取长时间缓慢低频度攻击入侵企业内网，可以编写一条 SIEM 规则，在较长时间内搜索特定事件，并在该事件范围内发生次数达到某个阈值时告警。

更进一步，这种检测规则对于不是以即时安全事件形式出现的日志也同样有效。以检测 DNS Tunnel 为例，DNS Tunnel 用于将 C&C 流量编码为 DNS 请求，从被感染机器发出，通过被感染企业的 DNS 服务器到达 C&C 服务器，然后再将响应返回给企业的 DNS 服务器，由其转发给受感染的内网机器。正常的 DNS 查询都有一定频率，DNS Tunnel 需要在网络上发送许多 DNS 数据包，那么制定内网单台机器对同一个域名的查询达到某个阈值（如 10 分钟内 1000 个查询）的规则可以有效检测 DNS Tunnel。

SIEM 的检测规则还可以配置为在流量来源与旧模式不同时发出告警，也可以配置为在合法时和以往正确的流量相比突然呈现指数上升或者下降时发出告警，例如，过去 90 天内产生一定数量日志的 Web 服务器突然开始产生 10 倍于正常数量的日志，这可能是被入侵主机用于向其他主机发动攻击的迹象。通过 SIEM 规则，安全团队可以根据流量的标准差制定告警，例如达到 10 个标准差阈值就告警。

2.健康度监控

从很多攻防案例中可以得出，防御方失败的原因主要归结于安全防护失效，其中 SIEM 平台工具健康度出了问题是比较常见的，包括安全 Sensor 安全监测信息采集器失效，SIEM 检测规则失效，安全告警失效，安全告警处理失效等。

·安全检测信息采集器失效的原因主要包括：未对采集器的物理机器性能监控、采集数据异常监控、采集数据日志解析和映射入库（Parser）异常监控等。

·SIEM 检测规则失效，包括设定条件无效、阈值无效、规则未生效等，有时告警阈值设置不合理而导致频繁告警，SIEM 平台自动禁用规则而导致规则无效。

·安全告警失效，包括邮件、短信网关配置无效，配置用户失效，网络失效，配置变更异常，手机号码设置错误等。

·安全告警处理失效主要是人的因素，比如多条告警短信选择性地忽略，假阳性告警太多淹没了真正有威胁的告警等。

值得一提的是安全 Sensor 自身的安全性。韩国在 2013 年 3 月 20 日下午 2 点，包括新韩、农协和济洲等三家银行与 KBS（韩国广播公司）、MBC（韩国文化广播公司）等两家电视台，超过 32 000 台电脑以及部分 ATM 提款机都在同一时间宕机，无法重新启动。黑客首先入侵了韩国防病毒软件厂商 AhnLab（安博士）的病毒定义更新服务器，利用病毒库定义升级机制，将恶意软件分发到用户的计算机，在用户的计算机上安装执行恶意程序。调查发现，另一家防病毒软件公司 ViRobot 也被黑客利用。

设想一下，如果你在企业内部部署的安全 Sensor 接受更新的是恶意软件……，真让人不寒而栗。因此，做好安全 Sensor 的安全性，需要注意以下几个原则：

·控制指令仅允许固化的指令，严禁在 Sensor 端预留执行系统命令接口。

·更新包必须经过审核才可上传至更新 Server 保存，更新仅允许选择更新 Server 上以后的安装包，最好校验更新包的 MD5。

·控制指令下发时必须人工审核确认后才执行。

·为可用性起见，更新最好分批分区域完成，否则由于大量更新包的下载导致生产网被堵塞，也是不可承受之痛。