Slashdot Mirror
Should Auditors Be Liable For Certifications?
dasButcher writes "Enterprises and mid-size business rely on auditors and service providers to certify their systems as compliant with such security regs and standards as PCI-DSS or SOX. But, as Larry Walsh speculates, a lawsuit filed by a bank against an auditor/managed service provider could change that. The bank wants to hold the auditor liable for a breach at its credit card processor because the auditor certified the processor as PCI compliant. If the bank wins, it could change the standards and liabilities of auditors and service providers in the delivery of security services."
What will be interesting about this lawsuit is how the court assigns responsibility for a breach at a certified business. Audits, by their very nature, are point-in-time or snapshot checks. They cannot account for the dynamic variables of business and IT operations that may weaken security over the long-haul.
If they win this lawsuit, they're setting a dangerous precedent - anyone who at any stage has certified a system as secure becomes responsible for its ongoing security, and can potentially be held liable for stupid user errors by users of that system.
Rampant carbon sequestration destroyed the Dinosaurs' tropical paradise. I'm here to help repair the damage.
All it will do, is make future certifications 10 times slower, more invasive and more expensive... This bank is shooting themselves in the foot because they will have to get themselves certified again in the future and will be expected to pay a hefty premium.
Besides, the auditor merely certifies that a particular defined system complies with a given spec at a point in time... They don't assert that the setup is secure, merely that it complies with the letter of the standard, and most of these standards are poorly written with loopholes big enough to drive a truck through.
Not to mention that there are ongoing changes, such as patching and updates to signature files etc, do you need to recertify every time a minor change is made? A minor change could introduce vulnerabilities, for instance a security update could introduce new features and bring with it new exploitable issues while it also fixes an older issue.
How widely do you define the scope? ideally you would include absolutely everything associated with the system, so every workstation used for admin purposes, every inch of cabling etc, this would make the scope very large and costly to deal with.
And how about the age old question of human error? No matter how secure a system is, an error (or intentional attack) by the legitimate users could break things in all manner of ways.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
I agree, but it's hard to say what standard auditors should be held to. Often, computer security audits are just surface level checks: they check your design docs and your testing methodology. And this is fine, but you get what you pay for. If a bug slips through your tests, or worse if you don't actually implement your design docs or tests, the auditors obviously shouldn't be liable. On the other hand, if there's a flaw that the auditors "should" have caught, and they don't, they should be liable at least to some degree.
The difficulty is that full, in-depth code audits are very, very hard. Consider the Linux kernel or OpenSSL: even after 16 years of "many eyes" treatment by engineers and security researchers across the world, serious bugs keep showing up. As a result, the fact that the auditor missed something doesn't mean much, and it's not clear that a court will be able to decide whether the auditor "should" have caught it.
I wonder if the same problem is present in other industries.
I hereby place the above post in the public domain.
Should the auditor be liable for mis-certification? Or for the (correctly) certified system not withstanding attacks?
I think people should *very* hard try to distinguish between the two scenarios:
1) An auditor certifies a system as XY-compliant as of [insert date here]. However, it can be demonstrated that the system was *not* XY-compliant at that date.
2) An auditor certifies a system as XY-compliant as of [insert date here]. However, at a later date, the system breaks for some reason. It can be proven that the system was XY-compliant, but for some reason (stupid user interaction?) is not anymore. Or, even better: it can be proven that the system *still* is XY-compliant, but the XY-standard is unfit to defend [insert attack here].
I think in case (1) the auditor should be held liable, since he obviously certified something that didn't meet the promised standards. However, in case of (2), not the auditor is to blame. If the system breaks despite of the certification, then it's not the auditor's fault -- it's how things work, and making a scapegoat out of the auditor is not going to do anybody any good. Even worse, if the system fails to meet standard XY because a stupid user (or admin, for that matter) interaction *after* the certification, then there's no way an auditor could have prevented that -- it's either the user/admin's fault for interfering with a certified system, or the standard's fault for not defining what a user/admin is allowed to do with the system without interfering with its certified qualities.
The big banks really are intent on shooting themselves in the foot. If they hold the auditor liable for security breaches, nobody else will be willing to offer certification services for PCI-DSS. And considering that it's the banks who desperately want everyone to be PCI-DSS compliant (does anybody other than the banks get any benefit from it? Really?), that is particularly stupid.
It's hard enough achieving compliancy as it is - whenever we get near to completing the questionnaire, they change all the questions!
The question is: does a certification have a value, or not?
Consider an example in a different area: accounting. At the end of the year, a public corporation must have its accounts certified by an auditor. The audit essentially states that the accounts are an accurate reflection of the company's financial state - that the accountants haven't "disappeared" a few million dollars into their private accounts, or whatever.
If the accounts turn out to be fraudulent, the auditors have failed - and it is entirely correct to sue them.
Back to IT certifications: if the audit missed something, then it is entirely appropriate to sue the auditors. If the security breach was not due to problems the auditors should have caught (inside job, violation of established procedures, etc.), then the auditors should not be liable.
Consider what happens if you do not hold the auditors liable: a very current example from the financial world. The ratings agencies said that derivatives based on sub-prime mortgages were top-quality, low risk investments. Screwing up a rating costs them nothing, so they gave in to political pressure and rated these derivatives too high. Had they been liable for the consequences of their ratings, they would have done a better job. At least, one would like to think so - sadly, there is no way to go back and test this hypothesis...
Enjoy life! This is not a dress rehearsal.
A Notary Public can be held responsible but an auditing firm isn't? I would have thought they already were held liable. If they're not, what a great job! Like a Notary Public that can stamp, validate and vouch for anything without cause for concern. It's probably because the Notary is people. The auditors are corporations. Corporations are just like people absent accountability or morals. Corporations are like Sociopaths. And as they're running the show, corporations are like Sociopaths in an Anarchy.
-[d]-
It's not that it's impossible to do in auditing and software at all... it's entirely feasible. The issue is cost - those checks (by pilots, co-pilots, et al) and required maintenance cost airlines a significant amount of money, but it is paid because: regulations say they have to, and the cost of a rash of failures is terrible PR. In the IT world, companies want to be certified, only because they have to, and don't want to spend much money on that compliance. That's totally ignoring the companies (typically small to medium sized) that don't have the resources to expend on "doing the audit right". It's apples and oranges.
No, it doesn't.
If you are "too small" and "don't have the resources" to fly a plane safely, then you can't play in the commercial airlines market. Tough luck, but we're all better off this way, thank you.
Now there are other markets, where quality isn't that important, and failure not half as critical. You could become a hairdresser, for example. Could still ruin someone's looks, but not their life. That's why hairdressers do not have to check all their equipment before cutting your hair.
And I dare to claim that software in many appliances is quite capable of ruining not one life, and not hundreds, but many thousands, or whole populations. Think of the software that drives the stock markets. Same for auditing. If you audited a bank in 2008 and you didn't notice that it's all a huge house of cards that's going to come tumbling down sometime in the near future, then you didn't do your job properly.
Assorted stuff I do sometimes: Lemuria.org
I'm surprised nobody mentioned this yet: adherence to PCI-DSS does not necessarily guarantee that your system cannot be cracked or broken into. PCI-DSS provides a set of guidelines - created by the banks and cc companies themselves - which must be met in order to be considered safe enough to be allowed to process transactions. Now, if the auditor was negligent or deceptive in certifying the system as compliant, this seems like a no-brainer lawsuit. However, it is entirely possible that the system *was* compliant, but got cracked anyway.
----
Not to be confused with Col.