Re: PCI compliance on a university network

["Davis, Thomas R" <tdavis () IU EDU>]

The PCI Virtualization Special Interest Group's (SIG) impending white paper should provide merchants and QSAs alike 
more guidance on both network and host virtualization.  You can find a bit more info here:

 http://tinyurl.com/yen5bme

and here:

 http://tinyurl.com/yc8spss
 
--
Tom Davis, CISSP, CISM
Chief Information Security Officer
Information and Infrastructure Assurance
Office of the VP for Information Technology and CIO
Indiana University
https://informationsecurity.iu.edu/Tom_Davis


On Dec 22, 2009, at 10:27 AM, Flynn, Gerald wrote:

> And our QSV said both VLANS and VMs were OK.
>
> Sigh.
>
>
>
> > -----Original Message-----
> > From: The EDUCAUSE Security Constituent Group Listserv
> > [mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of HALL, NATHANIEL D.
> > Sent: Tuesday, December 22, 2009 10:25 AM
> > To: SECURITY () LISTSERV EDUCAUSE EDU
> > Subject: Re: [SECURITY] PCI compliance on a university network
> >
> > We had a QSA review our network and we were told VLANs were not
> > acceptable.  The odd part was virtual servers were allowed, but they
> > had to have a dedicated physical interface for the PCI systems.  I am
> > waiting for VMs to be removed from the list of acceptable technologies.
> >
> > --
> > Nathaniel Hall, GSEC GCFW GCIA GCIH GCFA
> > Network Security System Administrator
> > OTC Computer Networking
> >
> > Office: (417) 447-7535
> >
> >
> > > -----Original Message-----
> > > From: The EDUCAUSE Security Constituent Group Listserv
> > > [mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of John Ladwig
> > > Sent: Tuesday, December 22, 2009 8:42 AM
> > > To: SECURITY () LISTSERV EDUCAUSE EDU
> > > Subject: Re: [SECURITY] PCI compliance on a university network
> > >
> > > I'm not a QSA, and I'm not a compliance director for an acquiring
> > bank,
> > > but I'm pretty sure I wouldn't rely on scenario 6) below (in trunked-
> > > VLAN virtual host mode) holding up to scrutiny for very long, if it
> > > were even passed by an acquiring bank.
> > >
> > > I'm actually a little surprised that compliance officers from
> > acquirers
> > > have reportedly been signing off on VLAN distribution of PCI islands
> > > across network switches which also carry unwashed traffic.  It's a
> > > great convenience to getting an island built, but I've seen my fair
> > > share of games played at layer-2...
> > >
> > >
> > > The best PCI-compliance-related advice I've received recently goes
> > > something like as follows:  ~"If you are choosing between what would
> > be
> > > a strict interpretation of a PCI compliance item and a looser
> > > interpretation, assume that the stricter interpretation is what
> > > holds."~
> > >
> > > And, folks, remember - "No organization experiencing a breach of
> > > cardholder data has ever been found to be PCI compliant at the time
> > of
> > > the breach."  I can't imagine the card-processing system is going to
> > > retrench from that statement.
> > >
> > >   -jml   *somewhat reluctantly becoming the domain expert for PCI in
> > > our area*
> > >
> > > > > > "Flynn, Gerald" <flynngn () JMU EDU> 2009-12-22 08:12 >>>
> > > > -----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
> > >
> > > The regulations call for a NAT stateful firewall to separate the
> > > card holder environment. We were getting ready to deploy Cisco
> > > ASA 5505 firewalls as point solutions in needed areas until
> > > we had some scope creep. We're re-evaluating now.
> > >
> > > > 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).
> > >
> > > We also have a lot of distributed transactions but we believe we've
> > > identified them all. What we didn't realize were some of the same
> > > areas have accounts on the major credit card sites that allow them
> > > to do monthly reporting and reconciliation. Those sites show full
> > > PANS. That puts the computers that use those sites in scope. Hence
> > > our recent scope creep.
> > >
> > > > 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.
> > >
> > > We converted all servers to use outside processing companies.
> > However,
> > > the web sites that lead to those companies are still considered
> > > "supporting systems" so fall into scope for quarterly vulnerability
> > > scans. They don't have all the other requirements though.
> > >
> > > > 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?
> > >
> > > Here is what we were in the process of doing before the
> > aforementioned
> > > scope creep:
> > >
> > > 1) Outsource all server card handling.
> > > 2) Identify all desktops into which credit card numbers were typed.
> > >   a) Isolate them with a Cisco ASA 5505 firewall installed in the
> > >      closest switch closet. Traffic to credit card sites is NATed
> > and
> > >      SSL protected. Traffic to infrastructure is not NATed  (e.g.
> > dns,
> > >      AD, SMS, Symantec server). No inbound traffic allowed.
> > Computers
> > >      are dedicated to the card handling task and cannot communicate
> > >      with systems other than the card sites and infrastructure. This
> > >      meant giving staff a second computer for office work. The
> > second
> > >      computer must be blocked from card handling site(s).
> > > 3) Analyze business processes to see where it makes sense to stop
> > > performing
> > >   credit card transactions from desktops.
> > > 4) Convert from desktops to dedicated card swipe machines where
> > > possible.
> > >
> > > With the addition of computers that access the reporting and
> > > reconciliation
> > > sites, the cost model changes. What we're considering now:
> > >
> > > 4) Reanalyze business processes.
> > > 5) Create area networks with vlans for PCI operations and bring them
> > > back
> > >   to a central point where they'll be isolated with NAT firewalls as
> > >   previously described.
> > > 6) Instead of giving people two computers, use virtual machines.
> > >   Base machine will be treated as described above. A virtual machine
> > >   on that machine will be used to perform non-card functions. The
> > >   traffic associated with the virtual machine will have its own
> > >   IP address. It will either go out the same network card on a
> > >   different vlan (vlan tagging in card and a trunked port) or a
> > >   second network card. The virtual machine must be blocked from
> > >   accessing card sites. Note that this means in some cases the
> > >   machine will not be able to reach consumer oriented card sites.
> > >   I'm not sure what we're going to do if we find card sites that
> > >   use Akamai and similar services making blocking by IP addresses
> > >   impossible.