Difference between revisions of "Testing Guide Foreword"

From OWASP
Jump to: navigation, search
Line 3: Line 3:
 
==Forward by [[User:Jeff Williams|Jeff Williams]], OWASP Chair==
 
==Forward by [[User:Jeff Williams|Jeff Williams]], OWASP Chair==
  
DRAFT - in progress
+
The problem of insecure software is perhaps the most important technical challenge of our time. Security is now the key limiting factor on what we are able to create with information technology. At OWASP, we're trying to make the world a place where insecure software is the anomoly, not the norm, and the OWASP Testing Guide is an important piece of the puzzle.
  
The problem of insecure software is perhaps the most important technical challenge of our time. Security is now the key limiting factor on what we are able to create with information technology.
+
It goes without saying that you can't build a secure application without performing security testing on it. Yet many software development organizations do not include security testing as part of their standard software developement process.
  
At OWASP, we're trying to make the world a place where insecure software is the anomoly, not the norm, and the OWASP Testing Guide is an important piece of the puzzle. It goes without saying that you can't build a secure application without performing security testing on it. Yet many software development organizations do not include security testing as part of their standard software testing process.
+
Security testing, by itself, isn't a particularly good measure of how secure an application is, because there are an infinite number of ways that an attacker might be able to make an application break, and it simply isn't possible to test them all. However, security testing has the unique power to absolutely convince naysayers that there is a problem.
  
Security testing is one piece of a complex set of teams, roles, activities, policies, standards, tools, and technologies that make building a secure application possible. Testing, by itself, isn't a particularly good measure of how secure an application is. The reason is that there are an infinite number of ways that an attacker might be able to make an application break, and it simply isn't possible to test them all.
+
Security testing has proven itself as a key ingredient in any organization that needs to trust the software it produces.
 
+
However, security testing has the unique power to absolutely convince naysayers that there is a problem. Security testing has proven itself as a key ingredient in any organization attempting to produce secure software.
+
  
 
==Why OWASP?==
 
==Why OWASP?==
  
Creating a guide like this is a massive undertaking, representating decades of work.  
+
Creating a guide like this is a massive undertaking, representating decades of work by hundreds of people around the world. There are many different ways to test for security flaws and this guide captures the consensus of the leading experts on how to perform this testing quickly, accurately, and efficiently.
  
It's impossible to underestimate the importance of having this guide available in a completely free and open way. There are simply too many applications and too many lines of code for individual
+
It's impossible to underestimate the importance of having this guide available in a completely free and open way. Security should not be a black art that only a few can practice. Much of the available security guidance is only detailed enough to get people worried about a problem, without providing enough information to find, diagnose, and solve security problems. The project to build this guide keeps this expertise in the hands of the people who need it.
  
Security guidance is very susceptible to commercial pressures.
+
This guide must make its way into the hands of developers and software testers. There are not nearly enough application security experts in the world to make any significant dent in the overall problem. The initial responsibility for application security must fall on the shoulders of the developers. It shouldn't be a surprise that developers aren't producing secure code if they're not testing for it.
  
How the problem keeps evolving. Goal is to reduce the time lag
+
Keeping this information up to date is a critical aspect of this guide project. By adopting the wiki approach, the OWASP community can evolve and expand the information in this guide to keep pace with the fast moving application security threat.
 
+
We've set up the best system for keeping this up to date. Books, etc... are all ephemeral.  
+
  
 
==Tailoring and Prioritizing==
 
==Tailoring and Prioritizing==
  
Need to tailor to YOUR organization's technologies, processes, and organizational structure.
+
You should adopt this guide in your organization. You may need to tailor the information to match your organization's technologies, processes, and organizational structure. If you have standard security technologies, you should tailor your testing to ensure they are being used properly. There are several different roles that may use this guide.
  
The key is prioritizing. You have limited testing time and resources. Be sure you spend it wisely.
+
* Developers should use this guide to ensure that they are producing secure code. These tests should be a part of normal code and unit testing procedures.
  
==Use Automated Tools with Caution==
+
* Software testers should use this guide to expand the set of test cases they apply to applications. Catching these vulnerabilities early saves considerable time and effort later.
  
they're generic
+
* Security specialists should use this guide in combination with other techniques as one way to verify that no security holes have been missed in an application.
they're seductive
+
 
they can be a huge distraction
+
The most important thing to remember when performing security testing is to continuously reprioritize. There are an infinite number of possible ways that an application could fail, and you always have limited testing time and resources. Be sure you spend it wisely. Try to focus on the security holes that are the most likely to be discovered and exploited by an attacker, and that will lead to the most serious compromises.
 +
 
 +
This guide is best viewed as a set of techniques that you can use to find different types of security holes. But not all the techniques are equally important. Try to avoid using the guide as a checklist.
 +
 
 +
==The Role of Automated Tools==
 +
 
 +
There are a number of companies selling automated security analysis and testing tools. While they are improving and can assist, it's important to remember their limitations so that you can use them for what they're good at.
 +
 
 +
Most importantly, these tools are are generic - meaning that they are not designed for your custom code, but for applications in general. That means that while they can find some generic problems, they do not have enough knowledge of your application to allow them to detect most flaws. In my experience, the most serious security issues are generally the ones that are not generic, but deeply intertwined in your business and custom application design.
 +
 
 +
These tools can also be a seductive, since they do find lots of potential issues. While running the tools doesn't take much time, each one of the potential problems takes time to investigate and verify. If the goal is to find and eliminate the most serious flaws as quickly as possible, consider if your time is best spent with automated tools or with the techniques described in this guide.
 +
 
 +
Still, these tools are certainly part of a well-balanced application security program. Used wisely, they can support your overall processes to produce more secure code.
  
 
==Call to Action==
 
==Call to Action==
  
If you're building software, I strongly encourage you to get familiar with the security testing guidance in this document.
+
If you're building software, I strongly encourage you to get familiar with the security testing guidance in this document. If you find errors, please add a note to the discussion page or make the change yourself. You'll be helping thousands of others who use this guide.
  
Join us.
+
Please consider [[Membership|joining us]] as an individual or corporate member so that we can continue to produce materials like this testing guide and all the other great projects at OWASP.
  
__NOTOC__
+
Thank you to all the past and future contributors to this guide, your work will help to make applications worldwide more secure.
  
 +
-- [[User:Jeff Williams|Jeff Williams]], OWASP Chair, December 15, 2006
 +
 +
__NOTOC__
  
 
{{Category:OWASP Testing Project AoC}}
 
{{Category:OWASP Testing Project AoC}}

Revision as of 11:34, 15 December 2006

OWASP Testing Guide v2 Table of Contents

Contents


Forward by Jeff Williams, OWASP Chair

The problem of insecure software is perhaps the most important technical challenge of our time. Security is now the key limiting factor on what we are able to create with information technology. At OWASP, we're trying to make the world a place where insecure software is the anomoly, not the norm, and the OWASP Testing Guide is an important piece of the puzzle.

It goes without saying that you can't build a secure application without performing security testing on it. Yet many software development organizations do not include security testing as part of their standard software developement process.

Security testing, by itself, isn't a particularly good measure of how secure an application is, because there are an infinite number of ways that an attacker might be able to make an application break, and it simply isn't possible to test them all. However, security testing has the unique power to absolutely convince naysayers that there is a problem.

Security testing has proven itself as a key ingredient in any organization that needs to trust the software it produces.

Why OWASP?

Creating a guide like this is a massive undertaking, representating decades of work by hundreds of people around the world. There are many different ways to test for security flaws and this guide captures the consensus of the leading experts on how to perform this testing quickly, accurately, and efficiently.

It's impossible to underestimate the importance of having this guide available in a completely free and open way. Security should not be a black art that only a few can practice. Much of the available security guidance is only detailed enough to get people worried about a problem, without providing enough information to find, diagnose, and solve security problems. The project to build this guide keeps this expertise in the hands of the people who need it.

This guide must make its way into the hands of developers and software testers. There are not nearly enough application security experts in the world to make any significant dent in the overall problem. The initial responsibility for application security must fall on the shoulders of the developers. It shouldn't be a surprise that developers aren't producing secure code if they're not testing for it.

Keeping this information up to date is a critical aspect of this guide project. By adopting the wiki approach, the OWASP community can evolve and expand the information in this guide to keep pace with the fast moving application security threat.

Tailoring and Prioritizing

You should adopt this guide in your organization. You may need to tailor the information to match your organization's technologies, processes, and organizational structure. If you have standard security technologies, you should tailor your testing to ensure they are being used properly. There are several different roles that may use this guide.

  • Developers should use this guide to ensure that they are producing secure code. These tests should be a part of normal code and unit testing procedures.
  • Software testers should use this guide to expand the set of test cases they apply to applications. Catching these vulnerabilities early saves considerable time and effort later.
  • Security specialists should use this guide in combination with other techniques as one way to verify that no security holes have been missed in an application.

The most important thing to remember when performing security testing is to continuously reprioritize. There are an infinite number of possible ways that an application could fail, and you always have limited testing time and resources. Be sure you spend it wisely. Try to focus on the security holes that are the most likely to be discovered and exploited by an attacker, and that will lead to the most serious compromises.

This guide is best viewed as a set of techniques that you can use to find different types of security holes. But not all the techniques are equally important. Try to avoid using the guide as a checklist.

The Role of Automated Tools

There are a number of companies selling automated security analysis and testing tools. While they are improving and can assist, it's important to remember their limitations so that you can use them for what they're good at.

Most importantly, these tools are are generic - meaning that they are not designed for your custom code, but for applications in general. That means that while they can find some generic problems, they do not have enough knowledge of your application to allow them to detect most flaws. In my experience, the most serious security issues are generally the ones that are not generic, but deeply intertwined in your business and custom application design.

These tools can also be a seductive, since they do find lots of potential issues. While running the tools doesn't take much time, each one of the potential problems takes time to investigate and verify. If the goal is to find and eliminate the most serious flaws as quickly as possible, consider if your time is best spent with automated tools or with the techniques described in this guide.

Still, these tools are certainly part of a well-balanced application security program. Used wisely, they can support your overall processes to produce more secure code.

Call to Action

If you're building software, I strongly encourage you to get familiar with the security testing guidance in this document. If you find errors, please add a note to the discussion page or make the change yourself. You'll be helping thousands of others who use this guide.

Please consider joining us as an individual or corporate member so that we can continue to produce materials like this testing guide and all the other great projects at OWASP.

Thank you to all the past and future contributors to this guide, your work will help to make applications worldwide more secure.

-- Jeff Williams, OWASP Chair, December 15, 2006



OWASP Testing Guide v2

Here is the OWASP Testing Guide v2 Table of Contents