Difference between revisions of "Getting Started"

From OWASP
Jump to: navigation, search
(About Vulnerabilities)
Line 7: Line 7:
 
Drivers, market, business reasons. Links to articles about metrics, ROI, need for application security, what other companies are doing.
 
Drivers, market, business reasons. Links to articles about metrics, ROI, need for application security, what other companies are doing.
  
==Where to Start==
+
==Where Should I Start?==
  
 
If you're wondering whether your software really has application security weaknesses, then the best thing to do is to find out. You can do this in a number of ways, but the simplest is to have a few of your applications [[verified]]. The reviewer should check all the major security areas by using a combination of scanning, code review, penetration testing, and static analysis.  Chances are pretty good that you'll find some vulnerabilities and then you can make an informed decision about how to proceed.
 
If you're wondering whether your software really has application security weaknesses, then the best thing to do is to find out. You can do this in a number of ways, but the simplest is to have a few of your applications [[verified]]. The reviewer should check all the major security areas by using a combination of scanning, code review, penetration testing, and static analysis.  Chances are pretty good that you'll find some vulnerabilities and then you can make an informed decision about how to proceed.
Line 13: Line 13:
 
If you've already come to the conclusion that your project or organization is not producing secure code, then you should consider what organizational improvements are most likely to improve your ability. One popular place to start is developer training, as it is relatively inexpensive and has immediate effects. However, you may want to consider doing an appraisal of your organization to find out what changes are likely to e the most effective. Also, you might consider defining a risk model, creating organization roles and teams, establishing standards or coding guidelines, or introducing some security activities into your software development lifecycle before doing the training.
 
If you've already come to the conclusion that your project or organization is not producing secure code, then you should consider what organizational improvements are most likely to improve your ability. One popular place to start is developer training, as it is relatively inexpensive and has immediate effects. However, you may want to consider doing an appraisal of your organization to find out what changes are likely to e the most effective. Also, you might consider defining a risk model, creating organization roles and teams, establishing standards or coding guidelines, or introducing some security activities into your software development lifecycle before doing the training.
  
==About Vulnerabilities==
+
==About Threats, Vulnerabilities, and Countermeasures==
  
A good way to start learning about application security is by understanding software vulnerabilities. A good overview of the most critical application vulnerabilities is the OWASP [[OWASP_Top_Ten_Project|Top Ten]] awareness document. This is a short paper that describes the most critical vulnerabilities, how to find them, and what to do to protect against them in your application.
+
A good way to start learning about application security is by understanding software threats, vulnerabilities, and countermeasures. A good overview of the most critical of these is the OWASP [[OWASP_Top_Ten_Project|Top Ten]] awareness document. This is a short paper that describes the most critical vulnerabilities, how to find them, and what to do to protect against them in your application.
  
One of the best ways to learn about vulnerabilities is to study some real vulnerabilities and learn how they work. OWASP has developed [[OWASP_WebGoat_Project|WebGoat]] to provide hands-on examples of application vulnerabilities to learn from. WebGoat is a full J2EE application and training environment that contains real vulnerabilities to experiment with and learn from. You can read all about each of the [[:Category:Vulnerability|vulnerabilities]] on the OWASP website to learn more.
+
One of the best ways to learn about application security is to study some real vulnerabilities and learn how they work. OWASP has developed [[OWASP_WebGoat_Project|WebGoat]] to provide hands-on examples of application security to learn from. WebGoat is a full J2EE application and training environment that contains real vulnerabilities to experiment with and learn from. [[OWASP_WebScarab_Project|WebScarab]] is a powerful web application penetration testing tool that can use to test applications. For further reference, you can read all about each of the [[:Category:Vulnerability|vulnerabilities]] on the OWASP website to learn more.
  
Keep in mind as you learn that there are different ways of organizing vulnerabilities. Attempts to force vulnerabilities into a strict taxonomy mostly fail, because there are so many dimensions to each vulnerability. At OWASP, we have adopted the "folksonomy" tagging approach, and simply tag vulnerabilities with labels that make sense. You can use these tags to help get different views into all the different types of vulnerabilities.
+
Keep in mind as you learn that there are different ways of organizing threats, vulnerabilities, and countermeasures. [[Attempts]] to force these topics into a strict taxonomy have failed because there are too many dimensions to the problem. At OWASP, we have adopted the [[folksonomy]] tagging approach to solving this problem. We simply tag articles about threats, vulnerabilities, and countermeasures with a number of different categories. You can use these category to help get different views into the complex, interconnected set of topics that is application security.
  
Some of the key attributes of a vulnerability are:
+
Each article is tagged with the following tags:
 +
* Whether it is a threat, vulnerability, or countermeasure
 
* The level of abstraction of the description (e.g. [[:Category:Implementation Bug|Implementation Bug]], [[:Category:Design Flaw]], [[:Category:Business Problem]])
 
* The level of abstraction of the description (e.g. [[:Category:Implementation Bug|Implementation Bug]], [[:Category:Design Flaw]], [[:Category:Business Problem]])
 
* The associated [[:Category:Countermeasure|security mechanism]] (e.g. [[:Category:Authentication]], [[:Category:Access Control]], [[:Category:Input Validation]], [[:Category:Error Handling]], [[:Category:Logging]], [[:Category:Encryption]], etc...)
 
* The associated [[:Category:Countermeasure|security mechanism]] (e.g. [[:Category:Authentication]], [[:Category:Access Control]], [[:Category:Input Validation]], [[:Category:Error Handling]], [[:Category:Logging]], [[:Category:Encryption]], etc...)
Line 27: Line 28:
 
* The factors indicating likelihood of an exploit (e.g. [[:Category:Attractiveness]], [[:Category:Expertise Required]], etc...)
 
* The factors indicating likelihood of an exploit (e.g. [[:Category:Attractiveness]], [[:Category:Expertise Required]], etc...)
 
* others?
 
* others?
 +
 +
==Do You Have Vulnerabilities in Your Applications?==
  
 
A writeup about application vulnerabilities, how to find them,  and how to figure out their risk. This section would give people the background on the technologies and types of mistakes people make. Links to articles about:
 
A writeup about application vulnerabilities, how to find them,  and how to figure out their risk. This section would give people the background on the technologies and types of mistakes people make. Links to articles about:
Line 33: Line 36:
 
   Common areas (Top 10)
 
   Common areas (Top 10)
  
==Root Causes of Vulnerabilities==
+
==What Are the Root Causes of Application Vulnerabilities?==
  
 
A writeup of how vulnerabilities get created and left undiscovered. This section points out weaknesses in most software development lifecycles.  At a project level, this section talks about problems in staffing, roles, responsibilities, budget, and technology.  At the organizational level, this section links to information about management structure, how to raise global organizataion awareness, establishing metrics, and standardizing technologies to help.
 
A writeup of how vulnerabilities get created and left undiscovered. This section points out weaknesses in most software development lifecycles.  At a project level, this section talks about problems in staffing, roles, responsibilities, budget, and technology.  At the organizational level, this section links to information about management structure, how to raise global organizataion awareness, establishing metrics, and standardizing technologies to help.

Revision as of 15:06, 1 April 2006

Getting Started in Application Security

Application security is simply the process of developing, maintaining, and purchasing applications that your organization can trust. However, application security is inextricably tied into almost every aspect of organizations' information technology, and can be maddeningly difficult to tackle. This "Getting Started" page is intended to provide a roadmap of the various topics in application security and where OWASP materials can help you and your organization master them.

Contents

Application Security Overview

Drivers, market, business reasons. Links to articles about metrics, ROI, need for application security, what other companies are doing.

Where Should I Start?

If you're wondering whether your software really has application security weaknesses, then the best thing to do is to find out. You can do this in a number of ways, but the simplest is to have a few of your applications verified. The reviewer should check all the major security areas by using a combination of scanning, code review, penetration testing, and static analysis. Chances are pretty good that you'll find some vulnerabilities and then you can make an informed decision about how to proceed.

If you've already come to the conclusion that your project or organization is not producing secure code, then you should consider what organizational improvements are most likely to improve your ability. One popular place to start is developer training, as it is relatively inexpensive and has immediate effects. However, you may want to consider doing an appraisal of your organization to find out what changes are likely to e the most effective. Also, you might consider defining a risk model, creating organization roles and teams, establishing standards or coding guidelines, or introducing some security activities into your software development lifecycle before doing the training.

About Threats, Vulnerabilities, and Countermeasures

A good way to start learning about application security is by understanding software threats, vulnerabilities, and countermeasures. A good overview of the most critical of these is the OWASP Top Ten awareness document. This is a short paper that describes the most critical vulnerabilities, how to find them, and what to do to protect against them in your application.

One of the best ways to learn about application security is to study some real vulnerabilities and learn how they work. OWASP has developed WebGoat to provide hands-on examples of application security to learn from. WebGoat is a full J2EE application and training environment that contains real vulnerabilities to experiment with and learn from. WebScarab is a powerful web application penetration testing tool that can use to test applications. For further reference, you can read all about each of the vulnerabilities on the OWASP website to learn more.

Keep in mind as you learn that there are different ways of organizing threats, vulnerabilities, and countermeasures. Attempts to force these topics into a strict taxonomy have failed because there are too many dimensions to the problem. At OWASP, we have adopted the folksonomy tagging approach to solving this problem. We simply tag articles about threats, vulnerabilities, and countermeasures with a number of different categories. You can use these category to help get different views into the complex, interconnected set of topics that is application security.

Each article is tagged with the following tags:

Do You Have Vulnerabilities in Your Applications?

A writeup about application vulnerabilities, how to find them, and how to figure out their risk. This section would give people the background on the technologies and types of mistakes people make. Links to articles about:

 Design flaws and Implementation Bugs
 Approaches to finding vulnerabilities
 Common areas (Top 10)

What Are the Root Causes of Application Vulnerabilities?

A writeup of how vulnerabilities get created and left undiscovered. This section points out weaknesses in most software development lifecycles. At a project level, this section talks about problems in staffing, roles, responsibilities, budget, and technology. At the organizational level, this section links to information about management structure, how to raise global organizataion awareness, establishing metrics, and standardizing technologies to help.

Improving Application Security In Your Project

A writeup of how application security fits into the software development lifecycle. The discussion would link to templates, tools, additional reading. (This is not intended to be a complete list (yet))

 Security Requirements
 Threat Modeling
 Architecture Review
 Code Review
 Penetration Testing
 Vulnerability Scanning
 Project Responsibility and Roles
 Budget

Improving Application Security Across Your Organization

The discussion would link to templates, tools, additional reading. (This is not intended to be a complete list (yet))

 Training and Awareness
 Application Security Teams (Infosec, Audit, Appsec, CSO)
 Metrics
 Policies
 Templates
 Standard Tools
 Legal
 Community of Interest
 Executive Responsibility and Roles
 Organizational Budget