Document Comparison
PCI_Card_Production_Logical_Security_Requirements_2013.pdf
→
PCI_Card_Production_Logical_Security_Requirements_v1-1_March_2015.pdf
91% similar
44 → 47
Pages
14519 → 15621
Words
85
Content Changes
Content Changes
85 content changes. 42 administrative changes (dates, page numbers) hidden.
Added
p. 3
March 2015 1.1 PCI Enhancements for clarification
Added
p. 14
a) Test (non-production) keys and test (non-production) data cannot be used with production equipment.
b) Cards used for final system validation or user acceptance that use production keys and/or data may be produced using production equipment.
b) Cards used for final system validation or user acceptance that use production keys and/or data may be produced using production equipment.
Added
p. 15
a) The card production network must be segregated from other parts of an organization's network.
b) Effective 1 January 2016, the DMZ must be located in the Server Room of the HSA.
c) DMZ infrastructure equipment located within the HSA Server Room must be in a dedicated rack with access restricted to the minimum number of authorized individuals.
d) All switches and cabling associated with the DMZ equipment must be stored within the same rack with only the minimum required number of cable connections entering/exiting the rack in order to provide connectivity to firewalls.
b) Effective 1 January 2016, the DMZ must be located in the Server Room of the HSA.
c) DMZ infrastructure equipment located within the HSA Server Room must be in a dedicated rack with access restricted to the minimum number of authorized individuals.
d) All switches and cabling associated with the DMZ equipment must be stored within the same rack with only the minimum required number of cable connections entering/exiting the rack in order to provide connectivity to firewalls.
Added
p. 18
b) Deploy an external firewall outside the HSA to protect the HSA’s DMZ (see figures 2 and 3 above for acceptable configurations).
d) Check for anti-virus updates at least daily, and install updates whenever updates are available.
f) When a vendor does not use a wireless network, the vendor must still use a scanning device that is capable of detecting rogue and hidden wireless networks. Random scans of the HSA must be conducted at least monthly.
d) Check for anti-virus updates at least daily, and install updates whenever updates are available.
f) When a vendor does not use a wireless network, the vendor must still use a scanning device that is capable of detecting rogue and hidden wireless networks. Random scans of the HSA must be conducted at least monthly.
Added
p. 22
b) A log of media access-control addresses and associated devices (including make, model, owner, and reason for access) must be maintained, and a check of authorized media access control addresses on the access point (AP) must be conducted at least quarterly.
Added
p. 28
c) Locked accounts must only be unlocked by the security administrator. Alternatively, user accounts may be unlocked via automated password reset mechanisms. Challenge questions with answers that only the individual user would know must be used. These questions must be designed such that the answers are not information that is available elsewhere in the organization, such as in the Human Resources Department.
a) A written description of the vendor’s cryptographic architecture must exist. In particular it must detail all the keys used by each HSM. The key description must describe the key usage.
c) Effective implementation of these principles must enforce the existence of barriers beyond procedural controls to prevent any one individual from gaining access to key components or shares sufficient to form the actual key.
a) As plaintext inside the protected memory of a secure cryptographic device
a) A written description of the vendor’s cryptographic architecture must exist. In particular it must detail all the keys used by each HSM. The key description must describe the key usage.
c) Effective implementation of these principles must enforce the existence of barriers beyond procedural controls to prevent any one individual from gaining access to key components or shares sufficient to form the actual key.
a) As plaintext inside the protected memory of a secure cryptographic device
Added
p. 32
h) Key components or shares must be placed in pre-serialized, tamper-evident envelopes when not in use by the authorized key custodian.
i. Private keys shall be used only to create digital signatures OR to perform decryption operations. Private keys shall never be used to encrypt other keys.
iv. Key-encrypting keys must never be used as working keys (session keys) and vice versa.
viii. Maintain an inventory of keys under its management to determine when a key is no longer required•e.g., could include key label/name, effective date, expiration date, key purpose/type, key length, etc.
g) All derivation keys must be unique per issuer.
b) When a cryptographic device (e.g., HSM) is decommissioned, any data stored and any resident cryptographic keys must be deleted or otherwise destroyed.
d) All key destruction must be logged and the log retained for verification.
i. Private keys shall be used only to create digital signatures OR to perform decryption operations. Private keys shall never be used to encrypt other keys.
iv. Key-encrypting keys must never be used as working keys (session keys) and vice versa.
viii. Maintain an inventory of keys under its management to determine when a key is no longer required•e.g., could include key label/name, effective date, expiration date, key purpose/type, key length, etc.
g) All derivation keys must be unique per issuer.
b) When a cryptographic device (e.g., HSM) is decommissioned, any data stored and any resident cryptographic keys must be deleted or otherwise destroyed.
d) All key destruction must be logged and the log retained for verification.
Added
p. 42
Application Keys Keys used by the issuer application. Application keys include the MDK and keys that may be derived from the MDK to be loaded into the chips during personalization.
Hardware (host) security module An HSM is a type of SCD, a physically and logically protected hardware device that provides a secure set of cryptographic services. It includes the set of hardware, firmware, software, or some combination thereof that implements cryptographic logic, cryptographic processes, or both, including cryptographic algorithms.
Key-management device A device used anywhere in the key life cycle for the management of keys. It may or may not be an SCD. Where required in the document, it must be an SCD. Examples include devices used for key loading or key generation.
Local Master Key (LMK) See Master File Key.
Master File Key (MFK) This is a symmetric key used to encrypt other cryptographic keys that are to be stored outside of the …
Hardware (host) security module An HSM is a type of SCD, a physically and logically protected hardware device that provides a secure set of cryptographic services. It includes the set of hardware, firmware, software, or some combination thereof that implements cryptographic logic, cryptographic processes, or both, including cryptographic algorithms.
Key-management device A device used anywhere in the key life cycle for the management of keys. It may or may not be an SCD. Where required in the document, it must be an SCD. Examples include devices used for key loading or key generation.
Local Master Key (LMK) See Master File Key.
Master File Key (MFK) This is a symmetric key used to encrypt other cryptographic keys that are to be stored outside of the …
Added
p. 46
Working Key A key used to cryptographically process the transaction. A working key is sometimes referred to as a data key, communications key, session key, or transaction key.
Modified
p. 1
Payment Card Industry (PCI) Card Production Logical Security Requirements Version 1.0
Payment Card Industry (PCI) Card Production Logical Security Requirements Version 1.1
Modified
p. 12
e) The vendor must log and inform the card brands of all Issuers sending the vendor cardholder data in clear text.
e) The vendor must log and inform the card brands of all issuers sending the vendor cardholder data in clear text.
Modified
p. 14
c) Ensure that when personalization signals are encrypted, they comply with the encryption standards defined in Normative Annex A.
c) Ensure that when personalization signals are encrypted, they comply with the encryption standards defined in Normative Annex A. If the signals are encrypted, 4.7 a, b, and d herein do not apply.
Modified
p. 16 → 17
e) Put controls in place to restrict, prevent, and detect unauthorized access to this network.
e) Put controls in place to restrict, prevent, and detect unauthorized access to this network. Access from within the high security area to anything other than the personalization network must be “read-only.”
Modified
p. 16 → 17
g) Have controls in place to restrict “write” permission to any system external to the personalization network to only pre-approved functions that have been authorized by the VPA. These write functions must not transmit cardholder data.
g) Have controls in place to restrict “write” permission to any system external to the personalization network to only pre-approved functions that have been authorized by the VPA, except for systems in the dedicated DMZ. These write functions must not transmit cardholder data if this involves direct write from the system containing the information.
Removed
p. 17
b) Deploy a firewall between the Internet and Internet-facing network.
c) Deploy a firewall between the Internet facing network and personalization network.
c) Deploy a firewall between the Internet facing network and personalization network.
Modified
p. 17 → 18
c) Install a firewall between the data-preparation network and the personalization network unless both are located within the same high security area or network.
Modified
p. 17 → 18
d) Utilize physically separate firewalls for the aforementioned.
Modified
p. 17 → 18
e) Implement appropriate operating-system controls on firewalls.
Modified
p. 17 → 18
f) Review firewall rule sets and validate supporting business justification at least monthly.
Modified
p. 17 → 18
g) Restrict physical access to firewalls to only those designated personnel who are authorized to perform firewall administration activities.
Modified
p. 17 → 18
h) Ensure the firewall rule set is such that any server only requiring inbound connections (for example, web servers) is prohibited from making outbound connections.
Modified
p. 17 → 18
i) Ensure that only authorized individuals can perform firewall administration.
Modified
p. 17 → 18
j) Run firewalls on dedicated hardware. All non-firewall-related software such as compilers, editors, and communication software must be deleted or disabled.
Modified
p. 18 → 19
k) Implement daily, automated analysis reports to monitor firewall activity.
Modified
p. 18 → 19
l) Use unique administrator passwords for firewalls used by the personalization system and those passwords used for other network devices in the facility.
Modified
p. 18 → 19
m) Implement mechanisms to protect firewall system logs from tampering, and procedures to check the system integrity monthly.
Modified
p. 20 → 21
d) Use a scanning device that detects hidden networks, as well as wireless intrusion detection systems (WIDS) •fixed and/or mobile
•that will detect hidden and spoofed networks.
•that will detect
d) Use a wireless intrusion detection system (WIDS) capable of detecting hidden and spoofed networks for all authorized wireless networks.
Modified
p. 20 → 21
e) Use a WIDS to conduct random monthly wireless scans within the HSA to detect rogue and hidden wireless networks.
e) When a vendor uses a wireless network, the WIDS must be used to conduct random scans within the HSA at least monthly to detect rogue and hidden wireless networks.
Removed
p. 21
b) A log of message authentication codes (MACs) and associated devices (including make, model, owner, and reason for access) must be maintained, and a check of authorized MACs on the access point (AP) must be conducted at least quarterly.
Modified
p. 21 → 22
c) A MAC-based access control list (ACL) must be used for access control of clients.
c) A media access control address-based access-control list (ACL) must be used for access control of clients.
Modified
p. 21 → 23
a) Perform quarterly external vulnerability scans using an Approved Scanning Vendor (ASV) approved by the Payment Card Industry Security Standards Council (PCI SSC).
a) Perform quarterly external network vulnerability scans using an Approved Scanning Vendor (ASV) approved by the Payment Card Industry Security Standards Council (PCI SSC).
Modified
p. 21 → 23
b) Perform internal and external vulnerability scans after any significant change. Scans after changes may be performed by internal staff.
b) Perform internal and external network vulnerability scans at least quarterly and after any significant change in the network (such as new system-component installations, changes in network topology, firewall-rule modifications, product upgrades). Scans after changes may be performed by internal staff.
Modified
p. 21 → 23
c) Ensure all findings from vulnerability scans are prioritized and tracked. Corrective action for high-priority vulnerabilities must be started within two working days.
c) Ensure all findings from network vulnerability scans are prioritized and tracked. Corrective action for high-priority vulnerabilities must be started within two working days.
Modified
p. 23 → 24
i) Ensure that the badge access control system complies with the system security requirements in this document.
i) Ensure that the badge access-control system complies with the system security requirements in this document.
Modified
p. 24 → 25
j) Implement critical patches within two business days. When this is not possible the CISO, security manager, and IT director must clearly record that they understand that a critical patch is required and authorize its implementation within a maximum of seven business days.
j) Implement critical patches to all Internet-facing system components within seven business days of release. When this is not possible the CISO, security manager, and IT director must clearly record that they understand that a critical patch is required and authorize its implementation within a maximum of 30 business days.
Modified
p. 24 → 25
b) Review all access control and change logs•for example, logs from firewalls, routers, wireless access points, and authentication servers•to check for any unauthorized activity at least weekly.
b) Review all access-control and change logs
•for example, logs from firewalls, routers, wireless access points, and authentication servers
•to check for any unauthorized activity at least weekly.
•for example, logs from firewalls, routers, wireless access points, and authentication servers
•to check for any unauthorized activity at least weekly.
Modified
p. 25 → 26
a) Ensure access to software source code is restricted to authorized personnel only.
a) Ensure access to source code for applications used on the personalization network is restricted to authorized personnel only.
Modified
p. 25 → 26
b) Ensure personalization software logs any restart (and details associated with that restart event).
b) Ensure that in-house developed personalization software logs any restart (and details associated with that restart event).
Modified
p. 25 → 26
c) Ensure that the personalization software enforces authorization at restart.
c) Ensure that in-house developed personalization software enforces authorization at restart.
Modified
p. 27 → 28
h) Passwords must have a maximum life of 90 days and a minimum life of one day.
h) Passwords must have a maximum life not to exceed 90 days and a minimum life of at least one day.
Removed
p. 28
b) Effective implementation of these principles must enforce the existence of barriers beyond procedural controls to prevent any one individual from gaining access to key components or shares sufficient to form the actual key.
Modified
p. 28 → 29
b) The principles of split knowledge and dual control must be included in all key life cycle activities involving key components to ensure protection of keys. The only exceptions to these principles involve those keys that are managed as cryptograms or stored within an SCD.
Modified
p. 28 → 29
d) Where clear key components or shares pass through a PC or other equipment, the equipment must never be connected to any network and must be powered down when not in use.
Modified
p. 28 → 29
e) Keys used for protection of keying material or other sensitive data must meet the minimums delineated in Appendix A.
Modified
p. 28 → 29
f) All key-encrypting keys used to transmit or convey other cryptographic keys must be at least as strong as the key being transmitted or conveyed.
Modified
p. 28 → 29
g) Cryptographic keys must not be hard-coded into software.
Modified
p. 28 → 29
h) Audit trails must be maintained for all key-management activities.
Modified
p. 28 → 29
i) Key-management activities must be performed by vendor or issuer staff.
Modified
p. 28 → 29
j) Key-management activities must only be performed by fully trained and authorized personnel.
Modified
p. 28 → 29
k) All key-management activities must be documented, and all activities involving clear key components must be logged. The log must include:
Modified
p. 28 → 29
c) As two or more full-length components (where each component must be the same length as the final key) or as part of an “m of n” sharing scheme where the value of “m” is at least 2.
Modified
p. 28 → 29
i. The components or shares must be managed using the principles of dual control and split knowledge.
Modified
p. 28 → 29
ii. No single person shall be able to access or use all components or a quorum of shares of a single secret or private cryptographic key.
Modified
p. 29 → 30
iv. With a MAC (message authentication code) created using the algorithm defined in ISO 9807.
iv. With a MAC (message authentication code) created using the algorithm defined in ISO 16609.
Modified
p. 30 → 31
iii. Key custodians who form the necessary threshold to create a key must not report directly to the same manager.
iii. Key custodians who form the necessary threshold to create a key must not report directly to the same manager. If the Key Manager is also a key custodian, other key custodians must not report to the Key Manager if, in conjunction with the Key Manager, that would form a threshold to create a key.
Modified
p. 30 → 31
a) The roles and responsibilities of key custodians must be fully documented.
a) The roles and responsibilities of key custodians must be fully documented at a level sufficient to allow performance of required activities on a step-by-step basis.
Modified
p. 31 → 32
During operation, the HSM must utilize a security algorithm that complies with payment system requirements.
During operation, the HSM must utilize a security algorithm that complies with payment system requirements as defined in Appendix A.
Modified
p. 31 → 32
e) Key components, if printed, must be created in such a way that the key component cannot be observed during the process. Additionally, the key components cannot be observed on final documents without evidence of tampering.
e) Key components, if printed, must be created in such a way that the key component cannot be observed during the process by other than the authorized key custodian. Additionally, the key components cannot be observed on final documents without evidence of tampering.
Modified
p. 31 → 32
a) Adhere to the RSA algorithm and ensure that the length of RSA key pairs is in accordance with payment system requirements.
a) Adhere to the RSA algorithm and ensure that the length of issuer RSA key pairs used for payment-transaction processing is in accordance with payment-system requirements.
Removed
p. 33
i. Key-encrypting keys must never be used as working keys (session keys) and vice versa.
Modified
p. 33 → 34
b) Key storage containers must not be removable without detection.
b) These envelopes must not be removable without detection.
Modified
p. 33 → 34
d) Where a secret or private key component/share is stored on a token (e.g., an integrated circuit card) and a personal identification number (PIN) or similar mechanism is used to access that token, only that token’s owner (or designated backup) must be allowed possession of both the token and its corresponding PIN.
d) Where a secret or private key component/share is stored on a token (e.g., an integrated circuit card) and an access code (e.g., a personal identification number (PIN)) or similar access-control mechanism is used to access that token, only that token’s owner (or designated backup) must be allowed possession of both the token and its corresponding access code.
Modified
p. 33 → 34
ii. Names of key custodians involved
ii. Names and signatures of the key custodians involved
Modified
p. 33 → 34
iv. Serial number of envelope
iv. Serial number of envelope (in/out)
Modified
p. 33 → 34
iii. Private keys shall be used only to create digital signatures and to perform decryption operations. Private keys shall never be used to encrypt other keys.
iii. Public keys shall be used only to verify digital signature OR perform encryption operations.
Modified
p. 33 → 35
d) No key must be used for a period longer than the designated life span of that key.
d) No key must be used for a period longer than the designated life span of that key. Issuer keys must not be used for longer than the issuer-specified expiry date.
Removed
p. 34
b) When a device is decommissioned, delete or otherwise destroy the keys and data storage.
c) Whenever an HSM is removed from service, all keys resident within that device must be destroyed.
c) Whenever an HSM is removed from service, all keys resident within that device must be destroyed.
Modified
p. 34 → 35
iii. Ensure that any keys used for prototyping are not used in production.
iii. Ensure that any keys used for prototyping (i.e., using cards for proof of concept or process where production keys are not used) are not used in production.
Modified
p. 34 → 35
h) IC keys must be unique per IC.
Modified
p. 34 → 36
a) Immediately destroy keys and key components/shares that are no longer required after successful loading and validation as operational.
a) Immediately destroy key components/shares that are no longer required after successful loading and validation as operational.
Modified
p. 34 → 36
c) Securely destroy all copies of keys that are no longer required for card production.
Modified
p. 35 → 36
g) Destroy all hard-copy keys or key components/shares maintained on paper by cross- shredding, pulping, or burning. Strip shredding is not sufficient.
g) Destroy all hard-copy key components/shares maintained on paper by cross-shredding, pulping, or burning. Strip shredding is not sufficient.
Modified
p. 35 → 36
i) Destroy all keys under dual control with appropriate key-destruction affidavits signed by the applicable key custodian.
i) Destroy all key components under dual control with appropriate key-destruction affidavits signed by the applicable key custodian.
Modified
p. 35 → 37
i. Who is to be notified in the event of a key compromise. At a minimum, this must include the CISO, Key Manager, Security Manager, and the VPA
i. Who is to be notified in the event of a key compromise? At a minimum, this must include the CISO, Key Manager, Security Manager, and the VPA
Modified
p. 35 → 37
iii. An investigation into the cause of the compromise, including a documented analysis of how and why the event occurred and the damages suffered
iii. An investigation into the cause of the compromise, including a documented analysis of how and why the event occurred and the damages suffered.
Modified
p. 35 → 37
iv. The erasure or destruction of all compromised keys within a predefined time frame
iv. That the vendor will remove from operational use all compromised keys within a predefined time frame and provide a means of migrating to new key(s).
Modified
p. 37 → 39
k) No key must be used for a period longer than the designated life span of that key.
k) No key must be used for a period longer than the designated life span of that key. Issuer keys must not be used for longer than the issuer-specified expiry date.
Modified
p. 38 → 40
d) During transmission to and storage in the PIN distribution system, all PIN and authentication data must be encrypted using key algorithms and sizes as stated in Normative Annex A.
d) During transmission to and storage in the PIN distribution system, all PIN and authentication values must be encrypted using key algorithms and sizes as stated in Normative Annex A.
Modified
p. 38 → 40
g) The authentication mechanism or value must be different than the identification value and must not be a value easily associated with the cardholder.
g) The authentication value must be different than the identification value and must not be a value easily associated with the cardholder.
Modified
p. 38 → 40
l) The distribution system must have no way of associating an identification value or authentication value with a specific cardholder’s name, address, or account number.
l) The distribution system must not have any way of associating an identification value or authentication value with a specific cardholder’s name, address, or account number.
Modified
p. 38 → 40
o) The PIN distribution system must contain no other cardholder data (e.g., PAN, cardholder name).
o) The PIN distribution system must not contain any other cardholder data (e.g., PAN, cardholder name).
Modified
p. 40 → 42
Bureau A vendor performing card personalization and/or data preparation.
Authentication value The data that the PIN-distribution system uses to authenticate the cardholder Bureau A vendor performing card personalization and/or data preparation.
Modified
p. 41 → 43
Key-exchange key (KEK) A key used to encrypt and decrypt other keys during transport between entities in a key zone. Also known as key-encipherment or key-encryption key.
Key-exchange key (KEK) A key used to encrypt and decrypt other keys during transport between entities in a key zone or within a given entity. It may also be used for local storage of keys. Also known as key-encipherment or key-encryption key.
Modified
p. 41 → 44
Personalization The process of data preparation and applying the cardholder-specific data to the card, uniquely tying the card to a given cardholder and account. This includes encoding the magnetic stripe, embossing the card (if applicable), and loading data on to the chip.
Personalization The process of applying the account and, when required for the product, cardholder-specific data to the card, uniquely tying the card to a given account. This includes encoding the magnetic stripe, embossing the card (if applicable), and loading data on to the chip.
Modified
p. 41 → 44
Personalization file A file created by the issuer or issuer’s processor that has all of the necessary information to personalize a card.
d) Indent printing Personalization file A file created by the issuer or issuer’s processor that has all of the necessary information to personalize a card.