Testing Guide Introduction

OWASP Testing Guide v3 Table of Contents

This article is part of the OWASP Testing Guide v3. The entire OWASP Testing Guide v3 can be downloaded here.

OWASP at the moment is working at the OWASP Testing Guide v4: you can browse the Guide here

1 The OWASP Testing Project
2 Principles of Testing
3 Testing Techniques Explained
4 Security Requirements Test Derivation
5 References

The OWASP Testing Project

The OWASP Testing Project has been in development for many years. With this project, we wanted to help people understand the what, why, when, where, and how of testing their web applications, and not just provide a simple checklist or prescription of issues that should be addressed. The outcome of this project is a complete Testing Framework, from which others can build their own testing programs or qualify other people’s processes. The Testing Guide describes in details both the general Testing Framework and the techniques required to implement the framework in practice.

Writing the Testing Guide has proven to be a difficult task. It has been a challenge to obtain consensus and develop the content that allow people to apply the concepts described here, while enabling them to work in their own environment and culture. It has also been a challenge to change the focus of web application testing from penetration testing to testing integrated in the software development life cycle.

However, we are very satisfied with the results we have reached. Many industry experts and those responsible for software security at some of the largest companies in the world are validating the Testing Framework. This framework helps organizations test their web applications in order to build reliable and secure software, rather than simply highlighting areas of weakness, although the latter is certainly a byproduct of many of OWASP’s guides and checklists. As such, we have made some hard decisions about the appropriateness of certain testing techniques and technologies, which we fully understand will not be agreed upon by everyone. However, OWASP is able to take the high ground and change culture over time through awareness and education based on consensus and experience, rather than take the path of the "least common denominator."

The rest of this guide is organized as follows. This introduction covers the pre-requisites of testing web applications: the scope of testing, the principles of successful testing, and the testing techniques. Chapter 3 presents the OWASP Testing Framework and explains its techniques and tasks in relation with the various phases of the software development life cycle. Chapter 4 covers how to test for specific vulnerabilities (e.g., SQL Injection) by code inspection and penetration testing.

Measuring (in)security: the Economics of Insecure Software
A basic tenet of software engineering is that you can't control what you can't measure (T. DeMarco, Controlling Software Projects: Management, Measurement and Estimation, Yourdon Press, 1982). Security testing is not different. Unfortunately, measuring security is a notoriously difficult process. We will not cover this topic in detail here, since it would take a guide on its own (for an introduction, see S. Payne, A Guide to Security Metrics, 2006, retrieved July 18, 2008, from http://www.sans.org/reading_room/whitepapers/auditing/55.php).

One aspect that we want to emphasize, however, is that security measurements are necessarily about both the specific, technical issues (e.g., how prevalent a certain vulnerability is) and how these affect the economics of software. We find that most technical people understand at least the basic issues, or have a deeper understanding, of the vulnerabilities. Sadly, few are able to translate that technical knowledge into monetary terms, and, thereby, quantify the costs of vulnerabilities to their business. We believe that until this happens, CIOs will not be able to develop an accurate return on a security investment and, subsequently, assign appropriate budgets for software security.
While estimating the cost of insecure software may appear a daunting task, recently, there has been a significant amount of work in this direction. For example, in June 2002, the US National Institute of Standards (NIST) published a survey on the cost of insecure software to the US economy due to inadequate software testing (The economic impacts of inadequate infrastructure for software testing. (2002, June 28). Retrieved May 4, 2004, from http://www.nist.gov/public_affairs/releases/n02-10.htm) Interestingly, they estimate that a better testing infrastructure would save more than a third of these costs, or about $22 billion a year. More recently, the links between economics and security have been studied by academic researchers. See Ross Anderson’s page at http://www.cl.cam.ac.uk/users/rja14/econsec.html for more information about some of these efforts.

The framework described in this document encourages people to measure security throughout their entire development process. They can then relate the cost of insecure software to the impact it has on their business, and consequently develop appropriate business decisions (resources) to manage the risk. Remember: measuring and testing web applications is even more critical than for other software, since web applications are exposed to millions of users through the Internet. Even now, the confidence of customers using the World Wide Web to purchase goods or cover their needs is decreasing as more and more web applications are exposed to atta

What is Testing
What do we mean by testing? During the development lifecycle of a web application, many things need to be tested. The Merriam-Webster Dictionary describes testing as:

To put to test or proof
To undergo a test
To be assigned a standing or evaluation based on tests.

For the purposes of this document, testing is a process of comparing the state of a system against a set of criteria. In the security industry, people frequently test against a set of mental criteria that are neither well defined nor complete. For this reason and others, many outsiders regard security testing as a black art. This document’s aim is to change that perception and to make it easier for people without in-depth security knowledge to make a difference.

Why Testing
This document is designed to help organizations understand what comprises a testing program, and to help them identify the steps that they need to undertake to build and operate that testing program on their web applications. It is intended to give a broad view of the elements required to make a comprehensive web application security program. This guide can be used as a reference and as a methodology to help determine the gap between your existing practices and industry best practices. This guide allows organizations to compare themselves against industry peers, understand the magnitude of resources required to test and remediate their software, or prepare for an audit. This document does not go into the technical details of how to test an application, as the intent is to provide a typical security organizational framework. The technical details about how to test an application, as part of a penetration test or code review will be covered in the Part 2 document mentioned above.

When to Test
One of the best methods to prevent security bugs from appearing in production applications is to improve the Software Development Life Cycle (SDLC) by including security in each of its phases. A SDLC is a structure imposed on the development of software artifacts. If a SDLC is not currently being used in your environment, it is time to pick one! The following figure shows a generic SDLC model as well as the (estimated) increasing cost of fixing security bugs in such a model.

Figure 1: Generic SDLC Model

Companies should inspect their overall SDLC to ensure that security is an integral part of the development process. SDLCs should include security tests to ensure security is adequately covered and controls are effective throughout the development process.

What to Test
It can be helpful to think of software development as a combination of people, process, and technology. If these are the factors that "create" software, then it is logical that these are the factors that must be tested. Today most people generally test the technology or the software itself. In fact, most people today don’t test the software until it has already been created and is in the deployment phase of its life cycle (i.e., code has been created and instantiated into a working web application). This is generally a very ineffective and cost-prohibitive practice.

An effective testing program should have components that test People – to ensure that there is adequate education and awareness; Process – to ensure that there are adequate policies and standards and that people know how to follow these policies; Technology – to ensure that the process has been effective in its implementation. Unless a holistic approach is adopted, testing just the technical implementation of an application will not uncover management or operational vulnerabilities that could be present. By testing the people, policy and process, you can catch issues that would later manifest themselves into defects in the technology, thus eradicating bugs early and identifying the root causes of defects. Likewise, testing only some of the technical issues that can be present in a system will result in an incomplete and inaccurate security posture assessment. Denis Verdon, Head of Information Security at Fidelity National Financial (http://www.fnf.com) presented an excellent analogy for this misconception at the OWASP AppSec 2004 Conference in New York: "If cars were built like applications [...] safety tests would assume frontal impact only. Cars would not be roll tested, or tested for stability in emergency maneuvers, brake effectiveness, side impact and resistance to theft."

Feedback and Comments
As with all OWASP projects, we welcome comments and feedback. We especially like to know that our work is being used and that it is effective and accurate.

Principles of Testing

There are some common misconceptions when developing a testing methodology to weed out security bugs in software. This chapter covers some of the basic principles that should be taken into account by professionals when testing for security bugs in software.

There is No Silver Bullet
While it is tempting to think that a security scanner or application firewall will either provide a multitude of defenses or identify a multitude of problems, in reality there are no silver bullets to the problem of insecure software. Application security assessment software, while useful as a first pass to find low-hanging fruit, is generally immature and ineffective at in-depth assessments and at providing adequate test coverage. Remember that security is a process, not a product.

Think Strategically, Not Tactically
Over the last few years, security professionals have come to realize the fallacy of the patch-and-penetrate model that was pervasive in information security during the 1990’s. The patch-and-penetrate model involves fixing a reported bug, but without proper investigation of the root cause. This model is usually associated with the window of vulnerability (1) shown in the figure below. The evolution of vulnerabilities in common software used worldwide has shown the ineffectiveness of this model. Vulnerability studies (2) have shown that with the reaction time of attackers worldwide, the typical window of vulnerability does not provide enough time for patch installation, since the time between a vulnerability being uncovered and an automated attack against it being developed and released is decreasing every year. There are also several wrong assumptions in the patch-and-penetrate model: patches interfere with the normal operations and might break existing applications, and not all the users might (in the end) be aware of a patch’s availability. Consequently not all the product's users will apply patches, either because of this issue or because they lack knowledge about the patch's existence.
Note: (1) Fore more information about the window of vulnerability please refer to Bruce Schneier’s Cryptogram Issue #9, available at http://www.schneier.com/crypto-gram-0009.html
(2) Such as those included Symantec’s Threat Reports

Figure 2: Window of Vulnerability

To prevent reoccurring security problems within an application, it is essential to build security into the Software Development Life Cycle (SDLC) by developing standards, policies, and guidelines that fit and work within the development methodology. Threat modeling and other techniques should be used to help assign appropriate resources to those parts of a system that are most at risk.
The SDLC is King
The SDLC is a process that is well-known to developers. By integrating security into each phase of the SDLC, it allows for a holistic approach to application security that leverages the procedures already in place within the organization. Be aware that while the names of the various phases may change depending on the SDLC model used by an organization, each conceptual phase of the archetype SDLC will be used to develop the application (i.e., define, design, develop, deploy, maintain). Each phase has security considerations that should become part of the existing process, to ensure a cost-effective and comprehensive security program.
Test Early and Test Often
When a bug is detected early within the SDLC, it can be addressed more quickly and at a lower cost. A security bug is no different from a functional or performance-based bug in this regard. A key step in making this possible is to educate the development and QA organizations about common security issues and the ways to detect & prevent them. Although new libraries, tools, or languages might help design better programs (with fewer security bugs), new threats arise constantly and developers must be aware of those that affect the software they are developing. Education in security testing also helps developers acquire the appropriate mindset to test an application from an attacker's perspective. This allows each organization to consider security issues as part of their existing responsibilities.
Understand the Scope of Security
It is important to know how much security a given project will require. The information and assets that are to be protected should be given a classification that states how they are to be handled (e.g., confidential, secret, top secret). Discussions should occur with legal council to ensure that any specific security need will be met. In the USA they might come from federal regulations, such as the Gramm-Leach-Bliley Act (http://www.ftc.gov/privacy/privacyinitiatives/glbact.html), or from state laws, such as the California SB-1386 (http://www.leginfo.ca.gov/pub/01-02/bill/sen/sb_1351-1400/sb_1386_bill_20020926_chaptered.html). For organizations based in EU countries, both country-specific regulation and EU Directives might apply. For example, Directive 96/46/EC4 makes it mandatory to treat personal data in applications with due care, whatever the application.
Develop the Right Mindset
Successfully testing an application for security vulnerabilities requires thinking "outside of the box". Normal use cases will test the normal behavior of the application when a user is using it in the manner that you expect. Good security testing requires going beyond what is expected and thinking like an attacker who is trying to break the application. Creative thinking can help to determine what unexpected data may cause an application to fail in an insecure manner. It can also help find what assumptions made by web developers are not always true and how they can be subverted. This is one of the reasons why automated tools are actually bad at automatically testing for vulnerabilities: this creative thinking must be done in a case-by-case basis and most of the web applications are being developed in a unique way (even if using common frameworks).
Understand the Subject
One of the first major initiatives in any good security program should be to require accurate documentation of the application. The architecture, data-flow diagrams, use cases, and more should be written in formal documents and made available for review. The technical specification and application documents should include information that lists not only the desired use cases, but also any specifically disallowed use case. Finally, it is good to have at least a basic security infrastructure that allows the monitoring and trending of attacks against your applications & network (e.g., IDS systems).
Use the Right Tools
While we have already stated that there is no silver bullet tool, tools do play a critical role in the overall security program. There is a range of open source and commercial tools that can automate many routine security tasks. These tools can simplify and speed up the security process by assisting security personnel in their tasks. It is important to understand exactly what these tools can and cannot do, however, so that they are not oversold or used incorrectly.
The Devil is in the Details
It is critical not to perform a superficial security review of an application and consider it complete. This will instill a false sense of confidence that can be as dangerous as not having done a security review in the first place. It is vital to carefully review the findings and weed out any false positive that may remain in the report. Reporting an incorrect security finding can often undermine the valid message of the rest of a security report. Care should be taken to verify that every possible section of application logic has been tested, and that every use case scenario was explored for possible vulnerabilities.
Use Source Code When Available
While black box penetration test results can be impressive and useful to demonstrate how vulnerabilities are exposed in production, they are not the most effective way to secure an application. If the source code for the application is available, it should be given to the security staff to assist them while performing their review. It is possible to discover vulnerabilities within the application source that would be missed during a black box engagement.
Develop Metrics
An important part of a good security program is the ability to determine if things are getting better. It is important to track the results of testing engagements, and develop metrics that will reveal the application security trends within the organization. These metrics can show if more education and training are required, if there is a particular security mechanism that is not clearly understood by development, and if the total number of security related problems being found each month is going down. Consistent metrics that can be generated in an automated way from available source code will also help the organization in assessing the effectiveness of mechanisms introduced to reduce security bugs in software development. Metrics are not easily developed so using standard metrics like those provided by the OWASP Metrics project and other organizations might be a good head start.
Document the Test Results
To conclude the testing process, it is important to produce a formal record of what testing actions were taken, by whom, when they ware performed, and details of the test findings. It is wise to agree on an acceptable format for the report which is useful to all concerned parties, which may include developers, project management, business owners, IT department, audit, and compliance. The report must be clear to the business owner in identifying where material risks exist and sufficient to get their backing for subsequent mitigation actions. The report must be clear to the developer in pin-pointing the exact function that is affected by the vulnerability, with associated recommendations for resolution in a language that the developer will understand (no pun intended). Last but not least, the report writing should not be overly burdensome on the security tester themselves; security testers are not generally renowned for their creative writing skills, therefore agreeing on a complex report can lead to instances where test results do not get properly documented.

Testing Techniques Explained

This section presents a high-level overview of various testing techniques that can be employed when building a testing program. It does not present specific methodologies for these techniques, although Chapter 3 will address this information. This section is included to provide context for the framework presented in the next Chapter and to highlight the advantages and disadvantages of some of the techniques that can be considered. In particular, we will cover:

Manual Inspections & Reviews
Threat Modeling
Code Review
Penetration Testing

Manual Inspections & Reviews

Overview
Manual inspections are human-driven reviews that typically test the security implications of the people, policies, and processes, but can include inspection of technology decisions such as architectural designs. They are usually conducted by analyzing documentation or using interviews with the designers or system owners. While the concept of manual inspections and human reviews is simple, they can be among the most powerful and effective techniques available. By asking someone how something works and why it was implemented in a specific way, it allows the tester to quickly determine if any security concerns are likely to be evident. Manual inspections and reviews are one of the few ways to test the software development life-cycle process itself and to ensure that there is an adequate policy or skill set in place. As with many things in life, when conducting manual inspections and reviews we suggest you adopt a trust-but-verify model. Not everything everyone tells you or shows you will be accurate. Manual reviews are particularly good for testing whether people understand the security process, have been made aware of policy, and have the appropriate skills to design and/or implement a secure application. Other activities, including manually reviewing the documentation, secure coding policies, security requirements, and architectural designs, should all be accomplished using manual inspections.

Advantages:

Requires no supporting technology
Can be applied to a variety of situations
Flexible
Promotes team work
Early in the SDLC

Disadvantages:

Can be time consuming
Supporting material not always available
Requires significant human thought and skill to be effective!

Threat Modeling

Overview
Threat modeling has become a popular technique to help system designers think about the security threats that their systems will face. Therefore, threat modeling can be seen as risk assessment for applications. In fact, it enables designer to develop mitigation strategies for potential vulnerabilities and helps them focus their inevitably limited resources and attention on the parts of the system that most require it. It is recommended that all applications have a threat model developed and documented. Threat models should be created as early as possible in the SDLC, and should be revisited as the application evolves and development progresses. To develop a threat model, we recommend taking a simple approach that follows the NIST 800-30 (3) standard for risk assessment. This approach involves:

Decomposing the application – understand, through a process of manual inspection, how the application works, its assets, functionality, and connectivity.
Defining and classifying the assets – classify the assets into tangible and intangible assets and rank them according to business criticality.
Exploring potential vulnerabilities (technical, operational, and management).
Exploring potential threats – develop a realistic view of potential attack vectors from an attacker’s perspective, by using threat scenarios or attack trees.
Creating mitigation strategies – develop mitigating controls for each of the threats deemed to be realistic. The output from a threat model itself can vary but is typically a collection of lists and diagrams. Part 2 of the OWASP Testing Guide (the detailed “How To” text) will outline a specific Threat Modeling methodology. There is no right or wrong way to develop threat models, and several techniques have evolved, for example, the OCTAVE model from Carnegie Mellon (http://www.cert.org/octave/).

Advantages:

Practical attacker's view of the system
Flexible
Early in the SDLC

Disadvantage :

Relatively new technique
Good threat models don’t automatically mean good software

Note: (3) Stoneburner, G., Goguen, A., & Feringa, A. (2001, October). Risk management guide for information technology systems. Retrieved May 7, 2004, from http://csrc.nist.gov/publications/nistpubs/800-30/sp800-30.pdf

Source Code Review

Overview
Source code review is the process of manually checking a web application's source code for security issues. Many serious security vulnerabilities cannot be detected with any other form of analysis or testing. As the popular saying goes “if you want to know what’s really going on, go straight to the source”. Almost all security experts agree that there is no substitute for actually looking at the code. All the information for identifying security problems is there in the code somewhere. Unlike testing third party closed software such as operating systems, when testing web applications (especially if they have been developed in-house) the source code should be made available for testing purposes. Many unintentional but significant security problems are also extremely difficult to discover with other forms of analysis or testing, such as penetration testing, making source code analysis the technique of choice for technical testing. With the source code a tester can accurately determine what is happening (or is supposed to be happening) and remove the guess work of black box testing. Examples of issues that are particularly conducive to being found through source code reviews include concurrency problems, flawed business logic, access control problems and cryptographic weaknesses as well as backdoors, Trojans, Easter eggs, time bombs, logic bombs, and other forms of malicious code. These issues often manifest themselves as the most harmful vulnerabilities in web sites. Source code analysis can also be extremely efficient to find implementation issues such as places where input validation was not performed or when fail open control procedures may be present. But keep in mind that operational procedures need to be reviewed as well, since the source code being deployed might not be the same as the one being analyzed (4).
Advantages

Completeness and effectiveness
Accuracy
Fast (for competent reviewers)

Disadvantages

Requires highly skilled security developers
Can miss issues in compiled libraries
Cannot detect run-time errors easily
The source code actually deployed might differ from the one being analyzed

Note: (4) See "Reflections on Trusting Trust" by Ken Thompson (http://cm.bell-labs.com/who/ken/trust.html)

For more on code review OWASP manage a code review project:

http://www.owasp.org/index.php/Category:OWASP_Code_Review_Project

Penetration Testing

Overview
Penetration testing has become a common technique used to test network security for many years. It is also commonly known as black box testing or ethical hacking. Penetration testing is essentially the “art” of testing a running application remotely, without knowing the inner workings of the application itself, to find security vulnerabilities. Typically, the penetration test team would have access to an application as if they were users. The tester acts like an attacker and attempts to find and exploit vulnerabilities. In many cases the tester will be given a valid account on the system. While penetration testing has proven to be effective in network security, the technique does not naturally translate to applications. When penetration testing is performed on networks and operating systems, the majority of the work is involved in finding and then exploiting known vulnerabilities in specific technologies. As web applications are almost exclusively bespoke, penetration testing in the web application arena is more akin to pure research. Penetration testing tools have been developed that automate the process, but, again, with the nature of web applications their effectiveness is usually poor. Many people today use web application penetration testing as their primary security testing technique. Whilst it certainly has its place in a testing program, we do not believe it should be considered as the primary or only testing technique. Gary McGraw summed up penetration testing well when he said, “If you fail a penetration test you know you have a very bad problem indeed. If you pass a penetration test you do not know that you don’t have a very bad problem”. However, focused penetration testing (i.e., testing that attempts to exploit known vulnerabilities detected in previous reviews) can be useful in detecting if some specific vulnerabilities are actually fixed in the source code deployed at the web site.
Advantages

Can be fast (and therefore cheap)
Requires a relatively lower skill-set than source code review
Tests the code that is actually being exposed

Disadvantages

Too late in the SDLC
Front impact testing only!

The Need for a Balanced Approach

With so many techniques and so many approaches to testing the security of your web applications, it can be difficult to understand which techniques to use and when to use them. Experience shows that there is no right or wrong answer to exactly what techniques should be used to build a testing framework. The fact remains that all techniques should probably be used to ensure that all areas that need to be tested are tested. What is clear, however, is that there is no single technique that effectively covers all security testing that must be performed to ensure that all issues have been addressed. Many companies adopt one approach, which has historically been penetration testing. Penetration testing, while useful, cannot effectively address many of the issues that need to be tested, and is simply “too little too late” in the software development life cycle (SDLC). The correct approach is a balanced one that includes several techniques, from manual interviews to technical testing. The balanced approach is sure to cover testing in all phases in the SDLC. This approach leverages the most appropriate techniques available depending on the current SDLC phase. Of course there are times and circumstances where only one technique is possible; for example, a test on a web application that has already been created, and where the testing party does not have access to the source code. In this case, penetration testing is clearly better than no testing at all. However, we encourage the testing parties to challenge assumptions, such as no access to source code, and to explore the possibility of complete testing. A balanced approach varies depending on many factors, such as the maturity of the testing process and corporate culture. However, it is recommended that a balanced testing framework look something like the representations shown in Figure 3 and Figure 4. The following figure shows a typical proportional representation overlaid onto the software development life cycle. In keeping with research and experience, it is essential that companies place a higher emphasis on the early stages of development.

Figure 3: Proportion of Test Effort in SDLC

The following figure shows a typical proportional representation overlaid onto testing techniques.

Figure 4: Proportion of Test Effort According to Test Technique

A Note about Web Application Scanners
Many organizations have started to use web application scanners. While they undoubtedly have a place in a testing program, we want to highlight some fundamental issues about why we do not believe that automating black box testing is (or will ever be) effective. By highlighting these issues, we are not discouraging web application scanner use. Rather, we are saying that their limitations should be understood, and testing frameworks should be planned appropriately. NB: OWASP is currently working to develop a web application scanner-benchmarking platform. The following examples indicate why automated black box testing is not effective.
Example 1: Magic Parameters
Imagine a simple web application that accepts a name-value pair of “magic” and then the value. For simplicity, the GET request may be: http://www.host/application?magic=value
To further simplify the example, the values in this case can only be ASCII characters a – z (upper or lowercase) and integers 0 – 9. The designers of this application created an administrative backdoor during testing, but obfuscated it to prevent the casual observer from discovering it. By submitting the value sf8g7sfjdsurtsdieerwqredsgnfg8d (30 characters), the user will then be logged in and presented with an administrative screen with total control of the application. The HTTP request is now:
http://www.host/application?magic= sf8g7sfjdsurtsdieerwqredsgnfg8d
Given that all of the other parameters were simple two- and three-characters fields, it is not possible to start guessing combinations at approximately 28 characters. A web application scanner will need to brute force (or guess) the entire key space of 30 characters. That is up to 3028 permutations, or trillions of HTTP requests! That is an electron in a digital haystack! The code for this may look like the following:

public void doPost( HttpServletRequest request, HttpServletResponse response) 
{ 
String magic = “sf8g7sfjdsurtsdieerwqredsgnfg8d”; 
boolean admin = magic.equals( request.getParameter(“magic”));
if (admin) doAdmin( request, response); 
else …. // normal processing 
}

By looking in the code, the vulnerability practically leaps off the page as a potential problem.
Example 2: Bad Cryptography
Cryptography is widely used in web applications. Imagine that a developer decided to write a simple cryptography algorithm to sign a user in from site A to site B automatically. In his/her wisdom, the developer decides that if a user is logged into site A, then he/she will generate a key using an MD5 hash function that comprises: Hash { username : date }
When a user is passed to site B, he/she will send the key on the query string to site B in an HTTP re-direct. Site B independently computes the hash, and compares it to the hash passed on the request. If they match, site B signs the user in as the user they claim to be. Clearly, as we explain the scheme, the inadequacies can be worked out, and it can be seen how anyone that figures it out (or is told how it works, or downloads the information from Bugtraq) can login as any user. Manual inspection, such as an interview, would have uncovered this security issue quickly, as would inspection of the code. A black-box web application scanner would have seen a 128-bit hash that changed with each user, and by the nature of hash functions, did not change in any predictable way.
A Note about Static Source Code Review Tools
Many organizations have started to use static source code scanners. While they undoubtedly have a place in a comprehensive testing program, we want to highlight some fundamental issues about why we do not believe this approach is effective when used alone. Static source code analysis alone cannot understand the context of semantic constructs in code, and therefore is prone to a significant number of false positives. This is particularly true with C and C++. The technology is useful in determining interesting places in the code, however significant manual effort is required to validate the findings.
For example:

char szTarget[12];

char *s = "Hello, World"; 

size_t cSource = strlen_s(s,20); 

strncpy_s(temp,sizeof(szTarget),s,cSource); 

strncat_s(temp,sizeof(szTarget),s,cSource);

OWASP Testing Guide v3

Here is the OWASP Testing Guide v3 Table of Contents

Security Requirements Test Derivation

Testing Objectives
One of the objectives of security testing is to validate that security controls function as expected. This is documented via security requirements that describe the functionality of the security control. At high level, this means proving confidentiality, integrity, and availability of the data as well as the service. The other objective is to validate that security controls are implemented with few or no vulnerabilities. These are common vulnerabilities, such as the OWASP Top Ten, as well as vulnerabilities that are previously identified with security assessments during the SDLC, such as threat modeling, source code analysis, and penetration test.

Security Requirements Documentation
The first step in the documentation of security requirements is to understand the business requirements. A business requirement document could provide the initial, high-level information of the expected functionality for the application. For example, the main purpose of the application is to provide financial services to customers or shopping and purchasing goods from an on-line catalogue. A security section of the business requirements should highlight the need to protect the customer data as well as to comply with applicable security documentation such as regulations, standards, and policies.

A general checklist of the applicable regulations, standards, and policies serves well the purpose of a preliminary security compliance analysis for web applications. For example, compliance regulations can be identified by checking information about the business sector and the country/state where the application needs to function/operate. Some of these compliance guidelines and regulations might translate in specific technical requirements for security controls. For example, in case of financial applications, the compliance with FFIEC guidelines for authentication requires that financial institutions implement applications that mitigate weak authentication risks with multi-layered security control and multi factor authentication.

Applicable industry standards for security need also to be captured by the general security requirement checklist. For example, in the case of applications that handle customer credit card data, the compliance with the PCI DSS standard forbids the storage of PINs and CVV2 data and requires that merchant protect magnetic strip data in storage and transmission with encryption and on display by masking. Such PCI DSS security requirements could be validated via source code analysis.

Another section of the checklist needs to enforce general requirements for compliance with the organization information security standards and policies. From the functional requirements perspective, requirement for the security control needs to map to a specific section of the information security standards. An example of such requirement can be: "a password complexity of six alphanumeric characters must be enforced by the authentication controls used by the application." When security requirements map to compliance rules a security test can validate the exposure of compliance risks. If violation with information security standards and policies are found, these will result in a risk that can be documented and that the business has to deal with (i.e., manage). For this reason, since these security compliance requirements are enforceable, they need to be well documented and validated with security tests.

Security Requirements Validation
From the functionality perspective, the validation of security requirements is the main objective of security testing, while, from the risk management perspective, this is the objective of information security assessments. At high level, the main goal of information security assessments is the identification of gaps in security controls, such as lack of basic authentication, authorization, or encryption controls. More in depth, the security assessment objective is risk analysis, such as the identification of potential weaknesses in security controls that ensure the confidentiality, integrity, and availability of the data. For example, when the application deals with personal identifiable information (PII) and sensitive data, the security requirement to be validated is the compliance with the company information security policy requiring encryption of such data in transit and in storage. Assuming encryption is used to protect the data, encryption algorithms and key lengths need to comply with the organization encryption standards. These might require that only certain algorithms and key lengths could be used. For example, a security requirement that can be security tested is verifying that only allowed ciphers are used (e.g., SHA-1, RSA, 3DES) with allowed minimum key lengths (e.g., more than 128 bit for symmetric and more than 1024 for asymmetric encryption).

From the security assessment perspective, security requirements can be validated at different phases of the SDLC by using different artifacts and testing methodologies. For example, threat modeling focuses on identifying security flaws during design, secure code analysis and reviews focus on identifying security issues in source code during development, and penetration testing focuses on identifying vulnerabilities in the application during testing/validation.

Security issues that are identified early in the SDLC can be documented in a test plan so they can be validated later with security tests. By combining the results of different testing techniques, it is possible to derive better security test cases and increase the level of assurance of the security requirements. For example, distinguishing true vulnerabilities from the un-exploitable ones is possible when the results of penetration tests and source code analysis are combined. Considering the security test for a SQL injection vulnerability, for example, a black box test might involve first a scan of the application to fingerprint the vulnerability. The first evidence of a potential SQL injection vulnerability that can be validated is the generation of a SQL exception. A further validation of the SQL vulnerability might involve manually injecting attack vectors to modify the grammar of the SQL query for an information disclosure exploit. This might involve a lot of trial-and-error analysis till the malicious query is executed. Assuming the tester has the source code, she might learn from the source code analysis on how to construct the SQL attack vector that can exploit the vulnerability (e.g., execute a malicious query returning confidential data to unauthorized user).

Threats and Countermeasures Taxonomies
A threat and countermeasure classification that takes into consideration root causes of vulnerabilities is the critical factor to verify that security controls are designed, coded, and built so that the impact due to the exposure of such vulnerabilities is mitigated. In the case of web applications, the exposure of security controls to common vulnerabilities, such as the OWASP Top Ten, can be a good starting point to derive general security requirements. More specifically, the application security frame categorization (e.g., authentication, authorization, data protection, data validation, session management, configuration management, error and exception handling, and auditing and logging) provides a classification (e.g., taxonomy) of vulnerabilities that can be documented in different guidelines and standards, and validated with security tests.

The focus of a threat and countermeasure categorization is to define security requirements in terms of the threats and the root cause of the vulnerability. A threat can be categorized by using STRIDE, for example, as Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, and Elevation of privilege. The root cause can be categorized as security flaw in design, a security bug in coding, or an issue due to insecure configuration. For example, the root cause of weak authentication vulnerability might be the lack of mutual authentication when data crosses a trust boundary between the client and server tiers of the application. A security requirement that captures the threat of non-repudiation during an architecture design review allows for the documentation of the requirement for the countermeasure (e.g., mutual authentication) that can be validated later on with security tests.

A threat and countermeasure categorization for vulnerabilities can also be used to document security requirements for secure coding such as secure coding standards. An example of a common coding error in authentication controls consists of applying an hash function to encrypt a password, without applying a seed to the value. From the secure coding perspective, this is a vulnerability that affects the encryption used for authentication with a vulnerability root cause in a coding error. Since the root cause is insecure coding the security requirement can be documented in secure coding standards and validated through secure code reviews during the development phase of the SDLC.

Security Testing and Risk Analysis
Security requirements need to take into consideration the severity of the vulnerabilities to support a risk mitigation strategy. Assuming that the organization maintains a repository of vulnerabilities found in applications, i.e., a vulnerability knowledge base, the security issues can be reported by type, issue, mitigation, root cause, and mapped to the applications where they are found. Such vulnerability knowledge base can also be used to establish a metrics to analyze the effectiveness of the security tests throughout the SDLC.

For example, consider an input validation issue, such as a SQL injection, which was identified via source code analysis and reported with a coding error root cause and input validation vulnerability type. The exposure of such vulnerability can be assessed via a penetration test, by probing input fields with several SQL injection attack vectors. This test might validate that special characters are filtered before hitting the database and mitigate the vulnerability. By combining the results of source code analysis and penetration testing it is possible to determine the likelihood and exposure of the vulnerability and calculate the risk rating of the vulnerability. By reporting vulnerability risk ratings in the findings (e.g., test report) it is possible to decide on the mitigation strategy. For example, high and medium risk vulnerabilities can be prioritized for remediation, while low risk can be fixed in further releases.

By considering the threat scenarios exploiting common vulnerabilities it is possible to identify potential risks for which the application security control needs to be security tested. For example, the OWASP Top Ten vulnerabilities can be mapped to attacks such as phishing, privacy violations, identify theft, system compromise, data alteration or data destruction, financial loss, and reputation loss. Such attacks might represent threat scenarios that can be documented as part of the threat scenarios. By thinking in terms of threats and vulnerabilities, it is possible to devise a battery of tests that simulate such attack scenarios. Ideally, the organization vulnerability knowledge base can be used to derive security risk driven tests cases to validate most likely attack scenarios. For example if identity theft is considered high risk, negative test scenarios should validate the mitigation of impacts deriving from the exploit of vulnerabilities in authentication, cryptographic controls, input validation, and authorization controls.

Functional and Non Functional Test Requirements

Functional Security Requirements
From the perspective of functional security requirements, the applicable standards, policies and regulations drive both the need of a type of security control as well as the control functionality. These requirements are also referred to as “positive requirements”, since they state the expected functionality that can be validated through security tests. Examples of positive requirements are: “the application will lockout the user after 6 failed logon attempts” or “passwords need to be 6 min characters, alphanumeric”. The validation of positive requirements consists of asserting the expected functionality and, as such, can be tested by re-creating the testing conditions, and by running the test according to predefined inputs and by asserting the expected outcome as a fail/pass condition.

In order to validate security requirements with security tests, security requirements need to be functional driven and highlight the expected functionality (the what) and implicitly the implementation (the how). Examples of high-level security design requirements for authentication can be:

Protect user credentials and shared secrets in transit and in storage
Mask any confidential data in display (e.g., passwords, accounts)
Lock the user account after a certain number of failed login attempts
Do not show specific validation errors to the user as a result of failed logon
Only allow passwords that are alphanumeric, include special characters and six characters minimum length, to limit the attack surface
Allow for password change functionality only to authenticated users by validating the old password, the new password and the user answer to the challenge question, to prevent brute forcing of a password via password change.
The password reset form should validate the user’s username and the user’s registered email before sending the temporary password to the user via email. The temporary password issued should be a one time password. A link to the password reset web page will be sent to the user. The password reset web page should validate the user temporary password, the new password as well as the user answer to the challenge question.

Risk Driven Security Requirements
Security tests need also to be risk driven, that is they need to validate the application for unexpected behavior. These are also called “negative requirements”, since they specify what the application should not do. Examples of "should not do" (negative) requirements are:

The application should not allow for the data to be altered or destroyed
The application should not be compromised or misused for unauthorized financial transactions by a malicious user.

Negative requirements are more difficult to test, because there is no expected behavior to look for. This might require a threat analyst to come up with unforeseeable input conditions, causes, and effects. This is where security testing needs to be driven by risk analysis and threat modeling. The key is to document the threat scenarios and the functionality of the countermeasure as a factor to mitigate a threat. For example, in case of authentication controls, the following security requirements can be documented from the threats and countermeasure perspective:

Encrypt authentication data in storage and transit to mitigate risk of information disclosure and authentication protocol attacks
Encrypt passwords using non reversible encryption such as using a digest (e.g., HASH) and a seed to prevent dictionary attacks
Lockout accounts after reaching a logon failure threshold and enforce password complexity to mitigate risk of brute force password attacks
Display generic error messages upon validation of credentials to mitigate risk of account harvesting/enumeration
Mutually authenticate client and server to prevent non-repudiation and Man In the Middle (MiTM) attacks

Threat modeling artifacts such as threat trees and attack libraries can be useful to derive the negative test scenarios. A threat tree will assume a root attack (e.g., attacker might be able to read other users messages) and identify different exploits of security controls (e.g., data validation fails because of a SQL injection vulnerability) and necessary countermeasures (e.g., implement data validation and parametrized queries) that could be validated to be effective in mitigating such attacks.

Security Requirements Derivation Through Use and Misuse Cases

Pre-requisite in describing the application functionality is to understand what the application suppose to do and how. This can be done by describing use cases. Use cases, in the graphical form as commonly used in software engineering, show the interactions of actors and their relations and help to identify the actors in the application, their relationships, the intended sequence of actions for each scenario, alternative actions, special requirements, and pre- and post-conditions. Similar to use cases, misuse and abuse cases describe unintended and malicious use scenarios of the application. These misuse cases provide a way to describe scenarios of how an attacker could misuse and abuse the application. By going through the individual steps in a use scenario and thinking about how can be maliciously exploited, potential flaws or aspects of the application that are not well defined can be discovered. The key is to describe all possible or at least the most critical use and misuse scenarios. Misuse scenarios allow the analysis of the application from the attacker's point of view and contribute to identifying potential vulnerabilities and the countermeasures that need to be implemented to mitigate the impact caused by the potential exposure to such vulnerabilities. Given all of the use, abuse cases, it is important to analyze them to determine which of them are the most critical ones and need to be documented in security requirements. The identification of the most critical misuse and abuse cases drives the documentation of security requirements and the necessary controls where security risks should be mitigated.

To derive security requirements from use and misuse case it is important to define the functional scenarios and the negative scenario and put these in graphical form. In the case of derivation of security requirements for authentication for example the following step by step methodology can be followed.

Step 1: Describe the Functional Scenario: User authenticates by supplying username and password. The application grants access to users based upon authentication of user credentials by the application and provides specific errors to the user when validation fails.

Step 2: Describe the Negative Scenario: Hacker breaks the authentication through brute force/dictionary attack of passwords and account harvesting vulnerabilities in the application. The validation errors provide specific information to an hacker to guess which accounts are actually valid registered accounts (usernames). The hacker then will try to brute force the password for such valid account. A brute force attack to four minimum length all digit passwords can succeed with limited number of attempts (e.g. 10^4)

Step 3: Describe Functional and Negative Scenarios With Use and Misuse Case:

The graphical example in Figure TBD depicts the derivation of security requirements via use and and misuse cases. The functional scenario consists on the user action: entering username and password and for the application actions: authenticate the user and provide for an error message if validation fails. The misuse case consists on the actions: hacker trying to break authentication by brute forcing the password via a dictionary attack and by guessing the valid username from the error messages. By graphically representing the threats to the user actions (misuses) it is possible to derive the countermeasures as the application actions that mitigate such threats.

Step 4: Elicit The Security Requirements.

In this case, the following security requirements for authentication are derived:

1) Passwords need to be alphanumeric, lower and upper case and minimum of seven character length

2) Accounts need to lockout after five unsuccessful login attempt

3) Logon error messages need to be generic

These security requirements need to be documented and tested.

Security Tests Integrated in Developers and Testers Workflow

Developer’s Security Testing Workflow
Security testing during the development phase of the SDLC represents the first of opportunity for developers to ensure that individual software components that they have developed are security tested before they are integrated with other components and built into the application. Software components might consist of software artifacts such as functions, methods, and classes as well as application programming interfaces, libraries, and executable. For security testing, developers can rely on the results of the source code analysis to verify statically that developed source code does not include potential vulnerabilities in compliance with the secure coding standards. Security unit tests can further verify dynamically (e.g. run time) that the components function as expected. Before integrating both new and existing code changes in the application build the results of the static and dynamic analysis should be reviewed and validated. The validation of source code before integration in application builds is usually the responsibility of the senior developer. Such senior developer is also the subject matter expert in software security and his role is to lead the secure code review and make decisions whether to accept the code to be released in the application build or to require further changes and testing. This secure code review workflow can be enforced via formal acceptance as well as a check in a workflow management tool. For example, assuming the typical defect management workflow used for functional bugs, security bugs that have been fixed by a developer can be reported on a defect or change management system. The build master can look at the test results reported by the developers in the tool and grant approvals for checking in the code changes into the application build.

Tester’s Security Testing Workflow
After components and code changes are tested by developers and checked in to the application build the most likely next step in the software development process workflow is to perform tests on the application as a whole entity. This level of testing is usually referred to as integrated test and system level test. When security tests are part of these testing activities can be used to validate both the security functionality of the application as a whole as well as exposure to application level vulnerabilities. These security tests on the application include both white box testing such as source code analysis and black box testing such as penetration testing.

The target for the security tests is the complete system that is the artifact that will be potentially attacked and includes both whole source code and the executable. One peculiarity of security testing during this phase is that it is possible for security testers to determine whether vulnerabilities can be exploited and expose the application to real risks. This includes common web application vulnerabilities as well as security issues that have been identified earlier in the SDLC with other activities such as threat modeling, source code analysis, and secure code reviews.

Usually testing engineers, rather then software developers perform security tests when the application is in scope for integration system tests. Such testing engineers have security knowledge of web application vulnerabilities, black box and white box security testing techniques, and own the validation of security requirements in this phase. In order to perform such security tests it is a pre-requisite that security test cases are documented in the security testing guidelines and procedures.

A testing engineer that validates the security of the application in the integrated system environment might release the application for testing in the operational environment (e.g. user acceptance tests). At this stage of the SDLC (e.g. validation) the application functional testing is usually a responsibility of QA testers while white-hat hackers/security consultants are usually responsible for security testing. Some organizations rely on their own specialized ethical hacking team in order to conduct such tests when a third party assessment is not required (such as for auditing purposes).

Since these tests are the last resort for fixing vulnerabilities before the application is released to production, it is important that such issues are addressed as recommended by the testing team (e.g. code, design or configuration change). At this level, security auditors and information security officers discuss the security issues being reported and analyze the potential risks according to information risk management procedures. Such procedures might require the developer team to fix all high risk vulnerabilities before the application could be deployed unless such risks are acknowledged and accepted.

Developers' Security Tests

Security Testing in the Coding Phase: Unit Tests
From the developer’s perspective the main objective of security tests are to validate that code is being developed in compliance with secure coding standards requirements. Developers' own coding artifacts such as functions, methods, classes, APIs, and libraries need to be functionally validated before being integrated into the application build.

The security requirements that developers have to follow should be documented in secure coding standards and validated with static and dynamic analysis. As testing activity following a secure code review, unit tests can validate that code changes required by secure code reviews are properly implemented. Secure code reviews and source code analysis through source code analysis tools help developers in identifying security issues in source code as it is developed. By using unit tests and dynamic analysis (e.g. debugging) developers can validate the security functionality of components as well as verify that the countermeasures being developed mitigate any security risks previously identified through threat modeling and source code analysis.

A good practice for developers is to build security test cases into the security unit testing framework. A security unit testing framework might consist on a place holder for security test cases and used to wrap the functions, methods and classes that need to be security tested. Developers empowered with a source code analysis tool integrated with their IDE, secure coding standards, and a security unit testing framework can assess and verify the security of the software components being developed. Security test cases can be run to identify potential security issues that have root causes in source code: besides input and output validation of parameters entering and exiting the components, this includes authentication and authorizations checks done by the component, protection of the data within the component, secure exception and error handling, and secure auditing and logging. Unit test frameworks such as Junit, Nunit, CUnit can be adapted to verify security test requirements. In the case of security functional tests, unit level tests can test the functionality of security controls at software component level such as functions, methods or classes. For example, a test case could validate input and output validation (e.g. variable sanitization), boundary checks for variables by asserting the expected functionality of the component.

The threat scenarios identified with use and misuse cases, can be used to document the procedures for testing software components. In the case of authentication components for example, security unit tests can assert the functionality of setting an account lockout as well as the fact that user input parameters cannot be abused to bypass the account lockout (e.g. by setting of the account lockout counter to a negative number). At the component level, security unit tests can validate positive assertions as well as negative assertions such as errors and exception handling. Exceptions should be caught without leaving the system in an un-secure state such as potential denial of service caused by resources not being de-allocated (e.g. connection handles not closed within a final statement block) as well as potential elevation of privileges (e.g. higher privileges acquired before the exception is thrown and not re-set to previous level before exiting the function). Secure error handling can validate potential information disclosure via informative error messages and stack traces.

Unit level security test cases can be developed by a security engineer that is subject matter expert in software security and is also responsible to validate that the security issues in the source code have been fixed and can be checked into the integrated system build. Typically the manager of the application builds also makes sure that third party libraries and executable files are security assessed for potential vulnerabilities before being integrated in the application build.

Threat scenarios for common vulnerabilities that have root causes on un-secure coding can also be documented in developer’s security testing guide. When a fix is implemented for a coding defect identified with source code analysis for example, security test cases can verify that the implementation of the code change follow the secure coding requirements documented in the secure coding standards.

Source code analysis and unit tests can validate that the code change mitigates the vulnerability exposed by the previously identified coding defect. The results of automated secure code analysis can also be used as automatic check-in gate for version control: software artifacts cannot be checked into the build with high or medium severity coding issues.

Functional Testers' Security Tests

Security Testing During the Integration and Validation Phase: Integrated System Tests and Operation Tests
The main objective of integrated system tests is to validate the “defense in depth” concept that is implementation of security controls provide security at different layers. For example, the lack of input validation when calling a component integrated with the application is often the factor that can be tested with integration testing.

The integration system test environment is also the first environment where testers can simulate real attack scenarios as can be potentially executed by a malicious external or internal user of the application. Security testing at this level can validate whether vulnerabilities are real and can be exploited by attackers. For example a potential vulnerability found in source code can be rated as high risk because of the exposure to potential malicious user as well because of the potential impact (e.g. access to confidential information). Real attack scenarios can be tested with both manual testing techniques and penetration testing tools. Security tests of this type are also referred ethical hacking tests. From the security testing perspective these are risk driven tests and have the objective to test the application in the operational environment. The target is the application build that is representative of the version of the application being deployed into production.

The execution of security in the integration and validation phase is critical to identify vulnerabilities due to integration of components as well as to validate the exposure of such vulnerabilities. Since application security testing requires a specialized set of skills that includes both software and security knowledge and is not typical of security engineers, it often requires organizations to security train their software developers on ethical hacking techniques, security assessment procedures and tools. A realistic scenario is to develop such resources in-house and document in a security testing guides and procedures that take into account of the developer’s security testing knowledge. A so called “security test cases cheat list or check-list” for example can provide simple test cases and attack vectors that can be used by testers to validate exposure to common vulnerabilities such as spoofing, information disclosures, buffer overflows, format strings, SQL injection and XSS injection, XML, SOAP, canonicalization issues, denial of service and managed code and ActiveX controls (e.g. .NET). A first battery of these tests can be performed manually with a very basic knowledge of software security. The first objective of security tests might be the validation of a set of minimum security requirements. The security test case might consist on manually forcing the application to errors and exceptions and gather knowledge from the application behavior. For example, SQL injection vulnerability can be tested manually by injecting attack vectors through user input and by checking if SQL exceptions are thrown back the user. The evidence of a SQL exception error might represent a vulnerability that can be exploited. A more in depth security testing might require the tester’s knowledge of specialized testing techniques and tools: besides source code analysis and penetration testing these include source code and binary fault injection, fault propagation analysis and code coverage, fuzz testing and reverse engineering as an example. The security testing guide should provide procedures and recommend tools that can be used by security testers to perform such in-depth security assessments.

The next level of security testing after integration system tests is to perform security tests in the user acceptance environment. There are unique advantages to perform security tests in the operational environment. The user acceptance tests environment (UAT) is the one that is most representative of the release configuration expect for the data (e.g. test data not real data). A peculiarity of security testing in UAT is testing for security configuration issues. In some cases these vulnerabilities might represent high risks. For example the server that hosts the web application might not be configured with minimum privileges, valid SSL certificate and secure configuration, essential services disabled and web root directory not cleaned from test and administration web pages.

Security Test Data Analysis and Reporting

Goals for Security Test Metrics and Measurements
The definition of the goals for the security testing metrics and measurements is a pre-requisite for using security testing data for risk analysis and management processes. For example, a measurement such as the total number of vulnerabilities found with security tests, might quantify the security posture of the application. These measurements also help to identify security objectives for software security testing: for example, reducing the number of vulnerabilities to an acceptable number (minimum) before the application is deployed into production.

Another manageable goal could be to compare the application security posture against a baseline to assess improvements in application security processes. For example the security metrics baseline might consist of an application that was tested only with penetration tests. The security data obtained from an application that was also security tested during coding should show an improvement (e.g. fewer number of vulnerabilities) when compared with the baseline.

In traditional software testing, software defects such as the number of bugs found in an application for could provide a measure of software quality. Similarly, security testing can provide a measure of software security. From the defect management and reporting perspective software quality and security testing can leverage similar issue categorizations and metrics. For example, security test data can be categorized from the cause, such as: defect due to an error in design (e.g. security flaws) or a defect due to an error in coding (e.g. security bug). Similarly to quality test data, security test data can also be categorized by the effort required to fix the defect such as: developer hours, the tools and resources required to fix, and finally the cost to implement the fix.

A peculiarity of security test data compared to quality data is the categorization in terms of the threat, the exposure of the vulnerability, and the potential impact posed by the vulnerability to determine the risk. Testing applications for security consists of managing technical risks to make sure that the application countermeasures meet acceptable levels. For this reason, security testing data needs to support the security risk strategy at critical checkpoints during the SDLC. For example vulnerabilities found in source code with source code analysis represent an initial measure of risk. Such measure of risk (e.g. high, medium, low) for the vulnerability can be calculated by determining the exposure and likelihood factors and further by validating such vulnerability with penetration tests. The risk metrics associated to vulnerabilities found with security tests empower business management to make risk management decisions such as to decide whether risks can be accepted, mitigated or transferred at different levels within the organization (e.g. business as well as technical).

When evaluating the security posture of an applications it is important to take into consideration certain factors such as the size of the application being developed. Application size has been statistically proven to be related to the number of issues found in the application with tests. One measure of application size is the number of line of code (LOC) of the application. Back to software quality metrics, statistically/historically software quality defects range from about 7 to 10 defects per thousand lines of new and changed code. Since testing can reduce the overall number by about 25% with one test alone it is logical for larger size applications to be tested more and more often than smaller size applications.

When security testing is done in several phases of the SDLC the test data could prove the capability of the security tests in detecting vulnerabilities as soon as are introduced and prove the effectiveness of removing them by implementing countermeasures at different checkpoints of the SDLC. A measurement of this type is also defined as “containment metrics” and provide a measure of the ability of a security assessment performed at each phase of the development process to maintain security within each phase. These containment metrics are also a critical factor in lowering the cost of fixing the vulnerabilities since it is less expensive to deal with when they are found (in the same phase of the SDLC) rather then fixing them later in another phase.

Security test metrics can support security risk, cost, and defect management analysis when it is associated with tangible and timed goals such as:

Reducing the overall number of vulnerabilities by 30%
Security issues are expected to be fixed by a certain deadline (e.g. before beta release)

Security test data can be absolute such as the number of vulnerabilities detected during manual code review as well as comparative such as number of vulnerabilities detected in code reviews vs. penetration tests. To answer questions about the quality of the security process it is important to determine a baseline for what could be considered acceptable and good.

Security test data can also support specific objectives of the security analysis such as compliance with security regulations and information security standard, management of security processes, the identification of security root causes and process improvements, and security costs vs. benefits analysis.

When security test data is reported it has to provide metrics to support the analysis. The scope of the analysis is the interpretation of test data to find clues about the security of the software being produced as well the effectiveness of the process. Some examples of clues supported by security test data can be:

Are vulnerabilities reduced to an acceptable level for release?
How does the security quality of this product compare with similar software products?
Are all security test requirements being met?
What are the majority of the root causes of security issues?
How numerous are security flaws compared to security bugs?
Which security activity is most effective in finding vulnerabilities?
Which team is more productive in fixing security defects and vulnerabilities?
Which percentage of overall vulnerabilities are high risk?
Which tools are most effective in detecting security vulnerabilities?
Which kind of security tests are most effective in finding vulnerabilities (e.g. white box vs. black box) tests?
How many security issues are found during secure code reviews?
How many security issues are found during secure design reviews?

In order to make a sound judgment using the testing data it is important to have a good understanding of the testing process as well as the testing tools. Typically, the more experienced the security testers are with the security testing methodology and the testing tools the better the results of the security test and analysis will be.

Finally, it is important to note that even the most sophisticated automation tools are not a match for an experienced security tester: just relying on successful test results from automation tools will give security practitioners a false sense of security. It is important that managers making an investment on security testing tools also consider an investment in human resources as well as security test training and awareness.

Reporting Requirements
The security posture of an application can be characterized from the perspective of the effect, such as number of vulnerabilities and the risk rating of the vulnerabilities, as well as from the perspective of the cause (i.e. origin) such as, coding errors, architectural flaws, and configuration issues.

Vulnerabilities can be classified according to different criteria. This can be a statistical categorization such as the OWASP Top 10 and WASC (Web Application Security Statistics) or related to defensive controls as in the case of WASF (Web Application Security Framework) categorization.

Besides the categorization of each vulnerability by type, best practice while report security test data is to include the following information:

The security threat that the issue is exposed to
The root cause of security issues (e.g. security bugs, security flaw)
The testing technique used to find it
The remediation of the vulnerability (e.g. the countermeasure)
The risk rating of the vulnerability (High, Medium, Low)

By describing what the security threat is, it will be possible to understand if and why the mitigation control is ineffective in mitigating the threat.

Reporting the root cause of the issue can help pinpoint what needs to be fixed: in the case of a white box testing for example, the software security root cause of the vulnerability will be the offending source code.

Once issue are reported, it is also important to provide guidance to the software developer on how to re-test and find the vulnerability. This might involve using a white box testing technique (e.g. security code review with a static code analyzer) to find out if the code is vulnerable. If a vulnerability can be found via a black box technique (penetration test) the test report also needs to provide information on how to validate the exposure of the vulnerability to the front end (e.g. client).

The information about how to fix the vulnerability should be detailed enough for a developer to implement a fix. It should provide secure coding examples, configuration changes, and provide adequate references.

Finally the risk rating helps to prioritize the remediation effort. Typically, assigning a risk rating to the vulnerability involves a risk analysis based upon factors such as impact and exposure.

Business Cases
For the security test metrics to be useful, they need to provide value back to the organization's security test data stakeholders such as project managers, developers, information security offices, auditors, and chief information officers. The value can be in terms of the business case that each project stakeholder has in terms of role and responsibility.

Software developers look at security test data to show that software is coded more securely and efficiently so that they can made the case of using source code analysis tools as well as follow secure coding standards and attend software security training.

Project managers, look for data that allows them to successfully manage and utilize security testing activities and resources according to the project plan. To project managers, security test data can show that projects are on schedule and moving on target for delivery dates and are getting better during tests.

Security test data also helps the business case for security testing if the initiative comes from information security officers (ISOs). For example it can provide evidence that security test during the SDLC does not impact the project delivery but rather reduces the overall workload needed to address vulnerabilities later in production.

To compliance auditors security test metrics provide a level of software security assurance and confidence that security standard compliance is addressed through the security review processes within the organization.

Finally Chief Information Officers (CIOs) and Chief Information Security Officers (CISOs) responsible for the budget that needs to be allocated in security resources look for derivation of a cost/benefit analysis from security test data to make informed decisions on which security activities and tools to invest. One of the metrics that support such analysis is the Return On Investment (ROI) in Security. To derive such metrics from security test data it is important to quantify the differential between the risk due to the exposure of vulnerabilities and the effectiveness of the security tests in mitigating the security risk and factor this gap with the cost of the security testing activity or the testing tools adopted.

References

Books

Gary McGraw. Software Security: Building Security In. Addison-Wesley, Boston, MA, 2006. http://www.swsec.com

Whitepapers

Ian Alexander, “Misuse Cases, Use Cases with Hostile Intent”, 2003, http://doi.ieeecomputersociety.org/10.1109/MS.2003.1159030

Gil Regev, Ian Alexander,Alain Wegmann,”Use Cases and Misuse Cases Model the Regulatory Roles of Business Processes”, 2005 http://easyweb.easynet.co.uk/~iany/consultancy/regulatory_processes/regulatory_processes.htm

Sindre,G. Opdmal A. Capturing Security Requirements Through Misuse Cases, 2001 http://folk.uio.no/nik/2001/21-sindre.pdf

Nancy R. Mead, Security Requirement Engineering, 2006, https://buildsecurityin.us-cert.gov/daisy/bsi/articles/best-practices/requirements/243.html?branch=1&language=1

Sindre,G. Opdmal A. Capturing Security Requirements Through Misuse Cases, 2001 http://folk.uio.no/nik/2001/21-sindre.pdf

Joshua Pauli, Dianxiang Xu,”Misuse Case-Based Design and Analysis of Secure Software Architecture”, 2005 http://www.homepages.dsu.edu/paulij/pubs/pauli-xu-ITCC05.pdf

Hope, Paco, Gary McGraw, and Annie I. Anton," Misuse and Abuse Cases: Getting Past the Positive," IEEE Security and Privacy, May 2004 https://buildsecurityin.us-cert.gov/daisy/bsi/125/version/6/part/4/data/bsi2-misuse.pdf?branch=main&language=default

Testing Guide Introduction

The OWASP Testing Project

Principles of Testing

Testing Techniques Explained

Manual Inspections & Reviews

Threat Modeling

Source Code Review

Penetration Testing

The Need for a Balanced Approach

Security Requirements Test Derivation

Functional and Non Functional Test Requirements

Security Requirements Derivation Through Use and Misuse Cases

Security Tests Integrated in Developers and Testers Workflow

Developers' Security Tests

Functional Testers' Security Tests

Security Test Data Analysis and Reporting

References

Navigation menu

Personal tools

Namespaces

Variants

Views

More

Search

Navigation

Reference

Tools