In any endeavor – business, war, sports, etc. – perfect tactical implementation will never lead to success if the underlying strategy is flawed. Still, when companies look to fix the software causing their security headaches, they almost invariably point first to the individual, code-level implementation errors without considering the larger and more critical issues of design.

In their defense, implementation errors garner the vast majority of coverage in industry articles, conference sessions, blogs, and podcasts about software security. Discussion of these flaws, including buffer overflows, race conditions, and other code-level typographical mistakes, constantly pervade through the media, driven by aggressive security researchers and the software vendors scrambling to respond to them.

There is far less discussion of the more complex, more abstract errors of design, which typically impact business functions and policies more than the quality of the code. Examples include the failure to effectively utilize security functions such as authentication or encryption, employing insecure code components, and processing data input before it’s properly validated.
It should be noted that while implementation errors have garnered the majority of mindshare among the technical community, design errors have actually lead to the most costly breaches of privacy, confidentiality, and system integrity. Organizations as diverse as the University of Southern California, the US Air Force, Ralph Lauren, and BJ’s Wholesale Club have all suffered public exposure of confidential data as a result of design-level vulnerabilities in critical applications.

One reason for the recent increase in design error exploits is that many compromised applications are typically enabled by higher-level languages. These languages provide rapid deployment of functionality and broad access to multiple services and data sources, but they do not require a detailed understanding of the consequences of each data access and service offered. Applications are now commonly built using newer languages and frameworks that result in fewer implementation errors, because the typical sources of risk, such as poor memory management and resource control, have been reduced by taking such low-level controls out of the developers’ hands.

However, because of the complexity and due sheer number of potential design errors, developers cannot readily identify or remediate them within their individual units of code. This requires a broad analysis that spans entire applications, and which considers the wide variety of potential mismatches between expected application controls and those which are actually implemented. To effectively address these potentially devastating vulnerabilities, a thorough analysis of the entire code base, with an understanding of both the security and architectural implications, is necessary.

	A critical component for improving application security early in the SDLC is to perform a structured security design review. This review can be performed as part of a higher-level design review, but it must include a software engineer or security architect who understands security and has the ability to think in abstract ways essential for reviewing high-level design and architecture documents.
	Integrate Security Best Practices and Tools Into Software Development Life Cycle Gartner Research (2/10/06) Amrit T. Williams and Neil MacDonald

The following design-level errors are examples of commonly-seen mistakes and should provide a helpful starting point for security review teams.

Security-related functions
Application design should account for the type of data being processed and the users that will be able to access and manipulate that data; both should be strictly monitored and controlled. Security-related functions dictate how information is stored and transferred as well as identifying users and properly restricting their application privileges. Design errors in this category most commonly lead to data theft and privacy breaches, attacks for which victim companies have paid fines in the millions of dollars, in addition to enormous losses of corporate reputation and consumer confidence. Standard security-related functions that should be strictly audited include:

	Cryptography
	Network communication
	Application configuration
	Access control
	Database and file system use
	Dynamic code
	Access control and authentication errors

Input/Output validation and encoding errors
Applications that accept input or publish output without proper security controls can expose both systems and innocent users to security risk. Sources of input, particularly those that are populated dynamically by user interactions, should be validated against conditions that describe the expected characteristics of that input field. Likewise, output should be encoded to make sure malicious commands are not redirected by an attacker through the application to a user. Failure to design the application with these validation and encoding controls may expose applications to attacks such as:

	SQL injection
	Cross-site scripting
	OS injection
	Custom cookie/hidden field manipulation

Error handling and logging vulnerabilities
Error handling and logging may be difficult to design properly because both result from nonstandard application behavior. However, it is important to carefully plan the behavior and output that results from incorrect use of an application, because many exploits take advantage of this response. Potentially vulnerable errors in this category include: 

	Insecure error handling
	Insecure or inadequate logging
	Native code loading
	Data storage vulnerability

Insecure Components
In many cases, application source code will include elements that are not part of the original software design. Whether inserted purposefully or accidentally, security review teams must identify components of the code that introduce risks without appropriately adding to the application’s functionality. Code components that may occur outside the realm of secure design include:

	Malicious Code
	Unsafe native methods
	Unsupported methods

While not an exhaustive list, addressing these vulnerability categories during the design phase of the software development lifecycle will greatly reduce an application’s security and maintenance costs in the long term. For software security audits conducted on applications already developed and/or deployed, a comprehensive analysis of the entire code base is the only way to effectively ensure that these design elements have been addressed.

To find out more about design-level issues and how the Ounce solution enables customers to address them, please contact info@ouncelabs.com.