Tag Archives: PTES

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.

Post Brucon thoughts – guesstimates in an engineering field

So, another epic Brucon has ended, and while everyone is getting their thoughts together again (the amount of super smart people I have had the pleasure to have conversations with is unimaginable), I wanted to post a quick recap.

First things first – numbers. I’ve been working with the FAIR methodology quite a while now, and have actually (with the kind permission of Jack Jones) integrated some of its elements into the Penetration Testing Execution Standard (PTES). Watching the discussions that started after Jack’s talk at Brucon was heartwarming. Pentesters and security practitioners finally “get it”, was divine. Working in a field of engineering that has the least engineering in the sense of how it’s applied to businesses has been frustrating to say the least. With the ability to effortlessly connect the technical elements of vulnerabilities and exploits to business-speak has been one of my personal challenges (and hopefully strengths), and being able to tilt the industry even a little towards that direction is something that we all needed for a long time.

A quick “teaser” to add on top of it (which has been previewed in my talk) is the ability to also marry in the social media risk into the risk management practice (look out for some more cool research and insights coming from that direction very soon!).

Which leads me to the last point – the ever evolving presentation I use to deliver the message about data exfiltration is provided for your viewing pleasure. Don’t fear the >100 slide count – it’s mostly the “build” effects that I left in for clarity.

Looking forward for some more discussions and developments in the way that we as an industry are justifying what we practice (if it wasn’t obvious by now – go check out what FAIR is, and then start thinking on how to integrate it into what you do…).