Prioritized testing: how to secure your estate and focus spend on real threats

Common approaches to scoping and testing are led by volume — how much can be tested within the scoped budget and how many vulnerabilities are exposed? Though efficient in theory, they fail to address how attackers view an organization’s estate and assets, what they will target, and how they would pivot between systems to achieve actions on objective. Testing without this context inevitably leads to an inaccurate understanding of posture and comes at the cost of long-term resilience. This can also lead to:

• Under-securing critical assets that are hidden or misunderstood
• Over-securing assets of low significance

Pragmatic prioritization — as an alternative — contemplates the assets that require scrutiny, based on specific, real-world threats, especially those that would threaten business continuity. Executed through the workflow described below, this prioritization can increase accuracy of security spend, expedite remediation, streamline resource, and provide proof of impact shareable with stakeholders.

Prioritization in practice

The prioritization workflow explained in this section is used by our own consultants. It can be applied within any organization, but it has been found to yield the biggest reward for those in which the estate is not well mapped and understood.

The two goals of this workflow are:

• To gather context on the assets in the estate by asking specific questions (outlined below)
• To apply an importance rating to each asset, indicating the criticality of its testing

Developing a universal vocabulary for the exercise

Before any scoping takes place, the team leading the workflow activity will benefit from aligning their security vocabulary. Though this may appear superfluous, it removes any possibility of nuance. The definitions below are a useful baseline, but your organization may have others.

Asset: a system or collection of services · Critical asset: any asset whose compromise or disruption in a cyber attack would interfere with business continuity.

Threat actor: a person (known also as attacker) or entity that exploits vulnerabilities to further an attack chain and reach a goal

Threat: something that could cause harm to an asset or assets

Vulnerability: a flaw in the design, implementation, or configuration of an asset that could be exploited by a threat actor

Control: something that reduces either the likelihood or impact of an event, reducing the risk as a result · Likelihood: a rating assigned to an asset indicating how likely it is to be targeted by attackers. This rating considers what the asset exposes and how it is hosted

Effect: from a business perspective, what the impact would be for the organization overall if the asset was compromised · Risk: a combination of the impact an event has on the business or its assets, and the likelihood of the event occurring.

Risk: a combination of the impact an event has on the business or its assets, and the likelihood of the event occurring.

Stakeholder workshop

The workflow begins with the identification of at least one critical asset in the estate, as well as the employees who act as stakeholders for it.

The associated stakeholders are then engaged in a workshop, each bringing their own knowledge to the exercise:

• Product Owner: understands the complexity of the asset, its business purposes, and what it is used for.
  • Product owners are often most valuable in the initial workshops, since they can provide high-level information on the asset, its purpose and its users.
  • They can also help identify connected assets and recommend when a technical stakeholder should be involved.
• Technical stakeholder: such as a developer, can describe the finer details of an asset and answer more technical questions, such as which services are exposed by an asset or in-use technology stacks.
• Asset user: especially useful for third-party-developed assets. These users understand the functionality of the asset and can thoroughly explain its use case, where access to technical stakeholders or product owners may not be possible within the business.

This workshop is led with a set of questions (see below) designed to help the stakeholders more deeply understand the asset at hand and those it integrates with. These questions should also be modified to fit the organization’s specific needs.

Asset investigation

For each asset:

1. How critical is this asset to the organization’s day to day business?

2. Is the asset proprietary or third-party?

3. Who interacts with the asset and how?

4. Where is the asset hosted?

5. How do users gain access to the asset?

6. If the asset was compromised, what would be the most likely actions an attacker could attempt? For example:

a. Service disruption

b. Financial loss

c. Exfiltration of client information

d. Exfiltration of employee information

7. What security controls are in place to protect the asset?

8. What testing has been carried out on the asset to date? 9. What services (e.g. anything users can interact with, such as an internet-facing web application, API, or MQ protocol) does the asset expose? The asset may be split into multiple if necessary. It is down to the team running the exercise to decide how granularly to define assets. For some organizations, an asset means a single web application, for others, it might include the corresponding API and underlying infrastructure.

For each connected asset:

1. What services consume resources from this asset?

2. What services are consumed by this asset?

3. What protocols are used to facilitate these connections?

4. Which of these connections are automated and which are manual? If manual, is it considered part of a security control?

5. Who are the relevant stakeholders for this asset?

Once identified, each connected asset is assessed through its own workshop. The process continues until the estate has been mapped out in full, or if a decision is made to stop the exercise. The latter may be necessary if the asset list becomes overabundant. Long asset lists lead to lengthy exercises that delay reporting and lose the context gathered at the start. In these instances, the exercise can be paused and revisited in future phases. Another approach would be to perform ad-hoc reporting to ensure context is not lost during the exercise.

Rating assets

Each identified asset is now documented and assigned an importance rating. It is this rating that will eventually lead to a prioritized scope.

Documenting

The following information should be documented for each asset:

1. A description of the asset (its role, functionality, user interactions, and any other significant insights)

2. A description of the asset integrations

3. The relevant stakeholders and asset owners

4. The likely goal an attacker would attempt following its compromise

5. An importance rating (calculated using the process below)

6. Estimate on the effort to assess the asset

Scoring and rating

The following information should then be captured:

What is the likelihood of this asset being targeted by an attacker?

1. Is the asset internal or external?

2. How many users have access?

3. How sensitive is the asset?

What are the potential impacts of a compromise?

1. Financial loss

2. All customer information leaked

3. Full control on the estate

The scoring system is defined by the risk and impact factors specific to the organization. These will vary greatly from business to business, but the two key metrics that should always be incorporated are “effect if compromised” and “likelihood of being targeted”. An example of our own risk matrix is shown below.

More metrics might be added as per the needs and interests of the organization. Banks, for example, would likely focus on loss of financial or client data, whilst telecommunications providers would place high emphasis on service disruptions. An organization will also have to adjust the risk matrix to their internal risk register. For certain organizations, even if a catastrophic effect is highly unlikely, it might still be rated as a critical asset.

Based on the results from the scoring exercise, an importance rating from critical to low can be assigned to each asset, as in the table below:

With the assets listed in order of risk, security tests may now be tactically scoped. When seeking stakeholder buy-in for testing, the list can be mapped to strategic security and business goals.

Modelling your environment

The information gathered from workshops, importance rating exercises, and goal-defined testing can be used to create threat models of an organization’s environment. These provide the security team with a visual reference showing how assets are connected—that is, how the risk of one asset affects the others around it. Examples of these models are shown below.

The first shows the connections between four assets in an estate. It also indicates the exposure of the assets, highlighting externally-facing systems. An attacker’s ability to modify data in Application A would be a medium risk vulnerability should it be tested in isolation. However, the model shows how this vulnerability would lead to users of Application B being affected, thus the vulnerability risk can be contextualized as a business risk. Based on the sensitivity of Application B, the organization can decide whether remediation of the medium risk vulnerability should be prioritized, perhaps above that of other, high-risk issues.

The model below indicates four assets and their connections to each other. It also indicates the potential attacker injection points, including the compromise of a middleware administrator and access to one of the communication channels between assets. The likelihood of these attacks occurring can be determined based on the exposure of said channels and the number of middleware administrators, to more accurately assign importance ratings for the assets. Considering the example in Fig. 4., the likelihood of attack on the middleware asset is low. This results from the asset being internal-facing, with access restricted to a select few users. Yet, the impact may be considered significant, due to the unfettered access this provides. Overall, this would constitute a medium importance rating.

Goal-defined testing

The above prioritization exercise will help teams decide which assets are worthy of their attention and tailor appropriate testing strategies to it. For some low-risk assets, this may mean no testing. For some higher-risk and low confidence assets, this may mean full, standard penetration testing. More often, though, this means some goal-defined testing – testing specific areas of an asset with a specific focus on achieving a particular business goal. This may include server compromise, exfiltration of PII or privilege escalation, or may be more technically-focused and specialized, such as configuration review of a CRM or SharePoint site.

Summary

A threat- and risk-based approach to security testing enables organizations to focus on the assets most in need of attention. At a deeper level, however, it also helps CISOs and other security leaders:

• Build executive-level confidence in their security assurance program by reducing the overall number of vulnerabilities reported. Those vulnerabilities that are identified will, when remediated, tangibly contribute to hardening resilience to critical business risks.
  
  
• Target the threats that matter most by weeding out the significant proportion of low to medium risk vulnerabilities usually reported via traditional pen-testing. Pre-empting and investigating the threats that pose the greatest risk helps to deliver tangible capability uplift by ensuring remediations address critical issues.
  
  
• Increase the breadth and value of testing by optimizing test time. Focusing on specific areas of investigation is likely to reduce the overall time and resource allocation per-test, and reduce time spent identifying low-risk vulnerabilities on low-priority assets. Further, looking at suites of assets at scale allows for the identification of high-complexity exploits involving chained vulnerabilities across assets. This leads to a holistic, contextualized assessment of overall security posture.
  
  
• Reduce the direct and indirect costs of security testing. It is important to note that the cost of testing is not limited to the test itself but includes the broader internal effort to plan and manage the security assurance lifecycle. By taking a more proactive role in the project management of your testing program, cost-efficiencies can be realized as a result.
  
  
• Overcome the static nature of cyclical testing. Historically, penetration testing has been performed cyclically. However, this means that assets are left untouched for months between engagements and exposed to the threats that emerge. By altering the mindset towards testing—that it should be modelled around ever-changing, real-world threats and attacker goals —there is greater chance that emerging issues get flagged and tested before they can be exploited.