Risk Management L2

RCA Practice UCF
Risk Management
Level 2
2013
UCF: Risk Management

Page | 2 Confidential

Table of Contents
Risk Management Overview ................................................................................................................. 5
What is IT Risk Management? .......................................................................................................... 5
What is Risk Assessment? ................................................................................................................. 6
What to do with Risk? ......................................................................................................................... 6
Risk Avoidance ................................................................................................................................. 6
Risk Transfer ..................................................................................................................................... 6
Risk Mitigation .................................................................................................................................. 7
Risk Acceptance ............................................................................................................................... 7
Importance of Risk Management .................................................................................................... 8
Integration of Risk Management in System Development Life Cycle (SDLC) .................... 8
Definitions and Roles ....................................................................................................................... 10
CIA Triad................................................................................................................................................... 12
Risk Assessment Scope........................................................................................................................ 14
Asset Identification ............................................................................................................................... 15
Vulnerability ............................................................................................................................................ 16
Classification: ..................................................................................................................................... 16
Vulnerability Sources ........................................................................................................................ 16
Vulnerability Identification and Removal ................................................................................... 17
Threat ........................................................................................................................................................ 18
Threat Classification ......................................................................................................................... 18
Threat Management .......................................................................................................................... 19
Risk Management Process .................................................................................................................. 20
First Step towards Risk Management: Risk Assessment ....................................................... 20
Qualitative Risk Assessment ...................................................................................................... 21
Quantitative Risk Assessments ................................................................................................. 22


Quantitative Vs. Qualitative ........................................................................................................ 24
Threat Risk modeling to Secure Web Application................................................................ 25
Risk Assessment Methodologies. ............................................................................................. 30
Risk Assessment Process ............................................................................................................ 36
Second Step towards Risk Management: Risk Mitigation...................................................... 53
Risk Mitigation Strategy ............................................................................................................... 53
Approach for Control Implementation .................................................................................... 55
Control Categories ........................................................................................................................ 57
Cost-Benefit Analysis ................................................................................................................... 58
Residual Risk ................................................................................................................................... 59
Third Step towards Risk Management: Evaluation, Assessment and Monitoring .......... 60
Risk Review and Monitoring ....................................................................................................... 60
Risk Reporting ................................................................................................................................ 61
Keys for Success ............................................................................................................................ 62
Vendor Risk Assessment ..................................................................................................................... 63
Risk based Auditing .............................................................................................................................. 64
Appendix A: Sample Interview Questions ...................................................................................... 67
Appendix B: Risk Assessment Report ............................................................................................. 68



Table of Figures
Figure 1: CIA Triad ................................................................................................................................ 12
Figure 2: Risk Management Process ................................................................................................ 20
Figure 3: Primary Steps towards Risk Assessment...................................................................... 39
Figure 4: Gather System Related Information ............................................................................... 39
Figure 5: Methods for Identifying System Vulnerabilities ......................................................... 46
Figure 6: Control Methods, Control Categories and the Control Analysis Technique ..... 47
Figure 7: Risk Mitigation Chart ......................................................................................................... 54
Figure 8: Risk Mitigation Methodology ........................................................................................... 56
Figure 9: High-level Overview of Control Categories ................................................................ 57
Figure 10: Keys for Success................................................................................................................ 62



Risk Management Overview
Organizations depend on information system to successfully carry out their missions and
business functions. Information systems can include very diverse entities ranging from office
networks, financial and personnel systems to very specialized systems (e.g.,
telecommunications systems, industrial/process control systems, and environmental control
systems). Information systems are subject to serious threats that can have adverse effects on
organizational operations , organizational assets, individuals, and the Nation. The risk
management program must have a specific purpose; otherwise, it will be difficult to determine
whether the program is successful. Example objectives: reduce number of industrial accidents,
reduce the cost of insurance premiums, or reduce the number of stolen assets. If objectives are
measurable and specific, then the individuals who are responsible for the risk management
program can focus on its objectives in order to achieve the best possible outcome. Risk
management is the identification, assessment, and prioritization of risks followed by
coordinated and economical application of resources to minimize, monitor, and control the
probability and/or impact of unfortunate events or to maximize the realization of opportunities.
Risks can come from uncertainty in financial markets, project failures, legal liabilities, credit
risk, accidents, natural causes and disasters as well as deliberate attacks from an adversary.
The risk management program, like other activities in the business, requires resources to
operate. This will include a budget for salaries as well as for workstations, software licenses,
and possibly travel. The various risk management activities like asset identification, risk
analysis, and risk treatment, along with some general activities like recordkeeping, should be
written down.
What is IT Risk Management?
IT Risk Management is the application of risk management to Information technology context in
order to manage IT risk, i.e.:

Definition of risk management:

The business risk associated with the use, ownership, operation, involvement, influence and
adoption of IT within an enterprise. IT risk management can be considered a component of
a wider Enterprise risk management system.

Risk management is the process of identifying vulnerabilities and threats to the information
resources used by an organization in achieving business objectives, and deciding what
countermeasures, if any, to take in reducing risk to an acceptable level, based on the value
of the information resource to the organization.


What is Risk Assessment?
A risk assessment is the process of identifying, prioritizing, and estimating information security
risks. Assessing information security risk requires the careful analysis of threat and
vulnerability information to determine the extent to which circumstances or events could
adversely impact an organization and the likelihood that such circumstances or events will
occur.
A risk assessment methodology is a risk assessment process, together with a risk model,
assessment approach, and analysis approach. Risk assessment methodologies are defined by
organizations. Selection of Risk Assessment methodology depends on: (i) the criticality and/or
sensitivity of the organizations core missions and business functions including the supporting
mission/business processes and information systems; (ii) the maturity of the organizations
mission/business processes (by enterprise architecture segments); or (iii) the stage of
information systems in the system development life cycle.
What to do with Risk?
Following are the four basic principles for handling risk:
Risk Avoidance
Risk avoidance is described as an informed decision on not involving in activities that lead to
the possibility of the risk being realized. To avoid the risk by eliminating the risk cause and/or
consequence, Risk avoidance includes not performing an activity that could carry risk. An
example would be not buying a property or business in order to not take on the liability that
comes with it. Avoidance may seem the answer to all risks, but avoiding risks also means losing
out on the potential gain that accepting (retaining) the risk may have allowed. Not entering a
business to avoid the risk of loss also avoids the possibility of earning profits.

Risk Transfer
Risk transfer is the practice of passing on the risk in question to another entity. However,
transferring risk is accompanied by a cost. E.g. purchase of insurance policy to cover loss due
to fire or flood.
A company may decide not to enable online business just because of the risks associated
with e-commerce or online transaction processing. However avoidance in such case can
also limit the companys ability to increase its business reach and negatively affect its
global expansion.


e.g.2: a personal injuries insurance policy does not transfer the risk of a car accident to the
insurance company. The risk still lies with the policy holder namely the person who has been in
the accident. The insurance policy simply provides that if an accident (the event) occurs
involving the policy holder then some compensation may be payable to the policy holder that is
commensurate to the suffering/damage.

Risk Mitigation
Risk Mitigation is the application of appropriate techniques/measures for either elimination of
risk or reduces the likelihood of an occurrence, its consequences, or both. For example, to
lessen the risk of exposing personal and financial information that is highly sensitive and
confidential; organizations put countermeasures in place. We will go through Risk Mitigation in
details in this document.

Risk Acceptance
Risk acceptance is used in risk management to describe an informed decision to accept the
consequences and likelihood of a particular risk. The decision to accept risk should not be
taken without appropriate information to justify the decision. The cost versus benefit, the
organization's willingness to monitor the risk long term, and the impact it has on the outside
world's view of the organization must all be taken into account when deciding to accept risk.
A company doing online business may decide to take an Internet Banking or e-commerce
related insurance policy.
A company doing online business may decide to put countermeasure such as encryption,
intrusion detection/prevention systems, periodic web application assessment etc,to
prevent/deter malicious outsiders from accessing highly sensitive information.


Importance of Risk Management
Risk management process allows IT Managers in an organization to balance the operational and
economic costs of protective measures and achieve gains in mission capability by protecting the
IT systems and data that support their organizations missions.
The head of an organizational unit must ensure that the organization has the capabilities
needed to accomplish its mission. These mission owners must determine the security
capabilities that their IT systems must have to provide the desired level of mission support in
the face of real world threats.

Integration of Risk Management in System Development Life Cycle (SDLC)
Effective risk management must be totally integrated into all the phases of SDLC. In some
cases, an IT system may occupy several of these phases at the same time. However, the risk
management methodology is the same regardless of the SDLC phase for which the assessment
is being conducted. Risk management is an iterative process that can be performed during each
major phase of the SDLC.
Table Integration of Risk Management into the SDLC portrays indicative characteristics of each
SDLC phase and indicates how risk management can be performed in support of each phase.
An organization doing online business will be confronted with risks identified during the
course of a risk assessment. These risks can be prioritized by high, medium, and low
impact to the organization. The organization notes that to mitigate or transfer the low-
level risks, significant costs could be involved. Mitigation might involve the hiring of
additional highly skilled personnel and the purchase of new hardware, software, and
office equipment, while transference of the risk to an insurance company would require
premium payments. The organization may note that an insignificant impact would occur if
any of the reported low-level threats were realized. Therefore, the organization might
forego the costs and accept the low level risk.
Most organizations have tight budgets for IT security; therefore, IT security spending must
be reviewed as thoroughly as other management decisions. A well-structured risk
management methodology, when used effectively, can help management identify
appropriate controls for providing the mission-essential security capabilities.


SDLC phases Phase Characteristics Support from Risk
Management Activities
Phase 1
Initiation
The need for an IT system is
expressed and the purpose and
scope of the IT system is
documented
Identified risks are used to support the
development of the system requirements,
including security requirements, and a
Security concept of operations (strategy).
Phase 2
Development or
Acquisition
The IT system is designed,
purchased, programmed, developed,
or otherwise constructed
The risks identified during this phase can be
used to support the security analyses of the
IT system that may lead to architecture and
design tradeoffs during system development.
Phase 3
Implementation
The system security features should
be configured, enabled, tested, and
verified
The risk management process supports the
assessment of the system implementation
against its requirements and within its
modeled operational environment. Decisions
regarding risks identified must be made prior
to system operation.
Phase 4
Operation or
Maintenance
The system performs its functions.
Typically the system is being
modified on an ongoing basis
through the addition of hardware and
software and by changes to
organizational processes, policies,
and procedures
Risk management activities are performed for
periodic system reauthorization (or
Reaccreditation) or whenever major changes
are made to an IT system in its operational,
production environment (e.g., new system
interfaces).
Phase 5
Disposal
This phase may involve the
disposition of information, hardware,
and software. Activities may include
moving, archiving, discarding, or
destroying information and
sanitizing the hardware and software
Risk management activities are performed for
system components that will be disposed of
or replaced to ensure that the hardware and
software are properly disposed of, that
residual data is appropriately handled, and
that system migration is conducted in a
secure and systematic manner.
Table 1: Integration of Risk Management into the SDLC



Definitions and Roles
Risk management is a management responsibility. This defines specific job titles, together with
their respective roles and responsibilities in the risk management program. In a risk
management program with several individuals, it should be clear as to which individuals or job
titles are responsible for which activities in the program. Following table describes the key roles
of the personnel who should support and participate in the risk management process.
Key Roles Responsibilities
Senior
Management
Senior management, under the standard of due care and ultimate responsibility for
mission accomplishment, must ensure that the necessary resources are effectively
applied to develop the capabilities needed to accomplish the mission. They must
also assess and incorporate results of the risk assessment activity into the decision
making process. An effective risk management program that assesses and mitigates
IT-related mission risks requires the support and involvement of senior
management.

Chief Information
Officer (CIO)
The CIO is responsible for the agencys IT planning, budgeting, and performance
including its information security components. Decisions made in these areas
should be based on an effective risk management program.

System and
Information
Owners
The system and information owners are responsible for ensuring that proper
controls are in place to address integrity, confidentiality, and availability of the IT
systems and data they own. Typically the system and information owners are
responsible for changes to their IT systems. Thus, they usually have to approve and
sign off on changes to their IT systems (e.g., system enhancement, major changes
to the software and hardware). The system and information owners must therefore
understand their role in the risk management process and fully support this process.

Business and
Functional
Managers
The managers responsible for business operations and IT procurement process must
take an active role in the risk management process. These managers are the
individuals with the authority and responsibility for making the trade-off decisions
essential to mission accomplishment. Their involvement in the risk management
process enables the achievement of proper security for the IT systems, which, if
managed properly, will provide mission effectiveness with a minimal expenditure of
resources.

ISSO IT security program managers and computer security officers are responsible for
their organizations security programs, including risk management. Therefore, they
play a leading role in introducing an appropriate, structured methodology to help
identify, evaluate, and minimize risks to the IT systems that support their
organizations missions. ISSOs also act as major consultants in support of senior
management to ensure that this activity takes place on an ongoing basis.
IT Security
Practitioners
IT security practitioners (e.g., network, system, application, and database
administrators; computer specialists; security analysts; security consultants) are


responsible for proper implementation of security requirements in their IT systems.
As changes occur in the existing IT system environment (e.g., expansion in network
connectivity, changes to the existing infrastructure and organizational policies,
introduction of new technologies), the IT security practitioners must support or use
the risk management process to identify and assess new potential risks and
implement new security controls as needed to safeguard their IT systems.
Security
Awareness
Trainers
(Security/Subject
Matter
Professionals)
The organizations personnel are the users of the IT systems. Use of the IT systems
and data according to an organizations policies, guidelines, and rules of behavior is
critical to mitigating risk and protecting the organizations IT resources. To
minimize risk to the IT systems, it is essential that system and application users be
provided with security awareness training. Therefore, the IT security trainers or
security/subject matter professionals must understand the risk management
process so that they can develop appropriate training materials and incorporate risk
assessment into training programs to educate the end users.
Table 2: Roles and Responsibilities



CIA Triad
There are several small and large objectives of a security program, but the main three goals in
all programs are availability, integrity, and confidentiality. These are referred to as the CIA
Triad.
The following Figure illustrates the CIA Triad.

Figure 1: CIA Triad
Lets look at each one of these pillars in details:
Confidentiality (C): Confidentiality is the term used to prevent the disclosure of information
to unauthorized individuals or systems. For example, a credit card transaction on the
Internet requires the credit card number to be transmitted from the buyer to the merchant
and from the merchant to a transaction processing network. The system attempts to
enforce confidentiality by encrypting the card number during transmission, by limiting the
places where it might appear (in databases, log files, backups, printed receipts, and so on),
and by restricting access to the places where it is stored. If an unauthorized party obtains
the card number in any way, a breach of confidentiality has occurred.

Integrity (I): In information security, integrity means that data cannot be modified
undetectably. Integrity is violated when a message is actively modified in transit.
Confidentialy
Availability
Information
Integrity


Information security systems typically provide message integrity in addition to data
confidentiality.

Availability (A): For any information system to serve its purpose, the information must be
available when it is needed. This means that the computing systems used to store and
process the information, the security controls used to protect it, and the communication
channels used to access it must be functioning correctly. High availability systems aim to
remain available at all times, preventing service disruptions due to power outages, hardware
failures, and system upgrades. Ensuring availability also involves preventing denial-of-
service attacks.
Apart from the above mentioned CIA, few other commonly associated principles around
information security are:
Authenticity: In computing, e-Business and information security it is necessary to ensure
that the data, transactions, communications or documents (electronic or physical) are
genuine. It is also important for authenticity to validate that both parties involved are who
they claim they are.

Non-repudiation: In law, non-repudiation implies one's intention to fulfill their obligations
to a contract. It also implies that one party of a transaction cannot deny having received a
transaction nor can the other party deny having sent a transaction. Electronic commerce
uses technology such as digital signatures and encryption to establish authenticity and non-
repudiation.

Accountability: This principles aims to ensure that users are accountable for their action.
This can be achieved by tracking user, system and application activities.
In next sections we will look into vulnerability and threat.


Risk Assessment Scope
Management must determine the scope of the risk management program. This is a fairly
delicate undertaking because of the many interdependencies found in IT systems and business
processes. However, in an organization with several distinct operations or business units (BUs),
a risk management program could be isolated to one or more operational arms or BUs. In such
a case, where there are dependencies on other services in the organization, those dependencies
can be treated like an external service provider (or customer).Scope of the risk assessment shall
be in terms of organizational applicability, time frame supported and architectural/technology
considerations. Risk assessment scope affects the range of information available to make risk-
based decisions and is determined by the organizational official requesting the assessment.
Establishing the scope of risk assessments helps organizations determine: (i) what tiers are
addressed in risk assessments; (ii) what parts of organizations are affected by risk assessments
and how are they affected; (iii) what decisions risk assessment results support; (iv) how long
risk assessment results are relevant; and (v) what influences the need to update risk
assessments.
Organizational Applicability
Organizational applicability describes which parts of the organization or sub-organizations are
affected by the risk assessment and the risk-based decisions resulting from the assessment.
Effectiveness Time frame
Organizations determine how long the results of particular risk assessments can be used to
legitimately inform risk-based decisions. Organizations determine the useful life of risk
assessment results and under what conditions the current assessment results become
ineffective or irrelevant. Risk monitoring can be used to help determine effectiveness time
frames for risk assessments.
Technology Considerations
Organizations determine the types of system architectures, information systems, and
environments of operation to which risk assessments and the resulting risk-based decisions
apply. For example, a risk assessment can be used to inform decisions regarding command and
control systems in fixed, land-based facilities.



Asset Identification
This process involves identification and classification of information resources or assets that
need protection because they are vulnerable to threats. The purpose of the classification may
be either to prioritize further investigation and identify appropriate protection (simple
classification based on asset value), or to enable a standard model of protection to be applied
(classification in terms of criticality and sensitivity). Examples of typical assets associated with
information and IT include:
Information and data
E.g. Mail Communication, Minutes of Meeting, Employee database
Hardware
E.g. Firewall, Router, Server, Laptop, Desktop
Software
E.g. MS Office, Tally, Dot net, SQL Server
Services
E.g. Internet, VoIP, Fire Extinguishers, Cafeteria, Physical Security
Documents
E.g. Contract Agreements, License
Personnel
E.g. Employees, Third Party vendors
Other more traditional business assets for consideration are buildings, stock of goods
(inventory), and cash and intangible assets such as goodwill or image/reputation.


Vulnerability
In computer security, vulnerability is a weakness which allows an attacker to reduce a system's
information assurance.
A broader definition of vulnerability is:

Classification:
Vulnerabilities can be classified based on the assets they relate to:
Classifications Description/Examples
Hardware Susceptibility to humidity
Susceptibility to dust
Absence of protected storage
Software Insufficient testing (can lead to Buffer overflows)
Lack of audit trail
Network Unprotected communication lines
Insecure network architecture
Personnel Inadequate recruiting process
Inadequate security awareness
Site Area subject to flood
Unreliable power source
Organizational Lack of regular audits
Absence of continuity plans
Table 3: Vulnerability Classification
Vulnerability Sources
The technical and nontechnical vulnerabilities associated with an IT systems processing
environment can be identified via the information-gathering techniques. A review of other
industry sources (e.g., vendor Web pages that identify system bugs and flaws) will be useful in
preparing for the interviews and in developing effective questionnaires to identify vulnerabilities
that may be applicable to specific IT systems (e.g., a specific version of a specific operating
system). The Internet is another source of information on known system vulnerabilities posted
by vendors, along with hot fixes, service packs, patches, and other remedial measures that may
be applied to eliminate or mitigate vulnerabilities. Documented vulnerability sources that
A flaw or weakness in system security procedures, design, implementation, or internal
controls that could be exercised (accidentally triggered or intentionally exploited) and result
in a security breach or a violation of the system's security policy. (Reference NIST SP 800-
30)


should be considered in a thorough vulnerability analysis include, but are not limited to, the
following:
Previous risk assessment documentation of the IT system assessed.
The IT systems audit reports, system anomaly reports, security review reports, and system
test and evaluation reports.
Vulnerability lists, such as the NIST I-CAT vulnerability database (http://icat.nist.gov).
Security advisories, such as FedCIRC and the Department of Energys Computer Incident
Advisory Capability bulletins.
Vendor advisories.
Commercial computer incident/emergency response teams and post lists (e.g.,
SecurityFocus.com forum mailings).
Information Assurance Vulnerability Alerts and bulletins for military systems.
System software security analyses.
For more a detailed vulnerability inventory, please refer:
Mitre Corporation maintains a list of disclosed vulnerabilities in a system called Common
Vulnerabilities and Exposures, where vulnerabilities are classified (scored) using Common
Vulnerability Scoring System (CVSS). (http://cve.mitre.org/)
OWASP collects a list of potential vulnerabilities in order to prevent system designers and
programmers insert vulnerabilities in the software.
(https://www.owasp.org/index.php/Category:Vulnerability)
Vulnerability Identification and Removal
Many software tools exist that can aid in the discovery (and sometimes removal) of
vulnerabilities in a computer system. Though these tools can provide an auditor with a good
overview of possible vulnerabilities present, they cannot replace human judgment. Relying
solely on scanners will yield false positives and a limited-scope view of the problems present in
the system.
Vulnerabilities have been found in every major operating system including Windows, Mac OS,
various forms of Unix and Linux, OpenVMS, and others. The only way to reduce the chance of a
vulnerability being used against a system is through constant vigilance, including careful
system maintenance (e.g. applying software patches), best practices in deployment (e.g. the use
of firewalls and access controls) and auditing (both during development and throughout the
deployment lifecycle).


Threat
In Computer security a threat is a possible danger that might exploit a vulnerability to breach
security and thus cause possible harm.
A threat can be either "intentional" (i.e., intelligent; e.g., an individual cracker or a criminal
organization) or "accidental" (e.g., the possibility of a computer malfunctioning, or the
possibility of an "act of God" such as an earthquake, a fire, or a tornado) or otherwise a
circumstance, capability, action, or event.
There are two aspects to threat considered: (i) threat sources; and (ii) threat events.
A threat source is an actor (causal agent) with the intent and method targeted at the
exploitation of vulnerability or a situation and method that may accidentally exploit
vulnerability. In general, types of threat sources include: (i) hostile cyber/physical attacks; (ii)
human errors of omission or commission; (iii) structural failures of organization-controlled
resources (e.g., hardware, software, environmental controls); and (iv) natural and man-made
disasters, accidents, and failures beyond the control of the organization. A threat event is an
event or situation initiated or caused by a threat source that has the potential for causing
adverse impact.
A broader definition of threat is:

Threat Classification
Threat can be classified by type and origin. Following table depicts threat by type:
Physical damage Fire
Water
Pollution
Natural events Tornadoes
Earthquake
Volcanic Eruptions
Loss of essential Power fluctuation
The National Institute of Standards and Technology (NIST) define a threat as "the potential
for a particular threat-source to successfully exercise a particular vulnerability."
Threat source is defined as "either (1) intent and method targeted at the intentional exploitation of
vulnerability or (2) a situation and method that may accidentally trigger vulnerability.


services HVAC failure
Compromise of
information
Eavesdropping
Theft of media
Dumpster Diving
Technical failures Equipment failure
Capacity saturation
Compromise of
functions
Collusion

Table 4: Threat Classification
Following table depicts threat by origin:
Deliberate aiming
at information
asset
Spying
Illegal processing of data
Accidental Equipment failure
Software failure
Environmental Natural event
Loss of power supply
Table 5: Threat by Origin
Threat Management
Threats should be managed by operating ISMS, performing all the IT risk management activities
foreseen by laws, standards and methodologies.
Very large organizations tend to adopt business continuity management plans in order to
protect, maintain and recover business-critical processes and systems. Some of these plans
foreseen to set up computer security incident response team (CSIRT) or computer emergency
response team (CERT).
Common forms of verification of the threat management process are:
Information security audit
Penetration test
Countermeasures for managing threats may include tools such as firewalls, intrusion detection
system and anti-virus software, Physical Security measures, policies and procedures such as
regular backups and configuration hardening, training such as security awareness education.



Risk Management Process
Risk management encompasses three processes as illustrated in the below figure.

Figure 2: Risk Management Process

As evident from the above figure, Risk Management is a continuous process, with each phase
acting as an input for the next phase.

In the following sections, we will look at each of the sub processes in details.
First Step towards Risk Management: Risk Assessment

Risk assessment is the first process in the risk management methodology. Organizations use
risk assessment to determine the extent of the potential threat and the risk associated with an
IT system throughout its SDLC. The output of this process helps to identify appropriate controls
for reducing or eliminating risk during the risk mitigation process.

Risk Assessment
Includes identification and evaluation of risks and
risk impacts, and recommendation of risk-reducing.

Risk Mitigation
Refers to prioritizing, implementing, and
maintaining the appropriate risk-reducing
measures recommended from the risk assessment
process.

Evaluation and Assessment
Continual evaluation process and keys for
implementing a successful risk management
program.
Risk Management
Process


Before we jump into the actual Risk Assessment Process, lets understand different ways of
carrying Risk Assessment and common Risk Assessment Methodologies.
Qualitative Risk Assessment
Organizations have the option of performing a risk assessment in two ways: qualitatively or
quantitatively. Qualitative risk assessments produces valid results that are descriptive as well as
measurable. A qualitative risk assessment is typically conducted when:

The risk assessors available for the organization have limited expertise in quantitative risk
assessment; that is, assessors typically do not require as much experience in risk
assessment when conducting a qualitative assessment.
The timeframe to complete the risk assessment is short.
The organization does not have a significant amount of data readily available that can assist
with the risk assessment and, as a result, descriptions, estimates, and ordinal scales (such
as high, medium, and low) must be used to express risk.

The following methods are typically used during a qualitative risk assessment:

Management approval to conduct the assessment must be obtained prior to assigning a
team and conducting the work. Management is kept apprised during the process to
continue to promote support for the effort.
Once management approval has been obtained, a risk assessment team can be formed.
Members may include staff from senior management, information security, legal or
compliance, internal audit, HR, facilities/safety coordination, IT, and business unit owners,
as appropriate.
The assessment team requests documentation, which may include, dependent upon scope:
Information security program strategy and documentation
Information security policies, procedures, guidelines, and baselines
Information security assessments and audits
Technical documentation, to include network diagrams, network device
configurations and rule sets, hardening procedures, patching and configuration
management plans and procedures, test plans, vulnerability assessment findings,
change control and compliance information, and other documentation as needed.
Applications documentation, to include software development life cycle, change
control and compliance information, secure coding standards, code promotion
procedures, test plans, and other documentation as needed
Business continuity and disaster recovery plans and corresponding documents, such
as business impact analysis surveys.
The team sets up interviews with organizational members, for the purposes of identifying
vulnerabilities, threats, and countermeasures within the environment. All levels of staff
should be represented, to include:


Senior management
Line management
Business unit owners
Temporary or casual staff (that is, interns)
Business partners, as appropriate
Remote workers, as appropriate
Any other staff deemed appropriate to task

Once interviews are completed, the analysis of the data gathered can be completed. This can
include matching the threat to vulnerability, matching threats to assets, determining how likely
the threat is to exploit the vulnerability, and determining the impact to the organization in the
event an exploit is successful. Analysis also includes a matching of current and planned
countermeasures (that is, protection) to the threatvulnerability pair.

When the matching is completed, risk can be calculated. In a qualitative analysis, the product of
likelihood and impact produces the level of risk. The higher the risk level, the more immediate
is the need for the organization to address the issue, to protect the organization from harm.

Once risk has been determined, additional countermeasures can be recommended to minimize,
transfer, or avoid the risk. When this is completed, the risk that is left over after
countermeasures have been applied to protect against the risk is also calculated. This is the
residual risk or risk left over after countermeasure application.
Quantitative Risk Assessments

As an organization becomes more sophisticated in its data collection and retention, and staff
becomes more experienced in conducting risk assessments, an organization may find itself
moving more toward quantitative risk assessment. The hallmark of a quantitative assessment is
the numeric nature of the analysis. The fequency, probability, impact, countermeasure
effectiveness, and other aspects of the risk assessment have a discrete mathematical value in a
pure quantitative analysis.

Often, the risk assessment an organization conducts is a combination of qualitative and
quantitative methods. Fully quantitative risk assessment may not be possible, because there is
always some subjective input present, such as the value of information.

It is important to note that staff across all business units within scope for the risk
assessment should be interviewed. It is not necessary to interview every staff person within
a unit; a representative sample is usually sufficient.



Quantitative analysis allows the assessor to determine whether the cost of the risk outweighs
the cost of the countermeasure, in mathematical rather than descriptive terms. Purely
quantitative analysis, however, requires an enormous amount of time and must be performed
by assessors with a significant amount of experience

Three steps are undertaken in a quantitative risk assessment:
Initial management approval
Construction of a risk assessment team
The review of information currently available within the organization.

Single loss expectancy (SLE) must be calculated to provide an estimate of loss. Single loss
expectancy is defined as the difference between the original value and the remaining value of
an asset after a single exploit.

Losses can include lack of availability of data assets due to data loss, theft, alteration, or denial
of service (perhaps due to business continuity or security issues).

Next, the organization would calculate the annualized rate of occurrence (ARO). This is done to
provide an accurate calculation of annualized loss expectancy (ALE). ARO is an estimate of how
often a threat will be successful in exploiting vulnerability over the period of a year.

When this is completed, the organization calculates the annualized loss expectancy (ALE). The
ALE is a product of the yearly estimate for the exploit (ARO) and the loss in value of an asset
after a single exploitation (SLE). The calculation follows:

Note that this calculation can be adjusted for geographical distances using the local annual
frequency estimate (LAFE) or the standard annual frequency estimate (SAFE).

Given that there is now a value for ALE, it is possible to determine what the organization should
spend, if anything, to apply a countermeasure for the risk in question. Remember that no
countermeasure should be greater in cost than the risk it mitigates, transfers, or avoids.

The formula for calculating SLE is as follows:
SLE = asset value (inAmount) exposure factor (loss in successful threat exploit, as %)

ALE = ARO SLE



Countermeasure cost per year is easy and straightforward to calculate. It is simply the cost of
the countermeasure divided by the years of its life (that is, use within the organization). Finally,
the organization is able to compare the cost of the risk versus the cost of the countermeasure
and make some objective decisions regarding its countermeasure selection.
Quantitative Vs. Qualitative

The Risk analysis team, management, risk analysis tool and culture of the company will
dedicate which approach Quantitative or Qualitative will be used. The goal of the each method
is to estimate a companys real risk and rank the severity of the threats so the correct
countermeasures can be put into place within a practical budget.

In deciding to use either a qualitative or quantitative approach, the following points might need
to be considered:
Qualitative Cons
The assessments and the results are basically subjective.
Usually eliminates the opportunity to create a dollar value for cost/benefit discussions.
Difficult to track risk management objectives with subjective measures.
Standards are not available. Each vendor has its own way of interpreting the process and
their results.
Quantitative Cons
Calculations are more complex. Can management understand how these values were
derived?
Without automated tools, this process is extremely laborious.
More preliminary work is needed to gather detailed information about environment.
Standards are not available. Each vendor has its own way of interpreting the process and
their results.



Threat Risk modeling to Secure Web Application
While starting a web application design, it is essential to apply threat risk modeling. OWASP
recommends Microsofts threat modeling process because it works well for addressing the
unique challenges facing web application security and is simple to learn and adopt by
designers, developers, code reviewers, and the quality assurance team
The threat risk modeling process has five steps, enumerated below and shown graphically in
Figure 1. They are:
1. Identify Security Objectives
2. Survey the Application
3. Decompose it
4. Identify Threats
5. Identify Vulnerabilities

Identify Security Objectives
Applications Security objectives can be split down to the following categories:
Identity
Does the application protect user identity from abuse? Are there adequate controls in
place to ensure evidence of identity?

Financial
Application Overview
Decompose Application
Identify Threats
Identify Vulnerabilities


Assess the level of risk the organization is prepared to absorb in remediation, as a
potential financial loss.
Reputation
Quantify or estimate of the loss of reputation derived from the application being
misused or successfully attacked.
Privacy and Regulatory
To what extent will the application have to protect user data?
Availability Guarantees
Is the application required to be available per a Service Level Agreement (SLA) or similar
guarantee? Is it a nationally protected infrastructure? To what level will the application
have to be available? High availability techniques are significantly more expensive, so
applying the correct controls up front will save a great deal of time, resources, and
money.
Application Overview
Once the security objectives have been defined, analyze the application design to identify the
components, data flows, and trust boundaries.
Do this by surveying the applications architecture and design documentation. High level
component diagrams are generally sufficient to understand how and why data flows to various
places. For example, data movement across a trust boundary (such as from the Internet to the
web tier, or from the business logic to the database server), needs to be carefully analyzed.
Decompose Application
Once the application architecture is understood then decompose it further, to identify the
features and modules with a security impact that need to be evaluated. For example, when
investigating the authentication module, it is necessary to understand how data enters the
module, how the module validates and processes the data, where the data flows, how the data
is stored, and what fundamental decisions and assumptions are made by the module.
Identify Threats
It is impossible to write down unknown threats, but it is likewise unlikely that new malware will
be created to exploit new vulnerabilities within custom systems. Therefore, concentrate on
known risks, which can be easily demonstrated using tools or techniques.


One of the approaches for writing up threats is structure list. Structured list is easier to create
but it will take longer for the threat impacts to become obvious.
1. Attacker may be able to read other users messages
2. User may not have logged off on a shared PC
3. Lack of data validation may allow SQL injection
4. Implement data validation
5. Authorization may fail, allowing unauthorized access
6. Implement authorization checks
7. Browser cache may contain contents of message
8. Implement anti-caching directive in HTTP headers
9. If eavesdropping risk is high, use SSL
Note that it takes a motivated attacker to exploit a threat; they generally want something from
your application or to obviate controls. To understand the relevant threats, use the following
categories to understand who might attack the application:
Accidental Discovery: An ordinary user stumbles across a functional mistake in your
application, just using a web browser, and gains access to privileged information or
functionality.
Automated Malware: Programs or scripts, which are searching for known vulnerabilities,
and then report them back to a central collection site.
The Curious Attacker: a security researcher or ordinary user, who notices something
wrong with the application, and decides to pursue further.
Script Kiddies: Common renegades, seeking to compromise or deface applications for
collateral gain, notoriety, or a political agenda, perhaps using the attack categories
described in the OWASP Web Application Penetration Checklist.
The Motivated Attacker: Potentially, a disgruntled staff member with inside knowledge
or a paid professional attacker.
Organized Crime: Criminals seeking high stake payouts, such as cracking e-commerce
or corporate banking applications, for financial gain.
Mentioned below are some of the known threats:
Spoofing Identity Identity spoofing is a key risk for applications that have many users but
provide a single execution context at the application and database level. In particular, users
should not be able to become any other user or assume the attributes of another user.


Tampering with Data Users can potentially change data delivered to them, return it, and thereby
potentially manipulate client-side validation, GET and POST results, cookies, HTTP headers, and
so forth. The application should not send data to the user, such as interest rates or periods,
which are obtainable only from within the application itself. The application should also
carefully check data received from the user and validate that it is sane and applicable before
storing or using it.
Repudiation Users may dispute transactions if there is insufficient auditing or recordkeeping of
their activity. For example, if a user says, But I didnt transfer any money to this external
account!, and you cannot track his/her activities through the application, then it is extremely
likely that the transaction will have to be written off as a loss.
Therefore, consider if the application requires non-repudiation controls, such as web access
logs, audit trails at each tier, or the same user context from top to bottom. Preferably, the
application should run with the users privileges, not more, but this may not be possible with
many off-the-shelf application frameworks.
Information Disclosure Users are rightfully wary of submitting private details to a system. If it is
possible for an attacker to publicly reveal user data at large, whether anonymously or as an
authorized user, there will be an immediate loss of confidence and a substantial period of
reputation loss. Therefore, applications must include strong controls to prevent user ID
tampering and abuse, particularly if they use a single context to run the entire application.
Also, consider if the users web browser may leak information. Some web browsers may ignore
the no caching directives in HTTP headers or handle them incorrectly. In a corresponding
fashion, every secure application has a responsibility to minimize the amount of information
stored by the web browser, just in case it leaks or leaves information behind, which can be used
by an attacker to learn details about the application, the user, or to potentially become that
user.
Finally, in implementing persistent values, keep in mind that the use of hidden fields is insecure
by nature. Such storage should not be relied on to secure sensitive information or to provide
adequate personal privacy safeguards.
Denial of Service Application designers should be aware that their applications may be subject
to a denial of service attack. Therefore, the use of expensive resources such as large files,
complex calculations, heavy-duty searches, or long queries should be reserved for
authenticated and authorized users, and not available to anonymous users.


For applications that do not have this luxury, every facet of the application should be
engineered to perform as little work as possible, to use fast and few database queries, to avoid
exposing large files or unique links per user, in order to prevent simple denial of service
attacks.
Elevation of Privilege If an application provides distinct user and administrative roles, then it is
vital to ensure that the user cannot elevate his/her role to a higher privilege one. In particular,
simply not displaying privileged role links is insufficient. Instead, all actions should be gated
through an authorization matrix, to ensure that only the permitted roles can access privileged
functionality.
The OWASP Top 10 Web Application Security Risks are:
SQL Injection
Cross-Site Scripting (XSS)
Broken Authentication and Session Management
Insecure Direct Object References
Cross-Site Request Forgery (CSRF)
Security Misconfiguration
Insecure Cryptographic Storage
Failure to Restrict URL Access
Insufficient Transport Layer Protection
Invalidated Redirects and Forwards



Risk Assessment Methodologies.
Some common risk assessment methodologies are explained below:
NIST SP 800-30 and 800-66

These methodologies are qualitative methods established for use of the general public, but are
particularly used by regulated industries, such as healthcare. The procedures for using the
methodologies in the field are essentially the same; SP 800-66 is written specifically with HIPAA
clients in mind (though it is possible to use this document for other regulated industries as
well).
OCTAVE

As defined by its creator, Carnegie Mellon University's Software Engineering Institute, OCTAVE
"is a self-directed information security risk evaluation." OCTAVE is defined as a situation where
people from an organization manage and direct an information security risk evaluation for their
organization. In OCTAVE, an interdisciplinary team, called the analysis team, leads the
evaluation.

The OCTAVE criteria are a set of principles, attributes, and outputs. Principles are the
fundamental concepts driving the nature of the evaluation. They define the philosophy that
shapes the evaluation process. For example, self-direction is one of the principles of OCTAVE.
The concept of self direction means that people inside the organization are in the best position
to lead the evaluation and make decisions.

The requirements of the evaluation are embodied in the attributes and outputs. Attributes are
the distinctive qualities, or characteristics, of the evaluation. They are the requirements that
define the basic elements of the OCTAVE approach and what is necessary to make the
evaluation a success from both the process and organizational perspectives. Attributes are
derived from the OCTAVE principles. For example, one of the attributes of OCTAVE is that an
interdisciplinary team (the analysis team) staffed by personnel from the organization lead the
evaluation.

There are four distinct areas of activity that are carried out through eight steps in the OCTAVE
Allegro methodology. The activity areas are:
Establish drivers, where the organization develops risk measurement criteria that are
consistent with organizational drivers.
Profile assets, where the assets that are the focus of the risk assessment are identified and
profiled and the assets containers are identified.
Identify threats, where threats to the assetsin the context of their containersare identified
and documented through a structured process.


Identify and mitigate risks, where risks are identified and analyzed based on threat
information, and mitigation strategies are developed to address those risks.
The individual steps of the methodology are listed below:
Step 1 - Establish Risk Measurement Criteria
Step 2 - Develop an Information Asset Profile
Step 3 - Identify Information Asset Containers
Step 4 - Identify Areas of Concern
Step 5 - Identify Threat Scenarios
Step 6 - Identify Risks
Step 7 - Analyze Risks
Step 8 - Select Mitigation Approach
FRAP

The FRAP (facilitated risk analysis process ) process can be used by any organization that needs to
determine what direction the organization must take on a specific issue.

The process allows organizations to prescreen applications, systems, or other subjects to
determine if a risk analysis is needed. By establishing a unique prescreening process,
organizations will be able to concentrate on subjects that truly need a formal risk analysis. The
process has no outlay of capital and can be conducted by anyone with good facilitation skills.
FRAP analyzes one system, application or segment of business processes at time.
FRAP assumes that additional efforts to develop precisely quantified risks are not cost effective
because:
such estimates are time consuming
risk documentation becomes too voluminous for practical use
Specific loss estimates are generally not needed to determine if controls are needed.
without assumptions there is little risk analysis
After identifying and categorizing risks, a team identifies the controls that could mitigate the
risk. The decision for what controls are needed lies with the business manager. The team's
conclusions as to what risks exist and what controls needed are documented along with a
related action plan for control implementation.
Three of the most important risks a software company faces are unexpected changes in
revenue, unexpected changes in costs from those budgeted and the amount of specialization of


the software planned. Risks that affect revenues can be unanticipated competition, privacy,
intellectual property right problems, and unit sales that are less than forecast. Unexpected
development costs also create risk that can be in the form of more rework than anticipated,
security holes, and privacy invasions.
Narrow specialization of software with a large amount of research and development
expenditures can lead to both business and technological risks since specialization does not
necessarily lead to lower unit costs of software. Combined with the decrease in the potential
customer base, specialization risk can be significant for a software firm. After probabilities of
scenarios have been calculated with risk analysis, the process of risk management can be
applied to help manage the risk.
Methods like applied information economics add to and improve on risk analysis methods by
introducing procedures to adjust subjective probabilities, compute the value of additional
information and to use the results in part of a larger portfolio management problem.
CRAMM

As described on the CRAMM (CCTA Risk Analysis and Management Method) Web site, residing
on Siemens Insight Consul tings Web site, "CRAMM provides a staged and disciplined approach
embracing both technical (e.g., IT hardware and software) and nontechnical (e.g., Physical and
human) aspects of security. To assess these components, CRAMM is divided into three stages:
Stage 1 The establishment of the objectives for security by:
o Defining the boundary for the study;
o Identifying and valuing the physical assets that form part of the system;
o Determining the value of the data held by interviewing users about the potential
business impacts that could arise from unavailability, destruction, disclosure or
modification;
o Identifying and valuing the software assets that form part of the system.

Stage 2 The assessment of the risks to the proposed system and the requirements for
security by:
o Identifying and assessing the type and level of threats that may affect the system;
o Assessing the extent of the system's vulnerabilities to the identified threats;
o Combining threat and vulnerability assessments with asset values to calculate measures
of risks.


Stage 3 Identification and selection of countermeasures that are commensurate with the
measures of risks calculated in Stage 2. CRAMM contains a very large countermeasure
library consisting of over 3000 detailed countermeasures organized into over 70 logical
groupings.

The implementation of this methodology is much like the other methods listed above. More
information will be presented on information valuation, threat, and vulnerability and
countermeasure identification and selection later in this work.

Spanning Tree Analysis

As stated in the (ISC)2 Information Systems Security Engineering Professional (ISSEP)course
material spanning tree analysis "creates a 'tree' of all possible threats to or faults of the system.
'Branches' are general categories such as network threats, physical threats, component failures,
etc." When conducting the risk assessment, organizations "prune 'branches' that do not apply."
Failure Modes and Effect Analysis

As stated inth (ISC)2 ISSEPcourse material , failure modes and effect analysis was born in
hardware analysis, but can be used for software and system analysis. It examines potential
failures of each part or module, and examines effects of failure at three levels:

Immediate level (part or module)
Intermediate level (process or package)
System wide

The organization would then "collect total impact for failure of given modules to determine
whether modules should be strengthened or further supported."
A failure modes and effects analysis (FMEA) is an inductive failure analysis used in product
development, systems engineering / Reliability Engineering and operations management for
analysis of failure modes within a system for classification by the severity and likelihood of the
failures.



A successful FMEA activity helps a team to identify potential failure modes based on past
experience with similar products or processes or based on common failure mechanism logic,
enabling the team to design those failures out of the system with the minimum of effort and
resource expenditure, thereby reducing development time and costs.

The process for conducting an FMEA is typically developed in three main phases, in which
appropriate actions need to be defined.

Step 1: Occurrence
In this step it is necessary to look at the cause of a failure mode and the number of times it
occurs. This can be done by looking at similar products or processes and the failure modes that
have been documented for them in the past. A failure cause is looked upon as a design
weakness. All the potential causes for a failure mode should be identified and documented.
Again this should be in technical terms. Examples of causes are: erroneous algorithms,
excessive voltage or improper operating conditions. A failure mode is given an occurrence
ranking (O), again 110. Actions need to be determined if the occurrence is high (meaning > 4
for non-safety failure modes and > 1 when the severity-number from step 2 is 9 or 10). This
step is called the detailed development section of the FMEA process. Occurrence also can be
defined as %. If a non-safety issue happened less than 1%, it can be given a 1. It is based on
product and customer specification.
Step 1: Detect
a failure mode
Stp 2:
Severity
number
(SEV)
Step 3:
Probablity
Number
(OCCUR)
Step 4:
Detection
Number
(DETECT)
Risk Priority
Number(RPN)=SEV*OCCUR*DETECT


Step 2: Severity
Determine all failure modes based on the functional requirements and their effects. Examples
of failure modes are: Electrical short-circuiting, corrosion or deformation. A failure mode in one
component can lead to a failure mode in another component; therefore each failure mode
should be listed in technical terms and for function. Hereafter the ultimate effect of each failure
mode needs to be considered. A failure effect is defined as the result of a failure mode on the
function of the system as perceived by the user. In this way it is convenient to write these
effects down in terms of what the user might see or experience. Examples of failure effects are:
degraded performance, noise or even injury to a user. Each effect is given a severity number (S)
from 1 (no danger) to 10 (critical). These numbers help an engineer to prioritize the failure
modes and their effects. If the sensitivity of an effect has a number 9 or 10, actions are
considered to change the design by eliminating the failure mode, if possible, or protecting the
user from the effect. A severity rating of 9 or 10 is generally reserved for those effects which
would cause injury to a user or otherwise result in litigation.
Step 3: Detection
When appropriate actions are determined, it is necessary to test their efficiency. In addition,
design verification is needed. The proper inspection methods need to be chosen. First, an
engineer should look at the current controls of the system that prevent failure modes from
occurring or which detect the failure before it reaches the customer. Hereafter one should
identify testing, analysis, monitoring and other techniques that can be or have been used on
similar systems to detect failures. From these controls an engineer can learn how likely it is for
a failure to be identified or detected. Each combination from the previous 2 steps receives a
detection number (D). This ranks the ability of planned tests and inspections to remove defects
or detect failure modes in time. The assigned detection number measures the risk that the
failure will escape detection. A high detection number indicates that the chances are high that
the failure will escape detection, or in other words, that the chances of detection are low.

Risk priority number (RPN)
RPN play an important part in the choice of an action against failure modes. They are threshold
values in the evaluation of these actions.
After ranking the severity, occurrence and detectability the RPN can be easily calculated by
multiplying these three numbers: RPN = S O D


However, the practice of prioritizing work on the basis of RPN has no theoretical basis, but is an
informal heuristic which fails for many cases, due to the "nonsensical notion that you can
multiply rankings together".
This has to be done for the entire process and/or design. Once this is done it is easy to
determine the areas of greatest concern. The failure modes that have the highest RPN should be
given the highest priority for corrective action. This means it is not always the failure modes
with the highest severity numbers that should be treated first. There could be less severe
failures, but which occur more often and are less detectable.
After these values are allocated, recommended actions with targets, responsibility and dates of
implementation are noted. These actions can include specific inspection, testing or quality
procedures, redesign (such as selection of new components), adding more redundancy and
limiting environmental stresses or operating range. Once the actions have been implemented in
the design/process, the new RPN should be checked to confirm the improvements. These tests
are often put in graphs for easy visualization. Whenever a design or a process changes, an
FMEA should be updated.
A few logical but important thoughts come in mind:
Try to eliminate the failure mode (some failures are more preventable than others)
Minimize the severity of the failure
Reduce the occurrence of the failure mode
Improve the detection

Now that we have basic idea on Risk Assessment types and methodologies, its time to
understand the Risk Assessment Process.
Risk Assessment Process
As we discussed before, Risk is a function of the likelihood of a given threat-sources
exercising a particular potential vulnerability, and the resulting impact of that adverse event on
the organization.
To determine the likelihood of a future adverse event, threats to an IT system must be analyzed
in conjunction with the potential vulnerabilities and the controls in place for the IT system.
Impact refers to the magnitude of harm that could be caused by a threats exercise of
vulnerability. The level of impact is governed by the potential mission impacts and in turn


produces a relative value for the IT assets and resources affected (e.g., the criticality and
sensitivity of the IT system components and data).
The risk assessment methodology encompasses nine primary steps, which are described in the
following table:



Input to the Steps Risk Assessment Steps Output of each Step

Hardware
Software
System interfaces
Data and information
People
System mission

System
Characterization

System Boundary
System Functions
System and Data
Criticality
System and Data Sensitivity

History of system attack
Data from intelligence
agencies, NIPC, OIG

Threat Identification

Threat Statement

Reports from prior risk
assessments
Any audit comments
Security requirements
Security test results

Vulnerability
Identification

List of Potential
Vulnerabilities

Current controls
Planned controls

Control Analysis

List of Current and
Planned Controls

Threat-source motivation
Threat capacity
Nature of vulnerability
Current controls

Likelihood
Determination

Likelihood Rating

Mission impact analysis
Asset criticality assessment
Data criticality
Data sensitivity

Impact Analysis
Loss of Integrity
Loss of Availability
Loss of
Confidentiality

Impact Rating

Likelihood of threat
exploitation
Magnitude of impact
Adequacy of planned or
current controls

Risk Determination

Risks and
Associated Risk
Levels

Control
Recommendations

Recommended
Controls



Results Documentation

Risk Assessment
Report
Figure 3: Primary Steps towards Risk Assessment
Lets review each step in details.
STEP 1: SYSTEM CHARACTERIZATION
Identifying risk for an IT system requires a keen understanding of the systems processing
environment. The person or persons who conduct the risk assessment must therefore first
collect system-related information, which is usually classified as follows:

Figure 4: Gather System Related Information
Additional information related to the operational environmental of the IT system and its data
includes, but is not limited to, the following:
System Related Information
System mission
(e.g., the
processes
performed by
the IT system)
Persons who support
and use the IT system.
Data and information
Hardware and Software.
System and data
criticality (e.g., the
systems value or
importance to an
organization)


The functional requirements of the IT system
Users of the system (e.g., system users who provide technical support to the IT system;
application users who use the IT system to perform business functions)
System security policies governing the IT system (organizational policies, federal
requirements, laws, industry practices)
System security architecture
The level of protection required to maintain system and data integrity, confidentiality, and
availability.
Current network topology (e.g., LAN and WAN diagram)
Information storage protection that safeguards system and data availability, integrity, and
confidentiality
Flow of information pertaining to the IT system (e.g., system interfaces, system input and
output flowchart)
Technical controls used for the IT system (e.g., built-in or add-on security product that
supports identification and authentication, discretionary or mandatory access control, audit,
residual information protection, encryption methods)
Management controls used for the IT system (e.g., rules of behavior, security planning)
Operational controls used for the IT system (e.g., personnel security, backup, contingency,
and resumption and recovery operations; system maintenance; off-site storage; user
account establishment and deletion procedures; controls for segregation of user functions,
such as privileged user access versus standard user access).
Physical security environment of the IT system (e.g., facility security, data center policies)
Environmental security implemented for the IT system processing environment (e.g.,
controls for humidity, water, power, pollution, temperature, and chemicals).

For a system that is in the initiation or design phase, system information can be derived
from the design or requirements document. For an IT system under development, it is
necessary to define key security rules and attributes planned for the future IT system.
System design documents and the system security plan can provide useful information
about the security of an IT system that is in development.


Information-Gathering Techniques
Any, or a combination, of the following techniques can be used in gathering information
relevant to the IT system within its operational boundary:
Questionnaire To collect relevant information, risk assessment personnel can develop a
questionnaire concerning the management and operational controls planned or used
for the IT system. This questionnaire should be distributed to the applicable
technical and nontechnical management personnel who are designing or supporting
the IT system. The questionnaire could also be used during on-site visits and
interviews.

On-site Interviews Interviews with IT system support and management personnel can enable risk
assessment personnel to collect useful information about the IT system (e.g., how
the system is operated and managed). On-site visits also allow risk assessment
personnel to observe and gather information about the physical, environmental, and
operational security of the IT system. Appendix A contains sample interview
questions asked during interviews with site personnel to achieve a better
understanding of the operational characteristics of an organization. For systems still
in the design phase, on-site visit would be face-to-face data gathering exercises
and could provide the opportunity to evaluate the physical environment in which the
IT system will operate.
Document Review Policy documents (e.g., legislative documentation, directives), system
documentation (e.g., system user guide, system administrative manual, system
design and requirement document, acquisition document), and security-related
documentation (e.g., previous audit report, risk assessment report, system test
results, system security plan (security policies) can provide good information about
the security controls used by and planned for the IT system. An organizations
mission impact analysis or asset criticality assessment provides information
regarding system and data criticality and sensitivity.
Use of Automated
Scanning Tool
Proactive technical methods can be used to collect system information efficiently.
For example, a network mapping tool can identify the services that run on a large
group of hosts and provide a quick way of building individual profiles of the target
IT system(s).
Table 6: Information Gathering Techniques
For an operational IT system, data is collected about the IT system in its production
environment, including data on system configuration, connectivity, and documented and
undocumented procedures and practices. Therefore, the system description can be based
on the security provided by the underlying infrastructure or on future security plans for the
IT system.


STEP 2: THREAT IDENTIFICATION
Before we proceed with the next step in Risk Assessment, lets quickly revise the basics

In determining the likelihood of a threat, one must identify the:
Threat-Source Identification: The goal of this step is to identify the potential threat-sources
and compile a threat statement listing potential threat-sources that are applicable to the IT
system being evaluated.
Motivation and Threat Actions: Motivation and the resources for carrying out an attack make
humans potentially dangerous threat-sources. This information will be useful to
organizations studying their human threat environments and customizing their human
threat statements.

Output of Step 1:
Characterization of the IT system assessed
A good picture of the IT system environment
Delineation of system boundary
What is Threat?
A threat is the potential for a particular threat-source to successfully exercise a
particular vulnerability.
What is Threat-Source?
Intent or method targeted at the intentional exploitation of vulnerability.
A situation and method that may accidentally trigger vulnerability.
What is Vulnerability?
Vulnerability is a weakness that can be accidentally triggered or intentionally exploited.
A threat-source does not present a risk when there is no vulnerability that can be
exercised.


Following Table presents an overview of many of todays common human threats, their possible
motivations, and the methods or threat actions by which they might carry out an attack.
Threat-source Motivation Threat Action
Hacker, cracker Challenge
Ego
Rebellion
Hacking
Social engineering
System intrusion, break-ins
Unauthorized system access
Computer
criminal
Destruction of information
Illegal information disclosure
Monetary gain
Unauthorized data alteration
Computer crime (e.g., cyber stalking)
Fraudulent act (e.g., replay,
impersonation, interception)
Information bribery
Spoofing
System intrusion
Terrorist Blackmail
Destruction
Exploitation
Revenge
Bomb/Terrorism
Information warfare
System attack (e.g., distributed denial
of service)
System penetration
System tampering
Industrial
espionage
(companies,
foreign
governments,
other
government
interests)
Competitive advantage
Economic espionage
Economic exploitation
Information theft
Intrusion on personal privacy
Social engineering
System penetration
Unauthorized system access (access to
classified, proprietary, and/or
technology-related information)
Insiders (poorly
trained,
disgruntled,
malicious,
negligent,
dishonest, or
terminated
employees)
Curiosity
Ego
Intelligence
Monetary gain
Revenge
Unintentional errors and
omissions (e.g., data entry error,
programming error)
Assault on an employee
Blackmail
Browsing of proprietary information
Computer abuse
Fraud and theft
Information bribery
Input of falsified, corrupted data
Interception
Malicious code (e.g., virus, logic bomb,
Trojan horse)
Sale of personal information
System bugs
System intrusion
System sabotage
Unauthorized system access
Table 7: Common Human Threats



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 organizations.
Intrusion detection tools also are becoming more prevalent, and government and industry
organizations continually collect data on security events, thereby improving the ability to
realistically assess threats.

Sources of information include, but are not limited to, the following:
Intelligence agencies (for example, the Federal Bureau of Investigations National
Infrastructure Protection Center)
Federal Computer Incident Response Center (FedCIRC)
Mass media, particularly Web-based resources such as SecurityFocus.com,
SecurityWatch.com, and SANS.org.

Output of Step 2:
A threat statement containing a list of threat-sources that could exploit system
vulnerabilities


STEP 3: VULNERABILITY IDENTIFICATION
The goal of this step is to develop a list of system vulnerabilities (flaws or weaknesses) that
could be exploited by the potential threat-sources.
The following Table presents examples of vulnerability/threat pairs:
Vulnerability Threat-Source Threat Action
Terminated
employees
system
identifiers (ID) are
not removed
from the system
Terminated employees. Dialing into the companys network and
accessing company proprietary data.
Company firewall
allows inbound
telnet, and guest
ID is enabled on
XYZ server
Unauthorized users (e.g.,
hackers, terminated
employees, computer
criminals, terrorists)
Using telnet to XYZ server and browsing
system files with the guest ID.
The vendor has
identified flaws in
the security
design of the
system;
however, new
patches have not
been applied to
the system
Unauthorized users (e.g.,
hackers, disgruntled
employees, computer
criminals, terrorists)
Obtaining unauthorized access to sensitive
system files based on known system
vulnerabilities.
Data center uses
water sprinklers
to suppress fire;
tarpaulins to
protect hardware
and equipment
from water
damage are not in
place
Fire, negligent persons. Water sprinklers being turned on in the data
center.
Table 8: Vulnerability/Threat pairs



Recommended methods for identifying system vulnerabilities are:

Figure 5: Methods for Identifying System Vulnerabilities

STEP 4: CONTROL ANALYSIS
The goal of this step is to analyze the controls that have been implemented, or are planned for
implementation, by the organization to minimize or eliminate the likelihood (or probability) of a
threats exercising a system vulnerability.
To derive an overall likelihood rating that indicates the probability that a potential vulnerability
may be exercised within the construct of the associated threat environment (Step 5 below), the
implementation of current or planned controls must be considered. For example, vulnerability
(e.g., system or procedural weakness) is not likely to be exercised or the likelihood is low if
Vulnerability Sources
Previous risk assessment
documentation of the IT
system assessed.

The IT systems audit
reports, system anomaly
reports, security review
reports, and system test and
evaluation reports.

Vulnerability lists, such as
the NIST I-CAT vulnerability
database
(http://icat.nist.gov).

Vendor advisories.
System Security Testing
Results from Automated
vulnerability scanning tool

Results from Security test
and evaluation (ST&E)

Results from Penetration
testing.
Security Requirements
Checklist
Checklist results from
Management Security area.

Operational Security area.

Technical Security area.
Output of Step 3:
A list of the system vulnerabilities (observations) that could be exercised by the
potential threat-sources


there is a low level of threat-source interest or capability or if there are effective security
controls that can eliminate, or reduce the magnitude of, harm.
The following figure highlights the control methods, control categories, and the control analysis
technique which help in understanding/classifying existing controls.

Figure 6: Control Methods, Control Categories and the Control Analysis Technique

STEP 5: LIKELIHOOD DETERMINATION
To derive an overall likelihood rating that indicates the probability that a potential vulnerability
may be exercised within the construct of the associated threat environment; the following
governing factors must be considered:
Threat-source motivation and capability
Nature of the vulnerability
Existence and effectiveness of current controls.
Control Methods
Technical controls :
Safeguards that are
incorporated into computer
hardware, software, or
firmware (e.g., access control
mechanisms )

Non Technical Controls:
management and operational
controls, such as security
policies; operational
procedures; and personnel,
physical, and environmental
security.
Control Categories
Preventive controls: Inhibit
attempts to violate security
policy and include such
controls as access control
enforcement, encryption,
and authentication.

Detective Controls: Detect
violations or attempted
violations of security policy
and include such controls as
audit trails, intrusion
detection methods, and
checksums
Control Analysis
Technique
Security Requirements
Checklist: Such checklist can
be used to validate security
noncompliance as well as
compliance.

Output of Step 4:
List of current or planned controls used for the IT system to mitigate the likelihood of
vulnerability being exercised and reduce the impact of such an adverse event.


The likelihood that a potential vulnerability could be exercised by a given threat-source can be
described as high, medium, or low. Below Table describes these three likelihood levels.
Likelihood Level Likelihood Definition
High The threat-source is highly motivated and sufficiently capable, and controls to
prevent the vulnerability from being exercised are ineffective.
Medium The threat-source is motivated and capable, but controls are in place that may
impede successful exercise of the vulnerability.
Low The threat-source lacks motivation or capability, or controls are in place to prevent,
or at least significantly impede, the vulnerability from being exercised.
Table 9: Threat Source Likelihood Level

STEP 6: IMPACT ANALYSIS
The next major step in measuring level of risk is to determine the adverse impact resulting
from a successful threat exercise of vulnerability. Before beginning the impact analysis, it is
necessary to obtain the following necessary information:
System mission (e.g., the processes performed by the IT system)
System and data criticality (e.g., the systems value or importance to an organization)
System and data sensitivity.
This information can be obtained from existing organizational documentation, such as the
mission impact analysis report or asset criticality assessment report. A mission impact analysis
(also known as Business Impact Analysis [BIA] for some organizations) prioritizes the impact
levels associated with the compromise of an organizations information assets based on a
qualitative or quantitative assessment of the sensitivity and criticality of those assets. An asset
criticality assessment identifies and prioritizes the sensitive and critical organization
information assets (e.g., hardware, software, systems, services, and related technology assets)
that support the organizations critical missions.
If this documentation does not exist or such assessments for the organizations IT assets have
not been performed, the system and data sensitivity can be determined based on the level of
protection required to maintain the system and datas Availability, Integrity, and Confidentiality.
Output of Step 5:
Likelihood Rating (High, Medium, Low)


Regardless of the method used to determine how sensitive an IT system and its data are, the
system and information owners are the ones responsible for determining the impact level for
their own system and information. Consequently, in analyzing impact, the appropriate approach
is to interview the system and information owner(s).
Therefore, the adverse impact of a security event can be described in terms of loss or
degradation of any, or a combination of any, of the following three security goals: Integrity,
Availability, and Confidentiality (Refer CIA Triad Section).
The following table highlights the magnitude of Impact qualitatively:
Magnitude of
Impact
Impact Definition
High Exercise of the vulnerability may
Result in the highly costly loss of major tangible assets or resources
May significantly violate, harm, or impede an organizations mission, reputation,
or interest
May result in human death or serious injury.
Medium Exercise of the vulnerability may
Result in the costly loss of tangible assets or resources
May violate, harm, or impede an organizations mission, reputation, or interest;
May result in human injury.
Low Exercise of the vulnerability
May result in the loss of some tangible assets or resources
May noticeably affect an organizations mission, reputation, or interest.
Table 10: Magnitude of Impact

STEP 7: RISK DETERMINATION
The purpose of this step is to assess the level of risk to the IT system. The determination of risk
for a particular threat/vulnerability pair can be expressed as a function of:

Output of Step 6:
Magnitude of Impact (High, Medium, Low)
The likelihood of a given threat-sources attempting to exercise a given vulnerability.
The magnitude of the impact should a threat-source successfully exercise the
vulnerability.
The adequacy of planned or existing security controls for reducing or eliminating risk.



To measure risk, a risk scale and a risk-level matrix must be developed. Lets look at these sub
steps in details.
Risk-Level Matrix
The final determination of mission risk is derived by multiplying the ratings assigned for threat
likelihood (e.g., probability) and threat impact. Risk Matrix Table shows how the overall risk
ratings might be determined based on inputs from the threat likelihood and threat impact
categories. The matrix below is a 3 x 3 matrix of threat likelihood (High, Medium, and Low) and
threat impact (High, Medium, and Low). Depending on the sites requirements and the
granularity of risk assessment desired, some sites may use a 4 x 4 or a 5 x 5 matrix. The latter
can include a Very Low /Very High threat likelihood and a Very Low/Very High threat impact to
generate a Very Low/Very High risk level. A Very High risk level may require possible system
shutdown or stopping of all IT system integration and testing efforts.
The sample Risk Matrix Table shows how the overall risk levels of High, Medium, and Low are
derived. The determination of these risk levels or ratings may be subjective. The rationale for
this justification can be explained in terms of the probability assigned for each threat likelihood
level and a value assigned for each impact level. For example:
The probability assigned for each threat likelihood level is 1.0 for High, 0.5 for Medium, 0.1
for Low
The value assigned for each impact level is 100 for High, 50 for Medium, and 10 for Low.
Impact
Threat
Likelihood
Low
(10)
Medium
(50)
High
(100)
High (1.0) Low
10 X 1.0 = 10
Medium
50 X 1.0 = 50
High
100 X 1.0 = 100
Medium (0.5) Low
10 X 0.5 = 5
Medium
50 X 0.5 = 25
Medium
100 X 0.5 = 50
Low (0.1) Low
10 X 0.1 = 1
Low
50 X 0.1 = 5
Low
100 X 0.1 = 10
Risk Scale: High (>50 to 100); Medium (>10 to 50); Low (1 to 10)
Table 11: Risk-Level Matrix
Description of Risk Level
Below Table describes the risk levels shown in the above matrix. This risk scale, with its ratings
of High, Medium, and Low, represents the degree or level of risk to which an IT system, facility,


or procedure might be exposed if a given vulnerability were exercised. The risk scale also
presents actions that senior management, the mission owners, must take for each risk level.
Risk Level Risk Description and Necessary Actions
High If an observation or finding is evaluated as a high risk, there is a strong need for
corrective measures. An existing system may continue to operate, but a corrective
action plan must be put in place as soon as possible.
Medium If an observation is rated as medium risk, corrective actions are needed and a plan
must be developed to incorporate these actions within a reasonable period of time.
Low If an observation is described as low risk, the system owner must determine whether
corrective actions are still required or decide to accept the risk.
Table 12: Risk Levels

STEP 8: CONTROL RECOMMENDATIONS
During this step of the process, controls that could mitigate or eliminate the identified risks, as
appropriate to the organizations operations, are provided. The goal of the recommended
controls is to reduce the level of risk to the IT system and its data to an acceptable level. The
following factors should be considered in recommending controls and alternative solutions to
minimize or eliminate identified risks:
Effectiveness of recommended options (e.g., system compatibility)
Legislation and regulation
Organizational policy
Operational impact
Safety and reliability
The control recommendations are the results of the risk assessment process and provide input
to the risk mitigation process, during which the recommended procedural and technical
security controls are evaluated, prioritized, and implemented.
It should be noted that not all possible recommended controls can be implemented to reduce
loss. To determine which ones are required and appropriate for a specific organization, a cost-
Output of Step 7:
Risk Level (High, Medium, Low)


benefit analysis, as discussed in Residual Risk section, should be conducted for the proposed
recommended controls, to demonstrate that the costs of implementing the controls can be
justified by the reduction in the level of risk. In addition, the operational impact (e.g., effect on
system performance) and feasibility (e.g., technical requirements, user acceptance) of
introducing the recommended option should be evaluated carefully during the risk mitigation
process.

STEP 9: RESULTS DOCUMENTATION
Once the risk assessment has been completed (threat-sources and vulnerabilities identified,
risks assessed, and recommended controls provided), the results should be documented in an
official report or briefing.
A risk assessment report is a management report that helps senior management, the mission
owners, make decisions on policy, procedural, budget, and system operational and
management changes. Unlike an audit or investigation report, which looks for wrongdoing, a
risk assessment report should not be presented in an accusatory manner but as a systematic
and analytical approach to assessing risk so that senior management will understand the risks
and allocate resources to reduce and correct potential losses. For this reason, some people
prefer to address the threat/vulnerability pairs as observations instead of findings in the risk
assessment report.
Appendix B provides a suggested outline for the risk assessment report.

Output of Step 8:
Recommendation of control(s) and alternative solutions to mitigate risk.
Output of Step 9: Risk assessment report that describes the:
Threats and vulnerabilities
Measures the risk
Recommendations for control implementation.


Second Step towards Risk Management: Risk Mitigation
Risk mitigation, the second process of risk management, involves prioritizing, evaluating, and
implementing the appropriate risk-reducing controls recommended from the risk assessment
process.
Because the elimination of all risk is usually impractical or close to impossible, it is the
responsibility of senior management and functional and business managers to use cost-benefit
analysis and implement the most appropriate controls to decrease mission risk to an acceptable
level, with minimal adverse impact on the organizations resources and mission.
In this section we will look at the risk mitigation strategy, an approach for control
implementation, control categories, the cost-benefit analysis used to justify the implementation
of the recommended controls, and residual risk.
Risk Mitigation Strategy
Senior management, the mission owners, knowing the potential risks and recommended
controls, may ask, When and under what circumstances should I take action? When shall I
implement these controls to mitigate the risk and protect our organization?
The risk mitigation chart in figure below addresses these questions. Appropriate points for
implementation of control actions are indicated in this figure by the word Y.


Vulnerable
?
Threat
Source
System
Design
Vulnerability
to Attack
Exists
No Risk No Risk
Risk
Exists
Unacceptable
Risk
Accept Risk Accept Risk
Attackers
Cost < Gain
Loss
Anticipated
> Threshold
Exploitable?

Figure 7: Risk Mitigation Chart
This strategy is further articulated in the following rules of thumb, which provide guidance on
actions to mitigate risks from intentional human threats:
When vulnerability (or flaw, weakness) exists implement assurance techniques to reduce
the likelihood of a vulnerabilitys being exercised.
When vulnerability can be exercised apply layered protections, architectural designs, and
administrative controls to minimize the risk of or prevent this occurrence.
When the attackers cost is less than the potential gain apply protections to decrease an
attackers motivation by increasing the attackers cost (e.g., use of system controls such as
limiting what a system user can access and do can significantly reduce an attackers gain).
Y
Y
Y Y


When loss is too great apply design principles, architectural designs, and technical and
nontechnical protections to limit the extent of the attack, thereby reducing the potential for
loss.
The strategy outlined above, with the exception of the third list item (When the attackers cost
is less than the potential gain), also applies to the mitigation of risks arising from
environmental or unintentional human threats (e.g., system or user errors). (Because there is no
attacker, no motivation or gain is involved.)
Approach for Control Implementation
When control actions must be taken, the following rule applies:

The following risk mitigation methodology describes the approach to control implementation:

Address the greatest risks and strive for sufficient risk mitigation at the lowest cost, with
minimal impact on other mission capabilities.



Input to the Steps Risk Mitigation Steps Output of each Step

Risk levels from the
risk assessment
report

Step 1. Prioritize Actions
Give priority to High Risk

Actions ranking from High
to Low.

Risk assessment
report

Step 2. Evaluate Recommended
Control Options
Feasibility
Effectiveness

List of possible controls

Step 3. Conduct Cost-Benefit
Analysis
Impact of implementing
Impact of not implementing
Associated costs

Cost-benefit analysis

Step 4. Select Controls
Which are cost effective as well

Selected Controls

Step 5. Assign Responsibility
According to Skill Sets

List of responsible persons

Step 6. Develop Safeguard
Implementation Plan
Risks and Associated Risk Levels
Prioritized Actions
Recommended Controls
Selected Planned Controls
Responsible Persons
Start Date
Target Completion Date
Maintenance Requirements

Safeguard implementation
plan

Step 7. Implement Selected
Controls

Residual Risks

Figure 8: Risk Mitigation Methodology



Control Categories

Technical Security
Controls

Supporting Technical
Controls
Identification
Cryptographic Key
Management.
Security administration
Preventive Technical
Controls
Authentication.
Authorization
Access Control
Enforcement.
Protected
Communications.
Transaction Privacy.

Detection and Recovery
Technical Controls
Audit
Intrusion Detection
and Containment.
Management Security
Controls

Preventive Management
Security Controls
Assign security
responsibility
Develop and maintain
system security plans
Enforce SOD
Security awareness
trainings
Detection Management
Security Controls
Background
investigations, rotation
of duties
Perform periodic
system audits
Conduct Risk
Management

Recovery Management
Security Controls
Establish an incident
response process
BCP/DR

Operational Security
Controls

Preventive Operational
Controls

Control data media
access and disposal
Control software
viruses
Safeguard computing
facility
Provide backup
capability
Provide emergency
power source (UPS)
Secure wiring closets
that house hubs and
cables
Protect IT assets from
fire damage (deploy
fire extinguishers)
Detection Operational
Controls

Provide physical
security (CCTV etc)
Ensure environmental
security (Smoke
Detectors)

Figure 9: High-level Overview of Control Categories


The above figure provides a high-level overview of some of the control categories. (Refer NIST
SP 800-18 and NIST SP 800-12 for details)
Cost-Benefit Analysis
To allocate resources and implement cost-effective controls, organizations, after identifying all
possible controls and evaluating their feasibility and effectiveness, should conduct a cost-
benefit analysis for each proposed control to determine which controls are required and
appropriate for their circumstances.
The cost-benefit analysis can be qualitative or quantitative. Its purpose is to demonstrate that
the costs of implementing the controls can be justified by the reduction in the level of risk. For
example, the organization may not want to spend $1,000 on a control to reduce a $200 risk.
A cost-benefit analysis for proposed new controls or enhanced controls encompasses the
following:
Determining the impact of implementing the new or enhanced controls
Determining the impact of not implementing the new or enhanced controls
Estimating the costs of the implementation. These may include, but are not limited to, the
following:
Hardware and software purchases
Reduced operational effectiveness if system performance or functionality is reduced
for increased security.
Cost of implementing additional policies and procedures
Cost of hiring additional personnel to implement proposed policies, procedures, or
services
Training costs
Maintenance costs
Assessing the implementation costs and benefits against system and data criticality to
determine the importance to the organization of implementing the new controls, given their
costs and relative impact.
The organization will need to assess the benefits of the controls in terms of maintaining an
acceptable mission posture for the organization. Just as there is a cost for implementing a
needed control, there is a cost for not implementing it. By relating the result of not
implementing the control to the mission, organizations can determine whether it is feasible to
forgo its implementation.


The organizations managers must determine what constitutes an acceptable level of mission
risk. The impact of a control may then be assessed, and the control either included or excluded,
after the organization determines a range of feasible risk levels. This range will vary among
organizations; however, the following rules apply in determining the use of new controls:
If control would reduce risk more than needed, then see whether a less expensive
alternative exists
If control would cost more than the risk reduction provided, then find something else
If control does not reduce risk sufficiently, then look for more controls or a different control
If control provides enough risk reduction and is cost-effective, then use it.
Frequently the cost of implementing a control is more tangible than the cost of not
implementing it. As a result, senior management plays a critical role in decisions concerning
the implementation of control measures to protect the organizational mission.
Residual Risk
Organizations can analyze the extent of the risk reduction generated by the new or enhanced
controls in terms of the reduced threat likelihood or impact, the two parameters that define the
mitigated level of risk to the organizational mission.
Implementation of new or enhanced controls can mitigate risk by:
Eliminating some of the systems vulnerabilities (flaws and weakness), thereby reducing the
number of possible threat-source/vulnerability pairs
Adding a targeted control to reduce the capacity and motivation of a threat-source For
example, a department determines that the cost for installing and maintaining add-on
security software for the stand-alone PC that stores its sensitive files is not justifiable, but
that administrative and physical controls should be implemented to make physical access to
that PC more difficult (e.g., store the PC in a locked room, with the key kept by the
manager).
Reducing the magnitude of the adverse impact (for example, limiting the extent of
vulnerability or modifying the nature of the relationship between the IT system and the
organizations mission).



If the residual risk has not been reduced to an acceptable level, the risk management cycle
must be repeated to identify a way of lowering the residual risk to an acceptable level.
Third Step towards Risk Management: Evaluation, Assessment and Monitoring
In most organizations, the network itself will continually be expanded and updated, its
components changed, and its software applications replaced or updated with newer versions. In
addition, personnel changes will occur and security policies are likely to change over time.
These changes mean that new risks will surface and risks previously mitigated may again
become a concern. Thus, the risk management process is ongoing and evolving.
This section emphasizes the good practice and need for an ongoing risk evaluation and
assessment and the factors that will lead to a successful risk management program.
Risk Review and Monitoring
Risk management should be conducted and integrated in the SDLC for IT systems, not because
it is required by law or regulation, but because it is a good practice and supports the
organizations business objectives or mission.
There should be a specific schedule for assessing and mitigating mission risks, but the
periodically performed process should also be flexible enough to allow changes where
warranted, such as major changes to the IT system and processing environment due to changes
resulting from policies and new technologies.

The risk remaining after the implementation of new or enhanced controls is the residual
risk. Practically no IT system is risk free, and not all implemented controls can eliminate the
risk they are intended to address or reduce the risk level to zero.


Risk Reporting
Different levels within an organization need different information from the risk management process
and risk reporting enables to create various views for this purpose..
The Board of Directors should:
know about the most significant risks facing the organization
know the possible effects on shareholder value of deviations to expected performance
ranges
ensure appropriate levels of awareness throughout the organization
know how the organization will manage a crisis
know the importance of stakeholder confidence in the organization
know how to manage communications with the investment community where applicable
be assured that the risk management process is working effectively
publish a clear risk management policy covering risk management philosophy and
responsibilities

Business Units should:
be aware of risks which fall into their area of responsibility, the possible impacts these
may have on other areas and the consequences other areas may have on them
have performance indicators which allow them to monitor the key business and financial
activities, progress towards objectives and identify developments which require
intervention (e.g. forecasts and budgets)
have systems which communicate variances in budgets and forecasts at appropriate
frequency to allow action to be taken
report systematically and promptly to senior management any perceived new risks or
failures of existing control measures
Individuals should:
understand their accountability for individual risks
understand how they can enable continuous improvement of risk management
response
understand that risk management and risk awareness are a key part of the
organizations culture
report systematically and promptly to senior management any perceived new risks or
failures of existing control measures


Keys for Success
The following figure highlights the key pillars on which a successful risk management program
relies on:

Figure 10: Keys for Success

Managements
commitment
Full support and
participation of the IT team
The competence of the risk assessment
team
The awareness and cooperation of members of the user
community
An ongoing evaluation and assessment of the IT-related mission risks


Vendor Risk Assessment
Vendor Risk Management is increasingly at the forefront of risk management priorities for
organizations of all shapes and sizes. In the drive to focus on their core competencies, many
organizations today rely thousands of partners, vendors and service providers to fill non-core
functions. In practice these external partners have access to much of the same data as regular
employees do. Commercially sensitive and proprietary data is often transmitted, stored and
processed among a wide range of partner and vendor networks, outside the influence of any
one organizations internal controls and security policies.
Regulators acknowledge the role that partner and vendor networks play, and regulations such
as SOX, GLBA, HIPAA, PCI DSS and others explicitly mandate that corporate control activities
extend to third-party vendors, outsourcers, contractors and consultants when appropriate.
Consequently third-party vendors may handle critical information and directly influence a
company's risk and compliance management process.
While doing Vendor Risk Assessment we need to focus on following points:
Vendor information, including profiles, contacts, facilities, contracts and projects, in a
centralized data repository
Minimize and manage risk associated with vendor relationships by tracking key
performance indicators and the status of deliverables
Provide effective assessment of the status of each finding, including the vendor
response and appropriate mitigation procedures, thereby facilitating tracking of
remediation tasks
Provide risk transparency and visibility into high-risk areas or your business, the status
of ongoing vendor assessments and your organizations overall risk exposure
Generate effective reports for analyzing your vendor risk profile, and allows creation of
ad-hoc reports and dashboards with drill-down capabilities
Create a win-win relationship with suppliers, with a shared understanding of goals,
helping both parties cost-effectively achieve and sustain compliance.



Risk based Auditing
Risk based audit approach is adapted to develop and improve the continuous audit process.
This approach assists the IS auditor deciding whether to perform compliance testing or
substantive testing. Risk based audit approach assists the auditor in determine the nature and
extent of testing. In this approach IS auditors are not just relying on risk; they also are relying
on internal and operational controls as well as knowledge of the company or the business. This
type of risk assessment decision can help relate the cost-benefit analysis of the control to the
known risk, allowing practical choices. The Risk model and approach in conducting the audit
can be determined by understanding the nature of the business. An overview of Risk based
audit approach is explained in the coming sections.

Audit Risk and Materiality
Audit risk can be defined as the risk that information may contain a material error that may go
undetected during the course of the audit. The IS auditor should also take into account, if
applicable, other factors relevant to the organization: customer data, privacy, availability of
provided services as well as corporate and public image as in the case of public organizations
or foundations. Audit risk can be categorized as:
Inherent risk-The risk that could be material or significant when combined with other errors
encountered during the audit, assuming that there are no related compensating controls.
Inherent risk can also be categorized as the susceptibility to a material misstatement in the
absence of related controls. For example, complex calculations are more likely to be misstated
than simple ones and cash is more likely to be stolen than an inventory of coal. Inherent risks
exist independent of an audit and can occur because of the nature of the business.
Control risk-If a material error exists and that will not be prevented or detected in a timely
manner by the internal controls system is Control risk. For example, the control risk associated
with manual reviews of computer logs can be high because activities requiring investigation are
often easily missed due to the volume of logged information. The control risk associated with
computerized data validation procedures is ordinarily low if the processes are consistently
applied.
Detection risk-The risk that an IS auditor uses an inadequate test procedure and concludes
that material errors do not exist when, in fact, they do. Detection of an error would not be
determined during the risk assessment phase of an audit. However, identifying detection risk
would better evaluate and assess the auditor's ability to test, identity and recommend the
correction of material errors as the result of a test.
Overall audit risk-The combination of the individual categories of audit risks assessed for
each specific control objective. An objective in formulating the audit approach is to limit the


audit risk in the area under scrutiny so the overall audit risk is at a sufficiently low level at the
completion of the examination. Another objective is to assess and control those risks to achieve
the desired level of assurance as efficiently as possible. Audit risk is also used sometimes to
describe the level of risk that the IS auditor is prepared to accept during an audit engagement.
The auditor may set a target level of risk and adjust the amount of detailed audit work to
minimize the overall audit risk.

The word "material;' when associated with any of the components of risks, refers to an error
that should be considered significant to any party concerned with the item in question. The
assessment of what is material is a matter of professional judgment and includes consideration
of the effect on the organization as a whole, and errors, omissions, irregularities and illegal acts
that may arise as a result of control weaknesses in the area being audited. Specifically, this
means that an internal control weakness or set of combined internal control weaknesses leaves
the organization highly susceptible to the occurrence of a threat (e.g., financial loss, business
interruption, loss of customer trust, economic sanction, etc.). The IS auditor should be
concerned with assessing the materiality of the items in question through a risk-based audit
approach to evaluating internal controls. An audit sample may not detect every potential error
in a population. However, by using proper statistical sampling procedures or a strong quality
control process, the probability of detection risk can be reduced to an acceptable level.
Similarly, when evaluating internal controls, the IS auditor should realize that a given system
may not detect a minor error. However, that specific error, combined with others, could become


material to the overall system. The concept of materiality requires sound judgment from the IS
auditor. The IS auditor may detect a small error that could be considered significant at an
operational level, but may not be viewed as significant to upper management. Materiality
considerations combined with an understanding of audit risk are essential concepts for
planning the areas to be audited and the specific test to be performed in a given audit.

To develop a more complete understanding of audit risk, the IS auditor should also understand
how the organization being audited approaches risk assessment and treatment.

Risk Assessment technique to determine areas to be audited
The IS auditor should evaluate various risk candidates to determine the high-risk areas that
should be audited. There are many risk assessment methodologies, computerized and non-
computerized, from which the IS auditor may choose. These range from simple classifications
of high, medium and low, based on the IS auditor's judgment, to complex scientific calculations
that provide a numeric risk rating.
One such risk assessment approach is a scoring system that is useful in prioritizing audits
based on an evaluation of risk factors. The system considers variables such as technical
complexity, level of control procedures in place and level of financial loss. These variables
mayor may not be weighted. The risk values are then compared to each other and audits are
scheduled accordingly. Another form of risk assessment is judgmental, where an independent
decision is made based on business knowledge, executive management directives, historical
perspectives, business goals and environmental factors. A combination of techniques may be
used as well. Risk assessment methods may change and develop over time to best serve the
needs of the organization.
Using risk assessment to determine areas to be audited:
Enables management to effectively allocate limited audit resources.
Ensures that relevant information has been obtained from all levels of management,
including boards of directors, IS auditors and functional area management. Generally,
this information assists management in effectively discharging its responsibilities and
ensures that the audit activities are directed to high-risk areas, which will add value for
management.
Establishes a basis for effectively managing the audit department.
Provides a summary of how the individual audit subject is related to the overall
organization as well as to the business plans.



Appendix A: Sample Interview Questions
Interview questions should be tailored based upon the details of the system being assessed.
Sample questions to be asked during interviews with site personnel to gain an understanding of
the operational characteristics of an organization may include the following:
Who are valid users?
What is the mission of the user organization?
What is the purpose of the system in relation to the mission?
How important is the system to the user organizations mission?
What is the system-availability requirement?
What information (both incoming and outgoing) is required by the organization?
What information is generated by, consumed by, processed on, stored in, and retrieved by
the system?
How important is the information to the user organizations mission?
What are the paths of information flow?
What types of information are processed by and stored on the system (e.g., financial,
personnel, research and development, medical, command and control)?
What is the sensitivity (or classification) level of the information?
What information handled by or about the system should not be disclosed and to whom?
Where specifically is the information processed and stored?
What are the types of information storage?
What is the potential impact on the organization if the information is disclosed to
unauthorized personnel?
What are the requirements for information availability and integrity?
What is the effect on the organizations mission if the system or information is not reliable?
How much system downtime can the organization tolerate? How does this downtime
compare with the mean repair/recovery time? What other processing or communications
options can the user access?
Could a system or security malfunction or unavailability result in injury or death?



Appendix B: Risk Assessment Report
EXECUTIVE SUMMARY
I. Introduction
Purpose
Scope of this risk assessment
Describe the system components, elements, users, field site locations (if any), and any
other details about the system to be considered in the assessment.
II. Risk Assessment Approach
Briefly describe the approach used to conduct the risk assessment, such as:
The participants (e.g., risk assessment team members)
The technique used to gather information (e.g., the use of tools, questionnaires)
The development and description of risk scale (e.g., a 3 x 3, 4 x 4, or 5 x 5 risk-level
matrix).
III. System Characterization
Characterize the system, including hardware (server, router, switch), software (e.g.,
application, operating system, protocol), system interfaces (e.g., communication link), data,
and users. Provide connectivity diagram or system input and output flowchart to delineate
the scope of this risk assessment effort.
IV. Threat Statement
Compile and list the potential threat-sources and associated threat actions applicable to the
system assessed.
V. Risk Assessment Results
List the observations (vulnerability/threat pairs). Each observation must include:
Observation number and brief description of observation (e.g., Observation 1: User
system passwords can be guessed or cracked)
A discussion of the threat-source and vulnerability pair
Identification of existing mitigating security controls
Likelihood discussion and evaluation (e.g., High, Medium, or Low likelihood)
Impact analysis discussion and evaluation (e.g., High, Medium, or Low impact)
Risk rating based on the risk-level matrix (e.g., High, Medium, or Low risk level)


Recommended controls or alternative options for reducing the risk.
VI. Summary
Total the number of observations. Summarize the observations, the associated risk levels,
the recommendations, and any comments in a table format to facilitate the implementation
of recommended controls during the risk mitigation process.

Risk Management L2

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Risk Management L2

Загружено:

Авторское право:

Доступные форматы

RCA Practice UCF

Вам также может понравиться