Home Page

Practical Threat Analysis in-depth

 Part 3: The PTA Threat Model and Risk Analysis Process

The following scheme describes the interrelations between a threat and the assets, vulnerabilities and countermeasures entities.

In a nutshell:

• Threats exploit Vulnerabilities and damage Assets.

• Countermeasures mitigate Vulnerabilities and therefore might mitigate Threats.

The Threat Analysis Steps

1. Threat Analysis Prerequisites

The threat analyst maps system assets, identifies system vulnerabilities, predicts (even the most hypothetical) threat scenarios and evaluates threat probability and damage in order to be able to prioritize the corresponding countermeasures.

Before starting out, the analyst should learn the system's terminology, functionality and architecture. The in-depth understanding of the system is of crucial importance for the correct identification of system assets and vulnerabilities and for the correct building of threat scenarios.

The following documentation is needed:

• Terminology dictionary that explains the terms and acronyms relevant to the system being analyzed
• Functional description of the system including all typical use cases descriptions
• Architectural diagram of the system and documentation for various system modules

These documents must be detailed enough to be used as reference for deciding on the applicability of various threat scenarios to the analyzed system.

2. Preparing a List of Tags

It is a good idea to prepare a list of relevant tags that will help the analyst classify the various threat model entities according to their specific properties. For example: define tags for each of the system’s components or various areas in the system architecture.

Tags can later be associated with model entities and improve the readability of the threat model.

3. Identifying System Assets

The correct mapping of assets, their financial value and the evaluation of financial loss to the system's owner when these assets are damaged or stolen, is one of the most critical tasks in the threat analysis process. The assets value is used as the basis for calculating threat risks and countermeasures priorities.

An analyst may at times hear claims like “everything we have is important”. While this could be true for some systems, we believe it is not the typical case. It is more likely that assets need to be clearly prioritized. Consider, for example the following partial list of the assets of a financial institution:

• Office equipment such as printers
• Confidential client information
• Clients’ money
• Private keys used for authentication of transactions
• Master key used for generating private keys

The accurate assessment of the potential financial damage of losing each of the above assets will enable their correct prioritizing and help avoid a situation where the institution invests resources in protecting printers while leaving the master key unprotected.

In some cases the value of assets is less intuitive especially when they are intangible. For example, the confidence of the public in an electronic trading system may be damaged by the appearance of non-relevant text on the system’s Web site. No money is lost, no information is disclosed, all technical resources are still functioning but the site reputation and the shopper's trust are shaken. An indirect financial loss should be set for this type of damage.

Due to the importance of asset mapping, we recommend that the asset list and corresponding values be regularly checked by non IT personnel, such as the company’s CFO, marketing officers and legal consultants. Analysts can quickly perform a “what-if” analysis by modifying asset values and obtaining insights on the model’s accuracy and completeness.

In practice, it is often easier for the analyst to identify system assets through analyzing specific threats (as described in the following). A fact of human nature is that we don’t realize how valuable things are until we lose them. This implies an iterative approach of mapping assets and threats.

4. Identifying System Vulnerabilities – the real ones

Identifying vulnerabilities requires that the analyst be intimate with the system’s functionality, architecture, implementation and deployment details. The analyst should also be familiar with business and operational procedures and the types of users and other parties involved in system operation.

An analyst can use the Web to find generally known vulnerabilities as published by software vendors and security consultants. Most of the items in these check lists are, in many cases, irrelevant to the specific system or may be easily solved by a simple comprehensive routine such as “always install most updated vendor’s security patches”. The thing that should concern us here is that such a list will draw the attention of the analyst away from the real vulnerabilities that are specific to the analyzed system.

Therefore we highly recommend that the analyst should investigate the system's architecture and implementation details and collaborate with architects, developers, installers and support engineers as well as with the system business managers to discover the real vulnerabilities that are unique to the system and may not be identified without this intimate knowledge. From experience – the most severe vulnerabilities reside in the interfaces, junctures and stitches between the various elements in complex systems and rarely appear in the standard lists.

As mentioned before, the identification of relevant vulnerabilities is a continuous iterative task bundled with the step of identifying threats (described below) - the real sophisticated vulnerabilities are identified when building threat scenarios.

5. Defining Countermeasures

Defining countermeasures produces two outputs:

• A list of countermeasures that protect vulnerabilities. The list includes the implementation cost of each countermeasure and their relevant tags. If the countermeasure is already applied it should be marked as ('already implemented') to enable producing updated statistics of the current system risk level.
• A map of the relationships between countermeasures and vulnerabilities. This map shows which vulnerability may be mitigated by a specific countermeasure. Sometimes a countermeasure is introduced as a solution to a specific vulnerability, but after additional consideration it turns out that it may help in mitigating other vulnerabilities too.

The accurate identification of countermeasures and their relations with vulnerabilities is the basis for building risk mitigation plans as described in the next steps.

6. Classifying Potential Attacker Types

Classifying relevant attacker types focuses the analysis on practical realities. The classification of attackers is useful when we can clearly relate each of the threats with one or more of the attacker types.

Attacker types data include the understanding of his/her motivation as well as his qualification, available tools and accessibility to the system. Special care should be given to the classification of ‘insiders’ attacker type since their activity may be especially dangerous.

A good starting point can be defining an attacker type for each of the user roles which appear in the system's use cases and reserve few more attacker types to hackers and other types of offenders.

7. Identifying Potential Entry Points

The best tactic for this step is to review the list of attacker types and document every possible way the potential attackers could access the system. The list of entry points may be revisited and clarified during the analysis process.

8. Building Threat Scenarios and Mitigation Plans

This is the most important step of the threat analysis process. Its outcomes are:

• A list of the system's threats
• A map of the relationships between threats and associated tags, assets, attacker types, entry points and vulnerabilities
• An evaluation of the total damage and risk parameters for each of the threats
• Mitigation plans and the evaluation of the remaining system's risk data

Since threats are the most complex entities in the model, the process of identifying and constructing the threat's elements and parameters has a 'decomposition' nature. During this process the analyst will have to return to previous analysis steps in order to create missing entities, such as assets and vulnerabilities referred by the constructed threat. The following describes the sub-steps of building a threat scenario and a mitigation plan for a single threat.

* Initializing threat - start from name and description

Always start by giving the threat a name and a short textual description (a few sentences) that includes the attacker’s actions and the threat’s impact on the system. The description will be used as reference for the following steps and will be refined during the process.

* Identifying damaged assets and damage levels

Compose a list of assets that may be damaged by the threat and the maximal damage level that may be caused by one incident of the threat to each of them. That will enable the automatic calculation of the total damage (financial losses) to the system if the threat materializes.

* Setting the threat's probability

Threat's probability is set by estimating the number of times the threat will materialize per year. Its value is in the range of 0 – N, where 0 means that threat will never materialize and N means that the threat will materialize N times in a year. The threat's risk value is automatically calculated based on the threat's total damage and the threat's probability.

* Identifying the exploited vulnerabilities

The correct identification of the vulnerabilities exploited by the threat is important for choosing the most suitable countermeasures and building the threat’s mitigation plan. Once the vulnerabilities are identified, the list of proposed countermeasures is populated automatically.

* Building a mitigation plan for the threat

Building a mitigation plan is done by selecting the most effective combination of countermeasures from the list of all the proposed countermeasures for the specific threat. The decision, which of the proposed countermeasures would be included in the actual mitigation plan, is done by the analyst according to his/her expertise and experience. She will decide upon the most effective group of countermeasures for mitigating the threat - the threat's mitigation plan.

Constructing a mitigation plan is a matter for experts and no simple rule for finding the correct combination of countermeasures can be given. A mitigation plan of a specific threat contains a subset of countermeasures associated with that threat which, in order to be efficient, has to be implemented as a whole. A threat mitigation plan is said to be implemented only if all of its countermeasures are implemented, otherwise it is considered as not implemented.

In order to assist with the computation of countermeasures’ contribution to mitigating the system risk, the analyst is asked to estimate the level of mitigation provided to the threat’s risk if all countermeasures in the mitigation plan are implemented.

* Identifying relevant attacker types

Associating threats with their relevant attacker types may be helpful in re-assessing the threat's scenario and probability, the exploited vulnerabilities and the potentially damaged assets. All the threat's elements should fit with the attackers’ profiles - their qualifications, motivations and accessibility to resources.

* Specifying tags

Associating threats with their relevant system tags helps validating the threat scenario mapping on top of the design documents used by the analyst. The tags properties may be used later for viewing risk and mitigation statistics grouped by specific tags e.g. system areas.

* Identifying relevant entry points

Associating threats with their relevant entry points may be done in correlation with the identification of exploited vulnerabilities, attacker types and tags associated with the threat. Each of the three last steps should be used by the analyst to validate the threat scenario and help evaluate the threat's risk and the effectiveness of the proposed countermeasures.

9. Studying the results

The following are the outcomes of the threat analysis process:

• List of the system's threats sorted by their risk level and the financial damage they cause
• Maximal financial risk caused to each asset by existing threats
• List of individual countermeasures sorted by their overall risk mitigation effect
• List of countermeasures sets AKA mitigation plans sorted by their cost effectiveness and return on investment parameter.
• Maximal financial risk caused to each asset by existing threats after all mitigation plans are implemented
• Maximal financial risk caused to each asset by existing threats after partial implementation of mitigation plans (use the 'already implemented' flag in countermeasures)
• Total financial risk in the system (including all assets)
• Total financial risk after all mitigation plans are implemented
• Total financial risk after partial implementation of mitigation plans
• Optimized mitigation steps for reducing the risk in system to an acceptable level

Reviewing these results can help the analyst improve the threat model and refine the model entities parameters. It is most productive to check how the model behaves in response to changes in the input data and run various "what if" scenarios since this provides additional insight of the systems' realities.

***

Risk Assessment of an Integrated Enterprise Call Accounting Solution (Case Study)
Beginning - Previous - Home Page

Check the Practical Threat Analysis FAQ Area