Payment Card Industry Data Security Standard

From Computing and Software Wiki

Revision as of 20:50, 2 December 2007 by Manselnj (Talk)
Jump to: navigation, search

NOTE: This is currently a very rough draft. I have 2 exams this week and will be making the final draft in one week (12/12/07)

The Payment Card Industry Data Security Standard (PCI DSS) is a security document created by the Payment Card Industry Security Standards Council (PCI SSC) in order to unify the security requirements of the Payment Card Industry. In order to tie this in with what was tought in Comp Sci 3IS3 (taught at McMaster University), the PCI DSS will be presented as an Industry Wide Security Policy and as such will be evaluated by tracing its development through the Security Life Cycle. The first step in the Security Life Cycle is to identify threats. The main threat to the PCI is that of Card Holder data being stolen. The next step is Policy Creation. In order to create one coherant document for Merchants to follow, the five major brands of the PCI (Visa, Mastercard, American Express, Discover and JCB) formed the Payment Card Industry Security Sandards Council. Next comes the requirements specifications. The PCI SSC created a detailed document of 12 major requirements for Merchants and any company which deals with Card Holder data to comply with. These requirements focused on the ability of the Merchant to protect Card Holder data, both electronic and physical copies. The next phase includes the design and implementation of the security a security system to enforce the afore stated requirements. For a company wide security policy, this is possible. However, for an industry wide security policy it does not make sense to specify implementation because of varrying Merchant sizes. Finally comes the Operation and Maintenance phase. The operation of each Merchants security system depends on their implementation of the requirements stated in the PCI DSS. However, this operation can be assured to be PCI DSS compliant through the use of QSA's and ASV's. The important part of this phase is the Maintenance part. The PCI DSS has gone through a few updates since it's creation as direct results of problems with the first version of it or new security issues that may have arrisen.

Contents

Terms Used In This Article

  • PCI (Payment Card Industry): A Payment Card is any "card" form of payment. This can cover everything from credit cards to debit cards. The Payment Card Industry consists of all the companies which make up the many different brands of payment cards in use today. (ie Visa, Mastercard, ect..)
  • PCI SSC (Payment Card Industry Security Standards Council): A council made up of Visa, Mastercard, American Express, Discover and JCB (Japan Credit Bureau) created in order to align their individual security goals into one document - the PCI DSS.
  • PCI DSS (Payment Card Industry Data Security Standard): The document created by the PCI SSC in order to align each companies security goals.
  • Card Holder: Any customer of a Payment Card company.
  • Merchant: Any company which accepts Payment Cards as a form of payment.

What is a Security Policy?

A Security Policy is a statement that partitions the states of a system into sets of authorized, or secure, states and a set of unauthorized, or nonsecure, states. [ 1 ] A security policy is the bases on which all the rest of a companies security mechanisms are based on. Obviously, having a good company wide security policy is important. The next logical step is to encorporate a system wide security policy. The Payment Card Industry Data Security Standard could be viewed as an example of an industry wide security policy.

Security Life Cycle


Figure 1: The Security Life Cycle


The Security Life Cycle consists of the following phases: Threats, Policy, Specification, Design, Implementation and Operation and Maintenance (See Figure 1). As you can see, the security life cycle relies heavily upon later phases giving input to previous phases so that they can be updated. This keeps the security system fresh and hence keeps whatever the security system is protecting more secure too.

Identify Threats

The main threat to the Payment Card Industry as a whole is more of a threat to the card holders than the industry itself. The card holders are taking a chance whenever they use their credit cards to make a purchase. This threat is not only present when purchasing online, but also when purchasing in stores. The threat originates from a lack of industry wide standards on how card holder information should be stored, processed or transmitted.

This security threat directly affects the Payment Card Industry because if cardholders don't trust that their information is secure, then they will not use their credit cards and hence the Payment Card Vendors loose business. This is why the Payment Card Industry is moving forward with their industry wide standard for security, the Payment Card Industry Data Security Standard.

Formation of the PCI SSC

Policy Creation

Before December 14th 2004, the 5 major Payment Card companies (Visa, Mastercard, American Express, Discover and JCB (Japan Credit Bureau)) each had their own set of Information Security Standards. This meant that retailers had 5 different security policies to comply to. After December 14th 2004, these 5 brands of cards collaborated to create the Payment Card Industry Security Standards Council (PCI SSC). The purpose of this council is to align the goals of each of the Payment Card companies an industry wide security policy for merchants to follow.

Requirements Specifications

An overview of the list of requirements needed to maintain Payment Card Industry Data Security Standard (PCI DSS) compliance is available here About the PCI Data Security Standard (PCI DSS). The full list of requirements is available here: Download the PCI DSS. Below is the summarized list and an explaination of what each item means. There are 12 major requirements which can be broken up into 6 categories.

Build and Maintain a Secure Network
1.)Install and maintain a firewall configuration to protect cardholders' data
2.)Do not use vendor-supplied defaults for system password and other security parameters

  • This set of requrements is meant to keep any network of computers which contain Card Holder information in a secure state


Protect Cardholder Data
3.)Protect stored cardholder data

  • This requirement is meant to protect the card holder data while it is stored on merchant computers

4.)Encrypt transmission of cardholder data across open, public networks

  • This requirement is meant to protect cardholder data when it might be necessary to transmit it accross a public network (ie when contacting the Payment Card server)


Maintain a Vulnerability Management Program
5.)Use and regularly update anti-virus software

  • This requirement is meant to ensure that all merchants do take advantage of some form of anti-virus software.

6.)Develop and maintain secure systems and applications

  • This requirement is meant to put security as a top priority during the development of software. This is an important requirement because many times when software is being designed, security is tacked on as an afterthought. By at least making developers aware of security as being a requirement of their software, this ensures better quality of any security mechanisms built into the software.


Implement Strong Access Control Measures
7.)Restrict access to cardholder data by business need-to-know

  • This requirement is meant to ensure that only people who need to know about cardholder data have access to it. This is similar to the principle of least privilege.

8.)Assign a unique ID to each person with computer access

  • This requirement is meant to add a level of accountability to all users on the system. If each user has their own unique ID on the merchant's system, then actions can be tracked on linked to the person who did them.

9.)Restrict physical access to cardholder data

  • This requirement is meant to extend the coverage of the PCI DSS to any form of Card Holder data which may not be on a computer. Hence, the PCI DSS is extended to cover not only digital information but also physical coppies of the information. However, this does not prevent the threat of customer data being stolen entirely. There is nothing to prevent an employee from copying down information with a pencil and paper. Though this is a problem, it is partially alleviated by requirement 7: Restrisct access to cardholder data by business need-to-know. If only a small number of employees can access the Card Holder data, then it is much easier to track down who may have stolen Card Holder data if there is a security breech from the inside.


Regularly Monitor and Test Networks
10.) Track and monitor all access to network resources and cardholder data

  • This requirement is designed to catch any unauthorized accesses to cardholder data. If an anomoly is detected, then the system should be able to detect it and steps should be taken to fix the problem

11.) Regularly test security systems and processes

  • This requirement is meant to ensure that merchants don't just set and forget their security systems. It reminds them that security is a fulltime job and must constantly be maintaned.


Maintain an Information Security Policy
12.) Maintain a policy that addresses information security

  • Though this may seem a bit redundant, this is an important requirement. It means that every merchant that deals with Cardholder Data must have their own security policy as well in order to protect cardholder data.


This list was adapted from lists found [[ | here]] and [[ | here]].

Design/Implementation

There is no design or implementation specified in the PCI DSS. This is because the application of this security policy is so broad that it is impossible to have one design that will work for every company. For example Soney, which may handle millions of transactions a year, will need a different implementatino than a small "mom and pop" company, who may handle only a few hundred transactions a year. However, requirements must still be met to some degree depending on the volume of Payment Card transactions which occur per given merchant. This makes the PCI DSS sound rather weak. However, there is a way which the Payment Card Industry Security Standards Council can keep track of whether or not the requirements are being met. This is through the use of QSA's and ASV's.

  • Qualified Security Assessors (QSA's) are companies who have been approved by the PCI Security Standrads Council to assess the compliance of merchants to the PCI DSS. The way the PCI Security Standards Council does this is through a certification program. This requires not only the company to be certified, but also all of it's employees to be certified on a yearly bases.
  • Approved Scanning Vendors (ASV's) are companies who are approved by the PCI Security Standards Council to assess merchants' networks for security vulnerabilities. They accomplish this by simulating both normal and abnormal processes on the merchants networks. Again, ASV's must also be certified by the PCI Security Standards Council on a yearly basis.


Operation and Maintenance

The final step of the Security Life Cycle is Operation and Maintenance. Though this is the final step, it is by far not the least and the life cycle does not end here. This step requires that any time a security breach is detected, steps must be taken to improve the security system. The PCI DSS has definately entered this phase. There are two examples of such maintenance and updating occuring in the PCI DSS:

  • Version 1.1
  • TJ Max

Version 1.1

Version 1.1 of the PCI DSS was releases on September 2006. This was only a year and a half after the release of the version 1.0 of the PCI DSS, which is pretty fast considering the PCI DSS is meant to be a security wide standard. Version 1.1 clarified many of the requirements and wording of Version 1.0 and also included suggestions on how to achieve compliance. A full summary of the changes between PCI DSS Version 1.1 and PCI DSS Version 1.0 are available[[1]].

TJ Max

In Mid-December of 2006, the company computer systems were compromised and customer data was stolen. Everything from credit card numbers to street addresses were stolen from 45.7 million customers. The attack did not come from the internet, but rather from an inadequitly secure wireless network. As you can see from figure 3, this even it still affecting the company today, December of 2007. The highlighted link links to an explaination to the customers about what happend, why it happened and what steps are being taken to fix the problem.
As a direct result of this, the PCI DSS was updated to included better guidelines about wireless networks. Specifically, section 4.1.1 added specifications about implementing Wireless Encryption Protocall Correctly and provided better guidelines for key rotation.

Summary

HaveFunWithCasWiki  :D

References

  1. Bishop, Matt. Introduction to Computer Security. Boston: Addison-Wesley, 2006.
  2. (2007). About the PCI DSS - PCI Security Standards Council. Retrieved December 2, 2007, Web site: https://www.pcisecuritystandards.org/tech/index.htm
  3. T.J. Maxx. (2007). In Wikipedia [Web]. Retrieved December 2, 2007, from http://en.wikipedia.org/wiki/T.J._Maxx
  4. PCI DSS. (2007). In Wikipedia [Web]. Retrieved December 2, 2007, from http://en.wikipedia.org/wiki/PCI_DSS
  5. PCI DSS Compliance Demystified. Retrieved December 2, 2007, Web site: http://pcianswers.com/
  6. PCI DSS Compliance, Payment Card Industry Data Security Standard and Credit Card Security. Retrieved December 2, 2007, from PCI Data Security Standard Web site: http://www.itgovernance.co.uk/pci_dss.aspx

External Links

See Also

Electronic Voting Systems
Social engineering
Piggybacking
Identity Theft
The Mitnick attack
Security and Storage Mediums
Operating Systems Security
Honeypot
Smart Card technology to prevent fraud

Retrieved from "http://wiki.cas.mcmaster.ca/index.php/Payment_Card_Industry_Data_Security_Standard"
Personal tools