安全管理平台，SOC/SIEM的实践分享【实践篇】

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

SOC/SIEM体系建设

SOC/SIEM 体系的建设要基于企业自身的环境现状，这里重点是企业内外部环境识别。

3.1 识别内外部环境

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

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

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

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

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

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

识别网络上下行链路：需要详细了解流量经过内外部的每一个区域或节点，根据企业的实际情况，可能远远不止上图这些，一般还会有 CDN 等。每个区域或节点我们需要关注的重点也不一样。

识别内部基础设施：主要围绕终端用户的一系列行为进行。了解正常行为，可以反向推导异常。这要求我们对内部防御手段以及基础设施，要有一个清晰了解。根据终端用户常见行为，我们需要在邮件网关、上网行为管理、防病毒、终端安全管理等方面做好相应的监控及防护手段。

3.2 资产及其脆弱性识别

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

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

1、漏洞管理

在漏洞管理上，需要多种漏洞扫描工具交叉验证。在漏洞修复进度追踪上，需要制定修复计划、控制修复时间、管理漏洞状态（漏洞状态一般可以划分为未修复、已修复或忽略）等。

2、基线管理

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

3、新增资产

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

4、变更资产

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

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

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

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

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

面对已知威胁，主要通过对已有数据进行分析，并从中得到规律。 通过安全设备日志，结合原始日志，进行分析，根据日志中获取到的相关信息设计威胁模型，根据模型去配置规则场景，再持续不断优化规则。

面对可疑威胁，我们可通过原始事件日志（比如流量、终端日志），进行溯源取证分析。 可以将可疑威胁统计分析的结果与已知威胁的监控检测结果进行对比分析，通过异常告警、事件发现异常入口。再按照时间轴顺序，对可疑威胁的上下文进行分析。分析可疑威胁发生前后执行的动作，往往可以帮助我们分析出可疑威胁发生的真正原因。

未知威胁和可疑威胁的分析思路基本相同，也是通过日志进行溯源取证分析。未知威胁是偶然事件，是小概率发生的。那么我们应该如何关注未知威胁呢？基于我们对内外部环境的认知度，以及现有的分析结果，有针对性地作出假设并展开防御。

3.4 安全事件溯源取证

对于安全事件，如何进一步去做溯源分析呢？下面这张思维导图提供了概要的思路。针对一个安全事件，我们从源地址进行分析，然后再到目的地址。对目的地址进行分析时，又会根据不同的资产，有不同的分析策略。如果是外部资产，则去排查内网源地址攻击情况，如果是内部资产，则去执行其他的动作。有一点需要注意，根据这个地址是首次攻击还是历史出现，会有一个攻击者画像的概念，根据攻击者的攻击记录，我们会对他采取相应的防御手段，比如封禁 IP。

根据源地址、目的地址对安全事件进行分析，如果有用户名称的话，再根据用户名称，看用户的活动痕迹，结合安全事件的发生区域，最终要达成的一个目标，就是鉴定此次攻击的攻击结果。

3.5 建立安全事件响应机制

当一起安全事件发生后，我们会对安全事件进行分析。影响 SOC/SIEM 项目成功的三要素，分别是人、流程、技术。对安全事件的结果进行鉴定后，响应的结果只有两个：封禁 IP 及锁定用户、不封禁 IP 和不锁定用户。围绕这两个结果，就应当建立起一套有效的安全事件响应机制，以便我们对这些事件作出相应的反应，安全事件响应机制包括安全事件的监测、分析、决策、处置以及修正。

简略而言，首先会有对安全事件的监测，基于监测上报的信息，对安全事件进行分析，接着通过分析安全事件是否属实，进行相应的决策或建议，最后就是处置。

3.6 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 的数据来源。

最后再强调一点， 我们应该基于企业的实际运行环境，注重对威胁模型的调优 ，而不仅仅是把规则建立好就可以了。我们应该是持续地对规则进行监测，看看威胁告警情况如何，涉及哪些资产？攻击结果如何？告警可能会有一些误报，但我们需要意识到这是正常的，我们才能不断调整，从而使规则更适合我们的环境。

关于 SIEM 建设，我们提倡的是 自动化、工作流和分权 ，这是我们的目标，也是我们持续在做的，并且对用户来说也是有价值的。