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
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