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. This is helped in part by the success of the book The Security Development Lifecycle by Michael Howard and Steve Lipner (Microsoft Press®, 2006). 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.

The analysis of the software necessary to dissect its security guarantees will be done, to be sure, by both malicious hackers and legitimate security researchers who will inevitably reverse-engineer it and draw their own conclusions. Unfortunately, in today's software marketplace most customers will only find out that their software is weak if a flaw is discovered, publicized, and exploited. This state of the software industry goes against the fundamental tenet called Kerckhoffs' Principle, also known as Shannon's Maxim, which states that implementation is public: the entire body of security is in the secret key that ensures access only by authorized parties. This is not to say that the software development community excessively relies on security by obscurity or that all software vendors must publish their technology as open source. The underlying problem I want to point out is that today's software is, by and large, developed and distributed in a manner that is most suited to the following two principles:

• Utilizing sound software engineering practices during implementation
• Patching vulnerabilities found by hackers after software has been deployed

There's a key element that's being overlooked, though. It relates to acknowledging that every security feature and every part of its implementation designed to ensure a more secure product must roll up to either an explicit feature or an implicit security guarantee made by the product. This makes sense, since it is universally recognized that everything about the software is built around its functional requirements. My first important rule is this:

Design and develop software that addresses the stated as well as implicit security requirements placed upon it by users.

As a security professional, I pay particular attention to the security guarantees of software. Recently I needed to choose a software package to back up my files. As with most users, the data I would like to back up from my laptop contains sensitive, personally identifiable, and financial information (such as my Microsoft® Money file). The data on my laptop is protected with Encrypting File System (EFS), so I am reasonably comfortable with the risk that it might get lost or stolen. The prospect of backing up my data to my beloved Network Attached Storage (NAS) device—a fabulous, expensive piece of hardware and a very attractive target to a potential burglar—is worrisome, however. I would like to ensure that the data stored on the NAS cannot be recovered by a thief. Therefore, software I purchase will need to meet my security requirements and also prove to me that it has done so.

I started out by searching on the Web for reviews and comparisons of different software packages. I discovered dedicated sites on the Internet that listed handy comparison tables. I was able to find information on literally dozens of features regarding backup functionality, such as disk imaging, types of supported backup (incremental, mirror), types of supported media (NAS, CD-ROM, and so on), drive spanning, registry backup, scheduling, and access to locked files.

However, on the topic of security, I found just two rows of information: backup password protection and backup password encryption. Let us go into a little bit of detail about why classifications like this, typical as they are of how vendors treat security features, would make a security-savvy person groan.

For starters, what exactly is "backup password protection"? The authors of the review site wrote: "Backup software allows you to add a password to your backup so you can restrict access." Every single software package reviewed had this so-called feature. But none of the packages explained what this really meant.

What measure of protection do I get if I password protect my backup to a NAS device? Most likely, the protection scheme looks like what you see in Figure 1. It appears the file will be protected as long as you're using the backup software to access it. In the illustration, the user of the laptop must supply the password to the backup software, which will perform the password check and retrieve the backup on the user's behalf. The attacker, however, does not need to bother with such gentlemanly contracts: he can either sniff the network as the file is being transferred or steal (or otherwise gain access to) the file server in order to access the file. Assuming the attacker has access to the unencrypted backup, the password protection arrangement offers no real additional security. At the risk of sounding cantankerous, I question why software developers even bother with such features.

On one hand, the password-protection solution makes matters no worse, so why worry? Step back for a moment and think of the users' perceptions. The notion of backup password protection implies a very different sense of the security guarantee than what is actually being delivered. To the uninitiated, password protection means that anyone who doesn't know the password will not be able to retrieve the data. In this case the backup password protection feature is misleading, which brings me to my next rule.

Avoid introducing features into the software that imply, but cannot deliver, defensible security guarantees.

With the password protection option thus discredited, what about the other option—backup encryption? If properly implemented, this can deliver a strong security guarantee, but many things can still go wrong. From the description of the functionality offered by backup software vendors I have evaluated, I couldn't determine if it would really work (and I chose not to reverse-engineer the software to find an answer).

In my job with the Secure Windows® Initiative team at Microsoft, I have long advocated that developers who design and implement logic involving cryptographic algorithms should first prove their ability to write correct cryptographic code. What follows is an incomplete list of potential problems I can see with improperly implemented backup encryption schemes.

Danger #1 Using Weak Cryptography An obvious problem with a weak algorithm, such as 40-bit RC4, is that it can be cracked by brute force in about one day on modern hardware, and that's without any fancy optimizations. Naturally, I would like to use the strongest possible cryptographic algorithm, such as 256-bit Advanced Encryption Standard (AES), and (one can dream!) that the software will seamlessly switch to even stronger cryptography as it becomes available in the future.

Danger #2 Using Strong Cryptography Incorrectly I am guessing that performing an incremental backup of a large set of files would require the backup software to access the contents of the existing backup in something other than sequential fashion. One easy (and even stupid) way of allowing random-access reading and writing of encrypted data is by turning off a default feature of most block ciphers called Cipher Block Chaining (CBC). This insecure mode, called Electronic Code Book (ECB), is illustrated in Figure 2. As you can see, the middle picture, encrypted with ECB, does not conceal much. I would expect a better grade of protection from my backup software!

Danger #3 Using Cryptography Inconsistently Would it be possible for an attacker to obtain the names of files and directories being backed up? Even with the files encrypted well, a lot can still be gleaned from the names of files and directories on the drive. If I stole an executive's backup file and found an encrypted file named Leveraged Buyout Plan for Contoso.xls, I may need to read no further—that alone reveals a great deal of information.

The list of possible security issues can be quite long. If the software has an auto-update feature (as most software products do), how easy would it be for an attacker to advertise a false update and install their code on the user's machine? Hopefully the software obtains its updates over a secure channel and also ensures that the update is properly signed by its maker before installing, but when was the last time you had any assurance of this being done correctly?

At this point I will issue my third and final rule, before I go into a proposal of how designers of software can address all three rules collectively.

Publish sufficient information about the design of security features to convince your users that the design is solid.

Granted, not everyone will be able to understand this technical information, so it doesn't necessarily belong on the front page of the sales pamphlet. Software vendors have no qualms about presenting users with voluminous end-user license agreements, but they often neglect to disclose equally important information about the software security design. Today, however, you have only two ways of evaluating security features of a product—to check sources such as CERT advisories for known vulnerabilities or to reverse-engineer the product (possibly violating the EULA in the process) to convince yourself that it is solid. Neither is a good alternative.

So what can we do about this? The solution I propose is tentatively called the top-down security design extension to SDL. The approach starts early in the development cycle, when functional requirements are being determined. In the case of creating a backup software product, the designers may list several requirements, not all of them dealing explicitly with security. The breakdown of functional requirements may look something like Figure 3.

The next step is to examine this list critically for both explicit and implicit security guarantees. The best way to think about this step is by asking, "What security features would make the customer more likely to buy my product?" This is where security expertise comes in handy, and this is also where functional specification should meet threat modeling—a critical missing link today. Figure 4 expands the list of features by specifying security considerations for a subset of each feature. I did this by adding a new column, listing anticipated end-user requirements and high-level design considerations that enable them. The considerations are prioritized according to their importance to the overall security of the products. For now, I informally put them into three buckets: High, Medium, and Low. High means that the feature is a key functionality and must be present in the product. Medium means a valuable feature that a user should know about and have the option of using. Low means it's OK to skip due to an insufficient additional level of protection or lack of practicality.

The long list in Figure 4 is far from exhaustive, but it illustrates the point that security considerations and guarantees apply to many features of the software, even those that on the surface are not primarily security features. Listing requirements in conjunction with the associated security guarantees is the key to understanding a full range of protections afforded by the software. Now, if you were in the position of evaluating software packages, wouldn't you agree that being presented with such a list of security guarantees would make your purchasing decision easier? Could it possibly tip the scale in favor of one product over another? I think that it would.

I think it's important to mention a couple of additional points: the work does not stop here, and documenting the security guarantees need not necessarily mean disclosing your trade secrets.

Clearly, enumerating the security guarantees thus far is good, but it is used primarily for educating your sales force and producing marketing literature. As we go from the design phase into implementation, it is critical that any additional decisions don't invalidate requirements-level security guarantees already enumerated.

For instance, the scheduling of backups might be done by a dedicated service. This presents additional considerations: is this scheduling service properly isolated from other, potentially malicious, software running on the box? If it is co-located with other service processes, what additional elevation paths does that present? What additional avenues for attack does it open? For instance, someone with the ability to set the system time can now affect the scheduling of backups. Is this an important threat? Clearly, it should be considered and its effects documented, if for no other reason than to have this information for the future, should the security landscape change. What interprocess communication mechanisms are you opening up? How do you secure those channels? Are there existing best practices for securely implementing what you want?

At this point, you can also examine the proposed solution and decide to include additional security guarantees. For instance, backup software may be naturally positioned to detect system and other critical files that have been tampered with since the last backup and alert the user of the incidents.

Now let us consider how this approach coexists with trade secrets. As you further dissect security features—from requirements to design to implementation—more and more technical details emerge. Your cryptographic algorithm for high-performance incremental encrypted backup may indeed be something you would want to patent. Your key escrow protections are something you might want to keep secret or obfuscate (not a good choice, but that's more of a business decision). A security researcher or technical reviewer may decide that this is a critical piece of functionality and ask additional questions. There is nothing in this approach to security engineering that can preclude you from stipulating that the algorithm should be available to reviewers who are willing to sign a nondisclosure agreement. You might want to proactively hire security research firms that would be willing to review your solution and offer their public approval to the strength of your design and implementation. The customers could then place their trust in your product based on the reputation of the research firm, rather than on the first-hand knowledge of the inner workings of a solution.

In summary, the approach presented here is what I believe to be the missing link in SDL: tying secure design and implementation of software directly to the functional specifications of security features in a way that can be understood by customers at any level of depth they require (and that your licensing terms allow). I believe this is a promising step forward in secure design of software.