当前模型 网络安全 被打破。 它包括获取和部署许多独立工具，每个工具都有自己的控制台，以分析日志或流量并检测可能构成威胁的异常。 在此模型中，每个安全分析人员都需要与其他分析人员进行交流，以确定每个工具的单独检测（每个工具本身看起来都是良性的）是否可以与其他工具的其他检测相关联以揭示复杂的攻击。
该模型迫使企业创建复杂的安全堆栈，其中包括 SIEM, SOAR, EDR, NDR 以及为检测企业，识别威胁，对威胁做出响应以及管理风险的目的。 购买所有这些工具并管理其许可证既复杂又昂贵，并且比较每个工具的检测结果所需的手动关联在整个安全基础架构中留下了许多空白。
这些系统还经常向分析师轰炸误报，从而引起“警惕疲劳”和工作不满。 甚至对自己的存在感到满意的企业 SIEM 其他工具将承认，他们花费大量时间和精力来建立一个多工具安全性基础架构并没有取得必要的结果。
案例 XDR
XDR 或 扩展的检测和响应已经演变成任何执行检测和响应技术的通用定义，因为在这个缩写中，X 实际上是一个变量。虽然 X 可以代表“端点+”或“网络+”，但这忽略了企业目前面临的工具孤立、数据不相关和警报疲劳等痛点。 XDR 目的就是为了解决这个痛点，因此 X 必须代表“一切”。“一切”意味着采用平台方法，通过检测和响应来覆盖整个攻击面。
这种平台方法可以通过以下方式修复当前存在缺陷的模式：将孤立的工具转换为统一的工具集，将不相关的数据转换为动态的、关联的攻击面表示，并将警报疲劳转化为安心感。一项技术如何实现这一目标是关键的架构问题。有两种类型的…… XDR 今天：开放和原生。
开放式 vs. 原生式 XDR
- Open XDR 通过开放式架构交付，该架构能够利用整个攻击面的现有安全工具的遥测和响应功能
- 本地人 XDR 由单个供应商的安全工具套件提供，该套件可在整个攻击面上提供遥测和响应
无论采用何种建筑方法 XDR 要成为平台，它必须满足以下技术要求才能被考虑。 XDR:
- 可部署性 – 云原生微服务架构，可扩展性，可用性和部署灵活性
- 数据融合 – 遍及整个攻击面的标准化和丰富数据，包括网络，云，端点，应用程序和身份
- 相关性 – 跨多个安全工具的高保真相关检测
- 智能响应– 来自同一平台的一键式或自动响应
关于一个常见的误解 开放式与原生式 XDR 因为它们是互斥的类型 XDR并非如此。 XDR 平台可以是完全开放的，也可以是部分原生的。例如，一个 XDR 平台 可以具有其供应商提供的一些内置工具，同时可以与其他供应商提供的现有工具进行公开集成。 这将启用可组合安全性策略，即利用现有工具的能力，同时允许客户在他们认为合适的时间和地点淘汰其中的一些工具。
开放平台与原生平台的构成 XDR 平台采取的方法是一种手段，而非目的：具体而言，就是平台如何对整个攻击面进行检测和响应。购买者 XDR 需要将架构方法视为实现目标的手段，并为企业做出最佳决策。
理想 XDR 开放
将会有一些企业没有问题，将其整个安全体系转移到单个供应商，并采用封闭式， 本地人 XDR 平台。 例如，还会有一些企业不太关心覆盖整个攻击面，而只希望对其端点进行检测和响应。 在这种情况下，他们应该追求 基于EDR的本地 XDR 平台.
但是，对于大多数企业而言， Open XDR 平台 必须将其视为首要任务。为什么？因为没有任何一家供应商能够创建或收购最好的云、终端、网络、身份等工具，所以原生应用才是关键。 XDR 该平台不会是同类最佳。此外，该企业极有可能已经 已经 在部署现有的安全工具上投入了大量的资金和精力–不想放弃这些投资，因此， 本地人 XDR 解决方案不会与这些工具进行交互，也不会捕获该企业的整个攻击面。 如果 Open XDR 平台 具有某些本机属性，可以覆盖成长中的企业的攻击面的某些区域，这非常好。 但是必须先打开。
最终，如果一家企业想要定义和执行可组合的安全策略并获得所有…… XDR通过平台交付的技术要求，一个完全 Open XDR 平台 是这样做的唯一现实方法。
