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."
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.
Job? I don't have time to get a job! Who will sit around and bitch about being broke and unemployed then?
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.
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
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.
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.
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=
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.
ACs don't waste your time replying, your posts are never seen by me.
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.
"If you make people think they're thinking, they'll love you; But if you really make them think, they'll hate you." - DM
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.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
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.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
PCI covers more than just servers ---- it covers physical security, staff identification, physical access to paperwork, disposal, data retention, lots of corporate policies.......
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.
As someone can grasp from going through a pci process, or even reading much of the docs. PCI-DSS has more to do with assigning liability(away from pci members) and insurance requirements, and holding credit-card "acceptors" responsible. It might improve security, but the real focus of it seems to be to assign the responsability of fradulent online card transactions away from the card companies, by pointing it to someone else.