Tag Archives: red teaming

Why You Should Go Beyond The Typical Penetration Test

This post was originally published on Forbes

If you’ve ever run across a penetration test report, they usually look bleak. I should know; I’ve authored hundreds of them. By their very nature, they try to focus on the most egregious security issues within a system or network. Having an understanding of how an actual adversary would perceive the organization (which is a lot different than how a hired penetration tester does) and a grasp of the business and operational relevance of the tested environment are crucial to driving an effective result.

In combination with a good understanding of the business risks and how they relate to cybersecurity (see my previous article on utilizing two frameworks for securing a decentralized organization), a company’s security organization can provide context for such technical and scope-focused penetration tests. As we go through a report and align it with business risks, we should keep asking “why/what.” Why is this finding relevant? Why is this issue so critical? What is the root cause that allowed an asset to be exploited? What are the environmental factors that are part of this scenario?

Through connecting the technical report to the specific business environment and contextualizing it with the actual valuation of assets/risks, we end up with a highly enriched map. This map contains the original report findings along with additional elements that the penetration test did not address, such as processes, out-of-scope-systems, environmental elements, compensating controls and awareness/practices.

How does this play out? Consider a report finding related to the ability to steal credentials, escalate them to a higher privilege and gain access to a sensitive server. A penetration tester may suggest addressing this through technical means (hardening the server to allow access from predetermined hosts, locking down workstations to reduce privilege escalation effectiveness and adding MFA). However, this could also be amended by enforcing two-person authorization for critical actions (breaking the ability to abuse a compromised account), using password managers (reducing the chances of reused or guessable passwords) or even increasing logging visibility (to provide the SOC with insights on privileged activities through the systems). These remediations are less likely to turn up on a penetration test report, however, they are just as effective — if not more so — than the classic ones that only address the common technical aspects of the issue.

By no means should this be read as an encouragement to ignore the report findings from a penetration test, but rather, it should compel you to enhance them within the business context and make them more applicable for your organization. Many of these tests are done through narrow scoping, so as you get more proficient in contextualizing the results, you’ll be able to work more closely with your penetration testers and guide them to provide tests and results that are attuned to your business’ needs.

Rather than taking these penetration test results as gospel, and instead of accounting for the specific business environment and risks (and, yes, the culture, practices and tolerance), security organizations can provide more effective and longer-lasting mitigations to security gaps, perhaps even lowering the severity of seemingly critical issues to negligible ones. By being a true partner in the organization, instead of limiting ourselves to a technical watch-guard, we can more easily come to acceptance and cooperation — not only from the technical teams we work with, but also from business leadership.

An obituary to pentesting?

I just saw a blog post in which Mike Kemp discovers the realities of 2010 (linkedin). (disclaimer – I know Mike and love him as a person, and this is my way of poking at him a bit – no disrespect here, but pretty much the opposite)

Now, go read that post (yes, I know, it’s long, but trust me).
This isn’t new (albeit very honest, direct and true),but here are a couple of comments I have:

  1. Penetration Testing is dead. Overrated, and abused by fancy vulnerability scanning, it died a few years ago. If you are still paying for one – check carefully what you are actually getting…
  2. Automation is king. I actually argue that 80% of what’s sold as a pentest by the major providers can/should be automated. All those scanner monkeys should be fired or forced to step up their game and actually do some work.
  3. Compliance? Really? Do you really want to go there? It’s got nothing to do with security, and if you thought so for a second I want to have what you were on when you did.
  4. Standards. This is where Mike touches on a sensitive topic for me (yes, PTES…). I’d actually challenge Mike to show me how PTES (which he mentions in the post – but you already know that because you read it, right?!) restricts providers by providing the engagement steps – which they should follow. There’s no restriction to scope, and I have personally used PTES in red team engagements. Full scope, no bars held. But still with a standard to follow, and something the client can also keep track of and know what to expect (and demand).
  5. I fully agree on the “pass the wealth” point where you should call in someone else who’s an expert to deal with a specific client request. Done that many times, and have never lost a customer that way.

Last but not least – yes, I do think that most pentesters can be replaced with a script. As they should. I do however have a solid advice to Mike and others who are still valuable professionals that have skills which are not replaceable by automation: demand a proper engagement model. And yes – I’m referring to the PTES again. You’d notice that threat modeling is part of it. Done properly threat modeling achieves multiple goals:

  • Forces the discussion to be around security rather than compliance, price or other factors that have nothing to do with security.
  • Scope goes out the window as threat models focus on the BUSINESS and not the TECHNOLOGY.
  • Enables the organization to test itself against its adversaries (threat actors/communities) rather than against pentesters. Much more rewarding, and correct.
  • Enables the provider (if it can muster to perform a decent threat model with the client) to charge decent rates for its services. You can clearly show how this isn’t some automated software running and spitting out reports, but skills and experience playing. It’s then your responsibility to follow through on it and make sure the final deliverable also looks like that (otherwise you are looking at a very short success rate for trying to adopt only part of this approach).

I actually welcome the hordes of scanner monkeys and tool-jockeys. They make the real professionals look even better. And although professionals don’t often have the marketing/sales power of the big-[number], trust me – they are busy, and doing work that the “big” and “trusted” suppliers can’t even start to put on their canned proposal templates.