http://news.com.com/2010-1022_3-5129350.html December 19, 2003 By Charles Cooper After a run of corporate scandals at the likes of Enron, WorldCom, Arthur Andersen, Tyco and others, Congress enacted the so-called Sarbanes-Oxley bill in 2002. The intent was to remedy the U.S. accounting system, which had allowed corrupt managers to take advantage of gaping holes. The new law now holds senior executives and directors of public companies responsible for the preparation and approval of their business's financial statements. Although the final verdict on the law won't be in for several years, this much is clear: If a CEO gets caught with his or her hand in the till, Sarbanes-Oxley makes sure that there's a comfy jail cell waiting in a federal penitentiary somewhere. There's a lesson here for the debate over how best to proceed on cybersecurity: Whatever its imperfections, the lesson of Sarbanes-Oxley is that if you want results, scare the hell out of 'em. You can count on companies to talk about implementing cybersecurity guidelines and best practices until they're blue in the face. Truth be told, however, you won't see major changes until the law holds actual fannies to the fire. There's no doubt that finding the right balance between coercion and voluntary compliance is a balancing act. But the last thing anyone should want is a repeat of the HIPAA fiasco. The Health Insurance Portability and Accountability Act of 1996 was ostensibly designed to protect workers' health coverage. Unfortunately, it doesn't have real teeth, because there's no auditing by the government or by independent third parties. (The Department of Health and Human Services will only audit a company in response to specific complaints.) While some companies are working very hard at complying, others are not--and not getting punished. No single set of best practices will apply to every company. Still, there's no reason that the software business can't adhere to a measurable benchmark. After all, the federal government regularly conducts audits based on set standards. That makes it clear to everyone what the game is. Why can't something similar apply here? Beats me. The issue has become too polarized, with pure laissez-faire advocates on one side and uber-regulation fanatics on the other. Somewhere in between, I suppose that there's a sensible middle ground that involves market mechanisms as well as government prodding. Shouldering responsibility The best answer, ultimately, resides with the software industry, in which folks intimately know what's wrong. What's more, no less than 80 percent of the known cybersecurity incidents result from vulnerabilities in software, according to former White House cybersecurity czar Richard Clarke. "We could do an enormous amount in cybersecurity by eliminating common errors," he said. "Very sloppy mistakes are made all the time, because people want to get their software to market quickly...If we could fix that problem, we could really take most of that issue off the table." Some have suggested pushing more liability on to the manufacturers. They say what's missing is a real-world incentive to convince companies to move beyond arguing that software can never be perfect. We don't need it to be perfect, they say, we need it to be safe. No argument there. But the only folks truly keen on trotting down that path are lawyers. Do you really want courts making decisions they're not competent to make? Yet, if the industry fails to organize itself and upgrade quality compliance standards in products, then tort hell, here we come. So in the spirit of the season, I'll offer this gift advice to software CEOs considering their next step: Jot off a quick morning note to your chief technology officer, nothing fancy, just this: "If I go to jail, so do you." When all else fails, that's guaranteed to command serious attention. And who knows, maybe it will be enough to break the logjam. -=- Biography Charles Cooper is the executive editor of commentary at CNET News.com. - ISN is currently hosted by Attrition.org To unsubscribe email majordomo@private with 'unsubscribe isn' in the BODY of the mail.
This archive was generated by hypermail 2b30 : Mon Dec 22 2003 - 06:04:24 PST