Reasonable room for doubt at the moment, due to flaky details.&nbsp; However, their statement would negate Requirement 3 failure (if accepted at face value = during transmission):<br><br>[The Reg] &quot;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,&quot; Hannaford chief exec Ron
Hodge said in an open letter to customers <a href="http://www.hannaford.com/Contents/News_Events/News/News.shtml" target="_blank">posted</a> on the grocer&#39;s website. [/The Reg]<br><br>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&#39;s my day gone ;-)<br>
<br><div><span class="gmail_quote">On 25/03/2008, <b class="gmail_sendername">Andrew van der Stock</b> &lt;<a href="mailto:vanderaj@owasp.org">vanderaj@owasp.org</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I really doubt that Hannaford was PCI DSS compliant:<br> <br> * Requirement 3 - Protect Card Holder Data. Losing 4.2 million records<br> requires failing Section 3.1 &quot;Keep cardholder data to a<br> minimum&quot; (basically ditch the PAN and expiry as soon as you&#39;re done<br>
 with them), and Section 3.4 &quot;Render PAN, unreadable anywhere where it<br> is stored&quot;. FAIL.</blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
 * Requirement 6 - Section 6.1, keeping up with patches. I don&#39;t know<br> of any site that meets PCI&#39;s 1 month deadline to install new patches<br> for critical components. It would be surprising to me if Hannaford did<br>
 this. Possible fail.<br> <br> * Section 6.5 - do a Top 10 review. This is the old Top 10 2004. 6.5.8<br> is &quot;Insecure storage&quot; - enough said! FAIL<br> <br> * Requirement 10 - Monitor and Test Networks and Requirement 11<br>
 Regularly Test security systems and processes. In particular section<br> 10.6:<br> <br> &quot;Review logs for all system components at least daily. Log reviews<br> must include those servers that perform security functions like<br>
 intrusion detection system (IDS) and authentication, authorization,<br> and accounting protocol (AAA) servers (for example, RADIUS).&quot;<br> <br> and 11.3.2 - conduct annual application layer pen tests<br> and 11.4 and 11.5 which says to install network and host IDS and<br>
 network IPS and file integrity monitoring software. These should have<br> immediately notified admin staff of changes.<br> <br> Hannaford didn&#39;t detect the breach for nearly three months. That<br> implies a lack of effective intrusion detection and monitoring EVEN if<br>
 they had the above items in place, operational, and logging<br> successfully, and someone is monitoring them. Which I highly doubt.<br> FAIL.<br> <br> Arguable:<br> <br> * Section 6.6 - mandates a code review or a web application firewall,<br>
 but only AFTER JUNE 30. They can be compliant up to now with neither<br> of these in place. We know that WAFs today are simply not enough to<br> prevent attacks from a motivated, skilled attacker. They are great<br> defense in depth and they do knock out script kiddie attacks. If<br>
 Hannaford obtained a code review, then the assessor wasn&#39;t<br> particularly good, or the firm refused to fix known issues, or both. I<br> think this is the area we will see the lawyers involved with if it can<br> be argued that 6.6 is REQUIRED to be complied with today. I don&#39;t<br>
 believe so.<br> <br> In my personal opinion, even given the limited information that is<br> public, from the first two issues above alone, we can assume Hannaford<br> were/are non-compliant.<br> <br> PCI DSS makes it abundantly clear what folks must do to be safer:<br>
 <br> Step 1.&nbsp;&nbsp;Don&#39;t store CC numbers. Really, really, really don&#39;t store<br> them. You don&#39;t need them.<br> Steps 2..153 However, if you want to damage your business reputation,<br> destroy customer confidence, lose shareholder value, set a bunch of<br>
 money on fire by protecting information you don&#39;t need (and shouldn&#39;t<br> want), then here goes... do this wishy-washy list of items. But do it<br> properly, or you&#39;ll get pwned.<br> <br> Hannaford ignored #1 and got pwned even though they did *some* of the<br>
 next 153 steps required for PCI DSS. In PCI DSS 1.2, they really<br> should make it real short and sweet:<br> <br> There are no valid business reasons for storing CC&#39;s. If you do, you<br> fail PCI DSS compliance. This is how you use authorization numbers for<br>
 these common business cases:<br> <br> That&#39;s a one pager in my view.<br> <br> thanks,<br> <br>Andrew van der Stock<br> Lead Author, OWASP Guide and OWASP Top 10<br> <br> <br> <br> <br> </blockquote></div><br>