ITS 4050 - Internet and Web Security

Chapter 9, Maintaining PCI DSS Compliance

This lesson presents some material from chapter 9. Objectives important to this lesson:

1. Common credit card transaction processing
2. Payment Card Industry Data Security Standard (PCI DSS)
3. Being PCI DSS compliant
4. PCI DSS assessment
5. Mitigation best practices
   

Concepts:

Chapter 9

The chapter begins with two common methods for processing transactions:

• batch processing - several transactions are held in a queue or a buffer, and are processed when the system is ready, or when the business chooses to process them; this method is more useful when transactions do not need to be processed immediately, such as pre-Internet catalog driven businesses
  
• real-time processing - transactions are processed as soon as they occur; this is more common for e-businesses than for brick and mortar businesses: online customers expect to get feedback about the sale and shipping updates constantly
  

The text provides some history about the Payment Card Industry Data Security Standard (PCI DSS), which was created by American Express, Discover, JCB (Japan Credit Bureau), Mastercard, and Visa. We can consider this a classic case of a trade association created by industry leaders to establish a set of working standards. Page 233 presents a list of six principles and twelve requirements for compliance with the PCI DSS rules. The link in my last sentence will take you to an official PDF with lots of details.

• maintain a secure network
• Install and maintain a firewall that protects cardholder data.
• Do NOT use default passwords or other security device defaults.
  
• protect cardholder data
• Protect stored cardholder data.
• Encrypt transmissions of cardholder data across public networks.
  
• manage vulnerability
• Use antivirus software and update it regularly.
• Develop systems with security as a feature.
  
• use strong access controls
• Restrict access by the need to know principle.
• Assign unique IDs to those who are given computer access.
• Restrict physical access to cardholder data.
  
• monitor and test your networks
• Track and monitor all access to network assets and cardholder data.
• Regularly test security.
  
• use an information security policy
• Maintain a security policy that covers employees and contractors.
  

This set of rules is like a constitution that outlines how a payment system should work. The rules seem obvious now, but they were not so obvious when they were created. As noted above, the official documents provide more detail about each of the twelve requirements.

The text moves on to consider the fact that PCI DSS is not a law, so we are not required to comply with it as we would be if it were a law or a regulation. However, the text explains that it is an industry standard, which gives the organization that oversees it (the PCI Security Standards Council) the right to fine organizations, and to refuse to allow noncompliant businesses to process transactions with the entities that are part of the council. This means "play by our rules or forget processing transactions on American Express, Discover, JCB, Mastercard, or Visa". The text mentions a story about a company that was in noncompliance when 40 million credit card numbers were stolen from it. (According to Wikipedia, this happened back in 2005.) The company lost its authorization to process Visa and American Express transactions. It was acquired by another company later that year, and that company shut down in 2008.

The bottom line is that the standards set by PCI SSC are international standards that are effectively laws everywhere, regardless of your location or government.

The text presents a short section on designing and building a website that is PCI DSS compliant. The first step is to determine your estimated number of annual transactions.

• Level 4 - fewer than 20,000 transactions per year
• Level 3 - from 20,000 to 1,000,000 transactions per year
• Level 2 - from 1,000,000 t0 6,000,000 transactions per year
• Level 1 - more than 6,000,000 transactions per year
  

If you are in levels 4, 3, or 2, you can do an annual self-assessment, and quarterly network scans. If you are in level 1, you must have an annual on-site audit from an accepted authority, and quarterly network scans. The text also provides six objectives on page 235 that describe behaviors that need to be part of your website's business.

• Remove sensitive data from your system as soon as possible. This reduces the possible data that could be lost to a successful attack.
• Protect your perimeter as well as your network. Your first line of defense is at the edge of your network, not deep inside it.
• Secure payment card applications. Any application that is used in processing payments should use secure protocols and secure procedures.
• Monitor and control access to systems. The text tells us to use access controls and auditing. It is also good to use random real time checks to see what happens between audits.
• Protect stored data. You will need to store some cardholder data. Protect it and remove it when it is no longer needed.
• Do everything else. This is an obvious catch all category, but it includes writing and using policies, as well as telling people how to comply with them.
  

Whether you are in the levels that do a self-assessment or must have an on-site audit, you should plan to conduct assessments yourself. If you are checking your status regularly, you will have fewer and smaller errors to handle. Pages 236 through 238 cover topics that should be examined internally, regularly and thoroughly. Page 237 has a long list of topics you should cover in a report about your findings.

The chapter has a much longer than usual section on best practices. It begins on page 238. It revisits and expands on the twelve requirements found at the beginning of the chapter.