Thank you for your interest in our newsletters. You will receive an email shortly to confirm your subscription.
Tinus Green, Security Consultant
20 mins read
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:
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.
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:
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.
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:
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.
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.
Each identified asset is now documented and assigned an importance rating. It is this rating that will eventually lead to a prioritized scope.
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.
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.
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.
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: