OSSIM下合规性管理
需求场景：
老板让我检测我公司的网站是否符合PCI Compliance，完全不知道PCI Compliance是什么东西啊。
怎么检测才能知道网站是否符合PCI Compliance？
通过对收集的各种设备日志和安全事件进行深入挖掘，结合安全合规管理，达到帮助建设企业信息安全合规管理体系的目标。OSSIM系统能够生成不同的安全合规报表，给出了标准的评价依据，通过检查信息系统中的各种安全合规项信息，生成安全合规测试报告，以达到对安全合规的管理的要求，通过将PCI DSS 2.0 、PCI DSS 3.0和ISO 27001融合为一体，可以很好的帮助企业规避合规风险.
下面主要谈谈2.0部分的内容。首先看一张整体效果图。
PCI DSS 2.0
需求 | 子需求 | 子需求内容 |
R.1 安装并维护防火墙配置以保护持卡人数据 | R.1.1建立并实施包含以下内容的防火墙和路由器配置标准 | R.1.1.1 批准和测试所有网络连接以及防火墙和路由器配置变更的正式流程 |
R.1.1.2 标识持卡人数据环境和其它网络（含任何无线网络）间所有连接的当前网络图表 | ||
R.1.1.3 显示整个系统和网络中所有持卡人数据流的当前图表。 | ||
R.1.1.4 各互联网连接以及任何非军事区(DMZ) 和内部网络区域间的防火墙要求 | ||
R.1.1.5 网络组件管理群组、角色与责任的说明 | ||
R.1.1.6 使用所有获准服务、协议和端口的文档记录和业务理由，包括对非安全协议实施安全功能的文档记录。 非安全服务、协议或端口包括但不限于 FTP、Telnet、POP3、IMAP 以及SNMP 1 版和2 版。 | ||
R.1.1.7 审核防火墙和路由器规则集（至少每半年一次）的要求 | ||
R.1.2构建防火墙和路由器配置，以限制不可信网络与持卡人数据环境中任意系统组件之间连接。 | R1.2.1 将输入和输出流量限制到持卡人数据环境所需的范围，并明确拒绝所有其它流量。
| |
R1.2.2 保护并同步路由器配置文件。 | ||
R1.2.3 在所有无线网络和持卡人数据环境间安装外围防火墙，并配置这些防火墙以拒绝流量或（如果业务需要流量）仅允许无线环境和持卡人数据环境间的授权流量。
| ||
R.1.3禁止互联网与持卡人数据环境中任何系统组件之间的直接公共访问。 | R.1.3.1 实施 DMZ，仅向提供授权服务、协议和端口（支持公共访问）的系统组件输入流量。 | |
R.1.3.2 仅向 DMZ 内的IP 地址输入互联网流量。 | ||
R.1.3.3 禁止任何直接的入站和出站连接在互联网和持卡人数据环境之间产生流量。 | ||
R.1.3.4 执行反欺骗措施以检测并阻止伪造的源IP 地址进入网络。 | ||
R.1.3.5 禁止从持卡人数据环境到互联网的非授权输出流量。 R.1.3.6 实施状态检查，也称动态数据包过滤。 | ||
R.1.3.7 将存储持卡人数据的系统组件（例如：数据库）放置在与DMZ 以及其它不可信网络隔离的内部网络区域中。 | ||
R.1.3.8 不要将私人 IP 地址和路由信息泄露给非授权方。 | ||
R.1.4在位于外网时仍连接到互联网且可用以访问网络的任意移动设备和/或员工自有设备（例如，员工使用的笔记本电脑）上安装个人防火墙软件。防火墙配置包括： 个人防火墙软件设有特定的配置设置 个人防火墙软件正在积极运行 移动设备用户和/或员工自有设备用户无法更改个人防火墙软件。 | ||
R.2 不要使用供应商提供的默认系统密码和其它安全参数 | R.2.1 始终更改供应商提供的默认值并于在网络中安装系统之前删除或禁用不必要的默认帐户。 该要求适用于所有默认密码，包括但不限于操作系统、提供安全服务的软件、应用程序和系统帐户、销售点(POS) 终端、简单网络管理协议 (SNMP) 社区字符串等使用的默认密码。 | R.2.1.1 对于连接到持卡人数据环境或传输持卡人数据的无线环境，在安装时更改所有无线供应商的默认值，包括但不限于默认的无线密钥、密码和SNMP 社区字符串。 |
R.2.2 制定适合所有系统组件的配置标准。确保这些标准能解决所有已知的安全漏洞并与行业认可的系统强化标准一致。 | R.2.2.1 每台服务器仅执行一项主要功能，以防需要不同安全级别的功能并存于同一台服务器上。（例如web 服务器、数据库服务器和DNS 均应在单独的服务器上执行。） 注：如果使用虚拟化技术，每个虚拟系统组件仅执行一项主要功能。 | |
R.2.2.2 仅启用系统功能所需的必要服务、协议、守护进程等。 R.2.2.2.a 选择系统组件样本，并检查已启用的系统服务、守护进程和协议，确认仅启用了必要的服务或协议。 R.2.2.2.b 找出任何已启用的不安全服务、守护进程或协议，并与工作人员面谈，确认已根据书面配置标准判断其实属合理。
| ||
R.2.2.3 对于任何被视为不安全的服务、协议或守护进程，均执行附加安全功能 — 例如，采用SSH、S-FTP、SSL 或IPSec *** 等安全技术保护NetBIOS、文件共享、Telnet、FTP 等不安全的服务。 R.2.2.3.a 检查配置设置，确认已针对所有不安全的服务、守护进程或协议记录并执行安全功能。 | ||
R.2.2.4 配置系统安全参数，以防滥用。 | ||
R.2.3 使用强效加密法对所有非控制台管理访问进行加密。对于基于web 的管理和其它非控制台管理访问，可采用SSH、*** 或SSL/TLS 等技术。
| ||
R.3 保护存储的持卡人数据 | R.3.1 通过实施数据保留和处理政策、程序和流程最大限度地减少持卡人数据存储，对所有持卡人数据(CHD) 存储而言，这些政策、程序和流程至少应包含以下方面： 将数据存储量和保留时间限制在法律、法规和业务要求的范围内 不再需要时安全删除数据的流程，持卡人数据的具体保留要求 按季度查找并安全删除所存储的超过规定保留期限的持卡人数据的流程。 | |
R.3.2 授权之后，不要存储敏感验证数据（即使已加密）。如果收到敏感验证数据，在完成验证流程后使所有数据不可恢复。 在下列情况下，允许发卡机构和支持发卡服务的公司存储敏感验证数据： 有正当的业务理由且 数据存储安全。 | R.3.2.1 切勿存储卡片背面磁条上任何磁道的完整内容、芯片或其它地方上的等效数据。此类数据也可称为全磁道、磁道、磁道1、磁道2 和磁条数据。 | |
R.3.2.2 切勿存储用于确认无实卡交易的卡验证代码或值（印在支付卡正面或背面的三或四位数值） | ||
R.3.2.3 切勿存储个人识别码(PIN) 或已加密的PIN 数据块。 | ||
R.3.3 显示PAN 时予以掩盖（最多显示前六位和后四位数字），这样仅具有正当业务需要者方可看到完整的PAN。 R.3.4 通过采取下列任一方法使所有位置（包括便携式数字媒介上、备份媒介上和日志中）存储的PAN 均不可读： 基于强效加密法的单向散列函数（散列必须要有完整的PAN） 截词（不能用散列代替 PAN 被截词的部分） 索引记号与索引簿（索引簿必须安全地存储） 具有相关密钥管理流程和程序的强效加密法 | R.3.4.a 检查关于 PAN 保护系统的文件记录，包括供应商、系统/流程类型以及加密算法（若适用），确认已通过使用下列任一方法令PAN 不可读取： 基于强效加密法的单向散列函数 索引记号与索引簿（索引簿存储安全） 具有相关密钥管理流程和程序的强效加密法 | |
R.3.4.b 检查数据储存库样本中的几个表格或文件，确认PAN 不可读 | ||
R.3.4.c 检查可移动媒介（例如备份磁带）样本，确认PAN 不可读。 | ||
R.3.4.d 审查检查日志样本，确认PAN 不可读或已从日志中删除。 | ||
R.3.4.1 如使用磁盘加密（而不是文件级或列级数据库加密），则逻辑访问必须得到单独管理并独立于本地操作系统的验证和访问控制机制（例如，不使用本地用户帐户数据库或通用网络登录凭证）。解密密匙决不能与用户帐户关联。 | ||
R.3.5 记录并实施保护程序，以保护用于防止存储的持卡人数据被泄露和滥用的密钥： | R.3.5.1 仅极少数必需的保管人有密钥访问权限。 | |
R.3.5.2 始终以下面的一种（或多种）形式存储用于加密/解密持卡人数据的机密密钥和私人密钥： 使用至少与数据加密密钥一样强效且与数据加密密钥分开存储的密钥加密密钥进行加密 在安全加密设备（例如，主机安全模块(HSM) 或PTS 批准的交互点设备）内 根据行业认可的方法，采用至少两个全长密钥组分或密钥共享 | ||
R.3.6 充分记录并实施用于持卡人数据加密的所有密钥管理流程和程序，包括： | R.3.6.a 针对服务提供商的附加程序：如果服务提供商与客户共享传输或存储持卡人数据的密钥，则需要检查服务提供商向客户提供的文档记录，以确认已根据下文要求3.6.1 至3.6.8 在文档记录中提供了安全传输、存储并更新客户密钥的指南。 R.3.6.b 检查用于持卡人数据加密的密钥管理程序和流程并执行以下操作： R.3.6.1.a 确认密钥管理程序详细列明强效密钥的生成方式。 R.3.6.1.b 查看密钥生成方法，确认已生成强效密钥。 R.3.6.2 安全的密钥分配 3.6.3 安全的密钥存储 3.6.4 根据相关应用程序供应商或密钥所有人的规定并基于行业最优方法和指南（例如，《NIST 特别出版物800-57》），在密钥周期结束时（例如，指定期限过后和/或给定密钥产生一定量的密文后）对密钥进行的变更。 3.6.5 密钥的完整性变弱（例如，知道明文密钥部分的员工离职）或怀疑密码遭受威胁时，认为有必要注销或替换（例如，存档、销毁和/或撤销）密钥。 3.6.6 若使用手动明文密钥管理操作，则必须使用分割知识和双重控制来管理这些操作。 3.6.7 防止密钥的非授权替换。 3.6.8 有关密钥保管人正式确认理解并接受密钥保管责任的要求。 | |
R.4 加密持卡人数据在开放式公共网络中的传输 | R.4.1 使用强效加密法和安全协议（例如，SSL/TLS、IPSEC、SSH 等） 来保护在开放式公共网络中传输的敏感持卡人数据，包括： 只接受可信的密钥和证书 使用的协议只支持安全的版本或配置 加密强度适合所使用的加密方法 | 4.1.a 审查书面政策和程序，确认已详细列明以下方面的流程： 只接受可信密钥和/或证书。 所使用的协议仅支持安全的版本和配置（不支持非安全版本和配置）。 根据所使用的加密方法实施适当的加密强度 4.1.b 在出现入站和出站传输时选择并查看其样本部分，以确认所有持卡人数据均在传输时使用强效加密法加密。 4.1.c 检查密钥和证书，确认仅接受可信密钥和/或证书。 4.1.d 检查系统配置，确认实施的协议仅使用安全的配置且不支持非安全版本或配置。 4.1.e 检查系统配置，确认已针对所使用的加密方法采用合适的加密强度。 |
4.1.1 确保传输持卡人数据或连接到持卡人数据环境的无线网络使用行业最优方法（例如，IEEE 802.11i），以对验证和传输实施强效加密。 | ||
R.4.2 不要使用终端用户通讯技术（例如，电子邮件、即时通讯、聊天等）来传送不受保护的PAN。 | 4.2.a 如果使用终端用户通讯技术来发送持卡人数据，则应查看发送PAN 的流程，并在出现出站传输时抽样查看，确认只要通过终端用户通讯技术传送，PAN 便不可读或受强效加密保护。 4.2.b 审查书面政策，确认已有不会通过终端用户通讯技术传送不受保护的PAN 方面的政策规定。 | |
R.5 为所有系统提供恶意软件防护并定期更新杀毒软件或程序 | R.5.1 在经常受恶意软件影响的所有系统（特别是个人电脑和服务器）中部署杀毒软件。 | 5.1.1 确保杀毒程序能检测、删除并阻止所有已知类型的恶意软件。 |
R.5.2 确保所有杀毒机制按如下方式维护： 保持为最新， 执行定期扫描 生成检查日志（PCI DSS 要求10.7 规定保留） | 5.2.a 检查政策和程序，确认已规定杀毒软件和相关定义需要保持为最新。 5.2.b 检查杀毒配置（包括软件的主体安装），确认杀毒机制： 配置为执行自动更新 配置为执行定期扫描 5.2.c 检查系统组件样本（包括经常受恶意软件影响的所有操作系统类型），确认： 杀毒软件和相关定义为最新 已执行定期扫描 5.2.d 检查杀毒配置（包括软件的主体安装和系统组件的样本部分），确认： 已启用杀毒软件日志生成功能，且日志根据 PCI DSS 要求10.7 进行保留。 | |
R.6 开发并维护安全的系统和应用程序 | R.6.1 制定相关流程，通过使用外部信源获取安全漏洞信息来识别安全漏洞，并为新发现的安全漏洞指定风险等级（例如“高”、“中”或“低”）。 | 6.1.a 检查政策和程序，确认已规定以下流程： 识别新的安全漏洞。 为漏洞指定风险等级，包括识别所有“高”风险和“重要”漏洞。 使用外部信源获取安全漏洞信息。 6.1.a 检查政策和程序，确认已规定以下流程： 识别新的安全漏洞。 为漏洞指定风险等级，包括识别所有“高”风险和“重要”漏洞。 使用外部信源获取安全漏洞信息。
|
R.6.2 通过安装供应商提供的适用安全补丁，确保所有系统组件和软件均杜绝已知漏洞。在发布后一个月内安装关键的安全补丁。 | ||
R.6.3 遵照如下要求安全地开发内部和外部软件应用程序（包括基于web 的应用程序管理访问）： 按照 PCI DSS（例如安全验证和记录） 基于行业标准和/或最优方法。 将信息安全纳入软件开发的整个生命周期。 | 6.3.a 检查书面软件开发流程，确认这些流程以行业标准和/或最优方法为基础。 6.3.b 检查书面软件开发流程，确认信息安全已纳入软件开发的整个生命周期。 6.3.c 检查书面软件开发流程，确认软件应用程序的开发符合PCI DSS。 6.3.d 与软件开发人员面谈，确认已实施书面软件开发流程。 | |
6.3.1 在应用程序启动前或向客户发布应用程序前，删除开发、测试和/或自定义应用程序帐户、用户ID 和密码 | ||
6.3.2 为识别任何潜在的编码漏洞（采用人工或自动流程），在发布到产品前或向客户发布前检查自定义代码时至少应包括以下方面： 由代码原作者以外人员以及熟悉代码审核方法和安全编码实践的人员审核代码变更。 代码审核可确保代码的开发符合安全编码指南 发布前已进行适当修正。 | ||
R.6.4 系统组件的所有变更均须遵守变更控制流程和程序。该流程必须包括如下内容： | 6.4.1 开发/测试环境独立于生产环境，并设置访问控制，确保两者分离 6.4.2 开发/测试环境与生产环境中的职责分离 6.4.3 在测试或开发过程中不使用生产数据（真实的PAN） 6.4.4 在生产系统启动前，删除测试数据与帐户 6.4.5 应用安全补丁和软件修改的变更控制程序必须包括以下方面： 6.4.5.a 检查有关应用安全补丁和软件修改的书面变更控制程序，确认已规定以下方面的程序： 影响记录 被授权方的变更审批记录 功能测试，以确认该变更未对系统安全造成不利影响 取消程序 6.4.5.b 对于系统组件样本，与负责人员面谈以确定最新的变更/安全补丁，并根据这些变更追溯到相关的变更控制记录。每次检查变更时，执行下列步骤： 6.4.5.1 确认每次抽取的变更样本的变更控制文档记录已包含影响记录。 6.4.5.2 确认每次抽取的变更样本都有被授权方的审批记录。 | |
R.6.5 按照以下操作解决软件开发流程中常见的编码漏洞： 为开发人员提供关于安全编码技术的培训，包括如何避免常见的编码漏洞，并理解敏感数据在内存中的处理方式。 根据安全编码指南开发应用程序 | 6.5.a 检查软件开发政策与程序，确认已要求开发人员必须参加安全编码技术培训，且培训以行业最优方法和指南为基础。 6.5.b 抽取部分开发人员进行面谈，确认他们熟悉安全编码技术。 6.5.c 检查培训记录，确认软件开发人员已接受关于安全编码技术的培训，包括如何避免常见的编码漏洞，并理解敏感数据在内存中的处理方式。 | |
6.5.1 注入***，特别是 SQL 注入。同时还须考虑OS 命令注入、LDAP等其它注入***。 6.5.2 缓冲区溢出 6.5.3 非安全加密存储 6.5.4 非安全通信 6.5.5 不正确的错误处理 6.5.6 漏洞识别流程中确认的所有“高风险”漏洞 6.5.7 跨站点脚本 (XSS) 6.5.8 不正确的访问控制（例如不安全的直接对象引用、未能限制URL 访问、目录遍历和未能限制用户的功能访问） 6.5.9 跨站点请求伪造 (CSRF) 6.5.10 失效的验证与会话管理 | ||
R.6.6 对于面向公众的 web 应用程序，应不断解决新的威胁和漏洞，并通过以下任一方法确保这些应用程序不会受到已知***： 利用手动或自动应用程序漏洞安全评估工具或方法审核面向公众的web 应用程序，至少每年一次或在有任何变更后进行注：该评估与要求11.2 中执行的漏洞扫描不同 在面向公众的 web 应用程序前安装可检查和防范网页式***的自动化技术解决方案（例如web 应用程序防火墙），用以不断检查所有流量。 | ||
R.7 按业务知情需要限制对持卡人数据的访问 | R.7.1 仅有工作需要的个人才能访问系统组件和持卡人数据。
| 7.1.1 为每个角色定义访问需要，包括： 每个角色依据工作职能需要访问的系统组件和数据资源 访问资源所需的权限级别（例如，用户、管理员等） |
7.1.2 将特权用户 ID 的访问权限限制为执行工作所需的最小权限。 | ||
7.1.3 基于个人的工作分类和职能分配访问权限。 | ||
7.1.4 要求由指定所需权限的被授权方作出书面批准。 | ||
R.7.2 为系统组件建立访问控制系统，以根据用户的知情需要限制访问，并且将系统设为“全部拒绝”，特别允许访问时除外。 该访问控制系统必须包含以下内容： | 7.2.1 所有系统组件范围 7.2.2 基于工作分类和职能为个人分配权限 7.2.3 默认的“全部拒绝”设置 | |
R.8 识别并验证对系统组件的访问 | R.8.1 规定并实施政策和程序，确保对所有系统组件中的非消费者用户和管理员执行以下适当的用户识别管理： | |
R.8.2 除了分配唯一 ID 以外，至少采用以下一种方法来验证所有用户，确保对所有系统组件中的非消费者用户和管理员执行恰当的用户验证管理： 所知，如密码或口令等 所有，如令牌设备或智能卡等 个人特征，如生物特征等 | ||
R.8.3 对来自网络外部人员（包括用户和管理员）以及所有第三方的远程网络访问（包括基于支持或维护目的的供应商访问）使用双因素验证。 | ||
8.4 记录并向所有用户传达验证程序和政策，包括： 选择强效验证凭证的指南 关于用户应如何保护其验证凭证的指南 关于不重用之前用过密码的说明 用户如怀疑密码可能暴露则应修改密码 | ||
R.8.5 不要使用群组、共享或常规ID、密码或其它验证方法，具体如下： 常规用户 ID 已禁用或删除 用于系统管理和其它重要功能的共享用户ID 不存在 不使用共享和常规用户 ID 管理任何系统组件 | 8.5.1 针对服务提供商的额外要求：有权远程进入客户经营场所的服务提供商（例如POS 系统或服务器的维修商）必须使用每个客户经营场所独有的验证凭证（例如密码/口令）。 | |
R.9 限制对持卡人数据的物理访问 | R.9.1 采用适当的场所入口控制，对持卡人数据环境中系统的物理访问进行限制和监控。 | 9.1.1 利用摄像头和/或访问控制机制监控个人对敏感区域的物理访问情况。核查采集的数据并与其它条目关联。除非法律另有规定，否则至少存储三个月。 9.1.1.a 确认已使用摄像头和/或访问控制机制监控敏感区域的出入口。 9.1.1.b 确认摄像头和/或访问控制机制受到安全保护，免遭破坏或禁用。 9.1.1.c 确认已对摄像头和/或访问控制机制实施监控，并且来自摄像头或其它机制的数据至少保存三个月。 |
R.9.1.2 实施物理和/或逻辑控制，限制对公共网络插座交换机的访问。 | ||
R.9.1.3 限制对无线访问点、网关、手持式设备、网络/通信硬件和电信线路的物理访问。 | ||
R.9.2 制定相关程序，轻松识别现场工作人员和访客，包括： 识别新的现场工作人员或访客（例如发放工卡） 修改访问要求 废除或取消现场工作人员和过期访客的***件（例如工卡） | 9.2.a 检查流程文档记录，确认已制定用于识别和区分现场工作人员与访客的程序。 9.2.b 查看关于识别和区分现场工作人员与访客的流程，确认： 访客的身份已清楚识别，并且 能轻松区分现场工作人员和访客 9.2.c 确认验证流程（如工卡系统）的查看权仅限于授权人员。 | |
R.9.3 控制现场工作人员对敏感区域的物理访问，具体如下： 必须根据个人的工作职能获取使用权 一旦离职，立即撤消使用权，所有物理访问机制（例如钥匙、访问卡等）均退回或禁用。 | ||
R.9.4 实施相关程序，识别并批准访客。 程序应包括以下方面： | 9.4 确认现已实施访客授权和访问控制流程，具体如下： 9.4.1.a 查看程序并与工作人员面谈，确认访客必须在获准后方可进入，并且在进入处理或维护持卡人数据的区域时始终有人陪同。 9.4.1.b 查看访客工卡或其它***件的使用情况，确认实体令牌工卡不允许在无人陪同的情况下进入处理或维护持卡人数据的现场区域 9.4.2.a 查看经营场所内的人员，确认已使用访客工卡或其它***件，并能从现场工作人员中轻松分辨出访客。 9.4.2.b 确认访客工卡或其它***件的有效期。 | |
R.9.5 保护所有媒介的实体安全。 | 9.5.1.a 查看存储场所的实体安全性，确认备份媒介存储安全。 9.5.1.b 确认至少每年检查一次存储场所的安全性。 | |
R.9.6 严格控制任何媒介的内部或外部分发，包括： | ||
R.9.7 严格控制对媒介的存储和获取。 | 9.7.1 检查媒介盘存记录，确认已保留记录，并且至少每年盘点一次媒介。 | |
R.9.8 当媒介因业务或法律原因不再需要时应予销毁，具体如下： | 检查媒介定期销毁政策，确认该政策涵盖所有媒介，并具备以下要求： 硬拷贝材料必须粉碎、焚烧或打浆，以合理保证这些硬拷贝材料无法重建。 用于存放待销毁材料的容器必须安全。 电子媒介上的持卡人数据必须通过安全擦除程序（符合行业认可的安全删除标准）或通过销毁媒介实体令其不可恢复。 | |
R.9.9 保护通过直接接触卡本身便可捕获支付卡数据的设备，以避免设备被篡改和替换。 | 9.9.1 保留一份最新的设备列表。该列表应包含如下信息： 设备的外形、型号 设备的位置（例如设备所安放的现场或设施的地址） 设备的序列号或其它独特验证方法 | |
R.9.10 确保已记录、正在使用且所有相关方了解用于限制持卡人数据物理访问权的安全政策和操作程序。 | ||
R.10 跟踪并监控对网络资源和持卡人数据的所有访问 | R.10.1 实施检查记录，将对系统组件的所有访问链接到个人用户。 | |
R.10.2 对所有系统组件实施自动检查记录以重建以下事件： | 10.2.1 对持卡人数据的所有个人用户访问 10.2.2 任何具有 root 或管理员权限的个人执行的所有操作 10.2.3 对所有检查记录的访问 10.2.4 无效的逻辑访问尝试 10.2 5 识别和验证机制的使用和变更（包括但不限于新建帐户和提升权限）以及具有root 或管理员权限帐户的所有变更、添加或删除 10.2.6 检查日志的初始化、关闭或暂停 10.2.7 系统级对象的创建和删除 | |
R.10.3 对于每次事件，至少记录所有系统组件的以下检查记录条目： | 10.3.1 用户识别 10.3.2 事件类型 10.3.3 日期和时间 10.3.4 成功或失败指示 10.3.5 事件的起因 10.3.6 受影响的数据、系统组件或资源的特性或名称。 | |
R.10.4 使用时间同步技术来同步所有关键系统的时钟和时间，并确保实施以下各项以获取、分配并存储时间。 | 10.4.1.a 检查获取、分配和存储组织内部正确时间的流程，确认： 只有指定的中央时间服务器能接收外来的时间信号，且外来的时间信号以国际原子时或UTC 为基础。 当存在多个指定时间服务器时，这些时间服务器会相互同步以保持准确的时间。 系统只接收来自指定中央时间服务器的时间信息。 10.4.1.b 对于系统组件样本，查看与时间相关的系统参数设置，确认： 只有指定的中央时间服务器能接收外来的时间信号，且外来的时间信号以国际原子时或UTC 为基础。 当存在多个指定时间服务器时，这些指定的中央时间服务器会相互同步以保持准确的时间。 系统只接收来自指定中央时间服务器的时间。 | |
R.10.4.2 时间数据受保护。 | 10.4.2.a 检查系统配置和时间同步设置，确认仅有业务需要的人员才能访问时间数据。 10.4.2.b 检查系统配置、时间同步设置和日志以及流程，确认已记录、监控并审核关键系统中时间设置的任何变更。 | |
R.10.4.3 时间设置来自行业认可的时间来源。 | ||
R.10.5 保护检查记录，禁止进行更改。 | 10.5.1 只允许有工作需要的人查看检查记录。 10.5.2 防止检查记录文件受到非授权修改。 10.5.3 即时将检查记录文件备份到难以更改的中央日志服务器或媒介中。 10.5.4 将向外技术的日志写入安全的内部中央日志服务器或媒介设备。 10.5.5 对日志使用文件完整性监控或变更检测软件可确保未生成警报时无法变更现有日志数据 | |
R.10.6 审核所有系统组件的日志和安全事件以识别异常情况或可疑活动。 | 10.6.1.a 检查安全政策和程序，确认已规定程序，以手动或采用日志工具至少每天审核一次以下内容： 所有安全事件 可存储、处理或传输 CHD 和/或SAD 或者影响CHD 和/或SAD 安全性的所有系统组件的日志 所有关键系统组件的日志 执行安全功能的所有服务器和系统组件（例如，防火墙、***检测系统/***防御系统(IDS/IPS)、验证服务器、电子商务重定向服务器等）的日志 10.6.1.b 查看流程并与工作人员面谈，确认至少每天审核一次以下内容： 所有安全事件 可存储、处理或传输 CHD 和/或SAD 或者影响CHD 和/或SAD 安全性的所有系统组件的日志 所有关键系统组件的日志 执行安全功能的所有服务器和系统组件（例如，防火墙、***检测系统/***防御系统(IDS/IPS)、验证服务器、电子商务重定向服务器等）的日志 | |
R.10.7 保留检查记录历史至少一年，其中最少3 个月的记录可立即访问以供分析（例如，在线、存档或可从备份恢复）。 | 10.7.a 检查安全政策和程序，确认规定以下内容： 检查日志保留政策 关于保留检查日志至少一年的程序，其中最少 3 个月的日志可立即在线访问。 10.7.b 与工作人员面谈并查看检查日志，确认检查日志至少一年可用。 | |
R11 定期测试安全系统和流程。 | R.11.1 实施流程以测试是否存在无线接入点(802.11)，并按季度检测和识别所有授权和非授权的无线接入点 | 11.1.a 检查政策和程序，确认已规定相应的流程，以按季度检测并识别授权和非授权的无线接入点。 11.1.b 确认所用方法足以检测并识别任何非授权无线接入点，其中至少包括： 在系统组件中插入 WLAN 卡 将系统组件连接到便携或移动设备以创建无线接入点（例如通过 USB 等） 将无线设备连接到网络端口或网络设备 11.1.c 检查最近的无线扫描结果，确认： 已识别出授权和非授权无线接入点，且 至少每季度扫描一次所有系统组件和设施。 11.1.d 如果采用自动监控（例如无线IDS/IPS、NAC 等），确认配置会发出警报以通知工作人员。 |
R.11.2 至少每个季度运行一次内部和外部网络漏洞扫描，并且在网络有任何重大变化（例如安装新的系统组件，更改网络拓朴，修改防火墙规则，产品升级）时也运行漏洞扫描。 | 11.2.1 执行每季度一次的内部漏洞扫描，并视需要重复扫描，直至所有“高风险”漏洞（具体规定请参阅要求6.1）均得以解决。必须由合格人员执行扫描。 11.2.2 通过由支付卡行业安全标准委员会(PCI SSC) 认证的授权扫描服务商(ASV) 执行每季度一次的外部漏洞扫描。视需要执行重复扫描，直至获得扫描通过结果。 11.2.3 在发生任何重要变更后，视需要执行内部和外部扫描和重复扫描。必须由合格人员执行扫描。 | |
R.11.3 实施一种包含以下内容的穿透测试法： 以行业认可的穿透测试法为基础（例如 NIST SP800-115） 包括覆盖整个CDE 环境和关键系统 来自网络内部和外部的测试 包括用于验证任何网段和范围缩小控制的测试 定义应用层穿透测试，至少包括要求 6.5 中列出的漏洞 定义网络层穿透测试，包括支持网络功能和操作系统的组件 包括审核并考虑过去12 个月内遇到的威胁和漏洞 指定保留穿透测试结果和修复活动结果。 | 11.3.1 每年至少执行一次外部穿透测试，并且在基础架构或应用程序有任何重要升级或修改时（例如操作系统升级、环境新增子网络或环境新增web 服务器）也执行该测试。 11.3.2至少每年执行一次内部穿透测试，并在基础架构或应用程序有任何重要升级或修改（例如操作系统升级、环境新增子网络或环境新增web 服务器）后也执行该测试。 | |
R.11.4 利用***检测和/或***防御技术来检测和/或防御网络***。监控持卡人数据环境周围以及持卡人数据环境中关键点的所有流量，并警示工作人员注意可疑威胁。 | 11.4.a 检查系统配置和网络图，确认目前已采用相关技术（例如***检测系统和/或***防御系统）监控以下位置的所有流量 持卡人数据环境周围 持卡人数据环境中的关键点 11.4.b 检查系统配置并与负责人员面谈，确认***检测和/或***防御技术会在发现可疑威胁时向工作人员发出警报。 11.4.c 检查IDS/IPS 配置和供应商文档记录，确认已按照供应商的说明对***检测和/或***防御技术进行配置、维护和升级，以确保提供最佳保护。 | |
R11.5 部署变更检测机制（例如文件完整性监控工具），在发现重要的系统文件、配置文件或内容文件出现非授权修改时警示工作人员；同时配置该软件至少每周执行一次重要文件比对。 | 11.5.a 查看系统设置和受监控文件，并审核监控活动结果，确认已在持卡人数据环境中使用变更检测机制。 应予以监控的文件有： 系统可执行文件 应用程序可执行文件 配置和参数文件 集中存储文件、历史或归档文件、日志和检查文件 由实体（通过风险评估或其它方法）确定的其它重要文件 11.5.b 确认已配置该机制，可在重要文件出现非授权修改时警示工作人员，并至少每周执行一次重要文件比对。 | |
R.12 维护针对所有工作人员的信息安全政策 | 12.1 制定、公布、维护和宣传安全政策 | 12.1.1 至少每年审核一次安全政策，并在环境发生变更时予以更新。 12. 2.a 确认每年一次的风险评估过程有文档记录，确定资产、威胁和漏洞，并形成正式的风险评估。 12. 2.b 审核风险评估文档记录，确认至少每年执行一次风险评估过程，并在环境有重大变更时也执行。 |
R.12.2 实施符合以下条件的风险评估流程： 至少每年执行一次评估，并在环境发生重大变更时（例如收购、合并、迁址等）也执行评估； 确定重要资产、威胁和漏洞；以及 形成正式的风险评估。 | ||
R.12.3 制定关键技术的使用政策，并规定这些技术的正确用法。 | 12.3.1 被授权方的明确许可 12.3.2 技术使用验证 12.3.3 一份列出所有此类设备和具有访问权的工作人员的列表 12.3.4 一种确定负责人、联系信息和用途 12.3.5 可接受的技术使用方式 12.3.6 技术可接受的网络位置 12.3.7 公司批准的产品列表 12.3.8 非活跃状态持续一定时间后自动中断远程访问技术的会话 12.3.9 仅在供应商和业务合作伙伴需要时为其激活远程访问技术，并在使用后立即停用 12.3.10 对于通过远程访问技术访问持卡人数据的工作人员，除非因规定的业务需要获得明确许可，否则禁止将持卡人数据复制、移动和存储到本地硬盘及可移动电子媒介上。如果有经批准的业务需要，使用政策必须规定应按照所有适用的PCI DSS 要求保护数据。 | |
R.12.4 确保安全政策和程序明确规定所有工作人员的信息安全责任。 | ||
R.12.5 将下列信息安全管理职责分配给个人或团队： | 12.5.1 确认已正式分配制定、记录和分发安全政策与程序的职责。 12.5.2 确认已正式分配安全警报的监控和分析职责，以及向适当的信息安全与业务部门管理人员分发信息的职责。 12.5.3 确认已正式分配建立、记录并分发安全事故响应和逐级上报程序的职责。 12.5.4 确认已正式分配用户帐户管理（添加、删除和修改）和验证管理的职责。 12.5.5 确认已正式分配监控并控制所有数据访问的职责。 | |
R.12.6 实施正式的安全意识计划，使所有工作人员意识到持卡人数据安全的重要性。 | 12.6.a 审核安全意识计划，确认该计划使所有工作人员意识到持卡人数据安全的重要性。 12.6.b 检查安全意识计划程序和文档记录并执行以下操作： 12.6.1 人员一经录用即进行培训，此后每年至少培训一次。 12.6.2 要求工作人员每年至少确认一次自己已阅读并了解安全政策和程序。 | |
R.12.7 在录用人员前筛选应征者，以最大程度地降低内部***的风险。（背景调查包括以往的工作经历、犯罪记录、信用记录以及证明人调查。） | ||
R.12.8 维护并实施政策和程序，以管理共享持卡人数据或可影响持卡人数据安全的服务提供商，具体方式如下： | 12.8.1 确认已保留一份服务提供商名单。 12.8.2 查看书面协议并确定服务提供商确认其负责维护所持有的持卡人数据，或以其它方式代表客户存储、处理或传输的持卡人数据的安全，或在可能影响持卡人数据环境安全性的程度内维护数据安全。 12.8.3 确认已记录并实施此政策和程序（包括雇用任何服务提供商之前相应的尽职调查）。 12.8.4 确认组织通过维护一项计划来监控（至少每年一次）服务提供商的PCI DSS 遵从性状态。 | |
R.12.9 针对服务提供商的额外要求：服务提供商以书面形式向客户确认其负责维护所持有的持卡人数据，或以其它方式代表客户存储、处理或传输的持卡人数据的安全，或在可能影响持卡人数据环境安全性的程度内维护数据安全。 | 12.9.1.a 确认事故响应计划包括： 出现威胁时的角色、责任以及沟通策略，至少包括支付品牌通知 详细的事故响应程序 业务恢复和继续程序 数据备份流程 报告威胁的法律要求分析（例如，“加州参议院第1386 号法案”要求，数据库中有加州居民资料的任何公司在发现实际威胁或怀疑出现威胁时都应通知受影响的消费者） 所有关键系统组件的范围和响应 支付品牌对事故响应程序的参考或应用 12.9.1.b 从之前报告的事故或警报中选取样本，与工作人员面谈并查看文档记录，确认已遵循书面事故响应计划和程序。 | |
12.9.2 至少每年测试一次计划。 | ||
12.9.3 指定可全天候响应警报的特定人员。 | ||
12.9.4 为具有安全漏洞响应责任的员工提供恰当的培训。 12.9.5 包含来自安全监控系统（包括但不限于***检测系统、***防御系统、防火墙和文件完整性监控系统）的警报。 | ||
12.9.6 根据以往的经验教训并结合行业发展情况，制定修改并改进事故响应计划的流程。 |
以上这些需求包括了对服从性的周期性报告(ROC)，漏洞扫描，***测试和Web应用测试等规范要求，如果你的企业需要进行IT审计那么这是必备内容。
根据PCI生成的报告：
