Staying compliant to PCI DSS ensures that merchants and service providers have implemented and maintained all security and authentication standards when taking card payments and gathering, storing and transmitting cardholder information. The new PCI DSS 3.0 requirements have rolled out that discuss changes and modifications to existing standards.
If your company takes any type of electronic payments from customers, or a third-party service provider handling cardholder information, then you already know how important it is to keep this data secure from internal and external security threats. The PCI DSS 3.0 are a set of protocols, procedures and policies from the Payment Card Industry Security Standards Council (PCI SSC) to ensure that you maintain a secure data environment for all cardholder payment information and have the internal controls in place to detect and remediate and risks.
The current version of PCI DSS 3.0 is the third major iteration of these security standards. Every three-year cycle, a new update is introduced that takes into account the changing technology environment and emerging threats that merchants and service providers may encounter. The new requirements for PCI DSS 3.0 have been rolled out and you will need to ensure that existing systems and networks will remain compliant with PCI SSC policies.
Changes to PCI DSS 3.0 focus on these 19 requirements:
1) PCI DSS 3.0 — 1.1.3: Current Diagram Showing All Cardholder Data Flows Across All Systems and Networks
This new requirement was added because old systems and new networks may be added throughout the life of the company. By creating a current diagram about how cardholder data travels through your IT infrastructure, you will have a better understanding of which systems and networks may store, transmit or use data and where these components are located so you can enhance and maintain security protocols.
2) PCI DSS 3.0 — 2.4: Maintain an Inventory of System Components that are in Scope for PCI DSS Controls
Creating a current inventory list of all system components can ensure that when PCI DSS is implemented, there will be no components excluded. Prevent these components from being forgotten by including them in the configuration standards of your organization.
3) PCI DSS 3.0 — 5.1.2: For Systems Considered Not Commonly Affected By Malicious Software, Perform Periodic Evaluations
This serves to identify and evaluate evolving malware threats in order to confirm whether such systems still don’t require anti-virus software. The requirement focuses on systems that are not typically targeted by malicious malware and other security threats. Since malicious software is constantly evolving, these systems may in time be targeted by new threats. By performing periodic evaluations, it allows you to create risk assessment on these systems and implement security methods and protection measures when necessary.
4) PCI DSS 3.0 — 5.3: Ensure That Anti-Virus Mechanisms Are Actively Running and Cannot be Disabled or Altered by Users
Anti-virus software offers optimal protection when it is constantly running and only updated with the latest anti-malware protections. This requirement allows you to create procedures and protocols to prevent any unauthorized altering of the software or have it become disabled unless it is specifically authorized. Make sure anti-virus measures are active unless specifically authorized by management on a case-by-case basis and for a limited time period.
5) PCI DSS 3.0 — 6.5.10: Broken Authentication and Session Management
Whenever a session ends, it should be completely broken so that no unauthorized individual gains account credentials or other access measures to an authorized user’s account. This can allow you to securely manage all authentication and sessions.
6) PCI DSS 3.0 — 8.2.3: Passwords and Phrases Criteria
The requirement specifies that all passwords and phrases should have a minimum length of 7 characters and contain both numeric and alphabetic characters. In addition, alternatively, the passwords and phrases should have the complexity and strength that is at least equivalent to the mentioned parameters.
7) PCI DSS 3.0 — 8.5.1: Service Providers with Remote Access to Customer Premises Must Use a Unique Authentication Credential for Each Customer
This service provider requirement involves the use of remote access such as a company providing support for POS servers and other examples but not for shared hosting providers who will be accessing their own hosted environment. This change is important as multiple customers may become impacted due to a service provider only using a single set of credentials to access the information for every customer. Instead, the service provider must have a different and unique authentication credential for each customer.
8) PCI DSS 3.0 — 8.6: Physical and Logical Controls Must Be in Place So that Only the Intended Account Can Use the Mechanism
Where other authentication mechanisms are used, use of these mechanisms must be assigned to an individual account and not shared by other accounts. Sometimes tokens, smart cards, certificates and other authentication mechanisms are used by multiple people to access a range of accounts as it can be hard to identify which user is which. For these circumstances, a unique PIN, password or other control should be put in place to identify the user who is gaining access to systems and networks using a shared authentication mechanism.
9) PCI DSS 3.0 — 9.3: Control Physical Access of Onsite Personnel to Sensitive Areas
A change to the PCI DSS 3.0 standard involves how onsite personnel can gain physical access to sensitive areas. This requirement focuses on controlled access where it must be authorized and only based on the worker’s job position. Access must be revoked immediately upon termination as all physical access mechanisms must be returned or disabled to prevent security breaches.
10) PCI DSS 3.0 — 9.9: Protect Devices that Capture Payment Card Data Via Direct Physical Interaction with the Card from Tampering and Substitution
This best practice has turned into a requirement as it applies to card-reading devices at the point of sale, such as a card swipe or a dip. Criminals have become more sophisticated in trying to break into these systems or creating skimming devices that will read cardholder information when in use. This standard is not required for manual key entry components such as POS keypads or computer keyboards, although it is recommended.
11) PCI DSS 3.0 — 10.2.5: Use of and Changes to Identification and Authentication Mechanisms
This includes, but is not limited to the creation of new accounts and elevation of privileges, and all changes, additions, or deletions to accounts with root or administrative privileges. By having identification controls in place, you can learn which accounts have been accessed and used as you can search for any malicious manipulation of authentication controls. This allows you to look for anyone who has attempted to impersonate a valid account to gain unauthorized access into system.
12) PCI DSS 3.0 — 10.2.6: Initialization, Stopping, or Pausing of the Audit Logs
Malicious users may turn off the audit logs to hide their illegal behavior and activities. This addition to the PCI DSS 3.0 can allow you to create control mechanisms, tests and alerts to determine when the audit logs have been stopped, paused and later initialized to hide this illicit activity.
13) PCI DSS 3.0 — 11.1: Implement Processes to Test for the Presence of Wireless Access Points (802.11)
Companies are also required to detect and identify all authorized and unauthorized wireless access points on a quarterly basis. Wireless technology may be exploited to gain access to cardholder information. Processes such as wireless network scans, network access controls and physical system component inspections can detect unauthorized wireless devices that may be hidden on a system component or may be invisible as it tries to gain access through a wireless point.
14) PCI DSS 3.0 — 11.3: Implement a Methodology for Penetration Testing
A penetration test can be used to simulate real-world attacks to check for vulnerabilities where a malicious user could penetrate the system environment and create strategies to prevent such attacks. Methodologies need to contain the following based on PCI DSS requirements:
- Includes review and consideration of threats and vulnerabilities experienced in the last 12 months
- Defines application-layer penetration tests to include, at a minimum, the vulnerabilities listed in Requirement 6.5
- Includes testing from both inside and outside the network
- Includes coverage for the entire CDE perimeter and critical systems
- Defines network-layer penetration tests to include components that support network functions as well as operating systems
- Includes testing to validate any segmentation and scope-reduction controls
- Specifies retention of penetration testing results and remediation activities results
- Is based on industry-accepted penetration testing approaches (for example, NIST SP800-115)
15) PCI DSS 3.0 — 11.3.4: If Segmentation is Used to Isolate the CDE from Other Networks, Perform Penetration Tests
These should be performed at least annually and after any changes to segmentation controls/methods to verify that the segmentation methods are operational and effective. All out-of-scope systems should be isolated from in-scope systems. This modification was added to PCI DSS 3.0 so that you can make sure that the segmentation controls are effective. Penetration testing from outside and inside the network can help to detect any gaps in security.
16) PCI DSS 3.0 — 11.5.1: Implement a Process to Respond to Any Alerts Generated by the Change-Detection Solution
Being alerted to any changes made to the network and systems is only the first step of the process. In addition, the PCI DSS 3.0 requirements also require that there be a process that can be implemented immediately to respond to these alerts.
17) PCI DSS 3.0 — 12.2: Implement a Risk-Assessment Process
Risk assessment is used by organizations around the world to help identify threats that will most impact their processes and develop strategies as well as protocols to implement. For PCI DSS 3.0 standards, a risk assessment process will need to be performed at least annually and when there are any significant changes made to the organization. It should also identify critical assets, vulnerabilities and threats as well as result in a formal risk assessment.
18) PCI DSS 3.0 — 12.8.5: Maintain Information About Which PCI DSS Requirements Are Managed by Each Service Provider, and Which Are Managed by the Entity
For PCI DSS compliance, you need to understand what standards service providers are abiding by and if these standards match the requirements your company is following. It provides more transparency into their security measures and offers greater assurance to your company.
19) PCI DSS 3.0 — 12.9: Service Providers Acknowledge in Writing to Customers that They Are Responsible for the Security of Cardholder Data
This refers to cardholder data that the service provider possesses or otherwise stores, processes, or transmits on behalf of the customer. It also says that the company is responsible to the extent that they could impact the security of the customer’s cardholder data environment. With written acknowledgment from the service provider, you can understand the PCI DSS responsibilities that the service provider abides by and their commitment to cardholder data security.
Learn More About PCI DSS
PCI DSS requirements can be an involved and confusing process for your organization. Here at I.S. Partners, we can help demystify these standards so you gain a greater understanding of what is required by your organization to safeguard cardholder data. In addition, we also provide PCI DSS assessments and testing of your systems and security programs. Contact us today to learn more: 215-675-1400 or request a PCI Quote