[Owasp-codereview] [Owasp-ireland] Potential of 4.2 million credit card details stolen via cyber attack.
eoin.keary at owasp.org
Wed Mar 26 06:08:48 EDT 2008
Re OWASP Top 10 compliant we, OWASP have a big issue here as many of the
vendors of scanning tools have an "OWASP Top 10" rule base that can be used.
OWASP have not been consulted on this to my knowledge so if one runs this
rule base and it comes up with no issues they can say they are OWASP Top 10
compliant. - plain silly IMHO
Also "Develop all web applications based on secure coding guidelines such as
the Open Web Application Security Project guidelines." - Sure they can do
that and say they do seen as OWASP does not have verification or
certification criteria. Who's to say they are not doing this, We have the
OWASP guides, dev, test and review but no certification.
Also one can be compliant and certified as such, next day not be compliant
but certified as compliant for the next 3 months until the next audit.
Expiration date & PAN are allowed to be stored (is a secure manner) but it
seems that the data was intercepted in transit (correct me if I am wrong).
Re storing CC numbers (PANS) many large popular store such numbers such as
Amazon.com, Play.com etc to "enhance the customer experience" and let the
customer purchase via 1-click.
On 25/03/2008, David Ryan <dave.ryan at gmail.com> wrote:
> 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 posted<http://www.hannaford.com/Contents/News_Events/News/News.shtml>on 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.
> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Owasp-codereview