BLUF

Competing priorities, cost-consciousness, and lower-hanging security fruit were the reasons penetration didn’t make it into my AOP this year. I’m not in a highly regulated environment, though, so if regular penetration testing is a requirement, then your options are limited, but here are some things to consider.

Analysis

Each offensive security consultancy and penetration tester has their own methodlogy. Penetration testing isn’t guaranteed to find your most prevalent vulnerability, nor your most difficult, movie-plot security threat. It should, more often than not, find your lowest hanging fruit. Nothing in life is guaranteed so you may find you spent five figures to learn that those critical vulnerabilities your vuln scanner has complained about for weeks are, in fact, critical vulnerabilities that attackers will abuse to gain access to your data.

Recommendation #1 - Scope

Scope your penetration tests accordingly. This concept is not new, but it is essential if you want to ensure maximal efficiency of your test. If you want to test a particular network application, give your testers access to the network and assume an attacker would be equally positioned after a successful phish or stolen credentials.

Don’t waste time and money having the pentesters looking for de-prioritized attack vectors.

Recommendation #2 - Validation

Penetration testing offers external validation that your vulnerability management and security operations programs are functioning. You should detect the penetration test.

Allow me to repeat: You should detect the penetration test

You should be very concerned if you do not.

If you do not, immediately interrogate your EDR program. Are you lacking coverage? Is your EDR mis-configured? You’re accountable, but are you responsible? Is your MSSP responsible? Is there a communication issue, process issue, technical issue, or something else?

If you do detect the penetration test, congratulations! Communicate this fact early and loudly with your vendor. Now, allow the activity to proceed so you can understand where else in the environment you might not have such great detection.

Recommendation #3 - Remember “point-in-time”

By all means, report your penetration test detection success up the chain as an example of your practical defense against attackers, and as a testament to your defenders’ vigilance.

But don’t let it lull you into a false sense of security - the environment you detected it in is in flux. New vulnerabilities arise, configurations change. Congratulate your team, celebrate your victory, but don’t let it go to your head.

Recommendation #4 - ROI

I’m operating in a cost-conscious environment. I managed to save tens of thousands of dollars by opting for the following over conducting an annual penetration test:

  • Refining my bug bounty’s scope and rules of engagement. Bug bounties are an excellent alternative to a point-in-time penetration test, at least for Internet-connected assets. Run a bug bounty with a tight scope.
  • Bolstering my Vulnerability Management program. It doesn’t provide much value to confirm that attackers can exploit the vulnerabilities my VM program has alerted me to previously. Novel attacks are neat, and worthwhile, but I will only be keenly interested in them when my count of Critical and High-risk vulnerabilities is nil.
  • Collaborating with my IT team to ensure full EDR coverage. This is how I’m able to detect (and stop) attacker activity in the first place.
  • Automating my EDR. Anywhere I can get a slack message instead of logging into a console is a time-savings opportunity that shortens my OODA loop and increases my chances of attacker detection/observation.