Re: Any PCI Gurus?

["Eric C. Lukens" <eric.lukens () uni edu>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
 
Just a side note on this thread. The big issue I see for Company A is
remote management of the device inside the PCI environment at Company
B. To get in, the people at Company B will have to setup accounts that
meet PCI requirements and enable them only while Company A needs them.
While Company A doesn't have to be PCI compliant, Company B must have
a service agreements and other PCI-required paperwork signed by
Company A and reviewed regularly. Company B needs to document all of
Company A's items in their network, again to various PCI requirements.
In summary, the PCI requirements fall on Company B, and Company A just
needs to be willing to sign service agreements (after a good review by
Company A) and follow relevant PCI rules as determined by Company B.
To company A, these PCI rules imposed by Company B should be seen no
differently as any other rules some client may have for accessing
their network. The requirements on vended solutions get a bit fuzzy
with PCI. With the QSAs I've worked with, vended appliances seem to be
mostly left alone as far as most of the requirements go (the
requirements would apply to Company B), but not entirely (again,
applying to systems that don't actually process CHD, but are just on
the same network as it). I personally think its one of the biggest
inconsistencies I've seen in PCI DSS.

Company B can avoid having Company A do the above things by
sufficiently segregating the appliance out of their cardholder
environment.

Now if Company A's software/hardware is involved in processing
cardholder data, then we have a different issue entirely.

- -Eric

Ben wrote:
> Hi Shankl,
>
> I'm no QSA or PCI consultant (apply all normal disclaimers here),
> but I think I can provide some insight on most of these.
>
> On Thu, Jan 13, 2011 at 4:38 PM, Shankl Shankl <shankl () hotmail com> wrote:
> > Heres a little scenario that I wanted to throw out there and get an
opinion on by someone who knows PCI. I am starting
> > to learn but couldn't help with this problem because I've never
assisted in a PCI audit...
> > (I would think this problem has been encountered by many companies
that make network appliances)
> > ====== Background =======
> >
> > 1) Company A is a small company (only 5 employees)
> >
> > 2) They provide a service which requires their customer, Company B, to
install a small network appliance on their LAN
> > in order to collect data from their onsite mechanical equipment.
> >
> > 3) Operating data is then pulled from these mechanical systems and
then dumped to a remote server which processes the
> > data and provides a dashboard for the customer to view (via SSL).
> >
> > 4) Company B bought a license for this service and was also handed
over the keys to administer accounts and decide
> > which employees it would like to give access to.
> >
> > 5) Now let’s say that Company B typically processes credit card
payments locally and sends transaction data through
> > their local LAN on its way out to their payment processor.
> >
> > ====== Problems =======
> >
> > 1) Company A does not take credit cards and is not required to be PCI
compliant however they do provide a service which
> > requires their network appliance to be installed on Company B’s network.
> >
> > 2) In recent days Company A has come to the conclusion that in some of
Company B’s newly acquired satellite offices,
> > credit card data is being forwarded across the LAN in a variety of
ways (some of which do not look to be
> > secure/encrypted).
> >
> > 3) In addition, several of these satellite offices are running
consumer grade routers (ie: Linksys, Netgear) providing
> > little in the way of segmentation.
> >
> > 4)Company A would like to avoid being “In Scope” and having to charge
the client for consulting fees.
> > ====== Questions =======
> >
> > 1) For the smaller satellite offices what might be a simple fix?
>
> Segmentation. Segmentation. Perhaps a little more segmentation.
> Proverbial "Company B" should really be segmenting their traffic to
> keep CHD away from other devices to reduce scope as much as possible.
> The other possibility, though it lands on the opposite end of the
> simplicity scale, is tokenization. This is a fairly new method of
> reducing scope and is a much larger undertaking probably best left
> alone in smaller environments.
>
> > 2) Does segregation provide an easy way to kick devices out of scope
for PCI audits?
> >
>
> Yes, very much so. (See above.) If we're still talking about
> consumer-grade devices, segmentation that meets standard may not be as
> easily achieved. Most entry-level business class equipment offers
> simple VLANs and ACLs that quite easily meet the requirements for
> network segmentation.
>
> > 3) Would it be recommended/possible to have a firm produce a report
which could be handed to an auditor and prove “Out of Scope” prior to
being dragged into one of these audits?
> >
>
> It would probably be possible to get a QSA to do a brief engagement to
> confirm whether or not "Company A's" devices are "in scope" at
> "Company B," but the QSA that "Company B" is using for their own audit
> should be able to define this, as well.
>
> > 4) Could the network appliance be designed/situated in such a way as
to be “out of scope” or at least easily verifiable as compliant even if
it was sitting on the same logical subnet where the card data traffic
was moving across?
> >
>
> While it may not seem like it, this is a fairly ambiguous question.
> The best way to situate the appliance to be out of scope is to put it
> on a different network segment. Whether or not the appliance itself is
> compliant is an even most dubious question. This depends heavily on
> what the device is, does, and can do. The only way that (this is where
> I'll admit my experience gets a bit fuzzy) a device can be said to be
> "compliant" is based upon its configuration or ability to meet
> configuration requirements. Is this what this particular question
> centers around?
>
>
> > ------------------------------------------------------------------------
> > Securing Apache Web Server with thawte Digital Certificate
> > In this guide we examine the importance of Apache-SSL and who needs an
SSL certificate. We look at how SSL works, how it benefits your company
and how your customers can tell if a site is secure. You will find out
how to test, purchase, install and use a thawte Digital Certificate on
your Apache web server. Throughout, best practices for set-up are
highlighted to help you ensure efficient ongoing management of your
encryption keys and digital certificates.
> >
http://www.dinclinx.com/Redirect.aspx?36;4175;25;1371;0;5;946;e13b6be442f727d1
> > ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------
> Securing Apache Web Server with thawte Digital Certificate
> In this guide we examine the importance of Apache-SSL and who needs an
SSL certificate. We look at how SSL works, how it benefits your company
and how your customers can tell if a site is secure. You will find out
how to test, purchase, install and use a thawte Digital Certificate on
your Apache web server. Throughout, best practices for set-up are
highlighted to help you ensure efficient ongoing management of your
encryption keys and digital certificates.
> http://www.dinclinx.com/Redirect.aspx?36;4175;25;1371;0;5;946;e13b6be442f727d1
> ------------------------------------------------------------------------

- -- 
Eric C. Lukens
IT Security Policy and Risk Assessment Analyst
ITS-Network Services
Curris Business Building 15
University of Northern Iowa
Cedar Falls, IA 50614-0121
319-273-7434
http://www.uni.edu/elukens/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iEYEARECAAYFAk0174AACgkQN+w4PqsMNp3EFACffY+yu6NwM8TMWemlVsB4FZ3H
B0AAn2nIqAtxsxSu4DZ2zgZYmPb69dWm
=RMNJ
-----END PGP SIGNATURE-----


------------------------------------------------------------------------
Securing Apache Web Server with thawte Digital Certificate
In this guide we examine the importance of Apache-SSL and who needs an SSL certificate.  We look at how SSL works, how 
it benefits your company and how your customers can tell if a site is secure. You will find out how to test, purchase, 
install and use a thawte Digital Certificate on your Apache web server. Throughout, best practices for set-up are 
highlighted to help you ensure efficient ongoing management of your encryption keys and digital certificates.

http://www.dinclinx.com/Redirect.aspx?36;4175;25;1371;0;5;946;e13b6be442f727d1
------------------------------------------------------------------------