20180111-PCIDSS支付卡行业数据安全标准的合规实践

Posted by PaymentGroup on January 11, 2018

主题分享

大家好,我叫XXX,主要负责公司信息安全与IT风险管理工作,很高兴给大家分享PCIDSS支付卡行业数据安全标准的合规实践。

什么是PCI DSS?

Payment Card Industry Data Security Standard支付卡行业数据安全标准。PCI DSS标准是面向持卡人数据环境的应用、系统、网络、物理环境、策略流程和人员管理等,从业务数据的存储、传输和处理出发关注全面且持续的信息安全建设。

PCI DSS的背景

由PCI安全标准委员会的创始成员(Visa、Mastercard、American Express、Discover Financial Services、JCB等五大发卡组织)制定的一致数据安全措施。

PCI DSS的目标

  • PCI DSS加强和保持数据安全性,提供了保护持卡人数据的技术和操作要求,旨在保护持卡人数据,并通过额外控制和最佳实践方法减少风险。
  • PCI DSS适用于所有涉及支付卡处理的机构—包括第三方收单机构、发卡行、商户、服务提供商和其他涉及存储、传输或者处理持卡人数据的机构,目前是作为五大发卡组织开展相关业务的准入条件之一。
  • PCI DSS的认证周期为每年一次,认证通过后延续一年有效期,目前执行的评估标准为2016年4月发布的V3.2。

PCIDSS 3.2标准要求:6大类,12大项,300余子项。
20180111_192704

持卡人数据范围:持卡人数据CHD和敏感验证数据SAD,共7类。
20180111_192748

存储要求

表格列举了持卡人数据和敏感验证数据的常用元素,是否允许存储各数据元素,以及是否必须保护各数据元素。
20180111_192827

业务视角数据梳理

  • 支付流程:请款/支付授权;对账/清结算;退款/拒付;发卡。
  • 传输途径:公网,内网,电话。
  • 支付通道:银联通道、银行通道、三方通道。

分析与识别

  • 存在位置:数据库、备份介质、文件柜、服务器。
  • 存在形态:数据内容、日志文件、纸张、单据。
  • 识别方法:识别工具,人工检查。

数据流向

  • 数据备份:备份站点、备份介质、可移动介质。
  • 日志与报表:数据包、业务日志、管理报表。
  • 第三方合作:交易数据、其他。

PCI DSS为何需要持续合规

相对与其他资质而言,PCI DSS 的合规实现和评估工作范围广、复杂度高、周期长,通过认证的支付机构,只有将PCI DSS标准要求融入信息安全体系运行的日常工作中,内化为涉卡人员日常行为操守,方可有效防范数据泄露的风险,提升威胁攻击的难度,同时更好地从持卡人数据的保护环节、安全运营环境的维护等方面维系持续合规状态。
PCI DSS同时也是一个不断更新的标准,为了应对支付业务技术发展的日新月异及其安全风险的衍生,周期化的标准版本发布更新,意味着合规要求需要与时俱进,因而对于刚刚通过认证的支付机构而言,获证之际既是终点,更是新起点。
PCI DSS的持续合规不仅是达到卡组织监管的强制性要求,更是进一步强化机构内部的控制和体系管理能力,塑造企业合规经营形象,增强往来机构信任度。
PCI DSS持续合规关注的着力点包括但不仅限于如下方面:

  1. 每季度执行:
    • 持卡人数据存储范围的梳理,持卡人数据的到期清理。
    • 评估及梳理完整卡号显示的业务合理性。
    • 针对涉卡环境中非授权无线网络的检测和处置。
    • 内部涉卡网络扫描以及外部ASV扫描及其整改。
  2. 每年度执行:
    • 覆盖开发、测试、代码审核人员以及安全响应人员的技能培训。
    • WEB应用服务的定期检查及修复工作,以及内外部渗透测试工作。
    • 访问控制设备的规则检查(每年上下半年各一次)。
    • 涉卡物理环境的安全评估工作。
    • POS使用方的安全巡检,POS使用商户及服务商的安全培训。
    • 安全事件的应急演练及行业安全事件的分享总结。
  3. 重大变化或重要变更时执行:
    • 密钥管理员变更时,所涉及管理的密钥需要及时变更,新密钥管理员需要在安全管理员的授权下签署密钥责任书.
    • 系统重大变更或网络环境变化时,维护系统对应变更组件的合规要求,如更新网络拓扑图及持卡人数据流向图.
    • 对于涉卡软件的开发测试环节,确保移除账号、密码等敏感数据,不使用真实的生产环境涉卡数据,执行覆盖OWASP top10的代码审核及安全测试.
    • 新版本发布时,需要审核并制定相应回滚流程,去除所有默认的账号密码,同时对其启用的功能和协议采取最小化的处理模式,维护涉卡系统的组件清单。
    • 对于通过内外部扫描新发现的漏洞,及时应对处置修复,涉及高危漏洞要求在一个月内完成修复,中危漏洞要求在一定周期内处置完毕。

Q&A

Q1、银联有自己的标准吗?国内对这个标准是什么态度,强制某类公司必须符合吗?
A、目前银联执行的标准是 ADSS银联卡收单机构信息安全管理标准。银联的ADSS标准2012年第一次发布,其实就是中国版的PCIDSS,但是后续断了好几年,从2017年开始,银联又重新发出通知要求各大支付机构强制符合ADSS的标准
A2、嗯,那就是这个国际标准国内不强求呗。
A3、对,如果你没有外卡业务就不是强制选项,有外卡业务必须强制。
A4、但是国内ADSS是强制的,合规实践也大同小异。
A5、国内的现状是,如果是应付监管,填表提交即可,但是要做好数据安全,任重道远。去年《网络安全法》的发布,个人信息安全问题也日益突显,也是黑产最需要的资源,数据安全从源头上保护用户数据的安全,并减少反欺诈和商户套利的风险。

Q2、请问你们有找第三方做一些PCI的指导吗 还是纯靠自己呀?
A1、我本人之前就是做信息安全和IT风险咨询的,所以经验还算丰富,都是自己做,年度现场审核的时候可以和审核老师交流。

Q3、了解信用卡主副卡概念吗?
A1、附属卡的所有权是属于主卡的,主卡可以对附属卡执行任何操作,包括冻结、销户等。你具体想问什么?

Q4、另外这些敏感数据中pin模块是指?
A1、PIN/PIN数据块:个人识别码,即密码。
A2、副卡只能消费,其他任何权限都没有对不对?
A3、除了额度共用外,主卡与附属卡基本上可视作两张独立的卡片,主卡挂失后,并不影响附属卡使用,反之亦然。
A4、预付卡和信用卡是两个概念,而且你们有支付牌照吗,如果没有,应该是只能做单用途预付卡,不能做多用途预付卡业务的(携程单用途预付卡变成多用途使用被查违规就是因为没牌照)

Q5、是不是用一些公有云的话 比如阿里云 基本肯定不符合PCI啦? 没有对机房的control
A1、好问题,现在云计算公司和PCI机构合作做公有云方面的PCIDSS认证,只要云计算公司符合PCIDSS的要求,基础环境就符合了,检测机构关注应用层面。
A2、 我们也在逐渐开始覆盖到我们的大商户方面,要求他们符合PCIDSS的要求,例如最近央行新规出来后,代扣代付通道都关闭了,无账号快捷支付业务发展较快,交易过程中大商户在某些场景可能会接触到卡数据信息,所以我们也对他们提出相应的数据安全保护要求。

Q6、现在很多收单机构做的套现工具 在用户支付时都会提交cvv2码 这个会不会有安全隐患?
A1、有个案例看分享下,例如大商户华住酒店APP可以绑卡支付,他们无支付牌照,其实是调用银联的支付通道完成支付的,中间涉及到一些卡数据可能留存在华住酒店公司,所以华住酒店也做了PCIDSS。

Q7、这些工具会不会保存这些数据 或者有什么规避?
A1、CVV2是敏感验证数据,根据PCIDSS或国内ADSS合规要求,是不允许存储的。
A2、你说的收单机构的如果存储了,那是违规的。
A3、明白 但套现本身不就是违规的吗 不在乎在家一个罪名吧。
A4、是的,所以接入段在他那边,你没法规避,除非用户不用。

Q8、做ADSS认证要多少钱?
A1、8万,还可以谈,银行卡检测中心和CFCA,两家可选。
A2、嗯,前几天跟银联的商务接触,跟我说10万。多谢

Q9、中金支付就是cfca吗?
A1、子公司。
A2、中金国盛跟你们有关系嘛?(那是人民银行金融电子化公司的企业)
A3、没关系,中金国信也是我们子公司。


招聘

  • 今日头条老熊团队在招聘, 支付产品经理、研发工程师都需要,工作地点:北京、上海, 猛击这里查看
  • 有赞团队在招聘, 支付产品经理、架构师、研发工程师, 工作地点:北京、杭州, 猛击这里查看

蚂蚁金服-互联网金融监管科技高级专家/资深专家(成都,北京)

基于蚂蚁金服各种领先的产品和技术,将应用技术与大数据融合,治理信息架构、监管合规数据,前瞻挖掘业务合规风险,提出专家意见,设计输出全球各种监管政策要求下,各种监管应对、合规风险巡检、监管合规决策技术方案,最终建成蚂蚁监管合规平台体系,消除业务监管合规风险,推动业务创新,通过技术创新、大数据、算法应用等手段建设自动化、智能化的监管合规产品,拓展监管科技、引领监管成为行业的标杆。 1、负责互联网金融监管领域的监管应对和规划,负责监管视角的架构、业务治理,前瞻挖掘业务合规风险,提出专家意见,推动业务创新,制定策略及统筹规划。
2、作为互联网金融领域的专家,同合规业务部门互动与各监管部门进行有效的书面和口头沟通。
3、作为业务型架构师能够带领研发团队完成公司监管应对的业务梳理和研发,指导解决方案架构师和域架构师对业务方向的前瞻性和带来的体系化思维。根据监管的动向以及公司自身业务特点规划制定业务架构,年度规划并推动落实,评审应用架构方案,负责核心功能的架构域代码模板的编写,协同上下游团队予以改善。

职位描述 1、专注于技术和业务、对业界的最新技术发展动态和互联网金融政策动态有比较密切的关注,同时对电子商务、金融行业、银行业或第三方支付行业有较深刻的理解,和敏感的触觉,能前瞻性提出行业解决方案;
2、具备5年以上的行业(金融银行、或者理财、基金等)架构师经验,有互联网业务的经验,能在架构设计及监管合规风险识别应对上有过往经验,有银行内审、风险管理等相关工作经验的优先考虑;
3、熟悉相关业务和风险管理要求以及监管要求,具有全面的企业风险识别、评估及管理知识和经验,具有较强逻辑思维和结构化思维能力,善于挖掘问题背后的本质,较强的沟通协调能力和独立分析、判断能力,能独立开展工作;
4、有独立带领团队的经历,并能体现较强的领导能力,善于学习,有较强的逻辑分析及文字表达能力者,优先考虑。
5、在大型金融或互联网企业中,负责过核心业务项目并成功实施落地的,优先考虑;
6、具有金融行业系统应用架构工作经验者,熟悉行业业务模型和应用架构模型者,优先考虑;
7、熟悉云计算技术架构者,优先考虑。

简历请发送到 junze.yu@alipay.com

本文档来自“支付产品架构交流群” 的聊天记录整理,由志愿者整理并发布到本网站。如需要及时收到来自“支付产品架构交流群”的最新消息,请扫码关注“凤凰牌老熊”的微信公众号。目前支付产品架构群还有不少空位。 本群面向支付行业的有经验(2年以上)的产品经理、软件工程师、架构师等,提供交流平台。如想加入本群,请在本文评论中留言(不公开),说明所在的公司、负责的工作、入群分享的主题和时间。