Re: PCI DSS compliance challenges

[Ellen Smout <esmout () UWO CA>]

If you could enter that information anywhere on the internet then the
answer is no, but the paper process is in scope.  The 3rd party should
be PCI compliant as well.

I know it's a very fine line, but where the credit card information is
entered is the key.

thxs,

Ellen

Gary Flynn wrote:
> Ellen Smout wrote:
> > 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.
>
> What if a campus office worker takes customer calls and enters the
> credit card information provided over the phone into a browser on
> their campus computer connecting to a server in a third party
> vendor's PCI compliant IP space. The way I read SAQ C, the local
> client and is in PCI scope and must be isolated from the rest of
> the campus network and be scanned by an external party quarterly.
>
>
>   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?

Attachment: esmout.vcf
Description: