PCI Security Standards on Big Data Platform (1)

Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin

PCI Security Standards on Big Data Platform (1)

2016/11/20

1


Agenda PCI Security Standards PTS PA-DSS PCI-DSS TSP

P2PE Card Production Logical Security Requirements

and Physical Security Requirements Case Study: Apple Pay

Introduction to Cloudera Distribution Hadoop MIT Kerberos on CDH Apache Sentry on CDH PCI-DSS on CDH

1

2

32


Be a Product Manager of Fin-Tech YOU have to know

PCI Security Standards

3


Product innovation in FinTech

4


We all have a responsibility to protect and safeguard our customers accounts

5



6


Payment Card Industry

Prepaid Card

Debit&Credit Card

E-Wallet

ATM

POS

7


Financial institutions Association Merchant POS Processor Others

Participating Organizations

Founding Members

8


1. PCI Data Security Standard (PCI-DSS)

2. Payment Application Data Security Standard (PA-DSS)

3. PIN Transaction Security (PTS) Requirements

4. PCI Point-to-Point Encryption Standard (P2PE)


5. PCI Card Production Logical Security Requirements and Physical Security Requirements

6. PCI Token Service Provider (TSP) Security Requirements

9


PTSPIN Transaction Standard

7 Control Objects includes 33 PIN Security Requirements

11

Object 1: Manufacturers


Insert a debit card into the ATM

13


Enter the PIN when prompted

14


Withdraw money from ATM

15


Login to online banking

16


PIN17


PINs used in transactions governed by these requirements are processed using equipment and methodologies that ensure they are kept secure.

1

PIN

18


Cryptographic keys used for PIN encryption/decryption and related key management are created using processes that ensure that it is not possible to predict any key or determine that certain keys are more probable than other keys.

2

GENKEY

19


Keys are conveyed or transmitted in a secure manner.320


Key-loading to HSMs and PIN entry devices is handled in a secure manner. 4

21


Keys are used in a manner that prevents or detects their unauthorized usage.5

22


Keys are administered in a secure manner.623


Equipment used to process PINs and keys is managed in a secure manner.7

24


Payment Application Data Security Standard

25

Object 2: Software Developments

12 PA-DSS Requirements


Payment Application

27


Hacked into your server

28


And THEN..

29


Payment Application

30


Do not retain full track data, card verification code or value (CAV2, CID, CVC2, CVV2), or PIN block data.1

Volatile

31


Protect stored cardholder data.232


Provide secure authentication features.333


Log payment application activity.434


Develop secure payment applications.535


Protect wireless transmissions.636


Test payment applications to address vulnerabilities and maintain payment application updates.7

37


Facilitate secure network implementation.838


Cardholder data must never be stored on a server connected to the Internet.9

39


Facilitate secure remote access to payment application.1040


Encrypt sensitive traffic over public networks.1141


Secure all non-console administrative access.1242


Maintain a PA-DSS Implementation Guide for customers, resellers, and integrators13

43

Customers

Resellers

Integrators


Assign PA-DSS responsibilities for personnel, and maintain training programs for personnel, customers, resellers, and integrators.14

44


Payment Card Industry Data Security Standard

45

Object 3: Merchants & Service Providers

6 Goals 12 PCI-DSS Requirements


Types of Data on a Payment Card

47


The security of cardholder data affects everybody

48


Cardholder Data

49


Install and maintain a firewall configuration to protect cardholder data.1Goal (1) : Build and Maintain a Secure Network and Systems

50


Do not use vendor-supplied defaults for system passwords and other security parameters.2

Goal (1) : Build and Maintain a Secure Network and Systems

51


Protect Stored Cardholder Data.3Goal (2) : Protect Cardholder Data

52


Encrypt transmission of cardholder data across open, public networks.4Goal (2) : Protect Cardholder Data

53


Protect all systems against malware and regularly update anti-virus software or programs.5

Goal (3) : Maintain a Vulnerability Management Program

54


Develop and maintain secure systems and applications.6Goal (3) : Maintain a Vulnerability Management Program

55


Restrict access to cardholder data by business need to know.7Goal (4) : Implement Strong Access Control Measures

56


Identify and authenticate access to system components.8Goal (4) : Implement Strong Access Control Measures

57


Restrict physical access to cardholder data.9Goal (4) : Implement Strong Access Control Measures

58


Track and monitor all access to network resources and cardholder data.10Goal (5) : Regularly Monitor and Test Networks

59


Regularly test security systems and processes.11Goal (5) : Regularly Monitor and Test Networks

60


Maintain a policy that addresses information security for all personnel. 12Goal (6) : Maintain an Information Security Policy

61


TSPPayment Card Industry Token Service Provider Security

62

Object 4: Token Service Provider

8 TSP Requirements


Mobile payment and digital wallet service

63


source:visa

65

https://usa.visa.com/dam/VCOM/Media%20Kits/PDF/visa-security-tokenization-infographic.pdf


Token Data68


Additional TSP Requirements

1. Document and validate PCI DSS scope

2. Secure TDE Systems and Network

3. Protect and manage cryptographic keys

4. Restrict access to TDE by business need to know

5. Identify and authenticate all access to TDE systems

6. Restrict physical access to the TDE

7. Monitor all access to TDE

8. Maintain an Information Security Policy

Token Data Environment

69


NEXT

PCI Point-to-Point Encryption Standard (P2PE)

PCI Card Production Logical Security Requirements and Physical Security Requirements

70

PCI Standard on Big Data Platform (2)


Reference(1)PCI-SSC, Apr 2016, PCI DSS Requirements and Security Assessment Procedures v3.2(2)PCI-SSC, Jun 2016, PCI DSS Quick Reference Guide v3.2(3)PCI-SSC, May 2016, PA DSS Requirements and Security Assessment Procedures v3.2(4)PCI-SSC, May 2016, PA DSS Program Guide v3.2(5)PCI-SSC, Dec 2016, PCI TSP Additional Security Requirements and Assessment

Procedures for Token Service Providers (EMV Payment Tokens) v1.0 (6)PCI-SSC, Dec 2014, PCI PIN Security Requirements and Testing Procedures v2.0(7)PCI-SSC, Jul 2015, PCI P2PE Solution Requirements and Testing Procedures v2.0(8)VISA, VISA Security Tokenization Infographic, https://usa.visa.com/dam/VCOM/Media%20Kits/PDF/visa-security-tokenization-infographic.pdf

71



THANK YOU FOR YOUR ATTENTION

72


Appendix APIN Security Requirements


PTS Control Objective 1 :

PINs used in transactions governed by these requirements are processed using equipment and methodologies that ensure they are kept secure.

PIN Security Requirements

1. All cardholder-entered PINs must be processed in equipment that conforms to the requirements for secure cryptographic devices (SCDs). PINs must never appear in the clear outside of an SCD.

2. Cardholder PINs shall be processed in accordance with approved standards. (a)All cardholder PINs processed online must be encrypted and decrypted using an approved

cryptographic technique that provides a level of security compliant with international and industry standards. Any cryptographic technique implemented meets or exceeds the cryptographic strength of TDEA using double-length keys.

(b)All cardholder PINs processed offline using IC card technology must be protected in accordance with the requirements in Book 2 of the EMV IC Card Specifications for Payment Systems and ISO 9654.

3. For online interchange transactions, PINs must be only encrypted using ISO 95641 PIN-block formats 0, 1, 3 or 4. Format 2 must be used for PINs that are submitted from the IC card reader to the IC card.

4. PINs must not be stored except as part of a store-and-forward transaction, and only for the minimum time necessary. If a transaction is logged, the encrypted PIN block must be masked or deleted from the record before it is logged.

74


PTS Control Objective 2 :

Cryptographic keys used for PIN encryption/decryption and related key management are created using processes that ensure that it is not possible to predict any key or determine that certain keys are more probable than other keys.


5. All keys and key components must be generated using an approved random or pseudo-random process.

6. Compromise of the key-generation process must not be possible without collusion between at least two trusted individuals.

7. Documented procedures must exist and be demonstrably in use for all key-generation processing.

75


PTS Control Objective 3:

Keys are conveyed or transmitted in a secure manner.


8. Secret or private keys shall be transferred by: (a)Physically forwarding the key as at least two separate key shares or full-length components (hard

copy, smart card, SCD) using different communication channels, or (b)Transmitting the key in ciphertext form. Public keys must be conveyed in a manner that protects their integrity and authenticity.

9. During its transmission, conveyance, or movement between any two organizational entities, any single unencrypted secret or private key component must at all times be protected. Sending and receiving entities are equally responsible for the physical protection of the materials involved.

10.All key-encryption keys used to transmit or convey other cryptographic keys must be (at least) as strong as any key transmitted or conveyed.

11.Documented procedures must exist and be demonstrably in use for all key transmission and conveyance processing.

76



Key-loading to HSMs and PIN entry devices is handled in a secure manner.


12.Secret and private keys must be input into hardware (host) security modules (HSMs) and PIN entry devices (PEDs) in a secure manner. (a)Unencrypted secret or private keys must be entered using the principles of dual control and split

knowledge. (b)Key-establishment techniques using public-key cryptography must be implemented securely.

13.The mechanisms used to load secret and private keyssuch as terminals, external PIN pads, key guns, or similar devices and methodsmust be protected to prevent any type of monitoring that could result in the unauthorized disclosure of any component.

14.All hardware and access/authentication mechanisms (e.g., passwords) used for key loading must be

managed under the principle of dual control.

15.The loading of keys or key components must incorporate a validation mechanism such that the authenticity of the keys is ensured and it can be ascertained that they have not been tampered with, substituted, or compromised.

16.Documented procedures must exist and be demonstrably in use (including audit trails) for all key-loading activities.

77



Keys are used in a manner that prevents or detects their unauthorized usage.


17.Unique, secret cryptographic keys must be in use for each identifiable link between host computer systems between two organizations or logically separate systems within the same organization.

18.Procedures must exist to prevent or detect the unauthorized substitution (unauthorized key replacement and key misuse) of one key for another or the operation of any cryptographic device without legitimate keys.

19.Cryptographic keys must be used only for their sole intended purpose and must never be shared between production and test systems.

20.All secret and private cryptographic keys ever present and used for any function (e.g., key-encipherment or PIN-encipherment) by a transaction-originating terminal (e.g., PED) that processes PINs must be unique (except by chance) to that device.

78



Keys are administered in a secure manner.


21.Secret keys used for enciphering PIN-encryption keys or for PIN encryption, or private keys used in connection with remote key-distribution implementations, must never exist outside of SCDs, except when encrypted or securely stored and managed using the principles of dual control and split knowledge.

22.Procedures must exist and must be demonstrably in use to replace any known or suspected compromised key, its subsidiary keys (those keys encrypted with the compromised key), and keys derived from the compromised key, to a value not feasibly related to the original key.

23.Keys generated using reversible key-calculation methods, such as key variants, must only be used in SCDs that possess the original key. (a)Keys generated using reversible key-calculation methods must not be used at different levels of the

key hierarchy. For example, a variant of a key-encryption key used for key exchange must not be used as a working key or as a Master File Key for local storage.

(b)Keys generated using a non-reversible process, such as key-derivation or transformation process with a base key using an encipherment process, are not subject to these requirements.

24.Secret and private keys and key components that are no longer used or have been replaced must be securely destroyed.

79



Keys are administered in a secure manner.


25.Access to secret and private cryptographic keys and key material must be: (a)Limited to a need-to-know basis so that the fewest number of key custodians are necessary to enable

their effective use; and (b)Protected such that no other person (not similarly entrusted with that component) can observe or

otherwise obtain the component.

26.Logs must be kept for any time that keys, key components, or related materials are removed from storage or loaded to an SCD.

27.Backups of secret and private keys must exist only for the purpose of reinstating keys that are accidentally destroyed or are otherwise inaccessible. The backups must exist only in one of the allowed storage forms for that key. Note: It is not a requirement to have backup copies of key components or keys.

28.Documented procedures must exist and must be demonstrably in use for all key-administration

operations.

80



Equipment used to process PINs and keys is managed in a secure manner.


29.PIN-processing equipment (e.g., POI devices and HSMs) must be placed into service only if there is assurance that the equipment has not been substituted or subjected to unauthorized modifications or tampering prior to the deployment of the deviceboth prior to and subsequent to the loading of cryptographic keysand that precautions are taken to minimize the threat of compromise once deployed.

30.Physical and logical protections must exist for deployed POI devices.

31.Procedures must be in place and implemented to protect any SCDsand ensure the destruction of any cryptographic keys or key material within such deviceswhen removed from service, retired at the end of the deployment lifecycle, or returned for repair.

32.Any SCD capable of encrypting a key and producing cryptograms (i.e., an HSM or key-injection/loading device) of that key must be protected against unauthorized use to encrypt known keys or known key components. This protection takes the form of one or more of the following: (a)Dual access controls required to enable the key-encryption function (b)Physical protection of the equipment (e.g., locked access to it) under dual control (c)Restriction of logical access to the equipment

33.Documented procedures must exist and be demonstrably in use to ensure the security and integrity of PIN-processing equipment (e.g., POI devices supporting PIN and HSMs) placed into service, initialized, deployed, used, and decommissioned.

81


Appendix BPA-DSS Requirements


PA DSS Requirements

1. Do not retain full track data, card verification code or value (CAV2, CID, CVC2, CVV2), or PIN block data.

2. Protect stored cardholder data.3. Provide secure authentication features.4. Log payment application activity. 5. Develop secure payment applications.6. Protect wireless transmissions.7. Test payment applications to address vulnerabilities and maintain payment

application updates.8. Facilitate secure network implementation. 9. Cardholder data must never be stored on a server connected to the Internet.10. Facilitate secure remote access to payment application.11. Encrypt sensitive traffic over public networks.12. Secure all non-console administrative access.13. Maintain a PA-DSS Implementation Guide for customers, resellers, and

integrators14. Assign PA-DSS responsibilities for personnel, and maintain training programs

for personnel, customers, resellers, and integrators.

83


Testing Laboratory Requirements

1. Install payment application per vendors installation instructions or training provided to customer.

2. Install and test all payment application versions listed in PA-DSS report. 3. Install and implement all PCI DSS required security devices. 4. Install and/or configure all PCI DSS required security settings. 5. Simulate real-world use of the payment application. 6. Provide capabilities for, and test using, the following penetration testing

methodologies: Use of forensic tools/methods Attempt to exploit application vulnerabilities Laboratory and/or processes attempted to execute arbitrary code during the

payment application update process7. Use vendors lab ONLY after verifying all requirements are met. 8. Maintain an effective quality assurance (QA) process.

84


Appendix CPCI-DSS Requirements


Goals PCI DSS Requirements

Build and Maintain a Secure Network and Systems

1. Install and maintain a firewall configuration to protect cardholder data.2. Do not use vendor-supplied defaults for system passwords and other

security parameters.

Protect Cardholder Data 3. Protect Stored Cardholder Data.4. Encrypt transmission of cardholder data across open, public networks.

Maintain a Vulnerability Management Program

5. Protect all systems against malware and regularly update anti-virus software or programs.6. Develop and maintain secure systems and applications.

Implement Strong Access Control Measures

7. Restrict access to cardholder data by business need to know.8. Identify and authenticate access to system components. 9. Restrict physical access to cardholder data.

Regularly Monitor and Test Networks

10. Track and monitor all access to network resources and cardholder data.11. Regularly test security systems and processes.

Maintain an Information Security Policy 12. Maintain a policy that addresses information security for all personnel.

86


Appendix DTSP Requirements


PCI DSS Requirements Additional Applicability for TSPs 1. Install and maintain a firewall configuration to protect

cardholder data. Firewall controls in PCI DSS Requirement 1 also apply to internal

firewalls used to separate TDE from non-TDE networks.

The current network and data flow diagrams (PCI DSS Requirements 11.2 and 1.1.3) must also include all connections between the TDE and other networks, and all flows of Payment Tokens across systems and networks in the TDE.

2. Do not use vendor-supplied defaults for system passwords and other security parameters.

PCI DSS Requirement 2 applies to all system components in the TDE.

Wireless environments are not permitted to be connected to the TDE.

3. Protect Stored Cardholder Data. Data retention and disposal policies, procedures and processes (PCI DSS Requirement 3.1) also apply to Payment Token Data.

Payment Tokens must also be masked when displayed such that only personnel with a legitimate business need can see the full Payment Token (PCI DSS Requirement 3.3), and rendered unreadable wherever they are stored (PCI DSS Requirement 3.4) in the TDE.

The key-management requirements in this document are in addition to those in PCI DSS Requirements 3.5 3.6 .

PCI-DSS vs. TSP

88


PCI DSS Requirements Additional Applicability for TSPs 4. Encrypt transmission of cardholder data across open, public networks.

Wireless environments are not permitted to be connected to the TDE.

5. Protect all systems against malware and regularly update anti-virus software or programs.

PCI DSS Requirement 5 applies to all system components in the TDE.

6. Develop and maintain secure systems and applications. PCI DSS Requirement 6 applies to all system components in the TDE.

All changes made to system components in the TDE must be in accordance with PCI DSS Requirement 6.4.5.

7. Restrict access to cardholder data by business need to know. Access to Payment Token Data in the TDE must also be restricted according to principles of need-to-know and least privilege.

8. Identify and authenticate access to system components. Strong authentication controls are required for all accounts used to access Payment Tokens or to access systems in the TDE.

9. Restrict physical access to cardholder data. Physical security controls also apply to secure access to Payment Token Data in the TDE.

10. Track and monitor all access to network resources and cardholder data.

Audit log requirements include all individual user access to Payment Token Data in the TDE (PCI DSS Requirement 10.2.1).

11. Regularly test security systems and processes.. Internal vulnerability scans, penetration tests (for example, to verify segmentation controls), intrusion detection, and change detection apply to the TDE.

12. Maintain a policy that addresses information security for all personnel.

PCI DSS Requirement 12 also applies to personnel with access to the TDE.

PCI-DSS vs. TSP

89

PCI Security Standards on Big Data Platform (1)

Economy & Finance

Transcript of PCI Security Standards on Big Data Platform (1)