A Comprehensive: Guide To Building A Pentest Program
A Comprehensive: Guide To Building A Pentest Program
A Comprehensive: Guide To Building A Pentest Program
Guide to Building
a Pentest Program
By Ray Espinoza Head of Security at Cobalt.io
Contents
Defining a Pentest …………..…………..…………..…………..…………..…………..…………..………..…………………….. 3
Bug bounty. These are open-ended programs where any security professional or hacker can
search for vulnerabilities in an application or asset. The customer pays testers based on the
perceived ‘quality’ of each finding, i.e., the level of risk it poses.
Pentest as a Service (PtaaS). PtaaS is an emerging delivery model that uses a platform-driven
solution and a freelance talent pool to manually search for vulnerabilities. Testers are
background checked and skills assessed before joining the talent pool, and then selected for
each project based on their specific skills and experience, making PtaaS a highly-focused
testing option. The addition of SaaS platform technology to traditional pentest consulting
models drives workflow efficiencies by connecting pentesters directly with engineering teams
to address identified vulnerabilities.
This guide focuses specifically on Pentest as a Service (PtaaS). When we use the term pentest,
it’s in the context of a PtaaS program. A formal testing program is a great way to ensure
continuous security coverage, and PtaaS is the approach we advocate to make security testing
effective, easy, and seamless.
Only pay for valid findings Hard to ensure full testing coverage
Pentest as a Service (PtaaS) Testers are chosen for their domain- For the best results, it requires ongoing
specific expertise input from the customer
These programs should be structured to ensure the most critical assets — or those that are most
frequently deployed — are tested on a regular basis. This ensures:
1. Continual testing coverage for critical and frequently updated assets; and,
2. A much higher probability that high-risk vulnerabilities will be quickly identified and
remediated.
NOTE
It’s important to realize pentest programs DON’T fulfill the same function as DAST/SAST
solutions OR bug bounty programs. Consistent pentesting of assets by experts with
domain-specific skills is necessary to identify vulnerabilities that require business context
not available from bug bounty programs or automated scanners.
Plan
Identify the asset(s) that need
to be tested, the cadence of
testing, and time frames.
Repeat Scope
Pentest programs use Determine testing depth
small, frequent tests to and resources.
ensure continual
coverage.
Anatomy of
a Pentest
Program
Retest Test
Testers check to ensure Domain-specific experts
fixes/mitigations have conduct thorough
addressed each automated and manual
vulnerability. testing.
Remediation
Security partners with
engineering to resolve or mitigate
identified vulnerabilities.
However, the demands placed on modern organizations ensure that IT infrastructure is never
static. New assets, patches, and lines of code are added all the time, and new vulnerabilities are
inevitably introduced over time. As a result, if the most recent pentest of an asset was six months
ago, there’s a very high chance it has new vulnerabilities that haven’t been identified.
However, the benefits of a pentest program don’t stop there. Maintaining a pentest program also
gives organizations the opportunity to build an ongoing relationship with their testers. Over time,
testers gain a much deeper understanding of the assets they are working with, helping them to
identify deeper issues and vulnerabilities that would otherwise be missed.
Finally, a pentest program can also help organizations identify systemic issues that arise across
multiple assets. These issues often indicate the need for targeted developer training or
implementation of new technologies. Through this insight, pentest programs help organizations
improve their overall security posture by addressing problems at their root cause.
In the Case Study section of this guide, we’ll explore the benefits of a pentest program in more
detail. By analyzing lessons learned from an initial engagement, the Cobalt Core pentest team was
able to get 5X the value during a second pentest.
However, in most cases, having a structured cadence for coverage is preferable to a point-in-time
assessment.
Before you enter into a pentest program, it’s important to determine what it needs to achieve. For
instance, do you need to achieve compliance with one or more frameworks? Do you have specific
assets that need to be tested and hardened? Your objectives will inform the structure of your
pentest program, so be sure to involve all stakeholders in this step.
STEP 2: IDENTIFY WHICH ASSETS ARE MOST CRITICAL AND/OR AT THE HIGHEST RISK
OF CYBERATTACK.
It may be that not all assets are equally important to your organization. Your pentest program
should aim to provide maximum coverage for your most critical assets while testing less critical
assets more infrequently.
A pentest program should provide continuous security coverage for in-scope assets. For that to be
possible, pentests should be scheduled each time a significant codebase change is rolled out.
Significant changes to infrastructure — such as a change in cloud providers or a move from on-
premise to the cloud — warrant a higher-than-average frequency and depth of pentesting. When
scheduling pentests, make sure you have a full picture of the organization’s intended digital
strategy during the program period. Equally, plan for some level of ad-hoc testing to account for
any surprises along the way.
The precise content of a pentest can vary significantly depending on the asset being tested and
your priorities. For instance, if you want to hunt down business logic flaws or privilege escalation
vulnerabilities, it makes sense to provide testers with login credentials for your asset. If you want
to know what an external threat actor could do without credentials, an uncredentialed test may be
appropriate. Equally, you may decide to include both credentialed and uncredentialed approaches
in a single pentest.
Once planning is complete, it’s time to decide which assets will be included in your program.
A word of caution: a common mistake that security buyers make is including too many assets in a
pentest and not allowing pentesters enough time to thoroughly test for vulnerabilities. If you aren’t
sure, ask your pentest provider for guidance to ensure your assets can be fully tested in the time
allocated.
Black box pentesting is where testers have no prior knowledge of the assets
being tested and aren’t provided with login credentials. It requires pentesters to
find flaws and vulnerabilities without any knowledge of data flow, design,
architecture, or roles/permissions.
Note that grey box pentesting is not the same as white box
pentesting, where testers usually have access to source code and
conduct targeted testing based on what is found in the code.
Some argue that black box pentests are more realistic, as real-
world threat actors won’t have access to credentials or guidance. At
Cobalt, we think about it like this.
The time allocated to pentesting is always limited. If testers are forced to spend some of the time
learning about the asset, that diminishes the time they can spend searching for vulnerabilities.
Threat actors, meanwhile, have as much time as they need to find weaknesses in an asset; having
to spend time studying an asset is not a hurdle to them in the same way it is for pentesters.
With a grey box pentest, testers have more time to search for vulnerabilities in an asset, because
they don’t have to waste time trying to reverse engineer an asset’s functionality. As a result, the
chance that testers will find high severity vulnerabilities such as business logic flaws are much
higher.
Once again, if real threat actors were to target the same asset, they would not suffer the same
disadvantages because they have the freedom to spend as long as needed to find a weakness. As a
result, while there are benefits to black box testing, grey box pentesting is a better option for most
organizations.
NOTE
The ‘black box’ vs ‘grey box’ debate is NOT only about credentials. In many cases, the most
important advantage a pentester can gain from grey box testing is a clearer understanding
of an asset’s business logic, permissions, and intended function.
Engineering/Product
Finding vulnerabilities is half the battle. The other half is closing them promptly and successfully.
For this to happen, vulnerability results from your pentest program need to be routed directly into
standard development systems and workflows. In other words, your pentest program should
support the secure development lifecycle (SDLC).
Engage with engineering and/or product leads as early as possible, and seek their input
throughout the planning stage of your pentest program. Developer time will be needed to resolve
identified vulnerabilities, and it’s best if this can be scheduled in advance to ensure sufficient
capacity.
For more on the importance of building relationships between security and engineering, check out
this blog post.
Leadership buy-in is critical for any security initiative. Pentest programs work best when they are
run consistently over time, so you’ll want to be sure that you have budgetary support beyond the
current year.
Fortunately, in recent years security has inched closer to the boardroom. In 2020, security is firmly
established as a critical business function, and most boards demand oversight in some capacity.
As a result, gaining approval for security initiatives that have genuine business value is much easier
than it once was.
Providing regular reporting to leadership executives is an excellent way to evidence the ROI of your
pentest program. By highlighting the number and quality of vulnerabilities identified, as well as
their potential impact on operations, you’ll be demonstrating the business value of your program.
Naturally, our program aims to be the gold standard of pentesting. After all, this is what we do.
As mentioned earlier, the first step in developing a pentest program is to set objectives. Cobalt’s
pentest program has the following objectives:
2. Ensure customers can trust that our platform is secure and regularly tested.
The program currently follows a quarterly testing cadence for key assets, which include the Cobalt
web application, API, network, and cloud configuration. In the event of larger releases, we also
perform ad hoc pentests.
Through our program, we’ve learned a lot about how to plan and structure pentests to support
business and security objectives. To highlight some of these learning points, we’ll examine two
recent rounds of testing: Q3 2019 and Q4 2019.
Our Q3 pentest targeted several Cobalt domains and subdomains, as well as all of our external IPs.
Our methodology was simple:
1. For web assets, we wanted to cover the OWASP Top 10, ASVS, and test application logic.
2. For our network assets, we wanted to cover OSSTMM and the CIS Security Controls.
3. For our APIs, we wanted to cover the OWASP 2017 Top 10.
The aim of our Q3 pentest was to find out what real-world threat actors might be able to do to our
assets. As a result, we decided to conduct a black box pentest
The results: Our pentesters discovered three total vulnerabilities, one of which was high-risk and
fixed immediately.
What did we learn? Overall the pentest engagement was a success, because it helped us identify
important vulnerabilities in our key assets. However, it didn’t produce as many findings as we had
hoped. We had a hunch that a grey box test would be more effective.
Since we had recently switched cloud providers, in Q4 we wanted to conduct a network pentest.
Our testing scope was similar to that of our Q3 pentest, however, we made several structural
changes based on our lessons learned from Q3:
2. We provided our pentesters with context about the assets, including documentation, use
cases, data flow/network diagrams, information on roles and permissions, etc. Among other
things, we recorded a video that walked testers through critical work flows and the differences
between roles.
3. We had an experienced Cobalt Core member lead the pentest as well as personally test a
critical section of our platform.
The results: Our pentesters uncovered a higher number of vulnerabilities during the second
pentest, two of which were high-risk and fixed immediately. On top of this, several of the
vulnerabilities were more complex in nature than those found during the first test — the type of
vulnerabilities that might be missed if testers aren’t provided with thorough context into the assets
they are testing. To illustrate this, many of the findings from the second test were related to roles
and permissions, which can only be thoroughly assessed by a tester who understands the business
logic of each asset.
In addition to the additional findings, comparing the experiences of our Q3 and Q4 pentests
yielded plenty of important lessons.
Lessons Learned
Pentest programs are great for incremental security improvement. Each round of pentests
within a program provides learning opportunities that can be implemented ahead of the
next test.
Grey box testing is the way to go for B2B companies. This may not be true for every
organization, but for our B2B assets, grey box pentesting proved a much more effective tool
for identifying high-risk vulnerabilities.
And we weren’t the only ones to learn from our pentest. Our testers also had a few things to say
about the engagement.
A more engaged customer means more engaged testers which leads to a better pentest.
From our testers’ perspectives, having a direct line of communication via Slack was hugely
valuable. They were able to get answers to questions quickly, and easily discuss their activities
to ensure full testing coverage.
Product walkthroughs and guidance make a huge difference. Again, grey box testing isn’t
just about credentials. It’s about testers understanding exactly how a system is supposed to
work. The better the guidance they receive, the higher quality findings they are able to
produce.
Perhaps the single greatest benefit of a pentest program over ad-hoc testing is the ability to learn
from each pentest and improve. Each time you conduct a pentest, you’ll have an opportunity to
learn more about how to run an ideal pentest program for your organization.
If you take the opportunity to learn from each engagement and implement changes, the quality of
your findings will improve exponentially over time.
To find out more about how a pentest program could benefit your organization, visit our website.
Ray has over 20 years of technology experience and 12+ years in information security. Prior to
Cobalt.io, Ray drove 3rd party cloud security across Amazon’s retail business. Additionally, he held
VP and CISO roles with Atmosera and Proofpoint as well as various security leadership positions at
Workday, Cisco Systems, and eBay.