Payment Card Industry Data Security Standard
PCI DSS is the standard set by the banking and credit card industry for security and privacy around how credit card data is handled. This standard is not a regulatory issue but rather a contractual issue between the College and the banks with which we do business. All credit card processing systems used at Middlebury or Monterey must comply with both the College PCI policy and the PCI DSS standard.
PCI DSS WIKI
The Payment Card Industry Data Security Standard (PCI DSS v3.0) is a standard that has been accepted by all major credit card companies and most credit providers. It is a standard that we must abide by if we are to accept credit cards as a form of payment. PCI DSS is broken into 12 requirements; each focusing on a different domain of security.
While PCI DSS is not an actual law, it is a standard enforced by the credit card industry, and the banks have stated and upheld the policy that they will no longer accept business from non-PCI compliant merchants. The government has used the PCI DSS as a yardstick by which they have measured such regulations as Gram-Leach-Bliley, Sarbanes-Oxley, and most recently the drafting of the Data Accountability and Trust Act.
We employ a device called a Barracuda here at Middlebury which helps us prevent SPAM from flooding our email system. Just shy of a year ago this system was updated to enable it to filter on cardholder information. By default this feature was turned on. We have left this enabled and have begun reporting on these blocked messages and alerting the senders of outbound messages. The Barracuda is intended to serve both as a SPAM filter and a compliance tool.
The PCI DSS v3.0 Standards:
1.0: Install and maintain a firewall configuration to protect cardholder data.
This requirement talks about segmentation of the network at a physical and logical level. It also talks about protections placed between the systems that contain cardholder information and the open or public networks.
2.0: Do not use vendor supplied defaults for system passwords and other security parameters.
This requirement talks about modifying systems from their factory settings so that they have strong security settings that are unique to both the organization and to the system.
3.0: Protect cardholder data.
This requirement points out that other security measures can be circumvented and that cardholder data must be protected and masked. It talks about who should have access to the data and that methods such as encryption should be employed. It emphasizes that account number should be masked and that only essential persons should have access to that information. It also mentions that information in the magnetic strip may not be stored.
4.0: Encrypt transmission of cardholder data across open, public networks.
This requirement states that encryption must be used to transmit data over networks that are out of scope for PCI. If data is unencrypted than that part of the network becomes in scope for PCI and must be protected accordingly.
5.0: Use and regularly update anti-virus software and programs.
6.0: Develop and maintain secure systems and applications.
Requirement 6.0 speaks to application development as well as change control and project management. It also speaks to patch management and system update control. This requirement is about project and system life-cycle management through change control. It also talks about incorporating secure programming practices to ensure error checking, validation controls and other measures.
7.0: Restrict access to cardholder data by business need to know.
This requirement sets guidelines for building business processes and systems that restrict access to cardholder data to only those individuals that need to have access for business critical functions. It speaks of access by user ids, setting rights to deny all, and other configurations.
8.0: Assign a unique ID to each person with a computer access.
This requirement is about accountability and access control. With the use of unique ID’s each user can be held accountable for his or her own actions on the systems. Also control to cardholder data can be controlled by user id. This standard also talks about password policies and control.
9.0: Restrict physical access to cardholder data.
This requirement talks about physical access in terms of access to switches and routers, server rooms and networking closets. It talks about the use of surveillance and locks. It also speaks to the destruction of media and what constitutes media.
10.0: Track and monitor all access to network resources and cardholder data.
This requirement looks at monitoring systems for both user access as well as user activity. It looks at how people manipulate data and also when users access systems. This is about creating audit trails and managing those logs.
11.0: Regularly test security systems and processes.
This requirement speaks to the use of vulnerability scans as well as the use of IDS/IPS solutions. It also speaks to the checking of rogue wireless systems in your in-scope network. This requirement is looking for the presence of testing against current threats on your systems and what measures are in place to test for those threats.
12.0: Maintain a policy that addresses information security for all personnel.
This requirement calls for the creation of a security policy and an education program on that policy for all employees of the organization. The policy should outline the PCI standards and what the expectations are for different individuals and roles under the PCI DSS as it has been implemented across the organization.
Common Practices: These are some common practices that help to protect cardholder information.
1) Do not write down or distribute credit card information in any unencrypted format.
2) Do not access files to which you have not been granted explicit permission to by the owner.
3) Ensure that you have appropriate training on the applications which you use.
4) If you find an error or unsecured cardholder data, notify a manager or the helpdesk.
5) Protect you own information as well as others.