SIEM技术已经存在并被使用了25年以上，起初只是在海外和国内部分头部企业使用，用以解决数据孤岛、安全事件分析、运维管等问题。鉴于技术原因起初的它并不好伺候，甚至是花钱买罪受。但随着技术的不断发展和实际需求，它又再次回归我们的视线。本文将带您了解SIEM并提供SIEM建设的一些建议。

SIEM定义

Security information and event management (SIEM) 安全信息和事件管理，通过多个维度的日志收集和场景分析，实现实时和历史事件的分析，旨在帮忙企业提升事前预测、事中检测和事后调查取证的能力，同时配合企业内部工作流程做到信息安全事件的闭环落地，以提高信息安全防御水平，提升信息安全管理能力。

SIEM技术成熟度

在Gartner发布的2021安全运营技术成熟度曲线中(如下图)，对主流的安全运营技术进行了分析，其中SIEM已步入稳步发展并趋进成熟的阶段，这个分析也正符合市场的现状，很多企业在安全运营中已把SIEM(或者叫做态势感知)作为主要实现平台。

编辑搜图

知识点补充：

技术成熟度曲线中指出技术的发展需要经历：萌芽期、膨胀期、低谷期、恢复期、成熟期(对应上图横轴的5个阶段)。在判断时先看报告的出具年份①，其次查看您关注的技术成熟度②，根据标注的淡蓝色③来看还有多少年到达成熟期。以SIEM为例就是2021+2~5年，在2023-2026年是SIEM技术彻底成熟的时候。

SIEM价值体现

1.外部驱动

不管是国家一把手在重要精神讲话中提到态势感知，还是等保2.0中的“一个安全管理中心+三重防护”的要求，都可以与SIEM进行契合。

2.内部驱动

以SIEM为抓手，帮助企业内部各层面人员开展安全运营工作。

领导层：

可纵览安全现状和决策：这里特指CIO这个层面，他们普遍对于业务非常熟悉，也懂部分技术。他们的职责是规划信息化建设，搭建IT团队，向上层汇报获得老板的支持，为企业降本增效和体现个人价值。那一个运营良好的SIEM可以帮助CIO判断现有安全现状，如安全态势展现、攻击可溯源、工作量可视化。

运维层：

可集中管理和舒心运维：运维人员考虑的是确保各服务安全稳定的运行，及时发现可以安全事件。他们的点在于保障业务对老板有交代，同时在运维中尽可能的便捷和自动化。通过SIEM可以解决分散日志的管理、解决各安全产品多控制台界面查询、解决设备间联动、告警事件工单流转、并可依托此平台进行攻防演练，提升自身应急响应能力。

业务层安全：

业务更多的关注系统的可用性，以及业务数据分析挖掘给他们带来创收机会。SIEM通过收集业务埋点数据采集，分析业务关注的指标点，并结合场景给到一些建议和提示(不能替代风控产品)。

SIEM投入产出

如果问这个解决方案贵吗?回答是，相比其他安全产品会略贵。但是这个投入主要看怎么衡量，如果采购了只是安全团队自己在“玩儿”(产品定位主打安全可再看下定义)，那只是少部分人在使用，并没有充分发挥它的价值。在实施之前因充分评估，特别是跨部门跨团队的场景协作(起初肯定应该定位在安全场景用例)，用的人越多参与的需求越多，性价比就越高。

SIEM架构

编辑搜图

SIEM的整体架构大致如上图所示，以一条Windows系统登录日志为例，来过一遍经过的所有流程。

1.日志采集

当用户成功登录windows电脑时，会产生一条Event ID 4624的日志，系统会记录下很多信息，包括但不仅限于时间、IP地址、系统版本、登录类型(本地或远程)、用户名、登出状态。

2.范式化

在SIEM中就是把这一整串的原始日志进行拆分，并按厂商定义的说明或者企业自行定义来丰富标签内容。

编辑搜图

3.事件过滤归

并就是把同类型的日志进行归类，如windows、Linux的登录日志其实格式是不一样的，可以归为2大类。并把暂时不关注的字段筛选去除，把需要关注的内容提取出来。

4.关联分析

这部分内容是SIEM的精髓，如何制定策略使误报率低，并产生有价值的场景(usecase)是各使用相关方需要重点考虑的。当然场景制定的优劣离不开日志源的质量、分析人员的经验等多方因素。继续以上为例，可以定义在30分钟内记录张三共产生了多少次登录行为。

5.告警

如果30分钟内有上百次的登录行为，那我们要判断下是否电脑有被入侵的可能?如果30分钟内有5次左右登录，那会不会张三同学上班在摸鱼呢(勤接水勤走动勤登录)? 具体告警阈值和产生结果的判断，由各位充分发挥想象或者根据实际情况来制定。

6.安全事件运维

就是根据产生的告警来判断和处理。可以人工处置去现场或者电话确认情况。如被确定为高危行为也可以联动相关产品进行实时封禁操作。

7.可视化展现

设定预制报表，定期出具一份统计结果。也可直接在大屏展示以上事件的结果，如攻击事件+1 或 摸鱼事件+1 (UEBA用户实体行为分析更偏向此块内容分析)

SIEM关键技术指标

• 底层数据的收集和管理

这块个人觉得是最重要的内容，如果最基础的日志收集和管理都不稳定，那上层的分析和告警必定会受到影响，至少应该支持每日TB级的数据收集和管理能力。日志来源包括内部本地和云环境的日志。

• 架构和部署

这块主要指系统的横向扩展能力，如有大型企业涉及多个分公司的情况，架构应能适应异地的扩展和日志的同步。

• 分析检索

产品应支持统计学模型和AI算法(ML机器学习、NLP自然语言处理)方面的能力。

• 异构产品协作

与其它安全产品的协作能力，如果选购的SIEM产品只支持同厂商的安全设备联动和对接，后期涉及自动化编排和联动等都会造成约束。

• 易用性

产品界面的易用性设计，对于运营人员的体验来说也非常的重要。

• 技术栈

产品各模块实现所使用的技术栈是否稳定、安全、主流等也是需要进行考虑的问题。

• 实施人员

SIEM项目的建设同样需要考虑项目团队的实施经验和能力，一个具有丰富经验的实施团队，对于项目的完美交付绝对起着至关重要的作用，他们能快速准确的理解客户需求，将人、技术、流程进行合理串联设计，并擅长疑难问题的排错。

SIEM建设建议

1.需要有一定的安全建设基础才开始SIEM之旅。

这里的安全建设指安全产品的部署，如杀毒软件、终端管控、网络准入、VPN、上网行为管控、数据防泄漏、IDPS、防火墙、WAF、流量探针、主机安全、蜜罐、微隔离、EDR、威胁情报、漏洞扫描、邮件安全网关、堡垒机等。并不是说没有这些设备不能开始SIEM的建设，但是SIEM更多的还是考虑威胁方向的发现。如果没有足够的上下文和数据源关联，SIEM就不能被充分利用。同样的道理CMDB、应用服务器和系统日志也同样重要，比如应用服务器访问日志可以用来确定WAF或者IDPS上的攻击是否成功，如果没有相关数据SIEM的判断也是不精准的。

2.建设之初做好整体规划，包括项目的范围和期望输出价值。

范围指的是定义好最终交付场景的方向。一般分为威胁类方向、合规类方向、业务类方向。根据范围考虑每个方向输出的价值：

威胁类：

更多的是企业安全团队优先考虑的问题，可能是现有安全产品和系统日志层面的组合，发现互联网侧和内网侧的可疑攻击风险，做的更好的可以结合威胁情报和ATT&CK框架，观察和发现攻击者的TTP(技术、战术和过程)。

合规类：

更多的可以和内部合规团队沟通，将他们的审计要求体现在输出中，如防范内部人员数据泄露、运维人员异常操作等。

业务类：

为业务赋能相对于前两者的优先级会靠后一些，但不影响在建设初期协同参与讨论。如针对特定业务场景的风险控制指标的监控，重复报表工作的优化等。

以上的这些方向可以分阶段、在充分考虑优先级和资源投入的基础上做一个统筹规划。

3.现有安全产品的性能考虑

在开启安全日志分析后产品的资源利用率，比如CPU、内存、I/O、存储的增加是否会影响现有产品输出内容的质量。

另外这些安全日志是否可以被读取到，是否存在技术限制不对外提供接口，这些都是在建设前需要调研和考虑的问题。如果已经有集中日志管理平台，建议从它入手优先获取数据。

注：SIEM和集中日志管理平台还是有区别的，SIEM收集和存储的每条日志应该是更有价值的或者说经过初次研判后的日志，用以发现威胁、取证或者合规等方面。如果已经有集中日志管理平台，那他与SIEM的使用场景和定位也是需要考虑的。

4.不要试图一次性将所有可接入的日志源导入SIEM平台，而忽略思考日志未来产出的价值和后续跟进，如场景、运营、报告、展现等方面。

建议：围绕场景展开工作，将安全团队、合规团队、业务团队最关心的场景做个优先级排序。从那些投入小但展现价值高的场景入手。

比如，安全团队原来要登录多个安全平台排查的问题将优先考虑。比如，合规团队以往定期关注的报表自动化展现。比如，业务团队关心的某个监控指标。建设初期充分讨论这些场景，以及为了满足这些场景所需要的日志源。

这些调研和头脑风暴是真正有价值，是项目初期成功的关键，也能有效的论证商业产品。会比直接使用开箱即用的场景更具价值，当然这些开箱即用的场景可以作为引发思路。

5.场景创建

• 把您最关注的各类安全平台日志威胁在SIEM中呈现(单一策略未做多场景联动)，减轻跨平台监控的工作量。

• 建立如上那些有价值的场景，这些场景中的策略明细以最小化满足的方式接入。比如，不要试图把杀毒管理控制台中的所有告警日志都发送到SIEM平台，而考虑把未部署的杀毒软件终端数量和IP地址引入，或者把离线的杀毒终端信息在SIEM中展现，以便后续的运营跟进处理。

如果您觉得仅从杀软管理控制台的离线数据不能判断，那可以考虑网络层的数据和这台终端人员是否离职注销等信息来进一步完善这个“未安装杀毒软件”的场景。

虽然这个场景的设计是不合理的，因为杀软会ping这台终端是否存活，不一定需要网络层的日志，人员离职与未安装杀软的关系也不是特别大，但是这边想要表达的核心思想是最小化日志接入，不要试图把可能与该场景有关的所有日志接入，这样只会产生大量的噪声和误报。只有当现有的日志不满足场景时才陆续将可能辅助产生最终效果的日志接入，并陆续调优。

• 不要试图一次性调优多条策略。

首先，策略的准确性是需要一定时间验证和优化的，可能是人为模拟触发或者真实安全事件的触发。 这种触发到最终SIEM平台的告警展现的实时性和误报可能是需要判断和调优的。

其次，安全事件的落地闭环过程中人和流程也是需要去制定和磨合的。正常运营人员在系统、网络、业务人员配合的情况下，一天能处理并最终确认的事件也就2-3个，不排除复杂和不能及时反馈的情况。所以SIEM实施过程中人和流程也是需要提前考虑和设计的。

再者，部分场景的策略涉及模型的学习时间，不是部署初期就特别准确的，需要持续跟进验证策略的有效性。

• 创建多个临时监控指标(watchlist)，作为黑白名单知识库参数，在后续其他场景的创建中嵌套这些黑白名单库，以提高研判的准确性和排除误报。比如从WAF攻击行为中提取攻击IP地址，作为黑名单池保存，并与其他攻击场景或防火墙日志做关联，当匹配此黑名单IP池时，判定为高威胁安全事件。再比如，读取由某业务系统中产出的白名单用户列表，与现有的“风险用户清单”场景做匹配，作为排除指标，以降低告警误判。

• 如果某些日志源在SIEM平台中难以处理或者会增加现有SIEM平台的性能开销，那可以考虑将这些日志暂时导入到独立的服务器中，在这台服务器上使用批处理或者脚本，对数据做二次加工后再录入SIEM中协同。

• 将一条场景规则从产生到最终人员落地闭合的运营流程梳理清楚，并与相关协同人演练顺畅后再步入新场景的建设。如果有分公司的情况，建议将此场景在分公司演练到位。这样做的好处是让大家知道有这样一个平台存在，其次是大家以可接受的工作量来熟练每一个场景。如果在项目初期就把所有的场景投入使用，且没有相关运营支撑，会让最终处理人员手忙脚乱，压力巨大。不但没有优化运营，而且会增加很多额外的工作量，并让配合人员抵触此平台。只有持续运营优化场景调优策略，解决相关方的根本需求，才能吸引更多人参与进来。

• 创建一个场景跟踪清单，列清楚需求方和目的，创建时间，使用到的日志源，策略优先级，策略场景分类，策略阶段(调研、新建、调优、投产)，策略的运营处置人，策略更新记录等。

6.报表和展现

这块主要是对分析后指标的呈现，过程中需要考虑汇报的对象是管理层、运维、安全、合规或业务相关方关心的指标背后带来的价值。通过数值、直方图、饼图、趋势图、百分比图、TopX等多种角度多种维度对数据进行分析呈现，并以不同对象可接受可理解的方式呈现。如果企业对于SIEM提供商给到的呈现不满意，想优化展示界面，也需要提前考虑从团队内部或者外部招聘前端工程师和UI设计师来完善相关工作。

7.维护工作

成功的SIEM部署需要专业的人才储备，一旦有任何威胁告警，将不可避免对发现的事件进行响应。人员需要配合环境的变化进行持续的调优和维护，这些变化包括威胁、合规要求以及数据源采集本身。在项目开始之前您至少需要考虑以下3类人才：

编辑搜图

因此，不仅需要有足够知识的员工来管理和维护SIEM，而且需要为SIEM带来的额外工作做好心理准备。事件需要被审查和处理，流程需要被制定，还要考虑与其他部门和团队的协作。这些都是需要提前准备和思考的而不是找到3名适合的员工就能开展的工作。这个过程中还不排除员工的事假、病假等额外因素，如果需要7*24小时的安全事件监控操作，人数还需要进行翻倍。

最佳实践：控制项目范围和聘请外部服务供应商

SIEM是一种有效好用的工具，它能够使特定的工作和场景更高效的执行和展现价值，但它不会完全自己运行。以下2个方面建议可供参考：

• 限制项目范围

就是在项目开始时控制本次项目的范围和需要达到的目的，将项目规模和资源进行可行性匹配。配合实际风险和企业风险偏好来制定优先级，还是围绕场景、日志源、报表、流程和产出价值去落地项目。并在后续年份通过二期、三期项目的方式持续迭代扩展。

• 聘请外部安全服务提供商

如果企业有一定的规模及合适的人才，完全可以在分析考虑清楚之后开展建设工作。如果企业由于缺乏内部资源或专业人才，可以考虑统SaaS化部署+安全管理服务(MSS) 的组合来落地此类项目，通过外部力量帮助企业显著提高安全能力，而无需进行大量的软硬件和人员投入，交付中包含持续运营和管理，而企业本身更多的关注安全场景和业务需求。托管安全服务提供商(MSSP)提供对安全事件的实时监控和分析，并通过他们自己的SIEM解决方案来进行日志收集，并应用于报告和调查。

注：管理安全服务(MSS)是为那些希望更多的减轻网络安全责任企业提供的选择。通过MSS，一个可信的合伙伴将协助处理公司的部分或全部安全流程，MSS可以在内部或远程进行。公司获得了MSS合作伙伴的分析人员和运维工程师的经验和技能，他们可以提供从安装到威胁检测到响应等系列服务。

8.云上SIEM的思考

近几年疫情的流行改变了许多企业的战略方向，特别是云计算的可扩展性、弹性计算、云上安全组件等优势，让原来较多不愿尝试上云的企业转变为主动拥抱云，并且思考云上的架构、云上的安全、云上的运维和云原生等问题。SIEM在云上运行您可能需要考虑的问题：

带宽：

云上SIEM需要一定的带宽来获取企业内部数据以及访问云上的用户界面。如果企业内部没有足够的带宽为基于云上的SIEM提供

它所需要的日志文件和访问SIEM的用户界面。那云上的可扩展性和弹性优势将享受不到，反而带来一些网络问题，这块是需要考虑和评估的。

数据安全：

虽然SIEM的常见作用之一是合规和满足监管要求，但在选择云SIEM解决方案时，也可能有监管、数据安全、法律方面的限制。

鉴于以上原因很多企业都在使用混合云管理。就是将企业内部的计算、存储和服务与公有云中的服务连接起来。混合云允许企业保留对内部敏感数据的控制，同时利用SaaS的相关优势。这种设计可以解决许多监管方面的问题，并使云上SIEM变的更为可行。

您可以考虑把SIEM部署在私有云中(下图标红)，或者部署在云上的专属云中(下图标绿)，并通过采集器和云上接口将数据同步到一处后再汇总分析。

编辑搜图

9.云上SIEM中的角色和责任

对于不想在SIEM上投入太多资源的企业来说，由托管安全服务提供商(MSSP)来执行是一个很好的选择。但是首先需要清楚的了解角色和责任。这里将用到RACI矩阵来直观的明确企业、云SIEM供应商和MSSP之间的关系。

编辑搜图

注：谁负责R = Responsible, 即负责执行任务的角色，具体负责操控项目、解决问题。谁批准A = Accountable, 即对任务负全责的角色，需经过他同意或签署之后，才能进行。咨询谁C = Consulted , 拥有完成项目所需的信息或能力的人员。通知谁 I =Informed ,即拥有特权、应及时被通知结果的人员，却不必向他咨询、征求意见。

总的来说，云SIEM供应商更多的职责是初期建设部署和围绕他们自己产品的功能更新等工作。MSSP更多的职责是中后期的场景优化及事件跟踪处置。企业在这个模式中更多的是需求的提出和确认决策。

总结：在SIEM建设初期确认好项目范围和预期价值。过程中围绕场景、日志、流程开展推进，将每个场景落实演练到位后才进入新的场景。根据企业合规和资源投入情况，考虑本地数据中心或云上SIEM的部署。人员方面需提前规划准备或寻找MSSP合作伙伴协助落地。