The old Payment Card Industry Data Security Standard (PCI DSS) v3.2.1 is still in effect. The new PCI 4.0 standards are not slated to be effective until the end of 2020, at the earliest. Again, the current PCI 4.0 draft isn’t final, and the 3.2.1 is still the standard to go to for compliance today and maybe for a long time. There will also be a period of time after the new standards are published when businesses will be given time to switch over to the latest version of the PCI DSS after its public release on the PCI Security Standard Council website.
However, the Payment Card Industry Security Standards Council (PCI SSC) has indicated several changes in the current draft are likely to stay. Here’s what you need to know.
RFC Feedback
Participating Organizations (POs), Qualified Security Assessors (QSAs) and Approved Scanning Vendors (ASVs) already got a sneak peek at the Version 4.0 changes during the RFC period late last year. The RFC not only included the first draft of PCI DSS v4.0 Draft v0.1, but also guidance documents for completing the RFC. These included a summary of changes to the document listed section by section and a guidance for stakeholders document that explained how to complete the RFC.
The next version of the PCI DSS will also take into account feedback received during the 2017 RFC period. Stakeholders from that period wanted the Payment Card Industry Security Standards Council PCI SSC to go over four specific areas of concern. The first area of concern was authentication in light of what the National Institute of Standards and Technology multi-factor authentication and password guidance is. The next was that a stronger requirement that cardholder data be encrypted even on trusted networks be implemented. The third was that there should be increased or new requirements for monitoring networks and other activities in light of technological advancements. The last was decreased intervals for testing critical controls. An example is that the reviewers want PCI DSS to include requirements from the Designated Entities Supplemental Validation (PCI DSS Appendix A3) in the main set of standards that apply to all entities seeking compliance.
Assess your PCI compliance
Appendix A3 Requirements
Appendix A3 applies to companies that were determined to require additional monitoring and controls under 3.2.1. Some examples of these companies included those who had experienced large or many security breaches, those who collected and held onto data, and those who store, process or transmit large amounts of data. Increased security controls in this section of the PCI DSS v3.2.1 were designed to make sure security was being maintained continuously on a business-as-usual basis. There were more requirements for validation and more devices and software to consider in the scoping of the Cardholder Data Environment (CDE). Businesses were only required to undergo the additional assessments in Appendix A3 if they were told to do so by a Payment Brand or an Acquirer, like a Merchant’s Bank.
Documentation for A3 Businesses
Some of the requirements listed in Appendix A3 that might be applicable to everyone in the new version of the PCI DSS include the activation of a formalized chain of responsibility and compliance program. This program is to be reviewed by executive management and the board of directors at least annually. Reports should include what has been done to achieve compliance and any issues encountered throughout the year including what was done to remediate these issues. This requires that the monitoring of the compliance program include the business as usual activities as well as other activities required to maintain overall compliance with the PCI DSS.
Download Our PCI DSS Checklist
The required formalized compliance program includes annual reporting and continuous validation of the PCI DSS requirements as indicated for each requirement, for example, some requirements might need to be validated even daily or weekly. It must also include a method for executing a business-impact analysis to determine what PCI DSS aspects should be considered in the development of future business strategies to make sure that ongoing compliance is achieved.
Part of the compliance requirement includes precise accountability for various roles within an organization. People who are indicated as being responsible for maintaining PCI DSS compliance must be interviewed to make sure they know what they are supposed to do and are actually doing it per the PCI DSS requirements. People who are designated as responsible for PCI DSS compliance and who are held accountable by the standards are required to go to yearly training on security for each of the requirements they are responsible for meeting. They must also be interviewed to make sure they have a record of their attendance at such training.
Scope Changes
Because systems change, Appendix A3 businesses are required to review changes in their compliance scope at least quarterly. This review includes determining which networks and system components are in scope and determining which networks and system components are out of scope. The business must also explain how it is so, for example, indicate the kind of segmentation implementation that isolates that portion of the network that is not considered to have any access to customers’ Personal Access Numbers (PANs). This review also includes determining what other entities may have any access to the businesses’ CDE.
When there’s a change in software, hardware or any aspect of your systems or network, you have to conduct another documented impact assessment. You must also review how your systems and network continue to meet PCI DSS conditions for compliance. If the PCI DSS scope has changed, then you have to formally update the scope in all documentation and procedures. All this documentation and the actual changes have to be reviewed by the responsible party who must also interview those persons responsible for any new systems or network segments in the scope of compliance. The results of the impact assessment have to be signed off on by the responsible party, who is held accountable for what is left out and what is added in.
Once a change is complete, the business has to go through the whole verification process again for the new or changed systems and networks to make sure everything is still in compliance. Changes to your network diagram that reflect changes to the network might have to be verified again. You might have to verify the new configuration of systems such that all default passwords are changed and all unused services are disabled. Ensuring your systems and network are safeguarded with the proper security controls like patching of systems and audit logging is also a strong possibility. Making sure that Sensitive Authentication Data (SAD) is never kept and that any Cardholder Data (CHD) that is stored is included in documentation and becomes part of the data-retention procedures and policies is likely to be required. It is also highly likely that newer system and network components will be included in the screening that must happen on a quarterly basis.
Penetration Testing and Data Discovery
After any segmentation changes are made to the network, the business must conduct penetration testing. Penetration testing must also be conducted again every six months thereafter to determine which segments of the network remain in scope. The business also has to do this every time there is another change to the way the network is segmented and the controls used to segment it. Penetration testing must decisively prove which systems and network segments remain in scope and which ones are out of scope from the rest of the systems in the CDE.
Beyond penetration testing, a data discovery method has to be used to determine what the PCI DSS scope is and where any clear-text PANs may come from and be kept. This has to be reviewed at least quarterly and when there are any changes to the CDE or the processes therein. Methods for data discovery have to consider the fact and take into account clear-text PANs outside of the currently defined scope. Again, the results must be documented and reviewed for any people who are responsible for conducting the data discovery to ensure it takes place as specified. An annual review of the data discovery methods used also has to be conducted proving their continued effectiveness.
Clear-Text PAN
What can a business do if it discovers PAN in cleartext outside the CDE? It’s required that a business documents a response that includes getting the data back, deleting it securely or moving it back into the CDE. At this point, the business is also required to document how the clear-text PAN escaped the CDE to begin with and the method for this determination. It is also necessary to explain how the business fixed the data leaks or gaps in processes that lead to the data being found outside the CDE. The business should also indicate the data source and whether the PANs had any track data associated with them.
There must be methods put in place for the detection and prevention of clear-text PAN exits outside the CDE in whatever way that it happened. This includes the production of audit logs and system alerts. To remain compliant, the business has to make sure that the remediation efforts actually happened by interviewing the people who were supposed to implement them. The business also has to make sure that audit logs were reviewed and alarms were responded to by going over the audit logs and alerts.
Incident Handling
To prevent the unauthorized exfiltration of PAN in clear text from the CDE, Appendix A3 of the PCI DSS also requires the development of procedures and policies that demonstrate how responsible people are supposed to handle an incident in progress. This includes procedures that document how to respond to the alert and what to do to fix a data leak or process gap for the prevention of data loss. It should also include what to do if a critical security control fails.
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
Some additional requirements include reviewing business-as-usual activities every quarter; reviewing both hardware and software every year; reviewing permissions according to the principle of least privilege every six months; and implementing a method to detect unusual behavior that might indicate a security incident is in progress.
No Peeking
It was disclosed that for the first time in the history of the PCI Security Standards Council’s compliance standards RFP feedback will be a significant driving force for the changes made in the PCI DSS v4.0 Draft 0.1. Specifics regarding precisely what changes are being suggested remain to be discovered as all stakeholders were required to sign a Non-Disclosure Agreement (NDA) in order to acquire the documents for review.
Even though the PCI SSC doesn’t want anyone leaking specific changes to the PCI DSS to the public. In interviews and online the PCI SSC has indicated several broad categories of change and general changes in requirements that give a good idea as to how compliance may change.
New Requirements
Most of the overarching intentions of the PCI DSS v4.0 Draft v0.1 are in keeping with v3.2.1:
- Ensure the standard continues to meet the security needs of the payments industry
- Add flexibility and support of additional methodologies to achieve security
- Promote security as a continuous process
- Enhance validation methods and procedures
However, there will be new requirements according to the PCI SSC. Some of the suggested upcoming requirements include verification by businesses that their PCI DSS scope is correct, more requirements of service providers, and password requirements changes that will allow for the reality of different and better authentication methods. There are also changes to the risk assessment process that ensure the risk management process is clearer with more guidance.
Security and Flexibility
The RFC PCI DSS v4.0 Draft v0.1 now contains a sample reporting template for a suggested new method to validate new security controls that are customized by a business. This means that the standards are going to be more flexible, if not more rigorous. Businesses that want to achieve compliance are going to be able to use the latest technologies to secure their cardholder data. They are no longer strapped to required practices and technologies that aren’t able to keep up with the fast-paced development of new security threats and countermeasures.
According to the PCI Security Standards Council, all 12 core PCI DSS requirements will remain intact but will be redesigned to present security objectives first and foremost. The 12 core standards currently mirror the security industry best practices, so the wording is expected to change and possibly become more generic regarding specific security controls. Version 3.2.1 Standard’s current goals and requirements can be viewed online on the PCI DSS Quick Reference Guide.
Expertise Where You Need It
Whether you’re planning to update your systems when the new standards are released or you’re in need of help with compliance issues now, RSI Security is here to help! RSI Security staff are experts in PCI DSS compliance and can help you assess your system to get the proper controls in place so you can get back to doing business. RSI Security is a Qualified Security Assessor (QSA) and an Approved Scanning Vendor (ASV) with over 10 years of experience as a top-of-the-line service provider. We have serviced over 200 PCI clients and are the only QSA in San Diego, CA. Contact RSI Security today to schedule a free consultation.
Schedule a free consultation
