Re: PCI and common access computers

[Patrick Ouellette <ouellep () ALGONQUINCOLLEGE COM>]

We've gone one step further to rate limit or throttle large downloads on specific VLAN's (i.e. access centers, labs, 
wireless, residences & VPN access). There are exceptions - like MSDNAA downloads - but they're rare.

Other VLANs, like staff offices and Data Center, are left open - we download ISO's and such on a more than averagely 
regular basis.

Otherwise, students - especially the one's just recently let loose from parents OR that don't have a lot of bandwidth 
at home - end up bogging the network down with torrents, online games and downloading God-only-knows what :)

Sincerely,

Patrick Ouellette
Algonquin College - School of Advanced Technology
Program Coordinator: Computer Systems Technician & Technology - Networking / Security Programs
Professor - Computer Studies Department


> -----Original Message-----
> From: The EDUCAUSE Security Constituent Group Listserv
> [mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of Ewing, Ashley
> Sent: March 25, 2010 3:27 PM
> To: SECURITY () LISTSERV EDUCAUSE EDU
> Subject: Re: [SECURITY] PCI and common access computers
>
> Didn't mean to mislead anyone.  The approach we are taking with our in
> scope desktops was primarily to isolate the CC traffic as much as
> possible to better enable the application of all other PCI requirements
> such as IDS/IPS, Firewalls, isolation from wireless, etc. Without that,
> everything sharing the same network as the CC processing systems would
> be in scope.
>
> J. Ashley Ewing, CISSP, CISA
> Information Security Officer
> Office of Information Technology (OIT)
> The University of Alabama
> A314 Gordon Palmer Hall (Box 870346)
> Tuscaloosa, AL 35487-0346
> Office: 205-348-6524
> Cell:     205-535-0335
>
>
> -----Original Message-----
> From: The EDUCAUSE Security Constituent Group Listserv
> [mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of John Ladwig
> Sent: Thursday, March 25, 2010 1:48 PM
> To: SECURITY () LISTSERV EDUCAUSE EDU
> Subject: Re: [SECURITY] PCI and common access computers
>
> I observe that "good vlans" are not a scope-delineating control under
> PCI.  You need stateful packet inspection with bidirectional default-
> deny between systems handling cardholder data and any system reachable
> from the Internet.  If you have a tight inbound traffic policy from
> both Internet and DMZ, you can get away with stateless router ACLs.
> Some of Cisco's IOS has "reflexive ACL" processing, and that supposedly
> counts for scope delineation.
>
> VLANs alone aren't enough.
>
> However, all QSA opinions I've seen are that a CHD VLAN may coexist on
> he same Layer-2 devices as a non-CHD VLAN, so long as there is Layer-3
> policy enforcement between the VLANs.
>
> I haven't pushed hard on the question of whether a host-based Layer-3
> firewall would suffice as a scope-delimiting control, not because I
> think the QSA would fail it, but because *I* probably wouldn't trust it
> not to be disabled by the next piece of malware to cross the machine.
>
>    jml
>
> > > > Blake Penn <BPenn () TRUSTWAVE COM> 2010-03-25 11:51 >>>
> That's a good strategy for segmentation.  Also, I've seen restrictive
> host-based firewalling and similar approaches used to create "islands"
> of in-scope systems while maintaining a greater out-of-scope network.
>
>
> Blake Penn
> CISSP, MCSE, MCSD, MCDBA, QSA
> Senior Security Consultant
> Trustwave
> bpenn () trustwave com
> 678-777-1277
> http://www.trustwave.com
>
> DISCLAIMER: The views represented in this message reflect the opinions
> of the author alone and do not neccessarily reflect the opinions of
> Trustwave.
>
> -----Original Message-----
> From: The EDUCAUSE Security Constituent Group Listserv
> [mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of Eric C. Lukens
> Sent: Thursday, March 25, 2010 11:38 AM
> To: SECURITY () LISTSERV EDUCAUSE EDU
> Subject: Re: [SECURITY] PCI and common access computers
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> If they're on the same subnet/segment, then they're also in scope.
> You're best bet is probably to invest in some good vlans or separate
> network hardware to segment the cardholder machines from everything
> else.  That's what we're doing here.  If you're interested in hearing
> more about it, just let me know.
>
> - -Eric
>
> - -------- Original Message  --------
> Subject: Re: [SECURITY] PCI and common access computers
> From: Mayne, Jim <j.mayne () TCU EDU>
> To: SECURITY () LISTSERV EDUCAUSE EDU
> Date: 3/25/10 10:30 AM
>
> > Blake,
> >   That makes sense but now what about other workstations that are not
> used for processing credit card information but are on the same network
> subnet or segment. Are they in scope as well?
> > Thanks,
> > Jim
> >
> > -----Original Message-----
> > From: The EDUCAUSE Security Constituent Group Listserv
> [mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of Blake Penn
> > Sent: Thursday, March 25, 2010 9:37 AM
> > To: SECURITY () LISTSERV EDUCAUSE EDU
> > Subject: Re: [SECURITY] PCI and common access computers
> >
> > That sounds spot on.  The key question is whether the system is being
> used as part of a university business process in either a merchant or
> service provider context.  If the answer is yes, then it is likely in
> scope, if no, then likely not.
> > Blake Penn
> > CISSP, MCSE, MCSD, MCDBA, QSA
> > Senior Security Consultant
> > Trustwave
> > bpenn () trustwave com
> > 678-777-1277
> > http://www.trustwave.com
> >
> > DISCLAIMER: The views represented in this message reflect the
> opinions of the author alone and do not neccessarily reflect the
> opinions of Trustwave.
> > -----Original Message-----
> > From: The EDUCAUSE Security Constituent Group Listserv
> [mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of Ewing, Ashley
> > Sent: Thursday, March 25, 2010 10:07 AM
> > To: SECURITY () LISTSERV EDUCAUSE EDU
> > Subject: Re: [SECURITY] PCI and common access computers
> >
> > I have been told by our QSA, Trustwave and auditors at PwC that they
> are in scope.  An employee entering a credit card on a university owned
> machine going through a university network to the payment process on
> site or off site is in scope along with the path as part of a
> university payment process.  Not an individual making a personal
> purchase, but the ticketing office, advancement/alumni, continuing
> studies programs, etc., taking customer credit cards via phone, fax or
> paper.
> > We are testing the use of a small PCs that shares the keyboard, mouse
> and monitor with the primary desktop, and runs software that will
> lockdown the device to the payment processes only on an isolated
> network segment (completely separate from any wireless network access).
> This reduces the risk associated with email, web surfing and network
> sniffing.
> > Feel free to contact me offline if you have any questions.
> >
> > J. Ashley Ewing, CISSP, CISA
> > Information Security Officer
> > Office of Information Technology (OIT)
> > The University of Alabama
> > A314 Gordon Palmer Hall (Box 870346)
> > Tuscaloosa, AL 35487-0346
> > Office: 205-348-6524
> > Cell:     205-535-0335
> >
> > -----Original Message-----
> > From: The EDUCAUSE Security Constituent Group Listserv
> [mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of Flynn, Gary
> > Sent: Thursday, March 25, 2010 8:46 AM
> > To: SECURITY () LISTSERV EDUCAUSE EDU
> > Subject: [SECURITY] PCI and common access computers
> >
> > It has been suggested that these types of computers that people could
> use
> > to perform credit card transactions may be in-scope for PCI
> compliance
> > requirements. Anyone heard anything like that? I don't see how it
> could
> > ever work as you couldn't restrict the access to the credit card
> requesting
> > sites because they could be anywhere. And you really couldn't
> reliably
> > prevent people from typing them either.
>
> - --
> Eric C. Lukens
> IT Security Policy and Risk Assessment Analyst
> ITS-Network Services
> Curris Business Building 15
> University of Northern Iowa
> Cedar Falls, IA 50614-0121
> 319-273-7434
> http://www.uni.edu/elukens/
> http://weblogs.uni.edu/elukens/
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.10 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkurg0MACgkQN+w4PqsMNp25vwCfTvR0vbb19PVxi3tiTmungRP3
> EO8An31lWtEmAUWBjZtMFJVAn7ihch1I
> =otO9
> -----END PGP SIGNATURE-----
>
>
> __________ Information from ESET Smart Security, version of virus
> signature database 4974 (20100325) __________
>
> The message was checked by ESET Smart Security.
>
> http://www.eset.com


__________ Information from ESET Smart Security, version of virus signature database 4974 (20100325) __________

The message was checked by ESET Smart Security.

http://www.eset.com