[Owasp-codereview] [Owasp-ireland] Potential of 4.2 million credit card details stolen via cyber attack.

Tue Mar 25 12:03:57 EDT 2008

I really doubt that Hannaford was PCI DSS compliant:

* Requirement 3 - Protect Card Holder Data. Losing 4.2 million records  
requires failing Section 3.1 "Keep cardholder data to a  
minimum" (basically ditch the PAN and expiry as soon as you're done  
with them), and Section 3.4 "Render PAN, unreadable anywhere where it  
is stored". FAIL.

* Requirement 6 - Section 6.1, keeping up with patches. I don't know  
of any site that meets PCI's 1 month deadline to install new patches  
for critical components. It would be surprising to me if Hannaford did  
this. Possible fail.

* Section 6.5 - do a Top 10 review. This is the old Top 10 2004. 6.5.8  
is "Insecure storage" - enough said! FAIL

* Requirement 10 - Monitor and Test Networks and Requirement 11  
Regularly Test security systems and processes. In particular section  
10.6:

"Review logs for all system components at least daily. Log reviews  
must include those servers that perform security functions like  
intrusion detection system (IDS) and authentication, authorization,  
and accounting protocol (AAA) servers (for example, RADIUS)."

and 11.3.2 - conduct annual application layer pen tests
and 11.4 and 11.5 which says to install network and host IDS and  
network IPS and file integrity monitoring software. These should have  
immediately notified admin staff of changes.

Hannaford didn't detect the breach for nearly three months. That  
implies a lack of effective intrusion detection and monitoring EVEN if  
they had the above items in place, operational, and logging  
successfully, and someone is monitoring them. Which I highly doubt.  
FAIL.

Arguable:

* Section 6.6 - mandates a code review or a web application firewall,  
but only AFTER JUNE 30. They can be compliant up to now with neither  
of these in place. We know that WAFs today are simply not enough to  
prevent attacks from a motivated, skilled attacker. They are great  
defense in depth and they do knock out script kiddie attacks. If  
Hannaford obtained a code review, then the assessor wasn't  
particularly good, or the firm refused to fix known issues, or both. I  
think this is the area we will see the lawyers involved with if it can  
be argued that 6.6 is REQUIRED to be complied with today. I don't  
believe so.

In my personal opinion, even given the limited information that is  
public, from the first two issues above alone, we can assume Hannaford  
were/are non-compliant.

PCI DSS makes it abundantly clear what folks must do to be safer:

Step 1.  Don't store CC numbers. Really, really, really don't store  
them. You don't need them.
Steps 2..153 However, if you want to damage your business reputation,  
destroy customer confidence, lose shareholder value, set a bunch of  
money on fire by protecting information you don't need (and shouldn't  
want), then here goes... do this wishy-washy list of items. But do it  
properly, or you'll get pwned.

Hannaford ignored #1 and got pwned even though they did *some* of the  
next 153 steps required for PCI DSS. In PCI DSS 1.2, they really  
should make it real short and sweet:

There are no valid business reasons for storing CC's. If you do, you  
fail PCI DSS compliance. This is how you use authorization numbers for  
these common business cases:

That's a one pager in my view.

thanks,
Andrew van der Stock
Lead Author, OWASP Guide and OWASP Top 10