我们整理了前不久安全直播中，日志易安全产品经理施泽寰分享的《日志易 SOC/SIEM 实践》。
直播共分 5 个环节：
1、 SIEM 建设背景
2、 影响 SOC/SIEM 项目成功的三要素
3、 SOC/SIEM 体系建设
4、 SOC/SIEM 实践经验总结
5、 问题答疑
以下为详细内容：
大家好，很荣幸能在这里和大家做一个安全方面的分享。最近护网比较热，等保 2.0 兴起，安全的话题一提再提，相信大家也对企业安全建设有了一些心得，可能还有一些困惑。日志易最近做了不少护网的项目，借这个直播的机会，也算是和大家分享一些我们在 SOC/SIEM 实践方面的经验。
关于今天的分享呢，关键词有三个：快速响应、统计挖掘、溯源分析。这三个关键词也是 SOC/SIEM 建设方面的三个要点，几乎涵盖了安全建设的主要内容。
基于这三个要点，我们来看一下今天分享的内容。
首先，我会从现在企业安全运营面临的主要问题出发，分析一下 SIEM 建设的背景：这部分的内容包括企业进行安全体系建设面临的诸多问题，传统的 SOC/SIEM 建设的流程，以及各企业 SOC/SIEM 落地过程中遇到的一些问题。
关于 SIEM 建设，我们提倡的是自动化、工作流和分权，这是我们的目标，也是我们持续在做的，并且对用户来说也是有价值的。在做真正的安全体系建设的时候，还应注意一个要点：任何体系的建设都离不开人、流程和技术，而这也是影响 SOC/SIEM 项目成功的三要素。
下面我们会系统性地讲解一下 SOC/SIEM 建设的流程和日志易实践经验的分享总结，包括识别内外部环境、日志采集、资产管理、威胁建模、溯源取证、安全事件响应机制建设与协作运营。这也会是今天分享的重点内容。
再之后，就是总结和答疑了。
SIEM建设背景
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 平台的价值。
虽然可疑事件及未知威胁不容易分析，但究其根本，了解内外部环境，才是分析的根本。因为检测异常主要有两种模式，我们定义为黑名单模式和白名单模式。在黑名单模式中，命中了就是异常，这也是发现已知威胁的模式。而另外一种，白名单，则是相反，出现与白名单不符的事件，即有异常。所以白名单的范围，直接决定了异常事件的准确度。在了解自身环境的基础上，扩展白名单范围，以不变应万变，始终是分析可疑事件、未知事件的主要原则。
第四就是落地威胁场景的过程，忽略持续对其优化。如上述所言，我们应该基于对实际环境的了解，不断对规则进行优化过滤，如白名单、严格过滤收敛，最后缩小范围，提高规则的准确度。不同企业安全体系建设的侧重点不同，不能持续优化、收敛的规则，对企业的环境而言不具备普适性，可能就是不适用于我们的环境的。
影响SOC/SIEM项目成功的三要素
通过上面对 SOC/SIEM 建设背景的分析，我们基本可以了解到：SIEM 的成功实施，是离不开这三个要素的——人、流程、技术。
企业 SIEM 建设需要注意几个要点。
首先，SIEM 流程建设应融入整体工作流程。只有这样，安全才不是一个孤立的系统。我们的 SIEM 要与工单系统对接，与 OA 对接。这是流程化的内容。
其次，是要做好用户分权设计。SIEM 体系建设需要多方协同，有多角色参与的需要，就要有不同角色的权限分配或针对某个事件，对某个角色（可能是外部的第三方人员）临时授权之类的权限管理。这里面一部分是安全事件处置的流程化影响的。
SIEM 建设需要提高威胁模型准确度。不是一味的强调开箱即用，应该有人力的不断投入，有一个不断优化的过程。
SIEM 建设还应着重于可疑威胁的分析。什么事件是可疑的呢？比如某些安全事件，可能已经被 WAF 过滤掉了，但可能又是另外一个安全事件的分析入口。又比如新创建的账户、账户出现了权限变更，在特定的时间、情境下，都需要引起分析人员的注意。
再者就是做好事件优先级的判断了。这就需要安全管理人员结合资产、漏洞的情况进行识别分析，不能仅仅依靠高中低的告警级别进行判断，因为机器是远不如人类智能的，规则是死的，而实际情况是多变的。
SIEM 成功实施与否，始终离不开流程、技术和人这三个要素。
SOC/SIEM体系建设
SOC/SIEM 体系的建设要基于企业自身的环境现状，所以企业内外部环境识别是首要的。
3.1 识别内外部环境
为什么要识别内外部环境呢？
很多人都清楚，如果把企业比作一个城堡的话，攻击与安全体系建设就相当于城堡攻防战争，一方是防守方，一方是攻击方，在安全攻防过程中，双方都要投入一定的成本（如时间成本），假如某个地方出现漏洞，比如攻击者掌握一些 0day，攻击者如果探测清楚“城堡”结构，知晓何处漏洞可以利用，那么会在防守者发现之前进入城堡（企业内部）。反之，如果防守者通过自查的方式，在攻击者之前发现漏洞所在，及时进行修复，那么就达到封堵预防的效果。某种程度上看，安全攻防就是一场成本博弈，对攻击者而言，安全体系建设好的企业单位攻击成本高（找到防守者所没发现的漏洞的时间长），自然不是攻击者的优先选择，反之亦然。所以对于防守者来说，了解内外部环境，有利于在安全事件发生之前或正在进行的时候，及时进行响应。
识别内外部环境分为两块：一是识别区域与外部边界；二是识别当前网络上下行链路以及内部基础设施。
识别区域与外部边界可以从业务所在区域和人员所在区域入手。
业务所在区域一般以防火墙或 WAF 或 IPS 为防御边界。业务区域一般为攻击方所攻击的重点，大量的信息探测、恶意爬虫、漏洞利用尝试、WebShell 上传等手段都会针对此区域的资产展开。
人员所在区域或办公区域一般以终端为防御边界。办公区域一般为钓鱼、社工的对象，主要通过钓鱼邮件来对终端植入恶意程序，并进行扩散，最终以获取IT基础设施的信息或者权限为目的，如域控、邮件服务器等，以期在企业内部找到支点，可以获得进一步进入业务区域的机会。
识别当前网络上下行链路以及内部基础设施自然是从网络上下行链路以及内部基础设施入手。
识别网络上下行链路：需要详细了解流量经过内外部的每一个区域或节点，根据企业的实际情况，可能远远不止上图这些，一般还会有 CDN 等。每个区域或节点我们需要关注的重点也不一样，如 WAF 日志中，真实源地址是否有对应字段可供查询，如 X-Forward-For。网络上下行链路中的设备包括互联网、应用层、网络层、安全设备、系统、终端、堡垒机及运维管理平台等部分。
识别内部基础设施：主要围绕终端用户的一系列行为进行。了解正常行为，可以反向推导异常。这就要求我们对内部防御手段以及基础设施，要有一个清晰了解。根据终端用户常见行为，我们需要在邮件网关、上网行为管理、防病毒、终端安全管理等方面做好相应的监控及防护手段。
3.2 资产及其脆弱性识别
建设 SOC/SIEM 前，需要清晰了解内部的资产，包括应用、中间件以及数据库等的服务器，对应的网段，存在的服务，Web 区域（或 DMZ 区，或其他与互联网有交互的区域）与内部其他区域的正常通信情况，并将资产、漏洞以及威胁关联起来看。资产、漏洞为非时序数据，如何与威胁事件（时序事件）进行关联分析，是个难点。
识别资产以及脆弱性主要围绕以下四点：
1、漏洞管理
在漏洞管理上，需要多种漏洞扫描工具交叉验证。在漏洞修复进度追踪上，需要制定修复计划、控制修复时间、管理漏洞状态（漏洞状态一般可以划分为未修复、已修复或忽略）等。我们应该关注较新的漏洞发现以及修复，并将其与威胁事件关联对比。这里我们需要重点关注某些漏洞，如内核类以及协议类漏洞。
2、基线管理
在基线管理时，应关注资产上的不安全配置，如密码管理中的弱口令等；关注应用 Web 后台是否暴露在互联网。而且不仅仅需要针对应用系统（操作系统、中间件以及数据库）进行安全基线检查，还需要对网络设备、安全设备进行安全基线检查和登录监控。
3、新增资产
应丰富资产属性，方便资产管理；及时发现新增资产，补充资产盲区。
4、变更资产
应及时发现已有资产的变更，将其与威胁、漏洞关联起来，如版本变更可能带来的新安全隐患。
对漏洞以及资产进行关联，可以从威胁、漏洞、资产三方面入手分析。看重点威胁是利用什么漏洞、针对哪些资产进行攻击；看资产存在哪些漏洞，是否与威胁利用的漏洞一致。
关联的关键点在于自动关联分析以及展示高风险事件、多元安全数据过滤高精度告警、对原始数据进行溯源分析上。
3.3 威胁建模以及模型持续优化
针对威胁，应该有一个模型对其进行分析，并持续地对模型进行优化，以长久保持规则的适用性。
面对已知威胁，主要通过对已有数据进行分析，并从中得到规律。通过安全设备日志，结合部分原始日志，如结合 Web 访问日志进行分析，根据日志中获取到的相关信息设计威胁模型，这个威胁模型开始可能并不精确，没关系，这个阶段我们可以大胆假设，当然，如能结合内外部环境，模型精准程度就会更高。根据这个模型，我们去配置规则场景，再持续不断优化规则（这里我们需要意识到，规则的持续优化是需要投入一定人力的）。
面对可疑威胁，我们可以通过原始事件日志（比如流量、终端日志），进行溯源取证分析。可以将可疑威胁统计分析的结果与已知威胁的监控检测结果进行对比分析，通过异常告警、事件发现异常入口。再按照时间轴顺序，对可疑威胁的上下文进行分析。分析可疑威胁发生前后执行的动作，往往可以帮助我们分析出可疑威胁发生的真正原因。
未知威胁和可疑威胁的分析思路基本相同，也是通过日志进行溯源取证分析。未知威胁是偶然事件，是小概率发生的。那么我们应该怎么关注未知威胁呢？基于我们对内外部环境的认知度，以及现有的分析结果，有针对性地作出假设并展开防御。
给大家举几个例子，这些都是实际环境中可能遇到的场景。
一个是同一日志关联分析场景，这个场景可能属于已知威胁。我们的 WAF 发现注入尝试攻击事件，但服务器正常响应。那么我们就可以建立这么一个查询分析，过滤 WAF 日志中出现注入告警且关键字匹配到 sleep 函数类，但关联状态码字段值为“200”（正常响应）的日志，并对这些过滤出的事件日志进行针对性分析，对攻击类型、源地址、目的地址进行分组展示。
再举一个对多源日志关联分析的场景。有时候，同一个源地址触发了不同设备规则库的规则，这个源地址可能执行了一些风险很高的操作，属于可疑威胁，这时我们需要对多源日志进行关联分析。
第三个例子是当服务器出现新实体、新账户或新进程时的检测。这可以通过与以往时间状态的实体或进程相比进行发现。这是应对未知威胁的一个分析思路（同样也是对应白名单检测模式）。
3.4 安全事件溯源取证
对于安全事件，如何进一步去做溯源分析呢？下面这张脑图提供了一个概要的思路。针对一个安全事件，我们从源地址进行分析，然后再到目的地址。对目的地址进行分析时，又会根据不同的资产，有不同的分析策略。如果是外部资产，则去排查内网源地址攻击情况，如果是内部资产，则去执行其他的动作。这里有个需要注意的地方，根据这个地址是首次攻击还是历史出现，会有一个攻击者画像的概念，根据攻击者的攻击记录，我们会对他采取相应的防御手段，比如封禁 IP。
根据源地址、目的地址对安全事件进行分析，如果有用户名称的话，还会结合用户名称，看用户的活动痕迹，结合安全事件的发生区域，最终要达成的一个目的，就是鉴定此次攻击的攻击结果。
3.5 建立安全事件响应机制
当一起安全事件发生后，我们会对安全事件进行分析。前面提到：影响 SOC/SIEM 项目成功的三要素分别是人、流程和技术。对安全事件的结果进行鉴定后，响应的结果只有两个：封禁 IP 及锁定用户、不封禁 IP 和不锁定用户。围绕这两个结果，就应当建立起一套有效的安全事件响应机制，以便我们对这些事件作出相应的反应，安全事件响应机制包括安全事件的监测、分析、决策、处置以及修正。
简略而言，首先会有对安全事件的监测，基于监测上报的信息，对安全事件进行分析，接着通过分析安全事件是否属实，进行相应的决策或建议，最后就是处置。当然这个过程中，可能会存在误判，所以事后的处置修正流程也是必要的。
3.6 SOC/SIEM多角色协作运营
上面所讲的 SOC/SIEM 流程涉及的内容很多，整个流程的落地比较复杂，需要由安全人员统筹，其他部门人员协作，共同把这个流程完善起来。
前面也提及过，SIEM 体系建设需要多方协同，需要有一个完善的权限管理制度。
SOC/SIEM实践经验总结
在SOC/SIEM真正实践落地的时候，我们通常需要结合企业内外部环境状况，对整个体系作出一个规划。规划包含的内容有很多。
4.1 正式规划
首先，应根据企业 SOC/SIEM 建设的目的，确定有关注度的功能用例，有了功能用例，还需要我们进一步落实，确定进行数据采集、报表输出和安全事件的监控需求，以便输出我们的工作成果。根据要输出的报表，可以反推我们需要哪些数据源，然后评估解决方案应该包含哪些数据源，并确定其规模，这需要做一个认真而全面的调研，也就是内外部环境调研了解（我们前面已经提及过多次）。
再者就是评估 SOC/SIEM 平台部署的架构，实际部署架构要比我们之前提到的架构模型复杂得多，包括各个区域的数据采集、中间数据流程的走向、所需的服务器配置以及数量、各个角色需要通讯的端口等。我们需要清晰地了解和认知这个架构，一般这个过程需要企业和厂商做到紧密合作。可以是厂商主导，但是用户应该参与进来，共同评估。这也方便用户对厂商所实施的项目进度进行把控。
还有就是确定数据源的类型和解析质量，解析质量对后面的分析结果的影响很大。最后就是定义安全事件处置流程，我们需要一个能够跑起来的流程，以便驱动 SOC/SIEM 的运营。
4.2 SOC/SIEM建设
规划完成后，就是落地建设了。虽然我们想要达成一个开箱即用的效果，但那在 SOC/SIEM 建设中往往不太现实。初期我们更需要关注的是如何让流程真正跑起来，这方面可以通过创建 5～7 个 USE CASE，也就是几个真正有用的告警规则，先结合流程运行起来。等到这几个规则用起来了，分析质量有保证了，验证安全事件的方式顺畅了，接下来再接入更多的日志，后续的建设才容易推动。而不是一上来，就是实施一大批的规则，但往往很少规则能真正运转起来，以至于到了后面，用户往往失去了耐心和信任。
然后就是保障充分的上下文信息，也就是说我们应该基于企业自身环境，接入更多的日志信息，如应用层、网络层、终端层的日志，丰富 SOC/SIEM 的数据来源。
最后再强调一点，我们应该基于企业的实际运行环境，注重对威胁模型的调优，而不仅仅是把规则建立好就可以了。我们应该是持续地对规则进行监测，看看威胁告警情况如何，涉及哪些资产？攻击结果如何？告警可能会有一些误报，但我们需要意识到这是正常的，我们才能不断调整，从而使规则更适合我们的环境。
问题答疑
问题1：CASE 怎么落地的？能举例说明下吗？
以前面提到的“WAF 发现注入尝试攻击事件，但服务器正常响应”事件为例，我们对其进行了相应的规则配置。“appname:waf”是对 WAF 日志进行过滤，使用“sleep”关键字可以通过 sleep 注入函数过滤出 WAF 日志中的注入日志，状态码“200”则是对这些日志中正常响应的日志进行过滤。
在这么一个案例中，我们通过收集日志，基于日志进行相应的解析和分析，最终实现了对安全事件的监控检测。现在，我们有两百多条这样的规则模版，但就像我们前面提到的，我们不能过分强调开箱即用的概念，我们应该有持续的人力投入，有对规则持续进行优化的意识。
问题2：日志易目前可以作为 SIEM 来使用么？
日志易有专门的 SIEM平台，SIEM 平台和日志易平台是有差异的。上一题目中提到的例子，就已经体现了我们 SIEM 平台的一些理念，我们的 SIEM 平台已经能解决包括上面提到的例子在内的若干规则。有进一步了解我们 SIEM 平台的需求的观众，可以联系我们市场部的同事（点击文末“阅读原文”提交信息即可），后续我们可以安排更加深入的交流。
问题3：安全规则库如何高效预警？
关于高效，我的理解就是准确度。准确度高，就可以花费更少的时间和精力在处理误报上，工作更有效率。高效预警依托于两点：首先，我们一定要了解我们自身的环境，第二，一定要有持续的安全服务人力投入，厂商也好，客户自身也好，一定要有自身人力或厂商服务的持续投入，确保有持续优化规则的意识，这样才能保证规则的准确度。
准确度怎么理解呢？就是说我们通过设置白名单，或不断的过滤误报，从而对规则不断地进行收敛，当对规则做到不能再收敛时，也就意味着准确度达到了最大。
问题4：对于资产如何管理呢？出现了告警，如何去做溯源分析？
如何去判断有问题，这个是要有相关场景，并且需要根据一定的安全知识来去做分析判断的。
以一个 WAF 攻击场景为例，基于该安全事件的属性就能确认很多信息。思路就是我们之前展示的这张脑图。
以 WAF 上出现攻击，去做溯源分析为例。比如说，通过源地址分析是谁在攻击我，通过目的地址确认是在攻击我们的什么资产，WAF 攻击里不存在用户名称，我们就先跳过。然后确认攻击区域的范围，最后是攻击结果，看攻击成功与否。我们主要是基于源地址和目的地址，对攻击者和被攻击者这两个属性进行分析。
以源地址为例。拿到一个安全事件，我们可以界定源地址是内部资产还是外部资产。如果是外部资产，根据我们的告警记录，这里又分两种方式，主要是看这个地址是不是经常出现，它是首次出现还是历史出现过，是第一次攻击，还是经常攻击。
针对历史出现过的，看处置记录。封禁过，说明安全风险就很高。前面我们也说过，我们主要的精力应该放在未知威胁的发掘上，对于已知威胁，我们应该有一个快速响应的处理流程，像是源地址界定，以及对规则的持续优化之类。如果是首次出现的，我们就应该去看他的日志。还是以 WAF 攻击为例，我们只看 WAF 日志还不够，还有比如说流量日志、应用层的日志、WAF 上的 Web 日志等。我们可以去看一下这些日志里面有没有一些与 WAF 相关的特殊信息，比如说一些函数、扫描器的关键字、系统命令类关键字等，这里是需要有一定安全背景的人去做分析的，但是以上的流程我们可以先梳理清楚。
对于内部资产我们也是分首次出现和历史出现两种情况。首次出现我们就去分析一些端点的日志，根据端点日志，如登录日志、操作日志，我们可以去分析攻击者的行为，从这个方向我们是能够发现一些信息的。打个比方，看攻击者的动作是攻击内网资产还是攻击其他资产，他为什么无缘无故的去攻击一个资产呢，他之前是不是有一个异常情况没有被我们发现。
像这样针对某个属性进行分析，我们溯源分析的思路大致就是这样。
不同的产品线，我们关注的安全属性也有一定的差异。具体去重点关注什么，这个还要基于安全方面的知识加以判断。我们后续的分享，就会涉及到这一方面，会告诉大家应该从哪些方面去关注一个安全事件。
今天的分享主要是告诉大家在 SOC/SIEM 构建过程中，我们应该去做的一个流程，应该怎么样去注意一下关键点、避开一些坑。
以上便是溯源分析的基本思路，不知道是否足够清晰。有不懂的可以在群里提问，或在公众号下面留言。
问题5：作为 SIEM 用的话，日志易只能溯源和分析吧，有没有办法和设备联动，下发指令封堵之类？
可以的，我们在一些案例里面做过。其实能不能封堵，要不要封堵，取决于模型的准确度，取决于能不能接受误伤。首先要对自己的模型有一个认知，做封堵首先要确定模型的准准度是很高的，另外就是能不能接受一定程度的误伤，误伤之后如何快速去判断，如何快速地进行修正、解封，都是要考虑的。
这里是可以做联动的。联动的话，我们目前还是定制类的，后续我们会把这块做成一个模块，就是可以集成 WAF、Firewall、以及一些身份认证的系统，这些接口全部封装在模块里。安全事件触发的告警，由这个模块去判断要调用什么资源系统，以及去执行什么样的操作，比如是否封禁之类。这是我们后续会做的一个事情。
问题6：通过哪些日志，如何促进企业安全建设？
一些企业想通过 SOC/SIEM 系统的建设，来完善企业安全建设体系，这些是可以理解的。不过这里有一个矛盾点，那就是对我们企业安全建设系统的认知。
如果我们不能识别我们的环境，不知道我们面临的威胁有哪些，我们就不知道我们安全建设的方向，这样又回到了前面的问题——我们应该去识别我们企业的环境。
风险大家都知道。风险是一个古老的概念，但古老并不意味着过时。我们应该由风险去指导如何建设企业安全体系。主要是识别我们企业的内部环境，由我们企业的内部环境去推导，推导出哪些是我们应该关注的威胁，再由威胁去推导出应该由 SOC/SIEM 去做哪些监控，再由监控去推导出需要有哪些数据源来做分析，再由数据源推导出我们应该去建设哪些防御手段，或者是增强哪些安全措施，主要是这么一个过程。
