“Rather than analyzing a hypothetical situation where a company is hacked by one of several means or subjected to the involuntary mass-propagation of a virus or worm, let’s focus on a real-life incident, dissect each component supported by fact and effectively diagram a blueprint for how you cannot only be targeted for a lawsuit or criminal prosecution, but demonstrate how you will lose. This loss will inflict a financial casualty, which may dramatically impact an organization’s fiscal health.”
His example is of a financial institution that had a web page defaced, apparently because it hadn’t applied a patch to its IIS 5 (Microsoft’s Internet Information Server version 5). Yet no customer or financial data was compromised as a result of the attack. Nonetheless, the financial institution had a responsibility to provide access to financial information and transactions to its customers, and according to news reports, customers had limited or no access during the attack. So was the financial institution negligent? How would you prove it?
Laws for negligence vary per state, but in the U.S. there are now a number of national laws that take precedence, such as Sarbanes-Oxley, HIPAA, and the Gramm Leach-Bliley Act. These permit discussing this case in specific terms, including quantifiable harm, opportunity, and motive. Carter goes so far as to say:
“This scenario will ultimately lead to share holders targeting corporate executives as being personally liable seeking seizure of personal wealth and even criminal sanctions.”
Technical IT and security personnel probably won’t avoid involvement, either; at the least they may be deposed in a lawsuit.
In such a situation I think I’d be for all three of a high standard of diligence, robust D&O insurance, and Internet business continuity insurance. And if I was a system administrator, I’d want specific policies that I could follow to the letter, so as to avoid being the target of a lawsuit.
Note that Carter’s example case did not involve a cracker specifically targeting that particular financial services institution for any reason other than that it happened to be running an unpatched copy of IIS, along with a number of other organizations that were attacked. So this was a force majeure event in the sense that it was not specifically targeted and had aggregate effect. However, there were things the financial institution could have done, but didn’t, of which patching the software was only the first.
Carter includes an interesting timeline showing patching shortly after point of discovery as manageable risk, developing over time still not patched into negligence and eventually gross negligence. And he compares typical cost for a system administrator to apply a patch versus fines and fees in a court case: they differ by more than a factor of 100.
In such a situation I think I’d be for all three of a high standard of diligence, robust D&O insurance, and Internet business continuity insurance. And if I was a system administrator, I’d want specific written policies approved by corporate executives that I could follow to the letter, so as to avoid being the target of a lawsuit.
Carter also mentions settlement of a lawsuit as being preferable to litigation partly because of risk of public exposure and resulting loss of reputation and perhaps financial consequences. I wonder if we shouldn’t turn that around and establish reputation systems that discover unapplied patches, nonredundant routes, congestion, etc., inform the affected enterprise first, and after a decent interval make remaining problems public. Such a reputation system would be tricky to implement, since it would not want to invite crackers to attack. However, it might be possible to do it in such a way as to encourage enterprises to patch and deploy so as to avoid security problems. And while I’m not a lawyer or a police detective, I would guess that companies that patched when warned would be less likely to be held liable in legal cases.
Carter’s article is a very interesting nuts and bolts examination of just what legal liability might mean for a specific case. There are a number of points in there that I suspect many enterprises have not considered. Well worth a read.
-jsq