As the IT industry’s focus on security has increased, so has the number of options for testing your website’s security. The number of vendors has exploded, too.
Have you ever had paralysis by analysis when staring at all of your options? You’re not alone.
So let’s take a look at all of your options for making sure your website doesn’t have significant security flaws that lead to data breaches. We’ll outline the pros and cons of each and where they fit into your website development process.
SAST uses static analysis to find security flaws in your code before it has been built and deployed to a testing environment.
SAST is an automated code review. SAST tools pull code files from your repository and analyze the code for pre-configured patterns that indicate the potential existence of security flaws.
The advantages of SAST include its speed and the ease of integration with Continuous Integration (CI) tools. SAST tools are easy to automate, lending themselves to a “set it and forget it” style of operation. Time is only required for the initial tool configuration, freeing you up to concentrate on analyzing and remediating the results.
CI tools like Jenkins can be set to kick off a SAST tool after every code commit. Another option is to run a static analysis every night, sending a report in the morning on any problems discovered.
False positives are the biggest drawback of SAST tools. They don’t try to exploit flaws to determine their impact. They find suspicious code and warn you about it.
The static model works well with well-known vulnerabilities, like SQL injection. You can quickly tell by looking at code whether or not a developer used parameterized queries. However, without traversing all of the execution paths, a small piece of code which on the surface may not seem vulnerable, might be a threat when the application is executing. SAST helps discover these potential vulnerabilities.
Use SAST tools as the first layer of defense. It’s great for finding “low-hanging fruit” code problems quickly, but it has limitations. Don’t use only SAST, but use it in conjunction with other methods, which we’ll discuss next.
Dynamic testing goes one step further than static testing. Static analysis reads your code and finds possible problems. Dynamic analysis attacks your running application to find exploitable vulnerabilities.
The most significant difference between static and dynamic analysis is where in the development process they are used. The static analysis runs before you compile the code, while dynamic testing works after the application is built and deployed to a testing environment.
Many DAST tools, such as Burp Suite or OWASP Zed Attack Proxy, can be operated manually by a human tester or be automated as part of a continuous integration pipeline. ZAP’s powerful scripting engine gives security experts the ability to write custom attack scripts and run them from the command line.
Dynamic testing finds bugs by actively attacking an application. For best results, use DAST tools in a testing environment with realistic amounts of data. You can find more complex security flaws than those seen with static testing.
One downside to dynamic testing is speed. It takes much longer to complete a full security scan on a running application than performing a static analysis on source code.
The biggest downside to DAST can be the number of false positives, and the difficulty pinning down the reason for the false positive. DAST tools could report a flaw in your application because it was able to coax a particular output from it. It can take time to nail down the source of the issue, taking time away from other vital tasks.
DAST tools are potent in the hands of skilled penetration testers. However, the difficulty of automating them in a CI pipeline and tracking down the source of the issues they find can be too resource-intensive for some businesses.
However, for those companies, there is a newer security testing tool that can replace DAST tools and provide better results.
SAST tests the application from the inside out, looking at the source for vulnerabilities. DAST tries to find vulnerabilities from the outside, but has no visibility into the inner workings of the application.
IAST is a best-of-both-worlds hybrid of both SAST and DAST. It tests the application externally with the ability to pinpoint where in the code the problem lies. Some IAST tools perform automated attacks on the fly in a sandbox to verify whether the vulnerability is exploitable.
IAST tools are more easily integrated into your SecDevOps pipeline. If you’re using SecDevOps, IAST is your best bet to smooth application security testing, both in ease of integration and developer use.
IAST tools also increase the accuracy of results. They work by installing agents that run within the runtime of the application and on specific servers in your environment. This instrumentation allows it to pinpoint where problems are happening as the code executes. You’ll know a vulnerability is exploitable, and where and how to fix it.
Many IAST tools depend on automated functional tests to perform their best work. IAST is built to run inside of a testing environment (RASP, or Runtime Application Self-Protection, is made for production). Therefore, if your application doesn’t have a robust suite of automated test cases, IAST tools will be of limited use. They use automated tests to exercise the application to find vulnerabilities.
If your development workflow is mature, with SecDevOps and automated testing well in hand, IAST is an excellent way to integrate application security analysis into your pipeline.
We’re now moving into the manual testing techniques you can use to find security flaws. Manual testing is still necessary because humans are better than machines at testing for particular bugs. For example, human testers are far better at finding business logic errors and poor authentication practices.
Penetration testing is typically done with a set time table and with an agreed-upon scope. The testers will try to break into a hardened application after automated tests have found the “easy-to-find” vulnerabilities.
Third-party consultants are typically engaged to perform penetration testing, which means the cost could be high. Also, the quality of the bugs found depends on the skill of the testers. Let the buyer beware.
A recent trend crowdsources penetration testing to help reduce the cost and increase the quality of the results.
The first step is to create a vulnerability disclosure policy (VDP). The VDP outlines which assets are open to bug bounty testing and how to accurately report vulnerabilities to your program. It should also include a safe harbor clause stating that you won’t prosecute hackers if they follow the VDP guidelines.
The most straightforward setup is a simple email, such as security@yoursite.com. Hackers who find bugs can send the reports here for your team to triage and try to replicate. Maintaining excellent communication with hackers will ensure that the best and brightest stick with your program over time.
The biggest question you may be wondering is, how much should I pay for bugs? Bounty values are dependent on the value you place on each risk level. Whatever amounts you decide, set aside a budget for bug bounties and communicate via your VDP what amounts hackers should expect for low, medium, and high vulnerabilities.
Prizes don’t have to be money. Sometimes a bit of swag and a shoutout on Twitter are enough. But you should be prepared to pay cash as your program matures.
Bug bounties save you money because you’re paying for performance. The amount paid out directly correlates to the value the hacker brings in. If a hacker finds a bug that, if exploited, would have cost millions, then paying $10,000 is more than worth it.
Running a bug bounty program by yourself is possible, but costly and challenging. If you’re serious about incorporating bug bounties into your application security strategy, look at bug bounty platforms like HackerOne or Bugcrowd. They make the process much more comfortable and have tools built for bug bounties.
We’ve created a diagram below of how all of these pieces fit into your Secure SDLC (S-SDLC). Results vary, so experiment with different options and find what works for you. For example, you may decide to replace your SAST and DAST tools with a single IAST tool. It’s up to you.
Security testing will continue to grow in importance as more sophisticated attacks surface. Building these testing strategies into your S-SDLC will help to keep your site safe from attack.
If you need help deciding how all of these tools fit into your environment, contact us, and we’ll be glad to help.