Anyong done PCI-DSS Compliance?

24 views
Skip to first unread message

Damien Gardner Jnr

unread,
Mar 2, 2012, 2:50:15 PM3/2/12
to 2600-au...@googlegroups.com
Hi Folks,

I'm currently doing a PCI assessment (they're small enough that they can
do a self-assessment..) for a client, and finding myself asking
questions of the standard, which I can't really find answered on
google... Wondering if anyone else has done them, who might have hit
some of the same problems...

This client has staff occasionally taking billing details over the
phone, and entering them into their billing portal for the clients who
don't want to use their credit cards 'over the internet' (Go figure,
they still end up 'over the internet' anyway, lol!) - which from the
wording of the DSS extends the CDE to staff workstations. Which then
from the DSS also means that we have to have a specific business case
for any holes we open through the firewall outbound from their
workstations - so no facebook, MSN, Skype, etc, as they're not 'needed'
for the business.. Which I can see going over like a lead balloon! I
can see that they could have a couple of PC's dedicated to being used
for billing-entry purposes - then we could keep the 'normal' staff
machines out of the defined CDE, and just have staff put the customer on
hold, walk over to that PC, take their details, then put them on hold
again, and go back to their own PC.. But that seems like a bit of
rigmarole just to keep the staff happy and able to browse facebook ;)

I'm also a bit curious about what level of 'firewall' is needed for
these PC's - they have a few offices around the world, some of which are
in 'serviced' office complexes - so network is provided by the office
provider, and the client just supplies their PC's - and they quite
explicitly *do not* allow the clients to put in their own networking
hardware to segregate themselves from the managed network there.. I'm
hoping we can get away with a locked down windows firewall in those
instances, or it's going to mean them either MOVING offices, or
transferring the customer to another country for billing processing! Ick!

Cheers,

DG

--
Damien Gardner Jnr
VK2TDG. Dip EE. GradIEAust
vk2...@gmail.com - http://www.rendrag.net/
--
We rode on the winds of the rising storm,
We ran to the sounds of thunder.
We danced among the lightning bolts,
and tore the world asunder

Troy Rose

unread,
Mar 4, 2012, 5:23:06 AM3/4/12
to 2600-au...@googlegroups.com
Hi Damien,

I have recently worked at such an environment where billing was done over the phone for customer transactions. 

The approach taken for locking down PCs was to have separate PCs for shared internet access - which was on a completely seperate DSL link, and was allowed to access (pretty much) any internet site and use (pretty much) any application. It was basically an internet kiosk, and it was not connected in any way to the rest of the network, and did not allow USB storage devices access to it.

The general user PCs where then locked down with minimal applications and restrictions on everything (except what was allowed for business).

This kept users (reasonably) happy, and allowed them to work and play but in very distinct zones. I thought this was a pretty good balance. At the end of the day you might even end up boosting productivity!

As for firewalls in use, yes, PCI-DSS is pretty vague on any details. I suggest have a look at the risks that you could be exposed to and come up with a mitigation strategy for each. If the risk is acceptable to run a Windows firewall, then go for it. Another thing that was done in my previous environment was to enforce the use of IPSEC over LAN connections to encrypt all traffic over the wire regardless of its source or destination.


Troy
--
------------------------------------------------------------
You received this message because you are subscribed to the "2600 Australia" group.
To post, send email to: 2600-australia@googlegroups.com
To subscribe, send email to: 2600-australia+subscribe@googlegroups.com
For 2600 monthly meetings, visit http://www.2600.org.au
For more options, visit this group at http://groups.google.com/group/2600-australia
To unsubscribe, send email to: 2600-australia+unsubscribe@googlegroups.com
Disclaimer: Comments to this mailing list are owned by the poster
------------------------------------------------------------

Jason Xiros

unread,
Mar 4, 2012, 6:08:13 PM3/4/12
to 2600-au...@googlegroups.com

Hi Damien / Troy,

I have consulted to several PCI-compliant contact centres... if you turn this problem on its head, what you actually need to achieve is  logical  (not necessarily physical) segregation of the PCI-compliant applications and data.

Two options are - 

(1) Contain all PCI-compliant applications within a virtual machine, thin client, or terminal-services environment.

(2) Contain all non-PCI-compliant applications as above.


I have seen both approaches deployed successfully.


Kind regards,

Jason



To post, send email to: 2600-au...@googlegroups.com
To subscribe, send email to: 2600-austral...@googlegroups.com

For 2600 monthly meetings, visit http://www.2600.org.au
For more options, visit this group at http://groups.google.com/group/2600-australia
To unsubscribe, send email to: 2600-australi...@googlegroups.com

Troy Rose

unread,
Mar 4, 2012, 7:08:28 PM3/4/12
to 2600-au...@googlegroups.com
Hi,

Yes, definitely. If you have VDI or thin client (Citrix or otherwise) then this would give you logical separation.

However, even with the use of virtualisation technology, the PCI security Standards Council organisation strongly recommends physical separation of virtual machines of mixed security levels on the same physical hypervisor:


I guess I'm not only concerned with PCI-DSS. I'm concerned with security in general as well.

My further concern is that even from a general security approach is that if you have a untrusted -zone physical machine connecting to a trusted PCI thin app environment, is that really the best approach to ensuring the security of your data? 

If the untrusted physical machine is compromised (say, your favourite site starts serving malware, or you are the victim of a spear phishing attack or something), then even though you have an uber secure virtual desktop or thin client app, you are still running that on a compromised host, and it would be possible for the VM (app or desktop) and data within to be compromised as a result.

Also, you are introducing more complexity into your environment, and, as mentioned in the document above, your hypervisor becomes a new vector for attack.

So, there are a couple of pros and cons there to each approach.

If it were me,  I would look at saving costs, improving productivity and improving security by deployment of a hardened linux desktop environment as the "trusted" computer (with minimal apps etc) - I mean, it sounds like you might only need a web browser, and then either go virtual desktop / thin app or deploy an internet kiosk. But maybe that's cause I'm biased towards Linux heh, and personally, when it comes to securing data, I don't really give a rats ars* about users who complain to me they can't get their latest facebook update. Seriously, you don't come to work to use facebook, you come to work to *ahem* do work.

Martin Barry

unread,
Mar 6, 2012, 11:10:37 AM3/6/12
to 2600-au...@googlegroups.com
$quoted_author = "Jason Xiros" ;

>
> I have consulted to several PCI-compliant contact centres... if you turn
> this problem on its head, what you actually need to achieve is logical
> (not necessarily physical) segregation of the PCI-compliant applications
> and data.
>
> Two options are -
>
> (1) Contain all PCI-compliant applications within a virtual machine, thin
> client, or terminal-services environment.

How does that get past the audit? Using a low security desktop or device to
access a high security one brings to mind problems with key-logging trojans
and similar nasties.


> (2) Contain all non-PCI-compliant applications as above.

That sounds like the tidier approach.

cheers
Marty

Damien Gardner Jnr

unread,
Apr 13, 2012, 2:22:36 AM4/13/12
to 2600-au...@googlegroups.com
So following on from a while back.. We're now a good way into the
process, have ended up securing a QSA as a consultant, which is proving
helpful.. The customers Call Center is out of scope, as they're only
handling credit cards in the same interface the end-user would be if
they were using the internet anyway..

The only place we're having troubles, is when a customer emails their
new credit card details for recurring payments.. It doesn't happen
often, the client doesn't promote to customers that they can do that -
but it does happen.. I'm being told that they need to ensure that this
*doesn't* happen.. - But the question we can't answer is *HOW* do you
stop third parties from sending you their credit card details?? Has
anyone else handled this?

Patrick Webster

unread,
Apr 13, 2012, 2:46:16 AM4/13/12
to 2600-au...@googlegroups.com
snort signature?
Reply all
Reply to author
Forward
0 new messages