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

David Ryan dave.ryan at gmail.com
Tue Mar 25 12:04:51 EDT 2008


The companies that perform the certification are required to be QSAs [1].
So, in theory, the expertise in deciding whether or not the controls are
suitable should be found there. I believe the only aspect of your PCI
project that a QSA cannot help with is implementation of controls, but they
can/should/will for extra money provide the necessary guidance regarding the
standard. Will this guidance always be correct? The same? Useful? Maybe not,
but at the end of they day the objective is to find a suitable agreement
between client and QSA on what controls should be in place and whether these
are suitable. This is also how things work during an ISO27001 certification:
Your risk assessment and management activities justify what controls are
required and management procedures measure the effectiveness of these,
certification being granted on the continuing adherence to (mostly) your own
stated objectives in line with the standard. Again, accredited organisations
can provide guidance (similar caveats) but can't get their hands dirty.
Certification holders are like graduates, some are clearly PhD material and
others are not, but you use the resource you have or can afford to get the
job done. The quality might be different, but it doesn't mean it's always
wrong.

The quality of the QSA (individuals and organisations) are likely to vary
(only human), but achieving the stated goals should carry a reasonable
consistency (would be interesting to see PCI do some analysis and anonymous
reporting on this). In the case cited (hannaford) the details are sketchy,
but apparently they were compliant. Unless PCI can find negligence on either
part (presumably there's an investigation due or taking place already), then
the insurance policies of the PCI member organisations will probably kick
in. I wonder what the PCI members premium reductions were based on the
PCIDSS? ;-) Of course as someone quite rightly pointed out: The Criminal
should be blamed; but if you leave your car window open in Castleknock,
you're asking for your horn to be beeped.

It might be worth highlighting that the aim of the PCI is not to provide
security controls for the entire organisation, but to ensure the PCIDSS
defined controls are in place to protect card holder data. I like to think
of PCIDSS as an insurance policy, rather than the security standard the
world has so earnestly waited upon. In my experience of PCIDSS,
ISO17799/27XXX, cobit, and others it appears obvious that these "best
practices" are "good practices" but usually only as good as the expertise of
the team that designs, implements, and (perhaps most importantly) manages
them.  That's not to say that the standards are themselves bad, it just
highlights that they fulfill an objective and I believe that object is not
to provide a framework to ensure you "never get hacked", but to ensure that
you have a set of controls in place that cover a range of strategic and
operational security controls in place suitable to the type of data you
protect (PCI specifically focusing on cardholder) and the capacity of your
organisations resources (financial, people, etc). How this is achieved is
left to the organisation, but it's not a complete failing of the standards
if something goes wrong. Standards can't tell you what firewall to buy, or
what amount of documentation you need in place, or whether you should code
in Java, dotNET, or TCL/TK (!). OK, they could if the standards stated those
things, but imagine the amount of standards we would have then!

I do agree with you that PCIDSS has quality issues and it misses or glosses
over some key elements, but again if we take the incremental view then
perhaps these can be worn now and washed in the future? There are plenty of
software apps out there that continue to offer *ancient* attack classes that
we would all love to see eradicated from code, yet we continue to use them
anyway, perhaps in the hope or under the observation that they may and will
get better (no names). Perhaps there already exists a Security Standard
Secure Security Development Security Lifecycle ...

Disclaimer: I'm giving my experience and knowledge of the subject matter,
which may or may not be totally based on fictional scenarios.

[1]  https://www.pcisecuritystandards.org/programs/qsa_program.htm

On 25/03/2008, Eoin <eoin.keary at owasp.org> wrote:
>
> David you have hit the nail on the head regarding the expertise in
> understanding standards such as PCI.
> This is a real big issue as following the PCI standard in a blind
> compliant fashion is a complete false sense of security. The PCI standard is
> technically incorrect in some of its assumptions for a start.
>
>
>
>
> On 25/03/2008, David Ryan <dave.ryan at gmail.com> wrote:
> >
> > I think interpretation of standards leads to a level of security that is
> > reasonably required by the organisation interpreting them. Of course, I
> > assume that the organisation is interpreting them with a modicum of
> > expertise in the field, which may be provided via internal resources or
> > through external consultancy. What they end up with might be "lower" than
> > what is "ideal", which may not be "perfect", but may be all that particular
> > entity can achieve at that stage of their
> > iterative-information-security-management-lifecycle. This reinforces my
> > original point, which evidently my elaboration failed to illuminate. The PCI
> > standard is applicable in different ways to different entities and this is
> > not only reflected in the ambiguity of the language within the standard, it
> > is also reflected in the multi-tiered compliance and conformance
> > requirements laid out by the PCI themselves.
> >
> > Objectivity is dead. Long live Subjectivity.
> >
> > Re: "breach". Granted, it is of concern, but perhaps less so considering
> > the information that was lost was the card issuers and not the private
> > information of the customer. I was also being somewhat facetious.
> >
> > On 25/03/2008, davidrook <david.rook at realexpayments.com> wrote:
> > >
> > > I fully understand that 100% security isn't realistic -  Thanks for
> > > the
> > > clarification though ;-)
> > >
> > > I agree that the standard will always be ambiguous but do you not feel
> > > that the interpretation of the standards is often what leads to a
> > > lower
> > > level of security than is required?
> > >
> > > My own opinion is that any breach like this is a big issue, from a
> > > consumers perspective if they have lost *any* data it should be a
> > > point
> > > of concern.
> > >
> > > Dave
> > >
> > >
> > > David Ryan wrote:
> > > > Dealing in absolutes is an error. There is no "secure". There are
> > > > security controls and depending on what, how, where, when, why, if,
> > > > biff, bam, and boom they are implemented and managed their effect is
> > > a
> > > > quasi-linear progression along the cost-versus-hardcore axis where
> > > > they intersect at the "good enough for us at this moment in time"
> > > > point. Compliance may equate to "good enough" security controls, but
> > > > suggesting there is a final resting point for IT expenditure on all
> > > > things security is folly.
> > > >
> > > > PCI has gone through a round of improvements and perhaps it will
> > > > continue to do so in the future. Whilst I don't have a history of
> > > > other safety standard from our recent industrialised history, I
> > > > imagine there are comparable observations to be made. Cars did not
> > > > start off with airbags and they still don't prevent people from
> > > > killing each other on country roads or on overpriced toll roads.
> > > >
> > > > As for the PCIDSS being ambiguous, I agree. However, I think this is
> > > > perhaps a necessary quality: Not all companies are equal. I would
> > > > suggest that VISA/Mastercard/AMEX/etc wanted to establish a baseline
> > > > for their own "insurance" purposes (imho and used here as a loose
> > > > term).  Does it raise the proverbial bar? In my experience, it
> > > > probably has done for some clients I've worked with and maybe not
> > > for
> > > > others, but again this is an example of the underlying intention
> > > > functioning (imho). Another example is BS7799/ISO17799
> > > certification.
> > > > No doubt any future attempts to provide a super-compliance-standard
> > > > will end up with ambiguity too.  The point is that the organisation
> > > > must interpret the "ambiguity" to suit their needs and explain why
> > > > they have interpreted it as such to the auditor and, where
> > > applicable,
> > > > compliance body.  The aim could be to provide the least amount of
> > > > ambiguity as possible, but being overly prescriptive would perhaps
> > > be
> > > > more prone to failure when issues such as capabilities, economics
> > > and
> > > > other factors are considered.
> > > >
> > > > As for who is to blame? I'm sure they both have insurance ... *if*
> > > no
> > > > personal data was lost, is this such a big issue? (from a consumers
> > > > perspective)
> > > >
> > > > On 25/03/2008, *davidrook* <david.rook at realexpayments.com
> > >
> > > > <mailto:david.rook at realexpayments.com>> wrote:
> > > >
> > > >     I think this is another example of PCI compliance being just
> > > that - a
> > > >     compliance standard. Being compliant (as is demonstrated here
> > > and with
> > > >     TJX) does not always equate to being secure.
> > > >
> > > >     PCI is ambiguous and it could be improved to try and make
> > > >     companies both
> > > >     secure and compliant. As for who is to blame, is it not a case
> > > of 6 of
> > > >     one and half a dozen of the other?
> > > >
> > > >     Dave
> > > >
> > > >
> > > >     Eoin wrote:
> > > >     > Maybe a bit slow on this one but I'd thought I'd share it
> > > >     >
> > > >     > A PCI compliant company was compromised and an estimate of 4.2
> > > >     million
> > > >     > cc numbers were obtained.
> > > >     > The issue arises that the company were PCI compliant and now
> > > the
> > > >     blame
> > > >     > game has ensued. The PCI assessors are being blamed, there is
> > > >     mention
> > > >     > of ambiguity regarding the PCI standard, where to apply some
> > > of the
> > > >     > technical controls etc..
> > > >     >
> > > >     > http://www.theregister.co.uk/2008/03/18/hannaford_data_breach/
> > > >     >
> > > >     >
> > > >     > http://www.hannaford.com/Contents/News_Events/News/News.shtml
> > > >     >
> > > >     >
> > > >     >
> > > >
> > > http://www.merchantcircle.com/blogs/Pre-Paid.Legal.Services.Inc.-.Ind.Associate.786-390-0581/2008/3/4.2-million-account-numbers-stolen-at-Hannaford-Bros.-Co./70643
> > > >     > --
> > > >     > Eoin Keary OWASP - Ireland
> > > >     > http://www.owasp.org/local/ireland.html
> > > >     > http://www.owasp.org/index.php/OWASP_Code_Review_Project
> > > >
> > > >     >
> > > >
> > > ------------------------------------------------------------------------
> > > >     >
> > > >     > _______________________________________________
> > > >     > Owasp-ireland mailing list
> > >
> > > >     > Owasp-ireland at lists.owasp.org <mailto:
> > > Owasp-ireland at lists.owasp.org>
> > >
> > > >     > https://lists.owasp.org/mailman/listinfo/owasp-ireland
> > > >     >
> > > >
> > > >     --
> > > >     David Rook | david.rook at realexpayments.com
> > >
> > > >     <mailto:david.rook at realexpayments.com>
> > >
> > > >     Information Security Analyst
> > > >
> > > >     Realex Payments
> > > >     Enabling thousands of businesses to sell online.
> > > >
> > > >     Realex Payments, Dublin, www.realexpayments.com
> > >
> > > >     <http://www.realexpayments.com>
> > >
> > > >     Castlecourt, Monkstown Farm, Monkstown, Co Dublin, Ireland
> > > >     Tel: +353 (0)1 2808 559 Fax: +353 (0)1 2808 538
> > > >
> > > >     Realex Payments, London, www.realexpayments.co.uk
> > >
> > > >     <http://www.realexpayments.co.uk>
> > >
> > > >     1 Hammersmith Grove, London W6 0NB, England
> > > >     Tel: +44 (0)203 178 5370 Fax: +44 (0)207 691 7264
> > > >
> > > >     Pay and Shop Limited, trading as Realex Payments has its
> > > >     registered office at Castlecourt, Monkstown Farm, Monkstown, Co
> > > >     Dublin, Ireland and is registered in Ireland, company number
> > > 324929.
> > > >
> > > >     This mail and any documents attached are classified as
> > > >     confidential and
> > > >     are intended for use by the addressee(s) only unless otherwise
> > > >     indicated. If you are not an intended recipient of this email,
> > > you
> > > >     must
> > > >     not use, disclose, copy, distribute or retain this message or
> > > any part
> > > >     of it. If you have received this email in error, please notify
> > > us
> > > >     immediately and delete all copies of this email from your
> > > computer
> > > >     system(s).
> > > >
> > > >     --
> > > >
> > > >
> > > >     _______________________________________________
> > > >     Owasp-ireland mailing list
> > >
> > > >     Owasp-ireland at lists.owasp.org <mailto:
> > > Owasp-ireland at lists.owasp.org>
> > >
> > > >     https://lists.owasp.org/mailman/listinfo/owasp-ireland
> > > >
> > > >
> > >
> > > --
> > > David Rook | david.rook at realexpayments.com
> > > Information Security Analyst
> > >
> > > Realex Payments
> > > Enabling thousands of businesses to sell online.
> > >
> > > Realex Payments, Dublin, www.realexpayments.com
> > > Castlecourt, Monkstown Farm, Monkstown, Co Dublin, Ireland
> > > Tel: +353 (0)1 2808 559 Fax: +353 (0)1 2808 538
> > >
> > > Realex Payments, London, www.realexpayments.co.uk
> > > 1 Hammersmith Grove, London W6 0NB, England
> > > Tel: +44 (0)203 178 5370 Fax: +44 (0)207 691 7264
> > >
> > > Pay and Shop Limited, trading as Realex Payments has its registered
> > > office at Castlecourt, Monkstown Farm, Monkstown, Co Dublin, Ireland and is
> > > registered in Ireland, company number 324929.
> > >
> > > This mail and any documents attached are classified as confidential
> > > and
> > > are intended for use by the addressee(s) only unless otherwise
> > > indicated. If you are not an intended recipient of this email, you
> > > must
> > > not use, disclose, copy, distribute or retain this message or any part
> > > of it. If you have received this email in error, please notify us
> > > immediately and delete all copies of this email from your computer
> > > system(s).
> > > --
> > >
> > >
> > >
> >
>
>
> --
> 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-ireland/attachments/20080325/80959f1b/attachment-0001.html 


More information about the Owasp-ireland mailing list