Re: PCI DSS compliance challenges

[John Ladwig <John.Ladwig () CSU MNSCU EDU>]

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