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

Eoin eoin.keary at owasp.org
Tue Mar 25 13:31:24 EDT 2008


Hi Andrew,
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.

ek

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.
> 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
>
>
>
>
>


-- 
Eoin Keary OWASP - Ireland
http://www.owasp.org/local/ireland.html
http://www.owasp.org/index.php/OWASP_Code_Review_Project
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-codereview/attachments/20080325/e9400c03/attachment.html 


More information about the Owasp-codereview mailing list