Educause Security Discussion mailing list archives

Re: PCI DSS - VDI (vmware) SAQ-C-VT question


From: John Ladwig <John.Ladwig () SO MNSCU EDU>
Date: Tue, 7 May 2013 19:37:35 +0000

A payment application vendor saying that a given product/solution is DSS-compliant, and a QSA who disagrees.  Imagine 
that.

Not seeing a P2PE validation listing for Square yet...

https://www.pcisecuritystandards.org/approved_companies_providers/validated_p2pe_solutions.php
PCI SSC does not currently have any Validated P2PE Solutions. Please check back later.

https://www.pcisecuritystandards.org/approved_companies_providers/validated_p2pe_applications.php
PCI SSC does not currently have any Validated P2PE Applications. Please check back later.

Square's application is not listed as a validated payment application:
  https://www.pcisecuritystandards.org/approved_companies_providers/validated_payment_applications.php?agree=true

Square's processing is, however, a listed Payment Gateway/Switch, and payment processor/Internet:
  http://www.visa.com/splisting/searchGrsp.do

I can see what the QSA is basing their opinion on.

   -jml

From: The EDUCAUSE Security Constituent Group Listserv [mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of Everett, 
Alex D
Sent: Tuesday, May 07, 2013 2:22 PM
To: SECURITY () LISTSERV EDUCAUSE EDU
Subject: Re: [SECURITY] PCI DSS - VDI (vmware) SAQ-C-VT question


One small point on the last item, I believe the QSA is wrong about Square.
See https://squareup.com/reader

Sincerely,

Alex Everett
University of North Carolina
IT Security Engineer

On May 7, 2013, at 3:16 PM, Jessica Odom <odom () LCLARK EDU<mailto:odom () LCLARK EDU>>
 wrote:

I'm in a similar situation and am working through this same scenario.

1) We are considering using a separate VMware VDI which users
connect to via dedicated PCoIP devices.  Connecting via general
desktop would not be allowed.   Comments?

We're going to do this too and are looking using thin clients/terminals, so there wouldn't be another (local) OS 
involved.


2) With respect to the VDI solution, IF we allowed users to use
their general use desktop, is there a way to configure their
desktop such that it would NOT be part of the CDE?  For the
record the desktops would be Windows 7 machines.

I'm not a VDI expert, but if your VDI environment can reside on the cardholder network (with ACLs and/or firewall 
between the network segments) and the other on a non-CDE network, then you would meet the requirements I would think.  
I don't know if that's possible to do, however.

3) What's your solution for this case?

Since I have lost my local VDI expert (we're hiring -- https://jobs.lclark.edu/postings/3571), I will likely error on 
the KISS side and use thin clients; however this will not work for my business office staff for whom I wish to tighten 
controls for sensitive work.

I know, I know, if we would just listen to our users and allow
'square' all would be OK :)

My QSA reports that devices that use the audio jack for the data (ie: Square) are not PCI compliant.  That type 
converts sound to data and writes it (ie: PAN) in plain text to the device.  I haven't validated this, but I've been 
told to pick the ones that use the data port (ie: Verifone).


Good luck!
Jess


Thanks in advance!
odk
--
NOTE: ASU ITS will NEVER ask you for your password in an email!
Oscar D. Knight                           knightod at appstate dot edu
ITS                                                Voice: 828-262-6946
Appalachian State University, Boone, NC 28608        FAX: 828-262-2236



--
Jessica Odom, GIAC GSEC, CISSP
Information Security Officer
Lewis & Clark | go.lclark.edu/it<http://go.lclark.edu/it>


Current thread: