Some of you may have just read the blog title and believe I made a typo on the year, but no, I am here to talk about PCI DSS in 2018. I know it seems crazy to be discussing 2018, as we are all just getting settled into 2017, but at the realization that it is already April, and somehow January, February, and March flew by like I was in a warp tunnel, I feel it’s appropriate to start discussing 2018.
As some of you have already completed your first PCI DSS version 3.2 assessment, or are in the swing of it, you may have realized there are a whole bunch of requirements labeled as best practice until 2018 within PCI DSS 3.2. I am guessing the majority of you handled the requirements the same way I did with my clients, which was smile, check “Not Applicable”, write a quick statement, and move forward. Unfortunately, this will not be the case next year for all assessments, so it’s time to start preparing.
I am including below the requirements and dates to prepare for in 2018. Some of these requirements are dependent on whether your company is considered a Merchant or Service Provider. Also, some of you are luckier than others, as based on recertification date, you may have a lot longer to prepare for these requirements. Please be aware the best practice date is only applicable for those who have not completed their assessment prior to the date listed. If you start your assessment prior to the Best Practice date but finish after, you are responsible to comply.
Best Practices Until January 31, 2018:
3.5.1 (Additional requirement for service providers only)
10.8 (Additional requirement for service providers only)
10.8.1 (Additional requirement for service providers only)
22.214.171.124 (Additional requirement for service providers only)
12.4.1 (Additional requirement for service providers only)
12.11 (Additional requirement for service providers only)
12.11.1 (Additional requirement for service providers only)
- Details of all algorithms, protocols, and keys used for the protection of cardholder data, including key strength and expiry date
- Description of the key usage for each key
- Inventory of any HSMs and other SCDs used for key management
This requirement is only applicable to service providers and includes interview and documentation requirements. Service providers are responsible to detail all algorithms, protocols, keys, and security encryption devices for the protection of cardholder data. Though I feel some of the additional items were already included within the DSS, I can understand where emphasizing may have been desired. From experience, companies tend to generalize their encryption policies and procedures into one overall policy for the entirety of the company. The new requirements will enforce detailing the key information per use case for further environment clarity. To me a documented inventory of HSMs and other SCDs should have already been covered within requirement 2.4, so I can only assume these were being overlooked and the PCI SSC felt a need to single out the appliances.
The guidance for 6.4.6, which is for both service providers and merchants, discusses entities must ensure PCI DSS requirements are being properly applied to the environment when significant changes occur, and to enforce these changes within the change management process. Overall, they want to ensure when an entity’s environment significantly changes, diagrams and inventories are properly updated, configuration standards are applied, and all applicable PCI DSS requirements are included for the changes to the environment. For the most part, this requirement is really not new in what it is asking entities to do as other requirements already exist for keeping inventories and diagrams up-to-date and applying PCI DSS controls when standing up new systems or environments. By adding this requirement to the change management scope of the assessment, in my opinion the Council is attempting to ensure PCI DSS requirements are thought of during the change process, and not as an after-thought when the environment changes go live. Once again it appears that maybe this has been a gap in the past, and the PCI SSC felt a need to create a new requirement to ensure significant changes are not taking environments out of compliance.
Prior to the requirement, multi-factor authentication was only required for remote access originating from outside the entity’s network to the cardholder data environment, which included third-party access. There have been plenty of discussions in the past on what exactly was considered “remote access.” Some assessors viewed access from the corporate network to the segmented cardholder data environment as “remote access” as they could be different levels of security. However, the PCI SSC clarified their definition of “remote access” within a June 2016 FAQ to state that remote access is non-console access from a network that the entity does not control. In summary, if the entity controls the corporate network and the cardholder data environment network, you were not required to utilize multi-factor for access.
The new requirement within 8.3.1 adds an additional layer of security enforcing multi-factor for any administrative access to the cardholder data environment. What this means is that if you are on a segmented off network from the cardholder data environment, you must multi-factor into the environment to do administrative work regardless of who controls the source network. Multi-factor can be utilized at the network or host layer, and once inside the cardholder data environment, multi-factor does not have to be repeated as long as the session is maintained. I think further d defining at what boundary one considers to be the cardholder data environment can make a difference for the interpretation of the requirement. If you go back to the PCI DSS definition of the CDE as the network where cardholder data is stored, processed, transmitted, and machines that are logically connected on same network, and you for instance utilize a jump host segmented off, it could be interpreted that either you must define the jump host network as CDE or utilize multi-factor from jump host into the CDE. Implications can come in on calling the jump host network the CDE as now everything connected to the jump host network could be considered in scope.
It must be noted that the PCI SCC released new guidance for multi-factor authentication as of February 2017, and the guidance has provided some significant clarifications on what PCI SSC considers to be sound multi-factor authentication based on other standards including NIST. The guidance has already caused a lot of heartburn to many who are attempting to evaluate their multi-factor solution against the guidance. I suggest giving it a review, and subscribe to this blog in order to be notified further with posts on the topic.
Subscribe to the Schellman blog:
10.8 Additional requirement for service providers only
Implement a process for the timely detection and reporting of failures of critical security control systems, including but not limited to failure of:
- Physical access controls
- Logical access controls
- Audit logging mechanisms
- Segmentation controls (if used)
10.8.1 Additional requirement for service providers only
Respond to failures of any critical security controls in a timely manner. 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
10.8 and 10.8.1 once again are only applicable to service providers. There is a trend on the new requirements targeting service providers, and in context of security tools utilized to detect and protect the cardholder data environment. Over the assessments I have performed, I can say there often is a gap on implementing security controls, and then properly managing and following up on alerts. 10.8.1 is pretty significant and honestly could be considered overkill if it were required for every security control failure. What companies will need to do is narrow down into the word “critical” and define what they consider to be critical security control failures, and then implement the bulleted process for those failures.
126.96.36.199 Additional requirement for service providers only
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.
The only add to this requirement is that now instead of annually or after significant change, service providers are required to perform segmentation penetration testing at least every six months.
- Overall accountability for maintaining PCI DSS compliance
- Defining a charter for a PCI DSS compliance program and communication to executive management
12.4.1 is an administrative task for service providers, and overall speaks to ensuring that executive management are on board with PCI DSS compliance. This is with any information security program, you need to have senior executives and management on board and in the know to ensure that the program succeeds.
12.11 Additional requirement for service providers only
Perform reviews at least quarterly to confirm personnel are following security policies and operational procedures. Reviews must cover the following processes:
- Daily log reviews
- Firewall rule-set reviews
- Applying configuration standards to new systems
- Responding to security alerts
- Change management processes
- Documenting results of the reviews
- Review and sign-off of results by personnel assigned responsibility for the PCI DSS compliance program
Requirements 12.11 and 12.11.1 are only applicable to service providers, and to add operational oversight for PCI DSS security controls for the cardholder data environment. I can understand a need to add further oversight and perform quarterly checks on the security applications protecting the cardholder data environment, as these controls often fall to the wayside over the assessment year. There is definitely a consistency with annual assessments and finding controls fell out of place over the prior year, only to be put back into place to pass the assessment for the current year. Quarterly checks will better ensure that if controls do slip, it does not take a full year to remediate the problem.
The following is not a considered best practice per say, but is marked as the drop dead date for the use of SSL 3.0 or early TLS. There was an exception given for POS POI terminals within.
June 30, 2018:
- After June 30, 2018, all entities must have stopped use of SSL/early TLS as a security control, and use only secure versions of the protocol (an allowance for certain POS POI terminals is described in the last bullet below).
- POS POI terminals (and the SSL/TLS termination points to which they connect) that can be verified as not being susceptible to any known exploits for SSL and early TLS, may continue using these as a security control after June 30, 2018.
For further guidance on these requirements please reference the PCI SSC site document titled “PCI DSS” with the date of publication “V3.2 Apr 2016”.
About the AuthorMore Content by Kate Donofrio