Security In The Web Development Process

We've talked about a number of practices that comprise the full-knowledge analysis methodology, including threat modeling, code review, and security testing. Increasingly, savvy organizations are weaving these disparate processes into the application development lifecycle, so that they simply become an inherent part of the development process itself.

Microsoft has popularized the term Security Development Lifecycle (SDL) to describe their integration of security best practices into the development process (see "References and Further Reading" for links to more information on SDL). We encourage you to read Microsoft's full description of their implementation of SDL. In the meantime, here are some of our own reflections on important aspects of SDL that we've seen in our consulting travels . We've organized our thoughts around the industry mantra of "people, process, and technology."

People

People are the foundation of any semi-automated process like SDL, so make sure to consider the following tips when implementing an SDL process in your organization.

Getting Cultural Buy-in

A lot of security books start out with the recommendation to "get executive buy-in" before embarking on a broad security initiative like SDL. Frankly, executive buy-in is only useful if the developers listen to executives, which isn't always the case in our consulting experience. At any rate, there will always need to be some level of grass-roots buy-in no matter how firmly executive management backs the security team, otherwise SDL just won't get adopted to the extent required to make significant changes to application security. Make sure to evangelize and pilot your SDL implementation well at all levels of the organization to ensure that it get widespread buy-in, and that it will be perceived as a reasonable and practical mechanism for improving product quality (and thus the bottom line). This will greatly enhance the potential for becoming part of the culture rather than some bolt-on process that everybody mocks (think TPS reports from the movie Office Space ).

Appoint a Security Liaison on the Development Team

The development team needs to understand that they are ultimately accountable for the security of their product, and there is no better way to drive home this accountability than to make it a part of a team member's job description. Additionally, it is probably unrealistic to expect members of a central enterprise security team to ever acquire the expertise (across releases) of a "local" member of the development teams . Especially in large organizations with substantial, distributed software development operations, where multiple projects compete for attention, having an agent "on the ground" can be indispensable . It also creates great efficiencies to channel training and process initiatives through a single point of contact.

Caution 

Do not make the mistake of holding the security liaison accountable for the security of the application. This must remain the sole accountability of the development team's leadership and should reside no lower in the organization than the executive most directly responsible for the application.

Education, Education, Education   Most people aren't able to do the right thing if they've never been taught what it is, and this is extremely true for developers (who have trouble even spelling "security" when they're on a tight ship schedule). Thus, an SDL initiative must begin with training. There are two primary goals to the training:

• Learning the organizational SDL process

• Imparting organizational-specific and general secure-coding best practices

Develop a curriculum, measure attendance and understanding, and, again, hold teams accountable at the executive level.

Process

To lend coherence to the concept of SDL, you might think of each of the major sections of this chapter as a milestone in the software development process. For example, threat modeling occurs at design time, code review follows implementation, and security testing occurs during alpha and beta up through final release. Additional milestones, including developer training, or a prerelease security audit/review, may also be used where appropriate. Figure 12-12 illustrates a stereotypical software development lifecycle with hypothetical SDL milestones (such as training and threat modeling) overlaid.

Figure 12-12: A sample SDL implementation

Technology

Of course, technology is a key ingredient in any SDL implementation. It can bring efficiency to the SDL process itself by automating some of the more tedious components (such as source code review). SDL should also specify consistent technology standards throughout the development process, such as compile-time parameters (for example, Microsoft's /GS flag) and incorporation of standard input validation routines. Here are some key considerations related to these themes.

Improved Automated Review and Testing Technologies

As security continues to gain prominence in business, the market will continue to evolve better security code review and testing technologies. We've already seen some examples in this chapter, including Microsoft's PREFix automated code assessment tool and SPIDynamics' QAInspect test suite. Make sure that you are keeping your SDL toolset state-of-the-art so that your applications face a lesser risk from cutting-edge zero-day attacks.

Managed Execution Environments

We strongly recommend migrating your web applications to managed development platforms like Sun's Java (http://java.sun.com) or Microsoft's .NET Framework ( http://www.gotdotnet.com) if you have not already. Code developed using these environments leverage strong memory management technologies and execute within a protected security sandbox that greatly reduces the possibility of security vulnerabilities.

Input Validation Libraries

Almost all software hacking rests on the assumption that input will be processed in an unexpected manner. Thus, the holy grail of software security is airtight input validation. Most software development shops cobble their own input validation routines, using regular expression matching (try http://www.regexlib.com/ for great tips). Microsoft Corp. provides an off-the-shelf input validation library for its IIS web server software called URLScan, and a similar library is available for Apache called mod_sec (see Appendix C for more information on URLScan and mod_sec). If at all possible, we recommend using such input validation libraries to deflect as much noxious input as possible for your applications.

If you choose to implement your own input validation routines, remember these cardinal rules of input validation:

• Limit the amount of expected user input to the bare minimum, especially freeform input.

• Assume all input is malicious and treat it as such, throughout the application.

• Never ever automatically trust client input.

• Constrain the possible inputs your application will accept (for example, a ZIP code field might only accept five-digit numerals).

• Reject all input that does not meet these constraints.

• Sanitize any remaining input (for example, remove metacharacters like & ' > < and so on that might be interpreted as executable content).

• Encode output so that even if something sneaks through, it'll be rendered harmless to users.

  Tip 

  See Chapter 6 for more input validation attacks and countermeasures.

Platform Improvements

Keep your eye on new technology developments like Microsoft's Data Execution Prevention (DEP) feature. Microsoft has implemented DEP to provide broad protection against memory corruption attacks like buffer overflows (see http://support.microsoft.com/kb/875352/ for full details). DEP has both a hardware and software component. When run on compatible hardware, DEP kicks in automatically and marks certain portions of memory as non-executable unless it explicitly contains executable code. Ostensibly, this would prevent most stack-based buffer overflow attacks. In addition to hardware-enforced DEP, Windows XP SP2 and later also implement software-enforced DEP that attempts to block exploitation of exception-handling mechanisms in Windows.

Web application developers should be aware of these improvements coming down the pike in 64-bit platforms and start planning to migrate as soon as possible.