IMPEDIMENTS TO SECURITY

- Obstructions that make objectives of computer security difficult to achieve

1. Attacker Intent
This is an issue that greatly complicates the prevention of threats. The basic

intent associated with an attack often cannot be determined, i.e. even if a given attack

can be observed, the motivation of the individual who caused some problem to be

introduced or exploited often cannot be identified. Cases certainly exist in which an

individual confesses to performing some malicious action but these are not
common (rare). To illustrate the problem. Consider some software development

scenario.

In C programming language, for example, it is common for programmers to

mistakenly test for the equality of two variables x and y by using “x = y”.

Unfortunately, this is actually a well-formed C statement that assigns the value of

y to x. The expression that should have been used is “x = = y”. Any malicious C

programmer can easily interchange these types of statements and expressions in order

to change the desired software functionality, and if caught, can claim that it was an

innocent mistake. When modelling, analysing and mitigating attacks it is important to

focus attention specifically on modelling, analysing and mitigating attacks that have

been introduced as a result of malicious intent.

2. Security and usability

An additional impediment to the mitigation of threats in a computer system is the inevitable
trade-off that results between security and usability. This conflict generally
occurs when the goal of information and resource sharing is combined with the goal of strict
security controls between users. The conflict can be resolved and systems do exist that deal
acceptably with both issues. If one views systems that impose minimal restrictions on
information and resource sharing as most usable, and systems that impose maximal restrictions
on information and resource sharing as the most secure, then the trade-offs must be made
between security and usability in which an increase in security results in corresponding decrease
in usability.

Usability

Security
Figure 1.1 Securities and Usability
A worthy goal in the design and development of security solutions for computer systems is to
reduce the degree to which increases in security affect the usability of a
system.

3. Retrofit
Development of security has been lagging behind other computer developments such
as hardware and software and as such is a relatively new concern. In the past years
there has been sensational publicity given to the amusing experiences of computer use
and very little attention was paid to computer security. This was to some extent okay
because the main frames or mini computers in use were operating in protected
environments such as computer rooms whose access was strictly limited to computer
operators and computer maintenance engineers and technicians. Because of the above
facts most existing systems were developed without sufficient attention to threats,
vulnerabilities and potential attacks. So in order to make an existing system secure ,
one is faced with the problem of retrofitting security into existing components,
mechanisms and environments. This problem is difficult for the same reasons that
retrofit of any requirements changes into an existing system is difficult. Consider for
example the problem of retrofitting security mechanisms into an existing operating
system. If the proposed mechanisms change an established system call interface to
the operating system kernel routines, then the existing user level applications may no
longer work. 4. Security requirements are difficult to identify

THREAT TREES

Introduction
Threats represent the highest-level security concern in any computer system. Vulnerabilities and
attacks are only concerns if they introduce the potential for certain threats to occur. As a result
one would expect that threat identification would be a
standard element of the requirements analysis activities of any computer system or project being
designed or developed. This is rarely the case, as most system design and developments efforts
do not involve a thorough analysis of threats.
The threat approach is an analytical threat derivation technique that has been designed
to assist system engineers during the security requirement analysis phase of computer system
development. This approach/technique has its origins in the use of fault trees in system
reliability engineering, where the objective is to prevent system failures due to errors. The threat
trees approach can be used to ensure that the security requirements of a system being developed,
enhanced, or assessed are complete, justifiable and well documented. Threat trees are not the
only approach or technique for identifying threats, but however this technique is recommended
and has also been used to identify threats in many practical settings including portions of the
AT&T worldwide telecommunications network and the “Star Wars” defence network

Arbitrary Threat Lists

I mentioned above that the threat trees technique is not the only technique or approach

used to identify threats. Lets examine a typically but inadequate method for

analytically deriving threats. This technique is known as the Arbitrary Threat Lists.

We will show that this technique is in adequate because it does not demonstrate

completeness of the list of identified threats. Some people can argue that the most

common means by which threats can be identified during system design,

development, or use involves a random, unstructured process often referred to as an

arbitrary threat list process. This approach is said to be random and unstructured
because the process is typically characterised by system developers either

brainstorming a collection of potential threats or allowing such a collection to arise

gradually as they are noticed during a discussion or even during normal system

operation. For example, suppose that a group of system developers wishes to identify

a set of possible threats in a hospital’s patient and medical information processing and

storage system. One might expect that this group would follow a brainstorming

process as a means for identifying possible threats to that hospital’s system.

The results of a typical brainstorming session might produce the following:

(i) Patient’s medical information is corrupted

(ii) Billing information is corrupted

(iii) Confidential patient information is disclosed

(iv) Internal schedules are compromised

(v) Confidential patient information is not available.

As time progresses (during the development or continued operation of the system),

one can imagine additional threats being noticed and added to the list. However the

threat identification process will remain unstructured. This is to say the arbitrary

threat process is likely to exhibit the following unfortunate characteristics:

Dubious Completeness.

Since the process for identifying threats is unstructured, one cannot be sure that

the complete set of potential threats has ever been identified, for example one

would imagine many different threats being added to this list. It would appear that

the best lists would result only when the people with the most experience spend a

great deal of time trying to identify potential threats.

Lack of Rationale
The ad hoc nature of the process prevents one from identifying suitable rationale for each
perceived threat. In the hospital example, justifying each of the identified threats would likely to
be done by identifying previous instances in which such a threat had occurred. However this
might prevent any novel, previously unreported threats from
being included.

Possible inconsistencies
Since threats are identified independent of each other in this approach, it is possible that a set of
threats could include potential statements that are contradictory or redundant. For example the
statement above that correspond to “Confidential patient information is disclosed” and
“Confidential information is not available” appear to be in conflict.

Threat Trees

To offset some of the shortcomings of the arbitrary threat list process, a more structured
technique for identifying threats has been developed. The threat tree is said to be structured
because it starts with a general abstract description of the complete set of threats that exists for a
given system and then introduce detail in an iterative manner, refining the description carefully
and gradually. This approach/technique is called the first abstract threat description is generally
depicted as the root of a tree and the next level of corresponding refinements corresponds to a
collection of new nodes connected to a tree. Each of these nodes in turn becomes the root of a
different sub tree. Eventually, each leaf of each sub tree will provide a description that can be
used for an arbitrary threat list. A side benefit of this technique/approach is that the resulting
analysis documents the rationale for each identified threat.
 Threat
subthreat

Figure 1.2 Structure of a Threat Tree

Please note that the top of the threat tree is labelled Threat, which is not to imply that a separate
threat tree is required for each threat. The top of the tree can be labelled with some generalised
description of all threats that are present on a given system if a single tree is desired. The most
critical notion related to threat tees is that at each level of refinement for a given node, the set of
new connected nodes must maintain demonstrable completeness so that one can be sure that
nothing has been missed.

Example: Hospital Computer System

To illustrate threat trees in more detail, suppose that we use the hospital computer system
example, with the intention of identifying threats using out threat tree technique. The term HCST
(Hospital Computer System Threat) as the general, abstract definition of all the threats that we
wish to identify. HCST will simply provide a label fro the root of out threat tree. The first level
of refinement in our example will split the set of threats into those that correspond to patient
medical information (labelled PMH) and those that do not (labelled NPMH) (see figure 1.3)

HCST

PMH NPMH
 Figure 1.3 Medical Threat Tree

For the threats that correspond to patient medical information, we introduce a subsequent
refinement that splits threats into those that are life threatening
(labelled LT) and those that are not (labelled NLT). Each of these is then portioned into the
disclosure (D), integrity (I) and denial of service (DOS) threats. The resultant subthreat tree is
shown in figure 1.4

PMH

LT NLT

D I DOS D I DOS

Figure 1.4 Patient Threat Subtree

Returning up to the NPMH node, we can introduce a refinement that splits the relevant threats
into billing threats (B) and nonbilling (NB) threats. These can each then be portioned into the
threats that are introduced during the development of a system by a malicious developer
(MDEV) and those that are not (NMDEV).

NPMH

B NB

MDEV NMDEV MDEV NMDEV

 Figure 1.5 Non Patient Medical History Subtree

The key notion here is that any conceivable threat that can occur on this hospital computing
system fall into one of the categories represented by the nodes in the threat tree. The longer one
follows this refinement process, the more detailed the deeper nodes become and the more likely
it becomes that a specific threat will be defined explicitly in the tree. This means that all the
threats identified in the arbitrary list process illustration would appear under one of the nodes of
the threat tree just presented.

HCST

PMH NPMH

LT NLT B NB

D I DOS D I DOS MDEV NMDEV MDEV NMDEV

“Patient’s medical “Confidential patient

information is information is disclosed”
corrupted” “Billing information
is corrupted”

“Confidential
patient information is not
available”
“Internal schedules
are compromised”
Figure 1.6 Threat Tree for Hospital System

Using Threat Trees for Calculation

One useful property of a threat tree involves first associating certain types of values with each of
the nodes in a threat tree. These values might be probability of occurrence, potential damage if
the threat actually occurs, level of effort required to enact the threat, and so on. Once such values
have been associated with the various nodes in the tree, logical or arithmetic calculations can be
performed to obtain information about the threats represented in the tree. A threat tree could be
developed using a relationship between the threat and subthreats that is disjunctive, conjunctive
or based on other relation. A disjunctive relation is based on the logical OR relation in which the
threat can occur only if one of the subthreats could occur (one subthreat OR the other)
Threat

OR
Subthreat Subthreat
Figure 2.1 Disjunctive
A conjunctive relation, is based on the logical AND relation in which a threat can occur only if
all of the subthreat occur (one subthreat AND the other).

Threat

AND

Subthreat Subthreat
Figure 2.2 Conjunctive
Suppose one wishes to create a threat tree of the integrity threats to some system, and suppose
further that this tree has two subnodes with a disjunctive (OR) relationship with respect to the
integrity threat node. So it means that in order to enact the integrity threat represented at the node
of the tree, one must enact either of the subnodes. If one node has its level of effort (by an
adversary) required to enact a threat listed as HIGH, and one subnode has its effort listed as
MODERATE, then by common sense, we can conclude that an attacker would be more likely to
attempt the MODERATE (easier) threat. We know this since the relation is based on the OR
relation and either subthreat would be suitable for carrying out the higher threat. This allows us
to conclude that the effort for the higher-level integrity threat would be
MODERATE as well.

Integrity Threat
(Effort = MODERATE)

Subnode Subnode
Threat Threat
(Effort = MODERATE) (Effort =HIGH)
Figure 2.3 Threat Three as a Basis for Calculation
Note that this conclusion would be different if the relationship between the nodes of the tree
were conjunctive (AND). In such a case, the level of effort for the two subthreats would have to
be combined into some measure that reflects as a MODERATE and a HIGH subthreat. Many
types of considerations have to be taken into account in such a calculation. For example,
although the level of effort for some threat might be estimated as MODERATE (as in the above
cited example), the likelihood of being caught for that subnode might be higher than for the other
subnodes. This might cause the attacker to attempt to enact one of the HIGH threats instead.
This illustrates the type of analysis one must perform in order to use a threat tree as the basis for
performing calculations on threats.
Using Threat Trees To Support System Security Engineering
.

Specify system
Architecture

Identify Threats, Identify and Install

Vulnerabilities, Safeguards
attacks

Estimate
Component Risk Prioritise
Vulnerabilities

Risk is Acceptably Low

Figure 2.4 System Security Engineering Process

Threat Trees can be used to support the performance of system security engineering by providing
a structured means for documenting and organizing these estimates and calculations, for
example, if nodes of a threat tree are associated with all available factor estimates (e.g. criticality
and effort) then risk calculations can be performed easily for a given node by considering all
relevant estimates of child nodes and the logical relationship established between these child
nodes. For example, one could determine the risk associated with the node of a tree by
determining the maxima risk for any subnode if a disjunctive relation were established between
nodes.
Figure 2.5 shows a simple illustration of how a threat tree could be helpful in the performance of
a system security engineering analysis to determine the optimal placement of security
protections.
 Threat

Subthreat A Subthreat B
Criticality = 4 Criticality = 5
Effort = 2 Effort = 1
Risk = 2 Risk = 5
Figure 2.5 Threat Tree For System Security Engineering
The two OR –related subnodes above depict subthreats with estimated criticality for the
resources affected by the subnodes as well as estimated levels of effort for attackers to cause
subthreats to occur. (The integers are used to simplify comparisons of the estimates). In the
above example risk is assumed to be criticality divided by effort. One might conclude from the
threat tree and associated estimates that if money is only available to mitigate one of the
subthreats, then clearly, subthreat should be selected since it represents a much greater risk.
Suppose that, in fact such a decision is made and suitable impediments are installed to increase
the level of effort for subthreat B attackers to an estimate of 5. This would cause the estimated
risks to be adjusted accordingly as shown below in figure 2.6

Threat

Subthreat A Subthreat B
Criticality = 4 Criticality = 5
Effort = 2 Effort = 5
Risk = 2 Risk = 1
Figure 2.6 Adjusted Risk Estimates
If additional money becomes available to increase security, then the priority of application
changes. Now the risk associated with subthreat A is greater and available money should be
allocated toward mitigating this subthreat.

Example: Aircraft Computer System

The use of threat trees in support of the system security engineering process can be
illustrated in the context of a simple example avionics system. Suppose that the
computerised portion of an aircraft includes only a main controller, a position sensor, a
temperature sensor, a flight recorder and connections to electromechanical servos that
control the engine and cooling system. This highly simplified view of an aircraft is shown in
figure 2.7 below.

Temperature
Sensor Servo to
Engine
Position Main Controller
Sensoe
Servo engine
Flight
Recorder

Figure 2.8 Simplified Aircraft Computer System

We follow the steps of system security engineering process to this example, which are:
(i) Specify system architecture
(ii) Identify Threats, Vulnerabilities, Attacks
(iii) Estimate Component Risk
(iv) Prioritise Vulnerabilities
(v) Identify and Install Safeguards
(vi) Iteration
Specify System Architecture
For the purposes of this simplified example, we will assume that the components of the
system are the following: temperature sensor (ts), position sensor (ps), flight recorder (fr),
main controller (mc), servo to engine (e), servo to cooling the system (cs), and all
interconnections (int). In other words these are the components of the system that must be
protected and that will be subject of our assessment. Roughly, the priority of various
components can be estimated as follows: Main controller (top priority), servo to engine
(high), all interconnections (high), position sensor (high), temperature sensor (moderate),
servo to cooling system (moderate), and flight recorder (low). These are estimated based on
their relation to the system mission of successful flight.

Identify Threats, Vulnerabilities, and Attacks.

The threats, vulnerabilities, and attacks to the system can now be identified using the threat
tree technique. The diagram below shows a possible decomposition of threats to the
components of the system.

Threats to System Components

Denial of service
Integrity Disclosure
fr
ts ps mc cs int
e
dev opn dev opn

Figure 2.9 Threats to System Components

The above diagram only shows a possible decomposition of threats to the components of the
system but does not show the specific vulnerabilities and attacks that would result from further
decomposition of these threats.

The denials of service threats are decomposed into the threats to the system components, and
threats to the flight recorder and engine servo are decomposed into the development and
operation threats. The two paths shown as dotted lines in the above diagram will serve to
illustrate system security engineering process.

Estimate Component Risk

An appropriate risk formula can be used to identify the highest risk areas of the system and the
main controller and the connection between the main controller and the servo to the engine are
likely to be the highest risk areas. Assume that the formula used is estimated gain to an intruder
divided by estimated effort required of an intruder. If these estimates are made using a scale of 1
to 10 then it is possible that the estimates and associated risk calculations would most likely to be
as shown below for these two paths. G denotes estimated gain, E denotes estimated effort,
and R = G/E denotes risk.

Threats to Computer System

Denial of Service G = 10, E = 2, R =5

fr

opn e
G = 5, E = 5, R = 1 opn G = 10, E = 2, R = 5

Figure 3.0 Risk Calculations for Two Paths

Threat trees generally depict gain, effort and risk estimates for intermediate nodes as

the maximum of the respective estimates for the sub nodes. The diagram above

shows that potential gain to an intruder for denial of service attacks to the engine is

greater and requires less effort than denial of service attacks to the flight recorder.

As a result, the denial of service risk associated with the engine is greater than that of the flight
recorder.
Prioritise Vulnerabilities
The vulnerabilities and attacks to the highest risk components would likely be assigned highest
priority and this means that vulnerabilities associated with denial of service attacks to the engine
would certainly be associated with a higher priority than vulnerabilities associated with denial of
service attacks to the flight recorder. In most cases, this prioritisation follows the risk estimates
directly. In cases where different components are associated with the same risk, the other
considerations related to available cost, resources, and other practical concerns may be used.