[Owasp-ireland] [Owasp-codereview] Potential of 4.2 million credit card details stolen via cyber attack.
Andrew van der Stock
vanderaj at owasp.org
Tue Mar 25 12:04:07 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
"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.
* 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
In my personal opinion, even given the limited information that is
public, from the first two issues above alone, we can assume Hannaford
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.
Andrew van der Stock
Lead Author, OWASP Guide and OWASP Top 10
More information about the Owasp-ireland