LBMC 是一家引以为豪的 PCI 合格安全评估公司,自 PCI 数据安全标准 (PCI DSS)。我们熟练且经验丰富的 QSA 团队为所有主要行业的各种规模的商家和服务提供商进行了评估和咨询工作。 

The QSA透视系列 是一个由六部分组成的博客系列,分享我们对理解、解释和应用 PCI DSS 的看法。系列主题将包括:

  • 持卡人数据环境
  • 连接到/安全影响系统
  • 网络和数据流图
  • 服务提供商和嵌套第三方
  • 云审计——真的有那么不同吗?
  • 云审计——AWS、Azure、客户——谁负责什么?

该系列的目标是分享知识并提供我们对合规性基本原理的看法,以及如何应用这些基本原理来帮助实体实现和维护 PCI DSS 合规性。我们希望本系列提供有关 QSA 如何解释 PCI DSS 和处理合规性评估的宝贵见解。

持卡人数据环境

要成功地计划、实施和完成评估,准确定义合规范围至关重要。这个范围,在 PCI 的说法中,被称为 持卡人数据环境. PCI 安全标准委员会已确定实体有责任定义其持卡人数据环境,或 CDE,以便可以正确应用和成功评估 PCI 控制要求。尽管概念很简单,但准确定义 CDE 通常是寻求合规的实体和评估人员面临的最大挑战。这就是为什么范围验证是评估中最先进行的活动之一。如果没有正确定义的 CDE,就无法确定评估的边界,因此,无法相信评估已包括所有相关的卡支付操作和组件。不幸的是,由于 CDE 定义不正确,许多评估,尤其是对于寻求初始证明的实体,都受到了负面影响。

那么,PCI DSS 对定义 CDE 有何看法?很简单,它指出“CDE 由存储、处理或传输持卡人数据或敏感身份验证数据的人员、流程和技术组成。”虽然是一句简单的陈述,却也留下了曲解的余地。持卡人数据,或 CHD, 由完整的主帐号组成,或 PAN,这是信用卡正面或背面的 16 位字符串、持卡人姓名、到期日期和/或服务代码。服务代码通常编码在磁条中,不应与卡的安全代码混淆,安全代码是通常印在卡背面的 3 位或 4 位代码。虽然所有这些值都被视为 CHD,但 PCI DSS 将 PAN 视为“持卡人数据的决定性因素”。如果不存在完整的 PAN,则其他元素不被视为 CHD。你没看错;即使存在持卡人的姓名、到期日期和/或服务代码,如果不包括完整的 PAN,那么您就没有持卡人数据。相反,如果完整的 PAN 附有名称、到期日期和/或服务代码,则所有这些元素都被视为符合 PCI DSS 的 CHD。顺便说一句,你可能已经学会了这个词 全PAN 在这些定义中。如果不超过 PAN 的前 6 位和后 4 位数字,则不视为 PAN。超过这个值被认为等同于完整的 PAN。

敏感身份验证数据,或 SAD 是卡的安全相关信息,包括全磁道数据(编码在磁条或芯片上)、卡安全代码、PIN 和 PIN 块。这些元素用于验证持卡人身份和/或授权支付卡交易。

这些定义的开始点是它们是确定实体 PCI 合规范围的基本要素。实体及其评估者必须识别持卡人数据的所有实例,以便能够定义和验证持卡人数据环境。现在,回想一下 PCI 委员会还确定 CDE 包括 人员、流程和技术.这意味着不仅要考虑计算机系统和网络,还要考虑与 CHD 交互的人员以及这些人用来促进信用卡支付和所有相关活动的手动或自动流程和技术。这是定义 CDE 的一项基本练习,以采访人员、观察他们的流程并将每个人纳入评估。尽管实体的 CDE 中可能有任意数量的人员和流程,但这里仅举几个常见示例:

  • 客户服务代理
  • 零售店合伙人
  • 会计部人员
  • 收发室人员
  • IT系统管理员
  • 软件开发人员
  • 数据库管理员

以下是这些人(或他们管理的系统)可能执行的一些常见流程:

  • 客户服务代理通过电话接收付款
  • 零售收银员通过支付终端刷卡
  • 会计支持人员处理退款和拒付
  • 收发室工作人员扫描书面付款单
  • 系统管理员安装销售点系统
  • 软件开发人员为基于网络的支付创建 API
  • 数据库管理员查询支付数据表

最后,这些过程中使用的技术可能包括:

  • IP 电话系统
  • 通话录音软件
  • 销售点系统和外部支付终端
  • 基于云的软件即服务应用程序
  • 打印机和扫描仪
  • 各种服务器平台,例如文件、数据库、大型机等。
  • 网络交换机和路由器

现在,您可能会想,“这些都是很好的信息,但是为我定义这个范围不是评估员的工作吗?”事实上,PCI DSS 明确确立了确定 CDE 被准确定义的共享性质。根据 PCI DSS,

至少每年一次和在年度评估之前,被评估实体应通过识别持卡人数据的所有位置和流来确认其 PCI DSS 范围的准确性,并识别所有连接到 CDE 或如果受到损害可能影响 CDE 的系统(例如,身份验证服务器)以确保它们包含在 PCI DSS 范围内。实体保留显示 PCI DSS 范围如何确定的文档。保留文件以供评估员审查和/或在下一次年度 PCI DSS 范围确认活动期间参考。对于每个 PCI DSS 评估,评估员需要验证评估范围是否准确定义并记录在案.”

简而言之,实体负责识别 CDE 并确定其合规范围,而评估员的作用是验证实体确定的内容。在开始评估之前,双方共同达成准确定义的 CDE。

PCI DSS 范围界定中的常见错误

值得重申的是,尽管概念上很简单,但准确定义 CDE 通常是最大的合规挑战。以下是实体甚至评估者在定义和验证 CDE 和合规范围时会犯的一些常见错误:

  • 从范围中省略非标准或支持流程(例如邮件收发室、会计)。
  • 俯瞰存储壁橱或异地记录设施等存储硬拷贝持卡人数据的位置。
  • 不包括参与接受付款或管理系统的第三方。
  • 假设加密数据超出范围(即使加密数据也是持卡人数据)。
  • 使用不正确和/或不完整的网络和数据流图来表示 CDE。
  • 维护存储、处理或传输持卡人数据的所有系统的不完整清单。

结论

您可能还记得旧的数据处理格言, 垃圾进垃圾出.它也适用于定义实体的 CDE 以评估 PCI 合规性。如果未准确定义实体的 CDE,则评估结果将不准确。实体及其评估员负责了解符合条件的内容和持卡人数据,然后仔细、有条不紊地识别支付流程中涉及的所有人员、流程和技术。在本系列的下一篇文章中,我们将考虑 PCI DSS 范围界定标准的另一个元素:连接到和安全影响的系统。