2

Supposing I had an office full of call centre operators, who sometimes update customers payment details by way of receiving these over the phone and then keying them into a secure web application, which stores the data securely in the "real" CDE. The data is never stored on the call centre operator's PC, nor is it transmitted in an unencrypted fashion.

Per the title, does this mean that those workstations fall into the scope of the CDE per the PCI-DSS definition?

EDIT: Clarification, the web application is an internal application. It is not exposed over public or open networks.

Nemec
  • 43
  • 1
  • 9
  • 1
    Without question. Think about it this way: unencrypted payment card info is input into the devices and is held resident in its memory (if only for brief moments) before the data is encrypted and sent off to the processor. What that describes is exactly how POS machines at retailers mostly operate, too. It's just that for you the card data is being input via human beings with keyboards instead of via card readers. Now, there's obviously a card-not-present vs. card-present distinction as well . But that doesn't actually matter here; a PC that sees & processes raw PAN info is within scope. – mostlyinformed Dec 13 '16 at 03:38
  • +1 @halfinformed, remember also that the Target breach involved malware that stripped the card info out of memory _on dedicated devices, much less PCs_. – gowenfawr Dec 13 '16 at 03:43

4 Answers4

2

The entire workstation and indeed the entire call centre and possibly the entire network could be in scope for PCI DSS.

No need for a keylogger, a piece of paper and a pencil is enough to make the operator a risk. Then there's the telephony to the operator, the patches required to maintain the general security of the workstation.

There are commercial solutions out there that mitigate the risk and reduce the effort of compliance by either proxying all calls or otherwise routing them through a secure telephony centre.

ste-fu
  • 1,092
  • 6
  • 9
1

Yes, those machines would be in the CDE; however, with appropriate segmentation they would be addressed by the SAQ C-VT. Merchants who fall under the SAQ ("Self-Assessment Questionnaire") C-VT ("Virtual Terminal") are subject to a reduced number of PCI DSS requirements, due to their limited scope.

SAQ C-VT has been developed to address requirements applicable to merchants who process cardholder data only via isolated virtual payment terminals on a personal computer connected to the Internet.

A virtual payment terminal is web-browser-based access to an acquirer, processor, or third-party service provider website to authorize payment card transactions, where the merchant manually enters payment card data via a securely connected web browser.

and

SAQ C-VT merchants process cardholder data only via a virtual payment terminal and do not store cardholder data on any computer system. These virtual terminals are connected to the Internet to access a third party that hosts the virtual terminal payment-processing function. This third party may be a processor, acquirer, or other third-party service provider who stores, processes, and/or transmits cardholder data to authorize and/or settle merchants’ virtual terminal payment transactions.

("C" in "C-VT" has no semantic meaning; the SAQs are A/B/C/D in increasing breadth of requirements. D is essentially the full DSS; A is a mere score of individual items; C falls in between.)

gowenfawr
  • 71,975
  • 17
  • 161
  • 198
  • The use case for SAQ C-VT is a single non-networked PC to connect to a virtual terminal for payment processing. While it may be possible to configure a number of systems within a call centre to suit the eligibility criteria, the systems would then become difficult to support in terms of standardisation, updates etc. – AndyMac Dec 13 '16 at 14:32
  • C-VT is not limited to a "single" PC; businesses with call centers which enter card transactions via VT are a common example. Per the definition the VT browser clients are explicitly "on a personal computer connected to the Internet" and not non-networked. And if you read the applicable DSS items in C-VT, the "standardisation, updates etc." are required to be addressed per DSS 5.1-3 and 6.1-2 for C-VT merchants. – gowenfawr Dec 13 '16 at 14:47
  • C-VT includes eligibility criteria requiring the system be isolated and not connected to other systems. This should preclude use of connected, centralised systems for authentication, anti-virus, WSUS etc. Perhaps 'single' was the incorrect word above, rather it be 'non-networked' per your comment. – AndyMac Dec 13 '16 at 14:54
  • @AndyMac, IANAQSA but "isolated and not connected to other systems" is generally interpreted as "...except those necessary to provide necessary functionality such as login, av, and updates." "Isolated" is designed to mean that the PCs used as VTs aren't also used for accessing random corporate systems, file servers, web proxies that grant Internet access, etc. etc. – gowenfawr Dec 13 '16 at 14:58
  • that interpretation would appear to support use of SAQ D in a call centre environment using supporting infrastructure for those services. – AndyMac Dec 13 '16 at 15:03
  • This is pretty much the way that I am leaning on this one. In my reading of the documentation I got the impression that any system handling cardholder data in any fashion was part of the CDE, but others in the company seem to feel differently. We've posed the question to our QSA to get their thoughts on it, but I think @gowenfawr might be on the money here. – Nemec Dec 13 '16 at 22:47
0

You could look at this 2 ways I would suspect.

Firstly, assuming that the website is secure, as you suggest, with the appropriate SSL configured, and employs proper account management functionality, then you make the argument that the transmission of the card data is encrypted between the source browser and the server so no further investigation in to the users PC is required.

On the other hand, if the user has a keylogger on their PC, then all other security measures may be compromised.

Under the first assumption, if you had a front end that allowed clients to update their own credit card details on record, you would have to include every clients PC into the CDE. Of course, you would expect that a clients login would only have access to their own data, not all data.

I would make the argument that no, it is not part of the CDE.

Simon Holman
  • 9
  • 1
  • Good answer (+1). I'd only add that although not PCI-DSS required, it may be useful to promote the security of an user's machine. For example, warn (but not forbid access) users that are using outdated browsers and inform users of AV solutions. – grochmal Dec 13 '16 at 00:35
  • I agree. This should be covered under the various IT and Security policies that are a requirement of PCI anyway. – Simon Holman Dec 13 '16 at 00:49
  • "PCI DSS also applies to **all** other entities that store, process or **transmit cardholder data (CHD)**" and "The cardholder data environment (CDE) is comprised of people, processes and technologies that store, process, or **transmit cardholder data**", from DSS 3.2. There's cardholder data; it's transmitted; it's part of the CDE. – gowenfawr Dec 13 '16 at 03:29
  • @gowenfawr Precisely. – mostlyinformed Dec 13 '16 at 03:41
  • @grochmal From reading the question my impression was that the PC's having card data input were not those of end customers of OP's company, but actually belonged to OP's company (or a contractor for OP's company) and are sitting in a call center. The word "user" as it was used in the question might, admittedly, be a bit confusing. But that was my read. And I think whether the machine is on the customer's side or the company's side is crucially important here. – mostlyinformed Dec 13 '16 at 04:00
  • @mostlyinformed Is correct, I am referring to our internal users and PCs, not the customer's systems. I have amended the question to clarify this. – Nemec Dec 13 '16 at 22:45
0

the workstations are in scope unless you implemented some sort of iframe solution to get them out.

any way the council has provided a supplementary in this issue at the following link : https://www.pcisecuritystandards.org/documents/protecting_telephone-based_payment_card_data.pdf

BokerTov
  • 539
  • 4
  • 10