Netcentric View:

By Bernard Cole
iApplianceWeb
(05/27/02, 6:10:52 P GMT)

Even before Sept. 11, Microsoft had a tough job proving to the professional programmer, let alone a skeptical consumer like me, that it had enough security safeguards built into its ambitious .NET web services framework.

Now, after Sept. 11, Microsoft Corp. is faced with an unsettling reality: it had better get it right the first time, with none of the almost weekly security gaffes that have plagued virtually all of its Windows operating system products.

I continue to harbor considerable doubts about .NET, despite the fact that Microsoft has put together an impressive range of security tools and instituted one of the most massive efforts in its history to find and plug every possible security hole.

The all-encompassing nature of Microsoft's .NET strategy, combined with an almost paranoid view of all things relating to security among even the most non-technical computer user, means that if it is only a tenth as buggy and full of security holes as previous products, consumers will turn away in droves. Not only that, corporations will not commit to it, and even worse, Microsoft may have more government agencies than the Justice Department looking over its shoulder. And the House and Senate will be there too.

To be fair, all of the providers of various web services frameworks, including both IBM and Sun with their Java/XML based approaches, will also be under the magnifying glass. But with its dismal past record, Microsoft will be looked at the most closely and the most critically.

So, how does .NET shape up vis--vis security? As is always the case with Microsoft, the message is mixed. The company is already in the midst of a media blitz to convince us that they have done everything they can to provide the best security possible.

Based on the reams of information I have read so far, it does seem that .NET's security policy is an impressive and systematic attempt to shed the poor reputation that Microsoft's software has earned.

Microsoft appears to have incorporated virtually every security mechanism it can find into .NET. It's got type verification, origin verification; a fine-grained permission mechanism; an intelligent credential caching mechanism; personal firewalls between each client and the servers it is accessing; file sharing support for encrypted files; a software restriction policy feature; support for the triple DES (data encryption standard) and extensive public key infrastructure enhancements such as cross certification and qualified subordination, editable certificate templates and a key recovery service; and, oh yes, expanded support for smart cards.

But as impressive as these improvements are, taken together, the whole security structure reminds me of a mesh screen on a window designed to keep insects out, but in which there are a variety of holes that someone has attempted to patch with duct tape or rubber cement.. At heart, it still seems to depend on the same security model that Windows has always used, albeit with catch-as-catch-can improvements.

Everything Microsoft has done in security seems to be based on its Authenticode technology, which employs what I call the "traffic cop" model. This methodology allows a software component access to operate anywhere as long as it has the right certification and is under close supervision by the system. If a component is dangerous, its activity is reported, and a traffic cop checks its license back to the source to ensure it is valid.

With Authenticode, digital signatures are used that allow the user to positively identify himself. Authenticode ensures accountability and authenticity of software components being used or send across the Internet by verifying that the software has not been tampered with and identifying the developer of the code.

Over the years Microsoft has applied additional safeguards. I don't have room in this column to go into all of these and their pros and cons. But my main skepticism about Microsoft is that the Authenticode traffic cop mechanism, even with its numerous enhancements, has not stopped the almost weekly reports of virus infestations of its software.

While I don't yet understand all of the technical details of Sun's approach to security, intuitively I trust it more. In its Java framework, Sun uses what I call a "sandbox" model.

Because ordinary Java applets are independent, self-executing programs that use communications links and protocols that in essence are "viruses," albeit benign, great care is taken with them.

In addition to checking the pedigree of each downloaded applet, in this model each and every one is confined to a sandbox where it can be monitored, and it is allowed access to the system only when it is determined it is well behaved.

Three additional lines of defense are the byte code verifier, which puts each applet class through a series of tests; the class loader, which divides and isolates Java classes into small, secure, well mannered and well guarded groups; and the security manager, which acts as the jailer, controlling the methods that are called and restricting methods that attempt file or network I/O access.

There are security features built into the Java language itself, too. Automatic garbage collection limits the ability of hackers to enter backdoors in the application. Because Java is strongly typed, it's not possible for a programmer to access the values of un-initialized local variables, preventing their types from being changed, a common way to get a Trojan Horse virus into a system.

Also, because Java largely prohibits the use of pointers and pointer arithmetic, security breaches such as object spoofing, dangling references, renegade pointers and memory corruption are not possible.

In this context, Microsoft's prohibition of Java from its new XP operating system, including no provisions for its use under .NET because it was "not secure" is absolutely ludicrous.

However, C# (C-sharp), the language Microsoft programmers created to help developers write code for .NET, is very Java-like in its features and operation. Let's hope that much of what Sun has learned about doing security under Java is reflected in C#.

Some features of the .NET framework, such as one program called SAFER, indicate that Microsoft is moving much closer to the Java sandbox security model. SAFER classifies all code as either trusted, which can be executed, and untrusted, which can't. No code under a client running XP Pro or a .NET-based server is excluded, no matter where it comes from and no matter who or what executes it.

Still, it will be a long time before I willingly go anywhere near either .NET or any of Microsoft's future OSes, embedded or otherwise. Maybe in about 15 years, the length of time Microsoft has made my life miserable.

What do you think? The security of the "information superhighway" is going to be on my mind a lot and I hope to write more about it, and for that I need all the help I can get from you. My contact information is listed below.

Reader Feedback

I agree.

Microsoft has consistently proven that they have had little regard for security or quality in designing their product. Given the types of (grave) blunders that they have made in the past, it is unlikely that .net will meet expectations. It is nothing short of a joke for a company to suddenly mandate security as a design principle after years of neglect. Good design, of which security is always a component, is an ideology, a methodology, an understanding which is not cultivated in a company overnight by sending out an email.

I am especially entertained by writers such as Michael (below) who point out how the .net architecture has all the proper constructs in place to be very secure product. However he is missing the fact that M$ has been perpetually weak when it comes implementation. Thus no matter how good the model and theory, the end result in many cases is something flawed by poor implementation.

Time will tell, but history is on my side :)

Ed

.Net is far more secure than systems built by Sun. i Iam not a microsoft fan. I happen to have interests in security and so far, I think .net is going on the right track. Until then, BSD is stil my favourite.

soc

Fanatic

This article is irresponible at the very least. It is obvious that the author has not really looked into .Net and just writing from assumption, prejudice, and a limited perspective on the subject. Don't get me wrong, I'm not some microsoft nazi, I love Java, but I am educated about the subject. First off there is no difference between C#, .Net, or any other language you can use to write ".Net" applications. (there are over 20 languages to my knowledge) All the languages use a platform independent version (called IL - Intermediate Language) of assemblier and the "Sandbox" security model. There are versions of the runtime being developed for windows, Linux, freeBSD, Mac, and many others . . . This is a first for Microsoft, actually letting go of it's new technology and releasing it as a public spec. (http://www.go-mono.com <-----Linux Site) Ximian has picked it up for linux and is trying to use it as the next Gen of Gnome. . . . interesting stuff going on with this platform and to completely discount it is just a result of ignorance and blind hate.

Michael

Bernard Cole is site leader and editor of iApplianceweb and an independent high technology editorial services consultant. He welcomes your feedback. Call him at 602-288-7257 or send an email to bccole@acm.org.