PCI DSS v3.2 REQUIREMENTS ACTIVATED FROM 2018
Payment Card Industry Data Security Standard (PCIDSS) Overview
The Payment Card Industry Data Security Standard (PCI DSS) was developed to encourage and enhance cardholder data security and facilitate the broad adoption of consistent data security measures globally. PCI DSS provides a baseline of technical and operational requirements designed to protect account data. PCI DSS applies to all entities involved in payment card processing—including merchants, processors, acquirers, issuers, and service providers. PCI DSS also applies to all other entities that store, process or transmit cardholder data (CHD) and/or sensitive authentication data (SAD). Below is a high-level overview of the 12 PCI DSS requirements.
PCI Data Security Standard – High Level Overview
| Goals | PCID SS 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 |
PCIDSS v3.2 Requirements activated from 2018
Below are the requirements that have become mandatory from 2018.
| Requirements activated from January 31, 2018 | Requirement
Number |
Breakdown |
| Service providers must provide a documented description of the cryptographic architecture that includes:
a) Details of all algorithms, protocols, and keys used for the protection of cardholder data, including key strength and expiry date b) Description of the key usage for each key. c) Inventory of any HSMs and other SCDs used for key management.
|
Req. 3 (3.5.1) | Maintaining current documentation of the cryptographic architecture for all applications and systems in scope (where cardholder data are encrypted) to enable the entity to understand the algorithms, protocols, and cryptographic keys used to protect cardholder data, as well as the devices that generate, use and protect the keys. This allows an entity to keep pace with evolving threats to their architecture, enabling them to plan for updates as the assurance levels provided by different algorithms/key strengths changes. Maintaining such documentation also allows an entity to detect lost or missing keys or key-management devices, and identify unauthorized additions to their cryptographic architecture |
| Upon completion of a significant change, all relevant PCI DSS requirements must be implemented on all new or changed systems and networks, and documentation updated as applicable.
|
Req. 6 (6.4.6) | Change management process should include supporting evidence that PCI DSS requirements are implemented or preserved through the iterative process. Examples of PCI DSS requirements that could be impacted include, but are not limited to:
· Network diagram is updated to reflect changes. · Systems are configured per configuration standards, with all default passwords changed and unnecessary services disabled. · Systems are protected with required controls—e.g., file-integrity monitoring (FIM), anti-virus, patches, audit logging. · Sensitive authentication data (SAD) is not stored and all cardholder data (CHD) storage is documented and incorporated into data-retention policy and procedures · New systems are included in the quarterly vulnerability scanning process. |
| Multi-factor Authentication for Administrative Access;
Incorporate Multi-Factor Authentication(MFA) for all non – console access into the CDE for personnel with administrative access. |
Req. 8 (8.3.1) | This requirement applies only to personnel with administrative access and only for non-console access to the CDE; it does not apply to application or system accounts performing automated functions.
If the CDE is segmented from the rest of the entity’s network, an administrator would need to use multi-factor authentication when connecting to a CDE system from a non-CDE network. You can implement the MFA at network level or at system/application level; it does not have to be both. If the administrator uses MFA when logging into the CDE network, they do not also need to use MFA to log into a particular system or application within the CDE. |
| Multi-factor Authentication for Remote Access;
a) Provide details on what Multi-factor authentication method used for any remote access (originating from outside organizations network) to organisation environment (network) by employees, administrators, and third parties. b) Provide list of employees, administrators, and third parties having granted remote access (originating from outside of the organizations network) to organizations cardholder data environment (network) and what level of access given to users. c) Provide the screenshot of remote access technology (e.g. VPN) configured user list and their access level for above point. d) Provide the screenshot of Multi-factor authentication method used for non-console access CDE zone |
Req. 8 (8.3.2) | Details of multifactor authentication method used for any remote access and list of personnel that have personnel remote access should be documented
Maintain an evidence of remote access technology configured and that of the multi – factor authentication method used for non – console access to CDE zone. |
| Service providers should implement a process for the timely detection and reporting of failures of critical security control systems, including but not limited to failure of:
· Firewalls · IDS/IPS · FIM · Anti-virus · Physical access controls · Logical access controls · Audit logging mechanisms · Segmentation controls (if used)
Processes for responding to failures in security controls must include: · Restoring security functions · Identifying and documenting the duration (date and time start to end) of the security failure · Identifying and documenting cause(s) of failure, including root cause, and documenting remediation required to address root cause · Identifying and addressing any security issues that arose during the failure · Performing a risk assessment to determine whether further actions are required as a result of the security failure · Implementing controls to prevent cause of failure from reoccurring. · Resuming monitoring of security controls
|
Req. 10 (10.8) | Without formal processes to detect and alert when critical security controls fail, failures may go undetected for extended periods and provide attackers ample time to compromise systems and steal sensitive data from the cardholder data environment.
Maintain a documented evidence (e.g., records within a problem management system) should support that processes and procedures are in place to respond to security failures. In addition, personnel should be aware of their responsibilities in the event of a failure. Actions and responses to the failure should be captured in the documented evidence |
| If segmentation is used, confirm PCI DSS scope by performing penetration testing on segmentation controls at least every six months and after any changes to segmentation controls/methods. | Req. 11 (11.3.4.1) | For service providers with CDE segmentation are to perform penetration test Bi-annually (every six month) to ensure PCI DSS scope remains up to date and aligned with changing business objectives. |
| Executive management shall establish responsibility for the protection of cardholder data and a PCI DSS compliance program to include:
a) Overall accountability for maintaining PCI DSS compliance b) Defining a charter for a PCI DSS compliance program and communication to executive management. |
Req 12 (12.4.1) | Executive management assignment of PCI DSS compliance responsibilities ensures executive-level visibility into the PCI DSS compliance program and allows for the opportunity to ask appropriate questions to determine the effectiveness of the program and influence strategic priorities. Overall responsibility for the PCI DSS compliance program may be assigned to individual roles and/or to business units within the organization |
| Perform and maintain a documented review at least quarterly to confirm personnel are following security policies and operational procedures. Reviews must cover the following processes:
a) Daily log reviews b) Firewall rule-set reviews c) Applying configuration standards to new systems d) Responding to security alerts e) Change management processes |
Req 12 (12.11) | Service providers are to regularly confirming that security policies and procedures are being followed to provide assurance that the expected controls are active and working as intended. The objective of these reviews is not to re-perform other PCI DSS requirements, but to confirm whether procedures are being followed as expected. |
PCI DSS v3.2 Requirements for Entities using SSL/early TLS (PCIDSS Appendix A2)=
* After June 30, 2018: all entities must have stopped the use of SSL/early TLS as a security control, and use only secure versions of the protocol i.e. TLS 1.1 and above – TLS 1.2 is strongly advised.
PCIDSS Mandatory Exercise for PCIDSS Certified Entities.
The following are to be performed by entities that are already PCI DSS certified, in order to be recertified.
- Bi-Annual Firewall and router rule set review – Requirement 1.1.7
- Quarterly Cardholder discovery scan report covering the Bank’s infrastructure assets – Requirement 3.1
- Daily Antivirus Update – Requirement 5.2
- Regular system Patch deployment – Requirement 6.2
- Quarterly Rogue Wireless Access Point reviews (Head Office, Contact Center, branches) – Requirement 11.1
- Quarterly Internal vulnerability scan and rescan after closure of vulnerabilities (To be performed by an external entity or an internal team. The internal team performing scans must have organizational independence and background of performing this activity) – Requirement 11.2.1
- Quarterly External ASV scan and rescan after closure of vulnerabilities (To be performed by an ASV company) – Requirement 11.2.2
- Annual External Network Penetration Testing and retest after closure of vulnerabilities – Requirement 11.3.1
- Annual Internal Network and Application Penetration Testing and retest after closure of vulnerabilities (At least every Six Months for entities with CDE Network Segmentation) – Requirement 11.3.2
Reference: PCI DSS Requirements and Security Assessment Procedures Version 3.2
Enquires: info@digitalencode.net
Leave a Reply