Re: PCI compliance on a university network

[John Ladwig <John.Ladwig () CSU MNSCU EDU>]

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.