Pentesting is an essential process to achieve good application security. There are many security experts that see it as the most important part of the security chain. But it has to be done often enough and it has to be done in the right way. And this is the crux, in my experience, the vast majority of current enterprise pentests and application security processes have severe shortcomings. Frequently to a point that they are not worth the money you spent on them.
Too often valuable pentester’s time is wasted on mundane tasks to “tick a box” in a compliance sheet. From a technical perspective, the tests are suboptimal and will find only the simplest vulnerabilities leaving many unpleasant surprises hidden in the code for attackers to exploit. Things like too short timeboxes, focusing exclusively on black-box testing, not measuring test code or end-point coverage are very common problems I see.
Obviously, there might be rational business reasons for this, like budget or time restrictions. However, we have seen many times that these constraints come back to bite us later. There are new concepts emerging that make security tests quicker, more affordable, and more effective. So let's not just rant about the current situation. Let's focus instead on how modern application security testing approaches allow you to introduce more sophisticated testing in your own team. So here are my 5 tips on how to do more cost-effective and powerful application security pen-testing.
1. Stop Using Pentesting to Cover Your Ass
“No one ever got fired for ordering a penetration test” - Many security managers live by this principle. Unfortunately, there are some who don’t see this as something valuable to actually make their software more secure. Instead, they shift the blame to the pentester if something goes wrong. By letting others perform a pentest, managers can always point out the fact that they did a pentest, even if the pentest simply consists of running a standard tool like the burp suite. Of course, from a technical perspective, it is clear that this kind of test has no chance of finding all vulnerabilities.
Even if we assume that in such cases the external pentesters do the very best they can, they have two major disadvantages: (1) Due to missing domain knowledge, they might miss some interfaces or edge cases compromising the security of the entire system [usually not everything is well documented). (2) Findings often lead to enormous follow-up work on the developer’s side and thus are unpopular and time and cost-intensive. The older a vulnerability is the more expensive it is to fix it. The obvious answer to this is to find as many vulnerabilities as possible and also do this as early as you can. And there are several ways to enable this.
2. White-Box Testing: Always a Step Ahead of the Attacker
The majority of the pentests on application security are performed as black-box scans where pentesters simply get access to a web application and try to break it from outside. Product security managers often only receive permission to perform source code reviews after these black-box tests, which in my view is the wrong way round.
So the majority of projects are only tested as black-boxes, without the source code. The argument being that this is the same view as an attacker would have. But why should the defenders tie their hands behind their back? Or maybe blindfold themselves, when they could be much more effective by testing with the full source code? White-box testing methods give you a significant advantage over the attackers (see this blog article showing how source code helps here).
3. Measure and Maximize Code Coverage
In various “enterprise” pentests neither endpoint nor code coverage is measured. The activation of code coverage measurement typically reveals that less than half of the code is covered with those scans. So not only do these black-box tests find fewer issues in the code they do actually manage to scan. Also, they don’t even look at the majority of the code at all!
In all projects I have been involved in - without exception -, a simple look at the code that was not covered always revealed critical vulnerabilities missing in the previous reports. When talking to pentesters about this, I always get the same reply: “Management decided not to include source code reviews, and I only had X days to perform the test.” So this really isn’t the pentesters fault, it is the tools and time they are given.
Black-box pentesting is only half of the battle. But fortunately, you can actually make your code more secure with less effort, by using white-box testing approaches that are optimized for code coverage. By using dynamic code analysis tools based on instrumentation, you could easily improve your code coverage. Even better, modern instrumented fuzzing frameworks not only allow you to measure code coverage but also increase it based on the feedback when running the application (see feedback-based fuzzing).
4. Let Developers Cover More Security Testing!
One of my customers recently told me about the disappointing results of a project he outsourced to external pentesters since they didn’t find much. Although they charged him a substantial sum for it and the bugs they were supposed to find were both common and simple to find. I was curious and had a look myself.
I decided to run OWASP Zap on the software via our Code Intelligence integration. The results were as one might expect: I basically found the exact same issues that my customer paid for within minutes. The difference was that I was working with the source code. To make things worse, I just took the default options, which took me only 2 minutes to set up. So it really required no work or expertise with the right tooling.
Seeing that some code wasn’t covered has shown me that some controllers couldn’t be covered due to some specific HMAC settings for CSRF protection. It only required about 30 more minutes by our customer success team to increase the code coverage. With this, we found new critical XSS vulnerabilities which have been overseen in the pentest.
Why spend all this money on external pentests to find common bugs when it’s far more efficient to incorporate testing tools that will enable your developers to scan the code themselves. This has so many advantages! Developers know their own code and with the right tools, they can be informed of bugs with little to no effort. And if by finding the bugs right away, fixing them becomes very simple and cost-effective.
Developers don’t have to get reacquainted with the code they wrote months ago. The code hasn’t been deployed and time of code reviewers has not been wasted. The added benefit is that pentesters can now focus on more complex problems developers might have missed due to limited pentesting
5. Make Effective Dynamic Application Security Testing Part of Your Development Process
Even though everyone speaks about DevSecOps nowadays, only Static Application Security Testing (SAST) and Static Code Analysis (SCA) are already part of most development processes.
There is some discussion on how useful static analysis is, but there is no question that it can’t replace real security testing. Enterprise pentests may often be imperfect, but they clearly demonstrate that SAST and SCA alone are insufficient (Not to speak of the many vulnerabilities found by attackers). These tools not only produce countless false positives but also miss critical vulnerabilities.
In my opinion, the main reasons that dynamic testing is not more widely used, are the limitations of most established Dynamic Application Security Tests (DAST) and Interactive Application Security Testing Tools (IAST). They are not geared towards developer's needs and user-friendliness.
Developers need to be enabled to conduct dynamic security testing themselves, and it has to be integrated into the development process. Everybody wins.
What The Future Might Bring
In my experience, individuals responsible for application security often become defensive when hearing that a lot of the pentests they pay for could be automated. Some of my suggestions might also sound a little harsh on “enterprise” pentests. But I’m not saying that in the future we won’t need pentesting, and everything will be covered with good tooling and processes. I’m only saying that we should rethink the role of pentesting in application security.
I am convinced that most of the performed “enterprise” pentests right now will be automated in the development process. This will enable developers to write more secure code with less effort. This will free up resources and allow pentesters to focus on things that cannot be automated with modern fuzzing and other dynamic techniques.
To find out how you can run automated security tests and achieve maximum code coverage without false positives, book a demo with one of our security experts. We will walk you through the process and answer your questions.
