Documenting And Evaluating The Security Guarantees Of Your Apps

The internal software design and development practice at Microsoft, called the Security Development Lifecycle (SDL), is reaching maturity and starting to be publicized and adopted outside the company. The success of SDL has been well documented—software developed in keeping with the requirements and recommendations that SDL puts forth is indeed better protected against attack. Yet, for all its documented success, software developed per SDL requirements still fails to answer a basic question many customers ask: what security features does the product deliver?

In this article, I'll present a case study of an extension to SDL which, if adopted, could translate into a much better flow of information between users and designers of the security features of software products. My approach calls for recognizing that security of software is not a compliance artifact. Rather, it is a set of key features that can and should be documented, evaluated, and used when making purchasing decisions.

The security features—I like to call them security guarantees of the software—are deep and multileveled. At a high level understandable by most users, they should be described in the customer-facing sales literature. Lower-level technical details targeted at experts should be readily available for inspection by those curious to understand the technology.