The growth of interconnected computers in recent years has pushed security concerns to the forefront of development and application design. The Microsoft effort, dubbed the Secure Windows Initiative (SWI), focuses on securing new and legacy code. A key player on the Secure Windows Initiative team is Senior Security Program Manager Michael Howard. Michael has a long history working on security-related issues and has written two books along the way—Writing Secure Code and Designing Secure Web-based Applications for Windows 2000 (both from Microsoft Press).

Erica Wiechers, co-host of the .NET Show on MSDN, sat down with Michael recently for an update on the security effort. Here's what he had to say.

MSDN Microsoft is heavily focused on security issues these days. How has the thinking about security changed over the past few years at Microsoft?

Howard Simply put—threats have changed, and all software must adapt to reflect the changing, and frankly, more dangerous landscape. Security—and by security I don't mean security features, I mean secure features—is at the forefront of everyone's thoughts at Microsoft. What was previously the domain of a small bunch of specialists is now part of daily life in the various Microsoft product groups. It's part of getting the job done. And Bill's January 2002 e-mail on Trustworthy Computing has added a huge impetus and urgency to the process.

MSDN What is the main charter of the Secure Windows Initiative group at Microsoft?

Howard Our role is simple: help product groups build more secure products. Our ultimate goal is to put our group out of business by seeding product groups with expertise, helping them design, develop, test, and document their products correctly and securely. All product teams should get to a stage where their security effort is self-sufficient over time, but we are in the building phase right now, so our group performs a great deal of hand holding until the teams can run on their own.

MSDN Describe your role in that group.

Howard I have many roles including security education, research, consulting, and writing. The education aspect is critical—in general it's rare to find new developers who understand how to build secure software, so our group fills that gap. I probably spend an average of six hours a week educating people. I also spend time researching things such as new threat modeling methods, determining attack profiles, and new vulnerability types. Because of the SWI charter, I also spend a good chunk of my time working with other product groups to make sure they are on track, answer questions, go over designs, code, threats, test plans, and so on.

MSDN What are some projects you are currently working on?

Howard You name it! We just finished working with Windows XP SP1 and Visual Studio .NET 2003; now we're onto Windows Server 2003, SQL Server, Microsoft Office, the next big Visual Studio .NET release, and much, much more.

MSDN What do you see as the biggest challenge that developers face while trying to code secure applications?

Howard Legacy code is definitely the biggest challenge in that respect. We think we have the new code pretty much solved. People know the right things to do now that we have provided mandatory training, set security rules in place, improved the tools, and created a huge security awareness company-wide. However, attackers target legacy code as well as new code, and the role of the various security pushes is to fix issues in both old and new code. We can task people here at Microsoft to review and fix all code, old and new, and make it part of their job.

MSDN What security features would you like to see incorporated into future Microsoft products?

Howard I would like to see people not focus on security features. In fact, I truly believe that the biggest security benefit we can provide our customers is to install only critical features by default. If the user wants to enable other features, then they should be optional installs.

I say this because we can create products that defend against the threats we know about today. Of course, there will be new threats in the future that we do not know about today, and if a feature has such a vulnerability and it is installed by default, the user of that particular feature is automatically susceptible to attack and will need to deploy a security fix quickly. However, if the feature is rarely used and not running by default, then it cannot be attacked. Therefore, the path deployment urgency is vastly reduced. In short, if a feature is not used by 90 percent of the product's users, then the feature should be disabled by default.