If software is the front line of your business, you probably have not overlooked any of these effective App Security strategy processes, right?
In today’s connected world, applications have become the lifeblood of businesses. Software is now the “front door” for many people around the world through which to enter into your business. This helps companies to reach wider audiences and gives them the chance to grow their business quickly wherever their headquarters are.
Caution is required, however. 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 of your business, an effective application security testing strategy is a must. Here are we’ll five things businesses may overlook when designing their application security testing strategy, from threat-modeling to metrics:
- Inform and Shape Your Security Testing with Threat Modeling
Threat modeling does not always get the attention it deserves when application security programs are taught or discussed. However, such modeling can do wonders to inform and shape your security testing program so you do not waste money and time testing what does not 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 is a new app, use a conceptual design. If it is 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 will find that data is the lifeblood of the application and touches every piece.
Once your diagram is created, you will 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 is not supposed to do. Find the pieces of your application that are most exposed to attack and test those thoroughly. - Automate with a grain of salt
A successful Development, Security and Operations (DevSecOps) program could not be possible without 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.
To a large extent, application security can also be automated. 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 probed 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 do not have these tests, using these tools will be difficult.
Automation is a necessary piece of a successful application security testing program. But bear in mind some of the pitfalls so that they do not cause more problems than you solve. - 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 cannot be creative like humans and thus they will find only basic vulnerabilities. For example, many authentication and authorization 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 are only delivering ‘swiss cheese’ software that is 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. - 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 prioritize and fix vulnerabilities found through testing, then why bother finding them? The vulnerabilities are not eliminated when they are found, but when they are 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 are 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. - 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 cannot 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 cannot 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 organization 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 organization with an effective application security testing strategy.
