Compliance work is overdue for a new approach
TL;DR · AI 摘要
Elastic 推出基于 Elastic Agent Builder 的 agentic compliance skills,通过实时分析安全遥测数据,提升合规操作的自动化与解释性。
核心要点
- Elastic 使用 Agent Builder 的可组合技能模型实现 PCI DSS v4.0.1 合规技能。
- Agentic compliance 支持用户以自然语言查询合规状态,如‘过去30天的认证合规情况’。
- 静态仪表板无法满足合规操作中后续问题的深入分析需求。
结构提纲
按章节快速跳转。
- §引言
传统合规工作依赖静态工具,难以应对动态的安全环境。
Elastic Security 引入基于 Elastic Agent Builder 的 agentic compliance skills,提升合规操作的自动化与解释性。
PCI DSS v4.0.1 合规技能整合了范围发现、合规评估、字段映射和 ES|QL 执行等工具。
静态仪表板在合规操作中无法满足后续问题的深入分析需求。
Agentic compliance 支持用户以自然语言查询合规状态,提升解释性与操作效率。
思维导图
用一张图看清主题之间的关系。
查看大纲文本(无障碍 / 无 JS 友好)
- Agentic Compliance Skills
- Elastic Security
- PCI DSS v4.0.1 合规技能
- Elastic Agent Builder
- ES|QL 执行
- 优势
- 自然语言查询
- 实时分析
- 解释性提升
金句 / Highlights
值得收藏与分享的关键句。
Agentic compliance skills reason over security telemetry and run ES|QL-backed checks to explain evidence and identify data gaps.
Static dashboards are strong at the first view; they are much weaker at those follow-up questions.
Agentic compliance changes how teams work through that gap by allowing users to ask questions in plain language.
合规工作亟需新的方法 | Elastic 博客
合规工作亟需新的方法
作者:
Smriti
Mia LaVada
2026年6月11日
- 在Twitter上分享 在Twitter上分享
- 在LinkedIn上分享 在LinkedIn上分享
- 在Facebook上分享 在Facebook上分享
- 通过电子邮件分享 通过电子邮件分享
- 打印本页 打印
传统上,合规工作主要依赖于仪表板、电子表格、截图、审计包和特定时间点的审查。安全团队深知现实情况更加动态。审计人员所需的证据通常分散在身份提供者、终端设备、云平台、网络控制、漏洞扫描器、警报和自定义应用程序日志中——所有这些都生成实时的运营遥测数据,而静态工具难以跟上这种变化。
Elastic Security 在 Elastic Agent Builder 中引入了一种新的合规模式:基于代理的合规技能,能够对安全遥测数据进行推理,运行基于 Elasticsearch 查询语言(ES|QL)的检查,解释证据,识别数据缺口,并帮助团队从态势审查转向响应工作流程。
首次实现的是一个 PCI DSS v4.0.1 合规技能。
Elastic 不是提供一个独立的合规代理,而是使用 Agent Builder 的可组合技能模型。PCI 技能整合了用于范围发现、合规评估、自定义数据字段映射和 ES|QL 执行的专用工具。其结果是一种交互式合规体验,用户可以提出问题、验证范围、检查证据,并了解哪些内容仍需要人工审计验证。
这不是“一键式合规”;而是迈向持续、以证据驱动的合规运营的实际一步。
Elastic Agent Builder 中的 PCI DSS v4.0.1 合规技能
为什么合规需要超越仪表板
在合规运营中,仪表板仍然有用。它们为团队提供了快速了解态势的途径,突出了最大的缺口,并为合规工作提供了一个共同的起点。然而,实际上,这个起点很少是工作的终点。
- 审计人员想知道哪些系统在范围内。
- 分析人员需要了解失败控制项的底层证据。
- 平台工程师需要了解为什么某个来源被标记为不可评估。
- 合规负责人需要一份仍然包含评估时间范围、检查字段和对审计防御性至关重要的注意事项的高管摘要。
静态仪表板在第一眼查看时表现强劲,但在后续问题上则显得很弱。
基于代理的合规改变了团队处理这一差距的方式。不再需要点击面板并手动拼接证据,人们可以用自然语言提问,例如过去30天内身份验证的PCI DSS态势如何;要求8.3.4是否失败,什么支持这一结论;哪些与PCI相关的来源具有较弱的ECS覆盖;或者高管仪表板会显示什么,突出显示红色发现。
重点不是用聊天框取代仪表板。而是让合规答案变得可解释:评估了什么,发现了什么证据,置信度高还是低,以及接下来应该发生什么。这就是我们正在构建的交互模式——在你需要方向时提供摘要,在下一个问题到来时提供证据级别的深度。
许多 PCI 要求依赖于遥测安全团队已经收集的数据:认证事件、漏洞发现、终端活动、网络流量、恶意软件检测、配置更改和审计日志。
Agent Builder 中的 PCI 合规技能是围绕这种运营现实设计的。它可以帮助用户:
- 发现环境中与 PCI 相关的数据
- 通过违规检测和置信度评分评估 PCI DSS v4.0.1 要求
- 生成带有红/黄/绿状态的报告式评分卡
- 通过 ES|QL 查询和结果检查支持证据
- 识别数据质量问题,如缺少 ECS 字段、自定义字段名称和覆盖范围缺口
该技能有意限定为以证据为导向的遥测评估。它不能替代合格的安全评估员。它不会发出正式的 PCI 认证。相反,它帮助团队准备更有力的证据,更早发现遥测缺口,并将发现结果转化为响应操作。
PCI 合规技能如何在 4 个步骤中工作
该技能遵循一个四步的自然调查模式:发现范围 → 评估态势 → 检查证据 → 解决缺口。
第一步:发现与 PCI 相关的数据
该技能运行 PCI 范围发现,以识别相关索引并按类别进行分类 —— 网络、身份、终端、云、应用和漏洞数据。它估算每个索引的 ECS 覆盖率,使团队能够看到数据源是否已准备好进行可靠检查,或者是否需要规范化工作。
范围发现识别出与 PCI 相关的索引及其 ECS 准备情况。
第二步:评估 PCI 要求
该技能针对一个或多个 PCI DSS v4.0.1 要求运行合规性评估。每个检查返回以下内容:
- 状态:GREEN(合规)、RED(检测到违规)、AMBER(部分数据)或 NOT_ASSESSABLE(缺少字段)
- 置信度:基于数据质量和覆盖范围,分为 HIGH、MEDIUM 或 LOW
- 证据:带有受影响实体、数量和时间范围的具体发现
- 建议:针对不合规发现的具体修复操作
用户可以检查单个要求(“检查要求 8.3.4”),或对所有要求运行完整的态势评估。
合规性检查在一个响应中返回状态、置信度、证据和建议。
第三步:生成合规报告
该技能生成一个高管评分卡,包含总体评分、每个要求的详细分析以及红/黄/绿的可视化摘要。
高管合规报告提供一个可审计的态势摘要。
第四步:处理非 ECS 数据
并非每家组织的数据都完全规范化。该技能包括一个字段映射器,用于检查自定义索引并建议 ECS 等效字段。如果认证日志使用 username 而不是 user.name,字段映射器会识别该映射,以便合规性检查可以进行调整。
字段映射器帮助团队将自定义数据映射到 ECS,以实现可靠的合规性检查。
范围声明:使答案具备审计意识
最重要的设计选择之一是使用结构化的范围声明。每个 PCI 工具响应都包括记录 PCI DSS 版本、评估的索引、时间范围、评估的要求、检查的字段以及非认证免责声明的元数据。这为代理提供了一个具体的出处记录,可以在其答案中引用。
该出处对于合规性对话至关重要。只有当用户知道哪些数据被包含,哪些未被包含时,结果才有意义。
- GREEN + 高置信度的结果与 GREEN + 低置信度的结果含义不同。
- 带有支持证据的 RED 结果与由于字段缺失而无法评估(NOT_ASSESSABLE)的要求含义不同。
- AMBER 结果可能表示部分遥测数据、没有匹配事件,或者需要扩大时间范围。
通过在每个结果旁边展示范围和置信度,Elastic 帮助用户避免两种常见的合规失败模式:错误的确定性和无法采取行动的模糊性。
从聊天到自动化合规工作流
PCI 合规技能在聊天对话中非常强大。但当它与 Elastic Workflows 配合使用时,真正的运营价值才得以释放。工作流将一次性的聊天交互转变为合规即代码(compliance-as-code)管道,包括计划检查、用于趋势分析的索引结果、违规案件管理以及利益相关者通知,设置完成后无需任何人工干预。
每日计划评估
工作流将 PCI 技能从按需聊天转变为合规即代码。Elastic Workflow Library(security/compliance)中的 PCI DSS 每日合规评估示例(默认每天 06:00 UTC 运行,也可手动触发)调用 elastic-ai-agent 技能中的 pci-compliance 技能,将每个报告索引到 pci-compliance-results 以进行趋势分析,并通过您在 consts.notification_connector_id 中配置的连接器将相同摘要发布到 Slack 或电子邮件。
该流程分为三个步骤:评估 → 索引 → 通知,分别通过 run_assessment(ai.agent)、index_report(elasticsearch.index)和 send_notification(kibana.request)实现。完整的提示、评分卡格式和失败重试都在 YAML 文件中;请从仓库中导入工作流,而不是将片段复制到博客中。
从哪里开始:合规 README(先决条件和设置顺序)
通过工作流,自动化每日合规报告会发送到 Slack。
自动化违规案件创建
对于需要明确责任人和审计追踪的发现,使用工作流,PCI 违规案件创建器会运行有针对性的 PCI 检查(例如,输入要求并默认所有项),然后仅当评估结果包含 RED 发现时,通过 steps.run_check.output.message 上的 'if' 步骤打开 Kibana 案件,而不是进行第二次代理调用。案件由 securitySolution 所有,标记为 pci-compliance / violation,并在描述中包含完整的代理报告。
您可以按需运行它,也可以在每周计划(示例中为每周一 07:00 UTC)上运行。请参阅链接的 YAML 文件以查看检查提示、案件字段和日志步骤。
合规趋势仪表板
通过将每日评估结果索引到 pci-compliance-results,团队可以构建合规态势的时间序列。然后,Kibana 仪表板可以可视化以下内容:
- 最新报告内容
- 随时间变化的合规分数趋势
- 评估频率和覆盖率
- 用于审计准备的历史数据钻取
索引的工作流结果为持续监控提供了一个合规趋势仪表板。使用 Agent Builder 仪表板技能的强大功能创建仪表板,并根据您的需求进行自定义。
合规即代码模式
这些功能共同创建了一个完整的操作循环:
这将合规从周期性的人工审查转变为持续的自动化流程,同时保留审计人员所需的透明度和可检查性。
专为负责任的自动化而设计
PCI 合规技能的设计具有明确的边界。PCI DSS 包含一些要求,这些要求无法仅通过 SIEM 的遥测数据进行完全验证。存储的账户数据保护(要求 3)、物理访问控制(要求 9)以及组织政策要求(要求 12)仍然需要人工验证和 QSA 审查。
Elastic 的方法承认了这一边界。该技能包含非认证语言和范围元数据,使用户能够理解自动化检查只是审计的输入,而非正式的合规性判断。
它还考虑到了数据质量。缺失的字段、较低的 ECS 覆盖率、重叠的索引模式以及较短的时间窗口都可能影响结果。该技能的设计旨在揭示这些限制,而不是用一个简单的绿色对勾将其隐藏。
未来合规技能的模式
PCI DSS 是第一步,但其架构指出了更广泛的方向。Agent Builder 中的技能优先模型允许合规能力围绕特定框架的知识、专用工具、证据收集、字段映射和响应工作流程进行构建。同样的模式可以扩展到其他合规框架,其中安全遥测数据可以提供有意义的证据。
这一未来至关重要,因为组织不会将合规视为孤立的框架。同一身份验证事件可能支持 PCI、SOC 2、ISO 27001 或内部访问控制审查。同一漏洞发现可能对多个审计计划都有影响。同一日志缺口可能削弱多个控制措施。智能代理合规为通过共享的运营证据提出特定框架的问题开辟了一条路径。
新的合规体验
合规审计的未来不应是翻阅静态仪表板和截图。它应该是针对实时运营数据提出精确的问题,并获得团队可以检查、解释和采取行动的基于证据的回答。
Elastic Security 为 Agent Builder 提供的 PCI DSS v4.0.1 技能,结合 Elastic Workflows 的自动化能力,引入了这种体验。合规性从仪表板转向对话。而在 Elastic,这种对话是基于安全遥测数据的。准备好看看这项技能如何加速您的合规操作了吗?今天就通过 Elastic Security 的免费试用亲自体验一下。
本文中提到的任何功能或功能的发布和发布时间均由 Elastic 单独决定。任何目前尚未提供的功能或功能可能无法按时或根本不会提供。
在本文中,我们可能使用或提及了第三方生成式 AI 工具,这些工具由其各自的所有者拥有和运营。Elastic 对第三方工具没有任何控制权,也不对这些工具的内容、操作或使用,或因使用这些工具而可能产生的任何损失或损害负责。在使用 AI 工具处理个人、敏感或机密信息时,请务必谨慎。您提交的任何数据可能会用于 AI 训练或其他用途。无法保证您提供信息的安全性或保密性。在使用任何生成式 AI 工具之前,请熟悉其隐私政策和使用条款。
Elastic、Elasticsearch 及相关标识是 elasticsearch B.V. 在美国和其他国家的商标、标志或注册商标。所有其他公司和产品名称均为其各自所有者的商标、标志或注册商标。