金融事业部风险与安全改进建议安全部分课件.ppt

1、金融事业部风险与安全改进建议安金融事业部风险与安全改进建议安全部分全部分金融事业部支付风险与安全改进建议金融事业部支付风险与安全改进建议2011年1月主要内容 改进建议制定思路 风险与安全现状分析 银行支付安全模式分析 安全模型设计基于现有风险与安全管控现状，结合银行模式，提出改进建议2012/01/062011/12/30 确定整体工作思路及方法 制定整体计划 确定资源需求 完成现有系统及运营风险和安全机制分析 基于银行支付安全 分析银行采用的国际国内规范 分析银行现有系统安全措施 提出针对 的建议 基于银行风险机制 分析国际国内风险规范 分析银行现有风险措施 提出针对 的建议 方法 计划

2、资源 PCI CUPSecure 网银 EMV？电子商务 BASEL AML 银行应用 系统现状分析 运营现状分析 确定综合考核体系 确定风险安全对象 确定对象的风险安全属性 制定维护策略 风险安全IT系统改进建议 风险安全内部管控改进建议 IT系统改进建议1 准备2 现状分析4 风险最佳实践分析3 安全模式对比5 安全模型设计6 风险改进建议 现有系统风险和安全机制分析 现有运营风险和安全机制分析2012/01/132012/01/20 策略 目标 综合 对象 属性 维护 IT系统改进 内部管控改进 优先级主要内容 改进建议制定思路 风险与安全现状分析 银行支付安全模式分析 安全模型设计5

3、金融支付相关的安全及风险现状已初成体系6领域领域现状描述现状描述风险管理 目前 风险管理整体建设尚未开始，部分风险管理功能已经进行开展；尚未建立统一的风险管理部门或类似职能组织，部分风险管理的职能分散在各业务部门之中，目前在筹建风险管理团队；没有或较少设置专门进行风险管理的岗位，没有或较少专门从事风险管理的人员；没有或较少制定风险管理相关的制度和管理办法；没有或较少制定风险管理相关的管理流程，部分流程通过系统实施中进行了梳理和制定并部署于系统之中；在管理系统中开始实施风险管理模块，实现了少部分风险管理的功能，如实名验证、危险人物名单等，有些业务需求因条件限制尚未得到实现，如交易规则的监控等；整

4、体上缺少风险管理相关的文档；尚未建设风险数据集市，目前所需数据直接从生产获取，数据源比较分散；尚未建立风险监控报表，已在规划当中；安全管理 安全管理已开展，支持目前支付业务的运行；安全管理很多功能均已系统化，在系统中实现了相关安全管理的流程，但缺乏安全管理的相关制度及相关文档；在主机的安全管理上，按照Web、应用和DB三类服务器制定了相应权限的管理机制；根据需求建立了银行接入模块，定义了银行接口规范，一般采用证书加签名方式保证支付请求的安全；金融支付相关的安全及风险现状已初成体系7领域领域现状描述现状描述安全管理 在客户系统的建立了客户门户模块支持外部客户的访问，其安全机制由网站提供证书、对用

5、户权限进行控制和部分需用户属性（如手机激活等）进行控制；在客户系统的建立了管理门户模块支持内部用户的访问，其安全机制由用户权限进行控制；在客户系统的建立了开放平台模块支持其他系统的访问，其安全机制签名验证和密钥进行控制；网络、主机和数据的管理及其安全工作由数据中心负责；互联网支付安全管理上，使用支付密码，在交易时进行短信提醒，手机校验码网上支付，正在进行安全控件招标工作，手机支付模式和互联网支付类似；在雨花机房进行了数据同城灾难备份，但未做应用备份，雨花机房主机通过服务器集群实现非单点高可用；办公网络和生产网络尚未进行隔离，容易通过办公网络访问生产产生安全问题，如网上打款等；尚未实现应用级的灾

6、难备份；主要内容 改进建议制定思路 风险与安全现状分析 银行支付安全模式分析 安全模型设计8银行的支付安全模式是基于国际国内规范的体系化成熟模型9PCI DSS支付安全规范研究 安全措施改进建议可能建议网络设置系统管理帐户管理网上支付密钥管理 安全措施对比基于银行支付安全框架分析，找到 可能借鉴的措施，为最终 的风险安全模型及改进建议打基础。网银安全规范研究电子商务安全措施研究EMV安全规范研究CUPSecure安全规范研究银行密钥体系研究主要内容 改进建议制定思路 风险与安全现状分析 银行支付安全模式分析 PCI DSS支付安全规范研究 CUPSecure安全规范研究 网银安全规范研究 银行

7、密钥体系研究 电子商务安全措施研究 EMV安全规范研究 安全模型设计10其中PCI DSS是国际公认的卡支付安全规范，被银行业广泛应用11PCI DSS（Payment Card Industry Data Security Standard）是是PCI SSC（Payment Card Industry Security Standards Council）所制定的卡支付行业数据安全标准。所制定的卡支付行业数据安全标准。l由由VISA、JCB、MASTERCARD、AMERICAN EXPRESS、DISCOVER FINANCIAL SERVICE 200606年设立的统一的支付卡行业信息

8、安全标准委员会年设立的统一的支付卡行业信息安全标准委员会lVISA 的的AIS（Account Information Security）PROGRAM发展而来发展而来lVISA的支付卡数据保护最佳实践：例如的支付卡数据保护最佳实践：例如 VISA的的PABP (Payment Application Best Practices)，20082008年被采纳作为年被采纳作为PA-DSS （Payment Application Data SECURITY STANDARD），PA-DSS已经代已经代替替PABP用于用于VISA的合规项目的合规项目lPCI SSC有相关工作组负责各自领域的标准开

9、发和体系维护技术工作：有相关工作组负责各自领域的标准开发和体系维护技术工作：DSS组、PED工工作组、作组、QSA（Qualified Security Assessors 合格的安全性评估机构合格的安全性评估机构）体系管理、体系管理、ASV（Approved Scanning Vendors授权扫描厂商授权扫描厂商）体系管理体系管理、PA（Payment Application)体系管理体系管理PCI DSS中规定了12项安全要求12高阶概述高阶概述对比对比 初步建议初步建议构建并维护安全网络构建并维护安全网络 要求1.安装防火墙配置并予以维护，以保护持卡人数据好加强正规流程，加强文档工作

10、要求2.系统密码和其它安全参数不要使用供应商提供的默认设置很好保护持卡人数据保护持卡人数据要求3保护存储的持卡人数据好在未来的设计中加强考虑，并建立机制要求4在开放型的公共网络中对持卡人数据进行加密传输很好维护漏洞管理程序维护漏洞管理程序要求5使用杀毒软件并定期更新很好要求6开发、维护安全系统和应用程序很好执行严格的访问控制措施执行严格的访问控制措施要求7只有具备业务需求的人才能访问持卡人数据好需要健全制度要求8为每位拥有计算机访问权限的人分配唯一的ID好需要推广单点登录，建立机制要求9限制对持卡人数据的物理访问好加强对媒介的管理与保护定期监控和测试网络定期监控和测试网络要求10跟踪和监控访问

11、网络资源和持卡人数据的所有操作差需要建立严格的机制要求11定期测试安全系统和流程差需要建立正式的流程维护信息安全政策维护信息安全政策要求12维护针对信息安全的政策很差需要建立并逐步完善政策、机制要求1：安装并维护防火墙配置，以保护持卡人数据的详细规定及分析13高阶概述高阶概述对比对比 1.1 建立包含以下各项的防火墙和路由器配置标准：1.1.1 为批准和测试所有网络连接以及更改防火墙和路由器配置制定正式流程没有正式的流程，建议未来纳入安全体系 1.1.2 提供当前网络架构图，必须包含所有与持卡人数据的连接，包括所有无线网络符合要求1.1.3 明确每个 Internet 连接处以及非军事化区(D

12、MZ)与内部网络区域之间的防火墙要求正在进行相关工作1.1.4说明网络组件逻辑管理组、角色及其责任符合要求1.1.5 书面说明允许的所有服务、协议和端口和业务原因，包括为那些认为不安全的协议实施的安全功能的文档缺乏书面文档，建议未来补充1.1.6 设置规则要求至少每 6 个月检查一次防火墙和路由器目前3个月检查一次，会清理冗余1.2 设置防火墙规则，拒绝任何没有受信的网络或主机接触持卡人数据和任何系统组件，只允许授权的协议通过1.2.1 根据IP地址限制网络必需的进出信息符合要求1.2.2 保护并同步路由器配置文件符合要求1.2.3 在任何无线网络和持卡人数据环境之间安装外围防火墙，并且将这些

13、防火墙配置为禁止或控制（如果业务目的需要这样的流量）从无线环境流入持卡人数据环境的信息符合要求要求1：安装并维护防火墙配置，以保护持卡人数据的详细规定及分析（2）14高阶概述高阶概述对比对比 1.3 禁止通过 Internet 直接访问系统组件和持卡人数据环境1.3.1 实施 DMZ 以限制只允许持卡人数据环境需要的协议的进出信息正在实施1.3.2 限制进入 DMZ 内部 IP 地址的Internet 信息正在实施1.3.3 不允许 Internet 和持卡人数据环境之间进出信息的任何直接路由符合要求1.3.4 不允许内部地址从 Internet 至 DMZ 通过正在实施1.3.5 限制从持卡

14、人数据环境至 Internet的传出信息只能访问DMZ 内部的 IP 地址正在实施1.3.6 实施状态检测，也即动态包过滤（也就是只有通过“建立”的连接才允许信息传输）符合要求1.3.7 在内部网络区域（从 DMZ 隔离开来的）中使用数据库正在实施1.3.8 实施 IP 伪装以防止内部地址被转译和发布到 Internet 上，使用 RFC 1918 地址空间或者网络地址转译(NAT)技术，例如端口地址转译(PAT)。符合要求1.4 通过至 Internet 的直接连接在任何移动和/或员工自有计算机上（例如员工使用的笔记本电脑）安装个人防火墙软件，然后才能用于访问机构网络。符合要求要求2：系统密

15、码和其他安全参数不使用供应商提供的默认设置的详细规定及分析15高阶概述高阶概述对比对比 2.1 在网络上安装系统以前，务必更改供应商提供的默认项，包括密码、简单网络管理协议(SNMP)机构字串，并删除不必要的账户。2.1.1 对于连接到持卡人数据环境或传输持卡人数据的无线环境，更改无线供应商默认项，包括但不局限于默认无线加密密钥、密码和 SNMP 机构字串。确保无线设备安全设置已启用，采用了严格的加密技术进行认证和传输基本作到，需要仔细检查现状，未来需要纳入体系要求2.2 制定所有系统组件的配置标准，符合行业接受的系统安全标准，并且确保安装所有已知的安全漏洞补丁包2.2.1 每台服务器只执行一

16、项主要功能（Web Server，APP Server，DNS，DB Server）符合要求2.2.2 禁用所有不必要和不安全的服务和协议（来执行设备特定功能的不必要的服务和协议）符合要求2.2.3 配置系统安全参数以防止滥用符合要求2.2.4 删除所有不必要的功能，例如脚本、驱动程序、属性、子系统、文件系统和不必要的 Web 服务器符合要求2.3 对所有非控制台管理访问进行加密。对于基于 Web 的管理和其他非控制台管理访问使用诸如 SSH、VPN 或 SSL/TLS 等技术符合要求2.4 共享托管提供商必须保护每个机构托管环境和持卡人数据。这些供应商必须满足：针对共享托管提供商的额外 PC

17、I DSS 要求中详细规定的具体要求N/A要求3：保护存储持卡人的数据的详细规定及分析16高阶概述高阶概述对比对比 3.1 使持卡人数据存储最小化。制定数据保留和处理政策。根据业务、法律和/或法规要求限制存储的大小和保留时间，在数据保留政策中进行记录。在未来的设计中需要采纳3.2 不在授权后存储敏感的验证数据（即使已经加密）。敏感验证数据包括下文要求 3.2.1 至 3.2.3 中列举的数据：3.2.1 不要存储磁条任意磁道上的完整内容（位于卡的背面、芯片上或其他位置）。该数据也可称为全磁道、磁道 1、磁道 2 和磁条数据注：在正常的业务过程中，以下磁条数据元素可能需要保留：持卡人姓名，主账户

18、(PAN)，失效期，以及 服务码为将风险降至最低，只存储业务所需的数据元素。需要考虑此安全思想，但要结合业务实际设计 方案3.2.2 不要存储用于验证离线交易的卡验证代码或值（印在支付卡正面或背面的三或四位数字）符合要求3.2.3 不要存储个人识别码(PIN)或经加密的 PIN 数据块。符合要求3.3 显示 PAN 时对其进行掩盖（最多可显示的数位包括前六位与后四位）。注：此要求不适用于那些因合法业务需要查看完整的 PAN 的员工和其他方。此要求不取代显示持卡人数据采用的更严格的要求，例如POS 收据。符合要求要求3：保护存储持卡人的数据的详细规定及分析（2）17高阶概述高阶概述对比对比 3.

19、4 通过以下方法尽量使 PAN 在存储的地方不可读（包括在便携式数字媒体、备份介质、日志中）：基于强效加密法的单向哈希 截词 索引记号与索引簿（索引簿必须安全地存储）使用具有密钥管理流程和过程的强效加密法注：在账户信息中，最应实现不可读的就是 PAN。如果因为某些原因，公司不能使 PAN 不可读，请参阅附录 B：补偿性控制。建议采用补偿性控制3.4.1 如使用了磁盘加密（而不是文件级或数据库列级加密），则对逻辑访问的管理必须独立于本地操作系统的访问控制机制（例如，不使用本地用户账户数据库）。解密密钥决不能与用户账户绑定。未来设计中采纳3.5 保护加密持卡人数据以防泄露和盗用的加密密钥：3.5.

20、1 将对加密密钥的管理人数尽量减到最少。未来安全体系中采纳3.5.2 将加密密钥以尽量少的形式安全存储在尽量少的地方。符合要求要求3：保护存储持卡人的数据的详细规定及分析（3）18高阶概述高阶概述对比对比 3.6 全面记录并实施用于加密持卡人数据的加密密钥采用的所有密钥管理流程和过程，包括以下各项：3.6.1 强效加密法密钥的生成符合要求3.6.2 安全的加密法密钥分发符合要求3.6.3 安全的加密法密钥存储符合要求3.6.4 定期更改加密密钥 认为有必要并且由相关应用程序推荐（例如重新加密）；首选自动 至少每年一次工作密钥符合，其它需要在未来体系中考虑3.6.5 弃用或更改旧的或疑似泄露的加

21、密密钥。需要建立相应机制3.6.6 加密密钥双重控制的分开保管和建立需要建立正规流程3.6.7 防止加密密钥的未授权更改符合要求3.6.8 要求密钥保管人签署声明他们知道并接受密钥保管责任的文件建议采纳要求4：在开放型的公共网络中传输持卡人数据时会加密的详细规定及分析 19高阶概述高阶概述对比对比 4.1 使用强效加密法和安全协议（例如SSL/TLS 或 IPSEC）以保护在开放型公共网络中传输敏感持卡人数据的安全。PCI DSS 范围内的开放型公共网络示例如：Internet，无线技术，移动通信的全球系统(GSM)和 通用无线分组业务(GPRS)。符合要求4.1.1 确保传输持卡人数据或连接

22、到持卡人数据环境的无线网络使用了行业最优方法（例如 IEEE 802.11i）对认证和传输实施了强效加密。对于新的无线实施，自 2009 年 3 月31 日起禁止实施 WEP。对于当前的无线实施，自 2010 年 6月 30 日起禁止使用 WEP。符合要求4.2 切勿使用终端用户通讯技术（例如，电子邮件、即时通讯工具、聊天工具等）发送未加密的 PAN。将来安全体系中采纳要求5：使用并定期更新杀毒软件或程序的详细规定及分析 20高阶概述高阶概述对比对比 5.1 在所有经常受恶意软件影响的系统上部署杀毒软件（特别是个人电脑和服务器上）。符合要求5.1.1 确保所有杀毒程序都能够监测、删除并防止所有

23、已知类型的恶意软件的攻击。符合要求5.2 确保所有杀毒机制都是最新并且在运行，而且能够生成审核日志。符合要求要求6：开发、维护安全系统和应用程序的详细规定及分析 21高阶概述高阶概述对比对比 6.1 确保所有系统组件和软件都安装了最新的供应商提供的安全补丁。在发布的一个月以内安装关键的安全补丁。要结合应用进行补丁升级6.2 建立一个流程来识别新发现的安全漏洞（例如，订阅 Internet 免费的警告服务）。根据 PCI DSS 要求 2.2 更新配置标准，以解决新的漏洞问题。正在实施6.3 根据 PCI DSS（例如，安全的认证和登录）并基于行业最优方法开发软件应用程序，并将信息安全融入到整个

24、软件开发生命周期中。这些程序必须包括以下各项：6.3.1 部署前，对所有的安全补丁、系统与软件配置的更改进行测试符合要求6.3.2 分开开发/测试环境与生产环境符合要求6.3.3 开发/测试环境与生产环境中的职责分离符合要求6.3.4 在测试或开发过程中不使用生产数据（真实的 PAN）符合要求6.3.5 在生产系统启动前清除测试数据与账户符合要求6.3.6 在激活应用程序或发布给用户以前，清除所有自定义应用程序账户、用户ID 和密码符合要求6.3.7 在发布生产以前检查自定义代码，以识别所有潜在的编码漏洞符合要求要求6：开发、维护安全系统和应用程序的详细规定及分析（2）22高阶概述高阶概述对比

25、对比 6.4 跟踪对系统组件进行的所有更改的更改控制流程。这些程序必须包括以下项目：6.4.1 影响记录符合要求6.4.2 相关方管理层的签发建议将来采纳6.4.3 对操作功能的测试符合要求6.4.4 取消流程符合要求6.5 基于安全编码指南开发所有 Web 应用程序（内部与外部的，以及对应用程序的Web 管理访问)，例如开放式 Web 应用程序安全项目指南。涵盖在软件开发过程中对常见编码漏洞的防护，包括以下各项：6.5.1 跨站脚本(XSS)符合要求6.5.2 注入攻击，特别是 SQL 注入。同时还须考虑 LDAP、Xpath 及其他注入攻击。符合要求6.5.3 恶意文件执行符合要求6.5.

26、4 不安全的直接对象引用符合要求6.5.5 跨站请求伪造(CSRF)符合要求6.5.6 信息泄露和不正确的错误处理符合要求要求6：开发、维护安全系统和应用程序的详细规定及分析（3）23高阶概述高阶概述对比对比 6.5.6 信息泄露和不正确的错误处理设计要完善6.5.7 失效的验证和会话管理符合要求6.5.8 不安全加密存储符合要求6.5.9 不安全通信符合要求6.5.10 未能限制 URL 访问符合要求6.6 对于面向公众的 Web 应用程序，经常解决新的威胁和漏洞，并确保保护这些应用程序不受到以下任一方法的攻击：通过手动或自动应用程序漏洞安全评估工具或方法检查面向公众的 Web 应用程序，至

27、少每年一次并在所有更改后进行检查。在面向公众的 Web 应用程序前端安装Web 应用程序防火墙符合要求要求7：限制为只有业务需要知道的人才能访问持卡人数据的详细规定及分析 24高阶概述高阶概述对比对比 7.1 将对系统组件和持卡人数据的访问限制为只有工作需要访问这些数据的人。访问限制必须包括以下项目：7.1.1 将特权用户 ID 的访问权限限制为执行工作职责要求的最小权限未来采纳此安全思想7.1.2 根据个人工作划分和职能分配权限符合要求7.1.3 要求管理层签署授权书以指明需要的权限未来纳入安全体系7.1.4 自动访问控制系统的实施符合要求7.2 为多用户系统组件建立访问控制系统，根据用户的

28、数据限制访问权限。缺省设置为“禁止所有”，除非特别允许。此访问控制系统必须包含以下各项：7.2.1 覆盖所有的系统组件符合要求7.2.2 根据工作划分和职能给个人分配权限符合要求7.2.3 默认的“禁止所有”设置符合要求要求8：为每位拥有计算机访问权限的用户分配唯一的 ID的详细规定及分析 25高阶概述高阶概述对比对比 8.1 在允许所有用户访问系统组件或持卡人数据之前为其分配唯一的 ID。部分符合要求，需要推广现有的LDAP8.2 除分配唯一的 ID 之外，至少采用以下一种方法验证所有用户的身份：密码或口令 双因素验证（例如令牌设备、智能卡、生物测定技术或公共密钥）采用密码8.3 员工、管理

29、员和第三方采用双因素验证以远程访问（从网络外进行网络级的访问）网络。使用远程拨入用户认证服务(RADIUS)、带有令牌的终端访问控制器访问控制系统(TACACS)或带有个人证书的 VPN（基于 SSL/TLS 或 IPSEC）等技术。采用VPN8.4 在所有系统组件上进行传输和存储操作时，采用强效加密术使所有密码不可读。符合要求8.5 确保在所有系统组件上都对非消费者用户和管理员都采用正确的用户身份认证和密码管理，具体如下：8.5.1 控制用户 ID、凭据和其他识别对象的添加、删除和修改操作。符合要求8.5.2 重置密码前确定用户身份。符合要求8.5.3 为每位用户的初始密码设置唯一值，第一次

30、使用后立即更改。符合要求要求8：为每位拥有计算机访问权限的用户分配唯一的 ID的详细规定及分析（2）26高阶概述高阶概述对比对比 8.5.4 立即撤销任何已终止用户的访问权限。需要改进8.5.5 至少每 90 天撤除/停用一次非活跃的用户账户。符合要求8.5.6 仅在所需时段启用供应商用于远程维护的账户。符合要求8.5.7 向拥有访问持卡人数据权限的所有用户通报密码程序和政策。需要改进8.5.8 不要使用组、共享或常规账户和密码。符合要求8.5.9 至少每 90 天更改一次用户密码。符合要求8.5.10 密码必 须至少有七个字符长。符合要求8.5.11 使用包含数字和字母字符的密码。符合要求8

31、.5.12 不允许个人提交和前四次使用过的任何密码相同的新密码。符合要求8.5.13 用户尝试次数达到六次后锁定该用户 ID，以限制尝试反复访问。符合要求8.5.14 将锁定时长设置为至少 30 分钟或直到管理员启用用户 ID 为止。符合要求8.5.15 如果会话保持空闲状态超过 15 分钟，则需要用户重新输入密码以重新激活终端。符合要求8.5.16 验证访问任何数据库（其中包括持卡人数据）的所有操作。这包括应用程序、管理员和所有其他用户的访问操作。需要改进要求9：限制对持卡人数据的物理访问的详细规定及分析 27高阶概述高阶概述对比对比 9.1 使用适当的机构入口控制，以在持卡人数据环境中限制

32、和监控系统的物理访问。9.1.1 使用摄像头或其他访问控制机制，以监控个人对敏感区域的物理访问。检查收集的数据并与其他入口相关联。至少保存三个月，法律另有规定的除外。符合要求9.1.2 限制对公共网络插座交换机的物理访问。符合要求9.1.3 限制对无线访问点、网关和手持式设备的物理访问。符合要求9.2 制订相关程序，以帮助所有员工迅速识别雇员和访客，尤其是在可以查看持卡人数据的区域迅速识别雇员和访客。建议未来安全体系采纳9.3 确保遵循以下程序处理所有访客：9.3.1 进入处理或维护持卡人数据的区域之前，必须获得授权符合要求9.3.2 提供可以将访客识别为非雇员而且使用后会过期的物理令牌（例如

33、工卡或访问设备）符合要求9.3.3 要求访客在离开机构之前或在过期日交出物理令牌符合要求9.4 使用访客日志，以保持访客活动的实体核查记录。在日志上记录访客姓名、所属公司以及授权访客进行物理访问的员工。将该日志至少保存三个月，法律另有规定的除外。符合要求9.5 将备份媒介存放在安全的地方，最好存放在机构之外的场所，例如其它场所或备用中心或商业性的存储机构。至少每年检查一次该场所的安全性。符合要求要求9：限制对持卡人数据的物理访问的详细规定及分析(2)28高阶概述高阶概述对比对比 9.6 采用物理方式保护包含持卡人数据的所有纸质媒介和电子媒介。需要改进9.7 始终严格控制在内部或外部分发任何类型

34、的包含持卡人数据的媒介，包括以下内容：9.7.1 将媒介分类，以便将其标识为“机密”。目前不需要，未来采纳9.7.2 使用安全的快递服务或其他可准确跟踪的传送方式寄送媒介。目前不需要，未来采纳9.8 将任何和所有包含持卡人数据的媒介从安全区域转移时（尤其是当媒介发放给个人时），务必确保管理层已同意。需要改进9.9 始终严格控制对媒介（其中包含持卡人数据）的存储和访问操作。需要改进9.9.1 正确保存所有媒介的盘存日志，媒介至少每年盘存一次。需要改进9.10 包含持卡人数据的媒介由于业务原因或法律原因不再需要时应予以销毁，具体如下：9.10.1 对硬拷贝材料进行粉碎、焚烧或打浆，让持卡人数据无法

35、复原。需要改进9.10.2 使电子媒介上的持卡人数据不可恢复，确保持卡人数据不可复原。需要改进要求10：跟踪和监控访问网络资源和持卡人数据的所有操作的详细规定及分析29高阶概述高阶概述对比对比 10.1 为每个个人用户建立一个可连接访问所有系统组件（尤其是具有根权限等管理权限的访问）的流程。未来需要采纳10.2 针对所有系统组件实施自动核查记录，以重建以下事件：10.2.1 对持卡人数据的所有个人访问符合要求10.2.2 具有根权限或管理权限的任何个人实施的所有操作符合要求10.2.3 访问所有核查记录符合要求10.2.4 无效的逻辑访问尝试符合要求10.2.5 使用身份认证和验证机制符合要求

36、10.2.6 初始化核查日志符合要求10.2.7 创建和删除系统级对象符合要求10.3 针对每个事件的所有系统组件至少记录以下核查记录条目：10.3.1 用户身份认证符合要求10.3.2 事件类型符合要求10.3.3 日期和时间符合要求10.3.4 成功指示或失败指示符合要求10.3.5 事件起源符合要求10.3.6 受损数据、系统组件或资源的特征或名称符合要求要求10：跟踪和监控访问网络资源和持卡人数据的所有操作的详细规定及分析(2)30高阶概述高阶概述对比对比 10.4 同步所有重要的系统时钟和时间。符合要求10.5 保护核查记录，以避免篡改。10.5.1 仅限出于工作需要的人员查看核查记

37、录。需要改进10.5.2 保护核查记录文件，防止未经授权的修改操作。需要改进10.5.3 将核查记录文件迅速备份到不易篡改的中心日志服务器或媒介。需要改进10.5.4 将外部式技术的日志写入外部 LAN上的日志服务器。需要改进10.5.5 针对日志使用文件完整性监控软件或更改检测软件，以确保现有的日志数据在不生成警报的情况下不会更改（尽管添加新数据不会引发警报）。需要改进10.6 每天至少检查一次所有系统组件的日志。日志检查必须包括检查执行入侵检测系统(IDS)和验证、授权等安全功能的服务器以及记账协议(AAA)服务器（例如 RADIUS）。需要改进10.7 核查历史记录至少保留一年，至少可以

38、立即准备（例如在线、已归档或从备份中恢复）三个月的历史记录以供分析。需要改进要求11：定期测试安全系统和流程的详细规定及分析31高阶概述高阶概述对比对比 11.1 至少每季度使用一次无线分析仪或部署可识别所有在用无线设备的无线 IDS/IPS，以测试无线访问点是否存在。需要改进11.2 至少每季度以及在网络有任何重大变动后（例如安装新的系统组件、更改网络拓扑、修改防火墙规则、产品更新）运行一次内部和外部网络漏洞扫描。需要改进11.3 外部和内部穿透测试每年至少执行一次，基础架构或应用程序有任何重大升级或修改后（例如操作系统升级、环境中添加子网络或环境中添加网络服务器）也应执行。此类穿透测试必须

39、包括以下内容：11.3.1 网络层穿透测试需要改进11.3.2 应用程序层穿透测试需要改进11.4 使用入侵检测系统和/或入侵防御系统，以监控持卡人数据环境中的所有流量并在发现可疑威胁时提醒员工。随时更新所有入侵检测引擎和入侵防御引擎。需要改进11.5 部署文件完整性监控软件，如发现未经授权修改重要系统文件、配置文件或内容文件的操作将提醒员工；配置该软件，使其至少每周比较一次重要文件。需要改进要求12：维护针对雇员和承包商信息安全的政策的详细规定及分析32高阶概述高阶概述对比对比 12.1 建立、发布、维护和散发可实现以下标准的安全政策：12.1.1 处理所有 PCI DSS 要求。需要参考1

40、2.1.2 包括可识别威胁和漏洞的年度流程并能生成正式的风险评估。需要改进12.1.3 包括至少每年执行一次检查并在环境变动时予以更新。需要改进12.2 根据此规格中的要求制订每日操作安全程序（例如用户帐户维护程序和日志查看程序）。需要改进12.3 针对面向员工的重要技术（例如远程访问技术、无线技术、可移动电子媒介、笔记本电脑、个人数据助理(PDA)、电子邮件使用和因特网使用）制订使用政策，以定义所有雇员和承包商正确使用这些技术的政策。确保此类使用政策要求以下内容：12.3.1 管理层的明确许可需要改进12.3.2 使用技术的授权需要改进12.3.3 所有此类设备和获得访问权限的员工列表需要改

41、进12.3.4 给设备贴标签并注明所有者、联系信息和用途需要改进12.3.5 可接受的技术使用方式符合要求12.3.6 可接受的技术网络位置符合要求要求12：维护针对雇员和承包商信息安全的政策的详细规定及分析（2）33高阶概述高阶概述对比对比 12.3.7 公司许可的产品列表需要改进12.3.8 非活跃状态达到特定时限后自动中断远程访问技术的会话需要改进12.3.9 仅在供应商需要时为其激活远程访问技术，并在使用后立即停用需要改进12.3.10 通过远程访问技术访问持卡人数据时，禁止将持卡人数据复制、移动和存储到本地硬盘和可移动电子媒介。需要改进12.4 确保安全政策和程序明确定义了所有雇员和

42、承包商的信息安全职责。需要改进12.5 针对个人或团队分配以下信息安全管理职责：需要改进12.5.1 建立、记录和分配安全政策和程序。需要改进12.5.2 监控、分析安全警报和安全信息并将其分配给相关人员。需要改进12.5.3 创建、记录和分配安全事故响应程序和逐层上报程序，以确保及时有效地处理所有情况。需要改进12.5.4 管理用户账户，包括添加、删除和修改需要改进12.5.5 监控和控制所有的数据访问操作。需要改进12.6 实施正式的安全意识计划，使所有雇员都能了解持卡人数据安全的重要性。12.6.1 雇员一经雇用后立即培训，之后每年至少培训一次。需要改进12.6.2 要求雇员每年至少确认

43、一次他们已阅读并了解公司的安全政策和程序。需要改进要求12：维护针对雇员和承包商信息安全的政策的详细规定及分析（3）34高阶概述高阶概述对比对比 12.7 雇用员工前筛选应征者，以尽量减少内部人员发起攻击的风险。需要改进12.8 如持卡人数据与服务提供商共享，应维护和实施管理服务提供商的政策和程序，以包括以下各项：12.8.1 保留服务提供商列表。需要改进12.8.2 要求服务提供商出具书面协议，由其确认对自己拥有的持卡人数据的安全性负责，并保留此协议。需要改进12.8.3 确保已建立雇用服务提供商的流程（包括雇用前相应的尽职调查）。需要改进12.8.4 始终遵循计划，以监控服务提供商的 PC

44、I DSS 遵从性状态。需要改进12.9 实施事故响应计划。随时准备立即响应系统漏洞事故。需要改进12.9.1 创建“事故响应计划”，以便在发现系统漏洞时实施。确保计划至少可以处理以下各项：发生漏洞时的角色、职责和沟通策略以及联系策略，至少包括通知支付品牌；特定的事故响应程序；业务恢复和业务连续性程序；数据备份流程；分析报告漏洞的法律要求；所有重要系统组件的范围和响应；来自支付品牌的参考或包涵事故响应程序需要改进要求12：维护针对雇员和承包商信息安全的政策的详细规定及分析（4）35高阶概述高阶概述对比对比 12.9.2 至少每年测试一次计划。需要改进12.9.3 指定一天 24 小时、一周 7

45、 天随时准备响应警报的特定人员。需要改进12.9.4 针对负责响应安全漏洞的员工提供相应培训。需要改进12.9.5 包括来自于入侵检测系统、入侵防御系统和文件完整性监控系统的警报。需要改进12.9.6 根据以往的经验教训、结合行业发展情况制订有关修改和改进事故响应计划的流程。需要改进主要内容 改进建议制定思路 风险与安全现状分析 银行支付安全模式分析 PCI DSS支付安全规范研究 CUPSecure安全规范研究 网银安全规范研究 银行密钥体系研究 电子商务安全措施研究 EMV安全规范研究 安全模型设计36CUPSecure是银联制定的网上交易支付安全标准37中国银联中国银联CUPSecure

46、：即网上安全控制系统，是中国银联电子支付验证和授权方案，内容覆盖了持卡人验证和交易授权两部分，是中国银联互联网支付的核心，实现了人民币卡在线进行安全支付验证。SC（Securtiy Control）：）：银联建立的安全信息输入系统，是CUPSecure的主控系统。它相当于交换系统的网络前置，负责互联网持卡人认证部分的消息传递。API（Authentication Plug-in）：）：即CUPSecure系统中收单系统插件，由收单机构负责与其收单系统进行整合，为收单系统与SC/SR之间的安全接口。SA（Security Authentication）：）：持卡人安全认证系统，等同于3-D Se

47、cure中的ACS。SR（Security Route）：）：路由确定，为CUPSecure的主控部分，负责CUPSecure的整个网上交易信息路由。SI（Security Interactive）：）：即持卡人安全互动系统，由银联建立，负责为持卡人提供原有持卡人验证之外的辅助性安全服务。SI和发卡行对持卡人采取双重认证，任何一种认证未通过都不能完成网上交易。银联安全输入模式：银联安全输入模式：在银联安全输入模式中，由安全信息输入服务器负责提供安全便利的交互界面供持卡人输入安全信息。安全信息输入成功后，相关支付信息由收单机构随联机交易报文送CUPS，CUPS将加密后的安全信息填入相关报文域后，

48、将报文转发给发卡机构，由发卡机构认证并完成相应支付交易。由于由于CUPSecure处理逻辑复杂，其基本原理可以通过处理逻辑复杂，其基本原理可以通过Visa 3DSecure说明说明1 验证注册过程，即验证持卡验证注册过程，即验证持卡人是否注册了人是否注册了3-D Secure服务服务2 持卡人验证过程，即通过持持卡人验证过程，即通过持卡人设定的验证信息，验证是卡人设定的验证信息，验证是否是持卡人本人否是持卡人本人3 交易授权过程，即通过支付交易授权过程，即通过支付平台产生的验证信息，验证交平台产生的验证信息，验证交易是否是合法交易易是否是合法交易3D Secure（3 Domain Secur

49、e）由发卡域（）由发卡域（Issuer Domain）、收单域（）、收单域（Acquirer Domain）和协作域（）和协作域（Interoperability Domain）三个域组成，）三个域组成，通过三个域组件交互实现网上安全支付身份验证和网上安全收单机制。通过三个域组件交互实现网上安全支付身份验证和网上安全收单机制。CUPSecure支付流程符合支付流程符合3DSecure的基本原理，并提供发卡机构代理服务（的基本原理，并提供发卡机构代理服务（SC模式，银模式，银联安全输入模式）联安全输入模式）国际卡组织3D Secure和中国银联 CUPSecure为银行卡安全支付提供了统一的支付

50、验证与授权方案基于 的实际情况，不会照搬银行的做法，但是可以参考银行网上支付安全体系适当修正。401 验证注册过程，即验证持卡人是否注册了3-D Secure服务2 持卡人验证过程，即通过持卡人设定的验证信息，验证是否是持卡人本人3 交易授权过程，即通过支付平台产生的验证信息，验证交易是否是合法交易银行机制银联ITSC/SA：独立的安全注册、认证系统SR：独立的交易路由系统SI：独立的辅助安全认证系统API：为商户提供安全插件CUPS：交易授权系统目前 的易购平台使用支持 易付宝、预付费卡、优惠券及银行卡支付，可以暂不考虑完全遵照CUPSecure规范。可以借鉴注册认证、持卡人身份认证和交易授