[Owasp-codereview] [Owasp-ireland] Potential of 4.2 million credit card details stolen via cyber attack.
eoin.keary at owasp.org
Tue Mar 25 13:31:24 EDT 2008
Congrats is in order btw.
I believe Hannaford were PCI compliant according the information at hand.
Which highlights the meaning of compliance as opposed to secure. Compliance
is simply a business enabler to show "we are making an effort" as opposed to
the esoteric "we are secure" statement IMO.
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
> "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
> 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.
> Andrew van der Stock
> Lead Author, OWASP Guide and OWASP Top 10
Eoin Keary OWASP - Ireland
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Owasp-codereview