Its been a bad month. weve learned of critical loopholes in recent versions of Windows and in even more versions of Microsoft Word. A month like this—a month of drawing up budgets for many—gives IT managers fair warning that future problems of this kind may well occur and that its part of their job to be ready with both strategies and resources.
At 3 a.m. Sept. 8, I was trying to get actual work done when I was interrupted by a SANS Critical Vulnerability Analysis. It warned of a macro execution loophole in every version of Microsoft Word beginning with the venerable, but still widely used, Word 97. Regardless of security settings, I learned with dismay, a maliciously crafted .doc file can execute macro code that runs with all of the users privileges.
Its exasperating that theres no distinction between the privileges that you have from a console window—from which you might actually want to format a hard drive—and the more limited privileges that youd typically want within a word processing session. Im tired of pointing out the wrongheadedness of this model, which dates back two decades to the time when any code on a machine was there because the user wanted it there. In this era of transparent connectivity to unknown service providers, all IT buyers should be demanding that platforms limit the privileges of a process to those that are needed to do its intended job.
Microsofts .Net, and also, of course, Suns Java, both offer good answers to this question—but we have years of work to do before those answers will span the IT stack.
Further reading
The first phrase that crossed my mind, after being reminded of this laxity of security in Word, was the punch line of an old and tired joke: "Doctor, it hurts when I do this." "Hmm," the doctor replies, "dont do that." Rather than distributing documents as .doc files, a format thats both proprietary and insecure, it makes more sense for users to shun complex and risky application- specific defaults: to choose and use, instead, a fully disclosed file format with less risk of harboring undesired content.
Rich Text Format comes to mind or, for that matter, plain old HTML—without ActiveX controls. Adobes PDF, with only two known malware cracks to date, is another candidate, especially given the growing availability of PDF authoring tools for many platforms.
The same question should guide format choice for other forms of data: Whats the least complex, most universal format that adequately captures the content? This approach will cut costs by promoting competition among application and tool providers, as well as by leaving time-wasting demons with fewer places to hide.
The second phrase that came to mind was, "Thats the last straw." That was my reaction to the Sept. 10 disclosure of two more holes in Windows RPC implementation: flaws shockingly similar to those that opened the door to Blaster, about a month earlier. Its impossible to give any credence to vows of better security when problems so similar are addressed in such haphazard fashion.
If we cant expect to see disciplined engineering that prevents these problems in popular IT products, or solves them in a reliable fashion when they occur, then we have to treat these problems like public health hazards or natural disasters. That means a continuing process of risk analysis that buys the protection we need, especially in the area of user training, but doesnt spend money on irrelevancies like crypto overkill or on overly Procrustean enforcement.
No enterprise IT boss should be afraid to budget for continuing investigation and remediation of platform and application defects. Its not a confession of incompetence. It is a mistake, though, for IT buyers to continue to remedy symptoms instead of attacking problems at their source.
Excessive behind-the-scenes automation, and ease of connection that gets too far ahead of control, are the enemies. Your next budget should reflect your plan to contain that complexity by getting data into the open—and by discarding, or disabling, the features of your platform that cause more trouble than theyre worth.
Discuss this in the eWEEK forum.
Technology Editor Peter Coffees e-mail address is peter_coffee@ziffdavis.com.
Research Assistant
