What is it and why should I care?
Penetration testing is a process of evaluating the security of a computer system or network by simulating an attack. The process involves an active analysis of the system for any potential vulnerabilities, is carried out from the position of a potential attacker and can involve active exploitation of security vulnerabilities. This is sometimes referred to as pen-testing or ethical hacking.
This means that you actually are probing the live system (usually in Dev, QA, or UAT) and trying to find (and sometimes exploit) actual vulnerabilities. There is tremendous value and power in being able to show not only that a vulnerability exists, but that it is directly exploitable. In my experience, it also opens up an honest dialog between development and security if you can show that something actually is exploitable, and approach it with the goal of getting it resolved together. There’s no more conversation about false positives at that point :>.
What should I do about it?
Just as you should do code reviews in addition to using static analysis, you should perform penetration testing in addition to dynamic analysis. Static and dynamic analysis give you the ability to point software at your applications and get back results (often good). However, there is a limit to the amount of analysis that current products (or even theory, for that matter) can provide.
So, that leaves us with supplementing our tools with humans (the common refrain in most security efforts). By adding code review to supplement static analysis, we’re able to find specific instances of vulnerabilities, and even whole classes of vulnerabilities we wouldn’t have found before. The same is true with penetration testing. By supplementing dynamic analysis, we find issues that the base tools wouldn’t have found. The tools generally continue to improve, but it’s debatable (and actually is heavily debated) whether or not the tools are even keeping up with the pace advance in software. Whichever side of the fence you sit on, the current situation is that we need to add humans to the mix to get better coverage.
There are a couple of very helpful resources that I would be remiss if I didn’t point out with respect to the penetration testing process. They are the Open Source Security Testing Methodology Manual and the OWASP Testing Guide. Both of these resoures are full of good (and thorough) information about both process implementation and integration within organizations.
In considering what to recommend with respect to the process of pen-testing, I came up with a similar process to my code-review list (so either the other list was good enough to work for both, or they’re both equally bad).
Define the Plan
Processes should have a set of goals. Define these within your organization based on your needs.
Again, simple, but not easy. This is a human-driven process, so it’s very common for people to either a) not do the tests, or b) to “rubber stamp” the tests. Neither are helpful, and both are common. This process must be setup and executed on a regular basis to provide the desired value.
Don’t Over-do It
Again, we have the idea that you have the law of diminishing returns. Showing that something is an issue in a couple places and thoughtfully working with the developers to come up with a resolution plan may very well be good enough. The developers can probably track down other instances of that pattern fairly easily.
Automate What You Can
You have to understand the capabilities and limits of your static and dynamic analysis tools. If there’s a coverage gap, you’ll need manual reviews or tests to cover it. Balancing this manual/automated approach is the key to security with scalability. Different organizations are going to slide along that scale a bit, but it’s important to know that the decision must be made, and to be conscious of the choices you’re making and why you’re making them.
Just like a code reviewer is going to use tools to assist in the review process (like a good IDE), a pen-tester uses special-purpose tools to have more control over the testing process. While I’m not a pen-tester by trade, I know some folks that are, and the tools I hear referenced most often as being good are OWASP ZAP and Burp. Again, I can’t personally vouch for either, but I really like the concept explained here regarding using ZAP for security regression tests, as this aligns nicely with my future article on testing.
Iterate and improve
This is, again, the idea of iterative and continual improvement. Come up with an initial process, try it out, then keep the things that work, and remove the things that don’t. I personally find that it’s helpful to do an evaluation/review of the process every 6 months to determine if everything’s still useful, and if anything needs to be added.
In conclusion, penetration testing is a necessary process if you really want to improve the security of your applications. It allows you to supplement the analysis from the tools and perform in-depth human-driven testing. This process has a high likelihood of success given you perform it regularly.