New 3.2 Requirements for Service Providers: What You Should Know

Learn what new requirements service providers will need to fulfill.  

By: Christopher Skarda Security Analyst CISSP, QSA

PCI DSS 3.2 introduced several new requirements for service providers. Until January 31, 2018, these new/revised requirements will be considered best practice and will become requirements starting February 1, 2018.

Here’s a quick look at the new requirements and what service providers are expected to do.

Cryptographic architecture (3.5.1) 

Service providers need to maintain a documented description of cryptographic architectures,
including:

• 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 


You should keep up with evolving threats to your architecture by planning for and documenting updates (e.g., different algorithms/key strengths changes). Maintaining documentation helps you detect lost or missing keys or key-management devices, and identify unauthorized additions to your cryptographic architecture. 


SEE ALSO: PCI DSS Requirement 3: What You Need to be Compliant

Timely detection and reporting (10.8, 10.8.1) 


Service providers are required to implement a timely detection and alerting process to identify failure of a critical security control systems.

Examples of critical security control systems include: 


• Firewalls 

• IDS/IPS 

• FIM 

• Anti-virus 

• Physical access controls 

• Logical access controls 

• Audit logging mechanisms 

• Segmentation controls (if used) 


Service providers need to respond to failures of any critical security controls in a timely manner.

Tweet

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 from the security failure 

• Implementing controls to prevent cause of failure from reoccurring 

• Resuming monitoring of security controls 


Establish responsibilities for PCI and Data (12.4.1) 

Executive management needs to establish responsibility for the protection of card-holder data and a PCI DSS compliance program to include:

• Overall accountability for maintaining PCI DSS compliance 

• Defining a charter for a PCI DSS compliance program and communication to executive management 


Smaller organizations should add these roles to an individual’s job responsibilities, while larger organizations might need to establish a PCI compliance team (e.g., a compliance team made up of IT, accounting, and management).

Whichever is the case, management should give their PCI officer/team power to act and implement necessary changes to become PCI DSS compliant, as well as have at least monthly  meetings with executive management to report on progress. 


SEE ALSO: What are Service Provider Levels and How Do They Affect PCI Compliance?

Quarterly Personnel Reviews (12.11, 12.11.1) 


Service providers need to 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: In addition, you need to maintain documentation of quarterly review process, including: 

• Documenting results of the reviews 

• Review and sign-off of results by personnel assigned responsibility for the PCI DSS compliance program 


These reviews help to ensure that security policies and procedures are being followed as expected. Keep records, including dates and findings of these quarterly reviews.

Penetration testing (11.3.4.1)

By February 1, 2018, service providers who use segmentation to isolate the cardholder data environment from other networks must perform penetration testing on segmentation controls at least every 6 months and after any changes to segmentation controls/methods.

This penetration testing should be performed by a qualified internal resource or third party. If an internal resource is used, the tester should have organizational independence (though they aren’t required to be a QSA or ASV). The purpose of penetration testing segmentation controls/methods is to verify that the cardholder data environment is protected from unauthorized access.

SEE ALSO: New 3.2 Requirements for Penetration Testing and Segmentation: What You Don’t Know

Need help with PCI compliance? Talk to one of our experts! 

Christopher Skarda (CISSP, QSA, CCNA) is a Security Analyst at SecurityMetrics and has worked in data security for thirteen years and the PCI sector for three years. He has a Bachelor of Science in Information Technology from BYU.