Difference between revisions of "Top 10-2017 What's Next for Security Testers"

Latest revision as of 12:15, 4 February 2018

Establish Continuous Application Security Testing

Building code securely is important. But it’s critical to verify that the security you intended to build is actually present, correctly implemented, and used everywhere it is supposed to be. The goal of application security testing is to provide this evidence. The work is difficult and complex, and modern high-speed development processes like Agile and DevOps have put extreme pressure on traditional approaches and tools. So we strongly encourage you to put some thought into how you are going to focus on what’s important across your entire application portfolio, and do it cost-effectively.
Modern risks move quickly, so the days of scanning or penetration testing an application for vulnerabilities once every year or so are long gone. Modern software development requires continuous application security testing across the entire software development lifecycle. Look to enhance existing development pipelines with security automation that doesn’t slow development. Whatever approach you choose, consider the annual cost to test, triage, remediate, retest, and redeploy a single application, multiplied by the size of your application portfolio.

Understand the Threat Model

Before you start testing, be sure you understand what’s important to spend time on. Priorities come from the threat model, so if you don’t have one, you need to create one before testing. Consider using OWASP ASVS and the OWASP Testing Guide as an input and don’t rely on tool vendors to decide what’s important for your business.

Understand Your SDLC

Your approach to application security testing must be highly compatible with the people, processes, and tools you use in your software development lifecycle (SDLC). Attempts to force extra steps, gates, and reviews are likely to cause friction, get bypassed, and struggle to scale. Look for natural opportunities to gather security information and feed it back into your process.

Testing Strategies

Choose the simplest, fastest, most accurate technique to verify each requirement. The OWASP Security Knowledge Framework and OWASP Application Security Verification Standard can be great sources of functional and nonfunctional security requirements in your unit and integration testing. Be sure to consider the human resources required to deal with false positives from the use of automated tooling as well as the serious dangers of false negatives.

Achieving Coverage and Accuracy

You don’t have to start out testing everything. Focus on what’s important and expand your verification program over time. That means expanding the set of security defenses and risks that are being automatically verified as well as expanding the set of applications and APIs being covered. The goal is to achieve a state where the essential security of all your applications and APIs is verified continuously.

Clearly Communicate Findings

No matter how good you are at testing, it won’t make any difference unless you communicate it effectively. Build trust by showing you understand how the application works. Describe clearly how it can be abused without “lingo” and include an attack scenario to make it real. Make a realistic estimation of how hard the vulnerability is to discover and exploit, and how bad that would be. Finally, deliver findings in the tools development teams are already using, not PDF files.

← What's Next for Developers

2017 Table of Contents

PDF version

What's Next for Organizations →

@@ Line 9: / Line 9: @@
 <!--- +T What's Next for Security Testers --->
 {{Top_10:SubsectionTableBeginTemplate|type=main}}{{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=freetext|position=firstWhole|title={{Top_10:LanguageFile|text=establishContinuousApplicationSecurityTesting |language=en}}|year=2017|language=en}}
-Building code securely is important. But it’s critical to verify that the security you intended to build is actually present, correctly implemented, and used everywhere it is supposed to be. The goal of application security testing is to provide this evidence. The work is difficult and complex, and modern high-speed development processes like Agile and DevOps have put extreme pressure on traditional approaches and tools. So we strongly encourage you to put some thought into how you are going to focus on what’s important across your entire application portfolio, and do it cost-effectively.
+Building code securely is important. But it’s critical to verify that the security you intended to build is actually present, correctly implemented, and used everywhere it is supposed to be. The goal of application security testing is to provide this evidence. The work is difficult and complex, and modern high-speed development processes like Agile and DevOps have put extreme pressure on traditional approaches and tools. So we strongly encourage you to put some thought into how you are going to focus on what’s important across your entire application portfolio, and do it cost-effectively.<br/>
 Modern risks move quickly, so the days of scanning or penetration testing an application for vulnerabilities once every year or so are long gone. Modern software development requires continuous application security testing across the entire software development lifecycle. Look to enhance existing development pipelines with security automation that doesn’t slow development. Whatever approach you choose, consider the annual cost to test, triage, remediate, retest, and redeploy a single application, multiplied by the size of your application portfolio.
 <br/ style="font-size:5px">
@@ Line 43: / Line 43: @@
 <!-- [[Category:OWASP Top Ten Project]] -->
-{{Top_10_2013:TopTemplate
-    |usenext=2013NextLink
-    |next={{Top_10:LanguageFile|text=whatsNextforOrganizations|language=en}}
-    |useprev=2013PrevLink
-    |prev={{Top_10:LanguageFile|text=whatsNextforDevelopers|language=en}}
-    |year=2017
-    |language=en
-}}
-{{Top_10:SubsectionTableBeginTemplate|type=main}} {{Top_10_2010:SubsectionAdvancedTemplate|type={{Top_10_2010:StyleTemplate}}|subsection=freetext|position=firstWhole|title={{Top_10:LanguageFile|text=establishContinuousApplicationSecurityTesting |language=en}}|year=2017}}
-Building code securely is important. But it’s critical to verify that the security you intended to build is actually present, correctly implemented, and used everywhere it was supposed to be. The goal of application security testing is to provide this evidence. The work is difficult and complex, and modern high-speed development processes like Agile and DevOps have put extreme pressure on traditional approaches and tools. So we strongly encourage you to put some thought into how you are going to focus on what’s important across your entire application portfolio, and do it cost-effectively.
-Modern risks move quickly, so the days of scanning or penetration testing an application for vulnerabilities once every year or so are long gone. Modern software development requires continuous application security testing across the entire software development lifecycle. Look to enhance existing development pipelines with security automation that doesn’t slow development. Whatever approach you choose, consider the annual cost to test, triage, remediate, retest, and redeploy a single application, multiplied by the size of your application portfolio.
-<br/ style="font-size:5px">
-{{Top_10:GradientBox|year=2017}}
-<b>Understand the Threat Model</b>
-:Before you start testing, be sure you understand what’s important to spend time on. Priorities come from the threat model, so if you don’t have one, you need to create one before testing. Consider using <u>[[ASVS|OWASP ASVS]]</u> and the <u>[[OWASP_Testing_Project|OWASP Testing Guide]]</u> as an input and don’t rely on tool vendors to decide what’s important for your business.
-{{Top 10:GrayBoxEnd|year=2017}}
-{{Top_10:GradientBox|year=2017}}
-<b>Understand Your SDLC</b>
-:Your approach to application security testing must be highly compatible with the people, processes, and tools you use in your software development lifecycle (SDLC). Attempts to force extra steps, gates, and reviews are likely to cause friction, get bypassed, and struggle to scale. Look for natural opportunities to gather security information and feed it back into your process.
-{{Top 10:GrayBoxEnd|year=2017}}
-{{Top_10:GradientBox|year=2017}}
-<b>Testing Strategies</b>
-:Choose the simplest, fastest, most accurate technique to verify each requirement. The <u>[[Benchmark|OWASP Benchmark Project]]</u>, which helps measure the ability of security tools to detect many OWASP Top 10 risks, may be helpful in selecting the best tools for your specific needs. Be sure to consider the human resources required to deal with false positives as well as the serious dangers of false negatives.
-{{Top 10:GrayBoxEnd|year=2017}}
-{{Top_10:GradientBox|year=2017}}
-<b>Achieving Coverage and Accuracy</b>
-:You don’t have to start out testing everything. Focus on what’s important and expand your verification program over time. That means expanding the set of security defenses and risks that are being automatically verified, as well as expanding the set of applications and APIs being covered. The goal is to get to where the essential security of all your applications and APIs is verified continuously.
-{{Top 10:GrayBoxEnd|year=2017}}
-{{Top_10:GradientBox|year=2017}}
-<b>Make Findings Awesome</b>
-:No matter how good you are at testing, it won’t make any difference unless you communicate it effectively. Build trust by showing you understand how the application works. Describe clearly how it can be abused without “lingo” and include an attack scenario to make it real. Make a realistic estimation of how hard the vulnerability is to discover and exploit, and how bad that would be. Finally, deliver findings in the tools development teams are already using, not PDF files.
-{{Top 10:GrayBoxEnd|year=2017}}
-{{Top_10:SubsectionTableEndTemplate}}
-{{Top_10_2013:BottomTemplate
-    |usenext=2013NextLink
-    |next={{Top_10:LanguageFile|text=whatsNextforOrganizations|language=en}}
-    |useprev=2013PrevLink
-    |prev={{Top_10:LanguageFile|text=whatsNextforDevelopers|language=en}}
-    |year=2017
-    |language=en
-}}

Difference between revisions of "Top 10-2017 What's Next for Security Testers"

Latest revision as of 12:15, 4 February 2018

Navigation menu

Personal tools

Namespaces

Variants

Views

More

Search

Navigation

Reference

Tools