| About InfoWorld : Advertise : Subscribe : Contact Us : Awards : Events : Store |
 |
||||
|
||||
 | ||||
 |
|
|||
 | ||||
|
|
|
||
|
||||||||||||||||||||||||||||||||||||||
 NEWSUCITA and national security By Ed Foster January 3, 2002 3:49 pm PT THE EVENTS OF Sept. 11, 2001 taught us that our enemies are ready to take advantage of any weakness to do us harm. One weak link is UCITA (Uniform Computer Information Transaction Act) and the security holes it encourages in government and corporate information systems. As a matter of national security, UCITA has got to go.
If the National Conference of Commisioners on Uniform State Laws (NCCUSL) and the states that have enacted UCITA follow that recommendation, it would certainly be a move in the right direction. It's wrong to assume, however, that the self-help ban will actually fix the model law's fundamental security flaws. UCITA is filled with language that encourages software publishers to secretly deploy remote disabling devices in their software and offers them legal protection should those devices be discovered and exploited by others. Even if electronic self help is banned, UCITA will still contain its "automatic restraint" provision (http://www.infoworld.com/articles/op/xml/00/08/21/000821opfoster.xml) that authorizes the deployment and use of much the same kind of backdoors and timebombs, and without any of the safeguards against vendor abuse that the electronic self-help provision used to have. Coupled with the "terminate at will" language found throughout the draft, UCITA gives carte blanche to any software publisher who wants the ability to force customers into upgrading by disabling older versions of a program. UCITA's proponents have pointed out that automatic restraints can't be banned because they clearly have some legitimate uses. A time bomb that turns off a free demo version after 30 days, for example, is a disabling mechanism that works to potential customers' benefit by letting them try before they buy. What security-minded opponents object to, however, is the lack of any requirement that customers be informed of the existence of these restraints. From a security point of view, the possibility that programs already residing on corporate or government networks might contain undisclosed destructive or restrictive code can lead to any number of nightmare scenarios. The inadvertent triggering of a disabling mechanism due to a bug -- even in a program that is not itself part of a mission critical system -- can wreak havoc in a complex network environment. I'll leave it to your imagination as to what technically sophisticated terrorists might do if they were to gain knowledge of how to use one of these software-disabling mechanisms. Beyond the issue of remote disabling of software, UCITA remains riddled with security issues. Just as one example, UCITA would offer protection for a software publisher who, through gross negligence, infects its customers with a virus. The drafting committee rejected all attempts to require software developers to take care that their products are free from viruses or other contaminants. The concern expressed by many over UCITA possibly validating shrinkwrap prohibitions against reverse engineering also has a security aspect. Reverse engineering techniques are often used in detecting and repairing security holes in systems. UCITA, even with the changes regarding reverse engineering recommended by the drafting committee late in 2001, still appears to allow software publishers to prohibit such activity. Then there's the thorny issue of how to keep manufacturers of ordinary goods from deliberately designing their products with some gratuitous electronic intelligence just so they can be covered under UCITA's vendor-friendly rules. As I've noted before (http://www.infoworld.com/articles/op/xml/00/12/04/001204opfoster.xml), this could lead to all manner of poorly designed products -- even problematic security devices. Would you want to fly on a plane if the baggage was checked for bombs with a device that's no more reliable than your average desktop operating system? Going even deeper into UCITA's core, a fundamental security problem with UCITA is that it removes any legal repercussions a publisher might face over not openly disclosing known problems in its software, including security flaws. All along, an important change most earnestly desired by some UCITA opponents, me included, has been a provision that would at least expose publishers to serious consequences for damages caused by known but unrevealed bugs. No such compromise was ever seriously considered. It's not surprising. Any attempt to fix UCITA's security problems will fail because it will change the most basic things the law does. By giving all the common shrinkwrap warranty disclaimers and damage limitations the force of a legally binding contract, UCITA is all about protecting software publishers and online service providers from responsibility for even the grossest defects of hastily developed, badly tested products. Poor quality information technology products inevitably make us more vulnerable. It once made sense to some that high tech industries should have special dispensation to inflict us with products that might be buggier than they should be. Now when we know how intent our enemies are to turn our every weakness against us, that's not just an idea whose time has passed. It's a concept that is positively dangerous. SPONSORED WHITE PAPERS 
SPONSORED LINKS
|
||||||||||||||||||||||||||||||||||||||
|
||||||||||
|
||||||||||
