By: Chua Bo Si, Technical Program Manager at HackerOne
Applications have become the lifeblood of businesses in today’s connected world. Software is now the “front door” into your business for many people around the world. This helps companies to reach wider audiences and gives them the chance to grow their business quickly wherever their headquarters are.
Caution is required, though. Applications exposed to the internet are also exposed to shady characters out to exploit your systems for their benefit, often at the expense of your customers and your business. You can do your best to protect your systems, but application vulnerabilities are not going away anytime soon.
Since software is the front line for your business, an effective application security testing strategy is a must. In this article, we’ll discuss 5 things businesses may overlook when designing their application security testing strategy. From threat modeling to metrics, we’ve got all the tips you need to make your application
security testing program a leader among your peers. Let’s dive in.
1. Inform and Shape Your Security Testing with Threat Modeling
Threat modeling doesn’t always get the attention it deserves when application security programs are taught or discussed. However, threat modeling can do wonders to inform and shape your security testing program so you don’t waste money and time testing what doesn’t need to be tested.
Threat modeling is the process of reviewing the design of an application to find potential security issues and weaknesses that may lead to exploitation. Threat models give the development and testing teams a high-level overview of where and how things could go wrong.
Start by reviewing high-level diagrams of the application. If it’s a new app, use a conceptual design. If it’s an existing app, take the time to review all of the pieces of the app with the development team and make an up-to-date diagram. It helps to concentrate on the flow of data through your application. Make diagrams based on where data comes from and where it goes, mapping all of the pieces it flows through on the way. You’ll find that data is the lifeblood of the application and touches every piece.
Once your diagram is created, you’ll be able to review it for possible trouble areas. For example, you may see a place where encryption is not used properly or find a publicly exposed API that could be a juicy target.
When you have a good threat model, the testing team can use this information to test the most valuable and highest risk pieces of the application. If your public API is identified as an area attackers may want to poke at, then your testers should focus on breaking the API or making it do things it’s not supposed to do. Find the pieces of your application that are most exposed to attack and test those thoroughly.
If you’re new to threat modeling, check out this guide on what, where, and how to do it.
2. Automate with a Grain of Salt
A successful DevSecOps program could not be possible with automation. New tools have emerged, giving dev and IT teams the ability to create and destroy servers and deploy entire applications in minutes with the push of a button.
Application security can also be automated to a large extent. Automated scanning tools can scan source code or even launch attacks against running systems to find vulnerabilities before the code reaches production.
Another way to automate is through security-focused unit tests. Many automated unit tests focus on functionality instead of security. When security is included in your unit testing, it gives an extra foundation of security without the added overhead of expensive testing tools. Security-focused unit tests can cover the “low-hanging fruit” of security for each piece of code.
Many types of vulnerabilities and exploits cannot be tested for using simple unit tests. More advanced scenarios can be automated by tools which can attack running applications, such as Burp or OWASP’s Zed Attack Proxy.
While automation can save loads of time and find good security bugs, there is a limit to what automated tools can provide. There are several different kinds of tools, each good at finding certain types of vulnerabilities. For example, static analysis can help find simple bugs related to coding best practices. However, static analysis tools are also the source of many false positives, which are more expensive to handle if they keep popping up. Other testing tools depend on a large set of automated functional tests. If you don’t have these tests, using these tools will be difficult.
Automation is a necessary piece of a successful application security testing program. But don’t forget some of the pitfalls and cause more problems than you solve.
3. Invest in Manual Testing
Even though automation is important in DevSecOps, manual testing is still a necessary step. Humans still find many bugs that automated tools simply cannot. Automated tools can’t be creative like humans and thus they’ll find only basic vulnerabilities. For example, many authentication and authorisation bugs cannot be found with scanning tools. Only real people can examine the many pieces and determine if exploitation is possible.
Manual penetration testing should be a regular part of your workflow. Even though DevSecOps focuses on quick delivery, you might as well not bother if you’re only delivering “swiss cheese” software that’s full of obvious holes attackers can exploit.
One effective way of using real humans to manually test your software on an ongoing basis is with hacker-powered security. A bug bounty allows your DevSecOps workflow to continue while hackers are working around the clock to help find security issues in your software.
4. Vulnerability Management is Essential
Vulnerability management is the process used to examine a vulnerability, determine the damage it could cause if exploited, and estimate the cost to fix it. Once these factors are determined, vulnerabilities can be fixed in order of priority.
Strong vulnerability management is essential to an application security testing strategy. If nothing is done to prioritise and fix vulnerabilities found through testing, then why bother finding them? The vulnerabilities are not eliminated when they’re found, but when they’re fixed.
Advice on effective vulnerability management can fill a book, but here are some quick tips to help you get started:
• Document your vulnerability ratings (high, medium, low) and create SLAs to fix each rating.
• Invest in good vulnerability management software to keep your process organized.
• Document communication procedures (who to contact and when).
• Hold development teams accountable for fixing prioritized vulnerabilities.
• Periodically review vulnerabilities to see if your testing efforts are working to reduce the number of new vulnerabilities.
If you’re using hacker-powered security, a vulnerability disclosure policy, or VDP, is a good first step in a vulnerability management workflow. This helpful guide explains what a VDP is, why you need one, and how to get started. A good VDP gives external hackers an explicit method for contacting you with their findings and explains what information you’d like them to provide. This ensures consistency between internal and external testers of your software.
When your testing efforts begin to pay off, a mature vulnerability management process will ensure those vulnerabilities get fixed in a timely fashion.
5. Develop Metrics
Ultimately, improvement is the whole point of testing software. You want to find fewer bugs over time and you want the ones that are found to be found, and fixed, faster over time. Good metrics are the key to improving your program over time.
You can’t improve without measuring what you have. However, you need to measure the right things or you may end up fixing the wrong things. Here are some of the key metrics your application security testing strategy should feature:
• Mean Time to Detection – How long does it take to discover vulnerabilities in your software?
• Mean Time to Resolve – How long does it take to fix the vulnerabilities you discover?
• Asset coverage – What assets do you have? How many are covered thoroughly through automated and manual testing processes?
• Number of high/critical vulnerabilities open – How many major vulnerabilities are currently not fixed? This metric can be grouped based on business unit or application to discover possible areas of focus.
• Vulnerability acceptance – How many vulnerabilities are not being fixed and why? This number should be as low as possible and should be revisited often (at least once per year) to make sure the vulnerability still can’t be fixed.
Metrics will become the guiding light for upper management and executives. Choose metrics that give a complete picture of the risk from vulnerabilities your organisation is currently managing. Use the metrics to tell a story of how your team is tackling application security testing and remediation efforts.
Protect Your Front Lines
Constantly reacting to what happens day-to-day will not lead to more secure software. A strategic eye is necessary to create an application security program that will keep your software safe while not interrupting a DevSecOps workflow.
Keep in mind the necessary pieces of a strategic application security testing program. Threat model your applications, add automation where appropriate, make room for manual testing, effectively manage your vulnerabilities, measure your success. Protect the front lines of your organisation with an effective application security testing strategy.
Hacker-powered security can play a key role in keeping your software safe in the “go, go, go” environment of DevSecOps. Check out our guide on how to incorporate hacker-powered security into your DevSecOps workflow to see how you can most effectively protect your software from attackers