PCI DSS in Europe: An Overview

Jonathan Care jonc@lacunae.org COSAC 2010

Overview
The Payment Card Industry Data Security Standard (PCI DSS) is about to enter iteration 2.0 and is increasingly being seen as a baseline for information security controls in business sectors that hitherto have seen little regulatory driver for control of information assets and threats. It is administered by the Payment Card Industry Security Standards Council (PCI SSC) . The PCI DSS addresses operational risk issues faced by processors of payment card data and is shortly to enter a new iteration, PCI DSS 2.0.
1

Who's who in the PCI world Payment Card

Simply put, this is the card issued to the consumer. A payment card under the scope of PCI DSS can be a debit or credit card, and will be branded by the card schemes that oversee the PCI SSC. Payment cards are issued by banks that are not governed by the PCI SSC, such as Laser Cards in Ireland, several in Eastern Europe, which are not governed by the PCI DSS. Store credit cards without a payment card industry brand are not in scope of the PCI DSS.

Payment Card industry

The Payment Card industry is defined as the card schemes that govern the PCI SSC. These are: VISA Inc. and its regional associates. In particular VISA Europe part owned by Visa Inc. and a consortium of member banks. Mastercard American Express Discover JCB These brands combine strategy on payment card security although there have been occasional differences in risk acceptance levels.

Acquiring Bank
The Acquiring Bank is the one that is responsible for clearing the payment made by a consumer into the merchant organisation's bank account. Acquirers are considered to be ultimately liable for the payment security and compliance of the merchants under their care. Fines for non-compliance and breach are levied by the Payment Card Industry member brands to the acquiring bank, who then may in turn issue fines to their merchant organisations.
1 See http://www.pcisecuritystandards.org

PCI DSS in Europe

COSAC 2010

Issuing Bank
An Issuing Bank is one that creates and issues a consumer with a payment card industry branded payment card. Typically these are issued to customers with an existing banking relationship with the Issuer however there are banking organisations that focus exclusively on the issuing of payment cards, offering no other facilities. It is perhaps worth noting that American Express act as an issuer directly, which Visa and Mastercard do not.

Merchant
The merchant is defined as the receiving party in a payment card transaction. Merchants can typically be traditional retailers receiving payments in person, by mail order/telephone order (MOTO), or via an e-commerce channel. In addition, merchants can include government organisations such as the Driver and Vehicle Licensing Agency (DVLA), charitable organisations such as Cancer Research, and indeed any organisation that takes payment cards in settlement is considered a merchant under the terms of PCI DSS. For the purposes of PCI DSS, merchants are categorised into risk levels, primarily dependent on number of card transactions processed regardless of value, although the sector (e.g. gaming, money services) and indeed, the opinion of the payment card industry will play a factor. Merchants who have suffered a breach are normally categorised at the highest level of risk. It is the responsibility of the acquiring bank to determine the merchant level, although QSAs are commonly asked to verify it. While the various payment brands occasionally differ over the number of transactions required to make it into a particular risk category, the reporting requirements are pretty constant. If you are categorised as a Level 1 merchant (typically over 6 millions transactions a year) then an onsite assessment from a QSA is required, together with quarterly scans from an ASV. Level 2 and 3 merchants must complete an annual self-assessment questionnaire, and provide quarterly ASV scans. Level 4 merchants, the lowest risk category (as defined by number of transactions) must complete their SAQ and

Service Provider
A service provider is an organisation that stores, processes or transmits cardholder data on behalf of another organisation (either a merchant or another service provider). Service providers either work as an intermediary between the merchant and the acquiring bank, or else will provide a service to the merchant that is not visible to the acquiring bank.

Participating Organisations
Participating Organisations are ones which pay a fee to the PCI SSC in order to provide input and shape to the evolving PCI Standards. Typical participating organisations include software vendors, large merchants, and some banks.

Qualified Security Assessors

Qualified Security Assessor companies (QSACs) are instructed to provide guidance and assessment of compliance with the PCI DSS. In addition, some QSACs are accredited to assess payment software applications under the Payment Application Data Security Standard (PA-DSS).

Approved Scanning Vendors

Approved Scanning Vendors are accredited to perform vulnerability scans of merchant and service provider infrastructure in order to meet compliance with PCI DSS. It is increasingly common to find QSACs offering this as a service, which hitherto had been provided by specialist penetration PCI DSS in Europe COSAC 2010 2

testing service providers.

What's the standard all about?

The PCI DSS is made up of twelve requirements, each with sub-requirements totalling over 200 control points in all. These requirements are sectioned as follows:

Build and Maintain a Secure Network Requirement 1: Install and maintain a firewall configuration to protect cardholder data
On the face of it, this requirement would seem simple. Install a stateful firewall, and compliance would seem assured. In fact, several controls are mentioned in requirement 1 that can expose procedural flaws in the organisation, such as: Regular reviews of all firewall and router configurations and rulesets. Documented business justification for all open rulesets Up-to-date network diagrams showing the flow of cardholder data throughout the network Ensuring a well-defined DMZ, and removing cardholder from DMZ repositories. Ensuring change control is in place for all firewall and router configuration changes..

Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
It is a well known fact that any attacker (whether software or human) will try to attack using passwords installed by the vendor as a default (for example, the sa account for MS SQL). In an attempt to prompt a move away from these vulnerabilities, lists are published on the internet by security researchers . It is a sobering thought that compromises can be so easily accomplished simply using an automated tool which attempts to gain access to a critical system using manufacturer's defaults. PCI DSS points this out by emphasising that default account, password and any other security controls for any device carrying cardholder data must be changed.
2

Protect Cardholder Data Requirement 3: Protect stored cardholder data

In many ways, requirement 3 can be seen as the heart of the PCI DSS, in that it is concerned with the protection of stored cardholder data. One excellent way of reducing the scope of PCI DSS on the organisation is to take a long hard look at the cardholder data stored ask the honest question Do you need this information, and how would you do your job if it went away. One of the hallmarks of an effective QSA is that they will work with the organisation to reduce the amount of cardholder data stored before engaging in costly and complex preventative measures. Frequently seen breaches are caused by repositories of cardholder that are not robustly protected It is worth considering at this point what constitutes cardholder data under the terms of the PCI DSS. Two classes of cardholder data exist, Protected Storage Data and Sensitive Authentication Data (SAD). We will consider protected storage data first.
2 See http://cirt.net/passwords as an example.

PCI DSS in Europe

COSAC 2010

Firstly, there is the primary account number (PAN). This is the long number found on any payment card. The first six digits are the Bank Identification Number (BIN), and together with the other digits form a unique identifier that can be validated using the Luhn Formula . Luhn is not intended to be cryptographically secure, has been placed in the public domain and is intended to protect against accidental errors in transposition, not malicious attacks.
3

When stored with the PAN, the following are also considered cardholder data: Cardholder Name Expiration Date Service Code (Found on the magnetic strip, and indicates the acceptance requirements and limitations for the card) Sensitive Authentication Data consists of security-related information on the card, and includes: Card Verification Codes/Values Magnetic Card track data PINS PIN Blocks SAD must not be stored for any reason whatsoever once an authorisation code has been received for the transaction. Typically, unless payment terminals or POS systems are in a debug mode, these details will not be stored. However, since the CVC/CVV is used during a customer not present transaction to verify that the card is in possession of the customer, it is typically given over the phone to a customer service representative, or entered into a website at point of payment. This fragile 3 digit authentication token is typically one of the key pain points especially when one considers that many call centres will record their calls, which directly violates the requirement not to store SAD. There are many ways to ensure the security of protected storage data, including: Encryption ensuring that the cardholder is stored inside a data repository using strong encryption methods such as AES or 3DES, and that the keys are protected using good practice key management processes. It seems apparent however that this approach moves the issue of storing one sensitive data set which the end user organisation struggles with to... storing another sensitive data set (which the end user organisation then struggles with!)
4

3 http://en.wikipedia.org/wiki/Luhn_algorithm 4 ISO11568 mandates a set of principles for key management which Pin Entry Device (PED) vendors must comply with. These are: a) Keys [whose disclosure will effect multiple parties] shall only exist within a Tamper Resistant Security Module, or as full length components. b) Plaintext keys shall be maintained under dual control / split knowledge. c) Secret/private keys must be protected against disclosure. d) Secret/private keys shall be random. e) Keys shall only be used for their intended purpose. f) Systems shall detect the unauthorized use / modification of keys. g, h, i) Keys shall be changed before their use is compromised. j) Logical separation will be maintained between keys of different use. k) A previously compromised key shall not enable the determination of its replacement. l) Keys shall not be loaded into compromised devices. Now. This all appears fairly straight forward, but there are some simple errors that seem to occur all the time. Example of these errors are: Keys hard coded into applications (violates a, b, c, l, and probably f depending if the application is authenticated or not) Keys separated into halves, not components (eg 128 bit key separated into two 64 bit halves - violates a, and b) Key updates performed under the old key (violates e - using the key for two purposes - and k)

PCI DSS in Europe

COSAC 2010

Hashing using a strong cryptographic algorithm to ensure a one-way translation between the cardholder data and an identifier. Truncation removing digits from the cardholder data PAN. Up to the first six and last four digits may be retained, leading to the term 6*4. This option is simple for most merchants and greatly reduces the scope of PCI DSS, as 465943******4312 is in actuality no longer cardholder data! This method can meet resistance from internal fraud and finance officers who are used to having the entire card number. At time of writing, no precedent has been established in Europe whether the 6*4 identifier together with a transaction ID does uniquely identify a transaction.
5

Index tokens and pads many vendors are now offering a tokenisation service where the vendor undertakes to manage the storage of cardholder data, and provides the merchant with a token index to manipulate. Architecturally, this is a non-trivial service, as it must give extremely fast response times, great reliability, and must integrate with the existing enterprise architecture. Masking subtly different to Truncation, in that the change is to the displayed data. This is actually covered in requirement 3.3, the intent of which is to avert the risk of cardholder data being disclosed to those without a need-to-know. However, effective use of masking does not remove the requirement for safe cardholder storage. Requirement 3 is usually a source of great concern for merchants. The PCI SSC have taken the problem of data classification out of the hands of security architects in end-user organisations, and have not only classified the information they consider critical, but also laid down requirements for the usage of that information

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

The other side of the store-and-forward coin, is of course the transmission of cardholder data, which is covered in requirement 4. In essence, whenever cardholder data is sent over a network not in control of the merchant (or service provider) it must be protected using strong encryption. Since the merchant's internal retail network can normally be considered private by definition, then the requirement extends only to networks such as the internet. Requirement 4 does contain mandates regarding wireless. It prohibits weak encryption especially when deployed in wireless networks.

Maintain a Vulnerability Management Program Requirement 5: Use and regularly update anti-virus software
One would not expect this to be a challenge as commercially available solutions normally cover this in entirety, and the various control sub-requirements can easily be activated in most enterprise antivirus packages. However, right at the end is a requirement to ensure that centralised logging is in place as per the specifications of Requirement 10. This can up-tilt the other wise clean bill of health that many organisations expect to achieve in this area.

Keys formed from passphrases or using a non-secure PRNG (violates d) Keys used directly by PC applications (violates a) (Grateful thanks to the PCI Community at pcianswers.com for this input) 5 Not my credit card number.

PCI DSS in Europe

COSAC 2010

Requirement 6: Develop and maintain secure systems and applications

Upon encountering requirement 6, many organisations breathe a sigh of relief, pointing out that they do no software development whatsoever. Careful questioning however can reveal some important points which make PCI DSS requirement 6 something that all merchants and service providers must consider. 1.If you hire a third party to do your web development for you, then this development is under the scope of PCI. DSS requirement 6. The exception to this is if you purchase a commercially available off the shelf package (or software modules that are COTS) which if it is used for payment card processing, storage, or transmission can be validated by the vendor under the PADSS. In Europe, new payment application deployments must now be validated as PA-DSS compliant by the vendor, and merchants and service providers should see this as a positive move as they will have a degree of assurance that the application will help and not harm their PCI DSS compliance efforts. 2.If your web site stores, processes or transmits cardholder data, then it is in scope. Many organisations seek to remove their website from scope by using a payment service provider to process payments, as recommended by most banks and QSAs. However, if the dataflow of the card traverses the website then this still brings the website itself into scope, requiring proper software development lifecycles . Its also important to note that as many attacks are aimed at the application layer, PCI DSS recommends best practices such as OWASP, the Open Web Application Security Project, and specifically mentions frequently seen attack vectors such as SQL Injection, Cross Site Scripting, unvalidated input, Insecure configuration management, buffer overflows, improper error handling, and insecure storage.
6

3.Patch critical system vulnerabilities within thirty days, and others within three months. One of the guilty little secrets of the IT industry is that the most critical systems are the ones that rarely get patched. Complex ERP systems tend to be very picky regarding the underlying platforms that they operate on, and its a normal IT operations mandate to insist that critical machines should not be touched. This can be a major issue for patch managers, and frequently I've seen old operating systems running with exploitable backdoors that could lead to a total compromise of the system, which of course can mean the loss of cardholder data, and tough conversations following that with the bank. 4.Proper change control. If you can't control changes to your application, you aren't in control of the security. This means ensuring that developers do not have access to live systems, and this can expose other deficiencies in the software development lifecycle. 5.Proper testing. As far as PCI DSS is concerned, this means not using live cardholder data to test systems with. It also means not leaving the test accounts, code, and data on a live system . A problem with many European banks is that they are not always set up to provide end-to-end payment testing for live systems, which means it can be hard for that all-important go-live test to be effectively carried out without using a real payment card, which is prohibited under the PCI DSS.
7

6.Code reviews, Penetration testing, and Web Application Firewalls. The advice on this is a little conflicting, it seems to suggest that you can purchase a get-out-of-pen-testing-free web application firewall and then you're ready to go. Ignoring requirement 11 looming further down this paper, how will you know if your WAF is up to the job? The best idea is to get penetration testing if you consider your code may be high risk, find a security service provider that is capable of providing source code reviews and then your WAF will form a part of an informed, threat-aware security architecture. A WAF that is poorly configured is at best another piece of kit that requires
6 To save you money on expensive consultants, Microsoft have released an exemplar secure software development lifecycle, available at http://msdn.microsoft.com/en-us/library/ms995349.aspx . 7 How to worry your QSA: A fascinating example of this was the test manager who called me up to tell me that he was unable to buy petrol on the way home because he had been making a series of test payments and refunds all day on his personal credit card!

PCI DSS in Europe

COSAC 2010

management .
8

VISA Inc. has implemented a set of mandates for payment application security with deadlines as follows :
9

Phase Compliance Mandate Newly boarded merchants must not use known vulnerable payment applications, and VisaNet Processors (VNPs) and agents must not certify new payment applications to their platforms that are known vulnerable payment applications VNPs and agents must only certify new payment applications to their platforms that are PA-DSS-compliant Newly boarded Level 3 and 4 merchants must be PCI DSS compliant or use PADSS-compliant applications* VNPs and agents must decertify all vulnerable payment applications** Acquirers must ensure their merchants, VNPs and agents use only PA-DSS compliant applications

Effective Date

1/1/08

7/1/08

3 4 5

10/1/08 10/1/09 07/01/10

* In-house use only developed applications & stand-alone POS hardware terminals are not applicable ** VisaNet Processors (VNPs) and agents must decertify vulnerable payment applications within 12 months of identification

Of note is the last point. PA-DSS now has some edge to it, and if deploying a new payment application, it must be PA-DSS compliant. Existing applications will require an upgrade plan to move to a compliant version. I have seen many application vendors who see this as an opportunity to extract large upgrade fees from their customers. Since PA-DSS compliance is a requirement for the product to be of merchantable quality, then there is the opportunity to review vendor quality should this occur!

Implement Strong Access Control Measures Requirement 7: Restrict access to cardholder data by business need-toknow
Fairly simply, and in alignment with the PCI SSC taking the step of classifying what cardholder data is and why it is important, is the need-to-know restriction. It is a key principle of security that sensitive assets should remain confidential, and that there should be a way of controlling who can have access to them, whether that be read, write, or some combination. Again, this seemingly simple requirement can land an organisation in hot water. Most directorybased authorisation systems can be set up to control and limit access, however, when one looks at application permissions, it may be difficult to ensure that the application designers follow the access control rulesets set out by the architects. Even more important, software bugs can allow a determined attacker to elevate privilege and break the designed access control limitations.
10

The choices seem to be to progress down the road of full-fledged identity and access management solutions, or entrust each application with the responsibility of authorising users. The complexity of IAM appears to scale geometrically dependent on the number of applications and users relying upon it, and the reliability requirements are high.
8 More ways to worry your QSA: Tell them that no one really knows how to configure a WAF as the one guy that did was downsized months ago! 9 See http://visa.com/pabp for more details and related information 10 A while back I performed a penetration test of an oil exploration database with a well designed hierarchical authorisation system based on business rules and role within the company. However a little traffic sniffing followed by knocking on the door of the database and using some manufacturer's default credentials led me around the authorisation system, and into the data! Although this is not PCI DSS, its an example of how the simple controls in this standard can really uplift an organisation's security maturity.

PCI DSS in Europe

COSAC 2010

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

Along with the requirement to establish need-to-know, software quality, and effective monitoring and logging (in requirement 10, yet to come) we have to be able to establish who performed an action. This means establishing everyone with their own ID, and being to track back activities to the original user, including admin, root, or DBA privileged actions. PCI DSS goes into some detail about how to make a password secure, including expiry, password history, and complexity. Most organisations are pretty aware of this and can meet or exceed these requirements (although bear in mind that your applications performing their own authentication must support this as well). Where the complexity can lie is the unique requirement. I work with many clients who for the best of reasons have set up generic or shared accounts hotel front desks, finance operations, retail staff. PCI DSS explicitly forbids these types of accounts for user access.

Requirement 9: Restrict physical access to cardholder data

Most retailers are all to familiar with the risks of physical security the case of whisky that disappears out of the back door, expensive small items such as razor heads that escape in the pockets of dishonest staff and customers, and of course the risks that come with handling any amount of cash. The change again comes with the fact that cardholder data has a value to the attacker, and so must be protected. I've seen breaches happen to companies of various sizes because a printout containing cardholder data is left around, and then swiped by an unscrupulous person, which in the past has included security guards, cleaners as well as disaffected staff. Let's also pay attention to merchant till receipts. As most of us know, when we get our receipt from the checkout the card number on the copy we get is truncated typically the last 4 digits only are displayed. However, most merchant receipts contain the full PAN on display. Given that Gartner have estimated the cost of breach recovery at approximately $300 per item of cardholder lost (as opposed to $19 to protect it) then each of those merchant receipts can be thought of as a potential cheque made payable to the attacker and drawn on the account of the careless organisation! One of the odd effects of QSAs can come into play especially in this section. QSAs tend to have their preferences for particularly controls based on their career experience, and I recall meeting a new client who were frantically spending thousands on high-specification shredders that turned cardholder receipts into paper dust. Section 9 states that materials should be cross-cut shredded, incinerated or pulped so that they cannot be reconstructed. It's important that your QSA gives you advice that is neither under the compliance standard, or over it but exactly bang on what is required for compliance. Best practices that exceed that requirement can of course be suggested, however make sure you understand whether something is necessary, or a best-practice.

Regularly Monitor and Test Networks Requirement 10: Track and monitor all access to network resources and cardholder data
One of the realities is that PCI compliance does not assure invulnerability from a breach. Nor is it perfect security. PCI DSS is intended as a baseline, aimed at a very broad audience think of all the different retailers that are out there, from corner shops to global mega-markets, and not forgetting all the banks, payment providers, and other service providers that are also under the scope of the standard. So when a breach occurs, the banks ask the merchant to instruct an independent Qualified Forensic Investigator to understand what cardholder data has been lost, what is at risk, how it happened, and PCI DSS in Europe COSAC 2010 8

of course the PCI compliance status of the breached organisation at the time of the breach . One of the key tools that investigators need is to see clear audit trails, which is the purpose of requirement 10 to specify what good logging is, and how to protect the audit trails against tampering. It also specifies that PCI DSS compliant organisations should have a daily practice of reviewing the logs (which can be done by having an automated process produce an exception report which humans look at). A number of companies sell COTS logging systems, but the design of a really good centralised security incident event management (SIEM) system is one that I always enjoy as it involve integration, process analysis, incident response, and thorough network security reviews in order to make it fly.
11

Architecturally, SIEM should allow you to achieve the following: Identify which log sources and automated tools you can use during the analysis. Copy log records to a single location where you will be able to review them. Minimize noise by removing routine, repetitive log entries from view after confirming that they are benign. Determine whether you can rely on logs' time stamps; consider time zone differences. Focus on recent changes, failures, errors, status changes, access and administration events, and other events unusual for your environment. Go backwards in time from now to reconstruct actions after and before the incident. Correlate activities across different logs to get a comprehensive picture. Develop theories about what occurred; explore logs to confirm or disprove them. Server and workstation operating system logs Application logs (e.g., web server, database server) Security tool logs (e.g., anti-virus, change detection, intrusion detection/prevention system) Outbound proxy logs and end-user application logs

When selecting your SIEM make sure that it can pick up the following:

Also, remember to consider other, non-log sources for security events. SIEM is based on the ability to correlate events from multiple sources and build a timeline of activity for use in an incident response investigation. Research organisations such as Gartner classify SIEM technologies and provide the usual Magic Quadrant of who's who. Open Source solutions exist, including OSSEC and OSSIM.

Requirement 11: Regularly test security systems and processes

Because threat landscapes change over time, the PCI DSS requires that regular security testing of infrastructure and applications is carried out by suitably qualified professionals. This includes: 1.Internal and external vulnerability scans of the network. Scanning is a semi-automated activity that is designed to act as an early-warning to the security administrator. A good scan will detect missing patches, vendor default passwords, and weak configuration settings that could be exploited by an attacker. External scans must be performed by a PCI SSC accredited approved scanning vendor as described previously. Internal scans can be carried out by an internal employee who is suitably qualified in other words, someone who can configure and run the scans
11 The PCI SSC state that no breached organisation has been compliant at the time of breach. From my experience as a QFI this is true, however there's always a catch. Organisations who haven't implemented PCI DSS as business-asusual tend to find that they drift off signal once compliant, but I've personally investigated breaches where the QSA has left site within days how is that possible?

PCI DSS in Europe

COSAC 2010

appropriately, and can then analyse the results and recommend changes. 2.Perform application and network layer penetration tests at least yearly, and after a significant change in the cardholder data environment. In the words of the advert: Just Do It. Good quality penetration tests are a keystone of effectively measuring where your security threats lie, and how your security architecture responds and mitigates those threats. Penetration testing complements vulnerability scanning and does not replace it, and vice versa. 3.File integrity monitoring on critical system components. The purpose of this requirement is to ensure that if someone changes an important file thats not supposed to change, thats a big red flag as far as security is concerned. For example, WINLOGON.EXE should never change apart from approved patch updates from the manufacturer. If it does change, thats probably a sign that an attacker has modified it, and in this particular case is looking for usernames and passwords to capture! 4.Quarterly wireless scanning at every location to identify all wireless devices. Its fair to say that this requirement is the one that causes the most consternation and confusion among people I speak to. Usually the source of frustration is based on difficulty in understanding how hazardous a rogue wireless access point can be, and how easy it can be for a disgruntled insider to set one up. Wireless networking requires care and vigilance to manage properly, and should never be connected to the core cardholder data environment. Several notable breaches have occurred where attackers have penetrated a wireless LAN set up in a store, and have from the safety of a nearby location, have gone over the entire network. Oftentimes, these wireless networks are set up by well meaning store managers to fix a short term problem, for example, needing a concession stand out in the mall centre, or to save running cabling through a wall. Its important to realise that one can use wireless LANs to connect payment terminals, several vendors offer this as a solution to merchants, especially those in the hospitality industry. The way to make this work is to treat the wireless segment as an untrusted network, and therefore to overlay encryption between the payment point and the central server. Payment service provider solutions offer this now (mostly) and will undertake the task of key management, removing this burden from the merchant. Testing can cover requirements in section 6 (specifically section 6.6) as well as section 11. The penetration test process is well understood in most IT delivery organisations, with most organisations seeking to develop a combination of in-house skills augmented by external specialist providers.

Maintain an Information Security Policy Requirement 12: Maintain a policy that addresses information security
Although this section is entitled Policy, what it actually requires is effective governance and robust process control around the non-technical aspects of payment card security. Possibly the biggest item in this is the requirement to ensure that any service provider that stores, process or transmits cardholder data on your behalf needs to acknowledge their responsibility for protecting the cardholder data you entrust to them. Of course, your service provider will most likely have encountered this requirement before with other customers, however expect a drawn-out argument over liability and indemnity. You should also expect your service providers to be able to commit to PCI compliance, and to keep you informed of their compliant status. Other than that, requirement 12 states that you should know what is going on in your network. It mandates an incident response plan that is regularly updated (especially after an incident) and that you should ensure your employees are properly trained and that some vetting is performed. The British Standards Institute produce BS7858, which is a gold standard for commercial vetting. If you don't want the expense of a full BS7858 background check, then ensure that your HR department perform the following: CRB Basic Disclosure; PCI DSS in Europe COSAC 2010 10

Verifying previous 2 employment references; Credit Search; County Court Judgement Search; Insolvency Search; Bankruptcy Search which should satisfy the requirements of PCI DSS.

Misconceptions around PCI DSS

1. PCI DSS doesn't apply to us! It does. If you store, process or transmit payment cards, it applies to your business. 2. PCI DSS is confusing and non specific! PCI DSS is very specific on what controls must be put in place, what processes must be implemented, and what documentation is required. Furthermore it classifies the information that is relevant to PCI DSS compliance, and defines the applicability. 3. PCI DSS is too hard! PCI DSS is complex, and a lot of organisations find that the number of changes required involve resistance. However each step is relatively simple, and for an organisation that has looked at a mature security model such as ISO 27001 there will be very few surprises. 4. PCI DSS is irrelevant just look at all those breaches! No breached organisation was compliant at time of breach. One of the things that has come to bite organisations who are extremely cost focused is that the lowest-cost advice is not necessarily the best. If your QSA tells you they can audit your organisation in a few days, then tread carefully. 5. PCI DSS is achievable with a scan, and this bright box from my favourite vendor! Most organisations are deluged by vendors promising to take PCI DSS away. In reality, if you are a merchant you cannot remove yourself from PCI DSS. Anyone who tells you otherwise is selling snake oil. Scans are only useful if you act on the results, fix the problems, and then embed this practice into the way you run your IT systems. 6. PCI DSS is security! Sadly not. PCI DSS is baseline compliance for prevention of retail fraud. It doesn't protect against: Your secret recipe being stolen. (In one penetration test, I found that the server with the secret sauce recipe was wide open, but the payment channel was encrypted securely). Unscrupulous persons stealing money, stock, and other items. Non-PCI DSS data leaking out. PCI DSS doesn't care if your loyalty card customer details get published. You might!

7. PCI DSS if I get breached, it's the bank's problem! The operating contract that merchants sign with their bank includes a liability acceptance and loss waiver that means any losses due to a breach in your payment security is down to you. I have had organisations protest this even when I am on site investigating a breach!

PCI DSS in Europe

COSAC 2010

11

Compensating control ju-jitsu

Ju-jitsu is known as the gentle art or even the art of compliance depending on the translation. One of the risk-based factors in PCI DSS is when it is impossible to meet a particular compliance requirement. A compensating control must: meet the intent and rigor of the original PCI DSS requirement provide a similar level of defense as the original PCI DSS requirement be above and beyond other PCI DSS requirements be commensurate with the additional risk imposed by not adhering to the PCI DSS requirement

This means that compensating controls are not a get-out clause that allows an organisation to evade PCI DSS. Rather, a compensating control is likely to be more expensive in the long term, and requires regular reviews, and is used where there is a legitimate business or technical constraint .
12

Compensating controls must be approved first by the QSA and ultimately by the acquiring bank. It's rare that a compensating control will yield lower cost and effort than actually meeting the compliance requirement in the first place, therefore its a mistake to see them as a alternative to compliance. One of the Zeroth-Law points around compensating controls is at the start of a PCI programme, take an inventory of exactly what cardholder data you have. Then get rid of as much of it as possible. A robust removal project to minimise the cardholder data held within the organisation can dramatically reduce the costs of PCI DSS compliance. Many merchants are turning to payment service providers in an attempt to get cardholder data out of their network, adopting tokenisation of cardholder data and hopefully removing internal POS and payment systems from scope.

Breaches
A breach happens when cardholder data is lost from the merchant. One of the important points about ensuring that the agreement between merchant and service provider contains an assignment of liability is that otherwise the merchant will find that the buck literally stops with them when a breach occurs. When a breach is discovered by the card brands through their fraud systems, the acquiring bank is notified of a potential common point of purchase (CPP) originating merchant. The acquirer will then communicate with the merchant, and advise them of the issue. The different card brands currently have varying response programmes, however in 2011 this process will come under the governance of the PCI SSC. It is likely to take on the name used by VISA Europe, the Qualified Forensic Investigator, (QFI). QFIs are instructed to provide a report to the card brands on what data has been lost, what data is at risk, the method of the breach, and the PCI compliance status at time of breach. PCI compliant organisations qualify for Safe Harbor , in other words, are not liable for fines. It is at this point that the liabilities assumed by the QSA for accrediting the compliant organisation come into play!
13

One point of contention on the QFI involvement is that the report issued by the QFI is sent to the card brands as well as the breached organisation. The breached organisation is liable for the QFI's costs and this can frequently bring much heated discussion in a situation that is already fraught. Costs of a breach can be considerable, and can drive an organisation into bankruptcy. By an overwhelming factor, most breaches occur in small merchants (level 3 and 4) and the commonest breach channel is through the web.
12 Not I don't want to 13 Hopefully Safe Harbour in europe!

PCI DSS in Europe

COSAC 2010

12

MasterCard Specific Steps http://www.mastercard.com/us/merchant/support/rules.html From the link above, click on the link to the document entitled Security Rules and Procedures Merchant Edition. Section 10.3 deals with account data compromise events. Visa U.S.A. Specific Steps (Excerpted from Visa U.S.A. Cardholder Information Security Program (CISP), What To Do If Compromised, 12/2008) http://usa.visa.com/download/merchants/cisp_what_to_do_if_compromised.pdf Discover Card Specific Steps http://www.discovernetwork.com/fraudsecurity/databreach.html American Express Specific Steps https://www209.americanexpress.com/merchant/singlevoice/dsw/FrontServlet? request_type=dsw&pg_nm=merchinfo&ln=en&frm=US&tabbed=breach&intsearchct=33f0 77fdbc00675ecd1cc7d72735efbd1 An observed issue currently is a certain amount of role tension in the acquiring bank. The acquirer currently has ultimate liability for a breached merchant, and also has responsibility for instructing the qualified forensic investigator. Therefore it is potentially in the acquirer's interest for no issues to be found, or for the breach to be the fault of a compliant entity. Informal concerns have been expressed by card brands along these lines in the past.

Adoption of PCI DSS in Europe

PCI DSS covered organisations are now mostly aware of the requirements of PCI DSS. Typically this awareness is highest at the large level one organisations those processing more than 6 million card transactions a year. Level 4 merchants are typically least aware of the issue, and are also the ones most likely to be hit by a breach, particularly when they embark on e-commerce. Acquiring banks now make efforts to strongly encourage small merchants to use an accredited payment service provider. Across Europe, awareness is high in the UK, and falls off as one progresses across. Its important to recognise that PCI DSS is a global standard at a conference, I listened to an angry french IT manager cry Mais non at something that only applied to America but the reality is that this is a standard that applies everywhere. The governance mechanism is through transferrable contract liability, passing from the card brand, through the acquirer and subsequent processors, and eventually to the merchant. Although the card brands hold their acquirers as finally and ultimately liable, merchants can find themselves exposed at the point of a breach. An important point to note is that where a merchant outsources part of their payment process to a third party, contractual language must reflect a liability shift to match the payment process. One factor that may improve adoption of PCI DSS is if more public disclosure is made of breaches in similar fashion to the public disclosures found in some states of the USA. This provides impetus to the banks and merchant organisations to safeguard against reputation risk as well as financial loss.

PCI DSS in Europe

COSAC 2010

13

What to expect from the QSA

The role of the QSA is to assess the organisation for compliance with the PCI DSS. Frequently QSAs are asked to give advice to organisations on what is required to achieve compliance and other related information security topics. Putting it charitably, the quality of advice given by QSA companies is variable. Common concerns expressed include: Lack of ability to translate technical vulnerabilities to business risk Lack of experience in assessment Individual QSA's over-emphasising favourite technical measures which do not strictly meet the compliance requirements QSA's not providing on-site assessments, instead using mostly client-provided assertions and remote interviews. It's important that when a QSA gives advice, they are operating from a position of knowledge not only in the information security domain, but also what will work for the client. You should expect your QSA to be able to interpret the PCI DSS and explain its applicability to your organisation. Also, you should expect your QSA to be ready to interface with your bank and participate in the update process to ensure your bank understand and support your progress toward compliance. In addition to domain expertise in the various sections of the standard, your QSA should be able to assist you in structuring the remediation programme and moving from the breakfix cycle into operational support and maintenance mode.

Conclusion
PCI DSS 2.0 is on the horizon, although the PCI SSC is keeping it's cards close to their chest, a statement has been made that this new iteration of the standard will be evolutionary, and seek to build acceptance and clarify uncertainty within organisations. We can expect to see the following changes: 1. Clarify processes and increase flexibility for cryptographic key changes, retired or replaced keys, and use of split control and dual knowledge. 2. Apply a risk based approach for addressing vulnerabilities. 3. Merge requirement 6.3.1 into 6.5 to eliminate redundancy for secure coding for internal and Web-facing applications. Include examples of additional secure coding standards, such as CWE and CERT. 4. Update requirement to allow business justification for copy, move, and storage of CHD during remote access. PCI DSS is achievable, however to many organisations it looks like an intense task. Of benefit is a robust structured programme with the proper executive backing. I have never seen a compliance effort succeed that did not have the finance director (or equivalent) making a firm, clear statement that achieving compliance is necessary to the organisations survival. With the availability of security architectures such as SABSA, PCI DSS should be a relatively straightforward challenge. For ISO2700x aligned organisations, very little will be in the PCI DSS that will be unfamiliar. It can be complex and multi-part, but by careful analysis, systematic execution of remediation activity, and a well-informed structured assessment by the QSA, its something thats achievable and can lead to a step-change in the compliant organisations security maturity.

PCI DSS in Europe

COSAC 2010

14