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
3
2

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
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

PIN
17

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
GEN
KEY
19

Keys are conveyed or transmitted in a secure manner.
3
20

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.
6
23

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 veriﬁcation code or value (CAV2, CID,
CVC2, CVV2), or PIN block data.1
Volatile
31

Protect stored cardholder data.
2
32

Provide secure authentication features.
3
33

Log payment application activity.
4
34

Develop secure payment applications.
5
35

Protect wireless transmissions.
6
36

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

Facilitate secure network implementation.
8
38

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

Facilitate secure remote access to payment application.
10
40

Encrypt sensitive trafﬁc over public networks.
11
41

Secure all non-console administrative access.
12
42

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 ﬁrewall conﬁguration to protect cardholder data.
1
Goal (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.
3
Goal (2) : Protect Cardholder Data
52

Encrypt transmission of cardholder data across open, public networks.
4
Goal (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.
6
Goal (3) : Maintain a Vulnerability Management Program
55

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

Identify and authenticate access to system components.
8
57

Restrict physical access to cardholder data.
9
58

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

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

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

TSP
Payment 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

Token Data
68

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
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 A
PIN 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.
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 ofﬂine using IC card technology must be protected in accordance with
the requirements in Book 2 of the EMV IC Card Speciﬁcations for Payment Systems and ISO 9654.
3. For online interchange transactions, PINs must be only encrypted using ISO 9564–1 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 keys—such as terminals, external PIN pads, key guns,
or similar devices and methods—must 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 identiﬁable 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

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

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 modiﬁcations or
tampering prior to the deployment of the device—both prior to and subsequent to the loading of
cryptographic keys—and 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 SCDs—and ensure the destruction of any
cryptographic keys or key material within such devices—when 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 B
PA-DSS Requirements

PA DSS Requirements
1. Do not retain full track data, card veriﬁcation 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 trafﬁc over public networks.
12. Secure all non-console administrative access.
13. Maintain a PA-DSS Implementation Guide for customers, resellers, and
integrators
14. 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 vendor’s 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 conﬁgure 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 process
7. Use vendor’s lab ONLY after verifying all requirements are met.
8. Maintain an effective quality assurance (QA) process.
84

Appendix C
PCI-DSS Requirements

Goals PCI DSS Requirements
Build and Maintain a Secure
Network and Systems
1. Install and maintain a ﬁrewall conﬁguration 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 D
TSP 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)

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (12)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie PCI Security Standards on Big Data Platform (1)

Ähnlich wie PCI Security Standards on Big Data Platform (1) (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

PCI Security Standards on Big Data Platform (1)