Educause Security Discussion mailing list archives
Re: PCI compliance on a university network
From: Joel Rosenblatt <joel () COLUMBIA EDU>
Date: Tue, 22 Dec 2009 10:37:27 -0500
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 --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
Current thread:
- Re: PCI compliance on a university network, (continued)
- 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)
- Re: PCI compliance on a university network Crary, Greg (Dec 22)
- Re: PCI compliance on a university network Robert Ellison (Dec 22)
- Re: PCI compliance on a university network Scott Sweren (Dec 22)
- Re: PCI compliance on a university network Paul Kendall (Dec 22)
- Re: PCI compliance on a university network Matthew Wollenweber (Dec 22)
- Re: PCI compliance on a university network John Ladwig (Dec 22)
- Re: PCI compliance on a university network Ellen Smout (Dec 22)
(Thread continues...)