"Is your system secure?"  This question, along with its cousin, "How secure is your system?," seems to be one of the funnier questions we are typically asked by business and IT stakeholders alike. The question is funny, not because security isn't important—to the contrary, in this day and age, security has never been more important—but because it is too general to have any measurable meaning.

In both variants, the most concrete answer you could ever really give is: "more secure than some, less secure than others." Of course, this answer is not very satisfying to a business, and as such, it is never given. Instead, we often end up defining security in terms of rather extreme absolutes. In one extreme, we focus solely on the business requirements of the system, relying on the IT department to supply a checklist of security-related tasks that we implement before deploying the system. In the other extreme, we spend countless amounts of time and energy researching and securing against every possible exploit that has ever been attempted in the history of the software industry—far surpassing the most stringent of DoD standards—and many times subjugating the needs of the business to the needs of our paranoia.

For this year's security issue of MSDN Magazine, I'm very happy to see an emphasis placed on a pragmatic approach to creating an effective, measureable security strategy. Michael Howard leads off with a discussion of some practical best practices he has learned over the past five years in building secure software at Microsoft. Following Howard's discussion of best practices, Michal Chmielewski, Neill Clift, Sergiusz Fonrobert, and Tomasz Ostwald discuss techniques for integrating security-related activities—both automated and manual—more deeply into the existing development lifecycle. Dan Griffin extends this discussion with a more concrete example of automated integration by developing a fuzz testing add-in for Visual Studio Team System. Finally, for those of you who just don't feel complete as developers without looking at assembly language, Adel Abouchaev, Damian Hasse, Scott Lambert, and Greg Wroblewski dive deep—really deep—into the different conditions that can cause your applications to crash, and how each of those conditions may additionally create security vulnerabilities.

One of the themes that seems to reoccur throughout many of this month's articles is that security concerns are constantly evolving and are based on a realistic assessment of threat—which is why the emphasis in this issue is more about creating a solid security strategy than it is on how to "do security" for an application. When you look at security in this light, security concerns look more like business requirements than static, infrastructure concerns—and perhaps if we can look at them this way, we can figure out how to create a reasoned, measurable security strategy, and thereby avoid going to one extreme or the other.

Speaking of measurable, one other quick note: we are constantly trying to improve the quality of both the content and the planning of MSDN Magazine. And, among other things, we rely on the ratings system found on the online version of each article in the issue. You can have a very direct impact on the magazine by simply going to the online version of an article you read here and rating it using the rating control. Your opinion matters.

Code safe! —Howard

Thanks to the following Microsoft technical experts for their help with this issue: Eric Bidstrup, Joe Binder, Todd Brooks, Claudio Caldato, John Durant, Steve Fox, Matt Gibbs, Ed Hintz, Michael Howard, Richard Johnson, Ivan Medvedev, Dave Reed, Bruce Taimana, Chris Tavares, Mads Torgersen, and James Whittaker.