Practical Threat Analysis for the Software Industry

{LANG_NAVORIGIN} Vulnerability Management Risk Assessment
Ygor Goldberg 01/10/2005



Threat Analysis Steps

Prerequisites
The threat analyst identifies system vulnerabilities, predicts even the most hypothetical threat scenarios and evaluates threat probability and risk to enable prioritizing 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 vulnerabilities and the building of possible 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
• Architectural diagram of the system and documentation for various system modules

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

Preparing a List of Tags
It is a good idea to prepare a list of relevant tags that will help the analyst in classifying the various threat model entities according to their specific properties e.g. define tags for each of the system’s components or tags which describe the various areas in the system’s architecture.

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

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 information about institution’s clients
• Clients’ money
• Private keys used for authentication of transactions
• Master key used for generating private keys

The accurate assessment of the financial value of the damage that may be caused by losing each of the above assets will enable the correct classification of assets according to their importance to the institution 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 texts 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 trust of the shoppers 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 periodically checked by non IT personnel e.g. the company’s CFO, marketing officers and legal consultants. Analysts can quickly do a “what-if” analysis by modifying asset values and obtaining an insight on the model’s accuracy and completeness.

In practice, it is often easier for the analyst to identify system assets via the process of 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.

Identifying System Vulnerabilities – the real ones
Identifying vulnerabilities requires the analyst to 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 system which is being analyzed.

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 business managers of the system to discover the real vulnerabilities that are unique to the system and that 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 the 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.

Identifying Countermeasures

Identifying countermeasures has two outputs:

• A list of countermeasures that protect vulnerabilities. The list includes the implementation cost of each countermeasure and the countermeasure's relevant tags. If the countermeasure is already applied it should be marked as 'already implemented' to enable producing updated statistics of the current risk level in the system.
• 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.

Classification of Potential Attacker Types

Classification of the relevant attacker types may be helpful in focusing 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 type’s data includes the understanding of his/her motivation as well as his qualification, available attack tools and her accessibility to the system’s resources. Special care should be given to the classification of ‘insiders’ attacker type since their activity may be very 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 bandits.

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 while analyzing threats.

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 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 threat which is constructed. 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) which includes the actions taken by the attacker and the description of the impact the threat has on the system. The description will be used as reference for the following steps and will be refined during the process.

Identifying the damaged assets and the damage levels
Identify the list of assets that may be damaged by the threat and the maximal damage level that may be caused by the threat to each of the assets. That is needed in order to enable the automatic calculation of the total damage (the financial losses) that may be caused to the system if the threat materializes.

Setting the threat's probability
Threat's probability is the likelihood of the occurrence of a specific threat scenario at least once a year. Its value may be in a range of 0 - 1 where 0 means that threat will never materialize and 1 means that threat will definitely materialize at least once 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 scenario is important for building the threat’s mitigation plan since the identified vulnerabilities define the collection of proposed countermeasures available for mitigating the threat. When vulnerabilities are identified, the list of proposed countermeasures is populated automatically.

Building a mitigation plan for the threat
Building a mitigation plan involves the selection of the most effective combination of countermeasures from the list of all the proposed countermeasures for the threat. The decision which of proposed countermeasures will 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. Moreover, the actual mitigation provided by all countermeasures in the mitigation plan is not necessarily equal to the sum of the individual mitigation provided by each of the countermeasures. In order to assist with the computation of countermeasures' contribution to mitigating the threat's risk, the analyst is asked to a) estimate the mitigation level each countermeasure provides to the threat as if it is the only countermeasure in the mitigation plan and b) estimate the total level of mitigation provided to the threat's risk by all countermeasures in the mitigation plan.

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's tags may be helpful for validating the mapping of the threat scenario 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 vulnerabilities exploited by the threat and the attacker types and the tags associated with the threat. Each of the three last steps should be used by the analyst to validate the threat scenario and to help in evaluating the threat's risk and the effectiveness of the proposed countermeasures.

Learning the results
The following are the outcomes of the threat analysis process:

• List of the system's threats sorted by their risk
• List of the system's threats sorted by the financial damage they cause
• List of individual countermeasures sorted by their overall risk mitigation effect
• List of countermeasures sorted by their cost effectiveness
• Maximal financial risk caused to each asset by existing threats
• 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 including all assets
• Total financial risk after all mitigation plans are implemented
• Total financial risk after partial implementation of mitigation plans

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

[1]RiskWatch, Callio Secura, COBRA
[2]CRAMM
[3]Microsoft Threat Modeling Tool
[4]Attack Trees by Bruce Schneier
[5]STRIDE and DREAD

© PTA Technologies 2005
www.ptatechnologies.com
+972 3 5443085















Your IP address will be sent with this e-mail

From e-mail to e-mail