零信任策略下云上安全信息与事件管理优秀实践

一、SIEM概念及发展趋势

随着企业数字化转型的深入推进，网络安全越来越被企业所重视。为了构建完备的安全防御体系，企业通常会引入了防火墙(Firewall)、防病毒系统(Anti-Virus System，AVS)、入侵防御系统(Intrusion Prevention System，IPS)、入侵检测系统(Intrusion Detection System，IDS)、审计系统等大量安全产品，然而这些安全产品往往各自为政、缺乏联动，难以形成有价值的、全面系统的安全态势分析报告，也就难以应对复杂多变的安全威胁。

安全信息和事件管理 (SIEM，Security Information and Event Management) 正好可以满足这方面的需求。SIEM可以收集和存储来自各种网络、安全设备等日志和事件，并能够持续分析接入的数据，用以持续地进行威胁检测和合规性检测，帮助提升企业威胁响应能力;另外，SIEM也可以综合所采集的安全日志和事件，提供系统全面地安全报告，以便企业完整地评估系统风险。

1. SIEM简介

Gartner在2021年度的《SIEM市场魔力象限分析(MQ)报告》中将SIEM定义为满足以下客户需求的解决方案：

• 实时收集安全事件日志和telemetry数据，用于威胁检测和合规性检测;
• 实时并持续分析接入数据，以检测攻击和其他感兴趣的活动;
• 调查安全事件以确定其潜在的严重性和对业务的影响;
• 报告上述活动;
• 存储相关事件和日志。

2. SIEM发展趋势

与自然界事物的发展规律类似，SIEM也有一个从简单到高级的发展过程。

(1) 早期的日志管理系统

日志采集的需求由来已久，在计算机领域，日志一般用于记录计算机操作系统或应用程序运行状态或者外部请求事件。SIEM产生之前，安全场景主要是利用一些日志管理工具收集来自各种网络设备的日志，并进行统一存储，以便当异常事件发生时，可以进行事后的日志审计。

(2) SIM和SEM

到了上世纪90年代末，日志分析的需求逐渐强烈，开始出现了SIM(Security Information Management，安全信息管理)和SEM(Security Event Management，安全事件管理)两种技术。在SIM和SEM发展的早期，两者是分开的，比较公认的理解是：SIM注重安全事件的历史分析和报告，包括取证分析;而SEM则更关注实时事件监控和应急处理，更多的强调事件归一化、关联分析。

(3) SIEM

随着企业在IT建设上的持续投入，企业拥有了更多的网络设备和安全设备，会有更加复杂的网络环境，同时对企业安全也越来越重视。随之而来的是更多的安全数据需要处理，并且希望能够从众多数据中提取出威胁事件和安全情报，用于达到安全防火或合规审计的需求。之前单一的基于日志分析的模式不在适用，需要一种新型的工具满足安全分析场景的需求，SIEM的出现正好匹配上这些需求。

SIEM可以收集企业和组织中所有IT资源(包括网络、系统和应用)产生的安全信息(包括日志、告警等)进行统一的实时监控、历史分析，对来自外部的威胁和内部的违规、误操作行为进行监控、审计分析、调查取证、出具各种报表报告，达到IT资源合规性管理的目标，同时提升企业和组织的安全运营、威胁管理和应急响应能力。

(4) SIEM AS A SERVICE

随着企业数字化转型的深入，企业往往需要有更高级的安全分析的能力，同时SIEM也变得越来越复杂，想要掌握整套的SIEM系统使用能力要求也越来越高。托管式的SIEM出现，很大程度上降低了本地部署的运维成本，提供了更多开箱即用的功能，可以一定程度上降低SIEM的使用门槛，助力企业的安全能力建设。

(5) SIEM AS A UTILITY

未来SIEM可能会作为网络设备的基础功能，作为一个内置工具存在。目前越来越多的云厂商开始将SIEM方案内嵌到自家的云产品中，作为一个基本的功能与云产品基础能力打包售卖。

3. SIEM如何保护企业组织安全?

识别未知威胁：SIEM可以通过针对日志或者安全事件提供实时的数据监控能力，并结合人工智能、威胁情报能力，帮助企业发现潜在的安全风险。

威胁追本溯源：因为安全事件的发生往往会有个很长的持续周期(例如数据库拖库的表象是一次数据库拖库行为，背后可能隐藏着更早之前的某个时间的跳板机密码的泄露)，SIEM提供了对于历史数据的分析能力，能够长达几个月甚至更长时间内协助企业发现安全事件发生的蛛丝马迹，还原事件现场。

支持自定义审计：通过SIEM提供的开放的规则引擎，企业可以根据自身的业务场景配置一些持续的审计监控规则，实时监控网络安全。

及时威胁响应：当威胁事件发生时，监控规则会将探测到的异常通过告警等形式通知给相关人员及时进行响应处理，形成问题闭环。

二、数字化时代企业安全面临的全新挑战

1. 企业数字化带来了新的安全挑战

传统的网络安全架构理念是基于边界的安全架构，企业构建网络安全体系时，首先要做的是寻找安全边界，把网络划分为外网、内网等不同的区域，然后在边界上部署防火墙、入侵检测、WAF等产品。然而这种网络安全架构是基于内网比外网更安全的假设建立起来，在某种程度上预设了对内网中的人、设备和系统的信任，忽视加强内网安全措施。不法分子一旦突破企业的边界安全防护进入内网，会像进入无人之境，将带来严重的后果。此外，内部人员100%安全的假说也是不成立的，我们可以从《内部威胁成本全球报告》里看到，不管是内部威胁的数量，还是成本从2018年到2020年都有大幅的提升。

此外，随着云计算、大数据、物联网、移动办公等新技术与业务的深度融合，网络安全边界也逐渐变得更加模糊，传统边界安全防护理念面临巨大挑战。在这样的背景下，零信任架构(Zero Trust Architecture, ZTA)应运而生。它打破传统的认证，即信任边界防护、静态访问控制、以网络为中心等防护思路，建立起一套以身份为中心，以持续认证、动态访问控制、审计以及监测为链条，以最小化实时授权为核心，以多维信任算法为基础，认证达末端的动态安全架构。

我们可以看到，零信任策略下，监控无边界、持续监控的需求也给SIEM提出了新的挑战。

2. 数字化对工程师的挑战

随着DevOps的逐渐深入人心，工程师的开发职责也逐步发生了变化，开发、测试、运维逐步成为趋势。但是DevOps模式下，安全产品、安全能力其实是外置的，在整个软件生命周期中安全防护只是安全团队的责任，在开发的最后阶段才会介入。然而在DevOps有效推进快速迭代的今天，过时的安全措施则可能会拖累整个开发流程，由此催生出了“DevSecOps”的概念。

DevSecOps认为安全防护是整个 IT 团队的共同责任，需要贯穿至整个生命周期的每一个环节。DevSecOps更多关注的是过程安全，这种安全前置的理念，可以把安全植入到开发、测试、部署的各个环节，从源头上屏蔽掉一些风险。

DevSecOps分为了如下几个阶段，每个阶段都有自己的安全要求。左边的“Dev 段”，聚焦软件开发过程的安全保障;右边的“Ops 段”，聚焦软件运行时安全。具体阶段如下：

• Plan+Create 阶段，从宏观上可以认为是在进行软件的安全设计与开发前准备，更注重安全规则的制定、安全需求分析、软件设计时的安全考虑;
• Verify+Preproduction 阶段，即是对开发阶段进行安全保障，可以进行 AST、Fuzz、SCA 等;
• Predict+Respond 阶段，可以理解为软件的在网安全监测，比如监测和响应安全事件等;
• Configure+Detect 阶段，可以理解为对应用程序的运行时的安全保障，比如容器和基础设施安全、RASP、WAF 等。

我们可以看到，“Ops 段”涉及的威胁探测、应急响应、威胁预测与SIEM的特性是比较符合的，为了应对DevSecOps中安全融合、快速迭代的要求，对SIEM也提出了轻量化、便捷化的需求。

3. SIEM的全新挑战

基于上述的趋势，我们可以看到零信任(从不信任，始终验证)理念、DevSecOps都给SIEM提出了新的发展要求。新一代的SIEM需要满足零信任下无边界持续动态监控的诉求，就需要监控更广泛的数据，并提供更强的关联分析能力。为了提升DevSecOps的效率，就需要做的更轻量，作为一个基础的工具与DevSecOps进行融合，提供更多开箱即用的功能。同时，与可观测平台一体化融合也是一个发展的趋势。

4. 云上一体化SIEM平台

为了适应这些挑战，我们认为一个云上一体化的SIEM平台需要具备如下特征：

(1) 平台能力：

• 对包括日志、Metric、Trace和事件的数据提供统一的采集、存储能力。
• 在统一存储的基础上，提供统一的数据处理、分析，并且具备机器学习分析能力。
• 基于可视化的安全态势，告警检测事件管理能力。

(2) 业务场景：基于统一的平台上层业务，支撑上层业务方(开发运营、监控、安全、用户运营)。

(3) 生态对接：可以对接上下游系统的安全生态支持。

三、Cloud SIEM核心技术及行业方案

1. SIEM的核心技术及挑战

要实现一个SIEM系统，需要经过采集(Collection)-> 探测(Detection)-> 调查(Investigation)-> 响应(Response)四个阶段。四个阶段面临的挑战如下：

• 采集：如何将数据便捷接入的问题，以及如何低成本存储。
• 探测：如何通过各种数据的关联分析，捕获未知的威胁。
• 调查：如何审计安全事件及还原威胁过程。
• 响应：如何将安全事件通知给用户的能力。

2. 常用的行业方案

Splunk的思路是基于“将数据转化为一切(Data-to-Everything)”的平台，提供了一整套融合了SIEM、UEBA、SOAR的完整解决方案。

Elastic以开源为基础，通过Logstash、Elasticsearch、Kibana组合奠定了数据的基本采集、分析、可视化能力。其中，Logstash作为一个日志聚合器，可以收集和处理来自几乎任何数据源的数据;Elasticsearch是存储引擎，用于解析大量数据;Kibana作为可视化层，用于可视化处理及问题分析。Elastic 7.14 版发布了首个免费开放的Limitless XDR，能够在一个平台中提供一体化的 SIEM 和 Endpoint Security 功能。

Exabeam 的 SIEM 解决方案可作为 SaaS(Exabeam Fusion SIEM)使用，也可用于混合、联合部署。它包括 Exabeam数据湖、高级分析、威胁捕获、实体分析、案例管理和事件响应。基于定制部署的模块化架构，用户可以灵活购买。Exabeam 的机器学习 (ML) 驱动的用户和实体行为检测，能为用户提供风险评分和自动的上下文富化能力。

从上述的行业方案我们可以看出SIEM厂商普遍是平台化、SaaS的发展思路。

3. SIEM核心特性及落地方案

基于上文提到的SIEM平台化的思路，我们可以看到SIEM系统一些核心的特性(左图)，而右图是我们最佳实践的落地方案。

四、构建Cloud SIEM方案的最佳实践

接下来我们将重点阐述构建Cloud SIEM方案一些最佳实践，主要从如下四个方面展开。

• 广泛的数据接入：数据采集(特别是云上场景：跨账号、多云)、处理、存储能力。
• 统一的查询分析能力：交互式的查询分析语法、ML算法支持、可视化分析能力。
• 威胁探测和响应：使用内置告警规则和自定义规则进行威胁探测，将发现的威胁事件通知给用户，并能够进行事件管理。
• 安全生态集成：如何与第三方平台集成。

1. 广泛的数据接入

构建Cloud SIEM方案，首先要解决的问题是海量数据的统一接入问题。然而目前行业中涉及的接入方案众多，例如日志可能会使用logstash、FluentD等，指标会使用Prometheus等。这也造成了数据接入管理的诸多痛点：

• 运维成本高：完整的数据接入需要数个软件的协同，从而也带了极高的运维成本。
• 学习成本高：每个软件都有自己的使用插件及配置规则，学习成本非常高。

我们的方案是建立了标准化的数据接入方式，支持SDK及Agent采集两种方式，可以方便的将各类数据(日志、Metric、Trace、Meta)统一地采集到统一存储系统中。除了支持服务器与应用日志采集外，对于开源软件、标准协议也有很好的支持。最主要的是，针对阿里云云原生场景提供了一键式的采集方案，例如，日志RDS审计日志、K8s审计日志等;并且与阿里云资源目录集成支持跨账号采集的能力(因为很多企业可能会有多个账号，每个账号对应一个部门的业务)。

Cloud SIEM场景下，往往需要采集多种数据源的数据(格式可能比较杂乱)，同时也有长时间跨度、海量数据的分析需求，而我们的做法是提供了一套低代码、可扩展的数据加工服务，通过Schema On Write的方式提前进行数据规整，能够为后续的分析处理提供很大的便捷。

数据加工服务可以对结构化或非结构化的日志进行实时的ETL处理。该功能目前包含200+算子，广泛应用于数据规整、数据聚合、富化、分发等场景。对于安全场景，数据加工也有很好的安全类算子支持。例如，数据加工提供的数据脱敏算子，可以有效地减少敏感数据在加工、传输、使用等环节中的暴露，降低敏感数据泄露的风险，保护用户权益。常见脱敏场景有为手机号、银行卡号、邮箱、IP、AK、身份证号网址、订单号、字符串等敏感信息脱敏。

2. 统一的数据查询分析能力

Cloud SIEM系统一个重要的能力就是对采集到的数据，进行实时的合规监控分析，支持对历史数据的合规审计，对来自外部的威胁和内部的违规进行审计分析。但是，安全威胁的方法往往是一个逐步的过程，可能需要几个月或更长的时间才会真正暴露出来;此外，安全威胁可能需要多种数据的联动分析才能发现。

为了应对这些挑战，我们将日志、指标、Meta等数据全部接入到统一的存储中，在此之上，我们构建了一套统一的查询分析引擎，用于支撑查询分析、可视化、监控告警、AI 等上层能力。

基于统一的存储，我们构建的统一的查询分析引擎，以标准 SQL 为基础，进行了SQL 函数扩展，并融合了 PromQL，从而让不同的数据之间进行联合查询也变成了可能。

SLS SQL = Search + SQL92(Agg，WIndow，GroupBy…)+ PromQL + …

以下就是一个复杂分析的例子：

• 我们可以通过标准 SQL 语句对日志进行分析。
• 还可以通过 PromQL 扩展的 SQL 函数对指标数据进行分析
• 还可以通过嵌套查询，对指标数据的分析结果进行再聚合
• 此外还可以再通过机器学习函数，给查询和分析赋予 AI 的能力

虽然不同阶段的数据产生自不同的系统，也有着不同的格式，但是由于它们的存储和分析是一致的，我们可以非常轻松地实现统一的安全态势及安全事件监控。

同时，提供了大量基于AI的巡检、预测、聚类、根因分析等算法，以SQL/DSL函数的形式向用户提供，在人工分析和自动巡检告警中都能使用到。

3. 威胁探测与响应

通过上文提到的统一的数据接入、统一的查询分析能力，我们可以做到对安全威胁的基本的探测能力。但是要构建完备的监控体系，接下来就要解决如何持续监控的问题。基于这个问题，我们开发了一套一站式智能运维告警系统。它提供对日志、时序等各类数据的告警监控，亦可接受三方告警，对告警进行降噪、事件管理、通知管理等。

我们提供了超过数百个内置告警规则，开箱即用并持续增加中。这些规则库有覆盖了CIS(覆盖了账号安全、数据库安全等)和安全场景的最佳实践，用户仅需开启对应规则，即可享受到全天候的安全保障。

当告警规则探测到异常发生时，需要尽快的将威胁事件通知给相应的开发人员。我们对接了丰富的通知渠道，便于威胁事件的全方位触达。

• 多渠道：支持短信、语音、邮件、钉钉、企业微信、飞书、Slack等多种通知渠道，同时还支持通过自定义 Webhook 进行扩展。同一个告警，支持同时通过多个渠道、每个渠道使用不同的通知内容进行发送。例如通过语音和钉钉来进行告警通知，既可以保证触达强度，又可以保证通知内容的丰富程度。

• 动态通知：可以根据告警属性动态分派通知。例如：测试环境的告警，通过短信通知到张三，并且只在工作时间通知;而生产环境的告警，通过电话通知到张三和李四，并且无论何时，都要进行通知。

• 通知升级：长时间未解决的告警要进行升级。例如某告警触发后，通过短信通知到了某员工，但是该问题长时间未被处理，导致告警一直没有恢复，此时需要通知升级，通过语音的方式通知到该员工的领导。

安全事件发生后，如果不及时处理或不慎遗漏都会造成更大的安全风险扩展。因此，一定要建立完备的反馈机制，将安全问题处理形成闭环。基于这个问题，我们提供了安全事件管理中心，便于用户全局查看安全事件，并进行相应的管理动作。当开发或安全人员接收到安全告警事件通知后，可以登陆安全事件管理中心进行事件的确认、处理人的指派、处理动作记录等操作。

最后，我们提供了安全态势大盘，帮助用户全局了解安全事件、安全态势，便于进行告警链路查看及排错使用。此外，报表还可自由扩展。

4. 安全生态集成

现代企业上云后，有时会将业务部署在多家云厂商上，那么安全场景可能就涉及多家云厂商数据的同步问题。我们提供了与第三方SIEM方案(例如Splunk)对接的方式，以便确保阿里云上的所有法规、审计、与其他相关日志能够导入到用户的安全运维中心(SOC)中。

五、总结

我们总体上介绍了SIEM的背景趋势、以及数字化时代新的挑战，并且介绍了构建云上SIEM的优秀实践。

另外，我们可以看到云上SIEM也在朝着平台化、SaaS化的方向发展，并且不断的优化以适应新的业务挑战。