Windows.NET Security Services

I am looking through my notes from PDC 2000 of July 11-14th 2000 in Orlando Florida. This was the conference that unveiled the details of .NET to the IT community. Praerit Garg, Lead Security Program Manager , Windows.NET platform. The presentation was thorough, wide ranging and full of security features and promises for Windows. The talk looked at 1)Credential Management then On-the-Net/Wire protection Services including a)Authentication Services, b)Authorization and Auditing Services, and c)DataProtection Services. The talk ended up with a Why Use the Windows.NET Security Framework slide. The payback to users (and Microsoft itself) were fairly compelling:
Common model for platfrom and applications – simpler learning curve
Common admin of access control – for individual objects and role-based policies
Integrated auditing – auto audits at access checks, one log for platform and app audits
Simplified APIs – reduces complexity in simple cases; yet great flexibility in generalized model
Performance – simple API helps boost performance
Windows.NET Security was one critical component of .NET energizing and promoting greater security, manageability and reliability of Windows operations. But it never happened.

Office 2003 was excused from being a .NET enabled. Windows 2003 server scaled back dramatically its commitment to .NET and .NET services. IE was taken off of any functional updates leaving in bad security exposures such as widespread ActiveX usage and privileged states made available to the Web browser user. Finally, Windows.NET rollout was delayed to Longhorn due originally in late 2004 and now likely to be delivered in early 2007.

The “We Are Most Exposed” Fictionary Excuse

Currently Microsoft argues strenuously that Windows is not the most vulnerable operating system simply the most used and therefore exposed for attack. We would argue the contrary. Up until 2000 and .NET Microsoft lacked a coherent security framework across its programming languages. .NET changed that dramatically bringing in a uniform implementation of try-catch-finally, exception handling, memory management, and dynamic reference checking, etc. But .NET did not get adopted by the two pillars of Microsofts software empire – neither Office nor Windows. They wont come on board until the Longhornish era of 2007-2009.

However, even within the .NET Framework there lurks a potentially wide hole – Unmanaged or Native Code in .NET. Managed Code in .NET is subect to all of the memory management, exception handling and reference checking regime that was used to provide a sure and reliable base to Microsoft code. But .NET Unmanaged or native code relaxes some of those security features to achieve better performance. Two problems arise. First, native or unmanaged code is more vulnerable but should be used in programming contexts where that greater vulnerability is not exposed. This is a programming decision. Heretofore when confronted with performance or functionality versus security, Microsoft has chosen against security to its users detriment and costs. The second problem is interoperation betwen native/unmanaged and managed code; this has turned out to be a very sticky wicket as covered in this Microsoft article:
“The typical C++/CLI developer is a sophisticated system programmer tasked with providing infrastructure and organizationally critical applications that serve as the foundation over which a business builds its future. She must address both scalability and performance concerns and must therefore have a system-level view into the underlying CLI. The level of detail of a CLI language reflects the face of its programmer.Complexity is not in itself a negative quality. Human beings are more complicated than single-cell bacteria, and that is certainly not a bad thing. However, when the expression of a simple concept is made complicated, that is usually considered to be a bad thing. In C++/CLI, the CLI team has tried to provide an elegant way to express complex subject matter.”
Suffice it to say interop brings a new level of complexity to VC++ code.

Security Requires Partnerships

But there are more Microsoft problems in the security arena. Credentials, Authentication, and Authorization are inevitability cross platform and interoperability issues requiring collaboration and partnership between ISVs. Microsoft has a very mixed record in this area. We have explored many times what Microsoft and its IE team have not done in supporting robust DHTML (HTML, CSS, DOM, JavaScript) standards and in fact embracing vulnerability plagued ActiveX extensions which give added functionality at the cost of two years of increasing security problems and rush fixes. In XML and Web Services Redmond started out as model citizen sticking to standards and working with BEA, IBM, Oracle , Sun and others in establishing many of the new Web Services standards. But of late Microsoft has said it will not stick to standards in the case of XSLT2, XPath2, and other parts of XSL. It has not committed to SVG or SMIL in the media arena. It is , contrary to W3C recommendations, taking out patents for processing XML and Web Services. In sum, Microsoft, even in the Trustworthy arena, has proven to be a narrow, proprietary and some times zero-sum player – “I win means you must lose”. Literally, “win-win” has fallen out of Redmonds vocabulary. Do a search on it on the Microsoft site.

So in negotiations with other major ISV players over standards, Microsoft has recently surrendered a position of relative creditability. Worse, its belligerent actions in such areas as BI give aways, misrepresenting itself on ERP intentions before the courts, and continued legal actions against small innovators have cemented Redmonds position as Partnership Pariah. This well may help to explain the discontinued use of Passport by eBay and others, difficulties in negotiations with Sun on credentials and identity management, and equally difficult reception in other standard proposals.

In sum, when Microsoft claims lapses in security, reliability and availability are the result of their exposure as dominant players in so many markets; take that inverted braggadacio and add a pinch of salt to the fine stew of a malaware mess Microsoft, and only Microsoft alone, have gotten themselves into.

(c) JBSurveyer 2005