Educause Security Discussion mailing list archives
Re: PCI compliance on a university network
From: "Flynn, Gerald" <flynngn () JMU EDU>
Date: Tue, 22 Dec 2009 09:12:03 -0500
-----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.
Current thread:
- PCI compliance on a university network Greg Francis (Dec 21)
- <Possible follow-ups>
- Re: PCI compliance on a university network Gary Dobbins (Dec 22)
- Re: PCI compliance on a university network James R. Pardonek (Dec 22)
- Re: PCI compliance on a university network Michael Johnson (Dec 22)
- Re: PCI compliance on a university network Flynn, Gerald (Dec 22)
- Re: PCI compliance on a university network Flynn, Gerald (Dec 22)
- Re: PCI compliance on a university network John Ladwig (Dec 22)
- Re: PCI compliance on a university network Daniel Adinolfi (Dec 22)
- Re: PCI compliance on a university network Paul Kendall (Dec 22)
- Re: PCI compliance on a university network HALL, NATHANIEL D. (Dec 22)
- Re: PCI compliance on a university network Flynn, Gerald (Dec 22)
- Re: PCI compliance on a university network Joel Rosenblatt (Dec 22)
- Re: PCI compliance on a university network Allison Dolan (Dec 22)
- Re: PCI compliance on a university network Flynn, Gerald (Dec 22)
- Re: PCI compliance on a university network John Ladwig (Dec 22)
(Thread continues...)