Re: PCI DSS compliance challenges

[Brad Judy <win-hied () BRADJUDY COM>]

Gary,

I think this info from the PCI Scanning Procedures document answers your
questions.  (Note this doc is for 1.1 and hasn't been updated for 1.2 yet,
but I don't expect this section will change.)

----quote-----

In some instances, companies may have a large number of IP addresses
available while only using a small number for card acceptance or processing.
In these cases,
scan vendors can help merchants and service providers define the appropriate
scope of the scan required to comply with the PCI. In general, the following
segmentation methods can be used to reduce the scope of the PCI Security
Scan.

-Providing physical segmentation between the segment handling cardholder
data and other segments
-Employing appropriate logical segmentation where traffic is prohibited
between the segment or network handling cardholder data and other networks
or segments

Merchants and service providers have the ultimate responsibility for
defining the scope of their PCI Security Scan, though they may seek
expertise from
ASVs for help. If an account data compromise occurs via an IP address or
component not included in the scan, the merchant or service provider is
responsible

----end quote----

They essentially define the "network" scope as devices that can contact a
system that handles card holder data in an unrestricted way.  As they note,
this scope decision lies in the organization's hands, along with the
responsibility.  Place any card data handling systems in a separate network
segment with restrictive firewall rules and count the devices in that
network segment as in-scope for compliance.

I would expect the smaller volume organizations not to process card data on
the network on-site (e.g. using swipe-and-dials and/or outsourced card
handling like Authorize.net).

I would encourage everyone to include non-card processing items involved in
the transaction (like stand-alone shopping cart systems leverage outsourced
transaction processing) as in-scope as well.  PCIDSS is about protecting
card holder data being given to the intended organization.  If you don't
protect a shopping cart, someone may game it to defraud you, or hack it to
send future customers to their evil phishing checkout system to "complete
their purchase".

Brad Judy


> -----Original Message-----
> From: The EDUCAUSE Security Constituent Group Listserv
> [mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of Gary Flynn
> Sent: Wednesday, June 10, 2009 2:35 PM
> To: SECURITY () LISTSERV EDUCAUSE EDU
> Subject: Re: [SECURITY] PCI DSS compliance challenges
>
> Scott Weyandt wrote:
> > One of my colleagues is a PCI Auditor (QSA and PA-QSA certified).  He
> > continually states that you cannot over stress the importance of
segregating
> > systems that transfer or store card holder data from the rest of your
> > network.  If you do so, you greatly limit the scope of a PCI audit to
that
> > network segment and its systems.  If you do not, your entire network is
> > potentially in scope for a PCI audit.
>
>
> Segmentation is certainly baked into the regulations. Even SAQ
> B and C levels prohibit the card handling devices from being
> connected to any other systems in the merchant environment.
>
> What I don't understand is how infrastructure needs are supposed
> to be handled. Is an organization that processes a relatively
> small number of cards supposed to put up redundant support
> infrastructure such as DNS, DHCP, AD, SMS, and AV servers?
> If they don't, do all the central infrastructure services
> come into scope? And if the central infrastructure services
> come into scope, does the rest of the network because of the
> intertwining with the infrastructure?
>
> --
> Gary Flynn
> Security Engineer
> James Madison University
> www.jmu.edu/computing/security