Episode: #117 – Pentest och ekonomi (eng)
Recorded: 2021-03-26 (published 2021-03-28)
Participants: Erik Zalitis and Simon Roe (Outpost24)
This episode is brought to you by SIG Security.

Listen to the episode

Things to ponder while listening

This text and the podcast is in English as mr Roe is a native English speaker.

So where to begin? I will assume you know what penetration testing means. Instead I will try to interpret Simon’s ideas and counter them with my own. I agree with much of what he says, but have some other experiences on some occasions.

Simon likes to talk about the future of pentesting by comparing it to Netflix. Instead of a lengthy negotiation of terms and prices, only to be told ”we will be able to start in eight weeks”, it should be a formalized process and little waiting times. This will mean that recurrent testing with short intervals can be done.

A common process is that you tell the customer that this is a 10 hour test or we need 40 hours. Simon rather tells you that this is what you get for x hours. He also believes that the customer should be able to see the tentative finding as the test runs and then fix them and ask the tester to retest within the tests original time frame.

Let’s first talk about where I agree with him:

The tests must be more formalized. Pentesting used to be long winded negotiation and suffer from some ”rockstar hacker” mentality. The testers were seen as super talented hackers that could warrant the exorbitant pricing. This is thankfully over now. The prices of testing is slowly decreasing as it should and there are many frameworks for testing available. Simon may talk about a Netflix (”Click to order”) approach, but for me it looks more like the ”order a new server by calling the customer manager” as opposed to the modern ”click a button to provision a new server on Amazon AWS”. I’m 100% with Simon here.

The reports and status should be available on a portal. This can make the process of delivering the bad news more secure, so the company gets the report and not some opportunistic hackers. The portal must have very heavy security and also feature automatic destruction of data and multifactor authentication not to say auditing.

Where I have other views on the matter

He wants to publish results on the portal as the test proceeds and also let the tester re-test (as I wrote previously). This is not something I would do. The rationale is that test must be allowed to finish before analysis can be done. Also, remember, we have a limited amount of testing hours. Retesting within those will consume time from completing the principal attacks properly. Also, I believe it will not give the customer a chance to understand the underlying problems before fixing them.

Then when it comes to the negotiation of the time frame, I see it a little bit differently.

I believe the correct approach to decide a time frame for testing is:

1. Get the size of the environment to be tested.
2. Build attack scenarios (e.g. Unauthenticated attack followed by a authenticated attack against…)
3. Decide knowledge profile (White/Gray/Black hat)
4. Decide location (e.g. On premises, over VPN or from the Internet)
5. Decide the type of attacks (e.g. injections, buffer overruns, but not DDOS)
6. Calculate a reasonable amount of time for the planned attack given the factors above
7. If the customer wants to shorten the suggested time frame, it’s not a problem, but will yield less results.

This means, the test can be properly defined and accepted.

To sum it up, I like the idea of optimizing the pentesting procedures in order to make it behave like any other service you purchase and believe that Simon’s ideas are a good way to step in exactly that direction.

But what about going even further? I have an idea too:

Create a governing body for pentesting that oversees the process. It should be voluntary for testing companies to join, but can be used to prove that ”we’re a part of the international ethical hacker congress” (or whatever such an organization may be called). Part of the organisation can be making sure testers work, plan, attack, report and negiotiate jobs in a very similar way. The may create tools, procedures and provide a things like templates for reports and automatic data exports so reports from different testing companies can be loaded into an application to compare and summarize them. Some may think that ISC2 or ECCouncil could do this, but I think a large scope is needed for this.

Links

• SIG Security
• Outpost24
• Simon Roe – Product Manager at Outpost24

Errata

• None at this time. Please comment below if you find something that needs correction.

• 0 comments