Educause Security Discussion mailing list archives

Previous By Date Next
Previous By Thread Next

Re: PCI compliance on a university network

From: Scott Sweren <ssweren () UDEL EDU>
Date: Tue, 22 Dec 2009 11:58:01 -0500
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

--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
Previous By Date Next
Previous By Thread Next

Current thread: