Ygor Goldberg

PTA Technologies 

Practical Threat Analysis (PTA) is a structured process, supported by a software tool (PTA Professional) that assists security analysts, system developers and end user customers in assessing system risks and building the most effective risk reduction policy for their system.

By using a small number of intuitive, building blocks (threats, assets, vulnerabilities and countermeasures), PTA has found wide appeal with thousands of security analysts all over the world who use PTA on a daily basis in a large number of problem domains.

The attached customer case study describes how PTA was used to mitigate risk in a complex system based on Microsoft client-server technologies.

Introduction

The objective of the Practical threat analysis process is to understand where are the security issues, how much they can impact the organization - and the most cost-effective way of mitigating the threats; whether they are threats from viruses and phishing attacks, disclosure of trade secrets in social media or theft of sensitive information that impacts the national security.

When should threat analysis be applied?

Threat analysis is required for complex software and hardware systems that integrate disparate infrastructures and technologies - an integrated system of Windows client operating systems, Java GUI, message queuing, Linux servers and open source databases such as MySQL is not an unusual example.

Threat analysis is also be useful in identifying systems integration vulnerabilities that are incurred during an implementation of enterprise software such as Oracle Applications or SAP.

From a software security perspective, threat analysis is best used throughout the entire SDLC (Software development life cycle) starting with the design - which typically accounts for 50% of the security vulnerabilities.

The problem - security is too expensive?

The cost of implementing security countermeasures in working code or integrated systems is high - therefore the challenge is performing the threat analysis process in the most effective way and finding the cheapest countermeasures that fit the customer requirements.

The solution - keep it simple

With PTA, application domain experts can quickly build and analyze threat models and policies without endangering the project schedule and deliverables. Knowledge is retained, shared and maintained within the group and program management has total transparency to system risk without the need for additional resources.

A security audit / risk assessment can be performed in days by a small team instead of weeks by large forces of outside consultants using pre-built checklists. 

What are the existing tools?

Word-Processor + Spreadsheet Documents - The analyst has the freedom to describe threats and vulnerabilities and express her analytical qualification in a free format with no restrictions dictated by the tool. However, the overhead of the data management and the calculation tasks is very high because of the lack of a built-in ability to represent the interrelations between entities and to dynamically alter the threat model. In reality the data model required for threat modeling is far beyond the capabilities of spreadsheet programs. In addition, most of these solutions also lack the necessary reporting functionality.

Checklist-Based Tools - These are tools that provide pre-defined sets of security recommendations that are used as checklists. This approach may work for standard applications where all possible security issues are known in advance. Most of these tools have reporting capabilities and usually come in two flavors:

• Questionnaire-based in which the user is asked to answer a series of questions that reflect the embedded checklist.
• Template-based in which the user is asked to distinguish the specifics of her application from the standard checklist

Since this type of tool is based on lists of general purpose standard countermeasures, they are not flexible in supporting and encouraging the analyst to create new threat scenarios that are specific to her application.

Existing threat modeling tools

Microsoft's tool combines Schneier's Attack-Trees methodology with standard Microsoft Threat Classification and has four important limitations:

• Doesn't relate threats to financial losses to assets caused by the attacks and does not rank countermeasures by their effectiveness.
• Uses "pre-defined" cases and doesn't easily fit application-specific threat scenarios
• Doesn't provide a complete system view for threat analysis risk management.
• Limited reporting capability

Introducing Practical Threat Analysis (PTA)

The PTA process and companion software tool (PTA Professional) enable effective analysis and remediation of operational and security risks in complex software systems by an existing team.

It provides an easy way to maintain dynamic threat models that are capable of reacting to changes in system's assets and vulnerabilities. With PTA an analyst can maintain a growing database of threats, create documentation for security reviews and produce reports showing the importance of various threats and the priorities of the corresponding countermeasures

PTA automatically recalculates threats and countermeasures priorities and provides decision makers with updated action item lists that reflect the changes in threat realities. Countermeasure priorities are expressed as a function of system's assets values, degrees of damage, threat probabilities and degrees of mitigation provided by countermeasures to the threats.

A software development team should  use PTA from day one of design and throughout the system lifecycle. PTA provides intuitive and easy ways for iterative interaction between threat analysts and developers. It supports a collaborative process of evaluating threats risks and ranking the cost-effectiveness of proposed countermeasures. The team's "threat analyst" can be the program/product manager, system architect or development lead who can start being productive with the CASE tool within hours.

How does PTA relate to security standards such as HIPAA, PCI DSS, ISO 27001, FIPS 199, COBIT and others?

Some standards (such as HIPAA via the RMF (risk management framework) NIST SP-800-66 Rev. 1 require a top-down risk analysis.  Other standards (such as ISO 27001) prescribe a set of countermeasures (or controls) without delving into the underlying vulnerabilities or considering asset value. 

PTA complements such standards  by supplying the means for improving an organization's understanding of the complex interaction between threats, vulnerabilities and proposed countermeasures and taking the right purchasing and implementation decisions.

Defining a common terminology and process for threat modeling and analysis

In this section, we define a number of fundamental concepts in order to help the reader to easily understand the PTA threat model and the PTA calculative method which is described later.

Vulnerability is a weakness, limitation or a defect in one or more of the system's elements that can be exploited to disrupt the normal functionality of the system. The weakness or defect may be either in specific areas of the system, its layout, its users, operators, and/or in its associated regulations, operational and business procedures.

Countermeasure is a procedure, action or mean for mitigating a specific vulnerability. A specific countermeasure may mitigate several different vulnerabilities. In some standards documentation, countermeasures are called "controls" or "safeguards".

Asset is information, capability, an advantage, a feature, a financial or a technical resource that may be damaged lost or disrupted. The damage to an asset may affect the normal functionality of the system as well as of the individuals and/or organizations involved with the system.

Threat is a specific scenario of a sequence of actions that exploits a set of vulnerabilities and may cause damage to one or more of the system's assets.

Asset's Value is the financial value of an asset that is destroyed of stolen. Assets may be digital (software source, physical (a server) or commercial (a corporate brand).

Threat's Damage to Asset - financial value of damage caused by a specific threat to a specific asset.

Threat's Probability is the likelihood that the threat scenario will materialize. In some documentation the threat's probability is characterized by the term "Annual Occurrence Rate" (AOR).

Threat's Risk is a quantified measure of the likelihood of loss and/or damage that may be caused to one or more of the system's assets due to the specific threat. In some documentation the threat's risk is called "Annual Loss Expectancy" (ALE).

Threat's Recommended Countermeasures is a set of all the possible countermeasures that reduce the threat's risk. This set is based on the countermeasures that mitigate the threat's vulnerabilities.

Threat's Actual Countermeasures (AKA Threat's Mitigation Plan) is a subset of threat's recommended countermeasures that is assumed to be the most effective for mitigating a specific threat. The decision which of the recommended countermeasures will be included in the Threat's Mitigation Plan is made by the analyst, who uses his expertise to decide which countermeasures are most effective when applied together.

Countermeasure's Cost is the financial value that is associated with the implementation of a specific countermeasure.

Countermeasure Cost-Effectiveness is the degree of mitigation introduced by a specific countermeasure to the overall risk in the system in relation with the cost of implementing this specific countermeasure.

Additional Terms

Attacker is a person (or group of persons) that may perform the steps of a specific threat scenario.

Attacker Types are the various classes of attackers that are differentiated according to their motivation, qualification, available attack tools and their accessibility to the attacked system's resources.

Entry Points are the "doors", either in the system itself or in the human operation associated with it, that are used by attackers to penetrate the system, e.g. Web site, IVR service, SMS server, CRM representatives called by customers over the phone etc.

Area Tags are descriptive tags that are relevant to assets, threats, vulnerabilities and countermeasures. Classifying the various security entities in the threat model according to their areas improves the readability of complex threat models.

Threat analysis steps

1. Before starting a threat analysis study

As mentioned previously, 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 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.

• Functional description of the system including all typical use cases
• Architectural diagram of the system
• 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.

2. Preparing a List of System Area Tags

It is a good idea to prepare a list of relevant system' area tags that will help the analyst in mapping the various entities according to a variety of properties e.g. define area tags for each of the systems components that will enable the association of vulnerabilities with system's architecture areas

3. Identifying System's Assets

The correct mapping of assets, their financial value and the evaluation of financial loss to the system 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 a financial institution assets:

• 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. An analysts can quickly do "what-if" analysis by modifying asset values and obtain insight as o 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 step 8). It is a fact of human nature 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's 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 that are involved in system operation.

An analyst can use Google 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 that is being analyzed.

Therefore we highly recommend that the analyst should investigate the system 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 probably 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 that is associated with the step of identifying threats (step 8 below) - sophisticated vulnerabilities may be identified when building threat scenarios.

5. Identifying Countermeasures

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

6. 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 motivation as well as his qualification, available attack tools and his accessibility to the system's resources. Special care should be given to classification of 'insiders' attacker types since their activity may be very dangerous.

A good starting point may be to define an attacker type for each of the user roles that appear in the system use cases and reserve few more attacker types to hackers and other types of bandits.

7. Identifying System's 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. List of entry points may be revisited and clarified while analyzing threats.

8. Building Threat Scenarios and Mitigation Plans

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

A list of system's threats

• A map of the relationships between threats and area 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 residual system's risk data

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

9. The output of the PTA process

The PTA process provides a number of reports and management level information 

• List of system's threats sorted by their risk
• List of 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 (mitigation divided by implementation cost)
• 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 may 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 provide additional insight of the systems' realities.