Re: PCI compliance on a university network

[Ellen Smout <esmout () UWO CA>]

Hi

This is excellent advice.

We are almost 2 years into PCI here.  We took a first pass at defining
the scope of our audit and then brought a QSA in to review our findings
and give us recommendations and a budgetary estimate on the costing for
the audit.   This seems to have worked for us.

IMHO it's key to note that IT or Finance or whomever cannot complete the
audit alone, there are far too many business and technical processes to
cover.  It is a true cross-functional project.

Defining the scope of the key.  If a POS terminal is not an integrated
POS terminal then it may be deemed out of scope, these are issues that
can be discussed with your provider.  I would suggest engaging them
early in the process if you have not already.

It's key to remember that fines and monetary liability lie with the
Merchant id for the account, so if you 'outsource or transfer' the
payment system and don't transfer the merchant id you will not transfer
the liability.  Contracts become important, and PCI contractual language
should be added into contracts.  If you can transfer the merchant id,
great,  but reputational issues will probably still remain.

I would suggest using PCI as a way to understand how credit card
information flows in and out of your institution and the care and
control of those numbers, isolate your payment systems, and define the
scope of your audit.  You may find that you can change the way credit
cards are processed which can change your audit component.  We asked the
question, 'Are you storing credit cards?' and found the answers often
led to process changes.

As for the finances, we paid 3 days of consulting for our scoping
exercise, which helped us write our RFP which we tendered publicly.  We
had numbers from very high to very low.

As for Vlans and vm's, it is entirely dependant on the controls,
documentation, processes and environment. It never seems like a yes or
no answer.

It's an audit after all, not a binary function.  It took me a while to
get my head around that!

Merry Christmas,

Ellen Smout


On 12/22/2009 1:11 PM, John Ladwig wrote:
> Our system engaged a QSA firm to do a gap analysis at each card-acceptance point/process, and fill out an initial AOC/SAQ.  
> For SAQ-C and SAQ-D institutions, we've retained an ASV for required scanning, on a charge-back basis.
>
> Subsequent to that, we're examining changes to business and card-acceptance processes to drive our SAQ-D institutions 
> down to a lower-cost and -complexity SAQ-B or SAQ-C.
>
> In parallel, we're advising covered parties to work toward compliance at each institution per the 
> Milestones/Prioritized Approach guidance provided by the PCI Council.
>
> And we've convened an Advisory Group to wrestle with all the issues involved, with IT, Finance, Legal, and other 
> stakeholders represented.
>
> It's a *long* process, and we don't have enough experience yet to give anything like cost/effort estimates for 
> compliance.  Just finding out where we have problems was pretty expensive, though.
>
>     -jml
>
> > > > Robert Ellison<ellisonrobertj () GMAIL COM>  2009-12-22 10:20>>>
> As I'm sure many of you are, we are grappling with the time and effort
> involved for PCI compliance as well as an understanding of proper
> implementation of all the requirements.  Has anyone completed this process?
> Did you bring in a QSA or other security expert?  Do you have an estimation
> as to the time and cost involved?
>
> Thank you in advance for any response.
>
> Robert J. Ellison
> Senior Technical Analyst
> CTM Services
> University of Pittsburgh at Bradford
>
> Phone: 814 362-7666
> Fax: 814 362-7666
> Email: ellison () pitt edu
>
>
> On Tue, Dec 22, 2009 at 11:14 AM, Crary, Greg<gcrary () ewu edu>  wrote:
>
> > On the heels of Greg's question...
> >
> > Looking at requirement 1.3.5, am I to understand we must proxy outbound
> > traffic, or can the firewall serve as the vehicle for evaluation as to
> > traffic?
> >
> > Thanks,
> >
> > Greg
> >
> > -----Original Message-----
> > From: The EDUCAUSE Security Constituent Group Listserv [mailto:
> > SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of Gary Dobbins
> > Sent: Tuesday, December 22, 2009 1:10 AM
> > To: SECURITY () LISTSERV EDUCAUSE EDU
> > Subject: Re: [SECURITY] PCI compliance on a university network
> >
> > We found that the scope of requirements for compliance was so large, and
> > ended up including so much infrastructure, as to be untenable in a typical
> > university LAN.  For that reason we went with a wholly-isolated environment
> > in order to keep the scope localized to a set of systems and network gear
> > that we could "get our hands around" in terms of compliance.  We use a VPN
> > concentrator and inexpensive SOHO devices with nailed-up VPN tunnels for the
> > POS stations, so the payment card network ends up being virtual, and again
> > can be seen as wholly-contained in the special environment.
> >
> > You can find a writeup of this approach in the form of a few Educause
> > presentations by Mike Chapple (ND) and Jane Drews (Iowa) at
> > www.educause.edu.
> >
> > Hope that helps.
> >
> >
> >
> > > -----Original Message-----
> > > From: The EDUCAUSE Security Constituent Group Listserv
> > > [mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of Greg Francis
> > > Sent: Tuesday, December 22, 2009 12:55 AM
> > > To: SECURITY () LISTSERV EDUCAUSE EDU
> > > Subject: [SECURITY] PCI compliance on a university network
> > >
> > >
> > > I'm working with our finance offices to evaluate our PCI compliance
> > > levels on our network. The documentation I have from them doesn't
> > > adequate define the "cardholder data environment."
> > >
> > > For a couple of our areas where we do credit card transactions, we
> > > isolate the network traffic for those POS terminals using VLANs and
> > > then they do encrypted traffic across the Internet to a payment
> > > vendor. This includes places like our food services vendor and our
> > > bookstore. However, we also do on demand credit card cashiering sites
> > > using CashNet. Those sites can pop up throughout the network and we
> > > use PCI compliant devices and CashNet is PCI compliant as well. We
> > > actually went with CashNet in the hopes to avoid the need to be
> > > internally PCI compliant since that effectively outsources credit card
> > > processing (or so my finance office told me).
> > >
> > > It ends up that we own at least one server that does direct credit
> > > card processing (Blackbooard Transaction Server) which has the finance
> > > office understanding that we have to be PCI compliant internally.
> > >
> > > As I look at this though, I'm wondering just how much of our network
> > > has to be compliant? For example, if we don't do anything with credit
> > > cards on the residence hall network and there is a firewall between it
> > > and the administrative network, does the student network have to be
> > > PCI compliant? What if a club sets up a CashNet cashiering site that's
> > > setup in one of the residence halls for the weekend? What if we create
> > > a VLAN for that cashiering site in the residence hall network?
> > >
> > > As another example, since we use Active Directory for authentication,
> > > do all AD domain controllers automatically fall in the cardholder data
> > > environment? What if it's a read-only DC?
> > >
> > > The scope of areas that require PCI compliance feels significant.
> > >
> > > I'm wondering how other schools are handling PCI compliance from the
> > > IT side?
> > >
> > > Thanks,
> > > Greg
> > >
> > > Greg Francis
> > > Director, CCNSS
> > > Gonzaga University
> > > francis () gonzaga edu
> > > 509-313-6896

Attachment: esmout.vcf
Description: