Re: PCI DSS compliance challenges

["Greene, Chip" <cgreene2 () RICHMOND EDU>]

Finding IP addresses in a range can be accomplished by a wide range of free tools.  On our campus we own a class B, as 
well as use the 172.16 - 31 range.  Using these tools helps us build our design documents which provide an auditor with 
the exact ranges in scope as well as the segmentation used to narrow the scope (VLAN, FW, VPN). We are lucky that the 
Network Department is very involved in the PCI process, and the network team is also accountable for its security.  If 
there are two departments involved, gathering this information may be more tricky, however it is still important for 
these two functional groups to communicate.  

Chip

________________________________________
From: The EDUCAUSE Security Constituent Group Listserv [SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of Michael Johnson 
[mjohnson () COMPLYGUARDNETWORKS COM]
Sent: Wednesday, June 10, 2009 5:36 PM
To: SECURITY () LISTSERV EDUCAUSE EDU
Subject: Re: [SECURITY] PCI DSS compliance challenges

Caution, ASV Approaching...
My company is an approved scan vendor (# 3710-01-02) and we help people
scope their environment every day. We provide a FREE tool called Range
Probe that will find all open and active IPs in a range. We ask our
clients to determine if the discovered IP is needed. If not, remove from
the test range or close it down.
Yes we get paid to scan, but we only charge for what needs to be
scanned, and the charges are for UNLIMITED testing on those IPs
determined to be in scope. It's a fair practice all around.

As a side note, the acquirer will most likely tell anyone that asks to
go get an opinion from an approved vendor and then they might render an
opinion. The acquirer has an interest in being conservative and will
tell you the risk is with you the merchant so do what you think is the
mutual best interest of the parties.

Michael Johnson
ComplyGuard Networks.

-----Original Message-----
From: The EDUCAUSE Security Constituent Group Listserv
[mailto:SECURITY () LISTSERV EDUCAUSE EDU] On Behalf Of John Ladwig
Sent: Wednesday, June 10, 2009 5:10 PM
To: SECURITY () LISTSERV EDUCAUSE EDU
Subject: Re: [SECURITY] PCI DSS compliance challenges

The only answer (about scanning scope;/segmentation) that matters is the
answer the PCI compliance officer from your acquiring banks(s) gives
you.

Talk to them.

   -jml


> > > Gary Flynn <flynngn () jmu edu> 06/10/09 3:33 PM >>>
Brad Judy wrote:
> Gary,
>
> I think this info from the PCI Scanning Procedures document answers
your
> questions.  (Note this doc is for 1.1 and hasn't been updated for 1.2
yet,
> but I don't expect this section will change.)
>
> ----quote-----
>
> In some instances, companies may have a large number of IP addresses
> available while only using a small number for card acceptance or
processing.
> In these cases,
> scan vendors can help merchants and service providers define the
appropriate
> scope of the scan required to comply with the PCI.

So a vendor that gets paid based on the number of devices scanned
gets to help define the appropriate number of devices to scan.
I wonder how many different answers I might get. :)

  In general, the following
> segmentation methods can be used to reduce the scope of the PCI
Security
> Scan.
>
> -Providing physical segmentation between the segment handling
cardholder
> data and other segments
> -Employing appropriate logical segmentation where traffic is
prohibited
> between the segment or network handling cardholder data and other
networks
> or segments

I don't see any exception in there for infrastructure needs.

> Merchants and service providers have the ultimate responsibility for
> defining the scope of their PCI Security Scan,

Ahh. Now that is interesting. They're basically leaving it up to our
discretion and how comfortable we are accepting risk.

  though they may seek
> expertise from
> ASVs for help. If an account data compromise occurs via an IP address
or
> component not included in the scan, the merchant or service provider
is
> responsible


Hmmm. That sounds like we're really never judged to be in compliance.
Only that we've stated we're comfortable with the degree of risk
we've assumed by allowing AD, SMS, WSUS, or whatever traffic through
the "PCI network firewall".

So basically, as far as the scanning and segmentation goes, you're
in compliance until you get hacked. :)

Seems like I've seen things in the papers like that. :)


> ----end quote----
>
> They essentially define the "network" scope as devices that can
contact a
> system that handles card holder data in an unrestricted way.

Do they really specify the direction of connection? After all, a
computer that pulls malware from a compromised infrastructure
server is just as compromised as a client that allows an inbound
connection to a vulnerable or malicious port.

   As they note,
> this scope decision lies in the organization's hands, along with the
> responsibility.

I guess that is the bottom line.


   Place any card data handling systems in a separate network
> segment with restrictive firewall rules
  and count the devices in that
> network segment as in-scope for compliance.

And if infrastructure traffic is permitted through the firewall and
the infrastructure is the point of entry for a compromise, we're
at fault and judged non compliant after the fact.

"Do what you want. If it works, you're compliant. If it doesn't
  you weren't." :)

> I would expect the smaller volume organizations not to process card
data on
> the network on-site (e.g. using swipe-and-dials and/or outsourced card
> handling like Authorize.net).

True, but in the interest of customer service, unique needs, or extra
sales, some would like to.


> I would encourage everyone to include non-card processing items
involved in
> the transaction (like stand-alone shopping cart systems leverage
outsourced
> transaction processing) as in-scope as well.  PCIDSS is about
protecting
> card holder data being given to the intended organization.  If you
don't
> protect a shopping cart, someone may game it to defraud you, or hack
it to
> send future customers to their evil phishing checkout system to
"complete
> their purchase".

By the way, SAQ B&C prohibit storing card data electronically but
allow paper storage as long as the data was not received
electronically. Is a telephone electronic? ;)


--
Gary Flynn
Security Engineer
James Madison University
www.jmu.edu/computing/security