LECTURE 2 – RISK ANALYSIS

Threat/Vulnerability Assessments and Risk Analysis

All facilities face a certain level of risk associated with various threats. These threats may be the result of natural
events, accidents, or intentional acts to cause harm. Regardless of the nature of the threat, facility owners have a
responsibility to limit or manage risks from these threats to the extent possible.

Threat Assessment
The first step in a risk management program is a threat assessment. A threat assessment considers the full
spectrum of threats (i.e., natural, criminal, terrorist, accidental, etc.) for a given facility/location.
The assessment should examine supporting information to evaluate the likelihood of occurrence for each threat.
For natural threats, historical data concerning frequency of occurrence for given natural disasters such as
tornadoes, hurricanes, floods, fire, or earthquakes can be used to determine the credibility of the given threat.

Vulnerability Assessment
Once the credible threats are identified, a vulnerability assessment must be performed. The vulnerability
assessment considers the potential impact of loss from a successful attack as well as the vulnerability of the
facility/location to an attack. Impact of loss is the degree to which the mission of the agency is impaired by a
successful attack from the given threat. A sample set of definitions for impact of loss is provided below. These
definitions are for an organization that generates revenue by serving the public.

 Devastating: The facility is damaged/contaminated beyond habitable use. Most items/assets are lost, de-
stroyed, or damaged beyond repair/restoration. The number of visitors to other facilities in the organiza-
tion may be reduced by up to 75% for a limited period of time.

 Severe: The facility is partially damaged/contaminated. Examples include partial structure breach result-
ing in weather/water, smoke, impact, or fire damage to some areas. Some items/assets in the facility are
damaged beyond repair, but the facility remains mostly intact. The entire facility may be closed for a pe-
riod of up to two weeks and a portion of the facility may be closed for an extended period of time (more
than one month). Some assets may need to be moved to remote locations to protect them from environ-
mental damage. The number of visitors to the facility and others in the organization may be reduced by
up to 50% for a limited period of time.

 Noticeable: The facility is temporarily closed or unable to operate, but can continue without an interrup-
tion of more than one day. A limited number of assets may be damaged, but the majority of the facility is
not affected. The number of visitors to the facility and others in the organization may be reduced by up
to 25% for a limited period of time.

 Minor: The facility experiences no significant impact on operations (downtime is less than four hours)
and there is no loss of major assets.
Vulnerability is defined to be a combination of the attractiveness of a facility as a target and the level of
deterrence and/or defense provided by the existing countermeasures. Target attractiveness is a measure of the
asset or facility in the eyes of an aggressor and is influenced by the function and/or symbolic importance of the
facility. Sample definitions for vulnerability ratings are as follows:

 Very High: This is a high profile facility that provides a very attractive target for potential adversaries,
and the level of deterrence and/or defense provided by the existing countermeasures is inadequate.

 High: This is a high profile regional facility or a moderate profile national facility that provides an at-
tractive target and/or the level of deterrence and/or defense provided by the existing countermeasures is
inadequate.

1
  Moderate: This is a moderate profile facility (not well known outside the local area or region) that pro-
vides a potential target and/or the level of deterrence and/or defense provided by the existing counter-
measures is marginally adequate.

 Low: This is not a high profile facility and provides a possible target and/or the level of deterrence and/
or defense provided by the existing countermeasures is adequate.

RISK MANAGEMENT
Risk Analysis is a process of evaluating the probability of hazardous events
Risk: is a quantified measure of the likelihood of a threat being realised.
 The strength of an information infrastructure depends on how well information resources are managed--
what, how, where, and for whom sources of information are established and made available for reuse
 To say Risk Analysis is an important issue is an understatement. It is difficult to quantify the losses suffered
each year by businesses arising from the use and misuse of Information Systems (IS)
IS risk analysis is the process of:
 identifying potential causes of loss;
 designing and implementing controls to prevent them, and, should these fail;
 Designing and implementing controls to detect any occurrences and to minimize their effect.
Risk Analysis involves the identification and assessment of the levels of risk, calculated from the
 Values of assets
 Threats to the assets
 Their vulnerabilities and likelihood of exploitation
Risk Management involves the identification, selection and adoption of security measures justified by
◦ The identified risks to assets
◦ The reduction of these risks to acceptable levels

Risk Analysis and Management

An agreed upon framework is:-

To asses risk:-
 use a risk matrix to evaluate threat & counter-measure

2
  use a risk management model to manage threat
Responses to Risk
You respond to a risk by either:-
 Avoid it completely by withdrawing from an activity
 Accept it and do nothing
 Reduce it with security measures
 Transfer – Involves a third-party liability taking/ insurance.

DESIGNING RISK ANALYSIS

When designing a risk analysis for information systems, the following components can be considered:
 People--the information users and producers who direct, prioritize, interpret, and apply data and
information to policy problems
 Documents, databases, and other information entities that hold information and data collections
 Information processes such as collection, storage, retrieval, dissemination, communication, and display
 Information technologies--the know-how for manipulating and accessing information, including the
conceptual, statistical, and model-building structures that aggregate and process data and produce
information content, as well as mechanisms, people, and/or systems that provide intellectual, physical,
and economical access to information

Security Models
A security policy is a document that expresses clearly and concisely what the protection mechanisms are
to achieve.
A security model is a specification of a security policy:
 it describes the entities governed by the policy,
 It states the rules that constitute the policy.
There are various types of security models:
 Models can capture policies for confidentiality (Bell-LaPadula) or for integrity (Biba, Clark-Wilson).
 Some models apply to environments with static policies (Bell-LaPadula), others consider dynamic
changes of access rights (Chinese Wall).
 Security models can be informal (Clark-Wilson), semi-formal, or formal (Bell-LaPadula, Harrison-
Ruzzo-Ullman).
Model vs Policy
 A security model maps the abstract goals of the policy to information system terms by specifying
explicit data structures and techniques that are necessary to enforce the security policy. A security model
is usually represented in mathematics and analytical ideas, which are then mapped to system
3
 specifications, and then developed by programmers through programming code
 For Example, if a security policy states that subjects need to be authorized to access objects, the security
model would provide the mathematical relationships and formulas explaining how x can access y only
through the outlined specific methods
 A security policy outlines goals without regard to how they will be accomplished. A model is a
framework that gives the policy form and solves security access problems for particular situations.
Note

SECURITY DESIGN PRINCIPLES

Security is a system requirement just like performance, capability, cost, etc. Therefore, it may be necessary to
trade off certain security requirements to gain others.

Principles of Secure Design

 Design security in from the start
 Allow for future security enhancements
 Minimize and isolate security controls
 Employ least privilege
 Structure the security relevant features
 Make security friendly
 Don’t depend on secrecy for security
 Economy of mechanism- Should be sufficiently small and as simple as to be verified and implemented –
e.g., security kernel. Complex mechanisms should be correctly Understood, Modeled, Configured,
Implemented and Used
 Complete mediation- Every access to every object must be checked
 Psychological acceptability- User interface must be easy to use, so that users routinely and automatically
apply the mechanisms correctly. Otherwise, they will be bypassed
 Fail-safe defaults- Should be lack of access
 Secure the weakest link
 Compartmentalize- Minimize the amount of damage that can be done by breaking the system into units
 Use your community resources- Public scrutiny promotes trust

CONTROLS
Security controls are safeguards or countermeasures to avoid, counteract or minimize security risks
relating to personal property, or any company property.
The control environment sets the tone of an organization, influencing the control consciousness of its people. It
is the foundation for all other components of internal control, providing discipline and structure. Control
environment factors include the integrity, ethical values, and competence of the entity’s people; management’s
philosophy and operating style; and the way management assigns authority and organizes and develops its
people
Activity phase controls can be classified as follows:
• Preventative controls exist to prevent the threat from coming in contact with the weakness.
• Detective controls exist to identify that the threat has landed in our systems.
• Corrective controls exist to mitigate or lessen the effects of the threat being manifested.

4
Organizational Controls
Organizational controls are procedures and processes that define how people in the organization should perform
their duties.
Preventative controls in this category include:
 Clear roles and responsibilities. These must be clearly defined and documented so that management and
staff clearly understand who is responsible for ensuring that an appropriate level of security is implemented
for the most important IT assets.
 Separation of duties and least privileges. When properly implemented, these ensure that people have only
enough access to IT systems to effectively perform their job duties and no more.
 Documented security plans and procedures. These are developed to explain how controls have been
implemented and how they are to be maintained.
 Security training and ongoing awareness campaigns. This is necessary for all members of the
organization so that users and members of the IT team understand their responsibilities and how to properly
utilize the computing resources while protecting the organization's data.
 Systems and processes for provisioning and de-provisioning users. These controls are necessary so that
new members of the organization are able to become productive quickly, while leaving personnel lose access
immediately upon departure. Processes for provisioning should also include employee transfers from groups
within the company where privileges and access change from one level to another.
 Established processes for granting access to contractors, vendors, partners, and customers. This is
often a variation on user provisioning, mentioned previously, but in many cases it is very distinct. Sharing
some data with one group of external users while sharing a different collection of data with a different group
can be challenging. Legal and regulatory requirements often impact the choices, for example when health or
financial data is involved.
Detection controls in this category include:
 Performing continuing risk management programs to assess and control risks to the organization's key
assets.
 Executing recurrent reviews of controls to verify the controls' efficacy.
 Periodic undertaking of system audits to ensure that systems have not been compromised or misconfigured.
 Performing background investigations of prospective candidates for employment; You should contemplate
implementing additional background investigations for employees when they are being considered for
promotions to positions with a significantly higher level of access to the organization's IT assets.
 Establishing a rotation of duties, this is an effective way to uncover notorious activities by members of the
IT team or users with access to sensitive information.
Management controls in this category include:
 Incident response planning, which provides an organization with the ability to quickly react to and recover
from security violations while minimizing their impact and preventing the spread of the incident to other
systems.
 Business continuity planning, which enables an organization to recover from catastrophic events that impact
a large fraction of the IT infrastructure.
Operational Controls
Operational controls define how people in the organization should handle data, software and hardware. They also
include environmental and physical protections as described below.
Preventative controls in this category include:
 Protection of computing facilities by physical means such as guards, electronic badges and locks,
biometric locks, and fences.
 Physical protection for end-user systems, including devices such as mobile computer locks and alarms
and encryption of files stored on mobile devices.
 Emergency backup power, which can save sensitive electrical systems from harm during power
brownouts and blackouts; they can also ensure that applications and operating systems are shut down
gracefully manner to preserve data and transactions.
 Fire protection systems such as automated fire suppression systems and fire extinguishers, which are
essential tools for guarding the organization's key assets.
5
 Temperature and humidity control systems that extend the life of sensitive electrical equipment and help
to protect the data stored on them.
 Media access control and disposal procedures to ensure that only authorized personnel have access to
sensitive information and that media used for storing such data is rendered unreadable by degaussing or
other methods before disposal.
 Backup systems and provisions for offsite backup storage to facilitate the restoration of lost or corrupted
data. In the event of a catastrophic incident, backup media stored offsite makes it possible to store critical
business data on replacement systems.
Detection and recovery controls in this category include:
 Physical security, which shields the organization from attackers attempting to gain access to its premises;
examples include sensors, alarms, cameras, and motion detectors.
 Environmental security, which safeguards the organization from environmental threats such as floods and
fires; examples include smoke and fire detectors, alarms, sensors, and flood detectors.

Technological Controls
Technological controls vary considerably in complexity. They include system architecture design,
engineering, hardware, software, and firmware. They are all of the technological components used to build an
organization's information systems.
Preventative controls in this category include:
 Authentication. The process of validating the credentials of a person, computer, process, or device.
Authentication requires that the person, process, or device making the request provide a credential that
proves it is what or who it says it is. Common forms of credentials are digital signatures, smart cards,
biometric data, and a combination of user names and passwords.
 Authorization. The process of granting a person, computer process, or device access to certain
information, services, or functionality. Authorization is derived from the identity of the person, computer
process, or device requesting access, which is verified through authentication.
 Non-repudiation. The technique used to ensure that someone performing an action on a computer
cannot falsely deny that he or she performed that action. Non-repudiation provides undeniable proof that
a user took a specific action such as transferring money, authorizing a purchase, or sending a message.
 Access control. The mechanism for limiting access to certain information based on a user's identity and
membership in various predefined groups. Access control can be mandatory, discretionary, or role-based.
 Protected communications. These controls use encryption to protect the integrity and confidentiality of
information transmitted over networks.
Detection and recovery controls in this category include:
 Audit systems. Make it possible to monitor and track system behavior that deviates from expected
norms. They are a fundamental tool for detecting, understanding, and recovering from security breaches.
 Antivirus programs. Designed to detect and respond to malicious software, such as viruses and worms.
Responses may include blocking user access to infected files, cleaning infected files or systems, or
informing the user that an infected program was detected.
 System integrity tools. Make it possible for IT staff to determine whether unauthorized changes have
been made to a system. For example, some system integrity tools calculate a checksum for all files
present on the system's storage volumes and store the information in a database on a separate computer.
Comparisons between a system's current state and its previously-known good configuration can be
completed in a reliable and automated fashion with such a tool.
Management controls in this category include:
 Security administration tools included with many computer operating systems and business applications
as well as security oriented hardware and software products. These tools are needed in order to
effectively maintain, support, and troubleshoot security features in all of these products.
 Cryptography, which is the foundation for many other security controls. The secure creation, storage,
and distribution of cryptographic keys make possible such technologies as virtual private networks
(VPNs), secure user authentication, and encryption of data on various types of storage media.

6
  Identification, which supplies the ability to identify unique users and processes. With this capability,
systems can include features such as accountability, discretionary access control, role-based access
control, and mandatory access control.
 Protections inherent in the system, which are features designed into the system to provide protection of
information processed or stored on that system. Safely reusing objects, supporting no-execute (NX)
memory, and process separation all demonstrate system protection features.

Security Risk Management Practices

Comparing Approaches to Risk Management

Many organizations are introduced to security risk management by the necessity of responding to a
relatively small security incident. Whatever the incident, as more and more issues relating to security arise and
begin to impact the business, many organizations get frustrated with responding to one crisis after another. They
want an alternative to this reactive approach, one that seeks to reduce the probability that security incidents will
occur in the first place. Organizations that effectively manage risk evolve toward a more proactive approach, but
this is only part of the solution.

The Reactive Approach

Security incidents may help an organization to predict and prepare for future problems. This means that
an organization that takes time to respond to security incidents in a calm and rational manner while determining
the underlying reasons that allowed the incident to transpire will be better able to both protect itself from similar
problems in the future and respond more quickly to other issues that may arise.
The following six steps help when you are responding to security incidents quickly and efficiently:
1. Protect human life and people's safety. This should always be your first priority. For example, if affected
computers include life support systems, shutting them off may not be an option; perhaps you could logically
isolate the systems on the network by reconfiguring routers and switches without disrupting their ability to
help patients.
2. Contain the damage. Containing the harm that the attack caused helps to limit additional damage. Protect
important data, software, and hardware quickly. Minimizing disruption of computing resources is an
important consideration, but keeping systems up during an attack may result in greater and more widespread
problems in the long run. If you determine that there will be no adverse effects, or that they would be
outweighed by the positive benefits of activity, containment should begin as quickly as possible during a
security incident by disconnecting from the network the systems known to be affected. If you cannot contain
the damage by isolating the servers, ensure that you actively monitor the attacker’s actions in order to be
able to remedy the damage as soon as possible. And in any event, ensure that all log files are saved before
shutting off any server.
3. Assess the damage. Immediately make a duplicate of the hard disks in any servers that were attacked and
put those aside for forensic use later. Then assess the damage. You should begin to determine the extent of
the damage that the attack caused as soon as possible, right after you contain the situation and duplicate the
hard disks. This is important so that you can restore the organization's operations as soon as possible while
preserving a copy of the hard disks for investigative purposes. If it is not possible to assess the damage in a
timely manner, you should implement a contingency plan so that normal business operations and
productivity can continue. It is at this point that organizations may want to engage law enforcement
regarding the incident; however, you should establish and maintain working relationships with law
enforcement agencies that have jurisdiction over your organization's business before an incident occurs so
that when a serious problem arises you know whom to contact and how to work with them. You should also
advise your company’s legal department immediately, so that they can determine whether a civil lawsuit can
be brought against anyone as a result of the damage.
4. Determine the cause of the damage. In order to ascertain the origin of the assault, it is necessary to
understand the resources at which the attack was aimed and what vulnerabilities were exploited to gain
access or disrupt services. Review the system configuration, patch level, system logs, audit logs, and audit
trails on both the systems that were directly affected as well as network devices that route traffic to them.
These reviews often help you to discover where the attack originated in the system and what other resources
7
 were affected. You should conduct this activity on the computer systems in place and not on the backed up
drives created in step 3. Those drives must be preserved intact for forensic purposes so that law enforcement
or your lawyers can use them to trace the perpetrators of the attack and bring them to justice. If you need to
create a backup for testing purposes to determine the cause of the damage, create a second backup from your
original system and leave the drives created in step 3 unused.
5. Repair the damage. In most cases, it is very important that the damage be repaired as quickly as possible to
restore normal business operations and recover data lost during the attack. The organization's business
continuity plans and procedures should cover the restoration strategy. The incident response team should
also be available to handle the restore and recovery process or to provide guidance on the process to the
responsible team. During recovery, contingency procedures are executed to limit the spread of the damage
and isolate it. Before returning repaired systems to service be careful that they are not reinfected
immediately by ensuring that you have mitigated whatever vulnerabilities were exploited during the
incident.
6. Review response and update policies. After the documentation and recovery phases are complete, you
should review the process thoroughly. Determine with your team the steps that were executed successfully
and what mistakes were made. In almost all cases, you will find that your processes need to be modified to
allow you to handle incidents better in the future. You will inevitably find weaknesses in your incident
response plan. This is the point of this after-the-fact exercise—you are looking for opportunities for
improvement. Any flaws should prompt another round of the incident-response planning process so that you
can handle future incidents more smoothly.
This methodology is illustrated in the following diagram:

The Proactive Approach

Instead of waiting for incidences then respond, you minimize the possibility of the
incidences ever occurring in the first place. You make plans to protect your
organization's important assets by implementing controls that reduce the risk of
vulnerabilities being exploited by malicious software, attackers, or accidental
misuse. Each of the security risk management methodologies shares some common
high-level procedures:
1. Identify business assets.
2. Determine what damage an attack against an asset could cause to the organization.
3. Identify the security vulnerabilities that the attack could exploit.
4. Determine how to minimize the risk of attack by implementing appropriate controls.

Approaches to Risk Prioritization

There are many different methodologies for prioritizing or assessing risks, but most
are based on one of two approaches or a combination of the two: quantitative risk
management or qualitative risk management.

Quantitative Risk Assessment

In quantitative risk assessments, the goal is to try to calculate objective numeric
values for each of the components gathered during the risk assessment and cost-benefit analysis. Where you
estimate the true value of each business asset in terms of what it would cost to replace it, what it would cost in
terms of lost productivity, what it would cost in terms of brand reputation, and other direct and indirect business
values. You endeavor to use the same objectivity when computing asset exposure, cost of controls, and all of the
other values that you identify during the risk management process.

Weaknesses of this method:-

 There is no formal and rigorous way to effectively calculate values for assets and controls.
 Organizations that have tried to meticulously apply all aspects of quantitative risk management have found
the process to be extremely costly. Such projects usually take a very long time to complete their first full

8
 cycle, and they usually involve a lot of staff members arguing over the details of how specific fiscal values
were calculated.
 For organizations with high value assets, the cost of exposure may be so high that you would spend an
exceedingly large amount of money to mitigate any risks to which you were exposed. This is not realistic,
though; an organization would not spend its entire budget to protect a single asset, or even its top five assets.

Qualitative Risk Assessment

You calculate relative values in this method. Risk analysis is usually conducted through a combination
of questionnaires and collaborative workshops involving people from a variety of groups within the organization
such as information security experts; information technology managers and staff; business asset owners and
users; and senior managers. The questionnaires are designed to discover what assets and controls are already
deployed, and the information gathered can be very helpful during the workshops that follow. The information
security experts and the system administrators typically come up with controls to mitigate the risks for the group
to consider and the approximate cost of each control. Finally, the results are presented to management for
consideration during a cost-benefit analysis.
The basic process for qualitative assessments is very similar to what happens in the quantitative
approach. The difference is in the details. Comparisons between the value of one asset and another are relative,
and participants do not invest a lot of time trying to calculate precise financial numbers for asset valuation. The
benefits of a qualitative approach are that it overcomes the challenge of calculating accurate figures for asset
value, cost of control and the process is much less demanding on staff.

Comparing the Two Approaches

Both qualitative and quantitative approaches to security risk management have their advantages and
disadvantages. Certain situations may call for organizations to adopt the quantitative approach. The following
table summarizes the benefits and drawbacks of each approach:
Quantitative Qualitative
Benefits  Risks are prioritized by financial  Enables visibility and
impact; assets are prioritized by understanding of risk ranking.
financial values.  Easier to reach consensus.
 Results facilitate management of risk  Not necessary to quantify threat
by return on security investment. frequency.
 Results can be expressed in  Not necessary to determine
management-specific terminology (for financial values of assets.
example, monetary values and  Easier to involve people who are
probability expressed as a specific not experts on security or
percentage). computers.
 Accuracy tends to increase over time
as the organization builds historic
record of data while gaining
experience.
Drawbacks  Impact values assigned to risks are  Insufficient differentiation between
based on subjective opinions of important risks.
participants.  Difficult to justify investing in
 Process to reach credible results and control implementation because
consensus is very time consuming. there is no basis for a cost-benefit
 Calculations can be complex and time analysis.
consuming.  Results are dependent upon the
 Results are presented in monetary quality of the risk management
terms only, and they may be difficult team that is created.
for non-technical people to interpret.
 Process requires expertise, so
participants cannot be easily coached

9
through it.

10