23

A hypothetical online store that accepts credit card payment will have to be PCI compliant because it receives (transmit), process and possibly store credit card numbers.

But the client's web browser is also transmitting a credit card number, albeit on a secure connection, but after receiving in plain text from the keyboard.

We can't make every browser out there PCI compliant, but I can't find any reference in the specification.

Where is it written that a client's web browser need not be PCI compliant ?

Mark Davidson
  • 9,367
  • 6
  • 43
  • 61
ixe013
  • 1,912
  • 15
  • 20

4 Answers4

20

Well, first, what is written is the following: payment card companies are requiring merchants to be PCI-DSS compliant. PCI-DSS does not apply to anybody who doesn't process credit card transactions. The DSS requirements specify access control, logging, etc. None of this is applicable to a cardholder.

Clients do not have the same contracts as merchants. There is no benefit in trying to log activity on a client machine. Individual card numbers are likely to be stolen in many places, and the cost / benefit on forensic analysis of one person's computer for their one lost credit card is somewhere below sane. Finally, people just won't accept that. If using a credit card is too hard, card issuers will see decreased volume.

Jeff Ferland
  • 38,090
  • 9
  • 93
  • 171
  • Do you have any reference (e.g. from PCI counsil site) for you answer? Thanks D –  Mar 12 '12 at 16:37
  • @DVella I don't know quite where to point you, but I'd start at https://www.pcisecuritystandards.org/merchants/how_to_be_compliant.php. Since the very nature of PCI-DSS is that it applies to merchants, there's really not a section for clients. When you get your credit card, you don't sign on to PCI-DSS requirements. When you get your merchant account, you do. – Jeff Ferland Mar 12 '12 at 19:52
  • @ Jeff - My point is that I can't find a reference that says that as a company you don't need to log activity at client PCs e.g. when a client sees his credit card number (to explain better - our company offers virtual VISA and when you login to the client portal of our company the credit card is not visible immediately and you have to press a button to view the card number) –  Mar 13 '12 at 09:40
13

This is a classic scoping problem with compliance standards. Hold the merchant fully accountable -- but completely negate all of their efforts if the merchant's customer didn't protect their browsers.

However, what does remain questionable for scoping is if the merchant has CSR reps or employees/contractors/consultants of any kind (back-office, via business intelligence, CRM, accounting, officers, or otherwise) using a browser or other app to access payment card data.

I have heard that there is an exclusion for merchant elected individuals who access the cardholder data in the same way that a customer would -- however this is up to the QSA (the PCI DSS assessor) to decide: i.e. it is their discretion.

In order to prove that the above information is accurate, allow me to cite Gene Kim's PCI Scoping work, which in a series of slides -- he discusses using IIA's (responsible for COSO) GAIT-R for compliance "principles" identification versus "controls" identification (of which PCI DSS is heavy with). This is classically described as "The Spirit of the Law" versus "The Letter of the Law" in criminal/civil justice and legal reformation acts since the history of mankind.

In slides 35 and 37 of 2010 07 BSidesLV Mobilizing The PCI Resistance 1c, it is clear that:

  1. Category 3 devices are outside of PCI DSS scope, while Category 2 and 1 devices are in PCI DSS scope
  2. Devices that transmit CHD, are not able to decrypt the CHD, and are also not connected via local physical/virtual network segment to a Category 1 device CAN BE CONSIDERED as either a Category 2A, 2B, 2C, or even a Category 3 device
  3. According to the scoping, the customer (or those who transmit the CHD exactly like a customer) is considered a Category 3 device (and thus out of PCI DSS scope). The trick here is to make sure that the CSR rep (or other merchant employee/contractor/consultant) is not also violating any other scoping workflow as dictated in slide 37, such as caching CHD via the browser (or proxy, application-layer-gateway, etc) or saving the CHD in browser HTML-Form autocomplete functionality
  4. I honestly feel that you need to owe me a beer for answering this
Kalamane
  • 103
  • 3
atdre
  • 18,885
  • 6
  • 58
  • 107
  • 1
    So technically my desktop credit card processing application is out of scope, see:http://stackoverflow.com/questions/8511084/is-my-desktop-app-in-scope-for-pci-certification/8519255#8519255 – ATL_DEV Dec 16 '11 at 02:31
6

This has already been answered sufficiently, but I'll rephrase the same thing:

PCI is not the law, it's a contract between an acquirer (credit card company) and a merchant. This means that it cannot enforce any limitations on the customer, as there is no (binding) contract that could be used to require this. Hence, client web browsers get a free pass.

However, this is important, if the merchant being audited owns the machines where the web browsers are running - for example if some operations are done by customers using the merchant's computers at a store - they are a part of PCI scope. They do get some leeway if the risk they present is low, but that is for the auditor to decide case by case.

So, to reiterate, the only reason why client web browsers are not a part of PCI scope for the merchant is that the merchant can not exert any control over them. If it can, they become a part of the scope.

Nakedible
  • 4,501
  • 4
  • 25
  • 22
-2

I know this is not a direct answer, but I think this needs to get brought up: the general idea is that your security model should never rely on the security of the client, as the client might be malicious, hacked, virused, modified, outdated, or misconfigured... The server should check for the client being secure (following the security protocols), and if it isn't, it should refuse to serve.

Marcin
  • 2,508
  • 1
  • 15
  • 14
  • I think you might have missed the point of the question. The implicit point is that the security of credit card transactions *does* rely upon the security of the client. The server *can not* check that the client is secure or free of malware; that is simply not possible. – D.W. Aug 02 '11 at 19:52
  • So if you cannot verify the security condition of the client, then the protocol needs to rely on something else: something you have (the card), and something you know (pin number?). The worst the owned client can do is siphon off the PIN, and remember the card number. I don't know anything about card processing, but is having the number of the card equivalent of having the card, or is there something that the physical card provides beyond the number? This is more of a protocol design problem, the compliance is just a regulation trying to express secure protocol design, isn't it? – Marcin Aug 03 '11 at 01:23
  • 1
    If you are processing payment cards, you can't avoid having to deal with card numbers. PCI DSS is a set of requirements whose only concern is to keep card numbers (and card holder data) safe. It is stupid design by credit card companies that card numbers are security sensitive even for chip-and-pin cards, but it's a choice they have made - no one can affect that now. That makes client computers where the user types in a card number security sensitive and there's no way around that by any sort of design that can be done now. – Nakedible Aug 03 '11 at 05:25
  • @Marcin, the point you keep missing is: PCI DSS does not actually require any of those requirements you think would be logical to impose. No, PCI DSS is not trying to express secure protocol design. The protocol (using credit card numbers) is fixed and not up for question/modification. PCI DSS is a compliance standard, designed by credit card companies and intended to mitigate some of the risks inherent in credit card purchases. – D.W. Aug 03 '11 at 06:42