eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
I wish that IT systems offered consistent truth in labeling. I want systems to disclose what they do and how they do it, and the means by which I can tell them not to do those things that I dont like.
Its hard to achieve that level of disclosure and control today, because we need so many different interfaces to ask and answer questions and give commands. The required tools range from oscilloscopes to debuggers to firewalls to UML diagramming aids—and perhaps, sad to say, even law books, and not just those written in English.
Wed do better if we could use a single higher-level language to exchange requests, offers, acceptances, and transactions of data and services among subsystems at every level. Thats the vision I discussed with Microsoft XML Web services architect John Shewchuk during a phone call last week, when we talked about Microsofts goal of bringing the clarity and loosely coupled resilience of Web services to local connections among PC subsystems, as well as among distant Web sites.
“From interprocess communication, to devices, to the OS level, to application level features and transactions: one single model,” Shewchuk envisioned. The result, he said, will earn the much-hyped label of a computing fabric, describing what he called “interwoven networks that all can communicate through these loosely coupled, self-describing, policy-driven interfaces. As we put these on a contractual basis, we get a hardened capability that we have not had before,” he explained. (Get more of John Shewchuks perspective on communications infrastructure in next-generation platforms at http://msdn.microsoft.com/theshow/episode040/default.asp.)
Web services are by no means simple, but at least theyre a related family of protocols based on a small set of common ideas. Their wider use could give us more leverage in solving security problems once, rather than finding and fixing their analogs again and again in every new environment.
We see hope for that kind of leverage in this mornings joint announcement from Cigital Inc. and Fortify Software Inc.: The companies will join forces to incorporate more than 540 secure coding rules, developed from Cigitals decade-plus of security consulting, into Fortifys Source Code Analysis product suite.
And I suspect that many IT builders and users are with me in being ready for a tectonic shift toward more controllable machines. I spent almost an hour on the phone one morning last week de-Sassering my mothers almost-new laptop via a coast-to-coast long-distance call. Call it a tipping point: After that incident, Ive finally decided to start treating the cup of computing security as much more than half empty, rather than treating security threats as trace contaminants in an otherwise benign environment.
My motto has long been “deny by default,” but Im putting it into practice at a more aggressive level than ever before. Ive written a few new firewall rules that flatly deny all inbound TCP and UDP connections, putting only a few special-case permissions ahead of those general exclusions. Im grimly pleased to find that my security alerts are way down, with no apparent impact on anything that I actually want to do with my machine.
I dont know why I didnt do this a long time ago, and I dont know why it isnt the default setup for both new operating systems and third-party security products. In the same way that software is labeled with system requirements—memory, disk space, version of operating system, graphics memory, and so on—I suggest that its time to label software specifically with statements about what network permissions it needs.
Users who dont mind writing a firewall rule could then do so by reference to that description, instead of being forced to experiment. Applications installation utilities could also check for the presence of popular firewall or other defensive systems and request permission to add the needed access privileges in proper form without manual user intervention. Of course, wed have to have some way of keeping this mechanism out of the hands of the next generation of worms—and the arms race goes on.
Those application privileges, for that matter, could be enabled and disabled dynamically when associated applications load and quit. Am I missing something? Is this facility already available on one or more mainstream personal platforms? If so, please write and tell me how ignorant I am: Id like nothing more than to find that IT integrity and security are already here, and that I just hadnt yet noticed.
And speaking of my failures, I find that the data Ive lately shared with you on software defect rates for developers in different parts of the world have been updated to fix an initial data reduction error of treating non-responses as “zero” values. Look for a discussion of the resulting changes in researchers conclusions in my column next Monday in eWEEK: It will be available soon after publication at www.eweek.com/petercoffee if you dont get eWEEK in print.
Id like to know what paths youve found toward making systems do what you want, and nothing else. Share your tips with me at peter_coffee@ziffdavis.com.
Be sure to add our eWEEK.com developer and Web services news feed to your RSS newsreader or My Yahoo page:
