Re: PCI compliance on a university network

[Matthew Wollenweber <mjw () CYBERWART COM>]

I agree with Scott. I was never the PCI consultant, but I've worked with
them as part of network security assessments. Scott's advice is sound. I'd
only caution to heed his comment that the auditor needs to be comfortable
with the segmentation (and I'll add overall security posture). Pushing
virtual segmentation and other weak security barriers is going to make many
auditors uncomfortable.

I'd recommend having your security team push for strong security measures or
hire a consultant. If you deploy a configuration for compliance that doesn't
meet the audit requirements no one will be happy. So it's probably easier to
push for a stronger solution or use a consultant who is familiar with
hitting the minimum requirements (and that you can blame if things go
wrong).


On Tue, Dec 22, 2009 at 11:58 AM, Scott Sweren <ssweren () udel edu> wrote:

> I am the ISO at UD but was a QSA prior to joining UD in March.  I think
> some of the confusion is in how PCI DSS is interpreted by the QSA using the
> guidelines provided by PCI.  Not all technology is identical.  Even among
> implementations of identical technologies, not all configurations and
> management processes are identical.  So it is possible that an
> implementation of a VLAN was performed in accordance with PCI DSS and
> another is not.  I used the interpretation that VLANS were acceptable for
> internal segmentation as long as ACLs were in place to control the network
> traffic in and out of the VLAN.  The ACLs additionally had to meet and be
> managed in a PCI DSS compliant way.
>
> Not to imply anything but I also had multiple clients that heard one thing
> when I said something else.  I would prefer to see a standard firewall in
> place for segmentation and would tell my clients that.  I would also provide
> other options such as VLANS, using what I call virtual firewalls (from
> companies like Apani), or even using host-based TCP/IP filters but would
> push for a firewall as the "cleanest" way to meet segmentation.  However,
> sometimes all they "heard" was that a firewall was required.
>
> PCI had always instructed that the auditor needed to be comfortable that
> segmentation was really in place.  While it may be, if the company could not
> adequately demonstrate that, then the auditor could state so in the report.
>  Demonstration is through providing the ACL lists, showing reviews and
> approvals were done as required, etc.
>
> Not sure if this helps any of you.
>
> Scott
>
> *Scott Sweren
> Information Security Officer*
> University of Delaware
> ssweren () udel edu
>
>
>
>
> On Dec 22, 2009, at 10:37 AM, Joel Rosenblatt wrote:
>
> Interesting discussion - this just enforces the understanding that in order
> to become a QSV, you sign up and pay a license fee .. I guess you can just
> shop around to find one who will pass your setup.
>
> Again, this is the difference between real security and checklist security
> :-)
>
> ... and now, back to our regularly scheduled program ...
>
> Joel
>
> Joel Rosenblatt, Manager Network & Computer Security
> Columbia Information Security Office (CISO)
> Columbia University, 612 W 115th Street, NY, NY 10025 / 212 854 3033
> http://www.columbia.edu/~joel <http://www.columbia.edu/%7Ejoel>
>
> --On Tuesday, December 22, 2009 10:27 AM -0500 "Flynn, Gerald" <
> flynngn () JMU EDU> 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.
>
>
>
>
>
> Joel Rosenblatt, Manager Network & Computer Security
> Columbia Information Security Office (CISO)
> Columbia University, 612 W 115th Street, NY, NY 10025 / 212 854 3033
> http://www.columbia.edu/~joel <http://www.columbia.edu/%7Ejoel>


--
Matthew Wollenweber
mjw () cyberwart com
240-753-0281