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

Comments

Oh, this sounds like a good idea...

[fractoid]

TFA makes a very good point:

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.

Re:Oh, this sounds like a good idea...

[Renraku]

Inspectors of things like elevators are not responsible if their target checked out at the time of inspection, and later failed. For example, you could sign off on the construction of a bridge or an installation of an elevator because everything looked good, but when the bridge company doesn't maintain the bridge properly or the elevator company fails to do the same, the inspector is not held liable, even though they were certified as good.

Auditing a network should be the same way. Of course, an auditor should NOT be held responsible for undiscovered bugs or holes in software. Instead, their job should focus on general security. It would be like a bridge inspector trying to certify a bridge when the gravitational constant of the universe were in a state of flux. How do you guarantee that steel is the best material or that the iron won't suddenly turn liquid at room temperature? That about sums up the state of software development and bug discovery.

Re:Oh, this sounds like a good idea...

[Anonymous Coward]

but if the bank could demonstrate that it followed avery step without failing any of the certified process, then the blame would be on the certification authority - if the bridge of your example was built using a low quality concrete and falls, (an illegally low quality of concrete) then the inspector which allowed for that concrete to be used should be liable for the bridge fall.

Re:Oh, this sounds like a good idea...

[ArsenneLupin]

How do you guarantee that steel is the best material or that the iron won't suddenly turn liquid at room temperature?

Better analogy would be, how do you guarantee carbonated steel doesn't turn brittle in icy waters or how do you guarantee that the wind doesn't induce fatal vibrations matching the resonant frequency of the bridge.

Indeed, bugs do exist at the time of inspection, they are just not (yet) known. No change of laws of physics is required, only discovery of yet unknown (or underestimated) effects.

Re:Oh, this sounds like a good idea...

[noundi]

I highly doubt that's even the case. The bank would probably have to prove that the breach could have taken place even at the time of auditing, not after, due to obvious reasons anyone can imagine. If they manage do to so the suit should be perfectly valid.

Re:Oh, this sounds like a good idea...

[Tom]

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.

Contrary to the precedent that no matter how much you fuck up, and no matter how blatantly false your audit report is, you're not responsible for anything, including not finding problems that are there when your whole job justification is that you're there to find these problems?

Stop worrying about the poor little techie. We're talking commercial enterprises here. The immediate effect will be that auditing companies take out insurances to cover this risk, and the price of audits goes up a little. However, the secondary effect will be that audits do, in fact, improve, because the premiums on your insurance depend on how often you fuck up and the insurance company has to pay for it.

Re:Oh, this sounds like a good idea...

[Rogerborg]

If they win this lawsuit, they're setting a dangerous precedent

How so? The principle seems clear enough that any audit, in any industry, is only a snapshot; why would you think a court would change that principle in this case?

The article indicates that the system wasn't CISP compliant at the time of the breach, but presumably Merrick can only prevail if they can show that the non-compliant that allowed the breach was also in place at the time of the audit. Do you think otherwise? If so, what leads you the conclusion that the sky is about to fall?

Re:Oh, this sounds like a good idea...

[asdf7890]

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.

IMO it depends on where the fault lies.

If the fault that allowed the problem is a property of the system that an auditor or penetration tester could be reasonably expected to have picked up on (such as password complexity and cycling rules not being present or not being correctly enforced) then maybe the case is valid.

If on the other hand the problem is outside the system that was audited (i.e. the breach was due to a user having stored/transmitted a copy of their credentials insecurely, or due to users/admins not being adequately trained, or due (or due in part) to software/configuration/network changes made after the audit was complete) then there is no way the auditor should be held responsible.

In reality all that will happen which-ever way this case goes is that there will be chunks of new boiler-plate exceptions text in future relevant contracts or the auditors will charge companies more in exchange for underwriting the extra risk. At work we are currently playing piggy-in-the-middle with the agreements for penetrations testing a new system we are building for a client and there is a lot of contracts work that goes on sorting out who is allowed to do what and who (us, the DC and equipment provider, the client and the 3rd party testers) is responsible for what now and going forward - this case will do no more in the long run than to add extra items to those lists (an increase the relevant consultation fees too, of course).

Re:Oh, this sounds like a good idea...

[Chris Mattern]

from what I've heard from my sister-in-law in the US the Americans don't have a similar "road-worthiness test"

It's up to the individual states, but most states have them. Here in Virginia, I have to get my car safety inspected once a year (and carry an inspection sticker on my windshield) and emissions tested once every two years (or they won't let me renew the car's registration).

Re:Oh, this sounds like a good idea...

[Ihlosi]

how do you guarantee that the wind doesn't induce fatal vibrations matching the resonant frequency of the bridge.

Quote from the linked page:

"In the case of the Tacoma Narrows Bridge, there was no resonance."

That bridge came down due to a profoundly nonlinear positive feedback effect (the deformation caused by the wind increased the area of attack, which lead to more deformation, etc), not due to the bridge resonating.

Re:Oh, this sounds like a good idea...

[Smidge204]

So in other words, if the bank can demonstrate that the cert authority didn't do its job properly, the cert auth can be held liable?

Sounds about right to me.

I'd like to see the certs creep up the line of development. Software used for high security applications should be certified at the developer level, and the installation and implementation of that software should be certified at the implementation level.

To continue the bridge analogy: The contractor needs to be licensed and insured, just as the inspector needs to make sure the materials and methods used are up to spec. Are developers held responsible for the quality of their products?
=Smidge=

Re:Oh, this sounds like a good idea...

[Anonymous Coward]

Sounds like you're assuming that being PCI compliant is in fact the same thing as being 100% secure, which is retarded. They were supposed to make sure the servers were PCI compliant... that is all.

Re:Oh, this sounds like a good idea...

[hairyfeet]

I can see the possibility of time playing a factor in this as well. To keep with the bridge analogy, if I get a bridge certified safe, and it falls down around my ankles in 3 weeks even though I did everything the certifying contractor told me to do, I can see where there would be a lawsuit.

To apply that to this case, if the auditor certified them to be PCI compliant and they followed all the rules and it fell down around them in two weeks I think it'd be safe to say the auditor may have missed something and be liable for it. So while I can't see the auditors having to worry long term, as there are just too many variables that they aren't in control of, i could see them being on the hook if a company can show they followed the rules and it fell apart in a short period of time, say six months. Because that to me would make me wonder if the auditor was overworked and missed something small. And as all of us tech guys know it is the small things you overlook that come back to bite you in the ass.

Re:Oh, this sounds like a good idea...

[Opportunist]

Security is a 24/7 process. Audits are snapshots thereof.

There are quite a few companies that dread and fear their 9001 or (even more) 27001 renewals because they are "so much work". Yes they are, if you're not sticking to the certification requirements (which you technically have to, after all that's what the sheet of paper that you get certifies).

Every time a company moans about "certification work", I question their certification worthyness.

Re:Oh, this sounds like a good idea...

[mysidia]

Except those two specific conditions, and in theory (how to prevent them) are well-known.

The unknown bugs software has are new cases entirely that cannot be examined a priori like a bridge's aerodynamics can.

Re:Oh, this sounds like a good idea...

[Nikker]

PCI compliance is mostly about network security and infrastructure, such as ensuring networks that service secured endpoints are isolated from networks that aren't. The auditor is really only there to attempt to mitigate and isolate known security issues that most shops don't bother to take too seriously. By starting this buck passing all you are really doing is starting a new age of insurance that you will need to take to cover the possible fraud that can take place rather than working with the banks to just keep it to a minimum and deal with the one offs. I do believe that if an auditor checks out a network / system and approves a network / protocol that is insecure by their own standards then of course it is the fault of the auditor and the responsibility of the auditors company to clean up the mess. As many are alluding to as far as OS exploits and the like no one is really able to prevent or anticipate all these possibilities and those are just the "breaks".

As I said before looking for a fall guy (especially when both parties are financially powerful) will never resolve anything rather than finding a way to screw the business running the system that was audited. This will likely be too much of a liability for many to handle and will rather come out of your pocket in other ways. If you think any financial type business will actually take responsibility on paper or other wise for anything then you are way to new to this game to be making decisions like this.

Re:Oh, this sounds like a good idea...

[JumpDrive]

Are developers held responsible for the quality of their products? Yes, Microsoft developers are held responsible for the quality of their products, can't you tell.

Re:Oh, this sounds like a good idea...

[mindstrm]

PCI covers more than just servers ---- it covers physical security, staff identification, physical access to paperwork, disposal, data retention, lots of corporate policies.......

Re:Oh, this sounds like a good idea...

[Zerth]

PCI is just troweling mortar on a crumbled foundation. Sure, it covers all the really boneheaded stuff, like using decent authentication and applying patches, but there is no part of it that says "don't use badly made(but it is expensive, it must be good) software on a fundamentally broken OS"

Re:Oh, this sounds like a good idea...

[ZouPrime]

Exactly. This is a very important disctinction that some peoples fail to grasp.

An auditor basically compare a situation vs a checklist of auditable issues. He's NOT there to find your security vulnerabilities and tell you to fix them. He's there to tell you that you do or don't respect requirement XYZ. If an issue isn't covered by the standard's requirements, well, what can he do? He can always make a formal observation, but that's beyond the scope of his responsabilities.

Standards such as PCI, SOX, NERC CIPs etc. aren't designed to protect you against all known threats, they are designed around the general, most common, most problematic security issues. A company can pass an audit and still be very insecure.

Re:Oh, this sounds like a good idea...

[???]

And they failed to do that.

They knew the processor had previously failed an audit because of storage of unencrypted PANs and non-compliant firewalls.

They provided an audit report that said "fully compliant" with CISP.

In the aftermath of the breach, it was discovered that the processor still had non-compliant firewalls and was still storing unencrypted PANs.

It appears that Savvis did not do their job. This will not be the big question at the trial, though.

Merrick was not in contractual privity with Savvis. Savvis was contracted by CardSystems, not Merrick. The issue at trial will likely be whether Savvis owed a duty of care to others that relied on their report (rather than just their client).

I would suggest that if an audit scheme is to have any benefit at all, it must accrue to those that rely on the audit findings. If 3rd parties cannot rely on the audit findings, then there is no reason to conduct the audit in the first place.

What about the Dufus?

[siloko]

Well much as I like people to be held responsible for the quality of their work I think it is a bit much to expect technology certification experts to be held responsible for the dufus who puts his username and password on a PostIt stuck to his monitor . . .

Kind of.

[Renraku]

If an inspector inspects and then signs off on an elevator, and the elevator subsequently catastrophically fails due to some reason the inspector should have caught, the inspector can be held liable, unless they can show that his inspection was somehow tampered with. Like perhaps the safety interlocks were just for show and didn't have any real parts inside of them.

Auditors should be held to the same standard, and given the same rights to defend themselves.

I don't want to sound harsh, but considering people pay auditors to do a job, if the job isn't done right, they need to suffer the consequences.

Re:Kind of.

[wirelessbuzzers]

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.

Re:Kind of.

[Rosco P. Coltrane]

You're correct that, if an elevator cable is frayed and the auditor missed it, he should be sued. However, audits aren't a way for businesses to shift the blame onto the auditor: they're a way for honest businesses to confirm that everybody (employees and contractors) and everything is in order at a certain point in time. If the auditor finds something that isn't right, his job is to inform his client, and perhaps propose remedies, but that's all. It's the business' job to implement the remedies. What I mean is, audits are a tools *for the client* to help do things right, that's all.

For instance, I once subcontracted in a company that used all manners of cracked software. A day or two before the IT audit was due, the manager used to go around telling employees to uninstall anything shady and put away copied CDs. The auditor would come, say everything was good, and the day after, all the cracked software were reinstalled. Is this the auditor's fault? The problem in this case is that the company needed the audit to be this-or-that-certified, in order to work for a certain customer. They didn't see the audit as a tool to help them do business better, but as an annoyance that could prevent them to do IT on the cheap.

Re:Kind of.

[Xest]

The problem is that auditors only check something at that point in time. They can't check that things are correct on an ongoing basis and they can't help it if what they're checking against isn't foolproof.

I used to support IT in schools, and was sent on a PAT testing (http://www.pat-testing.info/) course so that I could PAT test equipment in schools. One thing that was made clear on the course was that if we are not willing to do PAT testing we do not have to even if our employer tells us to. Why? Because if you sign off a piece of electrical equipment as safe and someone injures themselves because it wasn't safe a day later you could be liable - that sounds fair enough at first read through, but what if it really was safe when tested but something happened after testing, before the incident that led to it becoming unsafe? How can you as an tester foresee that? I actually refused to do PAT testing because of this, I simply was not willing to sign myself as liable for something I could not control.

Furthermore, many auditors for example, security auditors can check to ensure a company is complying to security policies, but what if those policies are flawed and a breach occurs because of that? The auditor was paid to ensure policies were followed, and it is the company that is paying for that who is at fault IMO if the policy wasn't enough. Say an IT security policy states that all security patches should be applied immediately, that's great, a security auditor could check that, but what if then there's a breach using a vulnerability for which there was no patch? Is it the auditors fault?

To me it's the company's fault again, the real problem is this, companies don't want to spend time and money on things they see no instant benefit from such as following security policies and procedures. They do the bare minimum they can and comply with the policies and procedures they have to - knowing full well that these policies and procedures are the bare minimum and insufficient for real security and good practice. There's always more that can be done, allowing them to shift the blame just means they'll struggle to find auditors.

Auditors do what auditors are supposed to do, if auditors do their job wrong then sure they should be liable, but I do not see how you can make them liable for something outside their remit. If you pay someone for a full security audit it's one thing, if however you pay them to ensure you're BS7799 compliant and you don't do anything over and above that but suffer a breach as a result of the fact there are things you can do over and above BS7799 then it's your companies fault.

The answer has to come down to the auditor's role, and if the auditor has audited what he's supposed to he should not be at fault. It is only when the auditor has accepted to do an audit and signed it off and that his audit was found to be at fault that he should be liable. In the example of the lift you state though, there is no way that we can know if the auditor was at fault, if he tested it and it really was safe, how could he be at fault if say over night a minor earthquake occured making the lift not safe? What if because of the nature of it he can't prove that it wasn't like that when he tested it? Should he be jailed for manslaughter? When he did nothing wrong at all, should he even have to suffer having his name dragged through the mud, possibly being suspended from work/losing his job in the process until he's finally found not guilty even though his life is wrecked anyway?

Companies should be held liable anyway, if a company gets screwed by a bad auditor it should be on the company to prove the audit itself was faulty. In other words, let's stick to innocent until proven guilty. If a company feels the auditor is guilty, let them prove it, not vice versa.

Re:Kind of.

[Tom]

The problem is that auditors only check something at that point in time. They can't check that things are correct on an ongoing basis and they can't help it if what they're checking against isn't foolproof.

The elevator guy has the same problem and yet it works in real life.

That is because in any real life situation, tests are indeed done repeatedly, such as every quarter, every month - or if they are really important, every day or every event. No plane in the western world takes off without the pilot and co-pilot having run through a standardized checklist first.

"But things can change" is a pretty bad excuse. Like the elevator (where wear and tear change the physics constantly), your system has to be resilient enough to withstand normal changes (e.g. wear and tear, different weights, etc.) at least until the next check. Unauthorized changes have to be hard to make unintentionally (that's why there's no "cut the cable" button inside the elevator).

It really isn't that hard. It works in thousands of areas, many of whom are non-trivial and technically complex (e.g. airplanes). But for some reason, we think it's impossible to do it in auditing and software?

Re:Kind of.

[Opportunist]

Oh tell me about it.

I've done more than one security test for companies that boast 27001 certs, only to succeed with the most basic systems of social engineering or inside jobs. More often than not I get paid to shut my mouth rather than talk about how stellar the security of the company is.

The general reactions are quite different, too. Some companies are genuinely interested in security and they're quite happy when you find a loophole in their process. Most, though, just want a signed paper and get rid of it.

Re:Kind of.

[Tom]

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.

Costs...

[Bert64]

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.

Liable for what, exactly?

[getuid()]

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.

Re:Liable for what, exactly?

[Tom]

I think people should *very* hard try to distinguish between the two scenarios:

I think people should try harder to understand auditing.

Static audits are a thing of the past. Every audit and compliance proceduree AD 2009 includes not only checks of the current system state, but in fact puts more of a focus on changes. More precisely: Change management. In a properly certified and audited system, it ought to be impossible to change the system in a compliant way into a non-compliant state. Either your changes are part of the proper change procedures, or they are not. If they are not, then you (i.e. the guy doing the non-compliant change) is responsible, because you broke procedure. If the change is OK, but its effects are not, then the change process is faulty and whoever audited it didn't catch that.

One way or the other, you very clearly find a culprit if you include change management into your processes.

And any auditing that (2009) gets signed off without containing change management should never have been signed off in the first place, so again the auditor is clearly at fault.

Wow

[Peregr1n]

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!

In PCI the auditor does not certify

[hugetoon]

After conducting an audit of a Merchant et a PSP (payement service provider), a QSA (qualified security assesor) issues a ROC (report on compliance to PCI-DSS) that is submitted du issuers (VISA, Mastercard, Amex, JCB and Discover).

Then the issuers certify the auditee.

An individual can not be a QSA by itself, it has to work in an organization that is qualified as well. Among other things a QSA organization has to provision a HUGE amount of cash in case it is found liable of having unduly declared an auditee compliant.

When a breach occurs, there is an investigation and eventually it is found that the ROC was not accurate by the time of the audit in such case the QSA organization and the QSA individual are in trouble.

BTW a certification is only for one year.

Now the case is not about PCI-DSS but "Cardholder Information Security Program" (CISP) and the breach happened in 2005.
Therefore I think the outcome would not have much impact on PCI program where liabilities are well defined.

Re:In PCI the auditor does not certify

[hemp]

CISP applied to Visa only. At the time, each payment card was instituting a separate security program. Due to feed back from merchants, all of the programs were rolled into PCI.

PCI is very similar to the original Visa CISP program.

The standard can be found here in case anyone is wondering what all is involved in a PCI audit:
https://www.pcisecuritystandards.org/security_standards/pci_dss.shtml/

What is a certification worth?

[bradley13]

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

Audit Responsibility - Possibly a good thing.

[luftmatraze]

I am working in a large firm. Quite often new projects upon realisation require technical audits as well as "Life Cycle" audits for existing systems involved with billing etc. One point that needs to be clear. Audits are not cheap! These guys are paid between 1500-2000 per Man day. Presently this is done in essence without ANY liability as to the quality of their work. What needs to be established in this case is: 1. Technical Audits provide a snapshot of a system "at a particular point in time" - Did at the time of the Audit these holes exist, or where there changes afterwards which could have affected the audit results? 2. Audit Scope. This is really important! If the Audit scope didn't include for instance the visibility of the systems from outside of the firewall, then the perspective of the auditors were limited and therefore the audit itself is not complete. I have seen companies for instance that are ISO 27001 Certified....however.... the audit scope was only for a particular part of the company. This enables the company to suggest 27001 Certification when in fact it may not indeed be fully the case. Most likely the outcome of such a case would be an increase in costs to cover Liability (insurance or something of the like) on the part of the auditor. However it may well be also an increase in the quality and transparency (clearer scope, limitations etc.) of technical audit work. Both of these are positive outcomes! http://streetstyles.ch/ - Swiss Band & Fashion Tshirts

Re:Erh... I thought that was the point?

[Aladrin]

Exactly. A certificate -certifies- something. If it doesn't, it's not a certificate.

The real question here is: What should happen to the certifier if their certificate proves false.

I don't think this is a government question. If there's nothing in the contract about this scenario, then you paid for -nothing-. And if there is, you already know the solution to the problem... It's right in the contract.

They Aren't Liable Now?!

[DeanFox]

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

You don't understand what "certification" means

[TrueKonrads]

I am an IT auditor working for a company that You would call if You would want to be certified.

Certification means that there is a work (audit) programme that states control objectives. Auditor follows this programme very closely and then, if the issues are within some zone of tolerance (which may be zero as well), auditor writes a statement that company XYZ is compliant with this and that.

What it does NOT mean is:
  a) a certified company will follow its practice after certification (they may just have put a convincing show).
  b) that there are no other issues with the company that are outside of work programme
  c) that sysadmin will be dilligent in future to apply timely patches

A PCI-DSS compliance says "There are no critical issues on the surface". That's it.

Sued for what exactly?

[Klync]

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.

This is a perfect example of why Wiki sucks balls.

[HornWumpus]

Damn Wikipedea sucks balls.

Some moron gets it into his head that the Tacoma Narrows bridge failed due to 'aeroelastic flutter' not resonance. The definition of 'aeroelastic flutter' begins with the description:

Flutter is a self-feeding and potentially destructive vibration where aerodynamic forces on an object couple with a structure's natural mode of vibration to produce rapid periodic motion. Flutter can occur in any object within a strong fluid flow, under the conditions that a positive feedback occurs between the structure's natural vibration and the aerodynamic forces.

Emphasis mine

In any case the bridge was visibly in resonance torquing in its second harmonic. WTF do you think 'natural vibration' means.

The editor of the Wiki article goes to great lengths to prove he doesn't really know what resonance means. He quotes some profs point that there wasn't resonance between the vortex shedding and the natural frequency (something started it torquing, ). Completely missing the point that flutter is still resonance.