最近一段时间 XDR 的概念十分热门，该产品主要是一个什么类型的产品？具体能够解决那些问题，和当前已有的产品有什么区别？

作为近两年最为热门的安全技术方向，XDR 成为被 Gartner《Top Security and Risk Management Trends》报告提到的第一项技术和解决方案。对于 XDR，虽然很多安全厂商给出的定义都不尽相同，但是却有这样一个基本的共识：它不仅是众多安全能力的集合，更将这些单独的能力进行全面协同，从而使之成为上下联动、前后协作的有机整体。虽然 XDR 仍处概念阶段，但其最大优势在于把此前已经发展相对成熟的安全解决方案进行融合，发挥各自长处形成功能更为完整的解决方案。

0x0 安全建设的意义与目标

稍微宏观一点的视角来看目前企事业在做内部安全建设的主要动力粗略分析后主要有 2 个大类：

基于合规驱动 基于安全事件驱动 基于合规驱动的安全建设目前按照时间的推移也被满足的较好，从项目难度来看也相对容易成果也更加容易体现和评估。但是随着最近几年日益偏向实战化的攻防对抗趋势逐渐凸显很多用户逐渐发现以合规为主要驱动力的安全建设并无法适应这种高强度的对抗场景，伴随着黑产的活跃暴露了很多安全建设的短板，更加频繁的攻防演练、攻击手法逐渐呈现高度定制化、定向攻击模式的勒索场景导致安全建设方的不得不抛弃以往堆砌安全设备的思路，从而走向主动化得安全运营的思路，在最近几年明显可以感知到安全效果、安全运营的标签活跃度快速增加；从安全产品的角度来看，安全产品的品类也更加丰富从偏向传统的防火墙、UTM、IPS、Anti-Virus、漏洞扫描逐渐变成了以态势感知、EDR、CWPP、API 网关、SASE、零信任、ASM 等更加丰富的产品族，安全建设始终存在明显的木桶效应所以安全建设方不得不更加疲于去发现安全风险，并针对安全风险进行针对性的缓解与修复措施；

安全设备多了碎片化的情况便就开始越发严重，安全管理者需要花费更大的成本去运维这些安全设备，除了基本的性能指标指标收集之外，也需要关注这些安全设备产生的告警事件，但是很多运维的同学缺少一定的攻防知识的基础导致无法准确明确当前的安全状态，于是出现了更加专业的安全运营人员主要分析这些不同安全设备所产品的告警；基于此背景，安全运维逐渐转向成安全运营的阶段，比较明显的趋势在很多企事业单位当中安全部门逐渐从运维部门、IT 部门分离出来新成立了一个组织；

0x1 SOC 与 SIEM 与 XDR 的区别？

安全运营工作的开展也面临着较多的挑战，首当其冲的无非是当前网络当中有很多的安全设备，分散在不同的区域、登录方式也不尽相同，运营这些安全设备传统的 SNMP 的方式亦无法满足此类需求。于是新出现了一类产品即 SIEM 类产品主要用于收集这些分散在各个 IT 设备所产生的安全告警，主要方式也驱动这些安全产品将有价值的告警事件通过 syslog、FTP、kafaka 等协议一起汇总到 SIEM 平台当中，而这个 SIEM 平台需要将不用产品的告警事件、日志文件、字段各异的数据进行统一的标准化处理，能够方便与安全运营人员可以快速的检索、查询、分析等操作，而且基于一些合规需求此类数据也需要保存一定的时间 180 天。由于很多安全建设方基于异构的思路出发不太会单一采购某一家安全产品导致不同厂家对安全的理解、字段的定义都不一样，也同样的为安全运营带了较大的误差；

典型的案例比如：

安全 A 厂商针对一个 web RCE 的主要使用 Snort 的规则引擎进行检测识别，定义为高危攻击、误报率在 10% 左右，字段描述、关键字段有 8 个；但是安全 B 厂商识别同样的攻击主要使用了 suricata 进行检测识别，定义为致命攻击，字段描述与关键字段有 20 个； 安全产品防火墙识别到了一个 Web RCE 的告警，终端的 EDR 识别到了一个 webshell 的生成，但是二个告警却是同一个攻击者的不同阶段的攻击行为所导致的，安全运营人员缺乏一定的安全场景理解无法将此二个事件进行关联剖析； SIEM 除开事件的分析之外，也存在较大的成本主要在于对安全数据的对接问题，由于安全设备的日志内容可能会随着版本升级、功能更新有所不同，也就意味着 SIEM 平台需要不停的去适配这些安全告警的变化，由此带来的工作量也并不少；虽然存在一些繁琐的问题，不过终究还是避免了登录到各个安全产品上进行事件的调查与查询，也算是提高一定的安全运营效率；在 SIEM 的基础上安全事件/告警产生之后，安全数据需要得到了一个有效的闭环，比如发现某个主机出现了一个病毒事件一般需要运维人员进行紧急的处置，使用杀毒软件进行病毒查杀，加固，清理后门文件等操作。但是很多资产都是业务方、单独的运维人员进行维护安全运营人员需要将此类的事件以工单的形式进行流转通知到对应的人员，单独的 MOA、邮件不方便于安全运营工作的价值化体现，于是在现在的 SIEM 平台上需要新增一定的安全运营流程化工作，结合工单、资产 CMDB、邮件系统等系统进行联动组件行为事件发现、研判、分发、处置、闭环的阶段安全运营的工作逐渐流程化、标准化。

比较成熟的 SIEM/SOC 类的商业化产品例如国外的 ArcSight 某国内有一些金融行业客户案例，但是为了用好这个产品也需要维持一个专业的安全运营团队，有较高的成本；于是开始思考是不是可以把一些常规的案例能够给固化下来，把一些安全专家的能力能够代码化，尤其是在一些典型的自动化攻击场景，最近几年的 SOAR 便逐渐走向的大众的视野，一旦出现了一个确定的告警之后，即触发一个标准的剧本 playbook 让程序与安全产品自动化实现处理闭环，从而最小化安全人员的精力成本。理想是很丰满的，落地的时候确实很骨感，安全本质上还是需要为业务服务，由于告警的质量不高如果贸然的告警十分容易引起业务的中断、高延迟、用户体验变得糟糕，同时一些敏感的行为很难通过自动化的方式进行处理，比如无文件攻击、进程注入、内存马、rootkit 等场景。

按照常识来讲 SIEM/SOC 平台汇聚了这么多安全数据，应该可以实现 1+1 > 3 的安全效果，然后实际情况却是 1+1 < 1；根本原因是采集到的数据来自不同的安全厂家的告警数据、来自于不同的位置的安全告警数据，平台无法做到自动化的关联分析，同时大量的低危告警、中危告警、反而导致了刷屏的情况发生，安全人员反而需要从大量的数据中去筛选那些真正有价值的告警都很困难，更别说做到关联分析了发现很多隐蔽的攻击行为了。

0x2 XDR 主要解决什么安全问题？

SIEM/SOC 由于汇聚了太多的告警数据反而没有把数据真正的价值给发挥出来，一个最主要的原因是无法对这些林林总总的数据进行较好的分类；当前 XDR 的出现在此的基础上进行了一定的改进，明确了不同类型的数据来源即 NDR、EDR，将安全数据简单的分为网络层数据、终端层数据；可以明显的发现 XDR 的产品往往对采集数据的标准化进行明确的规定，从而保证了数据格式内容的标准化，只有符合一定格式标准的数据才能产生价值；对于很多来源不清晰的数据，便使用的 SIEM 的模式将重要性进行降低，目前也仅仅能做到的快速的检索查询，较难实现关联分析的能力；同时将符合标准的安全的数据进行了明确的分类即当前的日志 log、告警 alert、事件 incident/event 与遥测数据,之前安全产品为了更多的保证安全能力的检出往往不太会考虑安全人员在使用的过程当中的困境，导致很多规则、告警质量都不太高，当然一部分的原因很多用户的环境当中也有很多特殊性，导致业务的误报也很多，安全人员操作起来也很困难。XDR 需要解决的是，将这些告警与日志通过一种特殊的分析方法汇聚成确定的 incident 事件，从而尽可能性的减少分析研判的工作量。

以往的告警为何无法满足此需求，一定需要更多的数据？这个原因主要是因为当前越来越多的攻击的隐蔽性更加丰富，单一来源的数据基本上无法满足需求，当前主要检测攻击成功的方式普遍采取了基于 HTTP 协议的回显、懂渗透的小伙伴应该是很清楚的大部分 web 攻击是有回显的，类似于有个交互没有回显的漏洞越来越多了，比如最近新出来的 Spring Cloud Function 的表达式注入 RCE、同样也是无回显类型的漏洞攻击者就的借助 JDNI、DNSLOG 等方式进行利用从而导致了此类攻击成功基本上就无法被识别；典型的案例如前几个月新出的漏洞 log4j，该漏洞的原理就不细细分析，改天可以单独拿出来看看。传统的 NDR 能识别这个攻击比较简单，但是这个攻击是不是攻击成功了，后面进行了什么操作，需不需要联系对应的负责人进行响应，就陷入了两难得情况；

如果但从这个数据包来看对攻击成功与否无法进行一个明确的标识，返回了 400 报错信息都反应出来的结果是没有成功的，但实际情况这是一个真实的攻击成功场景。该 payloda 主要是在 tmp 目录下创建几个文件，单一的流量检测无法识别的背景下结合端侧的数据可的确是可以发挥更大的价值。实现 1+1 > 3 事实上是可以实现的，但是需要的数据是有价值与明确的场景，而不是数据越多越好。

之前为什么没有出现这种问题？个人觉得主要还是实战化攻击的趋势导致的结果，笔者参与了 3 年国家级 HW 活动，作为蓝队感觉一次以比一次难阻止。最开始的基础漏洞利用到后面的加密流量、横向、CDN、0day 的攻击，传统的安全设备防护能力无法适应当前这种情况，尤其是在高强度的对抗过程中，安全运营人员需要从海量告警数据当中能够有快速发现，快速定义有效攻击事件，为什么是海量告警？一方面是攻击队的战术、一方面的安全设备种类都，一方面是为了保障检出告警策略都比较松。但是从安全的全局来看，我们定义的有效攻击主要还是攻击成功与失陷检测；大量的攻击能够产生实际危害的比较是少数，大量多攻击者、自动化攻击往往需要用很多的尝试才能成功，所以如何筛选出这一个成功的就是一个技术活；另外一个场景是攻击成功之后，攻击者后续的行为也需要有个方法进行识别，典型的场景的外联、爆破成功、内网横向扫描、持久化后门操作等等；

基于此背景可以定义一下 XDR 的核心能力到底在哪里或者说能给使用者带来怎么样的价值：

基于多源数据所得出的的准确安全事件，而非基础的海量告警； 丰富的数据在实战化场景识别，识别隐蔽攻击事件； 快速检索当前网络当中所有的安全数据； 相对其他基础安全产品的强调安全检出率的核心能力，XDR 的核心能力却在于如何能够将多源数据进行分析的关联能力，从技术上来看之前的态势感知的核心能力是提取高质量 snort 和 suricata 规则、分析能力的 APP 的话，XDR 的能力在于基于 Flink CEP 的框架编写检测规则的思路。数据量也存在一定的差距，相对于基础的 IDS 类产品主要分析对象集中在特定的文件，安全能力主要用户去消费此类文件数据；XDR 分析对象变成了广泛数据接入的数据湖 data lake；关联分析的能力个人理解主要有 3 点：

明确具体需要解决哪一类的安全问题/场景 (反弹 shell、加密通信) 为了解决此类场景需要哪些带分析的数据 (遥测、日志还是告警) 将不同的数据汇总到一起，用于相互举证相互印证； 安全类的 DR 产品普遍都有检出率、误报率二个技术指标；安全研究人员多数时候在识别一个攻击行为的同时都会明确当前的这个场景，误报和漏报到底谁的影响的更加一些，因为攻击行为大多数都是不容易被感知的，大多数安全产品普遍会牺牲检出率保障误报率；而且使用者在评估一个安全产品的时候更多的会说：这个产品不行，误报告警多的不行；如果没有异构的场景可能连漏报了也无法被感知到，如果不是每年的 HW 活动很多安全产品都很难面临化实战化的校验，不得不说当前安全测试的人才是缺少的，仔细想想能做红队大家又何必去做测试呢。于是在 XDR 的场景的多数据要求下，是需要既要保障检测率也要保障误报率的，技术上可行吗？如果遥测数据和关联能力梳理的恰当的化，理论上是可以的，而且国外的 crowd strike、PA-Cortex XDR 基本上已实现了该功能，还结合多源的数据对威胁事件进行定性，有数据的确是万能的安全行业逐渐也变成了互联网模式的，基于大量的数据分析驱动安全检测。

0x3 网络/终端谁更重要?

鬼佬们在 XDR 的方向更多喜欢重 EDR 的能力，将大部分的能力都放在了终端的数据采集和检测上，终端上除了能够采集到对应的网络、文件、进程的操作，还能关联到对应的进程启动顺序，pid、敏感 API 等操作，理论上的数据面会更加丰富一些，windows 上的 sysmon 就是一个非常 nice 的组件；但是在终端上需要考虑到对系统资源的占用、对业务的影响、网络与磁盘 IO 的占用、系统稳定性等多个因素，之前学习 windows 核心编程的时候给电脑弄蓝屏都是常事、更别说当前的系统监测。相对网络上的检测方向，明显技术性更强门槛也更加高一些，终端测得采集数据也更加需要注意之前内部孵化容器安全的产品时候本着重平台轻终端的方案，结果一个容器一天的采集到的行为数据居然高达 1G 之多，对网络与磁盘 IO 的影响已经很多很多，端上的核心能力的确在于如何能够采集到最少的数据而发挥更大的价值，而不是一股脑的全部收集上然后慢慢分析，这个工作路程的确是需要很长的路要走。相对终端的复杂，当前网络层的技术就要成熟很多，开源的技术与流量镜像技术都比较成熟而且总体上来看对业务基本上都没有什么影响，交换机的镜像资源也可以接受，所以国内普遍还是喜欢这种流量镜像的模式，部署维护都要简单便捷很多，但是检测到的数据就相对有限了，最典型的例子在 5 点：

加密流量、CDN 流量、https(证书解密性能消耗十分严重) 目前都没有办法进行有效的识别； 主机侧的凭证窃取、持久化、痕迹清理、信息收集均无法识别； 很多基于汇聚层交换的恶意攻击行为无法被镜像到，镜像流量缺失情况严重 大规模流量出现的时候容易出现审计流量不全或者缺失的情况 云上主机的流量无法进行镜像 可以明显感知虽然终端上的技术成本更高，但是从安全攻防的场景出发对攻击者的识别能够采集到的数据，明显端上的能力会优势点更多一些，也更加符合业务上云之后的一个大趋势；网络层的能力适合于一些攻击者初始入侵、CC 通讯的场景，终端能力更加适合后渗透阶段的各类行为，如何将二者的能力进行融合，也是当前 XDR 厂商需要思考的关键问题之一；

0x4 检测响应与访问控制

安全建设到时候发现有效的思路主要就 2 个：

检测响应趋近于安全运营中心的方案,快速发现、快速响应、快速闭环； 基于访问控制的隔离，保证攻击者无法进行有效攻击，即当前热门的零信任技术； 响应技术从目前的手法来看，还是投鼠忌器的场景多一些；常见的手法主要就封堵 IP 地址、隔离主机、隔离进程、隔离文件，换一个角度看即网络隔离、进程隔离、文件隔离；一个恶意攻击或者样本运行之后的行为，实际上是不可控的，更改了一些系统关键项目或者感染了一些特定类型的文件、创建了某些服务、利用了系统进程等场景，即使再专业的 SOAR 也无法对这些行为进行处置，无非也就是下发 API 调用防火墙、交换机等网络层设备进行特定的 IOC 进行封堵隔离，再下发 API 到终端的 EDR 进行全盘文件查杀，特定文件查杀，注册表清理等不影响业务的场景；那些难以查杀的病毒或者后门最后只能靠安全专家评估后进行操作，就算是真的靠安全人员大家都是很慎重，毕竟业务终端、系统蓝屏的影响大的多了，很多业务应用本身就脆弱，重启后服务不正常的情况也屡见不鲜，从业务负责人来说很多问题主要不影响业务都可以不清理，比如什么挖矿、rootkit 不就占用一些资源、发起一些链接么，反正业务也正常跑着，都可以接受；相对于一些业务的影响，挖矿的影响可能更加小一些，当然此类思想不值得鼓励。

0x5 关于未来

之前主要做态势感知的时候，就明显感知到网络层的安全能力很有限；尤其在自定义工具、与隧道通讯、以及各类魔改的流量特征之下，对端上数据的需求越发强烈；同时安全运营的工作会越发重要，不仅仅是在安全的乙方、甲方当中安全运营的需求也会有一个快速的增长；未来的 XDR 逐渐会以端上的数据为主、流量层的数据为辅的进行能力的构建，各个产品的同质化情况更加明显，核心能力会聚焦在异常检测上，结合安全人员对能力的强运营基于 PDCA 的模型持续对安全能力进行打磨，当前用户侧的安全运营中心逐渐行为以 XDR+SIEM+ 工单系统的模式进行分工；

2021 年 RSA 提出的一个最新的框架，帮助企业在安全建设当中掌握主动地位； 目前攻击者主要的思路都是利用攻击手法影响用户资产的 CIA 三 个属性，于是把更多的中心放在了对数据的保护和抵御攻击者的思路之下，根据 DIE 理论框架用户可以用另外的思路解决这个问题。 这个思路相对比较纯粹、攻击者利用使用 DDOS 攻击影响资产的可用性，那么用户就可以针对业务进行分布式的部署。攻击者篡改了内部的敏 感数据，用户可以通过回滚的方式让数据恢复到原始状态。攻击者进行高级持续性的攻击，用户就将数据进行化整为零减少单个资产的信息量避 免对机密性造成破坏；

相对于检测响应的大量投入，基于访问控制 (70%)+ 检测响应 (30%) 的模式会更加符合安全建设的目标，即大家常说的七分管理、三分技术；

原文链接：https://blog.csdn.net/momo_sleet/article/details/124062055