SANS ISC: Cyber Security Awareness Month - Day 12 PCI DSS - SANS Internet Storm Center

• SANS Site Network
  • Current Site
  • Internet Storm Center
  • Other SANS Sites Help
  • Graduate Degree Programs
  • Security Training
  • Security Certification
  • Security Awareness Training
  • Penetration Testing
  • Industrial Control Systems
  • Cyber Defense Foundations
  • DFIR
  • Software Security
  • Government OnSite Training

SANS ISC InfoSec Forums

Today I'll provide an overview of what is often the elephant in the room. The Payment Card Industry Data Security Standard (PCI DSS). Unlike ISO 27001 where shades of grey are acceptable, in PCI DSS things are very much black and white, with some wiggle room  although limited and realistically only if you can convince the QSA that what you are doing is ok.  It boils down to you either comply with a requirement, or you don't. There is no "kind of".
 

Background
Each of the payment brands has a set of information security requirements that must be met by its merchants. This meant that in order to process VISA transactions you needed to comply with Visa’s Cardholder Information Security Program (CISP).  When dealing with MasterCard you needed to comply with MasterCard’s Site Data Protection (SDP) and so on for American express, Discover and JCB issued cards. In order to simplify the requirements on merchants and to align the different programs the founding members developed PCI DSS and the PCI Security Standards Council was created to manage the various different standards.

Founding members and their various compliance requirements:

• American Express: • www.americanexpress.com/datasecurity
• Discover Financial Services: • www.discovernetwork.com/fraudsecurity/disc.html
• JCB International: • www.jcb-global.com/english/pci/index.html
• MasterCard Worldwide: • www.mastercard.com/sdp
• Visa Inc: • www.visa.com/cisp
• Visa Europe: • www.visaeurope.com/ais

The main standard most people will need to comply with is PCI DSS. The other standards have a specific scope. 

• PA-DSS applies to those that are selling an application that accepts, processes, stores or transmits credit card information.
• PCI PTS applies to the actual pin pad devices many of us are familiar with and
• PCI P2PE (Point-to-Point Encryption) which deals with encryption in point to point solutions.  

PCI DSS applies to any organisation that  accepts, process, store or transmit credit card information. It unfortunately does not matter how small or large you are, you have to meet all the requirements of PCI DSS, although there are some small differences in the standard depending on whether you are a merchant or a service provider. If you accept credit cards, you have to comply. 

Depending on the number of transaction you may be considered a level 1, 2, 3, or for some payment brands even a level 4 merchant or service provider.  In a nutshell if you are a level 1 merchant or service provider, you will need to have an on-site assessment annually and Quarterly Authorised Scanning Vendor (ASV) scans. Lower levels may only require you to validate using a self assessment questionnaire (SAQ) and have quarterly ASV scans. The main thing to remember though is that the number of transactions you do only determines the validation requirements, not the compliance requirements.  You will always have to comply with all requirements outlined in the standard, unless they are really not applicable to your situation.

Just to make it slightly more complicated the number of transactions that determines what level you are depends on each payment brand.  You can be a level 1 merchant for Visa, Level 2 for MasterCard and level 3 for Amex. The best place to find the specific levels is via one of the links above. To make it even more complicated your acquirer or the payment brand themselves may specify that you have to validate as a level 1 merchant or service provider. Some service providers will always have to validate as a level 1 regardless of the number of transactions processed, depending on the type of service being provided.   So life can get confusing
 
What happens if you don't comply, well that depends on the acquiring bank that you deal with as a merchant or service provider. Ultimately the Acquirer caries the risk, they are the ones that get yelled at and have to provide evidence of their merchants' compliance (i.e you) with the standard. When you are not compliant they may impose additional fees on your organisation until you are compliant, they may refuse services. I have see both happen in the past twelve months. Should there be a breach you may also be held liable for the costs associated with the breach.  Typically the acquirer or payment brand will bring in their own investigative team and perform an analysis as to how the breach occurred. If, at the time, of a breach you are not compliant with PCI DSS they may try and recover their costs. It is therefore important that once you are compliant you make sure you are able to maintain it.

A longish background I know, but it is important to get these things straight before you try and tackle the rest of the standard. 

Scope and scope reduction
Possibly the most difficult thing to do is scoping of the PCI environment and the one area where the as a QSA you get the most questions from people.  Scoping can be a pain, but there are a few rules of thumb you can work with that might make it easier for you.

• Electronic world
  • If the system accepts, stores, processes or transmits credit card information it is in scope.
  • If you use tokenization the systems interacting with the tokenization services are in scope.
  • If you can access systems that process card information you are in scope. For example if I have a web server that shows some static pages (nothing to do with buying anything or processing cards), but it is in the same network segment (i.e. it has access to the other web server) as those web servers dealing with credit card information, then it is in scope.
• Paper world
  • If it has a credit card written on it, it is in scope

If you are slightly freaked out by those broad rules and you are thinking OMG that means my entire worldwide network is potentially in scope, then you are starting to get it. PCI DSS is the elephant in the room or bigger than Ben Hur is quite appropriate as well. Which is where scope reduction comes into play.

PCI DSS is concerned with specific pieces of information, the cardholder data.  Credit card number, Name, expiry date, CVV/C2V, and authentication data. Some of which you are allowed to store and use prior to authorisation of a transaction and not after. Some of it must never be stored (e.g. authentication data, unless you are an issuer of course). So by reducing the information kept, you may be reducing the impact of PCI DSS on the organisation.  
The main mechanisms for reducing scope are:

• don't store card details. If you do not need the card number for anything, get rid of it once the transaction is complete.  Keep enough info so you can do your settlements and chargebacks if needed;
• Truncate, only store the first 6 and last 4 digits of the card number;
• Tokenize - Use an internal or third party tokenization service which takes a credit card and provides a non identifiable result back which is used in your transactions (i.e if you lose the token, the actual credit card number cannot be discerned);
• Network segmentation is also a common method for reducing the scope.  Basically those servers and other devices that accept store and process card details are segmented off from the main network and has very limited interaction between the cardholder environment and the rest of the network.  If done correctly the scope for PCI may be reduced and finally,
• get someone else to do it.  Many organisations reduce scope by getting a service provider to certain tasks for them, such as store credit card details. Third party tokenization services are quite common. Likewise having a third party scan forms, redact the credit card number prior to it being sent to your organisation is very common.  Depending on how it is implemented having someone else do the work may reduce your scope.

The how and why is a bit beyond this intro to the standard. Either way if doing scope reduction exercises keep your QSA briefed and they can provide advice as to what you are doing will help your situation or not.

Requirements
There are twelve requirements in the standard. A number of them have been introduced as a result of breach investigations, the remainder are fairly typical security practices that hopefully you are already doing anyway. Following are brief explanations of the requirements and some general observations regarding the requirement based on PCI based engagements over the years. 

• Requirement 1: Install and maintain a firewall configuration to protect cardholder data

This requirement outlines the processes that need to be in place with regards to the management of firewalls and routers used in the Cardholder Data Environment.

Most organisations have this reasonably under control. There are however documentation requirements that are not often met and there are those pesky ANY rules (you can have them, but it typically increases the scope).

• Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters

Systems are often compromised through the use of default passwords and other default configuration items.  This section addresses requirements such as default passwords, but also security/hardening configuration of devices used, such as server configuration standards for servers and network devices.

This varies from organisation to organisation. Basic build documents are usually available, but they do not often address the requirements of the standard. Default passwords are usually changed, but the simple ones are not (public, private ring a bell?). 

• Requirement 3: Protect stored cardholder data

This requirement addresses the storage requirements for cardholder information and what can be stored and what cannot be stored.   It also addresses encryption requirements and outlines the related documentation requirements.

This is probably the most difficult requirement for most organisations.  Encrypting and managing the keys can be a big challenge.  

• Requirement 4: Encrypt transmission of cardholder data across open, public networks

This requirement addresses the interaction between the organisation and third parties as well as donors/customers. 

Usually easily met by most organisations as they often already have VPNs or SSL based applications.

• Requirement 5: Use and regularly update anti-virus software or programs

This requirement addresses the malware management of the environment and helps ensure that malicious software does not adversely affect the environment.

If you don't have this sorted, PCI will be the least of your problems.  Most organisations do OK with this, just read the requirement for regular scanning carefully.

• Requirement 6: Develop and maintain secure systems and applications

This requirement addresses patching and change control as well as the development and testing of applications used to accept and process cardholder information.

The main issues we find relate to the lack of security training or awareness for developers as well as a deficiency in security related testing of internal and external facing applications.  On the patching side, if it has a CVSS score of 4 or higher, you must patch.

• Requirement 7: Restrict access to cardholder data by business need to know

Requirement 7 relates to access and privilege management and the processes involved for providing access the cardholder data.  This includes the authorisation process and documentation, typically role based.

Most of the time the deficiencies relate to documentation.

• Requirement 8: Assign a unique ID to each person with computer access.

Users have individual accounts on the various systems and password controls are applied, but not documented.

Userid and password management is often fine, however privileged accounts management and the use of root in some organisations can be challenge.

• Requirement 9: Restrict physical access to cardholder data.
  

In order to protect the cardholder information physical security must be considered.

Usually OK, the most problems we come across relate to dealing with visitors.  

• Requirement 10: Track and monitor all access to network resources and cardholder data.

As part of management of cardholder data it is important to have visibility in the environment and have the ability to track activities. 

The daily review of logs and file integrity monitoring is where most people struggle

• Requirement 11: Regularly test security systems and processes.

Under PCI DSS it is expected that the security of systems and applications be tested regularly to ensure that cardholder information is safe.

The quarterly wireless checks for rogue devices is usually the main stumbling block as all sites have to be done. Likewise the difference between a penetration test and a vulnerability scan is sometimes confused and causes issues.  

• Requirement 12: Maintain a policy that addresses information security for employees and contractors.
  

Policies are the cornerstone of compliance as they outline the requirements to be followed within the organisation.

Usually policies are OK, however monitoring of the PCI status of your service providers is often not well developed. 

Becoming compliant
If you are in the process of becoming compliant, then the first step should really be to see where you are at.  So perform a gap analysis, have a look at all the of the requirements and see how your organisation stacks up against these.  The council has two documents available here https://www.pcisecuritystandards.org/security_standards/documents.php that will help.  Firstly there is the "navigating the PCI DSS v2.0" document.  It provides guidance on the requirements. Secondly there is the "prioritised approach for PCI DSS Version 2.0" document and spreadsheet that will help with remediation by assisting in prioritising your efforts.  Acquirers have been know to ask for completion of this spreadsheet so they can track your compliance efforts.

Be aware of the self assessment trap that people tend to fall into. Remember all those quizzes in magazines. Can you run 100m in 12 seconds?, sure.  Can you bench press your own weight at least ten times?  no problem.  We tend to over estimate our abilities. So when doing the gap analysis, for each requirement you look at, add the following "how can I prove it?" That should bring answers back into reality. For example requirement 1.1.1 Verify that there is a formal process for testing and approval of all network connections and changes to firewall and router configurations "how can I prove it?".  What the QSA will be looking for is a document that states "must be approved, must be tested, etc" then typically they'll ask to see the approval for a particular change to a network device.  Who approved it, who executed it, etc. If that is not possible, then you are not compliant.

After the gap analysis and the remediation you are ready for either the on-site assessment, if needed, or the self assessment. There are a number of different self assessment questionnaires that can be completed depending on your situation.  Usually the acquirer stipulates which SAQ needs to the be completed. Just remember the magazine quiz trap when completing the SAQ, it is easy to say yes when the answer is really no.     

A bit longer than I had initially intended, so that's where we'll leave it for today. Comments always welcome I would suggest that for specific questions you use the contact form.

Cheers
Mark H - www.shearwater.com.au