Security Development Lifecycle

Building security into a system is difficult especially today as applications are more diverse in nature and span multiple technologies. Never the less, curtailing exploits and vulnerabilities from a development standpoint should be a high priority for any application that is scheduled to be developed.

This is one of those topic’s that has many layers but here are the area’s that define Microsoft’s Security Development Lifecycle (SDL) process:

These 7 areas layout a roadmap to follow which at conclusion should produce a system that has limited security weaknesses. “Limited” is the key word here as it’s extremely challenging to produce an application that is 100% secure albeit some need to reach as close to that percentage more so than others (e.g. online banking vs. streaming music). This doesn’t mean that the latter should not follow the SDL process as no matter what application is being built; best practices for a secure application should be followed. I will concede however that this is not always the case and there’s more leeway given to applications that do not interact with personal and identifiable information (PII).

While there are many types of security mechanisms that developers can employ in their applications which can deter hackers, the following are worth mentioning:

Code Generation Security (GS)

The most well-known example of a software vulnerability is the stack-based buffer overflow. This type of vulnerability is traditionally exploited by overwriting critical data that is used to execute code after a function has completed. Since the release of Visual Studio 2002 the Microsoft Visual C++ compiler has included support for the /GS compiler switch which, when enabled, introduces an additional security check that is designed to mitigate this exploitation technique.

Address Space Layout Randomization (ASLR)

Attackers often assume that certain objects (such as DLLs) will be located at the same address in memory every time a program runs (and on every PC that the program runs on). Assumptions such as these are convenient for an attacker because they are often fundamentally required for the exploit to succeed. The inability for an attacker to hard-code these addresses can make it difficult or impossible to write a reliable exploit that will work against every PC. This insight is what drives the motivation for ASLR. ASLR is able to break numerous exploitation techniques by introducing diversity into the address space layout of a program. In other words, ASLR randomizes the location of objects in memory to prevent an attacker from being able to reliably assume their location. This tactic has the effect of making the address space layout of a program different on all PCs and is what ultimately prevents an attacker from making universal assumptions about the location of objects in memory.

To enable support for ASLR, an application must link its executable images (EXEs or DLLs) with the /DYNAMICBASE flag. This flag tells the applicable versions of the Windows operating system that an image is ASLR-aware.

Data Execution Prevention (DEP)

One of the assumptions that exploits often make is that data can be executed as code. The origin of this assumption stems from the common practice in which exploits inject custom machine code (often referred to as shell code) and then later execute it – the process known as arbitrary code execution. In most cases, exploits will store such custom machine code in portions of a program’s memory, such as the stack or the heap, that are traditionally meant to contain only data. This exploitation technique has historically been quite reliable because older Intel processors and versions of Windows prior to Windows XP Service Pack 2 did not support non-executable memory. The introduction of DEP in Windows XP Service Pack 2 established a new invariant that made it possible to prevent data from being executed as code. When DEP is enabled, it is no longer possible for an exploit to directly inject and execute custom machine code from regions of memory that are intended for data.

There are multiple ways that an application can choose to enable DEP, including by linking EXEs with the /NXCOMPAT flag and by calling the SetProcessDEPPolicy API at runtime.

Summary

Securing an application is sometimes overlooked to meet strict deadlines and/or budget constraints. This mentality clearly needs to change as instead of thinking of security as an afterthought or as something that can be “cut” it should be given a seat at the table at the earliest stages of when a project is green-lighted. Only when this change occurs will business users see the potential monetary benefit (i.e. less code related threats eliminates refactoring which in turns saves costly development hours) as well as mitigating risks from the software being developed.

To learn more about the SDL, how development organizations are using it, and the benefits of secure development, please visit: https://www.microsoft.com/sdl