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

David Ryan dave.ryan at gmail.com
Tue Mar 25 13:35:56 EDT 2008

Reasonable room for doubt at the moment, due to flaky details.  However,
their statement would negate Requirement 3 failure (if accepted at face
value = during transmission):

[The Reg] "The stolen data was limited to credit and debit card numbers and
expiration dates, and was illegally accessed from our computer systems
during transmission of card authorisation," Hannaford chief exec Ron Hodge
said in an open letter to customers
the grocer's website. [/The Reg]

Plenty of room for failure in the other ones you mentioned. I guess a the
crux of this could be: Perhaps they were rated as compliant during an audit,
but their controls fell by the wayside afterwards. Who knows ... speculation
is distracting, where's my day gone ;-)

On 25/03/2008, Andrew van der Stock <vanderaj at owasp.org> wrote:
> 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.
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-codereview/attachments/20080325/e658ea45/attachment-0001.html 

More information about the Owasp-codereview mailing list