An Overview of PCI DSS 3.2: Part 2
Earlier today we wrote about the first half of the Payment Card Industry Data Security Standard (PCI DSS)- a set of requirements dedicated to helping secure credit card data. If you haven’t had a chance to read that yet, click here.
This post is dedicated to providing on overview on the second half of PCI DSS version 3.2: sections fourth through six.
Section 4 – Implement Strong Access Control Measures
This section discusses how access should be governed for system components that contain PCI data, and has three requirements.
Requirement 7: Restrict access to cardholder data by business need to know. This requirement is straightforward and details the approval processes that must be in place before access can be granted to a system or application containing cardholder data. Users requesting access to these systems must have a legitimate and justified business need, which should be documented and logged prior to granting access. A process owner should be identified who is responsible for approving or denying these requests.
Requirement 8: Identify and authenticate access to system components. This requirement discusses the identification and authentication processes when granting access to systems containing cardholder data. First, a unique user ID should be assigned to every individual user so that actions can be traced back to one specific person during an investigation. Systems must also have security features such as a lockout policy for repeated login attempts, removing inactive user IDs within 90 days, and a timeout period where inactive sessions are automatically terminated after 15 minutes. The requirement also describes acceptable standards for passwords and how user passwords should be managed.
Requirement 9: Restrict physical access to cardholder data. This section discusses all of the physical security measures that must be in place to protect systems that contain cardholder data. Some examples are badge readers for data centers, disabling unused network jacks, escorting visitors in sensitive areas, cameras, locking server racks, and others.’
Section 5 – Regularly Monitor and Test Networks
This section covers the monitoring and regular testing of networks containing cardholder data, and consists of two requirements.
Requirement 10: Track and monitor all access to network resources and cardholder data. Logging systems must be in place to track user activities as they relate to cardholder data. Enabling logging in all network environments allows tracking, alerting, and analysis in the event of a security breach – determining the cause of an incident is almost impossible if these logs are not in place. These logs must be protected from alteration or destruction, and an audit trail must be implemented so that investigators can review each user’s actions as they pertain to cardholder data.
Requirement 11: Regularly test security systems and processes. This requirement discusses several testing methods and procedures which must be implemented in the network environment. Scans for new wireless access points must be conducted, with unauthorized APs being removed immediately. Internal and external vulnerability scans must be performed at least quarterly and after any significant change to the network. Network Intrusion Detection Prevention Systems (IDS/IPS) should be implemented to monitor for unusual activity in the environment.
Section 6- Maintain an Information Security Policy
Requirement 12: Maintain an Information Security Policy. This section has only one requirement, which discusses the overall security policy that applies to all personnel in the organization. It first requires that an information security policy be created, published and communicated to all users of information systems. The policy must include: 1) Roles and responsibilities for information security, 2) Assigned individuals to various security management roles, 3) Procedures to manage service provider relationships when cardholder data is shared with third parties, and 4) an Acceptable Use Policy. This section also outlines the need for two additional programs: a Risk Management program to identify, track, and remediate security risks, and an Incident Response program to establish formal procedures for responding to security incidents.
As you can see, the handling of customers’ credit card information is no simple task. If you want to build your customers’ trust and establish your business as one that takes credit card security seriously, consider implementing the recommendations in this guide to help move your organization towards becoming PCI compliant.