PaloAlto的CTONir??Zuk于2018年首次提出扩展检测和响应（XDR）。在XDR的定义中，PaloAlto将其描述为“打破传统的安全孤岛，利用所有数据源进行安全检测和响应”。这不是家庭声明。随着业务上云和SaaS模式在全球范围内的流行，从所有孤立的平台和工具中获取数据并应用到一个安全能力——也就是本文所讨论的XDR——已经成为近年来公认的需求。然而，从概念到实施通常有很长的路要走。笔者认为，无论是单一厂商XDR还是混合XDR，要想在市场上取得成功，都有先天的局限性。单一供应商XDR的问题单一供应商XDR承诺用户可以使用一个开箱即用的产品成功实现多源数据威胁检测和响应，包括所需的收集、聚合、关联和分析功能。但是，指望某个供应商拥有最强的技术和商业能力，将分散的数据与众多独立的安全工具进行有效整合是不现实的。即使一家厂商声称自己能做到，也需要像行业巨头一样收购众多中小厂商，将众多中小厂商的能力分解、消化、整合成一套完整的安全能力。虽然需要将这些分离且独立的技术紧密集成以构建功能齐全的XDR平台，但商业利益非常有限。此外，XDR的出现主要是为了应对安全信息与事件管理（SIEM）和安全运营方面分析能力的不足。但是，作为最早的多源数据采集点，SIEM的规则和分析能力导致了大量的告警和大量的误报。包括后来出现的安全编排（SecurityOrchestration）和自动响应（AutomatedResponse，SOAR），如果它们都不能帮助我们在汇总数据后通过上下文或相关信息提供准确的安全分析能力，并给出可靠的响应决策建议，我们为什么认为XDR可以吗？尤其是在数据的种类和数量越来越难以集中的今天。最后（其实不止这三个），对于这个单一供应商的XDR平台，客户需要放弃并更换他们投入多年的原有技术栈。你可以想象一下，当客户的CISO或安全团队负责人要求扔掉之前花费的所有时间、金钱和精力，而是将他们安全系统的所有鸡蛋都放到这一个XDR供应商的篮子里——这个供应商的承诺集中所有数据以提供更精确的检测和响应能力甚至尚未得到证实——客户的CEO或董事会成员将如何反应。混合XDR的问题在这种XDR模型中，客户可以购买混合了多个供应商的XDR作为单点解决方案。对于绝大多数自建安全系统的企业客户来说，这种模式解决了“裁减换代”的问题，但就像单一厂商XDR的问题一样，仍然需要安全中心来整合所有孤立的安全工具都放在一起。这就引出了一个新问题：谁负责做这件事？我们能否指望独立供应商接管代表客户无缝集成其他供应商产品的责任？即使供应商愿意，客户会愿意被迫注册托管测试吗？而Response（MDR），委以重任？这个安全中台能不能淘汰？其实很容易评价。如果没有中间平台，各种独立的工具和平台就无法整合在一起，也就意味着无法整合和利用所有孤立的数据，帮助安全分析师理解数据之间的关系，从而给出可靠的响应建议，最终意味着这意味着XDR失去了它最初的目的。还有一点需要考虑的是，我们已经看到了XDR类联盟的出现，其目的是解决联盟成员之间技术和工具在生态过程中整合过程中出现的问题，帮助分析师提高威胁检测能力和反应能力。但是，这样的组织仍然是封闭生态，会限制客户只能采用联盟内供应商提供的技术和工具。因此，客户仍然需要更换他们的旧设备，重新申请预算和资源，并花时间部署和实施这些新技术和工具。在大肆宣传之后，XDR是否还有希望实现其最初的目标？答案是肯定的。XDR供应商已经开始意识到安全中台的重要性，它需要处于整个安全生态系统的顶端，并提供对各种安全工具产生的所有数据的访问。问题是XDR的炒作能持续多久，也许再过几年，它就会成为“过去”的技术。当那一天到来时，这将只是数十年提高安全能力有效性努力中的一次新尝试。也许那时人们会看到似曾相识的结果，就像处理SIEM和SOAR的经历——数百万美元和多年的投资，换来的是对响应收效甚微的警报感到厌倦。这里的重点是，人们不应该将“炒作”误认为真正的价值，而只看首字母缩略词“幻想”就盲目投入。安全团队需要在购买和实施任何新技术之前进行尽职调查。此外，无论是XDR、SIEM、SOAR还是其他旨在提升安全能力有效性的技术工具，安全团队都应该考虑将它们加入安全中心。只有这样，才能将安全分析所需的数据从之前的一个子集扩展到所有数据，从而给出更准确的分析结果，做出更可靠的响应决策。
