Pen testing best practices to take the pain out of penetration testing

I encounter many techies who love the science of penetration testing. They’re captivated by the technology stack, the vulnerabilities, and the tools at their disposal. But, at the same time, they find the task of pen testing itself aggravating and stressful. A real pain. Why is that? I noticed a common theme in their explanations when asked—the fun of breaking something is offset by the irritation of the overhead and mundane tasks required to get to the fun part. These individuals are my associates, my clients, and my friends. I recently started pondering how I could help them remove this pain from pen testing. I was especially perplexed because I knew these techies to be just that—exceptionally technically knowledgeable and capable.

It wasn’t until I met some folks who weren’t particularly technical—but loved the challenge of penetration testing—that I realized why some techies find it so painful. These technically lacking folks were green college grads whom I had the opportunity to work alongside for a client. They didn’t find penetration testing aggravating or stressful at all. They thought it was the best job in existence. I worked closely with these six individuals for several weeks. Over that time, I noticed their limited technical capacity was paired with a love of pen testing; compare that with the aforementioned techies’ abundance of technical capability and a distaste for the majority of the pen testing process.

These contrasting situations allowed me to realize a pattern; I was able to identify a handful of effective practices that may help take away the pain for those who are struggling.

Practice 1: Start immediately. Expect issues.

Penetration testing is something that has no quick resolution on the day your report is due. In the Doctor Who universe, the Doctor’s sonic screwdriver often provides such a dues ex machina resolution. Unfortunately, there is no sonic screwdriver plugin for Burp (although some find another type of screwdriver involving orange juice to be beneficial, but I digress).

The best way to avoid pain and frustration in the eleventh hour is to double your efforts in the first. Any issue that is a potential roadblock needs to be flushed out immediately. This roadblock is likely going to need to be resolved by someone else and will be something you’ll have little control over. But don’t be frustrated—you were expecting this, right?

Some questions you may want to identify from the start include:

• Do your credentials work?
• Can you access all parts of your application?
• Is it populated with test data?

Any question that isn’t answered with a ‘yes’ warrants an email or phone call to the appropriate party to resolve the issue. Make sure they understand the time sensitive nature of your request and its potential to roadblock your assessment.

Practice 2: Aggregate the important information.

You’re going to receive a lot of different information from a lot of different sources including emails, SharePoint assets, meeting recordings, instant messages, etc. Don’t keep these bits of information in their disparate locations. Extract the key information and record it in one centralized location. For me, this is as simple as creating a text document in my test’s folder in which I dump all of the relevant URLs, email extractions, scoping notes, etc. I even name it allthethings.txt. It’s the full body of knowledge for the test in one file. If you were to check my timestamps, you’d see that the file is created the day I receive as much as whisper about the upcoming test.

Few things are going to cause you more aggravation than spending 20 minutes tracking down a tidbit of information that you need for three minutes of testing.

I go as far as to keep a list of preliminary findings and notes on interesting things in this file as well. However, you organize your information in a way that makes sense to your process. Organize it in a portable format; portable meaning that if you have to pass the work on to another tester, it is arranged in a logical and centralized way. This will be immensely valuable should you have to pass the test on. You’ll also find the value should you yourself have to return to the test at a later time. Have you ever gone back and looked at poorly documented code that you wrote? Don’t make the same mistake with your penetration testing documentation. It’s a pain—and an avoidable one at that!

Practice 3: Organize your analysis.

I find a lot of the pain and frustration of penetration testing often comes from not discovering any particularly interesting vulnerabilities. This is particularly aggravating if your discouragement comes after days of frustratingly resolving roadblocks. There is a way to offset this though. Use a checklist. Even if you haven’t found anything of particular interest, the act of crossing things off of your checklist creates a sense of accomplishment.

There are other benefits too. It’s the same reason pilots use checklists on every flight. They provide a clarity check as you go through your routine and help prevent oversights. Pilots use two types of checklists much like penetration testers should:

1. The first is the typical checklist. An itemized list of things to check. For a penetration tester, this includes concrete things that you are looking for in your application. For example, “does the application rotate the session identifier after login?” belongs on the checklist. However, the question “how might the application be vulnerable to session hijacking?” is more generalized and does not belong on your checklist.
2. In aviation, pilots refer to the latter as ‘flows.’ For the penetration tester, it is a good idea to brainstorm these sorts of questions particular to the nuances of the application you’re testing. Maybe you’ll want to jot these down in your aggregated body of knowledge?