0% found this document useful (0 votes)
23 views63 pages

NIST Cybersecurity Framework 2.0 Overview

Risk assignment for frameworks

Uploaded by

bisho0323
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
23 views63 pages

NIST Cybersecurity Framework 2.0 Overview

Risk assignment for frameworks

Uploaded by

bisho0323
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

CHAPTER 2

Information Security Risk


Assessment

A Practical Approach
CHAPTER 1: Information
Security Risk Assessments

CHAPTER 8: Maintenance CHAPTER 2 : A Practical


and Wrap Up Approach

CHAPTER 7 : Reporting CHAPTER 3: Data Collection

CHAPTER 6 : Risk
CHAPTER 4 : Data Analysis
Prioritization and Treatment

CHAPTER 5 : Risk Assessment


Learning Outcomes
Upon successful completion of this chapter, students should be able to:
• Address the gap between conceptual risk frameworks and actual workplace
implementation.

• Coverage over major four information security risk assessment frameworks


(OCTAVE, FAIR, NIST SP800-30, and ISO 27005)

• Define the hybrid approach to conducting risk assessments.


A Primer on Information Security
• A framework is some form of logical structure to organize information or activities.

• Information Security risk assessment framework provides the logical structure or model to guide a
user through the process of executing an information security risk assessment.

• These frameworks won't go into implementation details but will focus on foundational concepts
associated with risk elements, high-level activities, formulas, and decision matrices, all of which
are components essential to successfully conducting an information security risk assessment within
an organization.

• The frameworks commonly used within the United States are OCTAVE, FAIR, NIST, and
ISO27005
Do I Use an Existing Framework or Should I
Use My Own?
• We often run across organizations that use custom or modified frameworks that
they have developed them- selves. There is nothing wrong with this approach.

• the choice is yours, but we recommend using a framework that gives you as much
flexibility as you need, so that you can tailor it to your organization, while still
maintaining a defensible position against the naysayers,who criticizes, and people
who always think they have a better way of doing things.
Do I Use an Existing Framework or Should I
Use My Own?
Standard Frameworks

Prons Cons
• There is less initial work since all you have to do is • Frameworks were not created specific to your
read and understand the framework organization.
• A standard framework makes your work easier to • The more detailed a framework is, the greater
defend. It is like using ISO 17799:2005 or COBIT. the chance that some aspect of it will not be
• When you are asked why you are doing something applicable or will be difficult to implement in the
you have a defensible position since you are using context of your organization
what is considered to be an industry standard
Do I Use an Existing Framework or Should I
Use My Own?
Custom Frameworks.
Prons Cons
• More initial work since you will have to build all • Depending on how knowledgeable the people
the formulas, activities and decision matrices for building the custom framework are, they might
yourself miss some important key concepts regarding
• If the people creating the custom framework are risk.
well versed with the theory behind risk • Remember though that all “standard”
assessments, they can make a framework that is frameworks were once custom as well
tailored to your organization and thus easier to • It is not widely used, it may be more difficult to
implement defend to stakeholders and auditors.
OCTAVE Framework
• OCTAVE (Operationally Critical Threat, Asset, and Vulnerability
Evaluation), is a collection of tools, techniques, and methods for risk-
based information security assessments. This framework was
developed by the Software Engineering Institute (SEI) of Carnegie
Mellon through its CERT program.
• Many risk assessment practitioners agree that the detail level and
complexity of the OCTAVE assessment approach has made it hard to
adopt on a wide scale.
• Currently OCTAVE has 3 different versions:
1. OCTAVE (original).
2. OCTAVE-S.
3. OCTAVE-Allegro.
Original OCTAVE Framework

• The basis for all OCTAVE types.

• It recommended for large organizations (more than 300 employees)

• It very comprehensive and contains various templates such as surveys,


meeting minutes, and guidelines on how to conduct workshops.

• It recommends the involvement of a wide variety of people, many of


whom are not directly involved in the risk management function.
OCTAVE-S
• Developed for smaller organizations (less than 100 employee)
• It require a team of 3–5 people who are knowledgeable about the
company.
• It assumes that the people doing the assessment know about the
company’s assets, security requirements, threats and security
practices and thus do not require the company-wide workshops and
meetings.
OCTAVE-Allegro.
• It is the most recent version of the framework.
• OCTAVE- Allegro was specifically streamlined for information security
risk assessments.
• It does not require extensive organizational involvement.
• We will be focusing on the Allegro iteration of OCTAVE and all future
references of OCTAVE in this course will be regarding OCTAVE-
Allegro.
• It describes eight steps and provides various worksheets and
questionnaires as a guide and model on how to assess risk for the
organization or more specifically the assets of the organization.
OCTAVE-Allegro Steps

Establish Risk Develop an Identify


Identify Areas of
Measurement Information Information
Concern
Criteria Asset Profile Asset Containers

Identify Threat Select Mitigation


Identify Risks Analyze Risks
Scenarios Approach
OCTAVE-Allegro:
Step1: Establish Risk Measurement Criteria
• The initial step of OCTAVE-Allegro is to establish a way to measure
risk.
• The idea here is that every organization would have a different view
of risk and would place more importance on some aspects than on
others.
• Some of the areas that octave recommends evaluating are:
1. Reputation/Customer Confidence.
2. Financial.
3. Productivity.
4. Safety and Health.
5. Fines and Legal Penalties.
6. User-defined Impact Criteria. Intended to be customized by your organization
OCTAVE-Allegro:
Step2: Develop an Information Asset Profile
• The second step of OCTAVE-Allegro deals with collecting a list of
information assets based on their importance to the organization.
• This list is created by focusing on the concept of identifying a “critical
few” assets by executing a brainstorming session to rank assets based
on a specific criteria.
• Several important activities included in this step are:
1. Documenting the owners.
2. Providing a description of the critical assets.
3. Identifying Confidentiality, Integrity, and Availability (CIA) requirements.
4. Identifying which of the CIA requirements is most important.
5. Rationale as to why the asset is important.
OCTAVE-Allegro:
Step3: Identify Information Asset Containers
• This might be confusing at first, but asset containers are simply assets
that contain information.

• The information being collected here can be categorized into:


1. Technical—Hardware, Processes, Type of Information, Vendor, Partner
Information, etc.
2. Physical—Location of the hardware/data, Data Centers, etc.
3. People—Asset Owners, Technical Contacts, etc.
OCTAVE-Allegro:
Step4: Identify Areas of Concern
• These areas are a descriptive statement that details a real-world condition
or situation that could affect an information asset in your organization.

• OCTAVE has a tendency to use different terminologies, but all this means is
that you start identifying possible weaknesses or vulnerabilities for the
system that is being reviewed.

• Example: On the web server, weak application security practices


(vulnerability) from our developers. Or sensitive HR records left on the
desks in the HR department.
OCTAVE-Allegro:
Step5: Identify Threat Scenarios
• In this step, you focus more on the threat leveraging that
vulnerability thereby creating a threat scenario.
• Example, weak application security practices (vulnerability) from our
developers could lead to potential unauthorized access by hackers
(threat).
• This threat scenario consists of a statement that combines the
following factors:
1. Asset.
2. Access/Means. Other frameworks would call
3. Actor. this process
4. Motive. “building a threat catalog.”
5. Outcome.
OCTAVE-Allegro:
Step6: Identify Risks
• This step identifies the risk for the asset by simply creating a table
listing down the threat and the impact.
• This is represented in the following formula:
• Risk = Threat (condition) + Impact (consequence)
• Example of dentify Risks:
Threat and Weaknesses Impact
On the web server, weak application security our website does not contain any confidential data
practices from our developers could lead to but a public defacement could cause damage to
unauthorized access from external hackers the hospitals reputation as patients or potential
patients may question the overall security of the
organization
OCTAVE-Allegro:
Step7: Analyze Risks
• The analysis computation of OCTAVE-Allegro is a little bit different from
other frameworks as it focuses primarily on impact.
• Other frameworks typically use the “Impact × Likelihood” formula.
• It is not to say that Allegro does not consider likelihood but the likelihood
value is in fact incorporated in a step associated with the selection of
mitigating factors.
• Example :>>
OCTAVE-Allegro:
Step7: Analyze Risks
Table 2.3 illustrates a threat to
impact analysis table that could be
completed. Going through this
analysis helps establish a rationale
to support the assignment of
scores using Octave's impact
scoring worksheets. An example of
what the scoring for this threat
would be is shown in Table 2.4.
OCTAVE-Allegro:
Step8: Select Mitigation Approach
• As mentioned in the previous step, the likelihood or probability is
considered in the mitigation approach. This approach can be seen in
this relative risk matrix (Octave Allegro document).
• This relative risk matrix provides a means to categorize risk.
• The categorized risk will then fall into certain mitigation approaches,
which brings us to the concept of “pools.” In OCTAVE, there are four
pools:
1. Pool 1—Mitigate.
2. Pool 2—Mitigate or Defer.
3. Pool 3—Defer or Accept.
4. Pool 4—Accept.
OCTAVE-Allegro:
Step8: Select Mitigation Approach
• Example, if the risk score falls under “Pool 2,” the organization has the option to
mitigate the risk or defer it to another time. This is a concept that provides a great
deal of flexibility to an organization in its approach to mitigating risk since it
provides options within the mitigation approach category that the risk falls into.
OCTAVE-Allegro Strengths
• Worksheets, decision/criteria matrices, and questionnaires are
provided with the framework. supplementary materials is needed
• Prescriptive though not as prescriptive as the original OCTAVE
framework
• Provides good impact criteria tables.
• The document provided is fairly easy to follow
• The concept of pools and how to categorize risk based on them is a
good method of choosing mitigation approaches.
OCTAVE-Allegro Weakness
• Even if Allegro is the streamlined version of OCTAVE, it is still
relatively long and complex if followed to
• No threat catalog is provided. It uses threat questionnaires which are
very subjective.
• Preparation of threat scenarios assumes that the assessor has good
knowledge of the organization and the system (though this is an
underlying assumption of Allegro), which in some cases may not
possible
• Adjustment based on controls is not explicitly computed.
• Likelihood is not explicitly computed in the risk analysis step but is
part of the probability computation in the selection of mitigation
approach.
OCTAVE-Allegro Links
• Homepage and Download link: [Link]

• OCTAVE-Allegro introduction and documentation:


[Link]

• Original OCTAVE: [Link]

• OCTAVE-S: [Link]
Fair Framework
• The FAIR framework was developed by Risk Management Insight and
has a strong following with several groups including the Open Group
and ISACA.
• The FAIR framework uses the term “stages” to break down its
activities. There are four primary FAIR stages:
• Stage 1: Identify Scenario Components
• Stage 2: Evaluate Loss Event Frequency
• Stage 3: Evaluate Probable Loss Magnitude (PLM)
• Stage 4: Derive and Articulate Risk
Fair Framework
Stage 1: Identify Scenario Components
The first FAIR stage consists of two primary activities:
1. Identify asset at risk: According to FAIR, an asset would be anything that would
have a value or liability. This includes anything, including credentials, applications,
systems and the information within the asset.
2. Identify the threat community: The threat community is the source of the threat. A
threat community is FAIR’s interpretation of what other frameworks refer to as
threat sources, threat agents, or threat actors.
For example, these threat communities could be actual groups of people (e.g. visitors, cleaning
crews, hackers).
Fair Framework
Stage 2: Evaluate Loss Event Frequency
This stage of the FAIR framework is a bit longer than the others. It
essentially has five steps:
1. Threat Event Frequency (TEF)
2. Threat Capability (Tcap) Let see these
3. Estimate Control Strength (CS) steps
4. Derive Vulnerability (Vuln) one by one
5. Derive Loss Event Frequency (LEF)
Threat Event Frequency (TEF)
• FAIR uses a 5 point scale with corresponding frequency ranges from
Very High (>100) to Very Low (<.1 times).
• Example: what would be the Threat Event Frequency for an automated
mechanism (e.g. a worm) attacking an externally facing system such as
a company website?

Using Table 2.6, this would be given


a "Very High" rating as this event
could possibly occur more than 100
times a year (due to the number of
worms that are in the wild).
Threat Capability (Tcap)
• FAIR defines this as probable level of force that a threat agent is
capable of applying against an asset.

• Additionally, it is a measure of the threat agents’ resources and skill


and how it can be effectively applied to the asset.

• All this means is you need to answer this question: What is the
capability of the attacker to conduct the attack?
Threat Capability (Tcap)
• Example: let’s say we have three threat sources: A secretary, a systems
administrator, and a hacker. Who would have the greatest Threat
Capability to perform unauthorized activities on a server?

Using Table 2.7, It is reasonable to


conclude that a systems administrator
would probably be within the top 2%
that could actually do this attack,
followed by a hacker, and then a
secretary.
Estimate Control Strength (CS)
• FAIR defines this as the expected effectiveness of controls, over a
given timeframe, as measured against a baseline level of force or the
assets ability to resist compromise. In other words, how strong are
the controls and protective mechanisms in place to prevent the
attack?
Derive Vulnerability (Vuln)

• FAIR defines this as the probability that an asset will be unable to


resist the actions of a threat agent.

• To obtain this value, you consider two previous values which are the
Threat Capability (Tcap) and the Control Strength (CS). Deriving the
Vuln value is as simple as plotting the Tcap and Control Strength and
finding the point where the two intersects.
Derive Loss Event Frequency (LEF)

• FAIR defines this as the probable frequency, within a given


timeframe, that a threat agent will inflict harm upon an asset.

• Obtaining the LEF is done by simply plotting the TEF and the Vuln and
identifying where the two intersect. The concept here is focused on
determining how likely a threat source would be able to successfully
leverage the vulnerability in a system.
Fair Framework
Stage 3: Evaluate Probable Loss Magnitude (PLM)
• This step is concerned with evaluating the impact if the threat event
does happen. There are two main activities in this stage:
• Estimate Worse Case Scenarios: FAIR defines this step as determining the
threat action that would likely result in a worst-case outcome.

• Estimate Probable Loss Magnitude (PLM): FAIR defines the PLM as the most
likely threat community action or actions. Let see these steps
one by one
Estimate Worse Case Scenarios
Example: Let’s say we are evaluating the
threat of patient records being stolen
from a nursing station.
For this sample threat scenario, we
have chosen disclosure as the worst-
case scenario. Then based on the
magnitude table provided, you simply
assign it to the proper magnitude
category.
So let’s say that if you believe that the
fines due to the disclosure of the
medical records could go up to $10,000
then you would put it in the “SV”
category.
Adding up the values in the table; we
calculate $21,002,000 which falls under
the Sever (SV) rating.
Estimate Probable Loss Magnitude (PLM)
• For example, in the stolen medical records scenario, for all intents
and purposes, the most likely threat could just be “Misuse” which
would have a much lower overall loss magnitude than the worst-case
scenario. The overall PLM will be Moderate (M) since our calculation
is $521,000, which falls within the moderate category.
Fair Framework
Stage 4: Derive and Articulate Risk
• This only entails plotting the Loss Event Frequency (LEF) and the
Probable Loss Magnitude (PLM). The intersection will be the final Risk
score
Fair Strengths and Weakness
• The Strengths
• Very objective, this makes it very defensible and very repeatable.
• Very good for organizations that have strong metrics
• The Weakness:
• Can initially appear to be overwhelming because of the terminologies and
matrices involved
• Some of the criteria are difficult to interpret in a real scenario.
• Might be difficult for organizations with immature programs due to lack of
objective data particularly regarding loss magnitudes
• Might be difficult for inexperienced assessors due to lack of knowledge in
specific areas such as threat frequencies
• Might be difficult to articulate in a cross-disciplinary group
Fair Links
• Website [Link]

• A Draft FAIR Introduction: [Link]


[Link]/Resources/Presentations/FAIR_introduction.pdf

• Basic Risk Assessment Guide:


[Link]
NIST SP800-30 Framework
• The “Risk Management Guide for Information Technology Systems”
or NIST SP800-30 was developed by the National Institute for
Standards and Technology (NIST).
• NIST is a standards organization that is sponsored by the US Federal
Government. It regularly publishes many guidelines and standards
related to all kinds of information security topics from cryptography
to incident response processes.
• The SP800-30 framework uses the term “steps” to break down its
activities. There are nine steps in SP800-30 which are:
NIST SP800-30 Framework steps:

System
Impact Analysis Risk Determination
Characterization

Likelihood Control
Threat Identification
Determination Recommendations

Vulnerability Results
Control Analysis
Identification Documentation
NIST SP800-30 Framework
Step1: System Characterization
• The objective of this step is to create a good picture of what the system is and
the environment that the system resides in and depends on.
• This step assumes that you already have a list of systems on hand. Based on the
framework, the following details should be collected for each asset:
1. Hardware.
2. Software.
3. Interfaces.
Using information gathering techniques:
4. Data & Information.
[Link].
5. Person Support. [Link]-site interviews.
6. System Mission. [Link] Review.
[Link] scanning tools.
7. System and data criticality.
8. System and data sensitivity.
NIST SP800-30 Framework
Step2: Threat Identification
• The objective of this step is to create a threat statement. A threat
statement is a list of threat sources that is applicable to the system.

• A threat source in turn is something that may leverage a weakness in


the system.

• For example, a “hacker” is a threat source as this threat source may


leverage a system or application weakness or vulnerability.
NIST SP800-30 Framework
Step3: Vulnerability Identification
• Identifying vulnerabilities mains put the threat source plus the
vulnerability that leverages it produces what we call a threat and
vulnerability pair.
• Example of a threat and vulnerability pair:
• Threat Source: Hacker.
• Vulnerability: Lack of System Patching.
• Then for each of the threat and vulnerability pairs that have been
identified, a threat action is then created.
• Threat action: A hacker using an exploit against a system vulnerability
and gaining access to the system.
NIST SP800-30 Framework
Step3: Vulnerability Identification
• For vulnerability identification, SP800-30 identifies the following
sources to assist in identifying vulnerabilities:
1. Previous risk assessments.
2. IT system audit reports.
3. Vulnerability Listings.
4. Security advisories.
5. Vendor advisories.
6. CERT (Computer Emergency Response Team).
7. System security testing.
8. Security requirements checklist.
NIST SP800-30 Framework
Step4: Control Analysis
• The main objective of this step is to take into account the current and
planned controls in assessing the likelihood of the vulnerability being
leveraged by a threat source.
• SP800-30 discusses different control methods, control categories, and
analysis techniques but we have found that an effective way to conduct
the analysis is to use the security requirements checklist, the one used to
identify vulnerabilities in the previous step, as a reference to determine
control deficiencies.
NIST SP800-30 Framework
Step5: Likelihood Determination
• SP800-30 provides a three-level likelihood scale for this
determination
NIST SP800-30 Framework
Step6: Impact Analysis
• The main objective of this step is to determine the adverse impact to the
asset if a vulnerability is successfully leveraged by a threat source.

• For impact, SP800-30 primarily focuses on the CIA security triad of


Confidentiality, Integrity and Availability.

• In addition, SP800-30 also focuses on impacts such as loss of public


confidence, loss of credibility, and damage to an organization’s interests as
other possible impact types to consider.
NIST SP800-30 Framework
Step7: Risk Determination
• Risk computation for SP800-30 is traditional and straightforward.
• Risk = Impact × Likelihood
• SP800-30 has provided a risk matrix table to assist in the determination of
risk
NIST SP800-30 Framework
Step8: Control Recommendations
• Once the risk rating is derived from the previous step, control
recommendations are provided to mitigate the risks which are identified.

• NIST also recommends performing a cost benefit analysis to make sure


that the cost of control implementation does not exceed the estimated
loss associated with a given event but it does not pro- vide specific
guidance on this process.
NIST SP800-30 Framework
Step9: Results Documentation
This step just entails putting together an official report or briefing based on the risk
assessment. This report helps senior management, and the mission owners make
decisions on policy, procedures, budget, system operational and management
changes. The report should contain:

1. Threat Sources.
2. Vulnerabilities.

3. Risks Assessed.
4. Recommended Controls Provided.
NIST SP800-30 Strengths
• The framework is open-ended and provides a lot of flexibility to the
assessor. Useful for highly diverse environments.
• Provides good sample interview questions and a sample report outline
(although it is a per asset reporting style).
• Many organizations in the United States, particularly in the federal space,
align to the standard.
• Good discussion regarding the concept of threat and vulnerability pairs.
• The risk mitigation section, though not technically part of a risk
assessment, is very thorough and may be useful for risk management
implementations.
• Inputs and outputs for each of the steps are clearly identified.
NIST SP800-30 Weaknesses
• Not as objective and data driven as other frameworks.
• There is a lack of criteria and decision guides. Some of the matrices
provided in the standard are high level and highly subjective.
• Results will be heavily dependent on the experience and opinions of
the individual executing the assessment leaving it open to
interpretation and challenge.
• Narrative is short and broad and does not provide a lot of details.
Implementation examples are also sparse.
• Threat sources are primarily geared for government and military
scenarios.
ISO 27005 Framework
• ISO 27005 is the “Information Technology—Security Techniques—
Information Security Risk Management” standard released by the
international standards body ISO to provide guidance over
information security risk management processes that are needed for
the implementation of an effective information security management
system (ISMS).
• The ISO 27005 standard has 6 major topic areas.
• ISO 27005 has 3 steps for the section dealing with risk assessment:
Risk Identification, Risk Estimation, and Risk Evaluation.
ISO 27005 standard (6 major topics)

Context
ISR Assessment. ISR Treatment.
Establishment.

ISR ISR Monitoring


ISR Acceptance.
Communication. and Review.
ISO 27005 standard steps
Step1: Risk Identification
Risk identification consists of 5 main activities, which are indication of :
1. Assets

2. Threats

3. Existing Controls
4. Vulnerabilities

5. Consequences
ISO 27005 standard steps
Step2: Risk Estimation
The risk estimation phase consists of three primary activities:
1. Assessment of consequences — The main objective of this activity is to assess the
impact cause by an incident scenario.

2. Assessment of incident likelihood—The main objective of this activity is to assess


the likelihood of an incident scenario using qualitative or quantitative estimation
techniques

3. Level of risk estimation—The main objective of this step is to provide values ot the
likelihood and consequences, which will ultimately result in a risk value.
ISO 27005 standard steps
Step3: Risk Evaluation.
• This final step is is to prioritize the risks that are identified based on
the risk evaluation criteria and the risk acceptance criteria.

• Determining the priority for these risks would allow the following risk
management actions to be determined:
• Whether an activity should be undertaken.

• Priorities of risk treatment considering estimated levels of risk.


ISO 27005 standard Strengths
• The Annexes provided in ISO 27005 provide very useful information
and examples.
• ISO 27005 provides good examples of a threat catalog,
vulnerabilities, and various computation and plotting techniques for
rating risk
• ISO is an international standard and stakeholders and auditors would
be hard pressed to contradict your approach
• It is very flexible. As with most ISO standards, ISO 27005 is fairly high
level and focuses on objectives, which leaves organizations a lot of
“wiggle-room” in terms of how the standard is implemented
ISO 27005 standard Weaknesses

• Very open to interpretation. Since it is not prescriptive,


there is a higher risk that different organizations and
different assessors would conduct an activity differently.
• Similarly, stakeholders and auditors might also have
different interpretations of the standards
A Comparison of the Major Activities for the Four
Frameworks
Summary
There are numerous information security risk assessment frameworks which
are the popular ones in the United States are
• OCTAVE

• FAIR
• NIST SP800-30.

• ISO 27005

This chapter provided a primer on risk assessment frameworks and a quick


preview of the methodology that we will be going through in the course.

You might also like