Securing .Net
A conversation with Microsoft's John Montgomery
May 2002New Architect: There's been talk recently about a .Net virus, though the consensus seems to be that this threat was misrepresented. Is the .Net framework really any more impervious to viral code than traditional Windows?
John Montgomery: The whole ".Net virus" issue isn't what it appears to be. As you point out, it's not really a .Net virus—that is, it's not written in managed code running on the .Net Framework. In fact, it's not even a new virus. The antivirus software on my computer immediately caught it when I was playing around with .Net. Heck, on my Windows XP system, the virus couldn't even load properly thanks to some of the security enhancements in XP.
The .Net Framework's Common Language Runtime (CLR) can protect Windows computers from lots of common attacks. It's capable of limiting the resources that a piece of code can access on the local machine based on the "evidence" that code bears—things like who wrote the application and where it came from.
NA: How does the CLR's security model compare to that of Java?
JM: The security system of the .Net Framework applies not only to C#, but to each of the more than 20 languages supported by the .Net Framework, including APL, C#, C++, Cobol, Fortran, Java, Perl, Python, and VB.Net. For the 90 percent of programmers not using the Java language, this is a pretty cool thing. Getting more granular, both Java and the .Net Framework provide execution environments for what you can call semi-trusted code. The .Net Framework provides a more granular and more extensible security system that gives systems administrators and developers greater control over which resources can and cannot be accessed by their code.
NA: Isn't transmitting remote procedure calls as human-readable XML data inherently less secure than using binary formats?
JM: You're right; SOAP doesn't address all of the issues that face Web services developers. SOAP and WSDL are just the baseline specifications that provide the foundation for XML Web services. There are a variety of ways to address Web services security, and many of the methods we use for Web sites today—Authentication, SSL, ipSec, VPNs—are directly applicable to Web services. These methods don't address all needs that Web services developers have. The WS-Security specification (msdn.microsoft.com/ws/2002/01/Security/) allows for much richer Web services security scenarios to be implemented where SOAP messages can be signed, encrypted, and can carry credential information in them.
NA: One of SOAP's features is the ability to skirt firewalls by sending traffic over HTTP at Port 80, but doesn't this lead to a security nightmare?
JM: SOAP is a pretty flexible protocol, and it doesn't actually require a specific transport protocol or messaging pattern. It can be bound to a variety of transports including TCP, SMTP, and HTTP. And again, the RPC model is just one of the messaging patterns in which SOAP/Web services can be and are used.
That said, a firewall could distinguish Web traffic from Web services traffic—even if they were both going to the same box—using HTTP on port 80. A Web service implemented inside of a company to provide EAI integration is most likely not exposed to the outside world thanks to a firewall, and it's thus protected from external malicious activity. Web services implemented for partner integration will implement one of the many security methods already used to transact in a protected manner.
NA: Bill Gates has made security job number one at Microsoft. What does this mean for the .Net Framework?
JM: The Gates memo on trustworthy computing is serious stuff. We've been thinking about what we need to do to make our products more secure for quite a while, and this memo is the kick-off for a full-fledged focus on security. Even before the memo became public, lots of teams were engaging in the process that the memo codified. In the case of the .Net Framework, it goes back a few years to the design of our evidence-based security model. More recently, in the spring of 2000, we brought in two leading security assessment firms, Foundstone and CORE Security Technologies, to act as a fresh set of eyes on our architecture.
No software vendor can guarantee a 100 percent bug-free product. Humans make mistakes. We've done everything we can to ship a programming model that is locked down by default. The burden is shared—between us, the administrators, and the developers, who must (as always) follow good security practices in developing their code. (We've created a good deal of documentation on this subject at msdn.microsoft.com/net/security.)
