Pentests in Risk Assessments: When, Why, How

Vulnerabilities, likelihood, impact, safeguards — all keywords that are part of every risk assessor’s vocabulary. As it so happens, these are also the main outcomes of a successful third-party pentest: a group of professional hackers stress test your systems or application(s) and raise discovered vulnerabilities; they use business context to determine an exploit’s likelihood and impact; and guide your team on how to remediate and implement stronger controls. 

Because of this, pentests are a valuable tool in risk assessments, particularly those focused on technical assets such as applications, APIs, networks, and cloud instances. In this blog post, we’ll go over different goals pentests can help you achieve in your larger GRC projects, and how to integrate them into your assessments. 

Goal 1: Identify Threats and Vulnerabilities

Chances are, you already have a general view of your weaknesses and corresponding security controls. But have you covered every attack vector? 

Things change quickly, especially in the realm of web applications and APIs, at a scale you could not cover consistently. There are many options for security teams to find vulnerabilities — scanners, bug bounties, red teaming, etc. — but pentesting brings benefits to the table that are hard to match: an independent view from a third party, not just on where you’re vulnerable, but also where your controls are not strong enough to stop a breach.

Malicious actors have much more time at their disposal to circumvent your defenses than you do to cover every attack vector. A group of pentesters can stress test your controls and report on the resistance they faced, what steps they took to try to bypass it, and whether they were successful. You’ll know where your controls are effective, and where you need to focus more resources. 

Goal 2: Determine likelihood and impact

Not every vulnerability is a bullet-shot wound — their severity depends on likelihood to be exploited, and the impact on the company if that happens. 

A scanner can flood your inbox with alerts on Cross-Site Scripting (XSS), but will it be able to determine with enough accuracy just how critical this is to your systems? Chances are, it will default to “critical” or “high” severity, even if the real issue is on the lower end of the risk spectrum. This inevitably pulls focus away from higher priority items. 

This is where manual testing from professionals can truly shine. Working together with security teams, pentesters can gain enough knowledge about your business and systems to customize a finding’s likelihood and severity to your particular context. Further, they can include information around your compensating controls, since they had to “endure” your defenses. This is strategic knowledge — it not only enriches your risk assessment and report, it also helps you decide where you need to focus as you move on to treating your risks.

Goal 3: Treat risk and manage vulnerabilities 

Using all the information and context gathered throughout the pentest, testers’ reports provide customized recommendations on how to correct every finding, whether it be low-risk or critical. This takes the burden off of your security team having to figure it all out, parsing through vulnerability libraries to find the best solution for your situation. 

And reports help reach another goal — communicating risks to relevant stakeholders. The context pentesters provide can help narrow things down to accurate next steps and estimated expenditure. This is especially valuable when you have to communicate your risk assessment results in strategic, high-level meetings, where the audience might not be technical. To help leadership prioritize security, you need to be specific, aligned with the business context, and strategic: interacting with your pentesters can help you achieve each of those points and get the resources you need to strengthen your security posture. 

Adding Pentests to Your Risk Assessments

So how do you actually kick things off with a third-party pentesting vendor? To answer this, we’ll focus on the first two steps of our pentest process: Preparation & Kickoff.

For us at Cobalt, preparation includes the pre-sales cycle, scope agreement, testing brief creation, tester staffing, credential sharing, and any kickoff or preparation calls needed before the testing begins. In other words, everything that is needed to perform the pentest must be aligned upon during this step. Here's an overview of the information that a good scope includes:

• Targets: What assets need to be tested? 
• Pentest size: Should the testers do a comprehensive review of your entire application, or focus on a specific feature? 
• Objectives: What do you hope to achieve with the test, e.g. fulfil compliance requirements or review a new release? 
• Instructions: Are there any technical details you want the testers to be careful about, or aware of? 
• Timing: Do you want the test to start as soon as possible, or schedule it for a later date?

This step is absolutely critical to the success of the pentest, and it’s also the place where you can define what quality results should look like. It sets the tone for the entire engagement both from a customer and vendor perspective. 

After confirming the scope, we move on to the testing phase, followed by reporting, re-testing, and feedback. To learn more about how our process compares to competitors, check out this buyer’s guide. And for a third-party view, check this report on the whole Pentest as a Service market by the independent research agency GigaOm.

Whichever vendor you choose, pentests will enrich your risk assessments with contextualized information, detailed findings, and strategic next steps — they strengthen your security, and protect your organization and customers.