Conducting A Successful Pentest by Ayman Elsawah Conducting A Successful Pentest by Ayman Elsawah

[mr23r0]

posts resources guides books philosophy
../

Conducting A Successful Pentest by Ayman Elsawah

Index

Introduction

As pentest season descends upon us, I’d like to share tips and tricks to get the best value out of your pentest and ensure a successful engagement. I’ve been on both sides of the fence, so I think I have a unique perspective to share on this often nebulous endeavor.

This guide will help you:

  • Distinguish a good pentest provider
  • Ensure you have the best talent on your project
  • Scope your project to have the most effective pentest
  • Setup your pentest for success
  • Understand what to expect from a good pentest company

With this guide you should be well equipped to have a successful pentest.

Let’s get into it!

What Is A Good Pentest?

Selecting a pentest provider can be a daunting process, especially if it’s your first time. How can you tell which company will do the best job?

Well, let’s start there.

What is a good job? What is a successful pentest?

A good pentest does not necessarily mean that a lot of bugs were found, although if it’s your first pentest I would be surprised no vulnerabilities were found.

A successful pentest means you had the right people on the job, they had adequate time to find the issues, and were provided with the proper resources.

That’s basically it in a nutshell.

Before The Pentest

Selecting A Provider

Now that we’ve established success criteria, let’s go into vendor selection. These are the people to do the job.

One distinguishing factor in a provider is having a good research arm.

  • Do they publish a lot of research? How often?
  • Do their pentesters have any published CVE’s?

At the end of the day, selecting a vendor is basically on whether they have the right people to do the job. They can have all the logos in the world, great sales people, and even an interesting app along with it… but can they do the job?

Next you will want to match the people with your stack.

Is there anything nuanced about your stack? Do you have mobile or desktop apps as well?

In the proposal, a good pentest vendor will provide you with bios of the people assigned to your project. That will allow you to look up their experience, their blog posts, GitHub profile, and etc and see if they are a fit for you.

Next is ascertaining how long the engagement will be. There are several ways they are configured, but there are only two main factors:

  • How many people are assigned to the pentest?
  • How long the actual pentest will be?

Typical engagements are 2 x 2, meaning two people for two weeks.

This can vary from provider to provider, with scope being a factor in consideration as well.

So if you have a tiny application, they may decide to make it a 2 x 1.

If they’re throwing a superstar on the application, it can be a 3 x 1.

YMMV here.

One other important consideration is whether the people assigned to your project are ever double booked. It’s important to ask your vendor whether they are ever double booked.

While they may not be double booked during the engagement, sometimes what happens is they are still writing the report the following weeks, while on another engagement.

Depending on the size of the firm, they may have a QA process where reports must go through a peer review or QA process. This is a good thing, and we should allow this process to work.

In some companies, the people that do the pentest are not the ones that write the report. Any findings found will be sent to a reporting team where they will verify findings and writeup the report and remediation. This is an interesting model.

A Note About Cost

Keep in mind, the most expensive provider does not always mean the best. Conversely, the cheapest isn’t always the worst.

Labor cost is just part of the equation, most of which can be attributed to locale. Other parts that play a factor is the amount of overhead internally (project management, account executives, etc.). So a lean shop of 10-20 super senior experts could be cheaper than the 80-100 person shop. So YMMV.

Project Coordination

A pentest is a significant project on its own. So many different components are involved and since it’s a time boxed engagement, any delays could be very costly. Momentum stops and having to restart again is a waste of time.

Some pentest firms will assign a project coordinator to help facilitate the process. They will take care of scheduling kick off calls, getting credentials, and communicating with you throughout the engagement.

Regardless of whether they provide someone or not, you must have a point person internally on your side that is coordinating the engagement and keeping them accountable. Having this will increase the likelihood of a successful pentest.

This can be the CISO/Head of Security, Deputy CISO, or security engineer.

This person will be the glue on your side that is working to get the environment up and running, getting credentials, checking calendars for calls, and coordinating communication between the internal team and the pentest team.

You thought you could just get a pentest and forget it huh? 😅

Environment

An important factor for any successful pentest is having the right environment for a pentest. You will want a like for like environment with the same code and logic running in production. This may be an existing staging/dev environment or a brand new environment.

Where possible you will want a dedicated environment, especially if your risk tolerance for availability is low, but it is totally understandable that resource constraints, especially if you’re a startup, may not warrant such a luxury.

Allowing a pentest on your production environment, while not unheard of, is not recommended. Pentesters will use a combination of automated and manual tools where they are trying to actively exploit your application. This means they are trying to get the application to do things it was NOT intended to do.

They cause the application to freeze.

They may access data they were not allowed to.

They may get RCE (Remote Code Execution) on your container or EC2, and try to elevate from there. (I assume you’re not running your containers as root, please tell me that’s the case!).

They should have liberty to do as they wish.

You are paying expensive dollars for this, make it worth it.

So yeah, don’t run a pentest in production or with production data.

Credentials

Another part of a good pentest is simulating authenticated users.

While pentesters will conduct unauthenticated attacks on your website, they will also need to run authenticated attacks.

The goal here is to have them try to access data they are not otherwise supposed to access (cross tenant attacks).

So to succeed, each pentester will require at least one credential for every role available on your application, including admin.

So if you have 2 pentesters, and 3 roles (user, power user, admin), you will need 2 sets of credentials created, one for each role, 6 in total.

Some companies may ask for more, but this is the minimum any good pentest firm should request from you.

If they don’t ask until the pentest has already started, then they are not organized and professional imho.

Please also make sure the testing environment is stable.

Nothing like an unstable environment to ruin a pentesters day.

Not to mention an utter waste of time and money.

Fix Your Low Hanging Fruit

Before doing a pentest, make sure you fix all your low hanging fruit.

You’re bringing in professionals to try to break your app and make it do nasty things.

You wouldn’t want to waste their valuable time with weak passwords and not secure cookies.

Not only that, but you don’t want these basic items on your report in the event you need to share it externally (see below).

Believe it or not, many companies know about these vulnerabilities already, but just haven’t fixed them for whatever reason.

Fix them.

Of course, don’t let this be a blocker for a pentest. Maybe you (the security person) are looking for a 3rd party to validate what you already know.

Happens all the time.

During The Pentest

So your pentest is scheduled to start on a Monday.

On the Friday prior, you should have had the kickoff call, credentials exchanged, slack channel setup, and environment ready to go.

That is the best early indicator of a successful pentest.

You have the pentesters ready to hit the ground running on Monday.

Nice work.

Watching the logs

Now you as coordinator on the client side sit and wait.

You can watch the web traffic and requests as they hit the application.

This will give you an idea of how they work.

They may first start with the standard automated or semi-automated tools.

Or maybe they are using custom scripts they’ve developed.

It should be pretty intense the first couple days.

You can see if your WAF has caught any of their traffic as well.

Check-Ins and Communication

As with any relationship, no news is not great news.

The more communication the better.

Did they find any bugs?

Did they run into any issues?

Is everything ok?

Keep in mind, if a pentester finds something they have to spend some time validating the finding.

They wouldn’t want to startle you with a finding, only to find out it was a false alarm.

Regardless, having a quick check-in more frequently than not can be very helpful, especially in the beginning, however the reality is that pentesting is a demanding business. A daily check-in for example is too much, and many shops will push back.

To find a balance, I would get a quick check-in at the end of the first day or first thing the next and then another a couple days later. You would be surprised, some pentesters may have something on their mind, but don’t speak up.

Sample Schedule

So if the project starts on a Monday, here what it could look like:

Week 1

  • Friday - Kick Off Call and creds exchange
  • Monday EOD - Quick Sync w/PM
  • Thursday AM - Quick Sync w/PM
  • Friday AM - Brief Check-in with Pentesters, findings update

Hopefully this doesn’t annoy them too much!

Week 2

  • Either Tues or Wed - Check-In w/pentesters

Why so many check-ins?

Sure this may sound like micro-managing a bit, but keep in mind this is a time boxed engagement. So if the pentesters bring something up that you think they should explore a little more or conversely don’t want them to go down a rabbit hole because you know about a bug already (which you should have mentioned), then this will save you time. This also assumes your application has a large footprint and may be a bit complex.

Hopefully this context will help you have a better understanding of a pentest flow.

Another helpful reason for the check-ins is to learn of any findings and try to fix them before the pentest is over. See below.

After The Pentest

Wrap Up

After the pentest period is over, now the fun part (no, I’m being sarcastic) comes. The pentesters now need to write up a formal report to be presented.

Keep in mind, they need to not only verify all the findings, but need to make suggestions regarding a fix.

More often than not the fixes will be generic, as many shops don’t have the time to write a custom recommendation.

However, sometimes you will see custom written recommendations, where they give specific instructions on how to fix a vulnerability. That is sweet.

Of course, we have AI now to help us with this task, so maybe it’s not so meaningful, but I can still reminisce right?

Once the report is done, they should reach out and schedule a read-out.

Reporting & Read Out

Probably the most important part of the penetration test is the read out.

This is an opportunity to hear it straight from the technical people who were hammering away on your app for a couple weeks.

You will want the right people in the room, and they need to hear it live.

Both Engineering leaders and engineers should attend.

The various viewpoints are important.

Especially if something is going to be prioritized, engineering leaders should have the context why.

Btw, If your pentest firm just hands you a report, then they may not be super professional imho!

Insist on a readout.

Fixes Before Final Report

You have a few opportunities to fix any vulnerabilities found which would be beneficial to you in the long run.

During the readout or prior, the firm may be presenting a draft report.

If there is a finding found and you are able to fix it before the report is finalized and during the pentest, then the finding will be labeled as fixed in the final report.

A finding will never be not disclosed once found. You wouldn’t want that and it’s not ethical.

Retesting

Some firms will also include a free retest within 60 or 90 days for example.

This is helpful in the event you were able to fix the issues, they can retest and make sure your fixes solved the findings.

They may be able to issue an updated report as well, or at least a one pager mentioning the retest and results.

Sharing Your Reports

You have this shiny new report that has a lot of ugly things about your environment.

What if customers ask you for a copy, what should you do?

The standard playbook for most security situations is to share as little as possible.

This is not legal advice, consult with a lawyer.

Your pentest firm should give you a Letter of Attestation along with the report.

This is a high level document that says they came in, they saw, and they finished.

Usually it will just have a count of the severity of vulnerabilities found.

Names of vulnerabilities are not usually listed here.

This will take care of many customer’s needs.

Keep in mind they will ask you if you’ve fixed them or not.

The next step of sharing, would be a table of contents for the report.

This would typically list the names of the vulnerabilities and severity.

Lastly, would be sharing the entire report.

Some things to consider when sharing your report:

  • Always have an NDA
  • Do not distribute this report freely, especially to non-customers
  • You are expected to fix the vulnerabilities in a reasonable amount of time. If you haven’t fixed them, it’s not the end of the world, as long as you are to explain why and it’s an egregious issue.

Conclusion

Ok, so that’s everything I know about running a pentest.

For pentesters, it’s an intense period. Having a short amount of time to find vulnerabilities can be daunting but also a fun challenge.

A successful pentest requires investment in time and resources ahead of time.

It’s well worth it though.

With this guide you should be well equipped to have a successful pentest.