Re: PCI DSS compliance challenges

["Basgen, Brian" <bbasgen () PIMA EDU>]

 While an institution is always responsible for PCI compliance, the first question is: who is responsible for managing 
the DSS? Wherever an institution can outsource, then the DSS will apply to the vendor. When an institution is 
processing internally, then DSS applies, even if the software purchased is "PCI approved", etc.

 The context here is for those circumstances where the DSS must be managed internally. Segregation is certainly 
essential in a higher ed network, and thus the question is: what kind of segregation have institutions successfully 
used for a relatively reasonable cost/effort? Has anyone found it necessary to do physical segregation? Has anyone 
passed an audit, and if so, with what kind of general configuration?

~~~~~~~~~~~~~~~~~~
Brian Basgen
Information Security
Pima Community College
Office: 520-206-4873


-----Original Message-----
From: The EDUCAUSE Security Constituent Group Listserv [mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of Ellen 
Smout
Sent: Wednesday, June 10, 2009 1:00 PM
To: SECURITY () LISTSERV EDUCAUSE EDU
Subject: Re: [SECURITY] PCI DSS compliance challenges

This all depends on how the cards are processed and where the cards are processed.  If you don't have any systems that 
process credit cards within your ip space then PCI probably won't apply to you.  If you enter credit card information 
into an external ip address then that entity must be PCI compliant.  Where the credit cards are entered is key.  This 
is what should be made PCI compliant.

So for example if you use an outside vendor to sell football tickets at your location then the outside vendor systems 
must be made PCI compliant, but you are responsible for any manual processes for PCI compliance on site.  If there 
aren't any, then you are not processing credit cards and PCI compliance does not apply here.

If you house the software to process the credit cards the ticketing software (and the systems that support) will have 
to be PCI compliant.
Any entities on the network segment will be affected (therefore segregation reduces your scope).  Authentication and 
authorization, NTP, DNS entities are also in scope if they are used by the credit card processing systems.  Oh and 
don't forget the logging systems, they fall into scope as well.

This, like any other security program is all about the risk.  The fallout from large breaches such as Heartland seem to 
be fines and paying for replacement cards.  A breach also rockets you into the category of Level 1 which is mandatory 
yearly audits.  You can also have your Merchant id stopped from processing.  The liability resides with the Merchant 
id, so if a breach occurs the liability (no matter where the processing occurs) is on the owner of the Merchant id, 
depending on your legal agreements.

Understanding how credit cards are processed in your organization is key.

thxs,

Ellen Smout

Gary Flynn wrote:
> 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?