大家好，很荣幸能在这里和大家做一个安全方面的分享。最近护网比较热，等保 2.0 兴起，安全的话题一提再提，相信大家也对企业安全建设有了一些心得，可能还有一些困惑。日志易最近做了不少护网的项目，借这个直播的机会，也算是和大家分享一些我们在 SOC/SIEM 实践方面的经验。

关于今天的分享呢，关键词有三个：快速响应、统计挖掘、溯源分析。这三个关键词也是 SOC/SIEM 建设方面的三个要点，几乎涵盖了安全建设的主要内容。 

基于这三个要点，我们来看一下今天分享的内容。

首先，我会从现在企业安全运营面临的主要问题出发，分析一下 SIEM 建设的背景：这部分的内容包括企业进行安全体系建设面临的诸多问题，传统的 SOC/SIEM 建设的流程，以及各企业 SOC/SIEM 落地过程中遇到的一些问题。

在做真正的安全体系建设的时候，还应注意一个要点：任何体系的建设都离不开人、流程和技术，而这也是影响 SOC/SIEM 项目成功的三要素。

下面我们会系统性地讲解一下 SOC/SIEM 建设的流程 ，包括识别内外部环境、日志采集、资产管理、威胁建模、溯源取证、安全事件响应机制建设与协作运营。这也会是今天分享的重点内容。

再之后，就是总结和答疑了。

1SIEM建设背景

1.1 目前企业安全运营面临的主要问题

一是安全设备多，日常维护压力大。一般企业发展到一定阶段，经过一段时间的安全建设，都会建立起较为完善的，或基础的安全防御体系，会部署了一定数量的、多种类型的安全产品，如防火墙、WAF、IPS、NIDS、防病毒、邮件网关、HIDS 等，但各类安全产品之间是相互孤立的。由于安全管理人员精力有限，面对整个安全防御体系中的安全产品，日常维护管理压力很大（主要是需要查看不同设备上的告警并进行分析，进而协调处置）。

二是日志量大，告警事件多，且无事件处理优先级之分。种类众多的安全设备，每天都会产生大量的日志，其中不乏大量的误报信息。而实际上，安全建设人少活多，安全运维人员每天能处理的安全事件有限，可能导致关键的安全信息和告警被大量的无效告警所淹没。

三是安全事件闭环处理进展缓慢，或者并无闭环处置。安全事件对应的资产，往往需要单独再去资产库里面进行查询，同时资产上对应的漏洞也无从得知，在整个安全事件闭环管理上，容易出现安全管理人员未知的大量空白区，导致安全管理人员无法做出有效且快速的判断，实现对安全事件的处置。

同时，安全运营实际上应该是整个内部团队的事情，因为安全运营涉及的方面很多，往往需要跨部门沟通，比如当出现安全事件的时候，进行了一番分析，接下来需要进行处置的时候，就需要和网络、运维或基础架构等不同的部门或小组之间的协调沟通，这个过程可能沟通很慢、推进困难，但是也不能就此搁置不管。这个我们后面还会提到。

再者就是安全现状不可见。有时候，在企业的边界上、各安全域中，每天、每周、每月、每年，出现了多少个安全事件？涉及多少种告警类型？安全事件发展趋势如何？最终结果是成功还是失败？我们很少能快速地回答上面的问题。但上述问题又是了解企业综合安全情况的重要衡量指标，这也是与不同的安全设备之间的孤立性有关。

所以，实际上，我们要回答上面的几个重要问题，还是需要先对企业自身的内外网环境以及边界加以了解。

当然，有些企业环境，如银行机构等，内网环境相对比较复杂。边界也不仅是说互联网边界，也可能是各个安全域之间的边界情况。所以我们才需要一个平台或工具类的产品，如 SOC/SIEM，帮我们将企业中，内网以及边界的各类安全防御技术手段的分析结果，也可以说是日志，集中到一起，并进行二次分析，进而给予安全管理人员以告警信息，让安全管理人员可以借此得到提示，展开取证调查。

同时还是那个问题，在人少活多的环境下，我们应该优先处理哪些问题？所以应该有个平台或工具来帮我们做分析决策，这就是 SOC/SIEM。

1.2 传统 SOC/SIEM 的建设过程

这里有一个简单的 SOC/SIEM 的建设流程图。现实的情况往往要复杂的多，我们只是拿这个图来做一个基本的了解。

首先是数据源。数据源包括安全设备、网络设备、应用系统、数据库，以及其他的日志类型，采集端一般会接收到数据源转发过来的日志，日志进来之后往往会有一个范式化清洗的流程，这个过程，会将不同类型的事件进行解析、映射等，处理之后才好去做统计分析。再然后是消息队列，可能是 Kafka 之类的组件，之后范式化后的数据一方面入库，我们也可以基于范式化后的结果进行查询、统计、分析。而分析可能采用的是计算引擎或如日志易的 SPL，最后会把分析结果或查询统计结果给到前端进行调用、展示。

这其中更为主要的节点是在解析阶段，因为解析的质量直接影响分析及展示的效果。在实践的时候，我们往往会有两种方式来保障数据解析的质量。

一是与厂商进行沟通，获取到不同安全设备的日志格式解释类文档，这是保障解析质量最为可靠的方式，由此也可以进行一定的日志解析经验积累。二是在有积累或与设备厂商沟通的基础上，应确保数据解析过程中，解析人员和解析工作的规范性，即解析人员尽可能保持稳定，同时解析结果需要输出解析文档，并由甲方安全管理人员在解析阶段就介入，对解析的结果进行校验，以确保解析的质量。

因为在项目初期，相对于乙方，往往甲方安全管理人员才是最为熟悉自身企业环境情况的人，而对企业环境的了解程度，也影响到数据解析时，事件如何分割、字段需要与否等问题的决策，所以这个过程特别需要甲方的介入。

1.3 目前 SOC/SIEM 存在的通用落地问题

SOC/SIEM 存在的落地问题主要是下面4类。

首先，安全事件处置优先级并无明确指引。很多企业往往只是固化地按照威胁定义的高中低告警级别来实施处理，但实践证明，在大量威胁告警并发情况下，按高中低的评估方式存在较大的不足。原因在于，风险值没有对应的指引方式，无法落实到相应的漏洞。如有些告警虽然是高危，但被阻断了（需要关注，作为某些分析的入口，但我们可以不用把主要精力放在这些上面）；有些威胁，虽然是低危，但是恰好资产上存在对应的漏洞，可被其利用（则需要重点关注攻击的结果以及后续漏洞的修复）。

针对优先级这点，我们可以从一个威胁与资产、漏洞之间的关系，来推导其中的风险程度，从而进行处理的优先级分配，合理安排安全管理人员的时间。

第二个落地的难点，在于 SOC/SIEM 平台只有安全管理人员使用，安全事件的闭环处置执行不了完整流程。我们前面也说过，安全事件的处置应该多角色参与进来，如网络管理人员、基础架构人员等。因为一个安全事件从监测、分析到处置，需要多个不同角色的人员进行配合，而在沟通的过程中，就需要强调 SOC/SIEM 平台的权限管理能力。因为对不同角色划分不同的数据访问权限或临时授权，有利于提高沟通的效率。

第三是过多依赖已知威胁场景的构建，忽略了应强调对可疑事件以及未知威胁的分析。

我们将威胁分为三类，已知威胁、可疑威胁（没有办法马上确认，需要进行调查分析的事件）、未知威胁（不在认知中的，需要对海量日志进行挖掘统计，才能发现异常的威胁）。上述的威胁，我们认为在企业环境中是客观存在的，不会随着人员的主观意识而改变。很多厂商规则库中内置了几百种规则 ，然而企业真正能开箱即用的规则很少（每个企业一般不会超过 20 种），很多规则都需要进行优化调试才具备落地投产的价值。然而，对于企业单位而言，内置的规则，我们可以认为就是已知的威胁，是专家经验的固化。我们往往看重已知威胁（或者内置规则），所以大部分精力都放在了已知威胁上，这里并不是说规则不重要，应该说持续优化的规则才是重要的。实际上，在企业环境中，我们应该将更多时间花在对可疑事件以及未知威胁的分析上，这些事件的风险是很高的，重点放在这些事件上，才能发挥 SOC/SIEM 平台的价值。

虽然可疑事件及未知威胁不容易分析，但究其根本，了解内外部环境，才是分析的根本。因为检测异常主要有两种模式，我们定义为黑名单模式和白名单模式。在黑名单模式中，命中了就是异常，这也是发现已知威胁的模式。而另外一种，白名单，则是相反，出现与白名单不符的事件，即有异常。所以白名单的范围，直接决定了异常事件的准确度。在了解自身环境的基础上，扩展白名单范围，以不变应万变，始终是分析可疑事件、未知事件的主要原则。

第四就是落地威胁场景的过程，忽略持续对其优化。如上述所言，我们应该基于对实际环境的了解，不断对规则进行优化过滤，如白名单、严格过滤收敛，最后缩小范围，提高规则的准确度。不同企业安全体系建设的侧重点不同，不能持续优化、收敛的规则，对企业的环境而言不具备普适性，可能就是不适用于我们的环境的。

2影响SOC/SIEM项目成功的三要素

这点也算是对前面讲的内容的一个小结。

通过上面对 SOC/SIEM 建设背景的分析，我们基本可以了解到：SIEM 的成功实施，是离不开这三个要素的——人、流程、技术。

企业 SIEM 建设需要注意几个要点。

首先，SIEM 流程建设应融入整体工作流程。只有这样，安全才不是一个孤立的系统。我们的 SIEM 要与工单系统对接，与 OA 对接。这是流程化的内容。

其次，是要做好用户分权设计。SIEM 体系建设需要多方协同，有多角色参与的需要，就要有不同角色的权限分配或针对某个事件，对某个角色（可能是外部的第三方人员）临时授权之类的权限管理。这里面一部分是安全事件处置的流程化影响的。

SIEM 建设需要提高威胁模型准确度。不是一味的强调开箱即用，应该有人力的不断投入，有一个不断优化的过程。

SIEM 建设还应着重于可疑威胁的分析。什么事件是可疑的呢？比如某些安全事件，可能已经被 WAF 过滤掉了，但可能又是另外一个安全事件的分析入口。又比如新创建的账户、账户出现了权限变更，在特定的时间、情境下，都需要引起分析人员的注意。

再者就是做好事件优先级的判断了。这就需要安全管理人员结合资产、漏洞的情况进行识别分析，不能仅仅依靠高中低的告警级别进行判断，因为机器是远不如人类智能的，规则是死的，而实际情况是多变的。

SIEM 成功实施与否，始终离不开流程、技术和人这三个要素。

3SOC/SIEM体系建设

SOC/SIEM 体系的建设要基于企业自身的环境现状，所以企业内外部环境识别是首要的。

3.1 识别内外部环境

为什么要识别内外部环境呢？

很多人都清楚，如果把企业比作一个城堡的话，攻击与安全体系建设就相当于城堡攻防战争，一方是防守方，一方是攻击方，在安全攻防过程中，双方都要投入一定的成本（如时间成本），假如某个地方出现漏洞，比如攻击者掌握一些 0day，攻击者如果探测清楚“城堡”结构，知晓何处漏洞可以利用，那么会在防守者发现之前进入城堡（企业内部）。反之，如果防守者通过自查的方式，在攻击者之前发现漏洞所在，及时进行修复，那么就达到封堵预防的效果。某种程度上看，安全攻防就是一场成本博弈，对攻击者而言，安全体系建设好的企业单位攻击成本高（找到防守者所没发现的漏洞的时间长），自然不是攻击者的优先选择，反之亦然。所以对于防守者来说，了解内外部环境，有利于在安全事件发生之前或正在进行的时候，及时进行响应。

识别内外部环境分为两块：一是识别区域与外部边界；二是识别当前网络上下行链路以及内部基础设施。

识别区域与外部边界可以从业务所在区域和人员所在区域入手。

业务所在区域一般以防火墙或 WAF 或 IPS 为防御边界。业务区域一般为攻击方所攻击的重点，大量的信息探测、恶意爬虫、漏洞利用尝试、WebShell 上传等手段都会针对此区域的资产展开。

人员所在区域或办公区域一般以终端为防御边界。办公区域一般为钓鱼、社工的对象，主要通过钓鱼邮件来对终端植入恶意程序，并进行扩散，最终以获取IT基础设施的信息或者权限为目的，如域控、邮件服务器等，以期在企业内部找到支点，可以获得进一步进入业务区域的机会。

识别当前网络上下行链路以及内部基础设施自然是从网络上下行链路以及内部基础设施入手。

识别网络上下行链路：需要详细了解流量经过内外部的每一个区域或节点，根据企业的实际情况，可能远远不止上图这些，一般还会有 CDN 等。每个区域或节点我们需要关注的重点也不一样，如 WAF 日志中，真实源地址是否有对应字段可供查询，如 X-Forward-For。网络上下行链路中的设备包括互联网、应用层、网络层、安全设备、系统、终端、堡垒机及运维管理平台等部分。

识别内部基础设施：主要围绕终端用户的一系列行为进行。了解正常行为，可以反向推导异常。这就要求我们对内部防御手段以及基础设施，要有一个清晰了解。根据终端用户常见行为，我们需要在邮件网关、上网行为管理、防病毒、终端安全管理等方面做好相应的监控及防护手段（如日志易 SOC/SIEM 实践分享（上） | 错过了直播分享？看这里→所提到的白名单检测手段）。

3.2 资产及其脆弱性识别

建设 SOC/SIEM 前，需要清晰了解内部的资产，包括应用、中间件以及数据库等的服务器，对应的网段，存在的服务，Web 区域（或 DMZ 区，或其他与互联网有交互的区域）与内部其他区域的正常通信情况，并将资产、漏洞以及威胁关联起来看。资产、漏洞为非时序数据，如何与威胁事件（时序事件）进行关联分析，是个难点。

识别资产以及脆弱性主要围绕以下四点：

1、漏洞管理

在漏洞管理上，需要多种漏洞扫描工具交叉验证。在漏洞修复进度追踪上，需要制定修复计划、控制修复时间、管理漏洞状态（漏洞状态一般可以划分为未修复、已修复或忽略）等。我们应该关注较新的漏洞发现以及修复，并将其与威胁事件关联对比。这里我们需要重点关注某些漏洞，如内核类以及协议类漏洞。

2、基线管理

在基线管理时，应关注资产上的不安全配置，如密码管理中的弱口令等；关注应用 Web 后台是否暴露在互联网。而且不仅仅需要针对应用系统（操作系统、中间件以及数据库）进行安全基线检查，还需要对网络设备、安全设备进行安全基线检查和登录监控。

3、新增资产

应丰富资产属性，方便资产管理；及时发现新增资产，补充资产盲区。

4、变更资产

应及时发现已有资产的变更，将其与威胁、漏洞关联起来，如版本变更可能带来的新安全隐患。

对漏洞以及资产进行关联，可以从威胁、漏洞、资产三方面入手分析。看重点威胁是利用什么漏洞、针对哪些资产进行攻击；看资产存在哪些漏洞，是否与威胁利用的漏洞一致。

关联的关键点在于自动关联分析以及展示高风险事件、多元安全数据过滤高精度告警、对原始数据进行溯源分析上。

3.3 威胁建模以及模型持续优化

针对威胁，应该有一个模型对其进行分析，并持续地对模型进行优化，以长久保持规则的适用性。

面对已知威胁，主要通过对已有数据进行分析，并从中得到规律。通过安全设备