23
2
Assessing Risk
Risk has been defined as “the possibility of incurring loss as a
result of inadequate or failed preparation to respond to a
perceived or potential threat.” A threat is the potential for a
particular threat-source [1] to successfully exercise a vulnera-
bility. A threat-source is defined as any circumstance or
event with the potential to cause harm to a system. Com-
mon threat-sources can be natural, human, or environmen-
tal, and can include the following:
Natural threats: floods, earthquakes, tornadoes, land-
slides, avalanches, electrical storms, and other such
events
Human threats: events that are either enabled by or
caused by human beings, such as unintentional acts
(inadvertent data entry) or deliberate actions (network
based attacks, malicious software upload, unauthorized
access to confidential information)
Environmenttal threats: long-term power failure, pollu-
tion, chemicals, liquid leakage
2.1 Determining Threats
A threat-source does not present a risk when there is no vulnerability that
can be exploited. In assessing threat-sources, it is important to consider all
potential threat-sources that could cause harm to a system or its processing
environment. Although the threat statement for a system located in the
desert may not include natural flood because of the low likelihood of such
an event occurring, environmental threats such as a bursting pipe can
24 2.1 Determining Threats
quickly flood a computer room and cause damage to an organization’s
assets and resources. Humans can see threat-sources through intentional
acts, such as deliberate attacks by malicious persons or disgruntled employ-
ees, or unintentional acts, such as negligence and errors. A deliberate
attack can be either:
A malicious attempt to gain unauthorized access to an IT system
(e.g., via password guessing) in order to compromise system and data
integrity, availability, or confidentiality; or
A benign, but nonetheless purposeful, attempt to circumvent system
security. One example of the latter type of deliberate attack could be a
programmer writing a Trojan horse program to bypass system secu-
rity in order to get the job done.
The objectives of a Threat Risk Assessment (TRA) are to identify sensi-
tive system assets; to identify how these assets can be compromised by
threat agents; to assess the level of risk the threat agent poses to an asset; and
to recommend how to proceed in the life cycle. The TRA occurs at various
stages of the system development life cycle. In the TRA analysis, vulnerabil-
Figure 2.1
Vulnerability
Analysis Chart.
2.1 Determining Threats 25
Chapter 2
ities and existing safeguards are identified and examined to determine the
ways an asset can be compromised by a threat agent. The level of risk to the
asset is a measure of the likelihood of the compromise and the conse-
quences of the compromise, where the consequences are a function of the
asset’s sensitivity.
An assessment of the adequacy of existing or proposed safeguards that
protect system assets forms part of the TRA process. Where the assessment
of safeguards indicates that certain vulnerabilities are not appropriately off-
set, appropriate additional safeguards are recommended in order to reduce
the risk to an acceptable level. Conversely, if safeguards are no longer appro-
priate, their removal is recommended. If additional safeguards cannot
reduce the risk to an acceptable level for an acceptable cost, the risk may be
avoided or transferred by moving the location of the system or removing
the asset that is at risk.
The TRA process provides the system manager with an appreciation of
the security status of the system. The TRA recommendations will suggest
either possible changes to the system design or acceptance of the risk. Each
option will have an associated cost: that is, risk, time, money, people, and
equipment. Management must choose the most appropriate option, based
on the likelihood of the undesirable or intolerable consequences of a threat
scenario occurring.
A vulnerability is defined as a flaw or weakness in system security pro-
cedures, design, implementation, or internal controls that, if exercised
(accidentally triggered or intentionally exploited), would result in a security
breach or a violation of the system’s security policy. In determining the like-
lihood of a threat, one must consider threat-sources, potential vulnerabili-
ties, and existing controls. The analysis of the vulnerabilities associated with
the system environment is intended to develop a list of system vulnerabili-
ties (flaws or weaknesses) that could be exploited by the potential threat-
sources. Such threats may include people, processes, systems, or external
events. To determine the likelihood of a potential adverse event, threats
must be analyzed in conjunction with the potential vulnerabilities and the
controls already put in place for the organization. An example vulnerability
analysis chart (see Figure 2.1) is useful in performing this exercise.
The threat statement, or the list of potential threat-sources, should be
tailored to the individual organization and its processing environment (e.g.,
end-user computing habits). In general, information on natural threats
(e.g., floods, earthquakes, storms) should be readily available. Known
threats have been identified by many government and private sector organi-
zations. Intrusion detection tools also are becoming more prevalent, and
26 2.1 Determining Threats
government and industry organizations continually collect data on security
events, thereby improving the ability to realistically assess threats.
Impact refers to the magnitude of harm that could be caused by a threat
actually taking place. The level of impact is governed by the potential mis-
sion impacts and in turn produces a relative value for the assets and
resources affected. If it is determined that risks are to be reduced, security
requirements can be defined in terms of the security functionality required
to reduce the risk. It should be possible for the functionality requirement to
be satisfied by more than one safeguard or set of safeguards. Technical and/
or nontechnical safeguards must be selected to meet the functional security
requirements and to adequately mitigate the identified risks. Nontechnical
safeguards include the establishment of the administrative security struc-
ture; personnel and physical security measures; and the establishment and
documentation of security procedures and practices. The cost of safeguards,
in terms of expense, system performance, user acceptance, schedules and
other potential impacts, must be balanced against the resulting reduction of
risk. To support this type of cost-benefit analysis, safeguards must be speci-
fied in parallel with design of the system.
Once the system security requirements have been identified and safe-
guards have been selected, the IT system can be constructed and imple-
mented. Security acceptance procedures ensure that the risk of operating
the system as it has been implemented is acceptable. These procedures are
usually referred to as risk certification and accreditation procedures.
2.1.1 Risk Certification
Risk certification is a comprehensive assessment of the technical and non-
technical security features of an IT system that establishes the extent to
which the system satisfies the specified security requirements. It should
include:
1. Validation that security safeguards meet security requirements
and security policy
2. Testing of security safeguards
3. Evaluation of technical security measures in terms of functional-
ity and assurance
4. Verification of physical, personnel, and procedural safeguards
5. Comparison of the system residual risk with the target risk
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.