|
This is something that has bugged me for some time. What is a perimeter? Does this mean a pvlan isnt good enough? What about a transparent firewall? Or kernel driver firewalls. Its all silliness to me and far too arbitrary as to the number of rounds on the fractal equation (ie levels of depth on the infinite self-referencing tree of fissures in a mandlebrot set). One minute they are telling you password length the next they say virtually nothing about the personnel background checks to make to avoiding the employmwnt of easily subverted persons. Also the scope decision is far too binary. An out of scope oobm seems really vulnerable in many cases but it is left out. Bind that daemon to a different interface and holy hell reigns down upon you. As if the user group accessing the sshd in band is any different than when its bound to an oobm interface. Similarly this puzzles me: a large SAN where the NAS head is in, but the FC switches and shared disk array is not. Or the backup system where the cryptotext and keys end up in the same offsite tape shipment... For many years I wanted physical to line up with logical L3 and that to line up with administrative domains. Then vlans came along and shared data centre hosting (vs colo) where nobody would pay for separate rackspace by the cabinet (not when it was rolled out anyhow). Network and hosting guys told me i was smoking rope as these compartmentalizations ruin the business case for hosting providers and outsourcers. Of course there are no logs for who is accessing the cabinet above and below your host. Then cloud comes along, and the variance for just who has access to what just gets higher, and the explanations, more silly. If I am hosting a CDE in a virtual environment, and that bastion host is segmented via L3 in the network driver stack, it has nothing to do with L3. So in the ultimate extreme now one is starting to see the same chassis with dozens of workloads on it. I haven't read the latest virtualization guidance of PCI but it sure seems like these QSA guys are really playing games with interpretations of this regulation. Some will let you play the scope game to avoid liabilities, others leverage the weight of the standard to secure as many systems as possible. After 17 years designing it i just want to kick it all down the street and be one of the guys who points out all thats wrong all the time and leave it be someone else's problem to design and fix it. W Sent from my BlackBerry® PlayBook⢠www.blackberry.com From: "Ron Gula" <[email protected]> To: "[email protected]" <[email protected]>, "PaulDotCom Security" <PaulDotCom Security> Sent: February 15, 2013 7:42 AM Subject: Re: [Pauldotcom] Limiting Scope of PCI review Tenable does a lot of ASV PCI scanning these days. One thing that surprised
me when we started doing this a few years ago was that anything on your
perimeter is considered in scope. You could have your ecom server sitting
next to a support portal one IP address off which has no physical, virtual,
shared backend connectivity and it will still be in scope.
I agree with the other comments about limiting scope internally. If you haven't
done it yet, you might want to do a Nessus scan looking for credit card data
on the inside of your network just to see where anything may be at.
Ron
From: Kevin <[email protected]>
Reply-To: "[email protected]" <[email protected]>, PaulDotCom List <[email protected]> Date: Thursday, February 14, 2013 11:50 AM To: PaulDotCom List <[email protected]> Subject: [Pauldotcom] Limiting Scope of PCI review Hi all -
I know this isn't a PCI focused list, but I'm hoping it's PCI tolerant and someone can point me in the right direction.
We are preparing to *begin* taking credit card payments from our customers, and since we've never dealt with them before, I'm kinda new to the whole PCI-DSS thing.
After reading through all the 'stuff' on the pci site, it seems to me like it would make sense to limit the number of desktops, servers, routers, etc that are "in scope". The PCI QSA vendors don't seem to want to help me limit the scope - it's almost
as if they make more $$ from having my entire network in scope... From reading the different SAQ's, it seems like we're already doing all the stuff they are asking for, I just want to limit our risk.
Currently my (4) cashier workstations are spread across my 2 client networks, and have full access to typical client facing network resources (exchange, sharepoint, various other non-customer service related web apps, etc) The CC payment processor we are
going to use has recommended installing a USB swipe reader hooked to some sort of virtual terminal (active x based) on each of the 4 PC's, and frankly that gives me the heebe-geebes.
Our finance director is pushing to go live sooner than later.
What types of techniques can be used to limit the scope? Am I overly worried about this? If I go live now and reduce scope later, would my entire network be in scope for this first year?
Thanks in advance for any pointers you can offer.
Kevin
|
_______________________________________________ Pauldotcom mailing list [email protected] http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom Main Web Site: http://pauldotcom.com
_______________________________________________ Pauldotcom mailing list [email protected] http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom Main Web Site: http://pauldotcom.com
