Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin
PCI Security Standards on Big Data Platform (1)
2016/11/20
1
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin
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
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin
Be a Product Manager of Fin-Tech YOU have to know
PCI Security Standards
3
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin
Product innovation in FinTech
4
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin
We all have a responsibility to protect and safeguard our customers accounts
5
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin
PCI Security Standards
6
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin
Payment Card Industry
Prepaid Card
Debit&Credit Card
E-Wallet
ATM
POS
7
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin
Financial institutions Association Merchant POS Processor Others
Participating Organizations
Founding Members
8
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin
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)
PCI Security Standards
5. PCI Card Production Logical Security Requirements and Physical Security Requirements
6. PCI Token Service Provider (TSP) Security Requirements
9
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin 10
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin
PTSPIN Transaction Standard
7 Control Objects includes 33 PIN Security Requirements
11
Object 1: Manufacturers
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin 12
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin
Insert a debit card into the ATM
13
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin
Enter the PIN when prompted
14
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin
Withdraw money from ATM
15
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin
Login to online banking
16
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin
PIN17
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin
PINs used in transactions governed by these requirements are processed using equipment and methodologies that ensure they are kept secure.
1
PIN
18
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin
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
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin
Keys are conveyed or transmitted in a secure manner.320
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin
Key-loading to HSMs and PIN entry devices is handled in a secure manner. 4
21
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin
Keys are used in a manner that prevents or detects their unauthorized usage.5
22
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin
Keys are administered in a secure manner.623
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin
Equipment used to process PINs and keys is managed in a secure manner.7
24
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin
Payment Application Data Security Standard
25
Object 2: Software Developments
12 PA-DSS Requirements
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin 26
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin
Payment Application
27
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin
Hacked into your server
28
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin
And THEN..
29
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin
Payment Application
30
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin
Do not retain full track data, card verification code or value (CAV2, CID, CVC2, CVV2), or PIN block data.1
Volatile
31
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin
Protect stored cardholder data.232
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin
Provide secure authentication features.333
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin
Log payment application activity.434
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin
Develop secure payment applications.535
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin
Protect wireless transmissions.636
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin
Test payment applications to address vulnerabilities and maintain payment application updates.7
37
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin
Facilitate secure network implementation.838
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin
Cardholder data must never be stored on a server connected to the Internet.9
39
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin
Facilitate secure remote access to payment application.1040
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin
Encrypt sensitive traffic over public networks.1141
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin
Secure all non-console administrative access.1242
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin
Maintain a PA-DSS Implementation Guide for customers, resellers, and integrators13
43
Customers
Resellers
Integrators
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin
Assign PA-DSS responsibilities for personnel, and maintain training programs for personnel, customers, resellers, and integrators.14
44
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin
Payment Card Industry Data Security Standard
45
Object 3: Merchants & Service Providers
6 Goals 12 PCI-DSS Requirements
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin 46
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin
Types of Data on a Payment Card
47
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin
The security of cardholder data affects everybody
48
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin
Cardholder Data
49
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin
Install and maintain a firewall configuration to protect cardholder data.1Goal (1) : Build and Maintain a Secure Network and Systems
50
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin
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
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin
Protect Stored Cardholder Data.3Goal (2) : Protect Cardholder Data
52
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin
Encrypt transmission of cardholder data across open, public networks.4Goal (2) : Protect Cardholder Data
53
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin
Protect all systems against malware and regularly update anti-virus software or programs.5
Goal (3) : Maintain a Vulnerability Management Program
54
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin
Develop and maintain secure systems and applications.6Goal (3) : Maintain a Vulnerability Management Program
55
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin
Restrict access to cardholder data by business need to know.7Goal (4) : Implement Strong Access Control Measures
56
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin
Identify and authenticate access to system components.8Goal (4) : Implement Strong Access Control Measures
57
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin
Restrict physical access to cardholder data.9Goal (4) : Implement Strong Access Control Measures
58
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin
Track and monitor all access to network resources and cardholder data.10Goal (5) : Regularly Monitor and Test Networks
59
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin
Regularly test security systems and processes.11Goal (5) : Regularly Monitor and Test Networks
60
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin
Maintain a policy that addresses information security for all personnel. 12Goal (6) : Maintain an Information Security Policy
61
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin
TSPPayment Card Industry Token Service Provider Security
62
Object 4: Token Service Provider
8 TSP Requirements
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin
Mobile payment and digital wallet service
63
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin 64
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin
source:visa
65
https://usa.visa.com/dam/VCOM/Media%20Kits/PDF/visa-security-tokenization-infographic.pdf
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin source:visa
Tokenization
66
https://usa.visa.com/dam/VCOM/Media%20Kits/PDF/visa-security-tokenization-infographic.pdf
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin source:visa
Merchant can vastly reduce or even eliminate the cardholder data environment (CDE) that is in scope for PCI audits.
67
https://usa.visa.com/dam/VCOM/Media%20Kits/PDF/visa-security-tokenization-infographic.pdf
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin
Token Data68
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin
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
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin
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)
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin
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
https://usa.visa.com/dam/VCOM/Media%20Kits/PDF/visa-security-tokenization-infographic.pdf
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin
THANK YOU FOR YOUR ATTENTION
72
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin 73
Appendix APIN Security Requirements
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin
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
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin
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.
PIN Security Requirements
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
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin
PTS Control Objective 3:
Keys are conveyed or transmitted in a secure manner.
PIN Security Requirements
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
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin
PTS Control Objective 4:
Key-loading to HSMs and PIN entry devices is handled in a secure manner.
PIN Security Requirements
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
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin
PTS Control Objective 5:
Keys are used in a manner that prevents or detects their unauthorized usage.
PIN Security Requirements
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
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin
PTS Control Objective 6:
Keys are administered in a secure manner.
PIN Security Requirements
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
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin
PTS Control Objective 6:
Keys are administered in a secure manner.
PIN Security Requirements
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
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin
PTS Control Objective 7:
Equipment used to process PINs and keys is managed in a secure manner.
PIN Security Requirements
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
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin 82
Appendix BPA-DSS Requirements
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin
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
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin
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
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin 85
Appendix CPCI-DSS Requirements
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin
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
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin 87
Appendix DTSP Requirements
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin
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
Copyright 2016 Cheng-Hsun Lin All Rights Reserved Chris Lin
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
Top Related