Please create a portfolio – 1000 words minimum about the Yahoo Security Breaches happened in the last decade
Website –>
https://www.cshub.com/attacks/articles/incident-of-the-week-multiple-yahoo-data-breaches-across-4-years-result-in-a-1175-million-settlement
Please use the attached white papers and technical documents as references to write about how a breach like that can be prevented for your organization?
Review of a security incident or threat, describing it in-depth and proposing controls for future use.
What measures you can take?
How you can approach an incident like that in the first place?
Criteria:
Minimum 2 references
References can only be technical documents and white papers or journals
APA Citation Format
I have attached some white papers for your reference.
Feel free to use more but make sure its only technical documents, white paper or journals.
Due this Friday 04/10/2020
NIST Technical Note 2051
Cybersecurity Framework Smart Grid
Profile
Jeffrey Marron
Avi Gopstein
Nadya Bartol
Valery Feldman
This publication is available free of charge from:
https://doi.org/10.6028/NIST.TN.205
1
NIST Technical Note 2051
Cybersecurity Framework Smart Grid
Profile
Jeffrey Marron
Applied Cybersecurity Division
Information Technology Laboratory
Avi Gopstein
Office of Smart Grid and Cyber-Physical Systems
Engineering Laboratory
Nadya Bartol
Boston Consulting Group
Bethesda, MD
Valery Feldman
HII Mission Driven Innovative Solutions (HII-MDIS)
Annapolis Junction, MD
This publication is available free of charge from:
https://doi.org/10.6028/NIST.TN.20
51
July 201
9
U.S. Department of Commerce
Wilbur L. Ross, Jr., Secretary
National Institute of Standards and Technology
Walter Copan, NIST Director and Undersecretary of Commerce for Standards and Technology
Certain commercial entities, equipment, or materials may be identified in this
document in order to describe an experimental procedure or concept adequately.
Such identification is not intended to imply recommendation or endorsement by the
National Institute of Standards and Technology, nor is it intended to imply that the
entities, materials, or equipment are necessarily the best available for the purpose.
National Institute of Standards and Technology Technical Note 2051
Natl. Inst. Stand. Technol. Tech. Note 2051, 142 pages (July 2019)
CODEN: NTNOEF
This publication is available free of charge from:
https://doi.org/10.6028/NIST.TN.2051
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
i
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Abstract
The Smart Grid Profile applies risk management strategies from the Framework for
Improving Critical Infrastructure Cybersecurity (Cybersecurity Framework) to the smart grid
and will serve as a foundation for refinements to support new grid architectures. The Profile
provides cybersecurity risk management guidance to power system owners/operators by
prioritizing cybersecurity activities based on their effectiveness in helping power system
owners/operators achieve common high-level business objectives for the smart grid. The
Profile also provides a list of considerations relevant to the challenges power system
owners/operators may experience as they implement these cybersecurity activities in
infrastructures with high concentrations of distributed energy resources (DERs).
Key words
Architecture; business/mission objectives; cybersecurity; Cybersecurity Framework (CSF);
distributed energy resource (DER); grid modernization; Pacific Northwest National
Laboratory (PNNL); Profile; reliability; resilience; safety; smart grid.
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
ii
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Table of Contents
Executive Summary …………………………………………………………………………………………… 1
Importance of Cybersecurity in the Smart Grid ………………………………………………….
3
Overview of the Cybersecurity Framework …………………………………………………………
5
Smart Grid Profile ……………………………………………………………………………………………
10
Smart Grid Business/Mission Objectives ………………………………………………………….. 1
2
Future Work …………………………………………………………………………………………………… 3
7
……………………………………………………………………………………………………………… 3
8
…………………………………………………………………………………………..
40
………………….
41
List of Tables
Table 1 – Cybersecurity Framework Functions and Categories …………………………………. 7
Table 2 – Cybersecurity Framework Subcategory Examples ……………………………………… 8
Table 3 – IDENTIFY Subcategories Prioritization and Considerations ……………………..
15
Table 4 – PROTECT Subcategories Prioritization and Considerations ……………………..
22
Table 5 – DETECT Subcategories Prioritization and Considerations ………………………..
30
Table 6 – RESPOND Subcategories Prioritization and Considerations ……………………..
33
Table 7 – RECOVER Subcategories Prioritization and Considerations ……………………. 3
6
List of Figures
Fig. 1 – Cybersecurity Framework Profile Creation Process ………………………………………. 9
Fig. 2 – Example of Considerations for Power System Owners/Operators ………………… 10
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
1
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Executive Summary
The U.S. electric power grid is undergoing modernization to make the grid “smart.” The smart
grid utilizes intelligent and distributed technologies to make the power grid more reliable and
resilient to disruptions. While there are clear benefits to this evolution, the modernization effort
is not easy. Power system owners/operators1 will face numerous challenges as they strive to
modernize their own capabilities, while also interfacing and co-existing with other power system
owners/operators at different stages of the modernization process. Along with the benefits of the
smart grid, there are cybersecurity risks that need to be considered to ensure a safe, effective grid
transformation.
The Smart Grid Profile applies risk management strategies from the Framework for Improving
Critical Infrastructure Cybersecurity (Cybersecurity Framework, explained in Sec. 3) to the
smart grid and will serve as a foundation for refinements to support new grid architectures. The
Profile provides cybersecurity risk management guidance to power system owners/operators by
prioritizing2 cybersecurity activities based on their effectiveness in helping power system
owners/operators achieve common high-level business objectives for the smart grid. These high-
level business objectives are:
• Maintain safety
• Maintain power system reliability
• Maintain power system resilience
• Support grid modernization
The Profile also provides power system owners/operators with considerations3 relevant to the
challenges they may experience as they implement these cybersecurity activities in
infrastructures with high concentrations of distributed energy resources (DERs).
The following are some examples of how power system owners/operators may use the Smart
Grid Profile:
• Prioritizing organizational cybersecurity activities to align with available resources
• Enabling better informed decision making about cybersecurity activities by
referencing the considerations listed for each cybersecurity activity
• Conveying cybersecurity requirements to an external entity such as a service provider
• Gauging their organizational cybersecurity posture against the prioritized
cybersecurity activities
In smart grid environments, power system owners/operators rely on and interact with a larger
community of diverse third parties than in traditional grid environments. These third parties
1 In this Profile, “power system owners/operators” refers primarily to distribution grid owners rather than customers and the assets that they own
“behind the meter.”
2 The prioritization of cybersecurity activities in this Profile consists of a binary “yes/no” determinations and is discussed in more detail in Sec.
4
3 A consideration is an interest in something relevant to one or more stakeholders. Considerations cover both things that are of interest for
positive or negative reasons. Considerations should be used to drive requirements. See Sec. 4 for more information about the use of
considerations in this Profile.
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
2
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
include but are not limited to vendors, suppliers, contractors, distributed generation
owners/operators, and consumers. Many of the cybersecurity activities that power system
owners/operators traditionally implemented within their own infrastructures will need to be
extended to the third party-owned devices and infrastructures that interconnect with the power
system infrastructure. Furthermore, supply chain risk management considerations are relevant in
these relationships especially when smart grid devices and systems are interconnecting with third
parties. In addition to using the Cybersecurity Framework to help assess and manage risks
associated with third parties, power systems owners/operators may consult Cybersecurity
Procurement Language for Energy Delivery Systems [10] and Utilities Telecom Council (UTC)
white paper [11] for more specific guidance.
Notes to Readers:
The smart grid is a complex system composed of a large community of diverse parties, each with
varied interests and perspectives. This Profile is focused on cybersecurity needs of smart grid
owners/operators and therefore may not be sufficiently useful by itself to all the diverse parties in
the smart grid.
The Profile indicates those cybersecurity activities which can directly help power system
owners/operators achieve high-level business objectives. However, the Profile’s greatest value
may be the description of considerations3 that power system owners/operators may have to
address as they implement the cybersecurity activities. The Profile can also help
owners/operators evaluate how the responsibilities for these considerations change as they
modernize equipment and as actors take on new roles within the power system.
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
3
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Importance of Cybersecurity in the Smart Grid
The U.S. electric power grid has provided inexpensive, reliable power for decades. Even as
electric utilities incorporate new technologies and accommodate changing customer
expectations, the basic structure of the grid remains broadly consistent with the first electric
systems build more than a century ago. In the traditional grid, power flows in one direction—
from centralized generation facilities, through transmission lines, and to customers via
distribution utilities. The centralized design has historically brought efficiencies in facilities and
operations but has also made the grid vulnerable to both malicious actions and natural disasters.
Also new technologies and operational solutions—and their unique vulnerabilities—are
becoming more important as evolving demands from economic development to diversifying
customer expectations come in conflict with the physical constraints of decades old
infrastructure.
The U.S. electric power grid is undergoing modernization to make the grid “smart.” In contrast
to the traditional grid, a smart grid features intelligent and distributed technologies such as
advanced metering infrastructure (AMI) and automated distribution management systems that
will enable the grid to incorporate new technologies and resources. By enhancing data
utilization at the grid-edge to accommodate bi-directional power flows and other system
dynamics inherent to extensive adoption of distributed energy resources (DERs), the grid will
become more resilient to disruptions and resilient in the face of attack [3]. As observability and
control extend to the grid-edge, customers and other participants will see new economic
opportunities through access to wholesale and other energy markets. However, these
opportunities carry obligations not previously assigned to customers to support the overall cyber
and operational health of the grid.
While the benefits of the smart grid are clear, it will not be an easy modernization effort.
Transitioning to the future grid has been compared to the building of the interstate highway
system [3]. In the same way that the interstate highway system took decades to complete,
modernization of the grid will take coordinated planning and execution that evolves over time.
There will be milestones in which the grid will become “smarter,” but the full realization of the
smart grid will take a decade or more. Along the way, there will be challenges for power system
owners/operators as they both strive to modernize their own capabilities while interfacing and
co-existing with other power system owners/operators that are at different stages of the
transformation process. The fact that the grid is already in use and pervasive in modern society,
and cannot be taken offline for this modernization effort, increases the complexity of these
challenges.
The modernized grid will consist of a variety of different architectures.4 Describing such
architectures to guide technology implementation is important when planning for an effort as
vast as grid modernization. Grid architectures—using the concepts of system architecture,
network theory, and control theory—define the components, structure, behavior, qualities,
properties, interactions, and limits of the electric power grid. As a high-level description of a
grid, architectures provide several benefits: they help simplify complex grid interactions to
understand and reduce risk; provide a shared vision of the future grid; and identify barriers to
4 As a high-level description of a grid, architectures define the components, structure, behavior, qualities, properties, and limits of the electric
power grid. This Profile explores a High-DER smart grid architecture developed by the Department of Energy’s Pacific Northwest National
Laboratory (PNNL). PNNL is developing other architectures to express different structural approaches to the smart grid
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
4
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
achieving that vision. The Department of Energy’s (DoE) Pacific Northwest National Laboratory
(PNNL) is one group developing high-level architectures of the smart grid. These architectures
describe some of the stages along the grid transformation—from the near-term modernization
that still relies on a conventional grid backbone to end states involving extensive automation and
high-penetrations of DERs.
Despite the considerable benefits of the future grid, many aspects of the smart grid have
cybersecurity risks that need to be considered to ensure a safe, effective grid transformation. The
modern grid should be safe, reliable and resilient. A resilient grid has to be able to withstand not
just hazards, human errors, hardware failure, and software bugs, but also cyber events as well.
This document explores evolving grid architectures—including the high DER penetration
architecture described by PNNL—and provides guidance for power system owners/operators to
manage cybersecurity risks. To that end, the document draws heavily from the NIST Framework
for Improving Critical Infrastructure Cybersecurity (Cybersecurity Framework, discussed in Sec.
3 below), helping power system owners/operators prioritize those cybersecurity activities that
most align with power system goals of safety, reliability, resilience, and grid modernization. The
document also provides considerations relevant to the challenges that power system
owners/operators may face when implementing the cybersecurity activities.
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
5
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Overview of the Cybersecurity Framework
Recognizing the national and economic security of the United States depends on the reliable
functioning of critical infrastructure, the President issued Executive Order (EO) 13636,
Improving Critical Infrastructure Cybersecurity, in February 2013. The EO directed NIST to
work with stakeholders to develop a voluntary framework—based on existing standards,
guidelines, and practices—for reducing cybersecurity risks to critical infrastructure.
Created through collaboration between industry and government, the Cybersecurity Framework
seeks to promote the protection of critical infrastructure. The prioritized, flexible, and risk-
based5 approach of the Cybersecurity Framework helps owners and operators of critical
infrastructure manage cybersecurity-related risk. Although it was designed for organization that
are part of the U.S. critical infrastructure, many other organizations6 in the private and public
sectors (including federal agencies) are using the Cybersecurity Framework.
The Cybersecurity Framework consists of three main components: the Core7, Implementation
Tiers, and Profiles.
• The Framework Core provides a catalog of desired cybersecurity activities and
outcomes8 using common language. The Core guides organizations in managing and
reducing their cybersecurity risks in a way that complements an organization’s
existing cybersecurity and risk management processes.
• The Framework Implementation Tiers provides context on how an organization views
cybersecurity risk management. The Tiers help organizations understand whether
they have a functioning and repeatable cybersecurity risk management process and
the extent to which cybersecurity risk management is integrated with broader
organizational risk management decisions.
• Framework Profiles are a customization of the outcomes of the Core to align with an
organization’s requirements. Profiles are primarily used to identify and prioritize
opportunities for improving cybersecurity at an organization
The Core presents industry standards, guidelines, and practices within five concurrent and
continuous Functions—Identify, Protect, Detect, Respond, and Recover. Each of these Functions
is described below.
Identify – Develop the organizational understanding to manage cybersecurity risk to systems,
assets, data, and capabilities. The activities in the Identify Function are foundational for effective
5 Risk-based here is differentiated from a compliance-based approach to managing cybersecurity risk. A compliance-based approach often
focuses on defining a set of requirements broadly applicable to all organizations. A risk-based approach recognizes that each organization has
unique threats and risks and enables organizations to prioritize cybersecurity activities according to their environment, requirements, and
budgetary considerations.
6 This document uses the general word “organization” to show that the Cybersecurity Framework may be used by private businesses, government
agencies, academia, etc.
7 Elements of the Cybersecurity Framework—including Core, Implementation Tiers, Profile, Function, Category, and Subcategory—are normally
capitalized and will be capitalized throughout this document
8 The word “outcomes” is used because the Cybersecurity Framework focuses on the “what” not the “how.” In other words, the emphasis is on
the cybersecurity outcomes that the organization wants to achieve, but not how they will achieve it. The Informative References described on p.
7 help organizations with the “how.”
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
6
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
use of the Cybersecurity Framework, enabling an organization to focus and prioritize its efforts,
consistent with its risk management strategy and business needs.
Protect – Develop and implement the appropriate safeguards to ensure delivery of critical
infrastructure services. The activities in the Protect Function support the ability to limit or
contain the impact of a potential cybersecurity event.
Detect – Develop and implement the appropriate activities to identify the occurrence of a
cybersecurity event. The activities in the Detect Function enable timely discovery of
cybersecurity events.
Respond – Develop and implement the appropriate activities to take action regarding a detected
cybersecurity event. The activities in the Respond Function support the ability to contain the
impact of a potential cybersecurity event.
Recover – Develop and implement the appropriate activities to maintain plans for resilience and
to restore any capabilities or services that were impaired due to a cybersecurity event. The
activities in the Recover Function support timely recovery to normal operations to reduce the
impact from a cybersecurity event.
When considered together, these Functions provide a high-level, strategic view of the lifecycle of
an organization’s management of cybersecurity risk. The Framework Core then identifies
underlying Categories and Subcategories for each Function. The 108 Subcategories are the
discrete cybersecurity outcomes that are organized into 23 Categories like “Asset Management”
or “Supply Chain Risk Management.” Table 1 shows the 5 Functions and 23 Categories of the
Core.
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
7
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Table 1 – Cybersecurity Framework Functions and Categories
Function
Unique
Identifier
Function
Category
Unique
Identifier
Category
ID
Identify
ID.AM Asset
Management
ID.BE Business Environment
ID.GV
Governance
ID.RA Risk Assessment
ID.RM Risk Management
Strategy
ID.SC Supply Chain Risk Management
PR
Protect
PR.AC
Access Control
PR.AT Awareness and Training
PR.DS Data Security
PR.IP Information Protection Processes and Procedures
PR.MA
Maintenance
PR.PT Protective Technology
DE
Detect
DE.AE Anomalies and Events
DE.CM Security Continuous Monitoring
DE.DP Detection Processes
RS
Respond
RS.RP Response Planning
RS.CO
Communications
RS.AN
Analysis
RS.MI
Mitigation
RS.IM
Improvements
RC
Recover
RC.RP
Recovery Planning
RC.IM Improvements
RC.CO Communications
Informative References—such as existing standards, guidelines, and practices—provide
practical suggestions for how to achieve the desired outcome of each Subcategory. An example
of two Subcategories, along with applicable Informative References, within the Supply Chain
Risk Management Category is shown in Table 2.
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
8
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Table 2 – Cybersecurity Framework Subcategory Examples
Function Category Subcategory Informative
References
Identify
(ID)
Supply Chain
Risk
Management
(ID.SC):
The organization’s
priorities, constraints,
risk tolerances, and
assumptions are
established and used to
support risk decisions
associated with
managing supply
chain risk. The
organization has
established and
implemented the
processes to identify,
assess and manage
supply chain risks.
ID.SC-1: Cyber supply chain
risk management processes are
identified, established, assessed,
managed, and agreed to by
organizational stakeholders
CIS CSC 4
COBIT 5 APO10.01, APO10.04, APO12.04,
APO12.05, APO13.02, BAI01.03, BAI02.03,
BAI04.02
ISA 62443-2-1:2009 4.3.4.2
ISO/IEC 27001:2013 A.15.1.1, A.15.1.2,
A.15.1.3, A.15.2.1, A.15.2.2
NIST SP 800-53 Rev. 4 SA-9, SA-12, PM-9
ID.SC-2: Suppliers and third
party partners of information
systems, components, and
services are identified,
prioritized, and assessed using a
cyber supply chain risk
assessment process
COBIT 5 APO10.01, APO10.02, APO10.04,
APO10.05, APO12.01, APO12.02,
APO12.03, APO12.04, APO12.05,
APO12.06, APO13.02, BAI02.03
ISA 62443-2-1:2009 4.2.3.1, 4.2.3.2, 4.2.3.3,
4.2.3.4, 4.2.3.6, 4.2.3.8, 4.2.3.9, 4.2.3.10,
4.2.3.12, 4.2.3.13, 4.2.3.
14
ISO/IEC 27001:2013 A.15.2.1, A.15.2.2
NIST SP 800-53 Rev. 4 RA-2, RA-3, SA-
12, SA-14, SA-15, PM-9
Note that the Subcategory outcomes are organized according to Functions and Categories and are
not prioritized within the Core. Each organization has unique requirements including risk
tolerance and budget. Therefore, the prioritization of the Subcategory outcomes will vary from
one organization to the next. This prioritization of Subcategory outcomes is the essence of a
Profile.
One way to create a Profile is depicted in Fig. 1. In the center of the figure are the
108
cybersecurity Subcategory outcomes of the Core. As input to the evaluative process, an
organization considers its high-level business objectives; any cybersecurity requirements through
policy, legislation, and regulations; and any unique technical or environmental threats. The
Subcategories which will best help the organization achieve its business objectives, meet
cybersecurity requirements, and address technical and environmental threats are prioritized. For
each prioritized Subcategory outcome, the Informative References of the Core can be used to
identify specific technical guidance or controls catalogs that can help the organization achieve
the cybersecurity outcome.
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
9
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Fig. 1 – Cybersecurity Framework Profile Creation Process
Profiles can be created for individual organizations or even parts of an organization (e.g.,
organizational units such as Finance or Human Resources). Increasingly, however, Profiles are
being created for entire critical infrastructure sectors (e.g., Financial Services sector) or for sub-
sectors (e.g., Oil and Natural Gas sub-sector within the Energy sector). Since organizations
within a sector or sub-sector share many of the same business objectives and regulatory
requirements, creating high-level Profiles for the sector/sub-sector can provide a common
starting prioritization of cybersecurity activities for all organizations within the sector/sub-sector.
These Profiles can serve as a starting point, making it easier for organizations to begin
incorporating cybersecurity and can also be used to provide a baseline of cybersecurity for
organizations within a sector or sub-sector. Individual organizations can take the sector/sub-
sector Profile and tailor it to address requirements, business objectives, or environmental threats
unique to them.
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
10
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Smart Grid Profile
The Smart Grid Profile is designed to be broadly applicable to power system owners/operators of
an infrastructure composed of high penetrations of DER. It is intended to help power system
owners/operators prioritize9 cybersecurity activities based on high-level business objectives that
are perceived as common throughout the smart grid. The Profile also presents considerations for
power system owners/operators as they seek to achieve the outcome of each Subcategory. In
addition to providing justifications for a Subcategory’s selection, the considerations highlight
challenges that power system owners/operators may encounter as they attempt to achieve the
Subcategory outcomes. Figure 2 below, a snippet from the Profile, illustrates considerations for
power system owners/operators for Subcategories ID.AM-1 Physical devices and systems within
the organization are inventoried and ID.AM-2 Software platforms and applications within the
organization are inventoried.
Fig. 2 – Example of Considerations for Power System Owners/Operators
While this Profile is based on a set of business objectives thought to be broadly applicable across
the smart grid, individual power system owners/operators may need to tailor their selection of
Subcategories. For example, a power system owner/operator may have additional business
objectives or may be subject to state or local regulatory requirements not considered in this
Profile. These requirements may impact the power system owner/operator’s prioritization of
Subcategory outcomes.
Development of this Smart Grid Profile consisted of the following steps:
1. Reviewed relevant literature, including available PNNL smart grid architecture
documentation and NIST publications [4], [5], [6], [7].
2. Interviewed industry experts from power system owners/operators and electric power
industry think tanks.
3. Developed a set of common business objectives based on the literature review and the
interviews (discussed in greater detail in Sec. 5).
9 The Subcategory prioritization in this document consists of a binary “yes/no” determination rather than a numerical prioritization (e.g., a rating
scale from 1 to 5). Our intent is to identify those cybersecurity outcomes which will directly help power system owners/operators achieve the
listed business objectives. More detailed prioritization of Subcategory outcomes will be highly dependent on each organization’s unique risk
tolerance, requirements, and budget constraints.
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
11
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
4. Analyzed NIST Cybersecurity Framework v1.1 Framework Core Subcategories in
relation to the identified business objectives. Identified which Subcategories directly
assist power system owners/operators in achieving the business objectives identified
in Sec. 5 of this document.
5. For each Subcategory, described the rationale for its prioritization and/or composed
relevant implementation considerations for power system owners/operators.
The following are some examples of how power system owners/operators may use the Smart
Grid Profile:
• Prioritizing organizational cybersecurity activities to align with available resources.
• Enabling better informed decision making about cybersecurity activities by
referencing the considerations listed for each Subcategory activity.
• Conveying cybersecurity requirements to an external entity such as a service
provider.
• Gauging their organizational cybersecurity posture against the prioritized
cybersecurity activities
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
12
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Smart Grid Business/Mission Objectives
Development of the Smart Grid Profile included identification of common business objectives
for the grid. These business objectives, which also accounted for regulatory and cybersecurity
requirements, provide a useful context for identifying and managing applicable cybersecurity
risks and mitigations. Four common business objectives for power systems stakeholders were
identified: Maintain Safety; Maintain Power System Reliability; Maintain Power System
Resilience; and Support Grid Modernization.
These business objectives are not listed in prioritized order and appear robust to changes in grid
architecture or technology.
Maintain Safety
Safety is an overarching concern of power system management and seeks to minimize the impact
to human life, equipment, and the environment from cybersecurity risks. This requirement aims
to manage cybersecurity risks to safety.
Maintain Power System Reliability
Reliability is the ability to deliver stable and predictable power in expected conditions or, in case
of power system failure, the ability to restore to a normal operational mode. For this Profile,
reliability includes both sustained interruptions and momentary interruptions and can be
measured in outage duration, frequency of outages, system availability, and response time.
Reliability is intended to ensure predictable system performance (the system operates as
intended) in sets of predetermined conditions which is defined as the system’s expected
operating environment. This requirement aims to manage cybersecurity risks to power system
reliability.
Maintain Power System Resilience
Resilience is the ability to prepare for and adapt to changing conditions and withstand and
gracefully recover from deliberate attacks, accidents, or naturally occurring threats or incidents.
Resiliency engineering focuses on situations where the environmental conditions have
deliberately been manipulated by malefactors [8]. This requirement aims to manage
cybersecurity risks to power system resilience.
In regard to power systems, resilience is the ability of the system to withstand instability,
unexpected conditions or faults, and gracefully return to predictable, but possibly degraded,
performance.
Support Grid Modernization
The integration of smart devices into the grid should provide required power to customers,
deliver reliable and accurate measurement data to control systems, and cause minimum
disruptions when devices fail. These smart devices are cyber-physical systems that are
increasingly being interconnected to the power distribution system to provide energy and
ancillary services. However, distribution power systems were not originally designed to handle
dispersed sources of generation, and these advanced systems may not be under direct
management of or subject to the security policies and procedures of the power system
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
13
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
owner/operator [9]. Additionally, grid modernization efforts will take decades. During this
time, legacy and new devices will need to co-exist and interact safely and securely. This
requirement supports integration of smart technologies with the traditional grid by managing
cybersecurity risks to power system, including integrity and timeliness of data and control
commands.
To align cybersecurity activities with overall organizational mission success, Subcategories were
identified and prioritized to support these business objectives. This is intended to help power
system owners/operators prioritize actions and resources.
The tables below highlight Subcategory outcomes that directly support achieving the identified
business objectives. The selection of Subcategories for each business objective was based on a
broad range of considerations for Smart Grid architectures. The most critical Subcategories may
differ for individual power system owners/operators.
While not all Subcategories were selected for each business objective, users of this document are
encouraged to consider all Subcategories in light of their own risk tolerance, risk appetite, asset
management approach, and specific business objectives. For the purposes of this document,
when a Subcategory is not selected for a specific business objective, it indicates that the activity
may not directly assist power system owners/operators in meeting the specific business
objective(s).
In developing this profile, the following considerations were identified:
• Most of the Identify Function addresses organizational activities. As a result, most of
the Categories and Subcategories within the Identify Function are executed at the
organizational level, rather than at a system level or specific security architecture
level. These Subcategory outcomes provide overall direction for security activities
and apply broadly to all business goals. For this reason, nearly every Identify
Subcategory was selected as directly supporting the achievement of the business
objectives. Where a Subcategory was not selected, a rationale was provided
explaining the decision.
• Whether an organization’s infrastructure is traditional or modernized, the
recommendations in the Cybersecurity Framework and in this Profile follow
cybersecurity best practices. Power system owners/operators should review each of
the prioritized Subcategories in light of their own risk management processes and
determine whether and how those Subcategories apply to their environment. Power
system owners/operators should examine each Subcategory in terms of the impact not
only to their organization, but also to interconnected organizations and surrounding
communities. The recommendations in this Profile should be considered within the
context of the size and interconnectedness of the power system owner/operator.
• In Smart Grid environments, power system owners/operators rely on and interact with
a larger community of diverse third parties than in the traditional grid environments.
These third parties include but are not limited to vendors, suppliers, contractors,
distributed generation owners/operators, and consumers. Many of the Subcategories
that power system owners/operators traditionally implemented within their own
infrastructures will need to be extended to the third party-owned devices and
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
14
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
infrastructures that interconnect with the power system infrastructure. Furthermore,
supply chain risk management considerations are important in these relationships
especially when smart grid devices and systems interoperate with third parties. In
addition to using a variety of Subcategories in this document to help manage risks
associated with third parties, power system owners/operators may consult
Cybersecurity Procurement Language for Energy Delivery Systems [10] and Utilities
Technology Council (UTC) white paper [11] for more specific guidance.
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
15
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Identify – The Identify Function is critical in the development of the foundation for cybersecurity management, and in the
understanding of cyber risk to systems, assets, data, and capabilities. This Function guides the owner/operator in the development of
the foundation for cybersecurity management, and in the understanding of cyber risk to systems, assets, data, and capabilities. The
activities in Asset Management, Business Environment, Risk Assessment, Risk Management Strategy, and Supply Chain Risk
Management are the primary security areas that address protections for the four business objectives. The Subcategories below are
derived from the Cybersecurity Framework Core, which includes descriptions and informative references for each Subcategory.
Table 3 – IDENTIFY Subcategories Prioritization and Considerations
Maintain
Safety
Maintain
Reliability
Maintain
Resilience
Support Grid
Modernization
Considerations for Power System Owners/Operators
Category Subcategories
Asset
Management
ID.AM-1 ID.AM-1 ID.AM-1 ID.AM-1
Knowing hardware assets is critical for maintaining safety,
reliability, and resilience, as well as facilitating the transition to
the modern grid. Legacy and modernized assets10 need to be
known and understood. As modernized grids become more
distributed, power system owners/operators need to be
accountable for all distributed assets that they own.
ID ID.AM-2 ID.AM-2 ID.AM-2 ID.AM-2
Knowing software assets is critical for maintaining reliability, and
resilience, as well as facilitating the transition to the modern
grid. Legacy and modernized assets need to be known and
understood. This especially applies to modernized assets
because the sophisticated logic that they execute is driven by
software.
ID.AM-3 ID.AM-3 ID.AM-3 ID.AM-3
Understanding communication and data flows is important to
ensure reliability and resilience. Communications networks are
critical for modernized grids, and understanding the different
types of data flows (control, monitoring, and management) will
provide critical information for managing those flows within
modernized infrastructures and between modernized and
traditional infrastructure.
10 Modernized assets/devices refers to power system devices that utilize two-way communication technologies and advanced sensing capabilities to help improve grid operations.
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C2
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C2
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C2
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C2
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C8
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C8
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C8
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C8
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C14
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C14
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C14
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C14
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
16
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Maintain
Safety
Maintain
Reliability
Maintain
Resilience
Support Grid
Modernization
Considerations for Power System Owners/Operators
Category Subcategories
ID.AM-4 ID.AM-4 ID.AM-4 ID.AM-4
The presence of external information systems may have many
impacts on the power grid. Grid reliability and resilience may be
impacted if power system owners/operators are not aware of all
power systems, customer-owned devices, and any other third-
party systems connected to the distribution system. With
respect to supporting grid modernization, traditional and
modernized parts of the grid will exist side by side within a single
power system owner/operator and across power system
ownership lines. Awareness of external information systems
that manage both traditional and modernized components is
important to assure security of both Information Technology (IT)
and Operational Technology (OT) infrastructures.
ID.AM-5 ID.AM-5 ID.AM-5 ID.AM-5
Power systems contain many types of resources, including
devices, data, personnel, and software. Resources directly
involved in the distribution of power should be prioritized ahead
of business systems.
ID.AM-6 ID.AM-6 ID.AM-6 ID.AM-6
Identifying all power system stakeholders and their roles and
responsibilities with respect to maintaining and restoring power
is critical to all four business requirements.
Business
Environment
ID.BE-1 ID.BE-1 ID.BE-1 ID.BE-1
“Supply chain” in this Subcategory includes IT and OT products
and services business partners, and other relevant third parties
that support power delivery. As such it impacts the reliable flow
of power and resiliency efforts including the flow of power from
modernized parts of the grid.
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C19
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C19
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C19
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C19
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C23
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C23
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C23
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C23
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C28
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C28
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C28
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C28
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C33
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C33
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C33
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C33
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
17
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Maintain
Safety
Maintain
Reliability
Maintain
Resilience
Support Grid
Modernization
Considerations for Power System Owners/Operators
Category Subcategories
ID.BE-2 ID.BE-2 ID.BE-2 ID.BE-2
Power system owners/operators should understand their
organization’s placement in the grid infrastructure in order to
manage potential cascading effects on the grid. The magnitude
of potential cascading effects should be understood. Because
the modernized grid incorporates distributed generation, the
points of integration of distributed resources with the larger grid
should be well understood. These pointes of integration may
include generation, transmission, distribution, customers, and
third-party owners/operators of distributed resources.
ID.BE-3 ID.BE-3 ID.BE-3 ID.BE-3
Power system owners/operators have a variety of state and local
regulatory requirements that influence their mission and
objectives. See ID.GV-3.
ID.BE-4 ID.BE-4 ID.BE-4 ID.BE-4
Understanding power system dependencies helps maintain
reliability and resilience. It also facilitates grid modernization
through providing necessary information to plan and implement
grid modernization initiatives. Having a thorough understanding
of dependencies within the power system can also improve
safety. Identify all sources and loads that require power.
Understand information about the loads, sources, and power
delivery network at any given time. Use this information to
control the flow of power from source to loads.
ID.BE-5 ID.BE-5 ID.BE-5 ID.BE-5
Power system owners/operators should understand and
implement the specific requirements to ensure resilient
operation of the power system.
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C36
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C36
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C36
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C36
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C39
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C39
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C39
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C39
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C42
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C42
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C42
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C42
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C45
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C45
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C45
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C45
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
18
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Maintain
Safety
Maintain
Reliability
Maintain
Resilience
Support Grid
Modernization
Considerations for Power System Owners/Operators
Category Subcategories
Governance
ID.GV-1 ID.GV-1 ID.GV-1 ID.GV-1
Information security policy drives a set of coherent security
requirements throughout the organization. In this context,
security policy should support safety, reliability, resilience,
privacy, and other related concerns. Also within this context,
grid components are cyber-physical systems (CPS) themselves,
composed into a more complex, networked cyber-physical
system of systems. NIST CPS Public Working Group (PWG)
Framework provides a set of relevant concerns. Organizational
informational security policy should address OT and IT
environments and how they integrate, the complexity of
external partnerships, as well as cover both traditional and
modernized environments.
ID.GV-2 ID.GV-2 ID.GV-2 ID.GV-2
Information security roles and responsibilities and their
coordination with external partners directly affect all
requirements. In the context of the modernized grid, external
parties include the owners of distributed resources.
ID.GV-3 ID.GV-3 ID.GV-3 ID.GV-3
Legal and regulatory requirements regarding cybersecurity are
especially applicable in the highly regulated critical infrastructure
environment of electric power generation, transmission, and
distribution. The modernized grid has additional regulatory
requirements that should be considered here.
ID.GV-4 ID.GV-4 ID.GV-4 ID.GV-4
Because the grid is a large cyber-physical system, governance
and risk management processes should address all risks, not just
cybersecurity.
Risk
Assessment
ID.RA-1 ID.RA-1 ID.RA-1 ID.RA-1
Identifying and documenting asset vulnerabilities can be
performed as part of a risk assessment. Vulnerabilities from
traditional and modernized environments should be included,
especially cyber-physical devices in the modern grid.
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C48
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C48
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C48
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C48
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C53
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C53
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C53
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C53
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C58
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C58
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C58
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C58
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C63
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C63
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C63
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C63
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C67
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C67
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C67
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C67
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
19
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Maintain
Safety
Maintain
Reliability
Maintain
Resilience
Support Grid
Modernization
Considerations for Power System Owners/Operators
Category Subcategories
ID.RA-2 ID.RA-2 ID.RA-2 ID.RA-2
Modernized devices need to be included in information sharing.
However, these newer devices that are a part of grid
modernization are not yet well-addressed within the information
sharing forums of the power system owner/operator
community.
ID.RA-3 ID.RA-3 ID.RA-3 ID.RA-3
Potential threats are greatly increased in the more complex
environment of the modernized grid, thereby requiring more
extensive analysis. The environment is more complex because
1) the high number of devices exponentially increases the attack
surface; 2) these devices may have different and distributed
ownership; 3) the devices are likely heterogeneous; 4) the
overall high interconnectivity of the modernized grid.
ID.RA-4 ID.RA-4 ID.RA-4 ID.RA-4
The modernized grid will have additional and more complex
business impacts due to its distributed and multi-owner nature
and complex regulatory landscape.
ID.RA-5 ID.RA-5 ID.RA-5 ID.RA-5
Power systems owners/operators should consider threats,
vulnerabilities, and impacts to the converged IT/OT
environment, including traditional and modernized components.
ID.RA-6 ID.RA-6 ID.RA-6 ID.RA-6
The complexity of the stakeholder landscape in the modernized
grid can make the risk responses of power system
owners/operators more complicated. Power system
owners/operators will need to consider how proposed risk
responses will impact interconnected stakeholders.
Risk
Management
Strategy
ID.RM-1 ID.RM-1 ID.RM-1 ID.RM-1
The complexity of the stakeholder landscape in the modernized
grid can make risk management processes more complicated.
ID.RM-2 ID.RM-2 ID.RM-2 ID.RM-2
Power system owners/operators should consider the
development of a comprehensive strategy to manage risk,
including integrating the modernized components of the grid
into the determination and description of risk tolerance.
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C72
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C72
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C72
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C72
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C77
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C77
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C77
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C77
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C82
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C82
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C82
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C82
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C87
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C87
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C87
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C87
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C91
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C91
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C91
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C91
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C95
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C95
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C95
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C95
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C100
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C100
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C100
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C100
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
20
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Maintain
Safety
Maintain
Reliability
Maintain
Resilience
Support Grid
Modernization
Considerations for Power System Owners/Operators
Category Subcategories
ID.RM-3 ID.RM-3 ID.RM-3 ID.RM-3
When determining organizational risk tolerance, power system
owners/operators should consider the potential cascading
effects on the immediate geographic area, larger region, and the
sector overall.
Supply Chain
Risk
Management
ID.SC-1 ID.SC-1 ID.SC-1 ID.SC-1
Power system owners/operators rely on integrators, Industrial
Control System (ICS) vendors, and commercial off-the-shelf
(COTS) providers to design and implement networks, systems,
and applications that run the grid. As power systems
owners/operators modernize their grids, their supply chains
increasingly include third party service providers and distributed
generation owners/operators. Power system owners/operators
therefore need to have robust processes for managing
cybersecurity risks stemming from these supply chains that
include all relevant members of this diverse ecosystem.
ID.SC-2 ID.SC-2 ID.SC-2 ID.SC-2
Organizational supply chain risk management processes should
be continuously improved regardless of the environment being
traditional or modernized.
ID.SC-3 ID.SC-3 ID.SC-3 ID.SC-3
When power systems transcend organizational boundaries, it
may be beneficial for power system owners/operators to
mutually agree on a set of appropriate security requirements in
order to manage security risks. In addition to security
requirements in supplier agreements, power system
owners/operators are encouraged to establish a set of security
requirements with their third-party partners. These agreements
may be mutual, as in power system owners/operators would
also be agreeing to a set of security requirements they would
commit to abide by. This is a key risk management
consideration for power system owners/operators.
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C104
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C104
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C104
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C104
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C107
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C107
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C107
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C107
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C112
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C112
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C112
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C112
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C116
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C116
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C116
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C116
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
21
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Maintain
Safety
Maintain
Reliability
Maintain
Resilience
Support Grid
Modernization
Considerations for Power System Owners/Operators
Category Subcategories
ID.SC-4 ID.SC-4 ID.SC-4 ID.SC-4
Assessments are required to understand whether suppliers and
third parties are continuously following agreed-upon
cybersecurity requirements. Power system owners/operators
should consider that lack of these assurances can have an impact
on all critical business/mission goals.
ID.SC-5 ID.SC-5 ID.SC-5 ID.SC-5
Power system owners/operators should ensure that the
modernized (including distributed) power environment is
accounted for in response and recovery plans. Testing of these
plans helps manage grid modernization efforts. Additionally,
suppliers and 3rd-party providers should be included in testing of
these plans. Suppliers and 3rd-party providers are critical to
orderly restoration after incidents. If they are not properly
integrated in testing efforts, it may have an impact on all critical
business/mission goals.
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C120
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C120
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C120
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C120
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C125
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C125
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C125
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C125
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
22
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Protect – The Protect Function is critical to limit the impact of a potential cybersecurity event. Identity Management and Access
Control, Awareness and Training, Information Protection Processes, Maintenance, and Protective Technology are the priority security
focus areas. Identity Management and Access Control identifies and regulates personnel ingress and egress. Awareness and Training
and the Protection Processes prepare the workforce to achieve cyber security. Protective technology implements security decisions.
The Subcategories below are derived from the Cybersecurity Framework Core, which includes descriptions and informative references
for each Subcategory.
Table 4 – PROTECT Subcategories Prioritization and Considerations
Maintain
Safety
Maintain
Reliability
Maintain
Resilience
Support Grid
Modernization
Considerations for Power Systems Owners/Operators
Category Subcategories
Access Control
PR.AC-1 PR.AC-1 PR.AC-1 PR.AC-1
Identity management is essential for all users, devices, and
processes in both traditional and modernized environments.
PR.AC-2 PR.AC-2 PR.AC-2 PR.AC-2
Power system owners/operators should control physical access
to the power system components as needed, including
modernized and distributed grid components. Power system
owners/operators should consider the limitations of
maintaining physical access to devices on other premises,
especially those devices that are owned by a 3rd party.
PR PR.AC-3 PR.AC-3 PR.AC-3 PR.AC-3
Many grid components are maintained remotely and such
remote access should be secured. For modernized
environments, consider the limitations of managing remote
access to devices that are owned by a 3rd party, such as
distributed resources.
PR.AC-4 PR.AC-4 PR.AC-4 PR.AC-4
Least privilege is important for limiting permissions and
authorizations to manage connected devices. This reduces risks
of unapproved operations which may create negative impacts
to safety, reliability, and resilience. For example, excessive
privileges may create an opportunity for compromise during
power restoration. Grid modernization efforts should ensure
that least privilege principles are designed into and
implemented in the modernized grid.
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C131
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C131
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C131
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C131
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C137
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C137
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C137
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C137
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C141
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C141
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C141
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C141
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C147
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C147
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C147
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C147
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
23
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Maintain
Safety
Maintain
Reliability
Maintain
Resilience
Support Grid
Modernization
Considerations for Power Systems Owners/Operators
Category Subcategories
PR.AC-5 PR.AC-5 PR.AC-5 PR.AC-5
Network segmentation is an important tool for containing
potential incidents (safety, reliability), and limiting damage
from incidents (resilience). Grid modernization efforts should
consider segmenting networks from the design stage into
operations (e.g., DER devices could be segmented to limit
exposure to the rest of the power system infrastructure).
PR.AC-6 PR.AC-6 PR.AC-6 PR.AC-6
In the power system, the safe delivery of reliable power is
paramount. For this reason, there may be situations (e.g.,
emergency maintenance or need to restore power) in which
the binding and proofing of credentials may interfere with
safety, reliability, and resilience. Power system
owners/operators will need to consider any risks introduced if
identities are not proofed and bound to credentials and if those
credentials are not required for certain user actions.
PR.AC-7 PR.AC-7 PR.AC-7 PR.AC-7
Devices should be authenticated before connecting to the grid
network to ensure that only authorized devices are allowed to
connect. Proper authentication of users, devices, and assets
helps ensure safety and reliability. Special care will need to be
taken to ensure that modernized devices are also authenticated
to the grid network.
Awareness and
Training
PR.AT-1 PR.AT-1 PR.AT-1 PR.AT-1
User training needs to include a mention that modernization of
a grid has impact to cybersecurity. For example, the
dependence on bi-directional, real-time data flows increases
the importance of data integrity. Security awareness training
should be provided to all users, including manufacturing system
users and managers. Training could include, for example, a
basic understanding of the protections and user actions needed
to maintain security of the system, procedures for responding
to suspected cybersecurity incidents, and awareness of
operational security. Also, it is recommended to incorporate
threat recognition and reporting into security awareness
training.
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C153
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C153
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C153
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C153
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C159
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C159
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C159
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C159
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C165
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C165
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C165
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C165
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C171
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C171
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C171
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C171
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
24
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Maintain
Safety
Maintain
Reliability
Maintain
Resilience
Support Grid
Modernization
Considerations for Power Systems Owners/Operators
Category Subcategories
PR.AT-2 PR.AT-2 PR.AT-2 PR.AT-2
Privileged user training needs to include a mention that legacy
to non-legacy migration has impact to cybersecurity. For
example, the dependence on bi-directional, real-time data
flows increases the importance of data integrity.
PR.AT-3 PR.AT-3 PR.AT-3 PR.AT-3
The stakeholder landscape is complicated in the modernized
grid and power system owners/operators will need to include
roles and responsibilities of all relevant stakeholders, including
third parties.
PR.AT-4 PR.AT-4 PR.AT-4 PR.AT-4
Executives need to understand the implications of business
decisions (e.g., grid modernization) on cybersecurity—which
can impact the larger business/mission goals
PR.AT-5 PR.AT-5 PR.AT-5 PR.AT-5
Training and responsibilities for physical and information
security personnel need to be tailored to the unique threats
and risks of the grid modernization environment as well as the
distributed and multi-owner nature of the environment.
Data Security PR.DS-1 PR.DS-1 PR.DS-1 PR.DS-1
In the case of power grid systems, protecting data-at-rest
should apply to protecting the integrity of device settings. If
tampered with, device settings may cause a safety or reliability
issue.
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C176
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C176
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C176
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C176
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C181
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C181
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C181
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C181
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C186
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C186
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C186
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C186
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C191
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C191
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C191
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C191
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C196
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C196
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C196
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C196
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
25
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Maintain
Safety
Maintain
Reliability
Maintain
Resilience
Support Grid
Modernization
Considerations for Power Systems Owners/Operators
Category Subcategories
PR.DS-2 PR.DS-2 PR.DS-2 PR.DS-2
In the case of power grid systems, protecting data in-transit is
an important tool to help protect the integrity of control
information and device settings. Loss of integrity of control
information may cause a safety or reliability issue. Power
system owners/operators should consider the potential for
resource-intensive cryptographic mechanisms to interfere with
the functional performance of control systems and use
additional methods to protect data in transit when less
resource intensive cryptographic mechanisms are used.
PR.DS-3 PR.DS-3 PR.DS-3 PR.DS-3
Power system owners/operators need to be aware of all
distributed, modernized assets they own and manage them
throughout the life cycle. IT components embedded in OT
devices within the grid modernization infrastructure (e.g.,
power control and delivery) may present challenges of
ownership/contractual agreements with the manufacturers.
During disposal of assets, special care should be taken to not
expose device configuration data. The integrity of device
configuration data should be protected to not impact future
safety and reliability.
PR.DS-4 PR.DS-4 PR.DS-4 PR.DS-4
Understanding capacity requirements is critical for power
system reliability and resilience.
PR.DS-5 PR.DS-5 PR.DS-5 PR.DS-5
Data can be used to understand system behavior and devise
methods to attack the system. Therefore, protection from data
leaks is important for safety and reliability.
PR.DS-6 PR.DS-6 PR.DS-6 PR.DS-6
The integrity of information and of software/firmware running
on system components is critical to all business/mission
requirements.
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C201
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C201
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C201
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C201
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C206
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C206
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C206
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C206
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C212
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C212
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C212
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C212
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C217
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C217
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C217
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C217
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C222
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C222
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C222
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C222
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
26
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Maintain
Safety
Maintain
Reliability
Maintain
Resilience
Support Grid
Modernization
Considerations for Power Systems Owners/Operators
Category Subcategories
PR.DS-7 PR.DS-7 PR.DS-7 PR.DS-7
The separation of development and testing environments is
critical to ensure testing does not accidentally impact
operational systems. Therefore, insufficient separation could
directly impact safety, reliability, and resilience. This applies to
both traditional and modernized environments equally;
therefore, grid modernization is not specifically highlighted.
This should be already done for the traditional environment
and this good process should also apply to modernized
environments. However, it should be noted that applying this
to distributed environments may be challenging due to their
scope.
PR.DS-8 PR.DS-8 PR.DS-8 PR.DS-8
The integrity of power system hardware is critical to safety,
reliability, resilience, and grid modernization.
Information
Protection
Processes and
Procedures
PR.IP-1 PR.IP-1 PR.IP-1 PR.IP-1
Baseline configurations are needed for all devices that are
owned by a power system owner/operator. However, power
system owner/operators should consider that they may have
little or no control over the configuration of devices owned by
other stakeholders connecting to the grid. Creating and
maintaining baseline configurations supports the safety,
reliability, and resilience (known state to restore to) of the
power grid. Grid modernization efforts are also supported by
having a standard configuration for all modernized devices.
PR.IP-2 PR.IP-2 PR.IP-2 PR.IP-2
Implementing a systems development life cycle ensures quality
and predictable performance of systems and networks. It is
critical for safety and reliability. While also important for
resilience and grid modernization, it is in no way special for
those two goals which are thus not selected.
PR.IP-3 PR.IP-3 PR.IP-3 PR.IP-3
Configuration change control processes support safety,
reliability, resilience (known state to restore to), and transition
to modernized grid. Power system owners/operators should
consider how organizational configuration change control
processes will include devices owned by third parties
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C227
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C227
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C227
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C227
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C231
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C231
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C231
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C231
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C235
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C235
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C235
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C235
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C241
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C241
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C241
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C241
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C246
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C246
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C246
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C246
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
27
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Maintain
Safety
Maintain
Reliability
Maintain
Resilience
Support Grid
Modernization
Considerations for Power Systems Owners/Operators
Category Subcategories
PR.IP-4 PR.IP-4 PR.IP-4 PR.IP-4
Backups are essential for retaining device configuration
information so that devices can be restored and recovered to
proper operational states. Modernized grids are especially
susceptible because modern devices have more programmable
logic in them. Special consideration should be taken to address
backups of devices owned by third parties.
PR.IP-5 PR.IP-5 PR.IP-5 PR.IP-5
Physical security policies are important for safety and reliability
of the power grid. Physical access to sensors can lead to
sensors being used as attack vectors. Physical security policies
also support the integration of distributed, modernized devices
into the grid.
PR.IP-6 PR.IP-6 PR.IP-6 PR.IP-6
The destruction of data is not directly applicable to these
business/mission requirements.
PR.IP-7 PR.IP-7 PR.IP-7 PR.IP-7
Protection processes should be continuously improved
regardless of whether the power system environment is
traditional or modernized.
PR.IP-8 PR.IP-8 PR.IP-8 PR.IP-8
Sharing the effectiveness of protection technologies is not
directly applicable to these business/mission requirements.
PR.IP-9 PR.IP-9 PR.IP-9 PR.IP-9
Power system owners/operators need to be sure to include the
modernized environment/devices in the response and recovery
plans and their testing to help manage grid modernization
efforts. They should also ensure that the plans address the
collaboration between IT and OT personnel and the distributed
nature of modernized environments.
PR.IP-10 PR.IP-10 PR.IP-10 PR.IP-10
Power system owners/operators need to be sure to include the
modernized environment/devices in cybersecurity response
and recovery plans and their testing to help manage grid
modernization efforts. The plans need to address the
collaboration between IT and OT personnel as well as the
distributed nature of modernized environments.
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C252
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C252
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C252
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C252
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C258
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C258
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C258
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C258
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C262
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C262
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C262
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C262
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C267
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C267
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C267
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C267
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C271
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C271
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C271
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C271
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C274
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C274
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C274
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C274
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C279
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C279
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C279
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C279
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
28
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Maintain
Safety
Maintain
Reliability
Maintain
Resilience
Support Grid
Modernization
Considerations for Power Systems Owners/Operators
Category Subcategories
PR.IP-11 PR.IP-11 PR.IP-11 PR.IP-11
Processes and procedures for including cybersecurity in human
resources practices are the same for both traditional and
modernized environments. Therefore, no special
accommodations are required for the modernized grid.
PR.IP-12 PR.IP-12 PR.IP-12 PR.IP-12
Modernized distributed energy resources can have
vulnerabilities that may allow new and unaccounted threat
vectors to the power grid. Power system owners/operators
should consider how externally-owned devices and third-party
owners/operators will be included in a vulnerability
management plan.
Maintenance
PR.MA-1 PR.MA-1 PR.MA-1 PR.MA-1
Special care needs to be taken when devices are owned by third
parties as may be the case in modernized environments.
PR.MA-2 PR.MA-2 PR.MA-2 PR.MA-2
Power system owners/operators need to be aware of any
remote access capabilities that the device vendor may have to
equipment. This is extremely important in energy
environments due to distributed nature, geographical
dispersion, and the mission need for remote maintenance of
both legacy and modernized devices.
Protective
Technology
PR.PT-1 PR.PT-1 PR.PT-1 PR.PT-1
Audit logs capture information that will be helpful during an
attack to find anomalies and potentially limit the impact or stop
the incident from inflicting worse damage (helps safety).
Capturing and monitoring audit logs is also important for
managing cybersecurity risks to grid modernization. These
audit logs may provide visibility into the activities and traffic
related to these distributed devices.
PR.PT-2 PR.PT-2 PR.PT-2 PR.PT-2
Protecting and restricting the use of removable media on
modernized devices has the same considerations as on legacy
devices.
PR.PT-3 PR.PT-3 PR.PT-3 PR.PT-3
Power system owners/operators should consider how the
principle of least functionality will be applied to third-party
assets connected to their grid.
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C285
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C285
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C285
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C285
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C290
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C290
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C290
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C290
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C294
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C294
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C294
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C294
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C298
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C298
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C298
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C298
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C303
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C303
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C303
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C303
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C309
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C309
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C309
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C309
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C314
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C314
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C314
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C314
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
29
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Maintain
Safety
Maintain
Reliability
Maintain
Resilience
Support Grid
Modernization
Considerations for Power Systems Owners/Operators
Category Subcategories
PR.PT-4 PR.PT-4 PR.PT-4 PR.PT-4
Distributed multi-ownership of some modern grid (e.g., DER)
environments may make it challenging to protect
communications and control networks.
PR.PT-5 PR.PT-5 PR.PT-5 PR.PT-5
Power system owners/operators should consider all possible
ways to achieve resiliency requirements.
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C320
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C320
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C320
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C320
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C325
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C325
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C325
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C325
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
30
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Detect – The Detect Function enables timely discovery of cybersecurity events. Real time awareness and continuous
monitoring of the systems is critical to detect cybersecurity events. The Subcategories below are derived from the
Cybersecurity Framework Core, which includes descriptions and informative references for each Subcategory.
Table 5 – DETECT Subcategories Prioritization and Considerations
Maintain
Safety
Maintain
Reliability
Maintain
Resilience
Support Grid
Modernization
Considerations for Power Systems Owners/Operators
Category Subcategories
Anomalies and
Events
DE.AE-1 DE.AE-1 DE.AE-1 DE.AE-1
A baseline of network operations and expected data flows is
extremely important in the OT space because information
flows are predictable, and control systems generally have few
users. Understanding the control information flows will help
monitor and detect unusual network behavior and allow for
timely response. This applies to both traditional and
modernized grid environments.
DE.AE-2 DE.AE-2 DE.AE-2 DE.AE-2
Analyzing detected cybersecurity events is critical for safety,
reliability, and resilience. There are no special considerations
for modernized parts of the infrastructure.
DE DE.AE-3 DE.AE-3 DE.AE-3 DE.AE-3
When collecting and aggregating data from third-party
devices, the devices and the data should be authenticated
and validated. Without this authentication and validation,
power system owners/operators should carefully consider
whether those devices and their data can be trusted.
DE.AE-4 DE.AE-4 DE.AE-4 DE.AE-4
Determining the impact of detected cybersecurity events is
critical for safety, reliability, and resilience. There are no
special considerations for modernized parts of the
infrastructure.
DE.AE-5 DE.AE-5 DE.AE-5 DE.AE-5
Establishing incident alert thresholds is critical for safety,
reliability, and resilience. This practice applies to both
traditional and modernized parts of the grid.
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C330
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C330
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C330
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C330
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C335
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C335
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C335
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C335
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C341
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C341
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C341
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C341
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C346
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C346
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C346
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C346
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C350
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C350
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C350
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C350
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
31
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Maintain
Safety
Maintain
Reliability
Maintain
Resilience
Support Grid
Modernization
Considerations for Power Systems Owners/Operators
Category Subcategories
Security
Continuous
Monitoring
DE.CM-1 DE.CM-1 DE.CM-1 DE.CM-1
Neglecting to monitor the grid for cybersecurity events may
result in missing an event with implications and impact. For
grid modernization, monitoring has to be built in for the
future. While the selection of safety may be surprising, not
monitoring substantially increases the risk of not knowing
that there may be safety impacts and being unable to reduce
or eliminate them.
DE.CM-2 DE.CM-2 DE.CM-2 DE.CM-2
Monitoring the physical environment for cybersecurity events
is critical for safety, reliability, and resilience. There are no
special considerations for modernized parts of the
infrastructure.
DE.CM-3 DE.CM-3 DE.CM-3 DE.CM-3
Monitoring personnel activity for cybersecurity events is
critical for safety, reliability, and resilience. There are no
special considerations for modernized parts of the
infrastructure.
DE.CM-4 DE.CM-4 DE.CM-4 DE.CM-4
Power system owners/operators should consider applying
malicious code detection methodologies to both traditional
and modernized infrastructure. These devices contain
complex software which makes them vulnerable to cyber
attacks.
DE.CM-5 DE.CM-5 DE.CM-5 DE.CM-5
Detecting unauthorized mobile code is critical for safety,
reliability, and resilience. There are no special considerations
for modernized parts of the infrastructure.
DE.CM-6 DE.CM-6 DE.CM-6 DE.CM-6
Power system owners/operators rely on vendors and external
service providers for many capabilities, including industrial
control systems and communications networks required to
operate the grid. Whether service providers are accessing IT
or especially OT environments, those activities should be
monitored to ensure mitigating actions can be taken in case
of attack stemming from external connections.
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C355
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C355
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C355
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C355
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C359
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C359
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C359
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C359
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C363
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C363
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C363
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C363
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C368
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C368
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C368
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C368
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C374
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C374
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C374
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C374
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C379
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C379
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C379
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C379
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
32
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Maintain
Safety
Maintain
Reliability
Maintain
Resilience
Support Grid
Modernization
Considerations for Power Systems Owners/Operators
Category Subcategories
DE.CM-7 DE.CM-7 DE.CM-7 DE.CM-7
Unauthorized personnel, connections, devices, or software
introduce risks into IT and OT, and may impact grid
operations. Any connections to IT and OT systems and
networks should be authenticated to ensure that only
approved and trusted parties gain access to those systems
and networks.
DE.CM-8 DE.CM-8 DE.CM-8 DE.CM-8
Performing vulnerability scans is required to identify
vulnerabilities in critical infrastructure. For modernized
environments, power system owners/operators may need to
consider an agreement to scan 3rd party-owned devices that
are connected to their grid.
Detection
Processes
DE.DP-1 DE.DP-1 DE.DP-1 DE.DP-1
Knowing roles and responsibilities with respect to detection is
critical to all four business goals. This includes restoration
across power system ownership lines and within a single
power system owner/operator with traditional and
modernized components and networks. Distributed
resources owners/operators may also have a role and
responsibilities in detection activities.
DE.DP-2 DE.DP-2 DE.DP-2 DE.DP-2
Power system owners/operators need to ensure that
detection activities comply with jurisdiction-specific safety
requirements.
DE.DP-3 DE.DP-3 DE.DP-3 DE.DP-3
Power system owners/operators should consider any
potential negative impact to the power system due to testing
of detection processes. The owners/operators of distributed
modernized devices may also need to participate in this
testing.
DE.DP-4 DE.DP-4 DE.DP-4 DE.DP-4
Event detection information communication includes
communicating detection events across traditional and
modernized environments as well as between power system
owners/operators in the modernized grid.
DE.DP-5 DE.DP-5 DE.DP-5 DE.DP-5 Detection processes should be continuously improved.
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C382
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C382
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C382
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C382
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C386
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C386
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C386
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C386
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C391
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C391
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C391
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C391
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C396
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C396
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C396
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C396
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C400
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C400
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C400
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C400
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C405
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C405
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C405
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C405
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C411
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C411
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C411
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C411
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
33
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Respond – The Respond Function supports the ability to contain the impact of a potential cybersecurity event.
Rapid and effective response and communication to cyber incidents is critical in protecting personnel and
environmental safety. Situational awareness to the event unfolding is needed to properly address it. The
Subcategories below are derived from the Cybersecurity Framework Core, which includes descriptions and
informative references for each Subcategory.
Table 6 – RESPOND Subcategories Prioritization and Considerations
Maintain
Safety
Maintain
Reliability
Maintain
Resilience
Support Grid
Modernization
Considerations for Power Systems Owners/Operators
Category Subcategories
Response
Planning
RS.RP-1 RS.RP-1 RS.RP-1 RS.RP-1 Response plan execution applies in both traditional and
modernized environments.
Communications
RS.CO-1 RS.CO-1 RS.CO-1 RS.CO-1 Knowing roles and responsibilities with respect to
response and grid restoration is critical to all four
business goals. This includes restoration across power
system ownership lines and within a single power
system owner/operator with integration of traditional
and modernized components and networks.
RS
RS.CO-2 RS.CO-2 RS.CO-2 RS.CO-2 Having an established criterion for reporting incidents
helps support safety objectives to ensure that safety
considerations are a part of incident response.
Furthermore, resilience benefits from a thoughtful
criterion.
RS.CO-3 RS.CO-3 RS.CO-3 RS.CO-3 Assuming that the event response information is shared
once an incident has occurred, this Subcategory
outcome supports resilience, rather than reliability.
Sharing of information is important to ensure safety of
restoration crews and has to be executed across
traditional and modernized systems and components.
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C415
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C415
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C415
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C415
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C420
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C420
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C420
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C420
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C425
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C425
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C425
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C425
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C430
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C430
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C430
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C430
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
34
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Maintain
Safety
Maintain
Reliability
Maintain
Resilience
Support Grid
Modernization
Considerations for Power Systems Owners/Operators
Category Subcategories
RS.CO-4 RS.CO-4 RS.CO-4 RS.CO-4 Power system owners/operators should consider that
the modernized grid is expected to have an expanded
set of stakeholders that includes distributed resources
owners/operators.
RS.CO-5 RS.CO-5 RS.CO-5 RS.CO-5 Sharing information across power system boundaries is
important, especially when some of the power systems
are modernized and some are not. In this context,
external stakeholders are assumed to include
neighboring power system owners/operators.
Analysis
RS.AN-1 RS.AN-1 RS.AN-1 RS.AN-1 Investigating notifications from detection systems is
important for safety, reliability, and resilience. There are
no special considerations for modernized parts of the
infrastructure.
RS.AN-2 RS.AN-2 RS.AN-2 RS.AN-2 Power system owners/operators should take care to
understand any similarities and differences in impacts
between the traditional and modernized environments.
RS.AN-3 RS.AN-3 RS.AN-3 RS.AN-3 Performing forensics of incidents is critical for safety and
resilience.
RS.AN-4 RS.AN-4 RS.AN-4 RS.AN-4 Categorizing incidents is critical for safety and resilience.
RS.AN-5 RS.AN-5 RS.AN-5 RS.AN-5 Having processes for receiving and analyzing
vulnerability information is important for reliability,
resilience, and the modernized grid because devices in
the modernized grid are smarter than the legacy devices
and have their own vulnerabilities. Safety will benefit
indirectly from these activities.
Mitigation
RS.MI-1 RS.MI-1 RS.MI-1 RS.MI-1 Containing incidents is critical for safety and resilience,
since once an incident occurs, reliability has already
been impacted. Containing incidents is important for
both traditional and modernized infrastructures.
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C435
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C435
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C435
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C435
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C440
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C440
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C440
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C440
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C444
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C444
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C444
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C444
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C450
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C450
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C450
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C450
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C454
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C454
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C454
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C454
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C458
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C458
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C458
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C458
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C463
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C463
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C463
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C463
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C466
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C466
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C466
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C466
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
35
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Maintain
Safety
Maintain
Reliability
Maintain
Resilience
Support Grid
Modernization
Considerations for Power Systems Owners/Operators
Category Subcategories
RS.MI-2 RS.MI-2 RS.MI-2 RS.MI-2 Mitigating incidents is critical for safety and resilience,
since once an incident occurs, reliability has already
been impacted. Mitigating incidents is important for
both traditional and modernized infrastructures.
RS.MI-3 RS.MI-3 RS.MI-3 RS.MI-3 Newer devices are likely to be more vulnerable because
they are interconnected and more complex than legacy
devices. Not patching will hinder the ability of power
system owners/operators to be resilient and reliable.
Processes should be in place to receive vulnerability
information from vendors, as well as to share
vulnerability information with device owners/operators
across power systems that may have different
ownership.
Improvements
RS.IM-1 RS.IM-1 RS.IM-1 RS.IM-1 Lessons learned will improve future safety, reliability,
resilience, and grid modernization.
RS.IM-2 RS.IM-2 RS.IM-2 RS.IM-2 Updating recovery strategies will improve future safety,
reliability, resilience, and grid modernization.
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C472
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C472
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C472
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C472
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C477
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C477
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C477
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C477
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C481
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C481
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C481
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C481
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C485
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C485
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C485
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C485
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
36
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Recover – The Recover Function supports timely recovery to normal operations to reduce the impact from a
cybersecurity event. Defined Recovery objectives are needed when recovering from disruptions. The Subcategories
below are derived from the Cybersecurity Framework Core, which includes descriptions and informative references
for each Subcategory.
Table 7 – RECOVER Subcategories Prioritization and Considerations
Maintain
Safety
Maintain
Reliability
Maintain
Resilience
Support Grid
Modernization
Considerations for Power Systems Owners/Operators
Category Subcategories
RE
Recovery Planning
RC.RP-1 RC.RP-1 RC.RP-1 RC.RP-1 There are implications to safety of power system
owner/operator workers (e.g., linemen) when the cyber
security recovery plan is executed. The plan should
include both traditional and modernized parts of the
grid.
Improvements
RC.IM-1 RC.IM-1 RC.IM-1 RC.IM-1 Incorporating lessons learned into plans is absolutely
critical for maintaining reliability and resilience. In this
case the other two business goals are of secondary
importance.
RC.IM-2 RC.IM-2 RC.IM-2 RC.IM-2 Updating recovery strategies is critical for reliability and
resilience and should cover any activities relevant to
safety and grid modernization.
Communications
RC.CO-1 RC.CO-1 RC.CO-1 RC.CO-1 While important, managing public relations is not critical
for the four goals.
RC.CO-2 RC.CO-2 RC.CO-2 RC.CO-2 While important, repairing reputation is not critical for
the four goals.
RC.CO-3 RC.CO-3 RC.CO-3 RC.CO-3 Cyber security event recovery activities have to be
coordinated to ensure safety of power system owner
operator workers (e.g., linemen) working on power
recovery. Recovery efforts also require coordination
across power systems, some of which may be
modernized and some not.
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C488
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C488
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C488
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C488
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C492
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C492
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C492
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C492
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C496
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C496
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C496
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C496
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C499
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C499
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C499
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C499
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C501
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C501
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C501
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C501
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C503
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C503
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C503
https://www.nist.gov/document/2018-04-16frameworkv11core1xlsx#sheet1!C503
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
37
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Future Work
This Smart Grid Profile effort focuses on identifying high level business/mission objectives
of the smart grid and prioritizing Subcategory outcomes of the Cybersecurity Framework
according to their ability to directly assist power system owners/operators in achieving those
business/mission objectives. The Profile also provides power system owners/operators with
considerations relevant to the challenges they may experience as they implement these
cybersecurity activities in infrastructures with high concentrations of distributed energy
resources (DERs).
This Profile looked at the smart grid from a high level to serve as a resource for those seeking
to understand the basic application of cybersecurity concepts to the grid. Since this high-
level view indicated that a large number of Subcategory outcomes was important to the grid,
the considerations included for each Subcategory describe the grid relevance of the outcome.
At a smart grid cybersecurity workshop held at NIST in November 2018, participants
discussed the current risk Profile and ways to make it more useful to smart grid stakeholders.
Those participant suggestions shape our future smart grid Profile work and are highlighted
below.
The next version of the smart grid Profile will focus on cybersecurity considerations of a grid
service/function rather than on an entire architecture. It was felt by participants that
exploration of a service/function within the context of grid architecture would be more useful
to stakeholders. To that end, we will compare and contrast the following:
• how a grid service or function is provided within a contemporary grid architecture
and within the previously-explored High-DER architecture,
• by which stakeholders the service or function is delivered within each
architecture, and
• cybersecurity considerations or concerns for stakeholders as they deliver the
service or function within each architecture.
Similar to the current risk Profile effort, we will prioritize Cybersecurity Framework
Subcategory outcomes for the grid service within each of the selected architectures. The
prioritization of Cybersecurity Framework Subcategories is based on the Subcategory
outcome’s ability to directly assist in the delivery of the service within the examined
architectures. Our goal will be to provide a more useful prioritization scale (e.g., low,
medium, and high) for Subcategories rather than the binary (i.e., yes, no) scale used in the
current effort.
Additionally, the next Profile will enable comparison of the Subcategory prioritization scales
and cybersecurity considerations for stakeholders providing similar grid services within two
different architectures. Finally, the goal is for the next Profile to contain updated mapping
information between the Cybersecurity Framework v1.1 and the current North American
Electric Reliability Corporation (NERC) Critical Infrastructure Protection (CIP) version.
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
38
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
References
[1] United States, Executive Office of the President [Barack Obama]. Executive Order
13636: Improving Critical Infrastructure Cybersecurity. 12 Feb. 2013. Federal
Register, vol. 78, 19 Feb. 2013, pp. 11737-44,
https://www.federalregister.gov/d/2013-03915.
[2] National Institute of Standards and Technology (2018) Framework for Improving
Critical Infrastructure Cybersecurity, version 1.1.
https:/doi.org/10.6028/NIST.CSWP.04162018
[3] U.S. Department of Energy (2008) Smart Grid: An Introduction. Available at
https://www.energy.gov/sites/prod/files/oeprod/DocumentsandMedia/DOE_SG_Book
_Single_Pages%281%29
[4] The Smart Grid Interoperability Panel – Smart Grid Cybersecurity Committee (2014)
Guidelines for Smart Grid Cybersecurity [3 vols.]. (National Institute of Standards
and Technology, Gaithersburg, MD), NIST Interagency Report (NIST IR) 7628, Rev.
1. https://doi.org/10.6028/NIST.IR.7628r1
[5] Stouffer K, Pillitteri V, Lightman S, Abrams M, Hahn A (2015) Guide to Industrial
Control Systems (ICS) Security. (National Institute of Standards and Technology,
Gaithersburg, MD), NIST Special Publication (SP) 800-82, Rev. 2.
https://doi.org/10.6028/NIST.SP.800-82r2
[6] Taft JD (2016) Grid Architecture 2. (Pacific Northwest National Laboratory,
Richland, WA), PNL-24044 2. Available at
https://gridarchitecture.pnnl.gov/media/white-papers/GridArchitecture2final
[7] Taft JD (2016) Advanced Networking Paradigms for High-DER Distribution Grids,
version 3.0. (Pacific Northwest National Laboratory, Richland, WA), PNNL-25475.
Available at
https://gridarchitecture.pnnl.gov/media/advanced/Advanced%20Networking%20Para
digms%20final
[8] Cyber-Physical Systems Public Working Group (2017) Framework for Cyber-
Physical Systems: Volume 2, Working Group Reports. (National Institute of
Standards and Technology, Gaithersburg, MD), NIST Special Publication (SP) 1500-
202, Version 1.0. https://doi.org/10.6028/NIST.SP.1500-202
[9] International Electrotechnical Commission (2016) IEC TR 62351-12:2016 – Power
systems management and associated information exchange – Data and
communication security – Part 12: Resilience and security recommendations for
power systems with distributed energy resources (DER) cyber-physical systems (IEC,
Geneva, Switzerland). Available at https://webstore.iec.ch/publication/24474
https://www.federalregister.gov/d/2013-03915
https://doi.org/10.6028/NIST.CSWP.04162018
https://www.energy.gov/sites/prod/files/oeprod/DocumentsandMedia/DOE_SG_Book_Single_Pages%281%29
https://www.energy.gov/sites/prod/files/oeprod/DocumentsandMedia/DOE_SG_Book_Single_Pages%281%29
https://doi.org/10.6028/NIST.IR.7628r1
https://doi.org/10.6028/NIST.SP.800-82r2
https://gridarchitecture.pnnl.gov/media/white-papers/GridArchitecture2final
https://gridarchitecture.pnnl.gov/media/advanced/Advanced%20Networking%20Paradigms%20final
https://gridarchitecture.pnnl.gov/media/advanced/Advanced%20Networking%20Paradigms%20final
https://doi.org/10.6028/NIST.SP.1500-202
https://webstore.iec.ch/publication/24474
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
39
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
[10] Energy Sector Control Systems Working Group (2014) Cybersecurity Procurement
Language for Energy Delivery Systems. Available at
https://www.energy.gov/sites/prod/files/2014/04/f15/CybersecProcurementLanguage-
EnergyDeliverySystems_040714_fin
[11] Bartol N (2015) Cyber Supply Chain Risk Management for Utilities – Roadmap for
Implementation (Utilities Telecom Council, Washington, DC). Available at
https://utc.org/wp-content/uploads/2018/02/SupplyChain2015-2
[12] Gopstein AM (2012) Energy Storage & the Grid—From Characteristics to Impact.
Institute of Electrical and Electronics Engineers (IEEE) Proceedings of the IEEE
100(2):311-316. https://doi.org/10.1109/JPROC.2011.2174890
[13] North American Electric Reliability Corporation, Critical Infrastructure Protection
Committee, Control Systems Security Working Group (2014) Mapping of NIST
Cybersecurity Framework to NERC CIP v3/v5 (North American Electric Reliability
Corporation, Washington, DC). Available at
https://www.nerc.com/comm/CIPC_Security_Guidelines_DL/CSSWG-
Mapping_of_NIST_Cybersecurity_Framework_to_NERC_CIP
https://www.energy.gov/sites/prod/files/2014/04/f15/CybersecProcurementLanguage-EnergyDeliverySystems_040714_fin
https://www.energy.gov/sites/prod/files/2014/04/f15/CybersecProcurementLanguage-EnergyDeliverySystems_040714_fin
https://utc.org/wp-content/uploads/2018/02/SupplyChain2015-2
https://doi.org/10.1109/JPROC.2011.2174890
https://www.nerc.com/comm/CIPC_Security_Guidelines_DL/CSSWG-Mapping_of_NIST_Cybersecurity_Framework_to_NERC_CIP
https://www.nerc.com/comm/CIPC_Security_Guidelines_DL/CSSWG-Mapping_of_NIST_Cybersecurity_Framework_to_NERC_CIP
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
40
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Appendix A: Acronyms
Selected acronyms and abbreviations used in this paper are defined below.
AMI
COTS
Advanced Metering Infrastructure
Commercial Off-the-Shelf
CSF Cybersecurity Framework
DER Distributed Energy Resources
DoE Department of Energy
FIPS Federal Information Processing Standards
ICS Industrial Control System
IEC International Electrotechnical Commission
ISA The International Society of Automation
IT Information Technology
ITL Information Technology Laboratory
LAN
NERC
Local Area Network
North American Electric Reliability Corporation
NIST National Institute of Standards and Technology
OT Operational Technology
PNNL Pacific Northwest National Laboratory
UTC Utilities Telecom Council
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
41
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Appendix B: NERC CIP v5 to Cybersecurity Framework v1.0 Mapping
The table below is the result of work by the NERC Critical Infrastructure Protection Committee (CIPC) Control Systems Security
Working Group (CSSWG) to map Subcategory outcomes of the Cybersecurity Framework v1.0 to NERC CIP versions 3 and 5. This
information supplements the Subcategory prioritization and considerations for power system owners/operators presented in Sec. 5 of
this Profile. As owners/operators and electricity subsector cybersecurity practitioners consider the applicability of the information in
Sec. 5 to their power systems, the mapping information below will help them ensure compliance with NERC CIP requirements. This
mapping can also help them align with practices from the Department of Energy’s Cybersecurity Capability Maturity Model (C2M2)
Program.
It should be noted that the mapping information contained in this appendix was completed in November 2014. Since that time, both
NERC CIP and the Cybersecurity Framework have been updated. Future Profile work aims to include updated mapping information
to improve the usefulness to stakeholders. The mapping work completed by the CIPC CSSWG included one additional column which
provided specific implementation guidance for the NERC CIP controls. For our Profile, we omitted that guidance column because our
purpose was primarily to provide the Cybersecurity Framework v1.0 to NERC CIP mapping information.
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
IDENTIFY
(ID)
Asset Management (AM): The
data, personnel, devices, systems,
and facilities that enable the
organization to achieve business
purposes are identified and
managed consistent with their
relative importance to business
objectives and the organization’s
risk strategy.
ID.AM-1: Physical devices and
systems within the organization
are inventoried
ACM-
1a
ACM-
1c
ACM-
1e
ACM-
1f
CIP-002-5.1 R1: Each Responsible Entity
shall implement a process that considers
each of the following assets for purposes
of parts 1.1 through 1.3: i. Control Centers
and backup Control Centers; ii.
Transmission stations and substations; iii.
Generation resources; iv. Systems and
facilities critical to system restoration,
including Blackstart Resources and
Cranking Paths and initial switching
requirements; v. Special Protection
Systems that support the reliable
operation of the Bulk Electric System
(BES); and vi. For Distribution Providers,
Protection Systems specified in
Applicability section 4.2.1 above.
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
42
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
IDENTIFY
(ID)
Asset Management (AM): The
data, personnel, devices, systems,
and facilities that enable the
organization to achieve business
purposes are identified and
managed consistent with their
relative importance to business
objectives and the organization’s
risk strategy.
ID.AM-1: Physical devices and
systems within the organization
are inventoried
ACM-
1a
ACM-
1c
ACM-
1e
ACM-
1f
CIP-002-5.1 R2: The Responsible Entity
shall: (2.1) Review the identifications in
Requirement R1 and its parts (and update
them if there are changes identified) at
least once every 15 calendar months,
even if it has no identified items in
Requirement R1, and; (2.2) Have its CIP
Senior Manager or delegate approve the
identifications required by Requirement R1
at least once every 15 calendar months,
even if it has no identified items in
Requirement R1.
IDENTIFY
(ID)
Asset Management (AM): The
data, personnel, devices, systems,
and facilities that enable the
organization to achieve business
purposes are identified and
managed consistent with their
relative importance to business
objectives and the organization’s
risk strategy.
ID.AM-1: Physical devices and
systems within the organization
are inventoried
ACM-
1a
ACM-
1c
ACM-
1e
ACM-
1f
CIP-003-5 R2: Each Responsible Entity for
its assets identified in CIP‐002‐5,
Requirement R1, Part R1.3, shall
implement, in a manner that identifies,
assesses, and corrects deficiencies, one
or more documented cyber security
policies that collectively address the
following topics, and review and obtain
CIP Senior Manager approval for those
policies at least once every 15 calendar
months: (An inventory, list, or discrete
identification of low impact BES Cyber
Systems or their BES Cyber Assets is not
required). (2.1) Cyber security awareness;
(2.2) Physical security controls; (2.3)
Electronic access controls for external
routable protocol connections and Dial‐up
Connectivity; and (2.4) Incident response
to a Cyber Security Incident.
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
43
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
IDENTIFY
(ID)
Asset Management (AM): The
data, personnel, devices, systems,
and facilities that enable the
organization to achieve business
purposes are identified and
managed consistent with their
relative importance to business
objectives and the organization’s
risk strategy.
ID.AM-2: Software platforms
and applications within the
organization are inventoried
ACM-
1b
ACM-
1c
ACM-
1e
ACM-
1f
CIP-002-5.1 R1: Each Responsible Entity
shall implement a process that considers
each of the following assets for purposes
of parts 1.1 through 1.3: i. Control Centers
and backup Control Centers; ii.
Transmission stations and substations; iii.
Generation resources; iv. Systems and
facilities critical to system restoration,
including Blackstart Resources and
Cranking Paths and initial switching
requirements; v. Special Protection
Systems that support the reliable
operation of the Bulk Electric System; and
vi. For Distribution Providers, Protection
Systems specified in Applicability section
4.2.1 above.
IDENTIFY
(ID)
Asset Management (AM): The
data, personnel, devices, systems,
and facilities that enable the
organization to achieve business
purposes are identified and
managed consistent with their
relative importance to business
objectives and the organization’s
risk strategy.
ID.AM-2: Software platforms
and applications within the
organization are inventoried
ACM-
1b
ACM-
1c
ACM-
1e
ACM-
1f
CIP-002-5.1 R2: The Responsible Entity
shall: (2.1) Review the identifications in
Requirement R1 and its parts (and update
them if there are changes identified) at
least once every 15 calendar months,
even if it has no identified items in
Requirement R1, and; (2.2) Have its CIP
Senior Manager or delegate approve the
identifications required by Requirement R1
at least once every 15 calendar months,
even if it has no identified items in
Requirement R1.
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
44
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
IDENTIFY
(ID)
Asset Management (AM): The
data, personnel, devices, systems,
and facilities that enable the
organization to achieve business
purposes are identified and
managed consistent with their
relative importance to business
objectives and the organization’s
risk strategy.
ID.AM-3: Organizational
communication and data flows
are mapped
RM-2g ACM-
1e
CIP-002-5.1 R1: Each Responsible Entity
shall implement a process that considers
each of the following assets for purposes
of parts 1.1 through 1.3: i. Control Centers
and backup Control Centers; ii.
Transmission stations and substations; iii.
Generation resources; iv. Systems and
facilities critical to system restoration,
including Blackstart Resources and
Cranking Paths and initial switching
requirements; v. Special Protection
Systems that support the reliable
operation of the Bulk Electric System; and
vi. For Distribution Providers, Protection
Systems specified in Applicability section
4.2.1 above.
IDENTIFY
(ID)
Asset Management (AM): The
data, personnel, devices, systems,
and facilities that enable the
organization to achieve business
purposes are identified and
managed consistent with their
relative importance to business
objectives and the organization’s
risk strategy.
ID.AM-3: Organizational
communication and data flows
are mapped
RM-2g ACM-
1e
CIP-003-5 R1 – 1.2: Each Responsible
Entity, for its high impact and medium
impact BES Cyber Systems, shall review
and obtain CIP Senior Manager approval
at least once every 15 calendar months for
one or more documented cyber security
policies that collectively address the
following topics: Electronic Security
Perimeters (CIP‐005) including Interactive
Remote Access;
IDENTIFY
(ID)
Asset Management (AM): The
data, personnel, devices, systems,
and facilities that enable the
organization to achieve business
purposes are identified and
managed consistent with their
relative importance to business
objectives and the organization’s
risk strategy.
ID.AM-3: Organizational
communication and data flows
are mapped
RM-2g ACM-
1e
CIP-005-5 R2: Each Responsible Entity
allowing Interactive Remote Access to
BES Cyber Systems shall implement one
or more documented processes that
collectively include the applicable
requirement parts, where technically
feasible, in CIP-005-5 Table R2 –
Interactive Remote Access Management.
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
45
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
IDENTIFY
(ID)
Asset Management (AM): The
data, personnel, devices, systems,
and facilities that enable the
organization to achieve business
purposes are identified and
managed consistent with their
relative importance to business
objectives and the organization’s
risk strategy.
ID.AM-3: Organizational
communication and data flows
are mapped
RM-2g ACM-
1e
CIP-011-1 R1: Each Responsible Entity
shall implement, in a Manner that
identifies, assesses, and corrects
deficiencies, one or more documented
information protection program(s) that
collectively includes each of the applicable
requirement parts in CIP‐011‐1 Table R1 –
Information Protection.
IDENTIFY
(ID)
Asset Management (AM): The
data, personnel, devices, systems,
and facilities that enable the
organization to achieve business
purposes are identified and
managed consistent with their
relative importance to business
objectives and the organization’s
risk strategy.
ID.AM-4: External information
systems are catalogued
EDM-
1a
EDM-
1c
EDM-
1e
EDM-
1g
RM-1c
CIP-002-5.1 R1: Each Responsible Entity
shall implement a process that considers
each of the following assets for purposes
of parts 1.1 through 1.3: i. Control Centers
and backup Control Centers; ii.
Transmission stations and substations; iii.
Generation resources; iv. Systems and
facilities critical to system restoration,
including Blackstart Resources and
Cranking Paths and initial switching
requirements; v. Special Protection
Systems that support the reliable
operation of the Bulk Electric System; and
vi. For Distribution Providers, Protection
Systems specified in Applicability section
4.2.1 above.
IDENTIFY
(ID)
Asset Management (AM): The
data, personnel, devices, systems,
and facilities that enable the
organization to achieve business
purposes are identified and
managed consistent with their
relative importance to business
objectives and the organization’s
risk strategy.
ID.AM-4: External information
systems are catalogued
EDM-
1a
EDM-
1c
EDM-
1e
EDM-
1g
RM-1c
CIP-002-5.1 R2: The Responsible Entity
shall: (2.1) Review the identifications in
Requirement R1 and its parts (and update
them if there are changes identified) at
least once every 15 calendar months,
even if it has no identified items in
Requirement R1, and; (2.2) Have its CIP
Senior Manager or delegate approve the
identifications required by Requirement R1
at least once every 15 calendar months,
even if it has no identified items in
Requirement R1.
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
46
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
IDENTIFY
(ID)
Asset Management (AM): The
data, personnel, devices, systems,
and facilities that enable the
organization to achieve business
purposes are identified and
managed consistent with their
relative importance to business
objectives and the organization’s
risk strategy.
ID.AM-4: External information
systems are catalogued
EDM-
1a
EDM-
1c
EDM-
1e
EDM-
1g
RM-1c
CIP-003-5 R1 – 1.1 to 1.9: Each
Responsible Entity, for its high impact and
medium impact BES Cyber Systems, shall
review and obtain CIP Senior Manager
approval at least once every 15 calendar
months for one or more documented cyber
security policies that collectively address
the following topics: 1.1 Personnel &
training (CIP‐004) 1.2 Electronic Security
Perimeters (CIP005) including interactive
Remote Access, 1.3 Physical Security of
BES Cyber Systems (CIP006), 1.4 System
security management (CIP007), 1.5
Incident reporting and response planning
(CIP008), 1.6 Recovery plans for BES
Cyber Systems (CIP009), 1.7
Configuration change management and
vulnerability assessments (CIP010), 1.8
Information protection (CIP011) and 1.9
Declaring and responding to CIP
Exceptional Circumstances.
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
47
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
IDENTIFY
(ID)
Asset Management (AM): The
data, personnel, devices, systems,
and facilities that enable the
organization to achieve business
purposes are identified and
managed consistent with their
relative importance to business
objectives and the organization’s
risk strategy.
ID.AM-4: External information
systems are catalogued
EDM-
1a
EDM-
1c
EDM-
1e
EDM-
1g
RM-1c
CIP-003 R2: Each Responsible Entity for
its assets identified in CIP-002-5,
Requirement R1, Part R1.3, shall
implement, in a manner that identifies,
assesses, and corrects deficiencies,
one or more documented cyber security
policies that collectively address the
following topics, and review and obtain
CIP Senior Manager approval for those
policies at least once every 15 calendar
months: [Violation Risk Factor: Lower]
[Time Horizon: Operations Planning]
2.1 Cyber security awareness;
2.2 Physical security controls;
2.3 Electronic access controls for external
routable protocol connections and Dial-up
Connectivity; and
2.4 Incident response to a Cyber Security
Incident.
An inventory, list, or discrete identification
of low impact BES Cyber Systems or their
BES Cyber Assets is not required.
IDENTIFY
(ID)
Asset Management (AM): The
data, personnel, devices, systems,
and facilities that enable the
organization to achieve business
purposes are identified and
managed consistent with their
relative importance to business
objectives and the organization’s
risk strategy.
ID.AM-4: External information
systems are catalogued
EDM-
1a
EDM-
1c
EDM-
1e
EDM-
1g
RM-1c
CIP-005-5 R1: Each Responsible Entity
shall implement one or more documented
processes that collectively include each of
the applicable requirement parts in CIP-
005-5 Table R1 – Electronic Security
Perimeter.
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
48
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
IDENTIFY
(ID)
Asset Management (AM): The
data, personnel, devices, systems,
and facilities that enable the
organization to achieve business
purposes are identified and
managed consistent with their
relative importance to business
objectives and the organization’s
risk strategy.
ID.AM-5: Resources (e.g.,
hardware, devices, data, and
software) are prioritized based
on their classification, criticality,
and business value
ACM-
1a
ACM-
1b
ACM-
1c
ACM-
1d
CIP-002-5.1 R1: Each Responsible Entity
shall implement a process that considers
each of the following assets for purposes
of parts 1.1 through 1.3: i. Control Centers
and backup Control Centers; ii.
Transmission stations and substations; iii.
Generation resources; iv. Systems and
facilities critical to system restoration,
including Blackstart Resources and
Cranking Paths and initial switching
requirements; v. Special Protection
Systems that support the reliable
operation of the Bulk Electric System; and
vi. For Distribution Providers, Protection
Systems specified in Applicability section
4.2.1 above.
IDENTIFY
(ID)
Asset Management (AM): The
data, personnel, devices, systems,
and facilities that enable the
organization to achieve business
purposes are identified and
managed consistent with their
relative importance to business
objectives and the organization’s
risk strategy.
ID.AM-5: Resources (e.g.,
hardware, devices, data, and
software) are prioritized based
on their classification, criticality,
and business value
ACM-
1a
ACM-
1b
ACM-
1c
ACM-
1d
CIP-003-5 R1 – 1.1 to 1.9: Each
Responsible Entity, for its high impact and
medium impact BES Cyber Systems, shall
review and obtain CIP Senior Manager
approval at least once every 15 calendar
months for one or more documented cyber
security policies that collectively address
the following topics: 1.1 Personnel &
training (CIP‐004) 1.2 Electronic Security
Perimeters (CIP005) including interactive
Remote Access, 1.3 Physical Security of
BES Cyber Systems (CIP006), 1.4 System
security management (CIP007), 1.5
Incident reporting and response planning
(CIP008), 1.6 Recovery plans for BES
Cyber Systems (CIP009), 1.7
Configuration change management and
vulnerability assessments (CIP010), 1.8
Information protection (CIP011) and 1.9
Declaring and responding to CIP
Exceptional Circumstances.
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
49
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
IDENTIFY
(ID)
Asset Management (AM): The
data, personnel, devices, systems,
and facilities that enable the
organization to achieve business
purposes are identified and
managed consistent with their
relative importance to business
objectives and the organization’s
risk strategy.
ID.AM-5: Resources (e.g.,
hardware, devices, data, and
software) are prioritized based
on their classification, criticality,
and business value
ACM-
1a
ACM-
1b
ACM-
1c
ACM-
1d
CIP-003 R2: Each Responsible Entity for
its assets identified in CIP-002-5,
Requirement R1, Part R1.3, shall
implement, in a manner that identifies,
assesses, and corrects deficiencies,
one or more documented cyber security
policies that collectively address the
following topics, and review and obtain
CIP Senior Manager approval for those
policies at least once every 15 calendar
months: [Violation Risk Factor: Lower]
[Time Horizon: Operations Planning]
2.1 Cyber security awareness;
2.2 Physical security controls;
2.3 Electronic access controls for external
routable protocol connections and Dial-up
Connectivity; and
2.4 Incident response to a Cyber Security
Incident.
An inventory, list, or discrete identification
of low impact BES Cyber Systems or their
BES Cyber Assets is not required.
IDENTIFY
(ID)
Asset Management (AM): The
data, personnel, devices, systems,
and facilities that enable the
organization to achieve business
purposes are identified and
managed consistent with their
relative importance to business
objectives and the organization’s
risk strategy.
ID.AM-5: Resources (e.g.,
hardware, devices, data, and
software) are prioritized based
on their classification, criticality,
and business value
ACM-
1a
ACM-
1b
ACM-
1c
ACM-
1d
CIP-005-5 R1: Each Responsible Entity
shall implement one or more documented
processes that collectively include each of
the applicable requirement parts in CIP-
005-5 Table R1 – Electronic Security
Perimeter.
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
50
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
IDENTIFY
(ID)
Asset Management (AM): The
data, personnel, devices, systems,
and facilities that enable the
organization to achieve business
purposes are identified and
managed consistent with their
relative importance to business
objectives and the organization’s
risk strategy.
ID.AM-5: Resources (e.g.,
hardware, devices, data, and
software) are prioritized based
on their classification, criticality,
and business value
ACM-
1a
ACM-
1b
ACM-
1c
ACM-
1d
CIP-009-5 R1 – 1.1: Each Responsible
Entity shall have one or more documented
recovery plans that collectively include
each of the applicable requirement parts in
CIP‐009‐5 Table R1:
1.1 Conditions for activation of the
recovery plan(s).
IDENTIFY
(ID)
Asset Management (AM): The
data, personnel, devices, systems,
and facilities that enable the
organization to achieve business
purposes are identified and
managed consistent with their
relative importance to business
objectives and the organization’s
risk strategy.
ID.AM-6: Cybersecurity roles
and responsibilities for the
entire workforce and third-party
stakeholders (e.g., suppliers,
customers, partners) are
established
WM-1a
WM-1b
WM-1c
CIP-003-5 R1 – 1.1: Each Responsible
Entity, for its high impact and medium
impact BES Cyber Systems, shall review
and obtain CIP Senior Manager approval
at least once every 15 calendar months for
one or more documented cyber security
policies that collectively address the
following topics: Personnel & training (CIP‐
004)
IDENTIFY
(ID)
Asset Management (AM): The
data, personnel, devices, systems,
and facilities that enable the
organization to achieve business
purposes are identified and
managed consistent with their
relative importance to business
objectives and the organization’s
risk strategy.
ID.AM-6: Cybersecurity roles
and responsibilities for the
entire workforce and third-party
stakeholders (e.g., suppliers,
customers, partners) are
established
WM-1a
WM-1b
WM-1c
CIP-003-5 R3: Each Responsible Entity
shall identify a CIP Senior Manager by
name and document any change within 30
calendar days of the change.
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
51
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
IDENTIFY
(ID)
Asset Management (AM): The
data, personnel, devices, systems,
and facilities that enable the
organization to achieve business
purposes are identified and
managed consistent with their
relative importance to business
objectives and the organization’s
risk strategy.
ID.AM-6: Cybersecurity roles
and responsibilities for the
entire workforce and third-party
stakeholders (e.g., suppliers,
customers, partners) are
established
WM-1a
WM-1b
WM-1c
CIP-003-5 R4: The Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, a documented process to
delegate authority, unless no delegations
are used. Where allowed by the CIP
Standards, the CIP Senior Manager may
delegate authority for specific actions to a
delegate or delegates. These delegations
shall be documented, including the name
or title of the delegate, the specific actions
delegated, and the date of the delegation;
approved by the CIP Senior Manager; and
updated within 30 days of any change to
the delegation. Delegation changes do not
need to be reinstated with a change to the
delegator.
IDENTIFY
(ID)
Asset Management (AM): The
data, personnel, devices, systems,
and facilities that enable the
organization to achieve business
purposes are identified and
managed consistent with their
relative importance to business
objectives and the organization’s
risk strategy.
ID.AM-6: Cybersecurity roles
and responsibilities for the
entire workforce and third-party
stakeholders (e.g., suppliers,
customers, partners) are
established
WM-1a
WM-1b
WM-1c
CIP-004-5.1 R4: Each Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, one or more documented
access management programs that
collectively include each of the applicable
requirement parts in CIP‐004‐5.1 Table R4
– Access Management Program.
IDENTIFY
(ID)
Business Environment (BE): The
organization’s mission, objectives,
stakeholders, and activities are
understood and prioritized; this
information is used to inform
cybersecurity roles,
responsibilities, and risk
management decisions.
ID.BE-1: The organization’s
role in the supply chain is
identified and communicated
EDM-
1b
EDM-
1d
EDM-
1f
EDM-
1g
RM-1c
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
52
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
IDENTIFY
(ID)
Business Environment (BE): The
organization’s mission, objectives,
stakeholders, and activities are
understood and prioritized; this
information is used to inform
cybersecurity roles,
responsibilities, and risk
management decisions.
ID.BE-2: The organization’s
place in critical infrastructure
and its industry sector is
identified and communicated
EDM-
1b
EDM-
1d
CPM-
1c
EDM-
1f
EDM-
1g
RM-1c
IDENTIFY
(ID)
Business Environment (BE): The
organization’s mission, objectives,
stakeholders, and activities are
understood and prioritized; this
information is used to inform
cybersecurity roles,
responsibilities, and risk
management decisions.
ID.BE-3: Priorities for
organizational mission,
objectives, and activities are
established and communicated
RM-3b
RM-1c
IDENTIFY
(ID)
Business Environment (BE): The
organization’s mission, objectives,
stakeholders, and activities are
understood and prioritized; this
information is used to inform
cybersecurity roles,
responsibilities, and risk
management decisions.
ID.BE-4: Dependencies and
critical functions for delivery of
critical services are established
ACM-
1a
ACM-
1b
EDM-
1a
ACM-
1c
ACM-
1d
EDM-
1c
EDM-
1e
ACM-
1e
ACM-
1f
RM-1c
EDM-
1g
CIP-002-5.1 R1: Each Responsible Entity
shall implement a process that considers
each of the following assets for purposes
of parts 1.1 through 1.3: i. Control Centers
and backup Control Centers; ii.
Transmission stations and substations; iii.
Generation resources; iv. Systems and
facilities critical to system restoration,
including Blackstart Resources and
Cranking Paths and initial switching
requirements; v. Special Protection
Systems that support the reliable
operation of the Bulk Electric System; and
vi. For Distribution Providers, Protection
Systems specified in Applicability section
4.2.1 above.
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
53
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
IDENTIFY
(ID)
Business Environment (BE): The
organization’s mission, objectives,
stakeholders, and activities are
understood and prioritized; this
information is used to inform
cybersecurity roles,
responsibilities, and risk
management decisions.
ID.BE-5: Resilience
requirements to support
delivery of critical services are
established
IR-4a
IR-4b
IR-4c
IR-4e
CIP-009-5 R1: Each Responsible Entity
shall have one or more documented
recovery plans that collectively include
each of the applicable requirement parts in
CIP‐009‐5 Table R1 – Recovery Plan
Specifications.
IDENTIFY
(ID)
Governance (GV): The policies,
procedures, and processes to
manage and monitor the
organization’s regulatory, legal,
risk, environmental, and
operational requirements are
understood and inform the
management of cybersecurity risk.
ID.GV-1: Organizational
information security policy is
established
RM-1a CPM-
2g
CPM-
5d
RM-3e
CIP-003-5 R1 – 1.1 to 1.9: Each
Responsible Entity, for its high impact and
medium impact BES Cyber Systems, shall
review and obtain CIP Senior Manager
approval at least once every 15 calendar
months for one or more documented cyber
security policies that collectively address
the following topics: 1.1 Personnel &
training (CIP‐004) 1.2 Electronic Security
Perimeters (CIP005) including interactive
Remote Access, 1.3 Physical Security of
BES Cyber Systems (CIP006), 1.4 System
security management (CIP007), 1.5
Incident reporting and response planning
(CIP008), 1.6 Recovery plans for BES
Cyber Systems (CIP009), 1.7
Configuration change management and
vulnerability assessments (CIP010), 1.8
Information protection (CIP011) and 1.9
Declaring and responding to CIP
Exceptional Circumstances.
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
54
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
IDENTIFY
(ID)
Governance (GV): The policies,
procedures, and processes to
manage and monitor the
organization’s regulatory, legal,
risk, environmental, and
operational requirements are
understood and inform the
management of cybersecurity risk.
ID.GV-1: Organizational
information security policy is
established
RM-1a CPM-
2g
CPM-
5d
RM-3e
CIP-003-5 R2: Each Responsible Entity for
its assets identified in CIP‐002‐5,
Requirement R1, Part R1.3, shall
implement, in a manner that identifies,
assesses, and corrects deficiencies, one
or more documented cyber security
policies that collectively address the
following topics, and review and obtain
CIP Senior Manager approval for those
policies at least once every 15 calendar
months: (An inventory, list, or discrete
identification of low impact BES Cyber
Systems or their BES Cyber Assets is not
required). (2.1) Cyber security awareness;
(2.2) Physical security controls; (2.3)
Electronic access controls for external
routable protocol connections and Dial‐up
Connectivity; and (2.4) Incident response
to a Cyber Security Incident.
IDENTIFY
(ID)
Governance (GV): The policies,
procedures, and processes to
manage and monitor the
organization’s regulatory, legal,
risk, environmental, and
operational requirements are
understood and inform the
management of cybersecurity risk.
ID.GV-1: Organizational
information security policy is
established
RM-1a CPM-
2g
CPM-
5d
RM-3e
CIP-004-5.1 R1: Each Responsible Entity
shall implement one or more documented
processes that collectively include each of
the applicable requirement parts in CIP‐
004‐5.1 Table R1 – Security Awareness
Program. (1.1) Security awareness that, at
least once each calendar quarter,
reinforces cyber security practices (which
may include associated physical security
practices) for the Responsible Entity’s
personnel who have authorized electronic
or authorized unescorted physical access
to BES Cyber Systems.
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
55
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
IDENTIFY
(ID)
Governance (GV): The policies,
procedures, and processes to
manage and monitor the
organization’s regulatory, legal,
risk, environmental, and
operational requirements are
understood and inform the
management of cybersecurity risk.
ID.GV-1: Organizational
information security policy is
established
RM-1a CPM-
2g
CPM-
5d
RM-3e
CIP-004-5.1 R3: Each Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, one or more documented
personnel risk assessment programs to
attain and retain authorized electronic or
authorized unescorted physical access to
BES Cyber Systems that collectively
include each of the applicable requirement
parts in CIP‐004‐5.1 Table R3 – Personnel
Risk Assessment Program.
IDENTIFY
(ID)
Governance (GV): The policies,
procedures, and processes to
manage and monitor the
organization’s regulatory, legal,
risk, environmental, and
operational requirements are
understood and inform the
management of cybersecurity risk.
ID.GV-2: Information security
roles & responsibilities are
coordinated and aligned with
internal roles and external
partners
WM-1a
WM-1b
WM-1c
WM-5b
ISC-2b
WM-1f
WM-1g
CIP-003-5 R3: Each Responsible Entity
shall identify a CIP Senior Manager by
name and document any change within 30
calendar days of the change.
IDENTIFY
(ID)
Governance (GV): The policies,
procedures, and processes to
manage and monitor the
organization’s regulatory, legal,
risk, environmental, and
operational requirements are
understood and inform the
management of cybersecurity risk.
ID.GV-2: Information security
roles & responsibilities are
coordinated and aligned with
internal roles and external
partners
WM-1a
WM-1b
WM-1c
WM-5b
ISC-2b
WM-1f
WM-1g
CIP-003-5 R4: The Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, a documented process to
delegate authority, unless no delegations
are used. Where allowed by the CIP
Standards, the CIP Senior Manager may
delegate authority for specific actions to a
delegate or delegates. These delegations
shall be documented, including the name
or title of the delegate, the specific actions
delegated, and the date of the delegation;
approved by the CIP Senior Manager; and
updated within 30 days of any change to
the delegation. Delegation changes do not
need to be reinstated with a change to the
delegator.
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
56
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
IDENTIFY
(ID)
Governance (GV): The policies,
procedures, and processes to
manage and monitor the
organization’s regulatory, legal,
risk, environmental, and
operational requirements are
understood and inform the
management of cybersecurity risk.
ID.GV-3: Legal and regulatory
requirements regarding
cybersecurity, including privacy
and civil liberties obligations,
are understood and managed
CPM-
2k
IR-3n
RM-3f
ACM-
4f
IAM-3f
TVM-
3f
SA-4f
ISC-2f
IR-5f
EDM-
3f
WM-5f
IDENTIFY
(ID)
Governance (GV): The policies,
procedures, and processes to
manage and monitor the
organization’s regulatory, legal,
risk, environmental, and
operational requirements are
understood and inform the
management of cybersecurity risk.
ID.GV-4: Governance and risk
management processes
address cybersecurity risks
RM-2a
RM-2b
RM-3b RM-2h
RM-3e
RM-1c
RM-1e
IDENTIFY
(ID)
Risk Assessment (RA): The
organization understands the
cybersecurity risk to organizational
operations (including mission,
functions, image, or reputation),
organizational assets, and
individuals.
ID.RA-1: Asset vulnerabilities
are identified and documented
TVM-
2a
TVM-
2b
TVM-
2c
TVM-
2d
TVM-
2e
TVM-
2f
RM-1c
RM-2j
TVM-
2i
TVM-
2j
TVM-
2k
TVM-
2l
TVM-
2m
CIP-010-1 R3: Each Responsible Entity
shall implement one or more documented
processes that collectively include each of
the applicable requirement parts in CIP ‐
010 ‐ 1 Table R3– Vulnerability
Assessments.
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
57
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
IDENTIFY
(ID)
Risk Assessment (RA): The
organization understands the
cybersecurity risk to organizational
operations (including mission,
functions, image, or reputation),
organizational assets, and
individuals.
ID.RA-1: Asset vulnerabilities
are identified and documented
TVM-
2a
TVM-
2b
TVM-
2c
TVM-
2d
TVM-
2e
TVM-
2f
RM-1c
RM-2j
TVM-
2i
TVM-
2j
TVM-
2k
TVM-
2l
TVM-
2m
CIP-003-5 R1 – 1.2: Each Responsible
Entity, for its high impact and medium
impact BES Cyber Systems, shall review
and obtain CIP Senior Manager approval
at least once every 15 calendar months for
one or more documented cyber security
policies that collectively address the
following topics: Electronic Security
Perimeters (CIP‐005) including Interactive
Remote Access;
IDENTIFY
(ID)
Risk Assessment (RA): The
organization understands the
cybersecurity risk to organizational
operations (including mission,
functions, image, or reputation),
organizational assets, and
individuals.
ID.RA-1: Asset vulnerabilities
are identified and documented
TVM-
2a
TVM-
2b
TVM-
2c
TVM-
2d
TVM-
2e
TVM-
2f
RM-1c
RM-2j
TVM-
2i
TVM-
2j
TVM-
2k
TVM-
2l
TVM-
2m
CIP-003-5 R1 – 1.4: Each Responsible
Entity, for its high impact and medium
impact BES Cyber Systems, shall review
and obtain CIP Senior Manager approval
at least once every 15 calendar months for
one or more documented cyber security
policies that collectively address the
following topics: System security
management (CIP‐007);
IDENTIFY
(ID)
Risk Assessment (RA): The
organization understands the
cybersecurity risk to organizational
operations (including mission,
functions, image, or reputation),
organizational assets, and
individuals.
ID.RA-1: Asset vulnerabilities
are identified and documented
TVM-
2a
TVM-
2b
TVM-
2c
TVM-
2d
TVM-
2e
TVM-
2f
RM-1c
RM-2j
TVM-
2i
TVM-
2j
TVM-
2k
TVM-
2l
TVM-
2m
CIP-003-5 R1 – 1.7: Each Responsible
Entity, for its high impact and medium
impact BES Cyber Systems, shall review
and obtain CIP Senior Manager approval
at least once every 15 calendar months for
one or more documented cyber security
policies that collectively address the
following topics: Configuration change
management and vulnerability
assessments (CIP‐010);
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
58
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
IDENTIFY
(ID)
Risk Assessment (RA): The
organization understands the
cybersecurity risk to organizational
operations (including mission,
functions, image, or reputation),
organizational assets, and
individuals.
ID.RA-1: Asset vulnerabilities
are identified and documented
TVM-
2a
TVM-
2b
TVM-
2c
TVM-
2d
TVM-
2e
TVM-
2f
RM-1c
RM-2j
TVM-
2i
TVM-
2j
TVM-
2k
TVM-
2l
TVM-
2m
CIP-003-5 R1 – 1.3: Each Responsible
Entity, for its high impact and medium
impact BES Cyber Systems, shall review
and obtain CIP Senior Manager approval
at least once every 15 calendar months for
one or more documented cyber security
policies that collectively address the
following topics: Physical security of BES
Cyber Systems (CIP‐006);
IDENTIFY
(ID)
Risk Assessment (RA): The
organization understands the
cybersecurity risk to organizational
operations (including mission,
functions, image, or reputation),
organizational assets, and
individuals.
ID.RA-1: Asset vulnerabilities
are identified and documented
TVM-
2a
TVM-
2b
TVM-
2c
TVM-
2d
TVM-
2e
TVM-
2f
RM-1c
RM-2j
TVM-
2i
TVM-
2j
TVM-
2k
TVM-
2l
TVM-
2m
CIP-007-5 R2: Each Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, one or more documented
processes that collectively include each of
the applicable requirement parts in CIP-
007-5 Table R2 – Security Patch
Management.
IDENTIFY
(ID)
Risk Assessment (RA): The
organization understands the
cybersecurity risk to organizational
operations (including mission,
functions, image, or reputation),
organizational assets, and
individuals.
ID.RA-2: Threat and
vulnerability information is
received from information
sharing forums and sources
TVM-
1a
TVM-
1b
TVM-
2a
TVM-
2b
CIP-007-5 R2: Each Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, one or more documented
processes that collectively include each of
the applicable requirement parts in CIP-
007-5 Table R2 – Security Patch
Management.
IDENTIFY
(ID)
Risk Assessment (RA): The
organization understands the
cybersecurity risk to organizational
operations (including mission,
functions, image, or reputation),
ID.RA-2: Threat and
vulnerability information is
received from information
sharing forums and sources
TVM-
1a
TVM-
1b
TVM-
CIP-010-1 R3: Each Responsible Entity
shall implement one or more documented
processes that collectively include each of
the applicable requirement parts in CIP ‐
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
59
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
organizational assets, and
individuals.
2a
TVM-
2b
010 ‐ 1 Table R3– Vulnerability
Assessments.
IDENTIFY
(ID)
Risk Assessment (RA): The
organization understands the
cybersecurity risk to organizational
operations (including mission,
functions, image, or reputation),
organizational assets, and
individuals.
ID.RA-3: Threats, both internal
and external, are identified and
documented
TVM-
1a
TVM-
1b
TVM-
1d
TVM-
1e
TVM-
1f
RM-1c
RM-2j
TVM-
1i
TVM-
1j
CIP-007-5 R4 – 4.1: Log events at the BES
Cyber System level (per BES Cyber
System capability) or at the Cyber Asset
level (per Cyber Asset capability) for
identification of, and after-the-fact
investigations of, Cyber Security Incidents
that includes,
as a minimum, each of the following types
of events:
4.1.1. Detected successful login attempts;
4.1.2. Detected failed access attempts and
failed login attempts;
4.1.3. Detected malicious code.
IDENTIFY
(ID)
Risk Assessment (RA): The
organization understands the
cybersecurity risk to organizational
operations (including mission,
functions, image, or reputation),
organizational assets, and
individuals.
ID.RA-4: Potential business
impacts and likelihoods are
identified
TVM-
1d
TVM-
1f
TVM-
1i
CIP-002-5.1 R1: Each Responsible Entity
shall implement a process that considers
each of the following assets for purposes
of parts 1.1 through 1.3: i. Control Centers
and backup Control Centers; ii.
Transmission stations and substations; iii.
Generation resources; iv. Systems and
facilities critical to system restoration,
including Blackstart Resources and
Cranking Paths and initial switching
requirements; v. Special Protection
Systems that support the reliable
operation of the Bulk Electric System; and
vi. For Distribution Providers, Protection
Systems specified in Applicability section
4.2.1 above.
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
60
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
IDENTIFY
(ID)
Risk Assessment (RA): The
organization understands the
cybersecurity risk to organizational
operations (including mission,
functions, image, or reputation),
organizational assets, and
individuals.
ID.RA-5: Threats,
vulnerabilities, likelihoods, and
impacts are used to determine
risk
RM-1c
RM-2j
TVM-
1i
TVM-
2l
TVM-
2m
CIP-007-5 R2: Each Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, one or more documented
processes that collectively include each of
the applicable requirement parts in CIP-
007-5 Table R2 – Security Patch
Management.
IDENTIFY
(ID)
Risk Assessment (RA): The
organization understands the
cybersecurity risk to organizational
operations (including mission,
functions, image, or reputation),
organizational assets, and
individuals.
ID.RA-5: Threats,
vulnerabilities, likelihoods, and
impacts are used to determine
risk
RM-1c
RM-2j
TVM-
1i
TVM-
2l
TVM-
2m
CIP-010-1 R3: Each Responsible Entity
shall implement one or more documented
processes that collectively include each of
the applicable requirement parts in CIP ‐
010 ‐ 1 Table R3– Vulnerability
Assessments.
IDENTIFY
(ID)
Risk Assessment (RA): The
organization understands the
cybersecurity risk to organizational
operations (including mission,
functions, image, or reputation),
organizational assets, and
individuals.
ID.RA-6: Risk responses are
identified and prioritized
RM-2e RM-1c
RM-2j
TVM-
1i
TVM-
2l
IR-3m
IR-4d
IR-4e
CIP-007-5 R2: Each Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, one or more documented
processes that collectively include each of
the applicable requirement parts in CIP-
007-5 Table R2 – Security Patch
Management.
IDENTIFY
(ID)
Risk Assessment (RA): The
organization understands the
cybersecurity risk to organizational
operations (including mission,
functions, image, or reputation),
organizational assets, and
individuals.
ID.RA-6: Risk responses are
identified and prioritized
RM-2e RM-1c
RM-2j
TVM-
1i
TVM-
2l
IR-3m
IR-4d
IR-4e
CIP-008-5 R1 – 1.1: Each Responsible
Entity shall document one or more Cyber
Security Incident response plan(s) that
collectively include
1.1 One or more processes to identify,
classify, and respond to Cyber Security
Incidents.
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
61
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
IDENTIFY
(ID)
Risk Assessment (RA): The
organization understands the
cybersecurity risk to organizational
operations (including mission,
functions, image, or reputation),
organizational assets, and
individuals.
ID.RA-6: Risk responses are
identified and prioritized
RM-2e RM-1c
RM-2j
TVM-
1i
TVM-
2l
IR-3m
IR-4d
IR-4e
CIP-010-1 R3: Each Responsible Entity
shall implement one or more documented
processes that collectively include each of
the applicable requirement parts in CIP ‐
010 ‐ 1 Table R3– Vulnerability
Assessments.
IDENTIFY
(ID)
Risk Management Strategy
(RM): The organization’s priorities,
constraints, risk tolerances, and
assumptions are established and
used to support operational risk
decisions.
ID.RM-1: Risk management
processes are established,
managed, and agreed to by
organizational stakeholders
RM-2a
RM-2b
RM-1a
RM-1b
RM-2c
RM-2d
RM-2e
RM-2f
RM-2g
RM-3a
RM-3b
RM-3c
RM-3d
RM-1c
RM-1d
RM-1e
RM-2h
RM-2i
RM-2j
RM-3e
RM-3f
RM-3g
RM-3h
RM-3i
IDENTIFY
(ID)
Risk Management Strategy
(RM): The organization’s priorities,
constraints, risk tolerances, and
assumptions are established and
used to support operational risk
decisions.
ID.RM-2: Organizational risk
tolerance is determined and
clearly expressed
RM-1c
RM-1e
IDENTIFY
(ID)
Risk Management Strategy
(RM): The organization’s priorities,
constraints, risk tolerances, and
assumptions are established and
used to support operational risk
decisions.
ID.RM-3: The organization’s
determination of risk tolerance
is informed by their role in
critical infrastructure and sector
specific risk analysis
RM-1b RM-1c
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
62
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
PROTECT
(PR)
Access Control (AC): Access to
assets and associated facilities is
limited to authorized users,
processes, or devices, and to
authorized activities and
transactions.
PR.AC-1: Identities and
credentials are managed for
authorized devices and users
IAM-
1a
IAM-
1b
IAM-
1c
IAM-
1d
IAM-
1e
IAM-1f
RM-1c
IAM-
1g
CIP-003-5 R1 – 1.1: Each Responsible
Entity, for its high impact and medium
impact BES Cyber Systems, shall review
and obtain CIP Senior Manager approval
at least once every 15 calendar months for
one or more documented cyber security
policies that collectively address the
following topics: Personnel & training (CIP‐
004)
PROTECT
(PR)
Access Control (AC): Access to
assets and associated facilities is
limited to authorized users,
processes, or devices, and to
authorized activities and
transactions.
PR.AC-1: Identities and
credentials are managed for
authorized devices and users
IAM-
1a
IAM-
1b
IAM-
1c
IAM-
1d
IAM-
1e
IAM-1f
RM-1c
IAM-
1g
CIP-003-5 R1 – 1.4: Each Responsible
Entity, for its high impact and medium
impact BES Cyber Systems, shall review
and obtain CIP Senior Manager approval
at least once every 15 calendar months for
one or more documented cyber security
policies that collectively address the
following topics: System security
management (CIP‐007);
PROTECT
(PR)
Access Control (AC): Access to
assets and associated facilities is
limited to authorized users,
processes, or devices, and to
authorized activities and
transactions.
PR.AC-1: Identities and
credentials are managed for
authorized devices and users
IAM-
1a
IAM-
1b
IAM-
1c
IAM-
1d
IAM-
1e
IAM-1f
RM-1c
IAM-
1g
CIP-003-5 R2 – 2.3: Each Responsible
Entity for its assets identified in CIP-002-5,
Requirement R1, Part R1.3 (i.e., low
impact), shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, one or more documented
cyber security policies that collectively
address the following topics, and review
and obtain CIP Senior Manager approval
for those policies at least once every 15
calendar months: Electronic access
controls for external routable protocol
connections and Dial-up Connectivity
PROTECT
(PR)
Access Control (AC): Access to
assets and associated facilities is
limited to authorized users,
processes, or devices, and to
authorized activities and
transactions.
PR.AC-1: Identities and
credentials are managed for
authorized devices and users
IAM-
1a
IAM-
1b
IAM-
1c
IAM-
1d
IAM-
1e
IAM-1f
RM-1c
IAM-
1g
CIP-004-5.1 R4: Each Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, one or more documented
access management programs that
collectively include each of the applicable
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
63
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
requirement parts in CIP‐004‐5.1 Table R4
– Access Management Program.
PROTECT
(PR)
Access Control (AC): Access to
assets and associated facilities is
limited to authorized users,
processes, or devices, and to
authorized activities and
transactions.
PR.AC-1: Identities and
credentials are managed for
authorized devices and users
IAM-
1a
IAM-
1b
IAM-
1c
IAM-
1d
IAM-
1e
IAM-1f
RM-1c
IAM-
1g
CIP-004-5.1 R5: Each Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, one or more documented
access revocation programs that
collectively include each of the applicable
requirement parts in CIP‐004‐5.1 Table R5
– Access Revocation.
PROTECT
(PR)
Access Control (AC): Access to
assets and associated facilities is
limited to authorized users,
processes, or devices, and to
authorized activities and
transactions.
PR.AC-1: Identities and
credentials are managed for
authorized devices and users
IAM-
1a
IAM-
1b
IAM-
1c
IAM-
1d
IAM-
1e
IAM-1f
RM-1c
IAM-
1g
CIP-007-5 R5: Each Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, one or more documented
processes that collectively include each of
the applicable requirement parts in CIP-
007-5 Table R5 – System Access
Controls.
PROTECT
(PR)
Access Control (AC): Access to
assets and associated facilities is
limited to authorized users,
processes, or devices, and to
authorized activities and
transactions.
PR.AC-2: Physical access to
assets is managed and
protected
IAM-
2a
IAM-
2b
IAM-
2c
IAM-
2d
IAM-
2e
IAM-2f
IAM-
2g
CIP-003-5 R1 – 1.1: Each Responsible
Entity, for its high impact and medium
impact BES Cyber Systems, shall review
and obtain CIP Senior Manager approval
at least once every 15 calendar months for
one or more documented cyber security
policies that collectively address the
following topics: Personnel & training (CIP‐
004)
PROTECT
(PR)
Access Control (AC): Access to
assets and associated facilities is
limited to authorized users,
processes, or devices, and to
authorized activities and
transactions.
PR.AC-2: Physical access to
assets is managed and
protected
IAM-
2a
IAM-
2b
IAM-
2c
IAM-
2d
IAM-
2e
IAM-2f
IAM-
2g
CIP-003-5 R1 – 1.3: Each Responsible
Entity, for its high impact and medium
impact BES Cyber Systems, shall review
and obtain CIP Senior Manager approval
at least once every 15 calendar months for
one or more documented cyber security
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
64
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
policies that collectively address the
following topics: Physical security of BES
Cyber Systems (CIP‐006);
PROTECT
(PR)
Access Control (AC): Access to
assets and associated facilities is
limited to authorized users,
processes, or devices, and to
authorized activities and
transactions.
PR.AC-2: Physical access to
assets is managed and
protected
IAM-
2a
IAM-
2b
IAM-
2c
IAM-
2d
IAM-
2e
IAM-2f
IAM-
2g
CIP-003-5 R2 – 2.2: Each Responsible
Entity for its assets identified in CIP‐002‐5,
Requirement R1, Part R1.3, shall
implement, in a manner that identifies,
assesses, and corrects deficiencies, one
or more documented cyber security
policies that collectively address the
following topics, and review and obtain
CIP Senior Manager approval for those
policies at least once every 15 calendar
months: Physical security controls;
PROTECT
(PR)
Access Control (AC): Access to
assets and associated facilities is
limited to authorized users,
processes, or devices, and to
authorized activities and
transactions.
PR.AC-2: Physical access to
assets is managed and
protected
IAM-
2a
IAM-
2b
IAM-
2c
IAM-
2d
IAM-
2e
IAM-2f
IAM-
2g
CIP-004-5.1 R4: Each Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, one or more documented
access management programs that
collectively include each of the applicable
requirement parts in CIP‐004‐5.1 Table R4
– Access Management Program.
PROTECT
(PR)
Access Control (AC): Access to
assets and associated facilities is
limited to authorized users,
processes, or devices, and to
authorized activities and
transactions.
PR.AC-2: Physical access to
assets is managed and
protected
IAM-
2a
IAM-
2b
IAM-
2c
IAM-
2d
IAM-
2e
IAM-2f
IAM-
2g
CIP-004-5.1 R5: Each Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, one or more documented
access revocation programs that
collectively include each of the applicable
requirement parts in CIP‐004‐5.1 Table R5
– Access Revocation.
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
65
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
PROTECT
(PR)
Access Control (AC): Access to
assets and associated facilities is
limited to authorized users,
processes, or devices, and to
authorized activities and
transactions.
PR.AC-2: Physical access to
assets is managed and
protected
IAM-
2a
IAM-
2b
IAM-
2c
IAM-
2d
IAM-
2e
IAM-2f
IAM-
2g
CIP-006-5 R1: Each Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, one or more documented
physical security plans that collectively
include all of the applicable requirement
parts in CIP-006-5 Table R1 – Physical
Security Plan.
PROTECT
(PR)
Access Control (AC): Access to
assets and associated facilities is
limited to authorized users,
processes, or devices, and to
authorized activities and
transactions.
PR.AC-2: Physical access to
assets is managed and
protected
IAM-
2a
IAM-
2b
IAM-
2c
IAM-
2d
IAM-
2e
IAM-2f
IAM-
2g
CIP-006-5 R2: Each Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, one or more documented
visitor control programs that include each
of the applicable requirement parts in CIP-
006-5 Table R2 – Visitor Control Program.
PROTECT
(PR)
Access Control (AC): Access to
assets and associated facilities is
limited to authorized users,
processes, or devices, and to
authorized activities and
transactions.
PR.AC-3: Remote access is
managed
IAM-
2a
IAM-
2b
IAM-
2c
IAM-
2d
IAM-
2e
IAM-2f
IAM-
2g
CIP-003-5 R1 – 1.1: Each Responsible
Entity, for its high impact and medium
impact BES Cyber Systems, shall review
and obtain CIP Senior Manager approval
at least once every 15 calendar months for
one or more documented cyber security
policies that collectively address the
following topics: Personnel & training (CIP‐
004)
PROTECT
(PR)
Access Control (AC): Access to
assets and associated facilities is
limited to authorized users,
processes, or devices, and to
authorized activities and
transactions.
PR.AC-3: Remote access is
managed
IAM-
2a
IAM-
2b
IAM-
2c
IAM-
2d
IAM-
2e
IAM-2f
IAM-
2g
CIP-003-5 R1 – 1.2: Each Responsible
Entity, for its high impact and medium
impact BES Cyber Systems, shall review
and obtain CIP Senior Manager approval
at least once every 15 calendar months for
one or more documented cyber security
policies that collectively address the
following topics: Electronic Security
Perimeters (CIP‐005) including Interactive
Remote Access;
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
66
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
PROTECT
(PR)
Access Control (AC): Access to
assets and associated facilities is
limited to authorized users,
processes, or devices, and to
authorized activities and
transactions.
PR.AC-3: Remote access is
managed
IAM-
2a
IAM-
2b
IAM-
2c
IAM-
2d
IAM-
2e
IAM-2f
IAM-
2g
CIP-003-5 R2 – 2.3: Each Responsible
Entity for its assets identified in CIP-002-5,
Requirement R1, Part R1.3 (i.e., low
impact), shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, one or more documented
cyber security policies that collectively
address the following topics, and review
and obtain CIP Senior Manager approval
for those policies at least once every 15
calendar months: Electronic access
controls for external routable protocol
connections and Dial-up Connectivity
PROTECT
(PR)
Access Control (AC): Access to
assets and associated facilities is
limited to authorized users,
processes, or devices, and to
authorized activities and
transactions.
PR.AC-3: Remote access is
managed
IAM-
2a
IAM-
2b
IAM-
2c
IAM-
2d
IAM-
2e
IAM-2f
IAM-
2g
CIP-004-5.1 R4: Each Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, one or more documented
access management programs that
collectively include each of the applicable
requirement parts in CIP‐004‐5.1 Table R4
– Access Management Program.
PROTECT
(PR)
Access Control (AC): Access to
assets and associated facilities is
limited to authorized users,
processes, or devices, and to
authorized activities and
transactions.
PR.AC-3: Remote access is
managed
IAM-
2a
IAM-
2b
IAM-
2c
IAM-
2d
IAM-
2e
IAM-2f
IAM-
2g
CIP-004-5.1 R5: Each Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, one or more documented
access revocation programs that
collectively include each of the applicable
requirement parts in CIP‐004‐5.1 Table R5
– Access Revocation.
PROTECT
(PR)
Access Control (AC): Access to
assets and associated facilities is
limited to authorized users,
processes, or devices, and to
authorized activities and
transactions.
PR.AC-3: Remote access is
managed
IAM-
2a
IAM-
2b
IAM-
2c
IAM-
2d
IAM-
2e
IAM-2f
IAM-
2g
CIP-005-5 R1: Each Responsible Entity
shall implement one or more documented
processes that collectively include each of
the applicable requirement parts in CIP-
005-5 Table R1 – Electronic Security
Perimeter.
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
67
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
PROTECT
(PR)
Access Control (AC): Access to
assets and associated facilities is
limited to authorized users,
processes, or devices, and to
authorized activities and
transactions.
PR.AC-3: Remote access is
managed
IAM-
2a
IAM-
2b
IAM-
2c
IAM-
2d
IAM-
2e
IAM-2f
IAM-
2g
CIP-005-5 R2: Each Responsible Entity
allowing Interactive Remote Access to
BES Cyber Systems shall implement one
or more documented processes that
collectively include the applicable
requirement parts, where technically
feasible, in CIP-005-5 Table R2 –
Interactive Remote Access Management.
PROTECT
(PR)
Access Control (AC): Access to
assets and associated facilities is
limited to authorized users,
processes, or devices, and to
authorized activities and
transactions.
PR.AC-4: Access permissions
are managed, incorporating the
principles of least privilege and
separation of duties
IAM-
2d
CIP-003-5 R1 – 1.4: Each Responsible
Entity, for its high impact and medium
impact BES Cyber Systems, shall review
and obtain CIP Senior Manager approval
at least once every 15 calendar months for
one or more documented cyber security
policies that collectively address the
following topics: System security
management (CIP‐007);
PROTECT
(PR)
Access Control (AC): Access to
assets and associated facilities is
limited to authorized users,
processes, or devices, and to
authorized activities and
transactions.
PR.AC-4: Access permissions
are managed, incorporating the
principles of least privilege and
separation of duties
IAM-
2d
CIP-003-5 R1 – 1.8: Each Responsible
Entity, for its high impact and medium
impact BES Cyber Systems, shall review
and obtain CIP Senior Manager approval
at least once every 15 calendar months for
one or more documented cyber security
policies that collectively address the
following topics: Information protection
(CIP‐011);
PROTECT
(PR)
Access Control (AC): Access to
assets and associated facilities is
limited to authorized users,
processes, or devices, and to
authorized activities and
transactions.
PR.AC-4: Access permissions
are managed, incorporating the
principles of least privilege and
separation of duties
IAM-
2d
CIP-004-5.1 R4: Each Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, one or more documented
access management programs that
collectively include each of the applicable
requirement parts in CIP‐004‐5.1 Table R4
– Access Management Program.
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
68
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
PROTECT
(PR)
Access Control (AC): Access to
assets and associated facilities is
limited to authorized users,
processes, or devices, and to
authorized activities and
transactions.
PR.AC-4: Access permissions
are managed, incorporating the
principles of least privilege and
separation of duties
IAM-
2d
CIP-004-5.1 R5: Each Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, one or more documented
access revocation programs that
collectively include each of the applicable
requirement parts in CIP‐004‐5.1 Table R5
– Access Revocation.
PROTECT
(PR)
Access Control (AC): Access to
assets and associated facilities is
limited to authorized users,
processes, or devices, and to
authorized activities and
transactions.
PR.AC-4: Access permissions
are managed, incorporating the
principles of least privilege and
separation of duties
IAM-
2d
CIP-007-5 R5: Each Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, one or more documented
processes that collectively include each of
the applicable requirement parts in CIP-
007-5 Table R5 – System Access
Controls.
PROTECT
(PR)
Access Control (AC): Access to
assets and associated facilities is
limited to authorized users,
processes, or devices, and to
authorized activities and
transactions.
PR.AC-5: Network integrity is
protected, incorporating
network segregation where
appropriate
CPM-
3a
CPM-
3b
CPM-
3c
CPM-
3d
CIP-003-5 R1 – 1.2: Each Responsible
Entity, for its high impact and medium
impact BES Cyber Systems, shall review
and obtain CIP Senior Manager approval
at least once every 15 calendar months for
one or more documented cyber security
policies that collectively address the
following topics: Electronic Security
Perimeters (CIP‐005) including Interactive
Remote Access;
PROTECT
(PR)
Access Control (AC): Access to
assets and associated facilities is
limited to authorized users,
processes, or devices, and to
authorized activities and
transactions.
PR.AC-5: Network integrity is
protected, incorporating
network segregation where
appropriate
CPM-
3a
CPM-
3b
CPM-
3c
CPM-
3d
CIP-003-5 R1 – 1.8: Each Responsible
Entity, for its high impact and medium
impact BES Cyber Systems, shall review
and obtain CIP Senior Manager approval
at least once every 15 calendar months for
one or more documented cyber security
policies that collectively address the
following topics: Information protection
(CIP‐011);
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
69
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
PROTECT
(PR)
Access Control (AC): Access to
assets and associated facilities is
limited to authorized users,
processes, or devices, and to
authorized activities and
transactions.
PR.AC-5: Network integrity is
protected, incorporating
network segregation where
appropriate
CPM-
3a
CPM-
3b
CPM-
3c
CPM-
3d
CIP-005-5 R1: Each Responsible Entity
shall implement one or more documented
processes that collectively include each of
the applicable requirement parts in CIP-
005-5 Table R1 – Electronic Security
Perimeter.
PROTECT
(PR)
Access Control (AC): Access to
assets and associated facilities is
limited to authorized users,
processes, or devices, and to
authorized activities and
transactions.
PR.AC-5: Network integrity is
protected, incorporating
network segregation where
appropriate
CPM-
3a
CPM-
3b
CPM-
3c
CPM-
3d
CIP-007-5 R1: Each Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, one or more documented
processes that collectively include each of
the applicable requirement parts in CIP-
007-5 Table R1 – Ports and Services.
PROTECT
(PR)
Awareness and Training (AT):
The organization’s personnel and
partners are provided
cybersecurity awareness
education and are adequately
trained to perform their information
security-related duties and
responsibilities consistent with
related
policies, procedures, and
agreements.
PR.AT-1: All users are informed
and trained
WM-3a WM-3b
WM-3c
WM-3d
WM-3e
WM-3f
WM-3g
WM-3h
WM-3i
CIP-003-5 R1 – 1.1 to 1.9: Each
Responsible Entity, for its high impact and
medium impact BES Cyber Systems, shall
review and obtain CIP Senior Manager
approval at least once every 15 calendar
months for one or more documented cyber
security policies that collectively address
the following topics: 1.1 Personnel &
training (CIP‐004) 1.2 Electronic Security
Perimeters (CIP005) including interactive
Remote Access, 1.3 Physical Security of
BES Cyber Systems (CIP006), 1.4 System
security management (CIP007), 1.5
Incident reporting and response planning
(CIP008), 1.6 Recovery plans for BES
Cyber Systems (CIP009), 1.7
Configuration change management and
vulnerability assessments (CIP010), 1.8
Information protection (CIP011) and 1.9
Declaring and responding to CIP
Exceptional Circumstances.
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
70
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
PROTECT
(PR)
Awareness and Training (AT):
The organization’s personnel and
partners are provided
cybersecurity awareness
education and are adequately
trained to perform their information
security-related duties and
responsibilities consistent with
related policies, procedures, and
agreements.
PR.AT-1: All users are informed
and trained
WM-3a WM-3b
WM-3c
WM-3d
WM-3e
WM-3f
WM-3g
WM-3h
WM-3i
CIP-003-5 R2 – 2.1: Each Responsible
Entity for its assets identified in CIP‐002‐5,
Requirement R1, Part R1.3, shall
implement, in a manner that identifies,
assesses, and corrects deficiencies, one
or more documented cyber security
policies that collectively address the
following topics, and review and obtain
CIP Senior Manager approval for those
policies at least once every 15 calendar
months: (An inventory, list, or discrete
identification of low impact BES Cyber
Systems or their BES Cyber Assets is not
required). Cyber security awareness;
PROTECT
(PR)
Awareness and Training (AT):
The organization’s personnel and
partners are provided
cybersecurity awareness
education and are adequately
trained to perform their information
security-related duties and
responsibilities consistent with
related policies, procedures, and
agreements.
PR.AT-1: All users are informed
and trained
WM-3a WM-3b
WM-3c
WM-3d
WM-3e
WM-3f
WM-3g
WM-3h
WM-3i
CIP-004-5.1 R1: Each Responsible Entity
shall implement one or more documented
processes that collectively include each of
the applicable requirement parts in CIP‐
004‐5.1 Table R1 – Security Awareness
Program. (1.1) Security awareness that, at
least once each calendar quarter,
reinforces cyber security practices (which
may include associated physical security
practices) for the Responsible Entity’s
personnel who have authorized electronic
or authorized unescorted physical access
to BES Cyber Systems.
PROTECT
(PR)
Awareness and Training (AT):
The organization’s personnel and
partners are provided
cybersecurity awareness
education and are adequately
trained to perform their information
security-related duties and
responsibilities consistent with
related policies, procedures, and
agreements.
PR.AT-1: All users are informed
and trained
WM-3a WM-3b
WM-3c
WM-3d
WM-3e
WM-3f
WM-3g
WM-3h
WM-3i
CIP-004-5.1 R2: Each Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, a cyber security training
program(s) appropriate to individual roles,
functions, or responsibilities that
collectively includes each of the applicable
requirement parts in CIP‐004‐5.1 Table R2
– Cyber Security Training Program.
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
71
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
PROTECT
(PR)
Awareness and Training (AT):
The organization’s personnel and
partners are provided
cybersecurity awareness
education and are adequately
trained to perform their information
security-related duties and
responsibilities consistent with
related policies, procedures, and
agreements.
PR.AT-2: Privileged users
understand roles &
responsibilities.
WM-1a
WM-1b
WM-1c
WM-1d
WM-1e
WM-1f
WM-1g
CIP-003-5 R1 – 1.1 to 1.9: Each
Responsible Entity, for its high impact and
medium impact BES Cyber Systems, shall
review and obtain CIP Senior Manager
approval at least once every 15 calendar
months for one or more documented cyber
security policies that collectively address
the following topics: 1.1 Personnel &
training (CIP‐004) 1.2 Electronic Security
Perimeters (CIP005) including interactive
Remote Access, 1.3 Physical Security of
BES Cyber Systems (CIP006), 1.4 System
security management (CIP007), 1.5
Incident reporting and response planning
(CIP008), 1.6 Recovery plans for BES
Cyber Systems (CIP009), 1.7
Configuration change management and
vulnerability assessments (CIP010), 1.8
Information protection (CIP011) and 1.9
Declaring and responding to CIP
Exceptional Circumstances.
PROTECT
(PR)
Awareness and Training (AT):
The organization’s personnel and
partners are provided
cybersecurity awareness
education and are adequately
trained to perform their information
security-related duties and
responsibilities consistent with
related policies, procedures, and
agreements.
PR.AT-2: Privileged users
understand roles &
responsibilities.
WM-1a
WM-1b
WM-1c
WM-1d
WM-1e
WM-1f
WM-1g
CIP-003-5 R2 – 2.1: Each Responsible
Entity for its assets identified in CIP‐002‐5,
Requirement R1, Part R1.3, shall
implement, in a manner that identifies,
assesses, and corrects deficiencies, one
or more documented cyber security
policies that collectively address the
following topics, and review and obtain
CIP Senior Manager approval for those
policies at least once every 15 calendar
months: (An inventory, list, or discrete
identification of low impact BES Cyber
Systems or their BES Cyber Assets is not
required). Cyber security awareness;
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
72
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
PROTECT
(PR)
Awareness and Training (AT):
The organization’s personnel and
partners are provided
cybersecurity awareness
education and are adequately
trained to perform their information
security-related duties and
responsibilities consistent with
related policies, procedures, and
agreements.
PR.AT-2: Privileged users
understand roles &
responsibilities.
WM-1a
WM-1b
WM-1c
WM-1d
WM-1e
WM-1f
WM-1g
CIP-004-5.1 R1: Each Responsible Entity
shall implement one or more documented
processes that collectively include each of
the applicable requirement parts in CIP‐
004‐5.1 Table R1 – Security Awareness
Program. (1.1) Security awareness that, at
least once each calendar quarter,
reinforces cyber security practices (which
may include associated physical security
practices) for the Responsible Entity’s
personnel who have authorized electronic
or authorized unescorted physical access
to BES Cyber Systems.
PROTECT
(PR)
Awareness and Training (AT):
The organization’s personnel and
partners are provided
cybersecurity awareness
education and are adequately
trained to perform their information
security-related duties and
responsibilities consistent with
related policies, procedures, and
agreements.
PR.AT-2: Privileged users
understand roles &
responsibilities.
WM-1a
WM-1b
WM-1c
WM-1d
WM-1e
WM-1f
WM-1g
CIP-004-5.1 R2: Each Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, a cyber security training
program(s) appropriate to individual roles,
functions, or responsibilities that
collectively includes each of the applicable
requirement parts in CIP‐004‐5.1 Table R2
– Cyber Security Training Program.
PROTECT
(PR)
Awareness and Training (AT):
The organization’s personnel and
partners are provided
cybersecurity awareness
education and are adequately
trained to perform their information
security-related duties and
responsibilities consistent with
related policies, procedures, and
agreements.
PR.AT-3: Third-party
stakeholders (e.g., suppliers,
customers, partners)
understand roles &
responsibilities
WM-1a
WM-1b
WM-1c
WM-1d
WM-1e
WM-1f
WM-1g
CIP-003-5 R1 – 1.1 to 1.9: Each
Responsible Entity, for its high impact and
medium impact BES Cyber Systems, shall
review and obtain CIP Senior Manager
approval at least once every 15 calendar
months for one or more documented cyber
security policies that collectively address
the following topics: 1.1 Personnel &
training (CIP‐004) 1.2 Electronic Security
Perimeters (CIP005) including interactive
Remote Access, 1.3 Physical Security of
BES Cyber Systems (CIP006), 1.4 System
security management (CIP007), 1.5
Incident reporting and response planning
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
73
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
(CIP008), 1.6 Recovery plans for BES
Cyber Systems (CIP009), 1.7
Configuration change management and
vulnerability assessments (CIP010), 1.8
Information protection (CIP011) and 1.9
Declaring and responding to CIP
Exceptional Circumstances.
PROTECT
(PR)
Awareness and Training (AT):
The organization’s personnel and
partners are provided
cybersecurity awareness
education and are adequately
trained to perform their information
security-related duties and
responsibilities consistent with
related policies, procedures, and
agreements.
PR.AT-3: Third-party
stakeholders (e.g., suppliers,
customers, partners)
understand roles &
responsibilities
WM-1a
WM-1b
WM-1c
WM-1d
WM-1e
WM-1f
WM-1g
CIP-003-5 R2 – 2.1: Each Responsible
Entity for its assets identified in CIP‐002‐5,
Requirement R1, Part R1.3, shall
implement, in a manner that identifies,
assesses, and corrects deficiencies, one
or more documented cyber security
policies that collectively address the
following topics, and review and obtain
CIP Senior Manager approval for those
policies at least once every 15 calendar
months: (An inventory, list, or discrete
identification of low impact BES Cyber
Systems or their BES Cyber Assets is not
required). Cyber security awareness;
PROTECT
(PR)
Awareness and Training (AT):
The organization’s personnel and
partners are provided
cybersecurity awareness
education and are adequately
trained to perform their information
security-related duties and
responsibilities consistent with
PR.AT-3: Third-party
stakeholders (e.g., suppliers,
customers, partners)
understand roles &
responsibilities
WM-1a
WM-1b
WM-1c
WM-1d
WM-1e
WM-1f
WM-1g
CIP-004-5.1 R1: Each Responsible Entity
shall implement one or more documented
processes that collectively include each of
the applicable requirement parts in CIP‐
004‐5.1 Table R1 – Security Awareness
Program. (1.1) Security awareness that, at
least once each calendar quarter,
reinforces cyber security practices (which
may include associated physical security
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
74
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
related policies, procedures, and
agreements.
practices) for the Responsible Entity’s
personnel who have authorized electronic
or authorized unescorted physical access
to BES Cyber Systems.
PROTECT
(PR)
Awareness and Training (AT):
The organization’s personnel and
partners are provided
cybersecurity awareness
education and are adequately
trained to perform their information
security-related duties and
responsibilities consistent with
related policies, procedures, and
agreements.
PR.AT-3: Third-party
stakeholders (e.g., suppliers,
customers, partners)
understand roles &
responsibilities
WM-1a
WM-1b
WM-1c
WM-1d
WM-1e
WM-1f
WM-1g
CIP-004-5.1 R2: Each Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, a cyber security training
program(s) appropriate to individual roles,
functions, or responsibilities that
collectively includes each of the applicable
requirement parts in CIP‐004‐5.1 Table R2
– Cyber Security Training Program.
PROTECT
(PR)
Awareness and Training (AT):
The organization’s personnel and
partners are provided
cybersecurity awareness
education and are adequately
trained to perform their information
security-related duties and
responsibilities consistent with
related policies, procedures, and
agreements.
PR.AT-4: Senior executives
understand roles &
responsibilities
WM-1a
WM-1b
WM-1c
WM-1d
WM-1e
WM-1f
WM-1g
CIP-003-5 R1 – 1.1 to 1.9: Each
Responsible Entity, for its high impact and
medium impact BES Cyber Systems, shall
review and obtain CIP Senior Manager
approval at least once every 15 calendar
months for one or more documented cyber
security policies that collectively address
the following topics: 1.1 Personnel &
training (CIP‐004) 1.2 Electronic Security
Perimeters (CIP005) including interactive
Remote Access, 1.3 Physical Security of
BES Cyber Systems (CIP006), 1.4 System
security management (CIP007), 1.5
Incident reporting and response planning
(CIP008), 1.6 Recovery plans for BES
Cyber Systems (CIP009), 1.7
Configuration change management and
vulnerability assessments (CIP010), 1.8
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
75
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
Information protection (CIP011) and 1.9
Declaring and responding to CIP
Exceptional Circumstances.
PROTECT
(PR)
Awareness and Training (AT):
The organization’s personnel and
partners are provided
cybersecurity awareness
education and are adequately
trained to perform their information
security-related duties and
responsibilities consistent with
related policies, procedures, and
agreements.
PR.AT-4: Senior executives
understand roles &
responsibilities
WM-1a
WM-1b
WM-1c
WM-1d
WM-1e
WM-1f
WM-1g
CIP-003-5 R2 – 2.1: Each Responsible
Entity for its assets identified in CIP‐002‐5,
Requirement R1, Part R1.3, shall
implement, in a manner that identifies,
assesses, and corrects deficiencies, one
or more documented cyber security
policies that collectively address the
following topics, and review and obtain
CIP Senior Manager approval for those
policies at least once every 15 calendar
months: (An inventory, list, or discrete
identification of low impact BES Cyber
Systems or their BES Cyber Assets is not
required). Cyber security awareness;
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
76
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
PROTECT
(PR)
Awareness and Training (AT):
The organization’s personnel and
partners are provided
cybersecurity awareness
education and are adequately
trained to perform their information
security-related duties and
responsibilities consistent with
related policies, procedures, and
agreements.
PR.AT-4: Senior executives
understand roles &
responsibilities
WM-1a
WM-1b
WM-1c
WM-1d
WM-1e
WM-1f
WM-1g
CIP-003-5 R4: The Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, a documented process to
delegate authority, unless no delegations
are used. Where allowed by the CIP
Standards, the CIP Senior Manager may
delegate authority for specific actions to a
delegate or delegates. These delegations
shall be documented, including the name
or title of the delegate, the specific actions
delegated, and the date of the delegation;
approved by the CIP Senior Manager; and
updated within 30 days of any change to
the delegation. Delegation changes do not
need to be reinstated with a change to the
delegator.
PROTECT
(PR)
Awareness and Training (AT):
The organization’s personnel and
partners are provided
cybersecurity awareness
education and are adequately
trained to perform their information
security-related duties and
responsibilities consistent with
related policies, procedures, and
agreements.
PR.AT-4: Senior executives
understand roles &
responsibilities
WM-1a
WM-1b
WM-1c
WM-1d
WM-1e
WM-1f
WM-1g
CIP-004-5.1 R1: Each Responsible Entity
shall implement one or more documented
processes that collectively include each of
the applicable requirement parts in CIP‐
004‐5.1 Table R1 – Security Awareness
Program. (1.1) Security awareness that, at
least once each calendar quarter,
reinforces cyber security practices (which
may include associated physical security
practices) for the Responsible Entity’s
personnel who have authorized electronic
or authorized unescorted physical access
to BES Cyber Systems.
PROTECT
(PR)
Awareness and Training (AT):
The organization’s personnel and
partners are provided
cybersecurity awareness
education and are adequately
trained to perform their information
security-related duties and
PR.AT-4: Senior executives
understand roles &
responsibilities
WM-1a
WM-1b
WM-1c
WM-1d
WM-1e
WM-1f
WM-1g
CIP-004-5.1 R2: Each Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, a cyber security training
program(s) appropriate to individual roles,
functions, or responsibilities that
collectively includes each of the applicable
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
77
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
responsibilities consistent with
related policies, procedures, and
agreements.
requirement parts in CIP‐004‐5.1 Table R2
– Cyber Security Training Program.
PROTECT
(PR)
Awareness and Training (AT):
The organization’s personnel and
partners are provided
cybersecurity awareness
education and are adequately
trained to perform their information
security-related duties and
responsibilities consistent with
related policies, procedures, and
agreements.
PR.AT-5: Physical and
information security personnel
understand roles &
responsibilities
WM-1a
WM-1b
WM-1c
WM-1d
WM-1e
WM-1f
WM-1g
CIP-003-5 R1 – 1.1 to 1.9: Each
Responsible Entity, for its high impact and
medium impact BES Cyber Systems, shall
review and obtain CIP Senior Manager
approval at least once every 15 calendar
months for one or more documented cyber
security policies that collectively address
the following topics: 1.1 Personnel &
training (CIP‐004) 1.2 Electronic Security
Perimeters (CIP005) including interactive
Remote Access, 1.3 Physical Security of
BES Cyber Systems (CIP006), 1.4 System
security management (CIP007), 1.5
Incident reporting and response planning
(CIP008), 1.6 Recovery plans for BES
Cyber Systems (CIP009), 1.7
Configuration change management and
vulnerability assessments (CIP010), 1.8
Information protection (CIP011) and 1.9
Declaring and responding to CIP
Exceptional Circumstances.
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
78
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
PROTECT
(PR)
Awareness and Training (AT):
The organization’s personnel and
partners are provided
cybersecurity awareness
education and are adequately
trained to perform their information
security-related duties and
responsibilities consistent with
related policies, procedures, and
agreements.
PR.AT-5: Physical and
information security personnel
understand roles &
responsibilities
WM-1a
WM-1b
WM-1c
WM-1d
WM-1e
WM-1f
WM-1g
CIP-003-5 R2 – 2.1: Each Responsible
Entity for its assets identified in CIP‐002‐5,
Requirement R1, Part R1.3, shall
implement, in a manner that identifies,
assesses, and corrects deficiencies, one
or more documented cyber security
policies that collectively address the
following topics, and review and obtain
CIP Senior Manager approval for those
policies at least once every 15 calendar
months: (An inventory, list, or discrete
identification of low impact BES Cyber
Systems or their BES Cyber Assets is not
required). Cyber security awareness;
PROTECT
(PR)
Awareness and Training (AT):
The organization’s personnel and
partners are provided
cybersecurity awareness
education and are adequately
trained to perform their information
security-related duties and
responsibilities consistent with
related policies, procedures, and
agreements.
PR.AT-5: Physical and
information security personnel
understand roles &
responsibilities
WM-1a
WM-1b
WM-1c
WM-1d
WM-1e
WM-1f
WM-1g
CIP-004-5.1 R1: Each Responsible Entity
shall implement one or more documented
processes that collectively include each of
the applicable requirement parts in CIP‐
004‐5.1 Table R1 – Security Awareness
Program. (1.1) Security awareness that, at
least once each calendar quarter,
reinforces cyber security practices (which
may include associated physical security
practices) for the Responsible Entity’s
personnel who have authorized electronic
or authorized unescorted physical access
to BES Cyber Systems.
PROTECT
(PR)
Awareness and Training (AT):
The organization’s personnel and
partners are provided
cybersecurity awareness
education and are adequately
trained to perform their information
security-related duties and
responsibilities consistent with
related policies, procedures, and
agreements.
PR.AT-5: Physical and
information security personnel
understand roles &
responsibilities
WM-1a
WM-1b
WM-1c
WM-1d
WM-1e
WM-1f
WM-1g
CIP-004-5.1 R2: Each Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, a cyber security training
program(s) appropriate to individual roles,
functions, or responsibilities that
collectively includes each of the applicable
requirement parts in CIP‐004‐5.1 Table R2
– Cyber Security Training Program.
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
79
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
PROTECT
(PR)
Awareness and Training (AT):
The organization’s personnel and
partners are provided
cybersecurity awareness
education and are adequately
trained to perform their information
security-related duties and
responsibilities consistent with
related policies, procedures, and
agreements.
PR.AT-5: Physical and
information security personnel
understand roles &
responsibilities
WM-1a
WM-1b
WM-1c
WM-1d
WM-1e
WM-1f
WM-1g
CIP-006-5 R2: Each Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, one or more documented
visitor control programs that include each
of the applicable requirement parts in CIP-
005-5 Table R2 – Visitor Control Program)
PROTECT
(PR)
Data Security (DS): Information
and records (data) are managed
consistent with the organization’s
risk strategy to protect the
confidentiality, integrity, and
availability of information.
PR.DS-1: Data-at-rest is
protected
ACM-
1b
TVM-
1c
TVM-
2c
CPM-
3b
ACM-
1e
TVM-
2i
TVM-
2n
CIP-003-5 R1 – 1.8: Each Responsible
Entity, for its high impact and medium
impact BES Cyber Systems, shall review
and obtain CIP Senior Manager approval
at least once every 15 calendar months for
one or more documented cyber security
policies that collectively address the
following topics: Information protection
(CIP‐011);
PROTECT
(PR)
Data Security (DS): Information
and records (data) are managed
consistent with the organization’s
risk strategy to protect the
confidentiality, integrity, and
availability of information.
PR.DS-1: Data-at-rest is
protected
ACM-
1b
TVM-
1c
TVM-
2c
CPM-
3b
ACM-
1e
TVM-
2i
TVM-
2n
CIP-004-5.1 R4: Each Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, one or more documented
access management programs that
collectively include each of the applicable
requirement parts in CIP‐004‐5.1 Table R4
– Access Management Program.
PROTECT
(PR)
Data Security (DS): Information
and records (data) are managed
consistent with the organization’s
risk strategy to protect the
confidentiality, integrity, and
availability of information.
PR.DS-1: Data-at-rest is
protected
ACM-
1b
TVM-
1c
TVM-
2c
CPM-
3b
ACM-
1e
TVM-
2i
TVM-
2n
CIP-004-5.1 R5: Each Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, one or more documented
access revocation programs that
collectively include each of the applicable
requirement parts in CIP‐004‐5.1 Table R5
– Access Revocation.
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
80
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
PROTECT
(PR)
Data Security (DS): Information
and records (data) are managed
consistent with the organization’s
risk strategy to protect the
confidentiality, integrity, and
availability of information.
PR.DS-1: Data-at-rest is
protected
ACM-
1b
TVM-
1c
TVM-
2c
CPM-
3b
ACM-
1e
TVM-
2i
TVM-
2n
CIP-007-5 R3: Each Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, one or more documented
processes that collectively include each of
the applicable requirement parts in CIP-
007-5 Table R3 – Malicious Code
Prevention.
PROTECT
(PR)
Data Security (DS): Information
and records (data) are managed
consistent with the organization’s
risk strategy to protect the
confidentiality, integrity, and
availability of information.
PR.DS-1: Data-at-rest is
protected
ACM-
1b
TVM-
1c
TVM-
2c
CPM-
3b
ACM-
1e
TVM-
2i
TVM-
2n
CIP-011-1 R1: Each Responsible Entity
shall implement, in a Manner that
identifies, assesses, and corrects
deficiencies, one or more documented
information protection program(s) that
collectively includes each of the applicable
requirement parts in CIP‐011‐1 Table R1 –
Information Protection.
PROTECT
(PR)
Data Security (DS): Information
and records (data) are managed
consistent with the organization’s
risk strategy to protect the
confidentiality, integrity, and
availability of information.
PR.DS-1: Data-at-rest is
protected
ACM-
1b
TVM-
1c
TVM-
2c
CPM-
3b
ACM-
1e
TVM-
2i
TVM-
2n
CIP-011-1 R2: Each Responsible Entity
shall implement one or more documented
processes that collectively include the
applicable requirement parts in CIP‐011‐1
Table R2 – BES Cyber Asset Reuse and
Disposal.
PROTECT
(PR)
Data Security (DS): Information
and records (data) are managed
consistent with the organization’s
risk strategy to protect the
confidentiality, integrity, and
availability of information.
PR.DS-2: Data-in-transit is
protected
ACM-
1b
TVM-
1c
TVM-
2c
CPM-
3b
ACM-
1e
TVM-
2i
TVM-
2n
CIP-003-5 R1 – 1.2: Each Responsible
Entity, for its high impact and medium
impact BES Cyber Systems, shall review
and obtain CIP Senior Manager approval
at least once every 15 calendar months for
one or more documented cyber security
policies that collectively address the
following topics: Electronic Security
Perimeters (CIP‐005) including Interactive
Remote Access;
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
81
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
PROTECT
(PR)
Data Security (DS): Information
and records (data) are managed
consistent with the organization’s
risk strategy to protect the
confidentiality, integrity, and
availability of information.
PR.DS-2: Data-in-transit is
protected
ACM-
1b
TVM-
1c
TVM-
2c
CPM-
3b
ACM-
1e
TVM-
2i
TVM-
2n
CIP-003-5 R1 – 1.8: Each Responsible
Entity, for its high impact and medium
impact BES Cyber Systems, shall review
and obtain CIP Senior Manager approval
at least once every 15 calendar months for
one or more documented cyber security
policies that collectively address the
following topics: Information protection
(CIP‐011);
PROTECT
(PR)
Data Security (DS): Information
and records (data) are managed
consistent with the organization’s
risk strategy to protect the
confidentiality, integrity, and
availability of information.
PR.DS-2: Data-in-transit is
protected
ACM-
1b
TVM-
1c
TVM-
2c
CPM-
3b
ACM-
1e
TVM-
2i
TVM-
2n
CIP-003-5 R2 – 2.3: Each Responsible
Entity for its assets identified in CIP-002-5,
Requirement R1, Part R1.3 (i.e., low
impact), shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, one or more documented
cyber security policies that collectively
address the following topics, and review
and obtain CIP Senior Manager approval
for those policies at least once every 15
calendar months: Electronic access
controls for external routable protocol
connections and Dial-up Connectivity
PROTECT
(PR)
Data Security (DS): Information
and records (data) are managed
consistent with the organization’s
risk strategy to protect the
confidentiality, integrity, and
availability of information.
PR.DS-2: Data-in-transit is
protected
ACM-
1b
TVM-
1c
TVM-
2c
CPM-
3b
ACM-
1e
TVM-
2i
TVM-
2n
CIP-004-5.1 R4: Each Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, one or more documented
access management programs that
collectively include each of the applicable
requirement parts in CIP‐004‐5.1 Table R4
– Access Management Program.
PROTECT
(PR)
Data Security (DS): Information
and records (data) are managed
consistent with the organization’s
risk strategy to protect the
confidentiality, integrity, and
availability of information.
PR.DS-2: Data-in-transit is
protected
ACM-
1b
TVM-
1c
TVM-
2c
CPM-
3b
ACM-
1e
TVM-
2i
TVM-
2n
CIP-004-5.1 R5: Each Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, one or more documented
access revocation programs that
collectively include each of the applicable
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
82
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
requirement parts in CIP‐004‐5.1 Table R5
– Access Revocation.
PROTECT
(PR)
Data Security (DS): Information
and records (data) are managed
consistent with the organization’s
risk strategy to protect the
confidentiality, integrity, and
availability of information.
PR.DS-2: Data-in-transit is
protected
ACM-
1b
TVM-
1c
TVM-
2c
CPM-
3b
ACM-
1e
TVM-
2i
TVM-
2n
CIP-005-5 R1: Each Responsible Entity
shall implement one or more documented
processes that collectively include each of
the applicable requirement parts in CIP-
005-5 Table R1 – Electronic Security
Perimeter.
PROTECT
(PR)
Data Security (DS): Information
and records (data) are managed
consistent with the organization’s
risk strategy to protect the
confidentiality, integrity, and
availability of information.
PR.DS-2: Data-in-transit is
protected
ACM-
1b
TVM-
1c
TVM-
2c
CPM-
3b
ACM-
1e
TVM-
2i
TVM-
2n
CIP-005-5 R2: Each Responsible Entity
allowing Interactive Remote Access to
BES Cyber Systems shall implement one
or more documented processes that
collectively include the applicable
requirement parts, where technically
feasible, in CIP-005-5 Table R2 –
Interactive Remote Access Management.
PROTECT
(PR)
Data Security (DS): Information
and records (data) are managed
consistent with the organization’s
risk strategy to protect the
confidentiality, integrity, and
availability of information.
PR.DS-2: Data-in-transit is
protected
ACM-
1b
TVM-
1c
TVM-
2c
CPM-
3b
ACM-
1e
TVM-
2i
TVM-
2n
CIP-007-5 R3: Each Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, one or more documented
processes that collectively include each of
the applicable requirement parts in CIP-
007-5 Table R3 – Malicious Code
Prevention.
PROTECT
(PR)
Data Security (DS): Information
and records (data) are managed
consistent with the organization’s
risk strategy to protect the
confidentiality, integrity, and
availability of information.
PR.DS-2: Data-in-transit is
protected
ACM-
1b
TVM-
1c
TVM-
2c
CPM-
3b
ACM-
1e
TVM-
2i
TVM-
2n
CIP-011-1 R1: Each Responsible Entity
shall implement, in a Manner that
identifies, assesses, and corrects
deficiencies, one or more documented
information protection program(s) that
collectively includes each of the applicable
requirement parts in CIP‐011‐1 Table R1 –
Information Protection.
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
83
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
PROTECT
(PR)
Data Security (DS): Information
and records (data) are managed
consistent with the organization’s
risk strategy to protect the
confidentiality, integrity, and
availability of information.
PR.DS-3: Assets are formally
managed throughout removal,
transfers, and disposition
ACM-
1a
ACM-
1b
ACM-
2a
ACM-
2b
ACM-
3a
ACM-
3b
ACM-
1c
ACM-
1d
ACM-
2c
ACM-
3c
ACM-
3d
ACM-
4a
ACM-
4b
ACM-
4c
ACM-
4d
ACM-
1e
ACM-
1f
ACM-
2d
ACM-
2e
ACM-
3e
ACM-
3f
ACM-
4e
ACM-
4f
ACM-
4g
ACM-
4h
ACM-
4i
CIP-011-1 R2: Each Responsible Entity
shall implement one or more documented
processes that collectively include the
applicable requirement parts in CIP‐011‐1
Table R2 – BES Cyber Asset Reuse and
Disposal.
PROTECT
(PR)
Data Security (DS): Information
and records (data) are managed
consistent with the organization’s
risk strategy to protect the
confidentiality, integrity, and
availability of information.
PR.DS-4: Adequate capacity to
ensure availability is maintained
TVM-
1c
TVM-
2c
CPM-
3b
TVM-
2i
TVM-
2n
CIP-003-5 R1 – 1.6: Each Responsible
Entity, for its high impact and medium
impact BES Cyber Systems, shall review
and obtain CIP Senior Manager approval
at least once every 15 calendar months for
one or more documented cyber security
policies that collectively address the
following topics: Recovery plans for BES
Cyber Systems (CIP‐009);
PROTECT
(PR)
Data Security (DS): Information
and records (data) are managed
consistent with the organization’s
risk strategy to protect the
confidentiality, integrity, and
availability of information.
PR.DS-4: Adequate capacity to
ensure availability is maintained
TVM-
1c
TVM-
2c
CPM-
3b
TVM-
2i
TVM-
2n
CIP-007-5 R4 – 4.3: Where technically
feasible, retain applicable event logs
identified in Part 4.1 for at least the last
90
consecutive calendar days except under
CIP Exceptional Circumstances.
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
84
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
PROTECT
(PR)
Data Security (DS): Information
and records (data) are managed
consistent with the organization’s
risk strategy to protect the
confidentiality, integrity, and
availability of information.
PR.DS-4: Adequate capacity to
ensure availability is maintained
TVM-
1c
TVM-
2c
CPM-
3b
TVM-
2i
TVM-
2n
CIP-009-5 R1: Each Responsible Entity
shall have one or more documented
recovery plans that collectively include
each of the applicable requirement parts in
CIP‐009‐5 Table R1 – Recovery Plan
Specifications.
PROTECT
(PR)
Data Security (DS): Information
and records (data) are managed
consistent with the organization’s
risk strategy to protect the
confidentiality, integrity, and
availability of information.
PR.DS-4: Adequate capacity to
ensure availability is maintained
TVM-
1c
TVM-
2c
CPM-
3b
TVM-
2i
TVM-
2n
CIP-007-5 R3: Each Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, one or more documented
processes that collectively include each of
the applicable requirement parts in CIP‐
007‐5 Table R3 – Malicious
Code Prevention.
PROTECT
(PR)
Data Security (DS): Information
and records (data) are managed
consistent with the organization’s
risk strategy to protect the
confidentiality, integrity, and
availability of information.
PR.DS-5: Protections against
data leaks are implemented
TVM-
1c
TVM-
2c
CPM-
3b
TVM-
2i
TVM-
2n
CIP-003-5 R1 – 1.2: Each Responsible
Entity, for its high impact and medium
impact BES Cyber Systems, shall review
and obtain CIP Senior Manager approval
at least once every 15 calendar months for
one or more documented cyber security
policies that collectively address the
following topics: Electronic Security
Perimeters (CIP‐005) including Interactive
Remote Access;
PROTECT
(PR)
Data Security (DS): Information
and records (data) are managed
consistent with the organization’s
risk strategy to protect the
confidentiality, integrity, and
availability of information.
PR.DS-5: Protections against
data leaks are implemented
TVM-
1c
TVM-
2c
CPM-
3b
TVM-
2i
TVM-
2n
CIP-003-5 R1 – 1.4: Each Responsible
Entity, for its high impact and medium
impact BES Cyber Systems, shall review
and obtain CIP Senior Manager approval
at least once every 15 calendar months for
one or more documented cyber security
policies that collectively address the
following topics: System security
management (CIP‐007);
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
85
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
PROTECT
(PR)
Data Security (DS): Information
and records (data) are managed
consistent with the organization’s
risk strategy to protect the
confidentiality, integrity, and
availability of information.
PR.DS-5: Protections against
data leaks are implemented
TVM-
1c
TVM-
2c
CPM-
3b
TVM-
2i
TVM-
2n
CIP-003-5 R1 – 1.8: Each Responsible
Entity, for its high impact and medium
impact BES Cyber Systems, shall review
and obtain CIP Senior Manager approval
at least once every 15 calendar months for
one or more documented cyber security
policies that collectively address the
following topics: Information protection
(CIP‐011);
PROTECT
(PR)
Data Security (DS): Information
and records (data) are managed
consistent with the organization’s
risk strategy to protect the
confidentiality, integrity, and
availability of information.
PR.DS-5: Protections against
data leaks are implemented
TVM-
1c
TVM-
2c
CPM-
3b
TVM-
2i
TVM-
2n
CIP-003-5 R2 – 2.3: Each Responsible
Entity for its assets identified in CIP-002-5,
Requirement R1, Part R1.3 (ie: low
impact), shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, one or more documented
cyber security policies that collectively
address the following topics, and review
and obtain CIP Senior Manager approval
for those policies at least once every 15
calendar months: Electronic access
controls for external routable protocol
connections and Dial-up Connectivity
PROTECT
(PR)
Data Security (DS): Information
and records (data) are managed
consistent with the organization’s
risk strategy to protect the
confidentiality, integrity, and
availability of information.
PR.DS-5: Protections against
data leaks are implemented
TVM-
1c
TVM-
2c
CPM-
3b
TVM-
2i
TVM-
2n
CIP-004-5.1 R4: Each Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, one or more documented
access management programs that
collectively include each of the applicable
requirement parts in CIP‐004‐5.1 Table R4
– Access Management Program.
PROTECT
(PR)
Data Security (DS): Information
and records (data) are managed
consistent with the organization’s
risk strategy to protect the
confidentiality, integrity, and
availability of information.
PR.DS-5: Protections against
data leaks are implemented
TVM-
1c
TVM-
2c
CPM-
3b
TVM-
2i
TVM-
2n
CIP-004-5.1 R5: Each Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, one or more documented
access revocation programs that
collectively include each of the applicable
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
86
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
requirement parts in CIP‐004‐5.1 Table R5
– Access Revocation.
PROTECT
(PR)
Data Security (DS): Information
and records (data) are managed
consistent with the organization’s
risk strategy to protect the
confidentiality, integrity, and
availability of information.
PR.DS-5: Protections against
data leaks are implemented
TVM-
1c
TVM-
2c
CPM-
3b
TVM-
2i
TVM-
2n
CIP-005-5 R1: Each Responsible Entity
shall implement one or more documented
processes that collectively include each of
the applicable requirement parts in CIP-
005-5 Table R1 – Electronic Security
Perimeter.
PROTECT
(PR)
Data Security (DS): Information
and records (data) are managed
consistent with the organization’s
risk strategy to protect the
confidentiality, integrity, and
availability of information.
PR.DS-5: Protections against
data leaks are implemented
TVM-
1c
TVM-
2c
CPM-
3b
TVM-
2i
TVM-
2n
CIP-005-5 R2: Each Responsible Entity
allowing Interactive Remote Access to
BES Cyber Systems shall implement one
or more documented processes that
collectively include the applicable
requirement parts, where technically
feasible, in CIP-005-5 Table R2 –
Interactive Remote Access Management.
PROTECT
(PR)
Data Security (DS): Information
and records (data) are managed
consistent with the organization’s
risk strategy to protect the
confidentiality, integrity, and
availability of information.
PR.DS-5: Protections against
data leaks are implemented
TVM-
1c
TVM-
2c
CPM-
3b
TVM-
2i
TVM-
2n
CIP-007-5 R3: Each Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, one or more documented
processes that collectively include each of
the applicable requirement parts in CIP-
007-5 Table R3 – Malicious Code
Prevention.
PROTECT
(PR)
Data Security (DS): Information
and records (data) are managed
consistent with the organization’s
risk strategy to protect the
confidentiality, integrity, and
availability of information.
PR.DS-5: Protections against
data leaks are implemented
TVM-
1c
TVM-
2c
CPM-
3b
TVM-
2i
TVM-
2n
CIP-007-5 R4: Each Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, one or more documented
processes that collectively include each of
the applicable requirement parts in CIP‐
007‐5 Table R4 – Security
Event Monitoring.
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
87
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
PROTECT
(PR)
Data Security (DS): Information
and records (data) are managed
consistent with the organization’s
risk strategy to protect the
confidentiality, integrity, and
availability of information.
PR.DS-5: Protections against
data leaks are implemented
TVM-
1c
TVM-
2c
CPM-
3b
TVM-
2i
TVM-
2n
CIP-007-5 R5: Each Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, one or more documented
processes that collectively include each of
the applicable requirement parts in CIP-
007-5 Table R5 – System Access
Controls.
PROTECT
(PR)
Data Security (DS): Information
and records (data) are managed
consistent with the organization’s
risk strategy to protect the
confidentiality, integrity, and
availability of information.
PR.DS-5: Protections against
data leaks are implemented
TVM-
1c
TVM-
2c
CPM-
3b
TVM-
2i
TVM-
2n
CIP-011-1 R1: Each Responsible Entity
shall implement, in a Manner that
identifies, assesses, and corrects
deficiencies, one or more documented
information protection program(s) that
collectively includes each of the applicable
requirement parts in CIP‐011‐1 Table R1 –
Information Protection.
PROTECT
(PR)
Data Security (DS): Information
and records (data) are managed
consistent with the organization’s
risk strategy to protect the
confidentiality, integrity, and
availability of information.
PR.DS-5: Protections against
data leaks are implemented
TVM-
1c
TVM-
2c
CPM-
3b
TVM-
2i
TVM-
2n
CIP-011-1 R2: Each Responsible Entity
shall implement one or more documented
processes that collectively include the
applicable requirement parts in CIP‐011‐1
Table R2 – BES Cyber Asset Reuse and
Disposal.
PROTECT
(PR)
Data Security (DS): Information
and records (data) are managed
consistent with the organization’s
risk strategy to protect the
confidentiality, integrity, and
availability of information.
PR.DS-6: Integrity checking
mechanisms are used to verify
software, firmware, and
information integrity
ACM-
3d
CIP-003-5 R1 – 1.7: Each Responsible
Entity, for its high impact and medium
impact BES Cyber Systems, shall review
and obtain CIP Senior Manager approval
at least once every 15 calendar months for
one or more documented cyber security
policies that collectively address the
following topics: Configuration change
management and vulnerability
assessments (CIP‐010);
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
88
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
PROTECT
(PR)
Data Security (DS): Information
and records (data) are managed
consistent with the organization’s
risk strategy to protect the
confidentiality, integrity, and
availability of information.
PR.DS-6: Integrity checking
mechanisms are used to verify
software, firmware, and
information integrity
ACM-
3d
CIP-010-1 R1: Each Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, one or more documented
processes that collectively include each of
the applicable requirement parts in CIP‐
010‐1 Table R1 – Configuration Change
Management.
PROTECT
(PR)
Data Security (DS): Information
and records (data) are managed
consistent with the organization’s
risk strategy to protect the
confidentiality, integrity, and
availability of information.
PR.DS-6: Integrity checking
mechanisms are used to verify
software, firmware, and
information integrity
ACM-
3d
CIP-010-1 R2: Each Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, one or more documented
processes that collectively include each of
the applicable requirement parts in CIP‐
010‐1 Table R2 – Configuration
Monitoring.
PROTECT
(PR)
Data Security (DS): Information
and records (data) are managed
consistent with the organization’s
risk strategy to protect the
confidentiality, integrity, and
availability of information.
PR.DS-7: The development and
testing environment(s) are
separate from the production
environment
ACM-
3c
ACM-
3e
CIP-003-5 R1 – 1.2: Each Responsible
Entity, for its high impact and medium
impact BES Cyber Systems, shall review
and obtain CIP Senior Manager approval
at least once every 15 calendar months for
one or more documented cyber security
policies that collectively address the
following topics: Electronic Security
Perimeters (CIP‐005) including Interactive
Remote Access;
PROTECT
(PR)
Data Security (DS): Information
and records (data) are managed
consistent with the organization’s
risk strategy to protect the
confidentiality, integrity, and
availability of information.
PR.DS-7: The development and
testing environment(s) are
separate from the production
environment
ACM-
3c
ACM-
3e
CIP-003-5 R1 – 1.7: Each Responsible
Entity, for its high impact and medium
impact BES Cyber Systems, shall review
and obtain CIP Senior Manager approval
at least once every 15 calendar months for
one or more documented cyber security
policies that collectively address the
following topics: Configuration change
management and vulnerability
assessments (CIP‐010);
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
89
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
PROTECT
(PR)
Data Security (DS): Information
and records (data) are managed
consistent with the organization’s
risk strategy to protect the
confidentiality, integrity, and
availability of information.
PR.DS-7: The development and
testing environment(s) are
separate from the production
environment
ACM-
3c
ACM-
3e
CIP-005-5 R1: Each Responsible Entity
shall implement one or more documented
processes that collectively include each of
the applicable requirement parts in CIP-
005-5 Table R1 – Electronic Security
Perimeter.
PROTECT
(PR)
Data Security (DS): Information
and records (data) are managed
consistent with the organization’s
risk strategy to protect the
confidentiality, integrity, and
availability of information.
PR.DS-7: The development and
testing environment(s) are
separate from the production
environment
ACM-
3c
ACM-
3e
CIP-010-1 R2: Each Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, one or more documented
processes that collectively include each of
the applicable requirement parts in CIP‐
010‐1 Table R2 – Configuration
Monitoring.
PROTECT
(PR)
Information Protection
Processes and Procedures (IP):
Security policies (that address
purpose, scope, roles,
responsibilities, management
commitment, and coordination
among organizational entities),
processes, and procedures are
maintained and used to manage
protection of information systems
and assets.
PR.IP-1: A baseline
configuration of information
technology/industrial control
systems is created and
maintained
ACM-
2a
ACM-
2b
ACM-
2c
ACM-
2d
ACM-
2e
CIP-010-1 R1: Each Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, one or more documented
processes that collectively include each of
the applicable requirement parts in CIP‐
010‐1 Table R1 – Configuration Change
Management.
PROTECT
(PR)
Information Protection
Processes and Procedures (IP):
Security policies (that address
purpose, scope, roles,
responsibilities, management
commitment, and coordination
among organizational entities),
processes, and procedures are
maintained and used to manage
protection of information systems
and assets.
PR.IP-1: A baseline
configuration of information
technology/industrial control
systems is created and
maintained
ACM-
2a
ACM-
2b
ACM-
2c
ACM-
2d
ACM-
2e
CIP-010-1 R2: Each Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, one or more documented
processes that collectively include each of
the applicable requirement parts in CIP‐
010‐1 Table R2 – Configuration
Monitoring.
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
90
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
PROTECT
(PR)
Information Protection
Processes and Procedures (IP):
Security policies (that address
purpose, scope, roles,
responsibilities, management
commitment, and coordination
among organizational entities),
processes, and procedures are
maintained and used to manage
protection of information systems
and assets.
PR.IP-2: A System
Development Life Cycle to
manage systems is
implemented
ACM-
3d
PROTECT
(PR)
Information Protection
Processes and Procedures (IP):
Security policies (that address
purpose, scope, roles,
responsibilities, management
commitment, and coordination
among organizational entities),
processes, and procedures are
maintained and used to manage
protection of information systems
and assets.
PR.IP-3: Configuration change
control processes are in place
ACM-
3a
ACM-
3b
ACM-
3c
ACM-
3d
ACM-
3e
ACM-
3f
CIP-003-5 R1 – 1.4: Each Responsible
Entity, for its high impact and medium
impact BES Cyber Systems, shall review
and obtain CIP Senior Manager approval
at least once every 15 calendar months for
one or more documented cyber security
policies that collectively address the
following topics: System security
management (CIP‐007);
PROTECT
(PR)
Information Protection
Processes and Procedures (IP):
Security policies (that address
purpose, scope, roles,
responsibilities, management
commitment, and coordination
among organizational entities),
processes, and procedures are
maintained and used to manage
protection of information systems
and assets.
PR.IP-3: Configuration change
control processes are in place
ACM-
3a
ACM-
3b
ACM-
3c
ACM-
3d
ACM-
3e
ACM-
3f
CIP-003-5 R1 – 1.7: Each Responsible
Entity, for its high impact and medium
impact BES Cyber Systems, shall review
and obtain CIP Senior Manager approval
at least once every 15 calendar months for
one or more documented cyber security
policies that collectively address the
following topics: Configuration change
management and vulnerability
assessments (CIP‐010);
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
91
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
PROTECT
(PR)
Information Protection
Processes and Procedures (IP):
Security policies (that address
purpose, scope, roles,
responsibilities, management
commitment, and coordination
among organizational entities),
processes, and procedures are
maintained and used to manage
protection of information systems
and assets.
PR.IP-3: Configuration change
control processes are in place
ACM-
3a
ACM-
3b
ACM-
3c
ACM-
3d
ACM-
3e
ACM-
3f
CIP-010-1 R1: Each Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, one or more documented
processes that collectively include each of
the applicable requirement parts in CIP‐
010‐1 Table R1 – Configuration Change
Management.
PROTECT
(PR)
Information Protection
Processes and Procedures (IP):
Security policies (that address
purpose, scope, roles,
responsibilities, management
commitment, and coordination
among organizational entities),
processes, and procedures are
maintained and used to manage
protection of information systems
and assets.
PR.IP-3: Configuration change
control processes are in place
ACM-
3a
ACM-
3b
ACM-
3c
ACM-
3d
ACM-
3e
ACM-
3f
CIP-010-1 R2: Each Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, one or more documented
processes that collectively include each of
the applicable requirement parts in CIP‐
010‐1 Table R2 – Configuration
Monitoring.
PROTECT
(PR)
Information Protection
Processes and Procedures (IP):
Security policies (that address
purpose, scope, roles,
responsibilities, management
commitment, and coordination
among organizational entities),
processes, and procedures are
maintained and used to manage
protection of information systems
and assets.
PR.IP-4: Backups of
information are conducted,
maintained, and tested
periodically
IR-4a
IR-4b
IR-4c
IR-4f IR-4g
IR-4j
CIP-009-5 R1: Each Responsible Entity
shall have one or more documented
recovery plans that collectively include
each of the applicable requirement parts in
CIP-009-5 Table R1 – Recovery Plan
Specifications.
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
92
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
PROTECT
(PR)
Information Protection
Processes and Procedures (IP):
Security policies (that address
purpose, scope, roles,
responsibilities, management
commitment, and coordination
among organizational entities),
processes, and procedures are
maintained and used to manage
protection of information systems
and assets.
PR.IP-4: Backups of
information are conducted,
maintained, and tested
periodically
IR-4a
IR-4b
IR-4c
IR-4f IR-4g
IR-4j
CIP-009-5 R3: Each Responsible Entity
shall maintain each of its recovery plans in
accordance with each of the applicable
requirement parts in CIP‐009‐5 Table R3 –
Recovery Plan Review, Update and
Communication.
PROTECT
(PR)
Information Protection
Processes and Procedures (IP):
Security policies (that address
purpose, scope, roles,
responsibilities, management
commitment, and coordination
among organizational entities),
processes, and procedures are
maintained and used to manage
protection of information systems
and assets.
PR.IP-5: Policy and regulations
regarding the physical operating
environment for organizational
assets are met
RM-2b
IAM-
2a
RM-3f
IAM-3f
CIP-003-5 R1 – 1.1 to 1.9: Each
Responsible Entity, for its high impact and
medium impact BES Cyber Systems, shall
review and obtain CIP Senior Manager
approval at least once every 15 calendar
months for one or more documented cyber
security policies that collectively address
the following topics: 1.1 Personnel &
training (CIP‐004) 1.2 Electronic Security
Perimeters (CIP005) including interactive
Remote Access, 1.3 Physical Security of
BES Cyber Systems (CIP006), 1.4 System
security management (CIP007), 1.5
Incident reporting and response planning
(CIP008), 1.6 Recovery plans for BES
Cyber Systems (CIP009), 1.7
Configuration change management and
vulnerability assessments (CIP010), 1.8
Information protection (CIP011) and 1.9
Declaring and responding to CIP
Exceptional Circumstances.
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
93
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
PROTECT
(PR)
Information Protection
Processes and Procedures (IP):
Security policies (that address
purpose, scope, roles,
responsibilities, management
commitment, and coordination
among organizational entities),
processes, and procedures are
maintained and used to manage
protection of information systems
and assets.
PR.IP-6: Data is destroyed
according to policy
ACM-
3d
CIP-011-1 R2: Each Responsible Entity
shall implement one or more documented
processes that collectively include the
applicable requirement parts in CIP‐011‐1
Table R2 – BES Cyber Asset Reuse and
Disposal.
PROTECT
(PR)
Information Protection
Processes and Procedures (IP):
Security policies (that address
purpose, scope, roles,
responsibilities, management
commitment, and coordination
among organizational entities),
processes, and procedures are
maintained and used to manage
protection of information systems
and assets.
PR.IP-7: Protection processes
are continuously improved
TVM-
1h
CPM-
1g
CIP-010-1 R3: Each Responsible Entity
shall implement one or more documented
processes that collectively include each of
the applicable requirement parts in CIP‐
010‐1 Table R3– Vulnerability
Assessments.
PROTECT
(PR)
Information Protection
Processes and Procedures (IP):
Security policies (that address
purpose, scope, roles,
responsibilities, management
commitment, and coordination
among organizational entities),
processes, and procedures are
maintained and used to manage
protection of information systems
and assets.
PR.IP-8: Effectiveness of
protection technologies is
shared with appropriate parties
ISC-1a
ISC-1b
ISC-1c
ISC-1d
ISC-1e
ISC-1f
ISC-1g
ISC-2b
ISC-1h
ISC-1i
ISC-1j
ISC-1k
ISC-1l
CIP-008-5 R3: Each Responsible Entity
shall maintain each of its Cyber Security
Incident response plans according to each
of the applicable requirement parts in CIP‐
008‐5 Table R3 – Cyber Security Incident
Response Plan Review, Update, and
Communication.
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
94
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
PROTECT
(PR)
Information Protection
Processes and Procedures (IP):
Security policies (that address
purpose, scope, roles,
responsibilities, management
commitment, and coordination
among organizational entities),
processes, and procedures are
maintained and used to manage
protection of information systems
and assets.
PR.IP-8: Effectiveness of
protection technologies is
shared with appropriate parties
ISC-1a
ISC-1b
ISC-1c
ISC-1d
ISC-1e
ISC-1f
ISC-1g
ISC-2b
ISC-1h
ISC-1i
ISC-1j
ISC-1k
ISC-1l
CIP-010-1 R3: Each Responsible Entity
shall implement one or more documented
processes that collectively include each of
the applicable requirement parts in CIP‐
010‐1 Table R3– Vulnerability
Assessments.
PROTECT
(PR)
Information Protection
Processes and Procedures (IP):
Security policies (that address
purpose, scope, roles,
responsibilities, management
commitment, and coordination
among organizational entities),
processes, and procedures are
maintained and used to manage
protection of information systems
and assets.
PR.IP-9: Response plans
(Incident Response and
Business Continuity) and
recovery plans (Incident
Recovery and Disaster
Recovery) are in place and
managed
IR-4c IR-3e
IR-3f
IR-4d
IR-4f
IR-5a
IR-5b
IR-5c
IR-5d
RM-1a
RM-1b
TVM-
1d
IR-3k
IR-3m
IR-4i
IR-4j
IR-5e
IR-5f
IR-5g
IR-5h
IR-5i
RM-1c
CIP-003-5 R1 – 1.5: Each Responsible
Entity, for its high impact and medium
impact BES Cyber Systems, shall review
and obtain CIP Senior Manager approval
at least once every 15 calendar months for
one or more documented cyber security
policies that collectively address the
following topics: Incident reporting and
response planning (CIP‐008);
PROTECT
(PR)
Information Protection
Processes and Procedures (IP):
Security policies (that address
purpose, scope, roles,
responsibilities, management
commitment, and coordination
among organizational entities),
processes, and procedures are
maintained and used to manage
protection of information systems
and assets.
PR.IP-9: Response plans
(Incident Response and
Business Continuity) and
recovery plans (Incident
Recovery and Disaster
Recovery) are in place and
managed
IR-4c IR-3e
IR-3f
IR-4d
IR-4f
IR-5a
IR-5b
IR-5c
IR-5d
RM-1a
RM-1b
TVM-
1d
IR-3k
IR-3m
IR-4i
IR-4j
IR-5e
IR-5f
IR-5g
IR-5h
IR-5i
RM-1c
CIP-003-5 R1 – 1.6: Each Responsible
Entity, for its high impact and medium
impact BES Cyber Systems, shall review
and obtain CIP Senior Manager approval
at least once every 15 calendar months for
one or more documented cyber security
policies that collectively address the
following topics: Recovery plans for BES
Cyber Systems (CIP‐009);
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
95
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
PROTECT
(PR)
Information Protection
Processes and Procedures (IP):
Security policies (that address
purpose, scope, roles,
responsibilities, management
commitment, and coordination
among organizational entities),
processes, and procedures are
maintained and used to manage
protection of information systems
and assets.
PR.IP-9: Response plans
(Incident Response and
Business Continuity) and
recovery plans (Incident
Recovery and Disaster
Recovery) are in place and
managed
IR-4c IR-3e
IR-3f
IR-4d
IR-4f
IR-5a
IR-5b
IR-5c
IR-5d
RM-1a
RM-1b
TVM-
1d
IR-3k
IR-3m
IR-4i
IR-4j
IR-5e
IR-5f
IR-5g
IR-5h
IR-5i
RM-1c
CIP-003-5 R2 – 2.4: Each Responsible
Entity for its assets identified in CIP‐002‐5,
Requirement R1, Part R1.3, shall
implement, in a manner that identifies,
assesses, and corrects deficiencies, one
or more documented cyber security
policies that collectively address the
following topics, and review and obtain
CIP Senior Manager approval for those
policies at least once every 15 calendar
months: (An inventory, list, or discrete
identification of low impact BES Cyber
Systems or their BES Cyber Assets is not
required). Incident response to a Cyber
Security Incident.
PROTECT
(PR)
Information Protection
Processes and Procedures (IP):
Security policies (that address
purpose, scope, roles,
responsibilities, management
commitment, and coordination
among organizational entities),
processes, and procedures are
maintained and used to manage
protection of information systems
and assets.
PR.IP-9: Response plans
(Incident Response and
Business Continuity) and
recovery plans (Incident
Recovery and Disaster
Recovery) are in place and
managed
IR-4c IR-3e
IR-3f
IR-4d
IR-4f
IR-5a
IR-5b
IR-5c
IR-5d
RM-1a
RM-1b
TVM-
1d
IR-3k
IR-3m
IR-4i
IR-4j
IR-5e
IR-5f
IR-5g
IR-5h
IR-5i
RM-1c
CIP-008-5 R1: Each Responsible Entity
shall document one or more Cyber
Security Incident response plan(s) that
collectively include each of the applicable
requirement parts in CIP‐008‐5 Table R1 –
Cyber Security Incident Response Plan
Specifications.
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
96
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
PROTECT
(PR)
Information Protection
Processes and Procedures (IP):
Security policies (that address
purpose, scope, roles,
responsibilities, management
commitment, and coordination
among organizational entities),
processes, and procedures are
maintained and used to manage
protection of information systems
and assets.
PR.IP-9: Response plans
(Incident Response and
Business Continuity) and
recovery plans (Incident
Recovery and Disaster
Recovery) are in place and
managed
IR-4c IR-3e
IR-3f
IR-4d
IR-4f
IR-5a
IR-5b
IR-5c
IR-5d
RM-1a
RM-1b
TVM-
1d
IR-3k
IR-3m
IR-4i
IR-4j
IR-5e
IR-5f
IR-5g
IR-5h
IR-5i
RM-1c
CIP-008-5 R3: Each Responsible Entity
shall maintain each of its Cyber Security
Incident response plans according to each
of the applicable requirement parts in CIP‐
008‐5 Table R3 – Cyber Security Incident
Response Plan Review, Update, and
Communication.
PROTECT
(PR)
Information Protection
Processes and Procedures (IP):
Security policies (that address
purpose, scope, roles,
responsibilities, management
commitment, and coordination
among organizational entities),
processes, and procedures are
maintained and used to manage
protection of information systems
and assets.
PR.IP-9: Response plans
(Incident Response and
Business Continuity) and
recovery plans (Incident
Recovery and Disaster
Recovery) are in place and
managed
IR-4c IR-3e
IR-3f
IR-4d
IR-4f
IR-5a
IR-5b
IR-5c
IR-5d
RM-1a
RM-1b
TVM-
1d
IR-3k
IR-3m
IR-4i
IR-4j
IR-5e
IR-5f
IR-5g
IR-5h
IR-5i
RM-1c
CIP-009-5 R1: Each Responsible Entity
shall have one or more documented
recovery plans that collectively include
each of the applicable requirement parts in
CIP‐009‐5 Table R1 – Recovery Plan
Specifications.
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
97
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
PROTECT
(PR)
Information Protection
Processes and Procedures (IP):
Security policies (that address
purpose, scope, roles,
responsibilities, management
commitment, and coordination
among organizational entities),
processes, and procedures are
maintained and used to manage
protection of information systems
and assets.
PR.IP-9: Response plans
(Incident Response and
Business Continuity) and
recovery plans (Incident
Recovery and Disaster
Recovery) are in place and
managed
IR-4c IR-3e
IR-3f
IR-4d
IR-4f
IR-5a
IR-5b
IR-5c
IR-5d
RM-1a
RM-1b
TVM-
1d
IR-3k
IR-3m
IR-4i
IR-4j
IR-5e
IR-5f
IR-5g
IR-5h
IR-5i
RM-1c
CIP-009-5 R3: Each Responsible Entity
shall maintain each of its recovery plans in
accordance with each of the applicable
requirement parts in CIP‐009‐5 Table R3 –
Recovery Plan Review, Update and
Communication.
PROTECT
(PR)
Information Protection
Processes and Procedures (IP):
Security policies (that address
purpose, scope, roles,
responsibilities, management
commitment, and coordination
among organizational entities),
processes, and procedures are
maintained and used to manage
protection of information systems
and assets.
PR.IP-10: Response and
recovery plans are tested
IR-3e
IR-4f
IR-3k
IR-4i
IR-4j
CIP-008-5 R2: Each Responsible Entity
shall implement each of its documented
Cyber Security Incident response plans to
collectively include each of the applicable
requirement parts in CIP‐008‐5 Table R2 –
Cyber Security Incident Response Plan
Implementation and Testing.
PROTECT
(PR)
Information Protection
Processes and Procedures (IP):
Security policies (that address
purpose, scope, roles,
responsibilities, management
commitment, and coordination
among organizational entities),
processes, and procedures are
maintained and used to manage
protection of information systems
and assets.
PR.IP-10: Response and
recovery plans are tested
IR-3e
IR-4f
IR-3k
IR-4i
IR-4j
CIP-009-5 R2: Each Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, its documented recovery
plan(s) to collectively include each of the
applicable requirement parts in CIP‐009‐5
Table R2 – Recovery Plan Implementation
and Testing.
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
98
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
PROTECT
(PR)
Information Protection
Processes and Procedures (IP):
Security policies (that address
purpose, scope, roles,
responsibilities, management
commitment, and coordination
among organizational entities),
processes, and procedures are
maintained and used to manage
protection of information systems
and assets.
PR.IP-11: Cybersecurity is
included in human resources
practices (e.g., deprovisioning,
personnel screening)
WM-2a
WM-2b
WM-2c
WM-2d
WM-2e
WM-2f
WM-2g
WM-2h
CIP-004-5.1 R3: Each Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, one or more documented
personnel risk assessment programs to
attain and retain authorized electronic or
authorized unescorted physical access to
BES Cyber Systems that collectively
include each of the applicable requirement
parts in CIP‐004‐5.1 Table R3 – Personnel
Risk Assessment Program.
PROTECT
(PR)
Information Protection
Processes and Procedures (IP):
Security policies (that address
purpose, scope, roles,
responsibilities, management
commitment, and coordination
among organizational entities),
processes, and procedures are
maintained and used to manage
protection of information systems
and assets.
PR.IP-11: Cybersecurity is
included in human resources
practices (e.g., deprovisioning,
personnel screening)
WM-2a
WM-2b
WM-2c
WM-2d
WM-2e
WM-2f
WM-2g
WM-2h
CIP-004-5.1 R4: Each Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, one or more documented
access management programs that
collectively include each of the applicable
requirement parts in CIP‐004‐5.1 Table R4
– Access Management Program.
PROTECT
(PR)
Information Protection
Processes and Procedures (IP):
Security policies (that address
purpose, scope, roles,
responsibilities, management
commitment, and coordination
among organizational entities),
processes, and procedures are
maintained and used to manage
protection of information systems
and assets.
PR.IP-11: Cybersecurity is
included in human resources
practices (e.g., deprovisioning,
personnel screening)
WM-2a
WM-2b
WM-2c
WM-2d
WM-2e
WM-2f
WM-2g
WM-2h
CIP-004-5.1 R5: Each Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, one or more documented
access revocation programs that
collectively include each of the applicable
requirement parts in CIP‐004‐5.1 Table R5
– Access Revocation.
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
99
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
PROTECT
(PR)
Information Protection
Processes and Procedures (IP):
Security policies (that address
purpose, scope, roles,
responsibilities, management
commitment, and coordination
among organizational entities),
processes, and procedures are
maintained and used to manage
protection of information systems
and assets.
PR.IP-12: A vulnerability
management plan is developed
and implemented
TVM-
2d
TVM-
2e
TVM-
3e
TVM-
3f
CIP-007-5 R2: Each Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, one or more documented
processes that collectively include each of
the applicable requirement parts in CIP-
007-5 Table R2 – Security Patch
Management.
PROTECT
(PR)
Information Protection
Processes and Procedures (IP):
Security policies (that address
purpose, scope, roles,
responsibilities, management
commitment, and coordination
among organizational entities),
processes, and procedures are
maintained and used to manage
protection of information systems
and assets.
PR.IP-12: A vulnerability
management plan is developed
and implemented
TVM-
2d
TVM-
2e
TVM-
3e
TVM-
3f
CIP-007-5 R3: Each Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, one or more documented
processes that collectively include each of
the applicable requirement parts in CIP-
007-5 Table R3 – Malicious Code
Prevention.
PROTECT
(PR)
Information Protection
Processes and Procedures (IP):
Security policies (that address
purpose, scope, roles,
responsibilities, management
commitment, and coordination
among organizational entities),
processes, and procedures are
maintained and used to manage
protection of information systems
and assets.
PR.IP-12: A vulnerability
management plan is developed
and implemented
TVM-
2d
TVM-
2e
TVM-
3e
TVM-
3f
CIP-010-1 R3: Each Responsible Entity
shall implement one or more documented
processes that collectively include each of
the applicable requirement parts in CIP ‐
010 ‐ 1 Table R3– Vulnerability
Assessments.
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
100
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
PROTECT
(PR)
Maintenance (MA): Maintenance
and repairs of industrial control
and information system
components is performed
consistent with policies and
procedures.
PR.MA-1: Maintenance and
repair of organizational assets
is performed and logged in a
timely manner, with approved
and controlled tools
IAM-
2a
ACM-
1c
AMC-
3f
CIP-010-1 R1: Each Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, one or more documented
processes that collectively include each of
the applicable requirement parts in CIP‐
010‐1 Table R1 – Configuration Change
Management.
PROTECT
(PR)
Maintenance (MA): Maintenance
and repairs of industrial control
and information system
components is performed
consistent with policies and
procedures.
PR.MA-1: Maintenance and
repair of organizational assets
is performed and logged in a
timely manner, with approved
and controlled tools
IAM-
2a
ACM-
1c
AMC-
3f
CIP-006-5 R3: Each Responsible Entity
shall implement one or more documented
Physical Access Control System
maintenance and testing programs that
collectively include each of the applicable
requirement parts in CIP-006-5 Table R3 –
Maintenance and Testing Program.
PROTECT
(PR)
Maintenance (MA): Maintenance
and repairs of industrial control
and information system
components is performed
consistent with policies and
procedures.
PR.MA-2: Remote maintenance
of organizational assets is
approved, logged, and
performed in a manner that
prevents unauthorized access
SA-1a
IR-1c
IAM-
2a
IAM-
2b
IAM-
2c
IAM-
2d
IAM-
2e
IAM-2f
IAM-
2g
IAM-
2h
IAM-2i
CIP-005-5 R2: Each Responsible Entity
allowing Interactive Remote Access to
BES Cyber Systems shall implement one
or more documented processes that
collectively include the applicable
requirement parts, where technically
feasible, in CIP-005-5 Table R2 –
Interactive Remote Access Management.
PROTECT
(PR)
Maintenance (MA): Maintenance
and repairs of industrial control
and information system
components is performed
consistent with policies and
procedures.
PR.MA-2: Remote maintenance
of organizational assets is
approved, logged, and
performed in a manner that
prevents unauthorized access
SA-1a
IR-1c
IAM-
2a
IAM-
2b
IAM-
2c
IAM-
2d
IAM-
2e
IAM-2f
IAM-
2g
IAM-
2h
IAM-2i
CIP-006-5 R3: Each Responsible Entity
shall implement one or more documented
Physical Access Control System
maintenance and testing programs that
collectively include each of the applicable
requirement parts in CIP-006-5 Table R3 –
Maintenance and Testing Program.
PROTECT
(PR)
Maintenance (MA): Maintenance
and repairs of industrial control
and information system
components is performed
consistent with policies and
procedures.
PR.MA-2: Remote maintenance
of organizational assets is
approved, logged, and
performed in a manner that
prevents unauthorized access
SA-1a
IR-1c
IAM-
2a
IAM-
2b
IAM-
2d
IAM-
2e
IAM-2f
IAM-
2g
IAM-
2h
IAM-2i
CIP-010-1 R1: Each Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, one or more documented
processes that collectively include each of
the applicable requirement parts in CIP‐
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
101
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
IAM-
2c
010‐1 Table R1 – Configuration Change
Management.
PROTECT
(PR)
Protective Technology (PT):
Technical security solutions are
managed to ensure the security
and resilience of systems and
assets, consistent with related
policies, procedures, and
agreements.
PR.PT-1: Audit/log records are
determined, documented,
implemented, and reviewed in
accordance with policy
SA-1a
SA-2a
SA-1b
SA-1c
SA-2e
SA-4a
SA-1d
SA-1e
SA-3d
SA-4e
CIP-006-5 R1 – 1.6: Monitor each Physical
Access Control
System for unauthorized physical access
to a Physical Access Control System.
PROTECT
(PR)
Protective Technology (PT):
Technical security solutions are
managed to ensure the security
and resilience of systems and
assets, consistent with related
policies, procedures, and
agreements.
PR.PT-1: Audit/log records are
determined, documented,
implemented, and reviewed in
accordance with policy
SA-1a
SA-2a
SA-1b
SA-1c
SA-2e
SA-4a
SA-1d
SA-1e
SA-3d
SA-4e
CIP-006-5 R1 – 1.8: Log (through
automated means or by
personnel who control entry) entry of each
individual with authorized unescorted
physical access into each Physical
Security Perimeter, with information to
identify the individual and date and time of
entry.
PROTECT
(PR)
Protective Technology (PT):
Technical security solutions are
managed to ensure the security
and resilience of systems and
assets, consistent with related
policies, procedures, and
agreements.
PR.PT-1: Audit/log records are
determined, documented,
implemented, and reviewed in
accordance with policy
SA-1a
SA-2a
SA-1b
SA-1c
SA-2e
SA-4a
SA-1d
SA-1e
SA-3d
SA-4e
CIP-006-5 R1 – 1.9: Retain physical
access logs of entry of
individuals with authorized unescorted
physical access into each Physical
Security Perimeter for at least ninety
calendar days.
PROTECT
(PR)
Protective Technology (PT):
Technical security solutions are
managed to ensure the security
and resilience of systems and
assets, consistent with related
policies, procedures, and
agreements.
PR.PT-1: Audit/log records are
determined, documented,
implemented, and reviewed in
accordance with policy
SA-1a
SA-2a
SA-1b
SA-1c
SA-2e
SA-4a
SA-1d
SA-1e
SA-3d
SA-4e
CIP-006-5 R2 – 2.2: Require manual or
automated logging
of visitor entry into and exit from the
Physical Security Perimeter that includes
date and time of the initial entry and last
exit, the visitor’s name, and the name of
an individual point of contact responsible
for the visitor, except during CIP
Exceptional Circumstances.
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
102
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
PROTECT
(PR)
Protective Technology (PT):
Technical security solutions are
managed to ensure the security
and resilience of systems and
assets, consistent with related
policies, procedures, and
agreements.
PR.PT-1: Audit/log records are
determined, documented,
implemented, and reviewed in
accordance with policy
SA-1a
SA-2a
SA-1b
SA-1c
SA-2e
SA-4a
SA-1d
SA-1e
SA-3d
SA-4e
CIP-006-5 R1 – 2.3: Retain visitor logs for
at least ninety
calendar days.
PROTECT
(PR)
Protective Technology (PT):
Technical security solutions are
managed to ensure the security
and resilience of systems and
assets, consistent with related
policies, procedures, and
agreements.
PR.PT-1: Audit/log records are
determined, documented,
implemented, and reviewed in
accordance with policy
SA-1a
SA-2a
SA-1b
SA-1c
SA-2e
SA-4a
SA-1d
SA-1e
SA-3d
SA-4e
CIP-007-5 R4 – 4.3: Where technically
feasible, retain applicable event logs
identified in Part 4.1 for at least the last 90
consecutive calendar days except under
CIP Exceptional Circumstances.
PROTECT
(PR)
Protective Technology (PT):
Technical security solutions are
managed to ensure the security
and resilience of systems and
assets, consistent with related
policies, procedures, and
agreements.
PR.PT-1: Audit/log records are
determined, documented,
implemented, and reviewed in
accordance with policy
SA-1a
SA-2a
SA-1b
SA-1c
SA-2e
SA-4a
SA-1d
SA-1e
SA-3d
SA-4e
CIP-007-5 R4 – 4.4: Review a
summarization or sampling of logged
events as determined by the Responsible
Entity at intervals no greater than 15
calendar days to identify undetected Cyber
Security Incidents.
PROTECT
(PR)
Protective Technology (PT):
Technical security solutions are
managed to ensure the security
and resilience of systems and
assets, consistent with related
policies, procedures, and
agreements.
PR.PT-2: Removable media is
protected and its use restricted
according to policy
IAM-
2a
IAM-
2b
IAM-
1c
IAM-
2c
IAM-
2e
IAM-3f
IAM-1i
PROTECT
(PR)
Protective Technology (PT):
Technical security solutions are
managed to ensure the security
and resilience of systems and
assets, consistent with related
policies, procedures, and
agreements.
PR.PT-3: Access to systems
and assets is controlled,
incorporating the principle of
least functionality
IAM-
2a
IAM-
2b
IAM-
2c
IAM-
2d
IAM-
2e
IAM-2f
IAM-
2g
IAM-
2h
IAM-2i
CIP-004-5.1 R4: Each Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, one or more documented
access management programs that
collectively include each of the applicable
requirement parts in CIP‐004‐5.1 Table R4
– Access Management Program.
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
103
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
PROTECT
(PR)
Protective Technology (PT):
Technical security solutions are
managed to ensure the security
and resilience of systems and
assets, consistent with related
policies, procedures, and
agreements.
PR.PT-3: Access to systems
and assets is controlled,
incorporating the principle of
least functionality
IAM-
2a
IAM-
2b
IAM-
2c
IAM-
2d
IAM-
2e
IAM-2f
IAM-
2g
IAM-
2h
IAM-2i
CIP-004-5.1 R5: Each Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, one or more documented
access revocation programs that
collectively include each of the applicable
requirement parts in CIP‐004‐5.1 Table R5
– Access Revocation.
PROTECT
(PR)
Protective Technology (PT):
Technical security solutions are
managed to ensure the security
and resilience of systems and
assets, consistent with related
policies, procedures, and
agreements.
PR.PT-3: Access to systems
and assets is controlled,
incorporating the principle of
least functionality
IAM-
2a
IAM-
2b
IAM-
2c
IAM-
2d
IAM-
2e
IAM-2f
IAM-
2g
IAM-
2h
IAM-2i
CIP-005-5 R2: Each Responsible Entity
allowing Interactive Remote Access to
BES Cyber Systems shall implement one
or more documented processes that
collectively include the applicable
requirement parts, where technically
feasible, in CIP-005-5 Table R2 –
Interactive Remote Access Management.
PROTECT
(PR)
Protective Technology (PT):
Technical security solutions are
managed to ensure the security
and resilience of systems and
assets, consistent with related
policies, procedures, and
agreements.
PR.PT-3: Access to systems
and assets is controlled,
incorporating the principle of
least functionality
IAM-
2a
IAM-
2b
IAM-
2c
IAM-
2d
IAM-
2e
IAM-2f
IAM-
2g
IAM-
2h
IAM-2i
CIP-007-5 R5: Each Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, one or more documented
processes that collectively include each of
the applicable requirement parts in CIP-
007-5 Table R5 – System Access
Controls.
PROTECT
(PR)
Protective Technology (PT):
Technical security solutions are
managed to ensure the security
and resilience of systems and
assets, consistent with related
policies, procedures, and
agreements.
PR.PT-4: Communications and
control networks are protected
CPM-
3a
CPM-
3b
CPM-
3c
CPM-
3d
CIP-004-5.1 R4: Each Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, one or more documented
access management programs that
collectively include each of the applicable
requirement parts in CIP‐004‐5.1 Table R4
– Access Management Program.
PROTECT
(PR)
Protective Technology (PT):
Technical security solutions are
managed to ensure the security
and resilience of systems and
assets, consistent with related
PR.PT-4: Communications and
control networks are protected
CPM-
3a
CPM-
3b
CPM-
3c
CPM-
3d
CIP-005-5 R1: Each Responsible Entity
shall implement one or more documented
processes that collectively include each of
the applicable requirement parts in CIP-
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
104
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
policies, procedures, and
agreements.
005-5 Table R1 – Electronic Security
Perimeter.
PROTECT
(PR)
Protective Technology (PT):
Technical security solutions are
managed to ensure the security
and resilience of systems and
assets, consistent with related
policies, procedures, and
agreements.
PR.PT-4: Communications and
control networks are protected
CPM-
3a
CPM-
3b
CPM-
3c
CPM-
3d
CIP-005-5 R2: Each Responsible Entity
allowing Interactive Remote Access to
BES Cyber Systems shall implement one
or more documented processes that
collectively include the applicable
requirement parts, where technically
feasible, in CIP-005-5 Table R2 –
Interactive Remote Access Management.
DETECT
(DE)
Anomalies and Events (AE):
Anomalous activity is detected in a
timely manner and the potential
impact of events is understood.
DE.AE-1: A baseline of network
operations and expected data
flows for users and systems is
established and managed
SA-2b SA-2e
DETECT
(DE)
Anomalies and Events (AE):
Anomalous activity is detected in a
timely manner and the potential
impact of events is understood.
DE.AE-2: Detected events are
analyzed to understand attack
targets and methods
IR-2i
IR-3h
CIP-003-5 R1 – 1.5: Each Responsible
Entity, for its high impact and medium
impact BES Cyber Systems, shall review
and obtain CIP Senior Manager approval
at least once every 15 calendar months for
one or more documented cyber security
policies that collectively address the
following topics: Incident reporting and
response planning (CIP‐008);
DETECT
(DE)
Anomalies and Events (AE):
Anomalous activity is detected in a
timely manner and the potential
impact of events is understood.
DE.AE-2: Detected events are
analyzed to understand attack
targets and methods
IR-2i
IR-3h
CIP-007-5 R4: Each Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, one or more documented
processes that collectively include each of
the applicable requirement parts in CIP-
007-5 Table R4 – Security Event
Monitoring.
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
105
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
DETECT
(DE)
Anomalies and Events (AE):
Anomalous activity is detected in a
timely manner and the potential
impact of events is understood.
DE.AE-2: Detected events are
analyzed to understand attack
targets and methods
IR-2i
IR-3h
CIP-008-5 R1: Each Responsible Entity
shall document one or more Cyber
Security Incident response plan(s) that
collectively include each of the applicable
requirement parts in CIP‐008‐5 Table R1 –
Cyber Security Incident Response Plan
Specifications.
DETECT
(DE)
Anomalies and Events (AE):
Anomalous activity is detected in a
timely manner and the potential
impact of events is understood.
DE.AE-2: Detected events are
analyzed to understand attack
targets and methods
IR-2i
IR-3h
CIP-008-5 R2: Each Responsible Entity
shall implement each of its documented
Cyber Security Incident response plans to
collectively include each of the applicable
requirement parts in CIP‐008‐5 Table R2 –
Cyber Security Incident Response Plan
Implementation and Testing.
DETECT
(DE)
Anomalies and Events (AE):
Anomalous activity is detected in a
timely manner and the potential
impact of events is understood.
DE.AE-3: Event data are
aggregated and correlated from
multiple sources and sensors
IR-1e IR-1f
IR-2i
CIP-007-5 R4: Each Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, one or more documented
processes that collectively include each of
the applicable requirement parts in CIP-
007-5 Table R4 – Security Event
Monitoring.
DETECT
(DE)
Anomalies and Events (AE):
Anomalous activity is detected in a
timely manner and the potential
impact of events is understood.
DE.AE-4: Impact of events is
determined
IR-2b IR-2d IR-2g CIP-008-5 R1 – 1.1: Each Responsible
Entity shall document one or more Cyber
Security Incident response plan(s) that
collectively include
1.1 One or more processes to identify,
classify, and respond to Cyber Security
Incidents.
DETECT
(DE)
Anomalies and Events (AE):
Anomalous activity is detected in a
timely manner and the potential
impact of events is understood.
DE.AE-5: Incident alert
thresholds are established
IR-2d
TVM-
1d
SA-2d
IR-2g
RM-2j
CIP-003-5 R1 – 1.5: Each Responsible
Entity, for its high impact and medium
impact BES Cyber Systems, shall review
and obtain CIP Senior Manager approval
at least once every 15 calendar months for
one or more documented cyber security
policies that collectively address the
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
106
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
following topics: Incident reporting and
response planning (CIP‐008);
DETECT
(DE)
Anomalies and Events (AE):
Anomalous activity is detected in a
timely manner and the potential
impact of events is understood.
DE.AE-5: Incident alert
thresholds are established
IR-2d
TVM-
1d
SA-2d
IR-2g
RM-2j
CIP-003-5 R2 – 2.4: Each Responsible
Entity for its assets identified in CIP‐002‐5,
Requirement R1, Part R1.3, shall
implement, in a manner that identifies,
assesses, and corrects deficiencies, one
or more documented cyber security
policies that collectively address the
following topics, and review and obtain
CIP Senior Manager approval for those
policies at least once every 15 calendar
months: (An inventory, list, or discrete
identification of low impact BES Cyber
Systems or their BES Cyber Assets is not
required). Incident response to a Cyber
Security Incident.
DETECT
(DE)
Anomalies and Events (AE):
Anomalous activity is detected in a
timely manner and the potential
impact of events is understood.
DE.AE-5: Incident alert
thresholds are established
IR-2d
TVM-
1d
SA-2d
IR-2g
RM-2j
CIP-008-5 R1: Each Responsible Entity
shall document one or more Cyber
Security Incident response plan(s) that
collectively include each of the applicable
requirement parts in CIP‐008‐5 Table R1 –
Cyber Security Incident Response Plan
Specifications.
DETECT
(DE)
Anomalies and Events (AE):
Anomalous activity is detected in a
timely manner and the potential
impact of events is understood.
DE.AE-5: Incident alert
thresholds are established
IR-2d
TVM-
1d
SA-2d
IR-2g
RM-2j
CIP-008-5 R2: Each Responsible Entity
shall implement each of its documented
Cyber Security Incident response plans to
collectively include each of the applicable
requirement parts in CIP‐008‐5 Table R2 –
Cyber Security Incident Response Plan
Implementation and Testing.
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
107
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
DETECT
(DE)
Anomalies and Events (AE):
Anomalous activity is detected in a
timely manner and the potential
impact of events is understood.
DE.AE-5: Incident alert
thresholds are established
IR-2d
TVM-
1d
SA-2d
IR-2g
RM-2j
CIP-008-5 R3: Each Responsible Entity
shall maintain each of its Cyber Security
Incident response plans according to each
of the applicable requirement parts in CIP‐
008‐5 Table R3 – Cyber Security Incident
Response Plan Review, Update, and
Communication.
DETECT
(DE)
Security Continuous Monitoring
(CM): The information system and
assets are monitored at discrete
intervals to identify cybersecurity
events and verify the effectiveness
of protective measures.
DE.CM-1: The network is
monitored to detect potential
cybersecurity events
SA-2a
SA-2b
SA-2e
SA-2f
SA-2g
SA-2i
CIP-005-5 R1 – 1.5: Each Responsible
Entity shall implement one or more
documented processes that collectively
include each of the applicable requirement
parts in CIP‐005‐5 Table R1 – Electronic
Security Perimeter. Have one or more
methods for
detecting known or suspected malicious
communications for both
inbound and outbound communications.
DETECT
(DE)
Security Continuous Monitoring
(CM): The information system and
assets are monitored at discrete
intervals to identify cybersecurity
events and verify the effectiveness
of protective measures.
DE.CM-2: The physical
environment is monitored to
detect potential cybersecurity
events
SA-2a
SA-2b
SA-2i CIP-006-5 R1: Each Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, one or more documented
physical security plans that collectively
include all of the applicable requirement
parts in CIP-006-5 Table R1 – Physical
Security Plan.
DETECT
(DE)
Security Continuous Monitoring
(CM): The information system and
assets are monitored at discrete
intervals to identify cybersecurity
events and verify the effectiveness
of protective measures.
DE.CM-2: The physical
environment is monitored to
detect potential cybersecurity
events
SA-2a
SA-2b
SA-2i CIP-006-5 R2: Each Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, one or more documented
visitor control programs that include each
of the applicable requirement parts in CIP-
006-5 Table R2 – Visitor Control Program.
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
108
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
DETECT
(DE)
Security Continuous Monitoring
(CM): The information system and
assets are monitored at discrete
intervals to identify cybersecurity
events and verify the effectiveness
of protective measures.
DE.CM-3: Personnel activity is
monitored to detect potential
cybersecurity events
SA-2a
SA-2b
SA-2i CIP-003-5 R1 – 1.2: Each Responsible
Entity, for its high impact and medium
impact BES Cyber Systems, shall review
and obtain CIP Senior Manager approval
at least once every 15 calendar months for
one or more documented cyber security
policies that collectively address the
following topics: Electronic Security
Perimeters (CIP‐005) including Interactive
Remote Access;
DETECT
(DE)
Security Continuous Monitoring
(CM): The information system and
assets are monitored at discrete
intervals to identify cybersecurity
events and verify the effectiveness
of protective measures.
DE.CM-3: Personnel activity is
monitored to detect potential
cybersecurity events
SA-2a
SA-2b
SA-2i CIP-003-5 R1 – 1.4: Each Responsible
Entity, for its high impact and medium
impact BES Cyber Systems, shall review
and obtain CIP Senior Manager approval
at least once every 15 calendar months for
one or more documented cyber security
policies that collectively address the
following topics: System security
management (CIP‐007);
DETECT
(DE)
Security Continuous Monitoring
(CM): The information system and
assets are monitored at discrete
intervals to identify cybersecurity
events and verify the effectiveness
of protective measures.
DE.CM-3: Personnel activity is
monitored to detect potential
cybersecurity events
SA-2a
SA-2b
SA-2i CIP-007-5 R4: Each Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, one or more documented
processes that collectively include each of
the applicable requirement parts in CIP-
007-5 Table R4 – Security Event
Monitoring.
DETECT
(DE)
Security Continuous Monitoring
(CM): The information system and
assets are monitored at discrete
intervals to identify cybersecurity
events and verify the effectiveness
of protective measures.
DE.CM-3: Personnel activity is
monitored to detect potential
cybersecurity events
SA-2a
SA-2b
SA-2i CIP-007-5 R5: Each Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, one or more documented
processes that collectively include each of
the applicable requirement parts in CIP-
007-5 Table R5 – System Access
Controls.
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
109
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
DETECT
(DE)
Security Continuous Monitoring
(CM): The information system and
assets are monitored at discrete
intervals to identify cybersecurity
events and verify the effectiveness
of protective measures.
DE.CM-4: Malicious code is
detected
SA-2a
SA-2b
SA-2e
CPM-
4a
SA-2i CIP-003-5 R1 – 1.2: Each Responsible
Entity, for its high impact and medium
impact BES Cyber Systems, shall review
and obtain CIP Senior Manager approval
at least once every 15 calendar months for
one or more documented cyber security
policies that collectively address the
following topics: Electronic Security
Perimeters (CIP‐005) including Interactive
Remote Access;
DETECT
(DE)
Security Continuous Monitoring
(CM): The information system and
assets are monitored at discrete
intervals to identify cybersecurity
events and verify the effectiveness
of protective measures.
DE.CM-4: Malicious code is
detected
SA-2a
SA-2b
SA-2e
CPM-
4a
SA-2i CIP-007-5 R3: Each Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, one or more documented
processes that collectively include each of
the applicable requirement parts in CIP-
007-5 Table R3 – Malicious Code
Prevention.
DETECT
(DE)
Security Continuous Monitoring
(CM): The information system and
assets are monitored at discrete
intervals to identify cybersecurity
events and verify the effectiveness
of protective measures.
DE.CM-5: Unauthorized mobile
code is detected
SA-2a
SA-2b
SA-2e SA-2h
SA-2i
CIP-007-5 R3: Each Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, one or more documented
processes that collectively include each of
the applicable requirement parts in CIP-
007-5 Table R3 – Malicious Code
Prevention.
DETECT
(DE)
Security Continuous Monitoring
(CM): The information system and
assets are monitored at discrete
intervals to identify cybersecurity
events and verify the effectiveness
of protective measures.
DE.CM-5: Unauthorized mobile
code is detected
SA-2a
SA-2b
SA-2e SA-2h
SA-2i
CIP-010-1 R2: Each Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, one or more documented
processes that collectively include each of
the applicable requirement parts in CIP‐
010‐1 Table R2 – Configuration
Monitoring.
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
110
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
DETECT
(DE)
Security Continuous Monitoring
(CM): The information system and
assets are monitored at discrete
intervals to identify cybersecurity
events and verify the effectiveness
of protective measures.
DE.CM-6: External service
provider activity is monitored to
detect potential cybersecurity
events
EDM-
2a
SA-2a
SA-2b
EDM-
2j
EDM-
2l
EDM-
2n
CIP-005-5 R1 – 1.5: Each Responsible
Entity shall implement one or more
documented processes that collectively
include each of the applicable requirement
parts in CIP‐005‐5 Table R1 – Electronic
Security Perimeter. Have one or more
methods for
detecting known or suspected malicious
communications for both
inbound and outbound communications.
DETECT
(DE)
Security Continuous Monitoring
(CM): The information system and
assets are monitored at discrete
intervals to identify cybersecurity
events and verify the effectiveness
of protective measures.
DE.CM-7: Monitoring for
unauthorized personnel,
connections, devices, and
software is performed
SA-2a
SA-2b
SA-2e
SA-2f
SA-2g
SA-2i
CIP-003-5 R2 – 2.3: Each Responsible
Entity for its assets identified in CIP‐002‐5,
Requirement R1, Part R1.3, shall
implement, in a manner that identifies,
assesses, and corrects deficiencies, one
or more documented cyber security
policies that collectively address the
following topics, and review and obtain
CIP Senior Manager approval for those
policies at least once every 15 calendar
months: (An inventory, list, or discrete
identification of low impact BES Cyber
Systems or their BES Cyber Assets is not
required). Electronic access controls for
external routable protocol connections and
Dial‐up Connectivity;
DETECT
(DE)
Security Continuous Monitoring
(CM): The information system and
assets are monitored at discrete
intervals to identify cybersecurity
events and verify the effectiveness
of protective measures.
DE.CM-7: Monitoring for
unauthorized personnel,
connections, devices, and
software is performed
SA-2a
SA-2b
SA-2e
SA-2f
SA-2g
SA-2i
CIP-004-5.1 R3: Each Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, one or more documented
personnel risk assessment programs to
attain and retain authorized electronic or
authorized unescorted physical access to
BES Cyber Systems that collectively
include each of the applicable requirement
parts in CIP‐004‐5.1 Table R3 – Personnel
Risk Assessment Program.
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
111
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
DETECT
(DE)
Security Continuous Monitoring
(CM): The information system and
assets are monitored at discrete
intervals to identify cybersecurity
events and verify the effectiveness
of protective measures.
DE.CM-7: Monitoring for
unauthorized personnel,
connections, devices, and
software is performed
SA-2a
SA-2b
SA-2e
SA-2f
SA-2g
SA-2i
CIP-006-5 R1 – 1.5: Issue an alarm or alert
in response to detected unauthorized
access through a physical access point
into a Physical Security Perimeter to the
personnel identified in the BES Cyber
Security Incident response plan within 15
minutes of detection.
DETECT
(DE)
Security Continuous Monitoring
(CM): The information system and
assets are monitored at discrete
intervals to identify cybersecurity
events and verify the effectiveness
of protective measures.
DE.CM-7: Monitoring for
unauthorized personnel,
connections, devices, and
software is performed
SA-2a
SA-2b
SA-2e
SA-2f
SA-2g
SA-2i
CIP-006-5 R1 – 1.6: Monitor each Physical
Access Control
System for unauthorized physical access
to a Physical Access Control System.
DETECT
(DE)
Security Continuous Monitoring
(CM): The information system and
assets are monitored at discrete
intervals to identify cybersecurity
events and verify the effectiveness
of protective measures.
DE.CM-7: Monitoring for
unauthorized personnel,
connections, devices, and
software is performed
SA-2a
SA-2b
SA-2e
SA-2f
SA-2g
SA-2i
CIP-007-5 R4: Each Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, one or more documented
processes that collectively include each of
the applicable requirement parts in CIP-
007-5 Table R4 – Security Event
Monitoring.
DETECT
(DE)
Security Continuous Monitoring
(CM): The information system and
assets are monitored at discrete
intervals to identify cybersecurity
events and verify the effectiveness
of protective measures.
DE.CM-8: Vulnerability scans
are performed
TVM-
2e
TVM-
2i
CIP-003-5 R1 – 1.7: Each Responsible
Entity, for its high impact and medium
impact BES Cyber Systems, shall review
and obtain CIP Senior Manager approval
at least once every 15 calendar months for
one or more documented cyber security
policies that collectively address the
following topics: Configuration change
management and vulnerability
assessments (CIP‐010);
DETECT
(DE)
Security Continuous Monitoring
(CM): The information system and
assets are monitored at discrete
intervals to identify cybersecurity
events and verify the effectiveness
of protective measures.
DE.CM-8: Vulnerability scans
are performed
TVM-
2e
TVM-
2i
CIP-007-5 R3: Each Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, one or more documented
processes that collectively include each of
the applicable requirement parts in CIP-
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
112
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
007-5 Table R3 – Malicious Code
Prevention.
DETECT
(DE)
Security Continuous Monitoring
(CM): The information system and
assets are monitored at discrete
intervals to identify cybersecurity
events and verify the effectiveness
of protective measures.
DE.CM-8: Vulnerability scans
are performed
TVM-
2e
TVM-
2i
CIP-010-1 R3: Each Responsible Entity
shall implement one or more documented
processes that collectively include each of
the applicable requirement parts in CIP ‐
010 ‐ 1 Table R3– Vulnerability
Assessments.
DETECT
(DE)
Detection Processes (DP):
Detection Processes (DP):
Detection processes and
procedures are maintained and
tested to ensure timely and
adequate awareness of
anomalous events.
DE.DP-1: Roles and
responsibilities for detection are
well defined to ensure
accountability
IR-1a
IR-3a
WM-1a
WM-1b
WM-1d WM-1f
WM-1h
CIP-003-5 R1 – 1.1: Each Responsible
Entity, for its high impact and medium
impact BES Cyber Systems, shall review
and obtain CIP Senior Manager approval
at least once every 15 calendar months for
one or more documented cyber security
policies that collectively address the
following topics: Personnel & training (CIP‐
004)
DETECT
(DE)
Detection Processes (DP):
Detection Processes (DP):
Detection processes and
procedures are maintained and
tested to ensure timely and
adequate awareness of
anomalous events.
DE.DP-1: Roles and
responsibilities for detection are
well defined to ensure
accountability
IR-1a
IR-3a
WM-1a
WM-1b
WM-1d WM-1f
WM-1h
CIP-003-5 R3: Each Responsible Entity
shall identify a CIP Senior Manager by
name and document any change within 30
calendar days of the change.
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
113
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
DETECT
(DE)
Detection Processes (DP):
Detection Processes (DP):
Detection processes and
procedures are maintained and
tested to ensure timely and
adequate awareness of
anomalous events.
DE.DP-1: Roles and
responsibilities for detection are
well defined to ensure
accountability
IR-1a
IR-3a
WM-1a
WM-1b
WM-1d WM-1f
WM-1h
CIP-003-5 R4: The Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, a documented process to
delegate authority, unless no delegations
are used. Where allowed by the CIP
Standards, the CIP Senior Manager may
delegate authority for specific actions to a
delegate or delegates. These delegations
shall be documented, including the name
or title of the delegate, the specific actions
delegated, and the date of the delegation;
approved by the CIP Senior Manager; and
updated within 30 days of any change to
the delegation. Delegation changes do not
need to be reinstated with a change to the
delegator.
DETECT
(DE)
Detection Processes (DP):
Detection Processes (DP):
Detection processes and
procedures are maintained and
tested to ensure timely and
adequate awareness of
anomalous events.
DE.DP-1: Roles and
responsibilities for detection are
well defined to ensure
accountability
IR-1a
IR-3a
WM-1a
WM-1b
WM-1d WM-1f
WM-1h
CIP-007-5 R3: Each Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, one or more documented
processes that collectively include each of
the applicable requirement parts in CIP-
007-5 Table R3 – Malicious Code
Prevention.
DETECT
(DE)
Detection Processes (DP):
Detection Processes (DP):
Detection processes and
procedures are maintained and
tested to ensure timely and
adequate awareness of
anomalous events.
DE.DP-1: Roles and
responsibilities for detection are
well defined to ensure
accountability
IR-1a
IR-3a
WM-1a
WM-1b
WM-1d WM-1f
WM-1h
CIP-008-5 R1: Each Responsible Entity
shall document one or more Cyber
Security Incident response plan(s) that
collectively include each of the applicable
requirement parts in CIP‐008‐5 Table R1 –
Cyber Security Incident Response Plan
Specifications.
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
114
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
DETECT
(DE)
Detection Processes (DP):
Detection Processes (DP):
Detection processes and
procedures are maintained and
tested to ensure timely and
adequate awareness of
anomalous events.
DE.DP-2: Detection activities
comply with all applicable
requirements
IR-1d IR-1g
IR-5f
RM-1c
RM-2j
CIP-008-5 R3: Each Responsible Entity
shall maintain each of its Cyber Security
Incident response plans according to each
of the applicable requirement parts in CIP‐
008‐5 Table R3 – Cyber Security Incident
Response Plan Review, Update, and
Communication.
DETECT
(DE)
Detection Processes (DP):
Detection Processes (DP):
Detection processes and
procedures are maintained and
tested to ensure timely and
adequate awareness of
anomalous events.
DE.DP-3: Detection processes
are tested
IR-3e IR-3j CIP-004-5.1 R2 – 2.1: Each Responsible
Entity shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, a cyber security training
program(s) appropriate to individual roles,
functions, or responsibilities that
collectively includes each of the applicable
requirement parts in CIP‐004‐5.1 Table R2
– Cyber Security Training Program.
Training content on:
2.1.1. Cyber security policies;
2.1.2. Physical access controls;
2.1.3. Electronic access controls;
2.1.4. The visitor control program;
2.1.5. Handling of BES Cyber System
Information and its storage;
2.1.6. Identification of a Cyber Security
Incident and initial notifications in
accordance with the entity’s incident
response plan;
2.1.7. Recovery plans for BES Cyber
Systems;
2.1.8. Response to Cyber Security
Incidents; and
2.1.9. Cyber security risks associated with
a BES Cyber System’s electronic
interconnectivity and interoperability with
other Cyber Assets.
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
115
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
DETECT
(DE)
Detection Processes (DP):
Detection Processes (DP):
Detection processes and
procedures are maintained and
tested to ensure timely and
adequate awareness of
anomalous events.
DE.DP-3: Detection processes
are tested
IR-3e IR-3j CIP-006-5 R3: Each Responsible Entity
shall implement one or more documented
Physical Access Control System
maintenance and testing programs that
collectively include each of the applicable
requirement parts in CIP-006-5 Table R3 –
Maintenance and Testing Program.
DETECT
(DE)
Detection Processes (DP):
Detection Processes (DP):
Detection processes and
procedures are maintained and
tested to ensure timely and
adequate awareness of
anomalous events.
DE.DP-3: Detection processes
are tested
IR-3e IR-3j
CIP-008-5 R2: Each Responsible Entity
shall implement each of its documented
Cyber Security Incident response plans to
collectively include each of the applicable
requirement parts in CIP‐008‐5 Table R2 –
Cyber Security Incident Response Plan
Implementation and Testing.
DETECT
(DE)
Detection Processes (DP):
Detection Processes (DP):
Detection processes and
procedures are maintained and
tested to ensure timely and
adequate awareness of
anomalous events.
DE.DP-4: Event detection
information is communicated to
appropriate parties
IR-1b
IR-3c
ISC-1a
ISC-1c
ISC-1d
IR-3n
ISC-1h
CIP-003-5 R1 – 1.5: Each Responsible
Entity, for its high impact and medium
impact BES Cyber Systems, shall review
and obtain CIP Senior Manager approval
at least once every 15 calendar months for
one or more documented cyber security
policies that collectively address the
following topics: Incident reporting and
response planning (CIP‐008);
DETECT
(DE)
Detection Processes (DP):
Detection Processes (DP):
Detection processes and
procedures are maintained and
tested to ensure timely and
adequate awareness of
anomalous events.
DE.DP-4: Event detection
information is communicated to
appropriate parties
IR-1b
IR-3c
ISC-1a
ISC-1c
ISC-1d
IR-3n
ISC-1h
CIP-007-5 R4: Each Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, one or more documented
processes that collectively include each of
the applicable requirement parts in CIP-
007-5 Table R4 – Security Event
Monitoring.
DETECT
(DE)
Detection Processes (DP):
Detection Processes (DP):
Detection processes and
procedures are maintained and
tested to ensure timely and
DE.DP-4: Event detection
information is communicated to
appropriate parties
IR-1b
IR-3c
ISC-1a
ISC-1c
ISC-1d
IR-3n
ISC-1h
CIP-008-5 R2: Each Responsible Entity
shall implement each of its documented
Cyber Security Incident response plans to
collectively include each of the applicable
requirement parts in CIP‐008‐5 Table R2 –
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
116
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
adequate awareness of
anomalous events.
Cyber Security Incident Response Plan
Implementation and Testing.
DETECT
(DE)
Detection Processes (DP):
Detection Processes (DP):
Detection processes and
procedures are maintained and
tested to ensure timely and
adequate awareness of
anomalous events.
DE.DP-5: Detection processes
are continuously improved
IR-3h IR-3k CIP-008-5 R2: Each Responsible Entity
shall implement each of its documented
Cyber Security Incident response plans to
collectively include each of the applicable
requirement parts in CIP‐008‐5 Table R2 –
Cyber Security Incident Response Plan
Implementation and Testing.
RESPOND
(RS)
Response Planning (RP):
Response processes and
procedures are executed and
maintained, to ensure timely
response to detected cybersecurity
events.
RS.RP-1: Response plan is
executed during or after an
event
IR-3d
CIP-008-5 R2: Each Responsible Entity
shall implement each of its documented
Cyber Security Incident response plans to
collectively include each of the applicable
requirement parts in CIP‐008‐5 Table R2 –
Cyber Security Incident Response Plan
Implementation and Testing.
RESPOND
(RS)
Communications (CO):
Response activities are
coordinated with internal and
external stakeholders, as
appropriate, to include external
support from law enforcement
agencies.
RS.CO-1: Personnel know their
roles and order of operations
when a response is needed
IR-3a IR-5a
IR-5b
CIP-004-5.1 R2 – Part 2.1.8: Each
Responsible Entity shall implement, in a
manner that identifies, assesses, and
corrects deficiencies, a cyber security
training program(s) appropriate to
individual roles, functions, or
responsibilities that collectively includes
each of the applicable requirement parts in
CIP-004-5.1 Table R2 – Cyber Security
Training Program. 2.1.8. Training content
on: Response to Cyber Security Incidents;
RESPOND
(RS)
Communications (CO):
Response activities are
coordinated with internal and
external stakeholders, as
appropriate, to include external
RS.CO-1: Personnel know their
roles and order of operations
when a response is needed
IR-3a IR-5a
IR-5b
CIP-008-5 R1: Each Responsible Entity
shall document one or more Cyber
Security Incident response plan(s) that
collectively include each of the applicable
requirement parts in CIP‐008‐5 Table R1 –
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
117
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
support from law enforcement
agencies.
Cyber Security Incident Response Plan
Specifications.
RESPOND
(RS)
Communications (CO):
Response activities are
coordinated with internal and
external stakeholders, as
appropriate, to include external
support from law enforcement
agencies.
RS.CO-1: Personnel know their
roles and order of operations
when a response is needed
IR-3a IR-5a
IR-5b
CIP-008-5 R3: Each Responsible Entity
shall maintain each of its Cyber Security
Incident response plans according to each
of the applicable requirement parts in CIP‐
008‐5 Table R3 – Cyber Security Incident
Response Plan Review, Update, and
Communication.
RESPOND
(RS)
Communications (CO):
Response activities are
coordinated with internal and
external stakeholders, as
appropriate, to include external
support from law enforcement
agencies.
RS.CO-2: Events are reported
consistent with established
criteria
IR-1a
IR-1b
CIP-003-5 R1 – 1.5: Each Responsible
Entity, for its high impact and medium
impact BES Cyber Systems, shall review
and obtain CIP Senior Manager approval
at least once every 15 calendar months for
one or more documented cyber security
policies that collectively address the
following topics: Incident reporting and
response planning (CIP‐008);
RESPOND
(RS)
Communications (CO):
Response activities are
coordinated with internal and
external stakeholders, as
appropriate, to include external
support from law enforcement
agencies.
RS.CO-2: Events are reported
consistent with established
criteria
IR-1a
IR-1b
CIP-003-5 R2 – 2.4: Each Responsible
Entity for its assets identified in CIP‐002‐5,
Requirement R1, Part R1.3, shall
implement, in a manner that identifies,
assesses, and corrects deficiencies, one
or more documented cyber security
policies that collectively address the
following topics, and review and obtain
CIP Senior Manager approval for those
policies at least once every 15 calendar
months: (An inventory, list, or discrete
identification of low impact BES Cyber
Systems or their BES Cyber Assets is not
required). Incident response to a Cyber
Security Incident.
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
118
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
RESPOND
(RS)
Communications (CO):
Response activities are
coordinated with internal and
external stakeholders, as
appropriate, to include external
support from law enforcement
agencies.
RS.CO-2: Events are reported
consistent with established
criteria
IR-1a
IR-1b
CIP-005-5 R1 – 1.5: Each Responsible
Entity shall implement one or more
documented processes that collectively
include each of the applicable requirement
parts in CIP‐005‐5 Table R1 – Electronic
Security Perimeter. Have one or more
methods for
detecting known or suspected malicious
communications for both
inbound and outbound communications.
RESPOND
(RS)
Communications (CO):
Response activities are
coordinated with internal and
external stakeholders, as
appropriate, to include external
support from law enforcement
agencies.
RS.CO-2: Events are reported
consistent with established
criteria
IR-1a
IR-1b
CIP-006-5 R1 – 1.5: Issue an alarm or alert
in response to detected unauthorized
access through a physical access point
into a Physical Security Perimeter to the
personnel identified in the BES Cyber
Security Incident response plan within 15
minutes of detection.
RESPOND
(RS)
Communications (CO):
Response activities are
coordinated with internal and
external stakeholders, as
appropriate, to include external
support from law enforcement
agencies.
RS.CO-2: Events are reported
consistent with established
criteria
IR-1a
IR-1b
CIP-006-5 R1 – 1.7: Issue an alarm or alert
in response to
detected unauthorized physical access to
a Physical Access Control System to the
personnel identified in the BES Cyber
Security Incident response plan within 15
minutes of the detection.
RESPOND
(RS)
Communications (CO):
Response activities are
coordinated with internal and
external stakeholders, as
appropriate, to include external
support from law enforcement
agencies.
RS.CO-2: Events are reported
consistent with established
criteria
IR-1a
IR-1b
CIP-007-5 R4: Each Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, one or more documented
processes that collectively include each of
the applicable requirement parts in CIP-
007-5 Table R4 – Security Event
Monitoring.
RESPOND
(RS)
Communications (CO):
Response activities are
coordinated with internal and
external stakeholders, as
appropriate, to include external
RS.CO-2: Events are reported
consistent with established
criteria
IR-1a
IR-1b
CIP-008-5 R1: Each Responsible Entity
shall document one or more Cyber
Security Incident response plan(s) that
collectively include each of the applicable
requirement parts in CIP‐008‐5 Table R1 –
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
119
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
support from law enforcement
agencies.
Cyber Security Incident Response Plan
Specifications.
RESPOND
(RS)
Communications (CO):
Response activities are
coordinated with internal and
external stakeholders, as
appropriate, to include external
support from law enforcement
agencies.
RS.CO-2: Events are reported
consistent with established
criteria
IR-1a
IR-1b
CIP-008-5 R2: Each Responsible Entity
shall implement each of its documented
Cyber Security Incident response plans to
collectively include each of the applicable
requirement parts in CIP‐008‐5 Table R2 –
Cyber Security Incident Response Plan
Implementation and Testing.
RESPOND
(RS)
Communications (CO):
Response activities are
coordinated with internal and
external stakeholders, as
appropriate, to include external
support from law enforcement
agencies.
RS.CO-2: Events are reported
consistent with established
criteria
IR-1a
IR-1b
CIP-008-5 R3: Each Responsible Entity
shall maintain each of its Cyber Security
Incident response plans according to each
of the applicable requirement parts in CIP‐
008‐5 Table R3 – Cyber Security Incident
Response Plan Review, Update, and
Communication.
RESPOND
(RS)
Communications (CO):
Response activities are
coordinated with internal and
external stakeholders, as
appropriate, to include external
support from law enforcement
agencies.
RS.CO-3: Information is shared
consistent with response plans
ISC-1a
ISC-1b
IR-3d
ISC-1c
ISC-1d
CIP-008-5 R1: Each Responsible Entity
shall document one or more Cyber
Security Incident response plan(s) that
collectively include each of the applicable
requirement parts in CIP‐008‐5 Table R1 –
Cyber Security Incident Response Plan
Specifications.
RESPOND
(RS)
Communications (CO):
Response activities are
coordinated with internal and
external stakeholders, as
appropriate, to include external
support from law enforcement
agencies.
RS.CO-3: Information is shared
consistent with response plans
ISC-1a
ISC-1b
IR-3d
ISC-1c
ISC-1d
CIP-008-5 R2: Each Responsible Entity
shall implement each of its documented
Cyber Security Incident response plans to
collectively include each of the applicable
requirement parts in CIP‐008‐5 Table R2 –
Cyber Security Incident Response Plan
Implementation and Testing.
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
120
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
RESPOND
(RS)
Communications (CO):
Response activities are
coordinated with internal and
external stakeholders, as
appropriate, to include external
support from law enforcement
agencies.
RS.CO-4: Coordination with
stakeholders occurs consistent
with response plans
IR-3d
IR-5b
CIP-003-5 R2 – 2.4: Each Responsible
Entity for its assets identified in CIP‐002‐5,
Requirement R1, Part R1.3, shall
implement, in a manner that identifies,
assesses, and corrects deficiencies, one
or more documented cyber security
policies that collectively address the
following topics, and review and obtain
CIP Senior Manager approval for those
policies at least once every 15 calendar
months: (An inventory, list, or discrete
identification of low impact BES Cyber
Systems or their BES Cyber Assets is not
required). Incident response to a Cyber
Security Incident.
RESPOND
(RS)
Communications (CO):
Response activities are
coordinated with internal and
external stakeholders, as
appropriate, to include external
support from law enforcement
agencies.
RS.CO-4: Coordination with
stakeholders occurs consistent
with response plans
IR-3d
IR-5b
CIP-008-5 R1: Each Responsible Entity
shall document one or more Cyber
Security Incident response plan(s) that
collectively include each of the applicable
requirement parts in CIP‐008‐5 Table R1 –
Cyber Security Incident Response Plan
Specifications.
RESPOND
(RS)
Communications (CO):
Response activities are
coordinated with internal and
external stakeholders, as
appropriate, to include external
support from law enforcement
agencies.
RS.CO-4: Coordination with
stakeholders occurs consistent
with response plans
IR-3d
IR-5b
CIP-008-5 R2: Each Responsible Entity
shall implement each of its documented
Cyber Security Incident response plans to
collectively include each of the applicable
requirement parts in CIP‐008‐5 Table R2 –
Cyber Security Incident Response Plan
Implementation and Testing.
RESPOND
(RS)
Communications (CO):
Response activities are
coordinated with internal and
external stakeholders, as
appropriate, to include external
support from law enforcement
agencies.
RS.CO-5: Voluntary information
sharing occurs with external
stakeholders to achieve broader
cybersecurity situational
awareness
ISC-1a
ISC-1b
IR-3c
ISC-1c
ISC-1d
ISC-1e
ISC-1f
ISC-1h
ISC-1i
ISC-1j
ISC-1k
ISC-1l
CIP-003-5 R1 – 1.5: Each Responsible
Entity, for its high impact and medium
impact BES Cyber Systems, shall review
and obtain CIP Senior Manager approval
at least once every 15 calendar months for
one or more documented cyber security
policies that collectively address the
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
121
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
following topics: Incident reporting and
response planning (CIP‐008);
RESPOND
(RS)
Communications (CO):
Response activities are
coordinated with internal and
external stakeholders, as
appropriate, to include external
support from law enforcement
agencies.
RS.CO-5: Voluntary information
sharing occurs with external
stakeholders to achieve broader
cybersecurity situational
awareness
ISC-1a
ISC-1b
IR-3c
ISC-1c
ISC-1d
ISC-1e
ISC-1f
ISC-1h
ISC-1i
ISC-1j
ISC-1k
ISC-1l
CIP-003-5 R2 – 2.4: Each Responsible
Entity for its assets identified in CIP‐002‐5,
Requirement R1, Part R1.3, shall
implement, in a manner that identifies,
assesses, and corrects deficiencies, one
or more documented cyber security
policies that collectively address the
following topics, and review and obtain
CIP Senior Manager approval for those
policies at least once every 15 calendar
months: (An inventory, list, or discrete
identification of low impact BES Cyber
Systems or their BES Cyber Assets is not
required). Incident response to a Cyber
Security Incident.
RESPOND
(RS)
Communications (CO):
Response activities are
coordinated with internal and
external stakeholders, as
appropriate, to include external
support from law enforcement
agencies.
RS.CO-5: Voluntary information
sharing occurs with external
stakeholders to achieve broader
cybersecurity situational
awareness
ISC-1a
ISC-1b
IR-3c
ISC-1c
ISC-1d
ISC-1e
ISC-1f
ISC-1h
ISC-1i
ISC-1j
ISC-1k
ISC-1l
CIP-008-5 R1: Each Responsible Entity
shall document one or more Cyber
Security Incident response plan(s) that
collectively include each of the applicable
requirement parts in CIP‐008‐5 Table R1 –
Cyber Security Incident Response Plan
Specifications.
RESPOND
(RS)
Communications (CO):
Response activities are
coordinated with internal and
external stakeholders, as
appropriate, to include external
support from law enforcement
agencies.
RS.CO-5: Voluntary information
sharing occurs with external
stakeholders to achieve broader
cybersecurity situational
awareness
ISC-1a
ISC-1b
IR-3c
ISC-1c
ISC-1d
ISC-1e
ISC-1f
ISC-1h
ISC-1i
ISC-1j
ISC-1k
ISC-1l
CIP-008-5 R2: Each Responsible Entity
shall implement each of its documented
Cyber Security Incident response plans to
collectively include each of the applicable
requirement parts in CIP‐008‐5 Table R2 –
Cyber Security Incident Response Plan
Implementation and Testing.
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
122
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
RESPOND
(RS)
Analysis (AN): Analysis is
conducted to ensure adequate
response and support recovery
activities.
RS.AN-1: Notifications from
detection systems are
investigated
IR-1e
SA-3a
IR-1f
IR-1h
CIP-003-5 R1 – 1.5: Each Responsible
Entity, for its high impact and medium
impact BES Cyber Systems, shall review
and obtain CIP Senior Manager approval
at least once every 15 calendar months for
one or more documented cyber security
policies that collectively address the
following topics: Incident reporting and
response planning (CIP‐008);
RESPOND
(RS)
Analysis (AN): Analysis is
conducted to ensure adequate
response and support recovery
activities.
RS.AN-1: Notifications from
detection systems are
investigated
IR-1e
SA-3a
IR-1f
IR-1h
CIP-003-5 R2 – 2.4: Each Responsible
Entity for its assets identified in CIP‐002‐5,
Requirement R1, Part R1.3, shall
implement, in a manner that identifies,
assesses, and corrects deficiencies, one
or more documented cyber security
policies that collectively address the
following topics, and review and obtain
CIP Senior Manager approval for those
policies at least once every 15 calendar
months: (An inventory, list, or discrete
identification of low impact BES Cyber
Systems or their BES Cyber Assets is not
required). Incident response to a Cyber
Security Incident.
RESPOND
(RS)
Analysis (AN): Analysis is
conducted to ensure adequate
response and support recovery
activities.
RS.AN-1: Notifications from
detection systems are
investigated
IR-1e
SA-3a
IR-1f
IR-1h
CIP-006-5 R1 – 1.5: Issue an alarm or alert
in response to detected unauthorized
access through a physical access point
into a Physical Security Perimeter to the
personnel identified in the BES Cyber
Security Incident response plan within 15
minutes of detection.
RESPOND
(RS)
Analysis (AN): Analysis is
conducted to ensure adequate
response and support recovery
activities.
RS.AN-1: Notifications from
detection systems are
investigated
IR-1e
SA-3a
IR-1f
IR-1h
CIP-006-5 R1 – 1.7: Issue an alarm or alert
in response to
detected unauthorized physical access to
a Physical Access Control System to the
personnel identified in the BES Cyber
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
123
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
Security Incident response plan within 15
minutes of the detection.
RESPOND
(RS)
Analysis (AN): Analysis is
conducted to ensure adequate
response and support recovery
activities.
RS.AN-1: Notifications from
detection systems are
investigated
IR-1e
SA-3a
IR-1f
IR-1h
CIP-007-5 R4: Each Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, one or more documented
processes that collectively include each of
the applicable requirement parts in CIP-
007-5 Table R4 – Security Event
Monitoring.
RESPOND
(RS)
Analysis (AN): Analysis is
conducted to ensure adequate
response and support recovery
activities.
RS.AN-1: Notifications from
detection systems are
investigated
IR-1e
SA-3a
IR-1f
IR-1h
CIP-008-5 R2: Each Responsible Entity
shall implement each of its documented
Cyber Security Incident response plans to
collectively include each of the applicable
requirement parts in CIP‐008‐5 Table R2 –
Cyber Security Incident Response Plan
Implementation and Testing.
RESPOND
(RS)
Analysis (AN): Analysis is
conducted to ensure adequate
response and support recovery
activities.
RS.AN-2: The impact of the
incident is understood
IR-2d
IR-2g
IR-2d
TVM-
1d
IR-2g
RM-2j
CIP-008-5 R2: Each Responsible Entity
shall implement each of its documented
Cyber Security Incident response plans to
collectively include each of the applicable
requirement parts in CIP‐008‐5 Table R2 –
Cyber Security Incident Response Plan
Implementation and Testing.
RESPOND
(RS)
Analysis (AN): Analysis is
conducted to ensure adequate
response and support recovery
activities.
RS.AN-3: Forensics are
performed
IR-3d IR-3i CIP-003-5 R1 – 1.5: Each Responsible
Entity, for its high impact and medium
impact BES Cyber Systems, shall review
and obtain CIP Senior Manager approval
at least once every 15 calendar months for
one or more documented cyber security
policies that collectively address the
following topics: Incident reporting and
response planning (CIP‐008);
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
124
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
RESPOND
(RS)
Analysis (AN): Analysis is
conducted to ensure adequate
response and support recovery
activities.
RS.AN-3: Forensics are
performed
IR-3d IR-3i CIP-008-5 R1: Each Responsible Entity
shall document one or more Cyber
Security Incident response plan(s) that
collectively include each of the applicable
requirement parts in CIP‐008‐5 Table R1 –
Cyber Security Incident Response Plan
Specifications.
RESPOND
(RS)
Analysis (AN): Analysis is
conducted to ensure adequate
response and support recovery
activities.
RS.AN-3: Forensics are
performed
IR-3d IR-3i CIP-008-5 R2: Each Responsible Entity
shall implement each of its documented
Cyber Security Incident response plans to
collectively include each of the applicable
requirement parts in CIP‐008‐5 Table R2 –
Cyber Security Incident Response Plan
Implementation and Testing.
RESPOND
(RS)
Analysis (AN): Analysis is
conducted to ensure adequate
response and support recovery
activities.
RS.AN-3: Forensics are
performed
IR-3d IR-3i CIP-009-5 R1 – 1.5: One or more
processes to preserve data, per Cyber
Asset capability, for determining the cause
of a Cyber Security Incident that triggers
activation of the recovery plan(s). Data
preservation should not impede or restrict
recovery.
RESPOND
(RS)
Analysis (AN): Analysis is
conducted to ensure adequate
response and support recovery
activities.
RS.AN-4: Incidents are
categorized consistent with
response plans
IR-2a IR-1d
IR-1e
IR-2d
TVM-
1d
IR-2g
RM-1c
CIP-003-5 R1 – 1.5: Each Responsible
Entity, for its high impact and medium
impact BES Cyber Systems, shall review
and obtain CIP Senior Manager approval
at least once every 15 calendar months for
one or more documented cyber security
policies that collectively address the
following topics: Incident reporting and
response planning (CIP‐008);
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
125
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
RESPOND
(RS)
Analysis (AN): Analysis is
conducted to ensure adequate
response and support recovery
activities.
RS.AN-4: Incidents are
categorized consistent with
response plans
IR-2a IR-1d
IR-1e
IR-2d
TVM-
1d
IR-2g
RM-1c
CIP-003-5 R2 – 2.4: Each Responsible
Entity for its assets identified in CIP‐002‐5,
Requirement R1, Part R1.3, shall
implement, in a manner that identifies,
assesses, and corrects deficiencies, one
or more documented cyber security
policies that collectively address the
following topics, and review and obtain
CIP Senior Manager approval for those
policies at least once every 15 calendar
months: (An inventory, list, or discrete
identification of low impact BES Cyber
Systems or their BES Cyber Assets is not
required). Incident response to a Cyber
Security Incident.
RESPOND
(RS)
Analysis (AN): Analysis is
conducted to ensure adequate
response and support recovery
activities.
RS.AN-4: Incidents are
categorized consistent with
response plans
IR-2a IR-1d
IR-1e
IR-2d
TVM-
1d
IR-2g
RM-1c
CIP-008-5 R1: Each Responsible Entity
shall document one or more Cyber
Security Incident response plan(s) that
collectively include each of the applicable
requirement parts in CIP‐008‐5 Table R1 –
Cyber Security Incident Response Plan
Specifications.
RESPOND
(RS)
Analysis (AN): Analysis is
conducted to ensure adequate
response and support recovery
activities.
RS.AN-4: Incidents are
categorized consistent with
response plans
IR-2a IR-1d
IR-1e
IR-2d
TVM-
1d
IR-2g
RM-1c
CIP-008-5 R2: Each Responsible Entity
shall implement each of its documented
Cyber Security Incident response plans to
collectively include each of the applicable
requirement parts in CIP‐008‐5 Table R2 –
Cyber Security Incident Response Plan
Implementation and Testing.
RESPOND
(RS)
Mitigation (MI): Activities are
performed to prevent expansion of
an event, mitigate its effects, and
eradicate the incident.
RS.MI-1: Incidents are
contained
IR-3b CIP-003-5 R1 – 1.5: Each Responsible
Entity, for its high impact and medium
impact BES Cyber Systems, shall review
and obtain CIP Senior Manager approval
at least once every 15 calendar months for
one or more documented cyber security
policies that collectively address the
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
126
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
following topics: Incident reporting and
response planning (CIP‐008);
RESPOND
(RS)
Mitigation (MI): Activities are
performed to prevent expansion of
an event, mitigate its effects, and
eradicate the incident.
RS.MI-1: Incidents are
contained
IR-3b CIP-003-5 R1 – 1.9: Each Responsible
Entity, for its high impact and medium
impact BES Cyber Systems, shall review
and obtain CIP Senior Manager approval
at least once every 15 calendar months for
one or more documented cyber security
policies that collectively address the
following topics: Declaring and responding
to CIP Exceptional Circumstances.
RESPOND
(RS)
Mitigation (MI): Activities are
performed to prevent expansion of
an event, mitigate its effects, and
eradicate the incident.
RS.MI-1: Incidents are
contained
IR-3b CIP-003-5 R2 – 2.4: Each Responsible
Entity for its assets identified in CIP‐002‐5,
Requirement R1, Part R1.3, shall
implement, in a manner that identifies,
assesses, and corrects deficiencies, one
or more documented cyber security
policies that collectively address the
following topics, and review and obtain
CIP Senior Manager approval for those
policies at least once every 15 calendar
months: (An inventory, list, or discrete
identification of low impact BES Cyber
Systems or their BES Cyber Assets is not
required). Incident response to a Cyber
Security Incident.
RESPOND
(RS)
Mitigation (MI): Activities are
performed to prevent expansion of
an event, mitigate its effects, and
eradicate the incident.
RS.MI-1: Incidents are
contained
IR-3b CIP-005-5 R1 – 1.5: Each Responsible
Entity shall implement one or more
documented processes that collectively
include each of the applicable requirement
parts in CIP‐005‐5 Table R1 – Electronic
Security Perimeter. Have one or more
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
127
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
methods for
detecting known or suspected malicious
communications for both
inbound and outbound communications.
RESPOND
(RS)
Mitigation (MI): Activities are
performed to prevent expansion of
an event, mitigate its effects, and
eradicate the incident.
RS.MI-1: Incidents are
contained
IR-3b CIP-006-5 R1 – 1.5: Issue an alarm or alert
in response to detected unauthorized
access through a physical access point
into a Physical Security Perimeter to the
personnel identified in the BES Cyber
Security Incident response plan within 15
minutes of detection.
RESPOND
(RS)
Mitigation (MI): Activities are
performed to prevent expansion of
an event, mitigate its effects, and
eradicate the incident.
RS.MI-1: Incidents are
contained
IR-3b CIP-006-5 R1 – 1.7: Issue an alarm or alert
in response to
detected unauthorized physical access to
a Physical Access Control System to the
personnel identified in the BES Cyber
Security Incident response plan within 15
minutes of the detection.
RESPOND
(RS)
Mitigation (MI): Activities are
performed to prevent expansion of
an event, mitigate its effects, and
eradicate the incident.
RS.MI-1: Incidents are
contained
IR-3b CIP-007-5 R3: Each Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, one or more documented
processes that collectively include each of
the applicable requirement parts in CIP-
007-5 Table R3 – Malicious Code
Prevention.
RESPOND
(RS)
Mitigation (MI): Activities are
performed to prevent expansion of
an event, mitigate its effects, and
eradicate the incident.
RS.MI-1: Incidents are
contained
IR-3b CIP-007-5 R4: Each Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, one or more documented
processes that collectively include each of
the applicable requirement parts in CIP-
007-5 Table R4 – Security Event
Monitoring.
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
128
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
RESPOND
(RS)
Mitigation (MI): Activities are
performed to prevent expansion of
an event, mitigate its effects, and
eradicate the incident.
RS.MI-1: Incidents are
contained
IR-3b CIP-008-5 R2: Each Responsible Entity
shall implement each of its documented
Cyber Security Incident response plans to
collectively include each of the applicable
requirement parts in CIP‐008‐5 Table R2 –
Cyber Security Incident Response Plan
Implementation and Testing.
RESPOND
(RS)
Mitigation (MI): Activities are
performed to prevent expansion of
an event, mitigate its effects, and
eradicate the incident.
RS.MI-2: Incidents are
mitigated
IR-3b CIP-003-5 R1 – 1.5: Each Responsible
Entity, for its high impact and medium
impact BES Cyber Systems, shall review
and obtain CIP Senior Manager approval
at least once every 15 calendar months for
one or more documented cyber security
policies that collectively address the
following topics: Incident reporting and
response planning (CIP‐008);
RESPOND
(RS)
Mitigation (MI): Activities are
performed to prevent expansion of
an event, mitigate its effects, and
eradicate the incident.
RS.MI-2: Incidents are
mitigated
IR-3b CIP-003-5 R1 – 1.9: Each Responsible
Entity, for its high impact and medium
impact BES Cyber Systems, shall review
and obtain CIP Senior Manager approval
at least once every 15 calendar months for
one or more documented cyber security
policies that collectively address the
following topics: Declaring and responding
to CIP Exceptional Circumstances.
RESPOND
(RS)
Mitigation (MI): Activities are
performed to prevent expansion of
an event, mitigate its effects, and
eradicate the incident.
RS.MI-2: Incidents are
mitigated
IR-3b CIP-003-5 R2 – 2.4: Each Responsible
Entity for its assets identified in CIP‐002‐5,
Requirement R1, Part R1.3, shall
implement, in a manner that identifies,
assesses, and corrects deficiencies, one
or more documented cyber security
policies that collectively address the
following topics, and review and obtain
CIP Senior Manager approval for those
policies at least once every 15 calendar
months: (An inventory, list, or discrete
identification of low impact BES Cyber
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
129
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
Systems or their BES Cyber Assets is not
required). Incident response to a Cyber
Security Incident.
RESPOND
(RS)
Mitigation (MI): Activities are
performed to prevent expansion of
an event, mitigate its effects, and
eradicate the incident.
RS.MI-2: Incidents are
mitigated
IR-3b CIP-005-5 R1 – 1.5: Each Responsible
Entity shall implement one or more
documented processes that collectively
include each of the applicable requirement
parts in CIP‐005‐5 Table R1 – Electronic
Security Perimeter. Have one or more
methods for
detecting known or suspected malicious
communications for both
inbound and outbound communications.
RESPOND
(RS)
Mitigation (MI): Activities are
performed to prevent expansion of
an event, mitigate its effects, and
eradicate the incident.
RS.MI-2: Incidents are
mitigated
IR-3b CIP-006-5 R1 – 1.5: Issue an alarm or alert
in response to detected unauthorized
access through a physical access point
into a Physical Security Perimeter to the
personnel identified in the BES Cyber
Security Incident response plan within 15
minutes of detection.
RESPOND
(RS)
Mitigation (MI): Activities are
performed to prevent expansion of
an event, mitigate its effects, and
eradicate the incident.
RS.MI-2: Incidents are
mitigated
IR-3b CIP-006-5 R1 – 1.7: Issue an alarm or alert
in response to
detected unauthorized physical access to
a Physical Access Control System to the
personnel identified in the BES Cyber
Security Incident response plan within 15
minutes of the detection.
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
130
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
RESPOND
(RS)
Mitigation (MI): Activities are
performed to prevent expansion of
an event, mitigate its effects, and
eradicate the incident.
RS.MI-2: Incidents are
mitigated
IR-3b CIP-007-5 R3: Each Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, one or more documented
processes that collectively include each of
the applicable requirement parts in CIP-
007-5 Table R3 – Malicious Code
Prevention.
RESPOND
(RS)
Mitigation (MI): Activities are
performed to prevent expansion of
an event, mitigate its effects, and
eradicate the incident.
RS.MI-2: Incidents are
mitigated
IR-3b CIP-007-5 R4: Each Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, one or more documented
processes that collectively include each of
the applicable requirement parts in CIP-
007-5 Table R4 – Security Event
Monitoring.
RESPOND
(RS)
Mitigation (MI): Activities are
performed to prevent expansion of
an event, mitigate its effects, and
eradicate the incident.
RS.MI-2: Incidents are
mitigated
IR-3b CIP-008-5 R2: Each Responsible Entity
shall implement each of its documented
Cyber Security Incident response plans to
collectively include each of the applicable
requirement parts in CIP‐008‐5 Table R2 –
Cyber Security Incident Response Plan
Implementation and Testing.
RESPOND
(RS)
Mitigation (MI): Activities are
performed to prevent expansion of
an event, mitigate its effects, and
eradicate the incident.
RS.MI-3: Newly identified
vulnerabilities are mitigated or
documented as accepted risks
TVM-
2c
TVM-
2f
TVM-
2g
RM-2j
TVM-
2m
TVM-
2n
CIP-003-5 R1 – 1.7: Each Responsible
Entity, for its high impact and medium
impact BES Cyber Systems, shall review
and obtain CIP Senior Manager approval
at least once every 15 calendar months for
one or more documented cyber security
policies that collectively address the
following topics: Configuration change
management and vulnerability
assessments (CIP‐010);
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
131
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
RESPOND
(RS)
Mitigation (MI): Activities are
performed to prevent expansion of
an event, mitigate its effects, and
eradicate the incident.
RS.MI-3: Newly identified
vulnerabilities are mitigated or
documented as accepted risks
TVM-
2c
TVM-
2f
TVM-
2g
RM-2j
TVM-
2m
TVM-
2n
CIP-007-5 R2: Each Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, one or more documented
processes that collectively include each of
the applicable requirement parts in CIP-
007-5 Table R2 – Security Patch
Management.
RESPOND
(RS)
Mitigation (MI): Activities are
performed to prevent expansion of
an event, mitigate its effects, and
eradicate the incident.
RS.MI-3: Newly identified
vulnerabilities are mitigated or
documented as accepted risks
TVM-
2c
TVM-
2f
TVM-
2g
RM-2j
TVM-
2m
TVM-
2n
CIP-007-5 R3: Each Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, one or more documented
processes that collectively include each of
the applicable requirement parts in CIP-
007-5 Table R3 – Malicious Code
Prevention.
RESPOND
(RS)
Mitigation (MI): Activities are
performed to prevent expansion of
an event, mitigate its effects, and
eradicate the incident.
RS.MI-3: Newly identified
vulnerabilities are mitigated or
documented as accepted risks
TVM-
2c
TVM-
2f
TVM-
2g
RM-2j
TVM-
2m
TVM-
2n
CIP-010-1 R3: Each Responsible Entity
shall implement one or more documented
processes that collectively include each of
the applicable requirement parts in CIP ‐
010 ‐ 1 Table R3– Vulnerability
Assessments.
RESPOND
(RS)
Improvements (IM):
Organizational response activities
are improved by incorporating
lessons learned from current and
previous detection/response
activities.
RS.IM-1: Response plans
incorporate lessons learned
IR-3h CIP-003-5 R1 – 1.5: Each Responsible
Entity, for its high impact and medium
impact BES Cyber Systems, shall review
and obtain CIP Senior Manager approval
at least once every 15 calendar months for
one or more documented cyber security
policies that collectively address the
following topics: Incident reporting and
response planning (CIP‐008);
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
132
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
RESPOND
(RS)
Improvements (IM):
Organizational response activities
are improved by incorporating
lessons learned from current and
previous detection/response
activities.
RS.IM-1: Response plans
incorporate lessons learned
IR-3h CIP-003-5 R2 – 2.4: Each Responsible
Entity for its assets identified in CIP‐002‐5,
Requirement R1, Part R1.3, shall
implement, in a manner that identifies,
assesses, and corrects deficiencies, one
or more documented cyber security
policies that collectively address the
following topics, and review and obtain
CIP Senior Manager approval for those
policies at least once every 15 calendar
months: (An inventory, list, or discrete
identification of low impact BES Cyber
Systems or their BES Cyber Assets is not
required). Incident response to a Cyber
Security Incident.
RESPOND
(RS)
Improvements (IM):
Organizational response activities
are improved by incorporating
lessons learned from current and
previous detection/response
activities.
RS.IM-1: Response plans
incorporate lessons learned
IR-3h CIP-008-5 R2: Each Responsible Entity
shall implement each of its documented
Cyber Security Incident response plans to
collectively include each of the applicable
requirement parts in CIP‐008‐5 Table R2 –
Cyber Security Incident Response Plan
Implementation and Testing.
RESPOND
(RS)
Improvements (IM):
Organizational response activities
are improved by incorporating
lessons learned from current and
previous detection/response
activities.
RS.IM-1: Response plans
incorporate lessons learned
IR-3h CIP-008-5 R3: Each Responsible Entity
shall maintain each of its Cyber Security
Incident response plans according to each
of the applicable requirement parts in CIP‐
008‐5 Table R3 – Cyber Security Incident
Response Plan Review, Update, and
Communication.
RESPOND
(RS)
Improvements (IM):
Organizational response activities
are improved by incorporating
lessons learned from current and
previous detection/response
activities.
RS.IM-2: Response strategies
are updated
IR-3e IR-3k CIP-003-5 R1 – 1.5: Each Responsible
Entity, for its high impact and medium
impact BES Cyber Systems, shall review
and obtain CIP Senior Manager approval
at least once every 15 calendar months for
one or more documented cyber security
policies that collectively address the
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
133
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
following topics: Incident reporting and
response planning (CIP‐008);
RESPOND
(RS)
Improvements (IM):
Organizational response activities
are improved by incorporating
lessons learned from current and
previous detection/response
activities.
RS.IM-2: Response strategies
are updated
IR-3e IR-3k CIP-003-5 R2 – 2.4: Each Responsible
Entity for its assets identified in CIP‐002‐5,
Requirement R1, Part R1.3, shall
implement, in a manner that identifies,
assesses, and corrects deficiencies, one
or more documented cyber security
policies that collectively address the
following topics, and review and obtain
CIP Senior Manager approval for those
policies at least once every 15 calendar
months: (An inventory, list, or discrete
identification of low impact BES Cyber
Systems or their BES Cyber Assets is not
required). Incident response to a Cyber
Security Incident.
RESPOND
(RS)
Improvements (IM):
Organizational response activities
are improved by incorporating
lessons learned from current and
previous detection/response
activities.
RS.IM-2: Response strategies
are updated
IR-3e IR-3k CIP-008-5 R1: Each Responsible Entity
shall document one or more Cyber
Security Incident response plan(s) that
collectively include each of the applicable
requirement parts in CIP‐008‐5 Table R1 –
Cyber Security Incident Response Plan
Specifications.
RESPOND
(RS)
Improvements (IM):
Organizational response activities
are improved by incorporating
lessons learned from current and
previous detection/response
activities.
RS.IM-2: Response strategies
are updated
IR-3e IR-3k CIP-008-5 R2: Each Responsible Entity
shall implement each of its documented
Cyber Security Incident response plans to
collectively include each of the applicable
requirement parts in CIP‐008‐5 Table R2 –
Cyber Security Incident Response Plan
Implementation and Testing.
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
134
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
RESPOND
(RS)
Improvements (IM):
Organizational response activities
are improved by incorporating
lessons learned from current and
previous detection/response
activities.
RS.IM-2: Response strategies
are updated
IR-3e IR-3k CIP-008-5 R3: Each Responsible Entity
shall maintain each of its Cyber Security
Incident response plans according to each
of the applicable requirement parts in CIP‐
008‐5 Table R3 – Cyber Security Incident
Response Plan Review, Update, and
Communication.
RECOVER
(RC)
Recovery Planning (RP):
Recovery processes and
procedures are executed and
maintained to ensure timely
restoration of systems or assets
affected by cybersecurity events.
RC.RP-1: Recovery plan is
executed during or after an
event
IR-3b IR-3o
IR-4k
CIP-003-5 R1 – 1.5: Each Responsible
Entity, for its high impact and medium
impact BES Cyber Systems, shall review
and obtain CIP Senior Manager approval
at least once every 15 calendar months for
one or more documented cyber security
policies that collectively address the
following topics: Incident reporting and
response planning (CIP‐008);
RECOVER
(RC)
Recovery Planning (RP):
Recovery processes and
procedures are executed and
maintained to ensure timely
restoration of systems or assets
affected by cybersecurity events.
RC.RP-1: Recovery plan is
executed during or after an
event
IR-3b IR-3o
IR-4k
CIP-003-5 R1 – 1.6: Each Responsible
Entity, for its high impact and medium
impact BES Cyber Systems, shall review
and obtain CIP Senior Manager approval
at least once every 15 calendar months for
one or more documented cyber security
policies that collectively address the
following topics: Recovery plans for BES
Cyber Systems (CIP‐009);
RECOVER
(RC)
Recovery Planning (RP):
Recovery processes and
procedures are executed and
maintained to ensure timely
restoration of systems or assets
affected by cybersecurity events.
RC.RP-1: Recovery plan is
executed during or after an
event
IR-3b IR-3o
IR-4k
CIP-007-5 R4: Each Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, one or more documented
processes that collectively include each of
the applicable requirement parts in CIP-
007-5 Table R4 – Security Event
Monitoring.
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
135
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
RECOVER
(RC)
Recovery Planning (RP):
Recovery processes and
procedures are executed and
maintained to ensure timely
restoration of systems or assets
affected by cybersecurity events.
RC.RP-1: Recovery plan is
executed during or after an
event
IR-3b IR-3o
IR-4k
CIP-009-5 R1: Each Responsible Entity
shall have one or more documented
recovery plans that collectively include
each of the applicable requirement parts in
CIP‐009‐5 Table R1 – Recovery Plan
Specifications.
RECOVER
(RC)
Recovery Planning (RP):
Recovery processes and
procedures are executed and
maintained to ensure timely
restoration of systems or assets
affected by cybersecurity events.
RC.RP-1: Recovery plan is
executed during or after an
event
IR-3b IR-3o
IR-4k
CIP-009-5 R2: Each Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, its documented recovery
plan(s) to collectively include each of the
applicable requirement parts in CIP‐009‐5
Table R2 – Recovery Plan Implementation
and Testing
RECOVER
(RC)
Recovery Planning (RP):
Recovery processes and
procedures are executed and
maintained to ensure timely
restoration of systems or assets
affected by cybersecurity events.
RC.RP-1: Recovery plan is
executed during or after an
event
IR-3b IR-3o
IR-4k
CIP-009-5 R3: Each Responsible Entity
shall maintain each of its recovery plans in
accordance with each of the applicable
requirement parts in CIP‐009‐5 Table R3 –
Recovery Plan Review, Update and
Communication.
RECOVER
(RC)
Improvements (IM):
Improvements (IM): Recovery
planning and processes are
improved by incorporating lessons
learned into future activities.
RC.IM-1: Recovery plans
incorporate lessons learned
IR-3h
IR-4i
IR-3k
CIP-003-5 R1 – 1.6: Each Responsible
Entity, for its high impact and medium
impact BES Cyber Systems, shall review
and obtain CIP Senior Manager approval
at least once every 15 calendar months for
one or more documented cyber security
policies that collectively address the
following topics: Recovery plans for BES
Cyber Systems (CIP‐009);
RECOVER
(RC)
Improvements (IM):
Improvements (IM): Recovery
planning and processes are
improved by incorporating lessons
learned into future activities.
RC.IM-1: Recovery plans
incorporate lessons learned
IR-3h
IR-4i
IR-3k
CIP-009-5 R3: Each Responsible Entity
shall maintain each of its recovery plans in
accordance with each of the applicable
requirement parts in CIP‐009‐5 Table R3 –
Recovery Plan Review, Update and
Communication.
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
136
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
RECOVER
(RC)
Improvements (IM):
Improvements (IM): Recovery
planning and processes are
improved by incorporating lessons
learned into future activities.
RC.IM-2: Recovery strategies
are updated
IR-3h
IR-3k
CIP-003-5 R1 – 1.6: Each Responsible
Entity, for its high impact and medium
impact BES Cyber Systems, shall review
and obtain CIP Senior Manager approval
at least once every 15 calendar months for
one or more documented cyber security
policies that collectively address the
following topics: Recovery plans for BES
Cyber Systems (CIP‐009);
RECOVER
(RC)
Improvements (IM):
Improvements (IM): Recovery
planning and processes are
improved by incorporating lessons
learned into future activities.
RC.IM-2: Recovery strategies
are updated
IR-3h
IR-3k
CIP-009-5 R3: Each Responsible Entity
shall maintain each of its recovery plans in
accordance with each of the applicable
requirement parts in CIP‐009‐5 Table R3 –
Recovery Plan Review, Update and
Communication.
RECOVER
(RC)
Communications (CO):
Restoration activities are
coordinated with internal and
external parties, such as
coordinating centers, Internet
Service Providers, owners of
attacking systems, victims, other
CSIRTs, and vendors.
RC.CO-1: Public Relations are
managed
TVM-
1d
IR-4d
RM-1c
RECOVER
(RC)
Communications (CO):
Restoration activities are
coordinated with internal and
external parties, such as
coordinating centers, Internet
Service Providers, owners of
attacking systems, victims, other
CSIRTs, and vendors.
RC.CO-2: Reputation after an
event is repaired
IR-4d
NIST TN 2051 CYBERSECURITY FRAMEWORK
SMART GRID PROFILE
137
This publication is available free of charge from
: https://doi.org/10.6028/N
IS
T.TN
.2051
Mapping of NIST Cybersecurity Framework v1.0 to NERC CIP version 5 & C2M2 Practices
Function Category Subcategory
C2M2 Practices **
NERC CIP v5
MIL 1 MIL 2 MIL 3
RECOVER
(RC)
Communications (CO):
Restoration activities are
coordinated with internal and
external parties, such as
coordinating centers, Internet
Service Providers, owners of
attacking systems, victims, other
CSIRTs, and vendors.
RC.CO-3: Recovery activities
are communicated to internal
stakeholders and executive and
management teams
IR-3d IR-5e CIP-003-5 R1 – 1.6: Each Responsible
Entity, for its high impact and medium
impact BES Cyber Systems, shall review
and obtain CIP Senior Manager approval
at least once every 15 calendar months for
one or more documented cyber security
policies that collectively address the
following topics: Recovery plans for BES
Cyber Systems (CIP‐009);
RECOVER
(RC)
Communications (CO):
Restoration activities are
coordinated with internal and
external parties, such as
coordinating centers, Internet
Service Providers, owners of
attacking systems, victims, other
CSIRTs, and vendors.
RC.CO-3: Recovery activities
are communicated to internal
stakeholders and executive and
management teams
IR-3d IR-5e CIP-009-5 R1: Each Responsible Entity
shall have one or more documented
recovery plans that collectively include
each of the applicable requirement parts in
CIP‐009‐5 Table R1 – Recovery Plan
Specifications.
RECOVER
(RC)
Communications (CO):
Restoration activities are
coordinated with internal and
external parties, such as
coordinating centers, Internet
Service Providers, owners of
attacking systems, victims, other
CSIRTs, and vendors.
RC.CO-3: Recovery activities
are communicated to internal
stakeholders and executive and
management teams
IR-3d IR-5e CIP-009-5 R2: Each Responsible Entity
shall implement, in a manner that
identifies, assesses, and corrects
deficiencies, its documented recovery
plan(s) to collectively include each of the
applicable requirement parts in CIP‐009‐5
Table R2 – Recovery Plan Implementation
and Testing.
RECOVER
(RC)
Communications (CO):
Restoration activities are
coordinated with internal and
external parties, such as
coordinating centers, Internet
Service Providers, owners of
attacking systems, victims, other
CSIRTs, and vendors.
RC.CO-3: Recovery activities
are communicated to internal
stakeholders and executive and
management teams
IR-3d IR-5e CIP-009-5 R3: Each Responsible Entity
shall maintain each of its recovery plans in
accordance with each of the applicable
requirement parts in CIP‐009‐5 Table R3 –
Recovery Plan Review, Update and
Communication.
- 1. Executive Summary
- 2. Importance of Cybersecurity in the Smart Grid
- 3. Overview of the Cybersecurity Framework
- 4. Smart Grid Profile
- 5. Smart Grid Business/Mission Objectives
- 6. Future Work
References
Appendix A: Acronyms
Appendix B: NERC CIP v5 to Cybersecurity Framework v1.0 Mapping
Anatomy of a Cyber Attack
The Lifecycle of a Security Breach
O R A C L E W H I T E P A P E R | D E C E M B E R 2 0 1 7
1
Table of Content
Introduction
2
We are at War 2
No one is immune
3
Typical Attack Vectors 3
Not Just a Single Attack Vector
4
Looking to the Future 4
Anatomy of a Typical Attack
5
Reconnaissance 5
Enumeration 5
Penetration 5
Exfiltration
6
Sanitation 6
Defending Your Data Center 6
Conclusion 7
2
Introduction
Security is everyone’s job today, from consumers, to system administrators, to executives. If you are doing
business, you need to elevate the priority of security across your organization and data center. Over the years,
cybercriminals have gotten more advanced and better funded. They are entire teams of highly trained hackers, and
they have built it into a very profitable business. Cybercrime is big business. In many cases, states have built their
own cyberattack teams. These teams are no less important to their state strategies than their army or navy. And just
like these cyber-attack teams are prepared to attack anyone, you too must be prepared to defend against anyone.
Whether you know it or not, you are in a cyber war.
You need to be prepared.
We are at War
Cybercrime is the new buzzword. Hackers have become highly sophisticated and organized. They have become the
new Mafia, and they are running it like an industry.
According to Breach Level Index database,1 1,792 data breaches were reported in 2016 resulting in theft of around
1.3 billion data records. Just to clarify, these are the data breaches publicly reported and don’t include thousands of
cyber-attack incidents and undiscovered data breaches.
Here are some examples of how hackers have industrialized cybercrime:2
You can get someone’s complete health insurance data by paying $1,250.
For just $7/hour, you can unleash a Distributed Denial of Service attack on your competition.
You can purchase US Fulz records (someone’s identity, passport, SSN, and others). You can get all that
for around $40.
You can also get 10,000 fake Twitter followers for $15.
And if you want access to a government server, that can be had for $6.
You’re dealing with professional organizations that:
Provide 24/7 customer service;
Offer free trial attacks to demonstrate their prowess;
Payment after the successful attack once you are satisfied with the results.
The cost of cybercrime in 2016 is estimated to be around $445 billion, and it is predicted to increase to around $2
Trillion globally by 2019.3
These estimates only include known attacks, not undetected cybercrime, industrial espionage, or state-sponsored
attacks.
1 http://breachlevelindex.com/assets/Breach-Level-Index-Report-2016-Gemalto
2 http://www.havocscope.com/black-market-prices/hackers/
3 http://www.forbes.com/sites/stevemorgan/2016/01/17/cyber-crime-costs-projected-to-reach-2-trillion-by-
2019/#4af445823bb0
3
No one is immune
In 2016, approximately 35% of all attacks occurred against the healthcare industry.4 In the past financial services
have been the biggest target. However, the financial services industry has gotten smarter and has hardened itself. In
2016, the most common type of incident was phishing/hacking/malware at 43%. It was the largest type of
attack/incident in all sectors, except financial services.5 Today, all business sectors must assume that they are at
risk.
Even small companies can’t assume they are safe. In 2016, 39% of all cyber-attacks occurred against companies
with less than $100 million in revenue and an additional 33% occurred against companies that have revenue
between $100 million and $500 million.
Ransomware is on the rise. In 2016, ransomware attacks rose 500%. It is to the point where it is being
recommended as good practice to keep a bitcoin wallet to pay off the ransomware attackers. However, there is no
guaranteeing that the attackers won’t take the money and lose the encryption key.
Typical Attack Vectors
Generally, cyberattacks fall into just a handful of attack vectors. As we’ve said, social engineering attacks (i.e.
phishing, hacking and malware) make up the largest single attack vector at 43%. Of course, vulnerability exploitation
(exploiting a bug in software or firmware that hasn’t been patched) is still a common attack vector. Typical examples
of these in recent history include such widespread attacks as Heartbleed, ShellShock, and DirtyCOW. Stolen
credentials are often used to gain access to systems, and then from there gain access to higher privileged
credentials that eventually lead to the data the attacker is after. This was used in an insurance company breach in
2014. Login credentials were obtained and then used to gain access to higher privileged systems in the datacenter,
4 https://www.databreaches.net/bakerhostetler-2017-data-security-incident-response-report-based-on-450-incidents/
5 https://www.databreaches.net/bakerhostetler-2017-data-security-incident-response-report-based-on-450-incidents/
35%
Healthcare
9%
Other
16%
Financial Services
8%
Professional
Services
14%
Education
13%
Retail
5%
Government
4
which was then used to steal 80 million Social Security numbers.6 Another recent attack of a financial services
company left 143 million Social Security numbers exposed.
7
Malware/ransomware implant themselves into vulnerable systems and then spread across connected networks. The
worst example of this most recently was the WannaCrypt exploit that infected systems on a network without any
action taken by anyone on the network. Finally, there are Denial of Service attacks and Distributed Denial of Service
attacks (DoS and DDoS). With these attacks a person, group, organization or enterprise is prevented from doing
business by flooding their websites and services with artificial network traffic either from within their network or from
outside their network. An example of a particularly bad DDoS attack was the Dyn DDoS attack. Dyn, one of the
largest name service providers on the Internet, was attacked by the Mirai botnet (a type of software robot that infests
a device and then awaits orders) via 10’s of millions of Wifi-based “smart” devices around the world that had been
infected.
Not Just a Single Attack Vector
If you dig into any of the examples mentioned above, you’ll notice something they all have in common. They don’t
rely on one attack vector. In fact, combinations of the above attack vectors are combined together to build the most
effective attack possible. For example, with the Dyn attack, a combination of stolen credentials and malware were
used.
How did they do it? The attackers got the system administrator password (known as “root” password in UNIX and
Linux) for the operating system that was being flashed into 10’s of millions of Wifi-based smart devices (e.g. security
cameras, light systems, baby monitors, etc.). The password was the same for every single device being put out by a
single manufacturer. They were then able to gain access to these devices and install the Mirai botnet malware.
When instructed, these devices would then send traffic to the targeted company/datacenter. This caused the
datacenter to be flooded with traffic, exceeding its capacity, and effectively taking it offline for a couple of hours while
Dyn engineers worked to mitigate the attack. The attackers tried again a few hours later. This time it was more than
just one datacenter. Dyn countered this second attack more quickly, and a third attack failed completely.8 While Dyn
was quick to counter the threat, and was successively more effective at mitigating the attacks, the impact was that
dozens of the Internet’s largest websites couldn’t be accessed by many of their users effectively taking the sites
offline.9
Looking to the Future
As technologies such as IOT and cloud gain market acceptance, they accelerate the growth of the number of users,
devices and machines, network traffic and data. This will lead to more attack vectors, more infected devices, larger
attacks and a significant increase in the amount of data stolen. New attack vectors like cloud jail-breaking will rise in
use. Cloud jail-breaking is when an attacker legitimately or illegitimately gains access to a virtual machine in a cloud
environment and uses that environment to break into or snoop on neighboring virtual machines, or utilizes the virtual
machine to gain access to the underlying infrastructure. This potentially gives them access to all the infrastructure
and access to all virtual machines in the cloud.
All of this leads us to the conclusion that we are at war.
You need to make cybersecurity and defenses your top strategic concern.
6 https://krebsonsecurity.com/tag/wellpoint-breach/
7 https://www.consumer.ftc.gov/blog/2017/09/equifax-data-breach-what-do
8 https://dyn.com/blog/dyn-statement-on-10212016-ddos-attack/
9 https://en.wikipedia.org/wiki/2016_Dyn_cyberattack
5
Anatomy of a Typical Attack
Let’s look at how a typical attack plays out. We’re going walk through a theoretical attack and use a real-world
example of an attack to show you how the theory is executed in reality.
Reconnaissance
Every attacker will start by trying to understand your business to gain as much detailed information as possible
about your organization and network, as well as identify online behavior of system administrators and other key
employees. The employee names and positions are found simply enough through common searches such as a
search for “system administrator” on social networking sites like LinkedIn.
This gives a wealth of knowledge about people quickly and even access to contacting them directly.
Once the targets are identified, the attacker moves on to the next step.
Enumeration
Once the attacker has sufficient information, they trick your administrators into exposing sensitive information or
downloading malicious software.
There are many ways that this could be done. An email could be sent to the employees that looks official asking
them to take some action such as downloading a new tool, or changing a password on a website.
In the case of one large insurance provider, an email was sent to employees that looked like an official email, asking
them to click on a link. The link looked legitimate. However, it was actually not a link to their site, but to a site that
had a similar looking name. This technique is known as typosquatting, and it is a type of spear-phishing that takes
advantage of the fact that our brains pattern match and make quick assessments. The websites look similar enough
that unless you look carefully at it, it makes the link look legitimate. This particular attack was more sophisticated.
The attackers built an entire website made to look like the target site and prompted victims to login, giving the
attackers access to their login credentials. It included a spoofed VPN service that allowed the attackers to gain VPN
level access to the corporate network. And it prompted the victims to download software/malware that infected the
user’s systems, giving them inside access to the network.
The attack managed to successfully spear five technology employees, including a system administrator, and gain
access to the entire IT system of the corporation.
Penetration
Once they have gained the access to your network, the attacker now looks to penetrate your network and systems.
This can come in many forms. Malware or ransomware could log keystrokes, waiting for you to type in a password,
or it could become a worm that looks for vulnerable systems and begins to spread throughout your network. If the
6
attacker gained access through user credentials, they can plant a worm and leave. They intend to keep the attack
going for as long as possible. This can be for months or even years.
They are looking for your data. It may be that they want Personally Identifiable Information (PII) or they may want
your business data. Either way, their next step will be to look for vulnerable credential servers like your Active
Directory servers. Exploiting your credential servers gives them broader access to your network and services.
Then they establish “Command and Control”. Once in your network, they will attempt to take control of your network.
The attacker will surreptitiously hijack as many of your systems as possible. This will give them the ability to control
as much of your network as possible and give them high availability of their attack. Once they’ve established a
foothold, they can then send requests back to a command server and begin to act on the commands given.
At this point, they begin their data collection. This may include your credentials from your credential servers, emails,
and business data, PII, or transaction data from your databases.
Exfiltration
Of course, the point of all this effort, if it isn’t to actively destroy your network, is to get your data out of your network
and back to the attackers. So the next step is to send that data back to them.
They’ll likely encrypt the data to prevent your Intrusion Detection Systems (IDS) and Intrusion Prevention Systems
(IPS) from detecting and/or blocking the data from being exfiltrated out of your datacenters. They use your own
servers to prevent detection.
Your data will be sent via one or more anonymizing routers throughout the Internet so that you can’t track where the
data is going.
Sanitation
This is the last step in the process. The attackers will remove all evidence that they were in your network and
systems. This is to make a clean getaway but also allowing them to come back in next week, month, or year and
attack you again.
Defending Your Data Center
You must do more than protect your network to defend your data center. Defense in depth, or building layers of
protection, is a must. There are three Pillars of Protection” that support each layer and assist in making your data
center secure. These are “People”, “Platform” and “Data.”
The first pillar is people. People are the Achilles’ Heel of Cybersecurity.10 People have been and continue to be the
single largest source of cybersecurity incidents. While, some may be “bad actors”, generally, they cause incidents by
making simple mistakes that result in exposure to cyberattack or information leaks.
The second pillar of protection is the platform. This is the physical and virtual machines in your datacenter or your
virtual machines in the cloud. While people are the root cause for the plurality of incidents, vulnerable systems are
still a large portion of successful attacks. Hackers are quick to exploit vulnerabilities. If your systems aren’t patched
or patched quickly enough you are exposed. A survey of Oracle customers showed that 74% of organizations take
more than three months (could be one year, five years, or never) to patch their systems.
10 http://www.pwc.com/gx/en/issues/cyber-security/information-security-survey/assets/gsiss-report-internet-of-things
7
The third pillar is your data. You must protect your data. In 2016, the average cost per record of data stolen was
$158.11 The cost per record by industry ranged from $88/record for government (public sector data) to $355 per
record in the healthcare industry. The means that the cost of stolen data to the healthcare industry in 2016 was over
$325,000 per minute.12
In our next white paper, “Pillars of Protection: A New View of Enterprise Security,” we’ll address the pillars and the
unique advantages Oracle Linux provides in assisting you in protecting all three pillars in your data center.
Conclusion
We are at war with cybercriminals. You need to make cybersecurity and defenses your top strategic concern.
Defending your datacenter is crucial for the survival of your business. Ask your Oracle representative about the
Oracle Linux Risk Assessment Program and how we can help you protect your data center and your data from
cyberattacks. Learn more about how to protect your data center and/or your cloud deployments and the unique
advantages that Oracle Linux provides in “Pillars of Protection: A New View of Enterprise Security” white paper.
11 2016 Cost of Data Breach Study: Global Analysis, Ponemon Institute Research Report
12 1,378,509,261 records in 2016; 2622/minute; 35% are healthcare; 2622*.35 = 917.7 records/minute*$355/record =
$325,783.5/minute
Oracle Corporation, World Headquarters Worldwide Inquiries
500 Oracle Parkway Phone: +1.650.506.7000
Redwood Shores, CA 94065, USA Fax: +1.650.506.7200
Copyright © 2017, Oracle and/or its affiliates. All rights reserved. This document is provided for information purposes only, and the
contents hereof are subject to change without notice. This document is not warranted to be error-free, nor subject to any other
warranties or conditions, whether expressed orally or implied in law, including implied warranties and conditions of merchantability or
fitness for a particular purpose. We specifically disclaim any liability with respect to this document, and no contractual obligations are
formed either directly or indirectly by this document. This document may not be reproduced or transmitted in any form or by any means,
electronic or mechanical, for any purpose, without our prior written permission.
Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.
Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and
are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are
trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group. 1217
C O N N E C T W I T H U S
blogs.oracle.com/Linux
facebook.com/OracleLinux
twitter.com/OracleLinux
oracle.com/Linux
AWSSecurity Incident
Response Guide
June 2019
Notices
Customers are responsible for making their own independent assessment of the
information in this document. This document: (a) is for informational purposes only, (b)
represents current AWS product offerings and practices, which are subject to change
without notice, and (c) does not create any commitments or assurances from AWS and
its affiliates, suppliers or licensors. AWS products or services are provided “as is”
without warranties, representations, or conditions of any kind, whether express or
implied. The responsibilities and liabilities of AWS to its customers are controlled by
AWS agreements, and this document is not part of, nor does it modify, any agreement
between AWS and its
customers.
© 2019 Amazon Web Services, Inc. or its affiliates. All rights reserved.
Contents
………………………………………………………………………………………………………….. 1
Before You Begin ………………………………………………………………………………………………. 2
The AWS CAF Security Perspective ……………………………………………………………………. 2
Foundation of Incident Response ………………………………………………………………………… 2
……………………………………………………………………………………………………………….. 3
Shared Responsibility ………………………………………………………………………………………… 3
Incident Response in the Cloud …………………………………………………………………………… 5
Cloud Security Incidents …………………………………………………………………………………….. 6
Understanding Cloud Capabilities ……………………………………………………………………….. 8
………………………………………………………………………………………………… 10
Define Roles and Responsibilities ……………………………………………………………………… 10
Define Response Mechanisms ………………………………………………………………………….. 11
Create a Receptive and Adaptive Security Culture………………………………………………. 11
Predicting Response ………………………………………………………………………………………… 12
…………………………………………………………………………………………. 15
Prepare Access to AWS Accounts …………………………………………………………………….. 15
Prepare Processes …………………………………………………………………………………………… 18
Cloud Provider Support …………………………………………………………………………………….. 24
…………………………………………………………………………………………………………….. 26
Security Incident Response Simulations …………………………………………………………….. 26
Simulation Steps ……………………………………………………………………………………………… 27
Simulation Examples ………………………………………………………………………………………… 28
………………………………………………………………………………………………………………… 29
Runbooks ……………………………………………………………………………………………………….. 29
Automation ……………………………………………………………………………………………………… 30
……………………………………………………………………………….. 33
Service Domain Incidents …………………………………………………………………………………. 33
Infrastructure Domain Incidents …………………………………………………………………………. 34
…………………………………………………………………………………………………………. 37
……………………………………………………………………………………………………….. 37
………………………………………………………………………………………….. 38
Media ……………………………………………………………………………………………………………… 38
Third-Party Tools ……………………………………………………………………………………………… 39
Industry References …………………………………………………………………………………………. 39
……………………………………………………………………………………………. 39
………………………………………………………………………………………. 40
…………………………………………………………….. 44
Logging and Events …………………………………………………………………………………………. 44
Visibility and Alerting ………………………………………………………………………………………… 46
Automation ……………………………………………………………………………………………………… 47
Secure Storage ……………………………………………………………………………………………….. 48
Custom …………………………………………………………………………………………………………… 49
About This Guide
This guide presents an overview of the fundamentals of responding to security incidents
within a customer’s AWS Cloud environment. It focuses on an overview of cloud
security and incident response concepts, and identifies cloud capabilities, services, and
mechanisms that are available to customers who are responding to security issues.
Amazon Web Services AWS Security Incident Response Guide
Page 1
Introduction
Security is the highest priority at AWS. As an AWS customer, you benefit from a data
center and network architecture that is built to meet the requirements of the most
security-sensitive organizations. The AWS Cloud has a shared responsibility model.
AWS manages security of the cloud. You are responsible for security in the cloud. This
means that you retain control of the security you choose to implement. You get access
to hundreds of tools and features to help you to meet your security objectives. These
capabilities help you establish a security baseline that meets your objectives for your
applications running in the cloud.
When a deviation from your baseline does occur (such as by a misconfiguration), you
might need to respond and investigate. To successfully do so, you must understand the
basic concepts of security incident response within your AWS environment, as well as
the issues you need to consider to prepare, educate, and train your cloud teams before
security issues occur. It is important to know which controls and capabilities you can
use, and can be helpful to review topical examples for resolving potential concerns, and
identify remediation methods that you can use to leverage automation and improve your
response speed.
Because security incident response can be a complex topic, we encourage customers
to start small, develop runbooks, leverage basic capabilities, and create an initial library
of incident response mechanisms to iterate from and improve upon. This initial work
should include teams that are not involved with security and should include your legal
department, so that you are better able to understand the impact that incident response
(IR), and the choices you have made, have on your corporate goals.
This paper is intended for those in technical roles and assumes that you are familiar
with the general principles of information security, have a basic understanding of
incident response in your current on-premises environments, and have some familiarity
with cloud services.
Amazon Web Services AWS Security Incident Response Guide
Page 2
Before You Begin
In addition to this document, we encourage you to review the AWS Security Best
Practices whitepaper and the Security Perspective of the AWS Cloud Adoption
Framework (CAF) whitepaper. The AWS CAF provides guidance that supports
coordinating between the different parts of organizations that are moving to the cloud.
The CAF guidance is divided into several areas of focus that are relevant to
implementing cloud-based IT systems, which we refer to as perspectives. The Security
Perspective describes how to execute a security program across several workstreams,
one of which focuses on incident response. This document details some of our
experiences in helping customers to assess and implement successful mechanisms in
that workstream.
The AWS CAF Security Perspective
The Security Perspective includes four components:
• Directive controls establish the governance, risk, and compliance models within
which the environment
operates.
• Preventive controls protect your workloads and mitigate threats and
vulnerabilities.
• Detective controls provide full visibility and transparency over the operation of
your deployments in AWS.
• Responsive controls drive remediation of potential deviations from your security
baselines.
Although incident response (IR) is generally viewed under the responsive controls
component, these are dependent and influenced by the other components. For
example, directive and preventative security controls help establish a baseline, so you
can monitor and investigate any deviations from this baseline. This approach not only
eliminates noise, but it also contributes to a defensive security design.
Foundation of Incident Response
All AWS users within an organization should have a basic understanding of security
incident response processes, and security staff must deeply understand how to react to
security issues. Experience and education are vital to a cloud incident response
program, before you handle a security event. The foundation of a successful incident
response program in the cloud is to Educate, Prepare, Simulate, and Iterate.
https://d1.awsstatic.com/whitepapers/Security/AWS_Security_Best_Practices
https://d1.awsstatic.com/whitepapers/Security/AWS_Security_Best_Practices
https://d0.awsstatic.com/whitepapers/AWS_CAF_Security_Perspective
https://d0.awsstatic.com/whitepapers/AWS_CAF_Security_Perspective
Amazon Web Services AWS Security Incident Response Guide
Page 3
To understand each of these aspects, consider the following descriptions:
• Educate your security operations and incident response staff about cloud
technologies and how your organization intends to use them.
• Prepare your incident response team to detect and respond to incidents in the
cloud, enabling detective capabilities, and ensuring appropriate access to the
necessary tools and cloud services. Additionally, prepare the necessary
runbooks, both manual and automated, to ensure reliable and consistent
responses. Work with other teams to establish expected baseline operations, and
use that knowledge to identify deviations from those normal operations.
• Simulate both expected and unexpected security events within your cloud
environment to understand the effectiveness of your preparation.
• Iterate on the outcome of your simulation to improve the scale of your response
posture, reduce time to value, and further reduce risk.
Educate
Shared Responsibility
The responsibility for security and compliance is shared between AWS and you. This
shared model relieves some of your operational burden because AWS operates,
manages, and controls the components from the host operating system and
virtualization layer, down to the physical security of the facilities in which the service
operates.
You are responsible for managing the guest operating systems (including updates and
security patches), application software, as well as configuring the AWS provided
security controls, such as security groups, network access control lists, and identity and
access management. You should carefully consider which services you use, because
your responsibilities vary depending on the services you choose, the integration of
those services in your IT environment, and applicable laws and regulations.
Figure 1 shows a typical representation of the shared responsibility model as it applies
to infrastructure services, such as Amazon Elastic Compute Cloud (Amazon EC2). It
separates most responsibilities into two categories: security of the cloud (managed by
AWS) and security in the cloud (managed by the customer). Responsibilities can
change, depending on which services you use. For abstracted services, such as
Amazon S3 and Amazon DynamoDB, AWS operates the infrastructure layer, the
Amazon Web Services AWS Security Incident Response Guide
Page 4
operating system, and platforms, and customers access the endpoints to store and
retrieve data. Customers are responsible for managing their data (including encryption
options), classifying their assets, and using IAM tools to apply the appropriate
permissions.
Figure 1 – Shared Responsibility Model
In addition to the direct relationship you have with AWS, there might be other entities
that have responsibilities in your particular responsibility model. For example, you might
have internal organizational units that take responsibility for some aspects of your
operations. You may also have partners or other third parties that develop, manage, or
operate some of your cloud technology.
Amazon Web Services AWS Security Incident Response Guide
Page 5
Incident Response in the Cloud
Design Goals of Cloud Response
Although the general processes and mechanisms of incident response, such as those
defined in the NIST SP 800-61 Computer Security Incident Handling Guide, remain true,
we encourage you to consider these specific design goals that are relevant to
responding to security incidents in a cloud environment:
• Establish response objectives – Work with your stakeholders, legal counsel,
and organizational leadership to determine the goal of responding to an incident.
Some common goals include containing and mitigating the issue, recovering the
affected resources, preserving data for forensics, and attribution.
• Respond using the cloud – Implement your response patterns where the event
and data occurs.
• Know what you have and what you need – Preserve logs, snapshots, and
other evidence by copying them to a centralized security cloud account. Use
tags, metadata, and mechanisms that enforce retention policies. For example,
you may choose to use Linux dd command or a Windows equivalent to make a
complete copy of data for investigative purposes.
• Use redeployment mechanisms – If a security anomaly can be attributed to a
misconfiguration, the remediation might be as simple as removing the variance
by redeploying the resources with the proper configuration. When possible, make
your response mechanisms safe to execute more than once and on unknown
states.
• Automate where possible – As you see issues or incidents repeat, build
mechanisms that programmatically triage and respond to common situations.
Use human responses for unique, new, and sensitive incidents.
• Choose scalable solutions – Strive to match the scalability of your
organization’s approach to cloud computing, and reduce the time between
detection and response.
• Learn and improve your process – When you identify gaps in your process,
tools, or people, plan to fix them. Simulations are safe methods to find gaps and
improve processes.
https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final
Amazon Web Services AWS Security Incident Response Guide
Page 6
Cloud Security Incidents
Incident Domains
There are three domains within the customer’s responsibility where security incidents
might occur: service, infrastructure, and application. The difference between the
domains is related to the tools you use when you respond. Consider these domains:
• Service Domain – Incidents in the service domain affect a customer’s AWS
account, IAM permissions, resource metadata, billing, and other areas. A service
domain event is one that you respond to exclusively with AWS API mechanisms,
or have root causes associated with your configuration or resource permissions,
and might have related service-oriented logging.
• Infrastructure Domain – Incidents in the infrastructure domain include data or
network-related activity, such as the traffic to your Amazon EC2 instances within
the VPC, processes and data on your Amazon EC2 instances, and other areas.
Your response to infrastructure domain events often involves retrieval,
restoration, or acquisition of incident-related data for forensics. It likely includes
interaction with the operating system of an instance, and in some cases, might
also involve AWS API mechanisms.
• Application Domain – Incidents in the application domain occur in the
application code or in software deployed to the services or infrastructure. This
domain should be included in your cloud threat detection and response
runbooks, and might incorporate similar responses to those in the infrastructure
domain. With appropriate and thoughtful application architecture, you can
manage this domain with cloud tools, using automated forensics, recovery and
deployment.
In these domains, you must consider the actors who might act against your account,
resources, or data. Whether internal or external, use a risk framework to determine what
the specific risks are to your organization and prepare accordingly.
In the service domain, you work to achieve your goals exclusively with AWS APIs. For
example, handling a data disclosure incident from an Amazon S3 bucket involves API
calls to retrieve the bucket’s policy, analyzing the S3 access logs, and possibly looking
at AWS CloudTrail logs. In this example, your investigation is unlikely to involve data
forensic tools or network traffic analysis tools.
Amazon Web Services AWS Security Incident Response Guide
Page 7
In the infrastructure domain, you can use a combination of AWS APIs and familiar
digital forensics/incident response (DFIR) software within the operating system of a
workstation, such as an Amazon EC2 instance that you’ve prepared for IR work.
Infrastructure domain incidents might involve analyzing network packet captures, disk
blocks on an Amazon Elastic Block Store (Amazon EBS) volume, or volatile memory
acquired from an instance.
Indicators of Cloud Security Events
There are many security events that you might not classify as incidents, but might still
be prudent to investigate. To detect security-related events in your AWS Cloud
environment, you can use these mechanisms. Though not an exhaustive list, consider
the following examples of some potential indicators:
• Logs and Monitors – Review AWS logs, such as Amazon CloudTrail, Amazon
S3 access logs, and VPC Flow Logs, and security monitoring services such as
Amazon GuardDuty and Amazon Macie. In addition, use monitors like Amazon
Route 53 health checks and Amazon CloudWatch Alarms. Similarly, use
Windows Events, Linux syslog logs, and other application-specific logs that you
can generate in your applications.
• Billing Activity – A sudden change in billing activity can indicate a security
event.
• Threat Intelligence – If you subscribe to a third-party threat intelligence feed,
you can correlate that information with other logging and monitoring tools to
identify potential indicators of events.
• Partner Tools – Partners in the AWS Partner Network (APN) offer hundreds of
industry-leading products that can help you meet your security objectives. For
more information, see Security Partner Solutions and Security Solutions in the
AWS Marketplace.
• AWS Outreach – AWS Support might contact you if we identify abusive or
malicious activity. For more information, see the AWS Response to Abuse and
Compromise section.
• One-Time Contact – Because it could be your customers, your developers, or
other staff in your organization who notice something unusual, it is important to
have a well-known, well-publicized method of contacting your security team.
Popular choices include ticketing systems, contact email addresses, and web
forms. If your organization works with the general public, you might also need to
have a public-facing security contact mechanism.
https://aws.amazon.com/guardduty/
https://aws.amazon.com/macie/
https://aws.amazon.com/cloudwatch/
https://aws.amazon.com/security/partner-solutions/
https://aws.amazon.com/marketplace/solutions/security
https://aws.amazon.com/marketplace/solutions/security
https://aws.amazon.com/premiumsupport/
Amazon Web Services AWS Security Incident Response Guide
Page 8
Understanding Cloud Capabilities
AWS offers a wide range of security capabilities that you can use to investigate security
events across the domains. For example, AWS provides a number of logging
mechanisms, such as AWS CloudTrail logs, Amazon CloudWatch Logs, Amazon S3
access logs, and more. You should consider the services that you’re using, and make
sure you have enabled the logs that pertain to those services. AWS also offers a
Centralized Logging Solution on AWS Solutions, which can help you to understand how
to centralize and store the common types of cloud logs. After you have enabled these
logging sources, you must decide how you want to analyze them, such as using
Amazon Athena to query logs held in your Amazon S3 buckets.
Additionally, there are a number of AWS partner products that can simplify your process
to analyze these logs, such as those described in the APN Security Competency
program. There are also several AWS services that can help you get valuable insights
into this data, such as Amazon GuardDuty (a threat detection service) and AWS
Security Hub, which can give you a comprehensive view of your high-priority security
alerts and compliance status across AWS accounts. For more information about
additional cloud capabilities that you can leverage during your investigations, see
Appendix B: Cloud Capability Definitions.
Data Privacy
We know customers care deeply about privacy and data security, and so we implement
responsible and sophisticated technical and physical controls designed to prevent
unauthorized access to or disclosure of customer content. Maintaining customer trust is
an ongoing commitment. You can learn more about AWS data privacy commitments on
our Data Privacy FAQ page.
These intentional, self-imposed controls, limit the ability of AWS to assist in responding
within a customer’s environment. Because of this, focusing on understanding and
building capabilities within the Shared Responsibility Model is key to success in the
AWS Cloud. Although enabling logging and monitoring capabilities in your AWS
accounts before an incident occurs is important, there are additional aspects to incident
response that are imperative to a successful program.
https://aws.amazon.com/solutions/centralized-logging/
https://aws.amazon.com/athena/
https://aws.amazon.com/security/partner-solutions/
https://aws.amazon.com/security/partner-solutions/
https://aws.amazon.com/guardduty/
https://aws.amazon.com/security-hub/
https://aws.amazon.com/security-hub/
https://aws.amazon.com/compliance/data-privacy-faq/
Amazon Web Services AWS Security Incident Response Guide
Page 9
AWS Response to Abuse and Compromise
Abuse activities are externally observed behaviors of AWS customers’ instances or
other resources that are malicious, offensive, illegal, or could harm other internet sites.
AWS works with you to detect and address suspicious and malicious activities from your
AWS resources. Unexpected or suspicious behaviors from your resources can indicate
that your AWS resources have been compromised, which signals potential risks to your
business.
AWS detects abuse activities in your resources using mechanisms, such as:
• AWS internal event monitoring
• External security intelligence against AWS network space
• Internet abuse complaints against AWS resources
Although the AWS abuse response team aggressively monitors and shuts down
unauthorized activity running on AWS, the majority of abuse complaints refer to
customers who have legitimate business on AWS. Some examples of common causes
of unintentional abuse activities include:
• Compromised resource – An unpatched Amazon EC2 instance could be
infected and become a botnet agent.
• Unintentional abuse – An overly aggressive web crawler might be classified as
a denial-of-service attack by some internet sites.
• Secondary abuse – An end user of the service provided by an AWS customer
might post malware files on a public Amazon S3 bucket.
• False complaints – Sometimes internet users mistakenly report legitimate
activities as abuse.
AWS is committed to working with AWS customers to prevent, detect, and mitigate
abuse, and to defend against future recurrences. We encourage you to review the AWS
Acceptable Use Policy, which describes prohibited uses of the web services offered by
Amazon Web Services and its affiliates. To support timely response to abuse
notifications from AWS, make sure that your AWS account contact information is
accurate. When you receive an AWS abuse warning, your security and operational staff
should immediately investigate the matter. Delay can prolong the reputation impact and
legal implications to others and to yourself. More importantly, the implicated abuse
resource may be compromised by malicious users, and ignoring the compromise could
magnify damages to your business.
https://aws.amazon.com/aup/
Amazon Web Services AWS Security Incident Response Guide
Page 10
Prepare – People
Automated processes enable organizations to spend more time focusing on measures
to increase the security of their cloud environment and applications. Automated incident
response also makes humans available to correlate events, practice simulations, devise
new response procedures, perform research, develop new skills, and test or build new
tools. Despite increased automation, analysts and responders within a security
organization still have much to do.
Define Roles and Responsibilities
The skills and mechanisms of incident response are most important when handling new
or large-scale events. Because we cannot predict or codify all potential events, humans
must do whatever the automation cannot. Handling unclear security events requires
cross-organizational discipline, bias for decisive action, and the ability to deliver results.
Within your organizational structure, there are probably many people who are
responsible, accountable, consulted, or kept informed during an incident. Consider
these roles and responsibilities, and whether any third parties must be involved.
Trusted partners might be involved in the investigation or response that provide
additional expertise and valuable scrutiny. You might need to contact owners of
impacted applications or resources, because they are subject matter experts (SMEs)
that can provide information and context. Application owners or SMEs might be required
to act in situations where the environment is unfamiliar, has unanticipated complexity, or
where the responders do not have access. Application SMEs should practice and
become comfortable working with the IR team.
Provide Training
To reduce dependency and decrease response time, make sure that your security
teams and responders are educated about cloud services and have opportunities to
practice hands-on with the specific cloud platforms that your organization uses. AWS
provides a number of training options and learning paths through digital training,
classroom training, partners, and certifications. To learn more, see AWS Training &
Certification.
Beyond general cloud experience, most customers need to significantly invest in their
people to be successful. Your organization can benefit by providing additional training to
your staff to learn programming skills, development processes (including version control
systems and deployment practices), and infrastructure automation.
https://aws.amazon.com/training/
https://aws.amazon.com/training/
Amazon Web Services AWS Security Incident Response Guide
Page 11
Define Response Mechanisms
When you consider your approach to incident response in the cloud, in unison with
other teams (such as your legal counsel, leadership, business stakeholders, and
others), you must understand what you have and what you need. First, identify
stakeholders and relevant contacts, and make sure you have appropriate access to
perform the necessary response.
Although the cloud can provide you with greater visibility and capabilities through
service APIs, you must document where these are and how to use them. Identify your
team’s AWS account numbers, the IP address ranges of your Virtual Private Clouds
(VPCs), corresponding network diagrams, logs, data locations, and data classifications.
Many of these technological processes are included in the
Prepare – Technology
section. Then, begin documenting your incident response procedures, often referred to
as procedures or runbooks, that define the steps to investigate and remediate an
incident.
Create a Receptive and Adaptive Security Culture
We have learned that our customers’ most successful security teams are cooperative
enablers for their business and its developers, who foster a culture that makes sure all
stakeholders cooperate and escalate to maintain an agile, high-responsive security
posture. Although improving your organization’s security culture is not the subject of this
paper, you can get relevant intelligence from your non-security staff if they see the
security team is receptive. When your security team is open and accessible, with
support from leadership, they are more likely to get additional, timely notifications and
responses to security events.
In some organizations, staff might fear retribution if they report a security problem.
Sometimes they simply don’t know how to report an issue.
In other cases, they might not want to waste time, or might be embarrassed to report
something as a security incident that is later discovered to not be a problem. From the
leadership team down, it is important to promote a culture of acceptance and to invite
everyone to be a part of the organization’s security. Provide a clear channel for anyone
to open a high-severity ticket, whenever they believe there could be a potential risk or
threat. Welcome these notifications with an eager and open mind, but more importantly,
make it clear to non-security staff that you welcome these notifications. Emphasize that
you would rather be over-notified of potential issues, than to receive no notifications at
all.
Amazon Web Services AWS Security Incident Response Guide
Page 12
These notifications offer valuable opportunities to practice responsive investigations
under stress. They can serve as an important feedback loop while you develop your
response procedures.
Predicting Response
Because it is impossible to predict all potential events, you must continue to rely on
human analysis. Taking the time to carefully train your staff and prepare your
organization helps you to anticipate the unexpected, however, your organization does
not have to prepare in isolation. Collaborating with trusted security partners to identify
unexpected security events gives organizations the benefit of additional visibility and
insight.
Partners and the Window of Response
The journey to the cloud is unique for every organization. However, there are patterns
and practices that other organizations have already encountered that a trusted security
partner can bring to your attention. We encourage you to identify external AWS security
partners that can provide you with outside expertise and a different perspective to
augment your response capabilities. Your trusted security partners can help you identify
potential risks or threats that you might not be familiar with.
In 1955, Joseph Luft and Harrington Ingham created the Johari Window, an exercise for
mapping traits to categories. The window is depicted as a grid that consists of four
quadrants, similar to the following diagram.
Figure 2 – Window of Response
Amazon Web Services AWS Security Incident Response Guide
Page 13
Although Luft and Ingham’s window was not intended for information security, we can
adjust the concept to use it as a simple mental model to consider the difficulty in
assessing an organization’s threats. In our modified concept, the four quadrants are:
• Obvious – Risk of which both your team and your partner are aware.
• Internally Known – Risk that your team is familiar with, but that your partner
isn’t. This could mean that you have internal expertise or tribal knowledge.
• Blind Spot – Risk that your partner is familiar with, but that your team is not.
• Unknown – Risk which neither you or your partner are familiar with.
Although this diagram is simple, it represents the value that having trusted partners can
achieve. Most critically, there might be blind spot items that you are unaware of, but a
partner with the right expertise can bring to your attention. Although you might both be
familiar with those risks in the obvious quadrant, your partner could recommend controls
and solutions that you are unfamiliar with. Additionally, although you might bring those
risks in the internally known quadrant to your partner’s attention, your partner might also
be able to identify optimized controls for mitigating that risk. As you measure yourself for
improvement, contact your partner to provide expert advice.
The Unknown
If you’ve been focused on tailoring alerts, improving your incident response procedures
with automation, and improving your security defenses, you might be wondering what to
improve next. You might be curious about your unknown risk, as represented in the
unknown category of Figure 2 – Window of Response. You can reduce unknown risk
through the following methods:
• Define security assertions – What are some truths that you can assert? What
are the security primitives that should absolutely be true in your environment?
Clearly defining these allows you to search for the inverse. This is something
that’s easier to do early in your cloud journey, rather than attempting to reverse
engineer your security assertions later.
• Education, communication, and research – Create cloud security experts on
your staff or include expert partners to help scrutinize your
environment.
Challenge your assumptions, and be wary of subtle reasoning. Create feedback
loops in your processes and offer mechanisms for your engineering teams to
communicate with security teams. You can also expand your approach to
monitor relevant security mailing lists and information security disclosures.
Amazon Web Services AWS Security Incident Response Guide
Page 14
• Reducing attack surface – Improve your defense to avoid risk and give yourself
more time against unknown attacks. Block and slow down attackers, and force
them to be noisy.
• Threat intelligence – Subscribe to a continuous feed of current and relevant
threats, risk, and indicators from around the world.
• Alerts – Generate notifications that alert you to unusual, malicious, or expensive
activities. For example, you might create a notification for activities that occur in
regions or services that you do not use.
• Machine learning – Leverage machine learning to identify complex anomalies
for a specific organization or individual personas. To help you identify unusual
behaviors, you can also profile the normal characteristics of your networks,
users, and systems.
Amazon Web Services provides you with the tools and services to manage these issues
yourself. Using machine learning to identify malicious patterns is a well-researched field
of study, with patterns that are implemented by customers, AWS Professional Services,
AWS Partners, and through AWS services such as Amazon GuardDuty and Amazon
Macie. Some of these patterns have been discussed at AWS re:Invent conference
sessions. For more information, see the Media section.
Customers are also expanding their traditionally business-centric data lakes to leverage
similar architecture patterns when they develop security data lakes. Security operations
teams are also expanding their use of traditional logging and monitoring tools, such as
Amazon Elasticsearch Service and Kibana, to big data architectures.
Those customers are collecting internal data from AWS CloudTrail event logs, VPC
Flow Logs, Amazon CloudFront access logs, database logs, and application logs, and
then combine this data with public data and threat intelligence. With this valuable data,
customers have expanded to include data science and data engineering skills on their
security operations teams to leverage tools such as Amazon EMR, Amazon Kinesis
Data Analytics, Amazon Redshift, Amazon QuickSight, AWS Glue, Amazon
SageMaker, and Apache MXNet on AWS to build custom solutions that identify and
predict anomalies that are unique to their business.
Amazon Web Services AWS Security Incident Response Guide
Page 15
Prepare – Technology
Prepare Access to AWS Accounts
During an incident, your incident response teams must have access to the
environments and resources involved in the incident. Make sure that your teams have
appropriate access to perform their duties before an event occurs. To do that, you must
know what level of access your team members require (for example, what kinds of
actions they are likely to take) and you must provision access in advance. Your team
members’ authentication and authorization should be documented and tested well
before an event occurs to make sure they can perform a timely response without
delays.
At this stage, you must work closely with your cloud architecture and development
teams to understand what level of access is necessary for responders. Identify and
discuss the AWS account strategy and cloud identity strategy with your organization’s
cloud architects to understand what authentication and authorization methods are
configured, for example:
• Federation – A user assumes an IAM role in an AWS account from an Identity
Provider.
• Cross-account access – A user assumes an IAM role between multiple AWS
accounts.
• Authentication – A user authenticates as an AWS IAM user created within a
single AWS account.
These options define the technical choices for authentication to AWS, and how you may
gain access during a response, but some organizations might rely on another team or a
partner to assist in the response. User accounts that are created specifically to respond
to a security incident are often privileged in order to provide sufficient access.
Therefore, use of these user accounts should be restricted, and they should not be used
for daily activities.
Before you create new access mechanisms, work with your cloud teams to understand
how your AWS accounts are organized and governed. Many customers use AWS
Organizations to help centrally manage billing, share resources across their AWS
accounts, and control access, compliance, and security. A core feature of Organizations
is that it can be leveraged to apply Service Control Policies to groups of accounts, which
enables you to gain policy management at scale. For additional information about
https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scp.html
Amazon Web Services AWS Security Incident Response Guide
Page 16
implementing governance mechanisms at scale, see AWS Governance at Scale. After
you understand how your organization has organized and governed your AWS
accounts, consider the following generalized response patterns to assist in identifying
which approaches are right for your organization.
Indirect Access
If you use indirect access, your account owners or application teams are required to
perform authorized remediations in their AWS accounts with tactical guidance from the
incident response team who are your security experts. This method is a slower and
more complex way to execute tasks, but it can be successful when the responders are
unfamiliar with the account or cloud environment.
Direct Access
To give incident responders direct access, you deploy an AWS IAM role into the AWS
accounts that your security engineers or incident responders can assume during a
security event. The incident responder authenticates either through a normal federated
process, or through a special emergency process, if the incident impacts your normal
authentication process. The permissions you give the incident response IAM role
depend on the actions you anticipate the responders to perform.
Alternative Access
If you believe a security event is impacting your security, identity, or communication
systems, you might need to seek alternative mechanisms and access to investigate and
remediate the impact. By using a new, purpose-built AWS account, your responders
can collaborate and work from an alternate, secure
infrastructure.
For example, responders can leverage new infrastructure launched in the cloud, such
as remote workstations using Amazon WorkSpaces and email services provided by
Amazon WorkMail. You must prepare appropriate access controls (using IAM policies)
to delegate access so that your secure, alternative AWS account can assume
permissions for the impacted AWS account.
After you have delegated appropriate access, you can use the AWS APIs in the affected
account to share relevant data, such as logs and volume snapshots, to perform
investigative work in the isolated environment. For more information about this cross-
account access, see Tutorial: Delegate Access Across AWS Accounts Using IAM
Roles.
https://docs.aws.amazon.com/aws-technical-content/latest/aws-governance-at-scale/introduction.html
https://aws.amazon.com/workspaces/
https://aws.amazon.com/workmail/
https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html
https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_cross-account-with-roles.html
Amazon Web Services AWS Security Incident Response Guide
Page 17
Automation Access
As you migrate to using automation to respond to security events, you must create IAM
roles specifically for your automation resources to use (such as Amazon EC2 instances
or AWS Lambda functions). These resources can then assume the IAM roles and inherit
the permissions assigned to the role. Instead of creating and distributing AWS
credentials, you delegate permission to your AWS Lambda function or Amazon EC2
instance. The AWS resource automatically receives a set of temporary credentials and
uses them to sign API requests.
You can also consider a secure method for your automation or tooling to authenticate
and execute within the operating system of your Amazon EC2 instance. Though there
are many tools that can perform this automation, consider using the AWS Systems
Manager Run Command, which enables you to remotely and securely administrate
instances using an agent that you install on your Amazon EC2 instance operating
system.
The AWS Systems Manager Agent (SSM Agent) is installed by default on some
Amazon EC2 Amazon Machine Images (AMIs), such as for Windows Server and
Amazon Linux. However, you might need to manually install the agent on other versions
of Linux and hybrid instances. Whether you use Run Command or another tool,
complete any prerequisite setup and configuration before you receive your first security-
related alert to investigate.
Managed Services Access
Your organization may already be partnered with an information technology provider
that manages services and solutions on your behalf. These partners have a shared
responsibility in supporting the security of your organization, and it’s important to clearly
understand this relationship before an anomaly occurs. Whether you already work with
an AWS Managed Service Provider (MSP) Partner, or AWS Managed Services, or a
managed security services partner, you must identify the responsibilities of each partner
as they relate to your cloud environments, what access the providers already have to
your cloud services, what access they need, and points-of-contact or escalation paths
for when you need their assistance. Finally, you should practice this with your partner to
make sure that your response plans are predictable and successful.
For example, AWS Managed Services (AMS) provides ongoing management of your
AWS infrastructure so that you can focus on your applications. By implementing best
practices to maintain your infrastructure, AWS Managed Services helps to reduce your
operational overhead and risk. AWS Managed Services automates common activities
https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html
https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html
https://aws.amazon.com/partners/msp/
Amazon Web Services AWS Security Incident Response Guide
Page 18
such as change requests, monitoring, patch management, security, and backup
services, and provides full-lifecycle services to provision, run, and support your
infrastructure.
As an Infrastructure Operator, AMS takes responsibility for deploying a suite of security
detective controls and providing first line response to them, 24/7 using a follow-the-sun
model. When an alert is triggered, AMS follows a standard set of runbooks to ensure a
consistent response. These runbooks are shared with AMS customers during
onboarding, so they can develop and coordinate response with AMS. AMS encourages
the joint execution of security response simulations with customers to develop
operational muscle before a real incident occurs.
Prepare Processes
Once appropriate access has been provisioned and tested, your incident response team
must define and prepare the related processes necessary for investigation and
remediation. This stage is effort intensive, because you must sufficiently plan the
appropriate response to security events within your cloud environments.
Work closely with your internal cloud services teams and partners to identify the tasks
required to ensure that these processes are possible. Collaborate or assign each other
response activity tasks and ensure necessary account configurations are in place. We
recommend preparing processes and prerequisite configurations in advance to give
your organization the following response
capabilities.
Decision Trees
Sometimes, different conditions can require different actions or steps. For example, you
might take different actions based on the type of AWS account (development versus
production), the tags of the resources, the AWS Config rules compliance status of those
resources, or other inputs.
To support you in the creation and documentation of these decisions, we recommend
you draft a decision tree with your other teams and stakeholders. Similar to a flow chart,
a decision tree is a tool that can be leveraged to support decision making, helping to
guide you to determine the optimal actions and outcomes based on potential conditions
and inputs, including probabilities.
Amazon Web Services AWS Security Incident Response Guide
Page 19
Use Alternative Accounts
Although responding to an event in the impacted account might be required, it is ideal to
investigate data outside of the affected account. Some customers have a process for
creating separate, isolated AWS account environments, using templates that
preconfigure the resources they must provision. These templates are deployed through
a service, such as AWS CloudFormation or Terraform, which provides an easy method
to create a collection of related AWS resources and provision them in an orderly and
predictable fashion.
Preconfiguring these accounts using templated mechanisms helps to remove human
interactions during the initial stages of an incident and ensure the environment and
resources are prepared in a repeatable and predictable manner, which can be verified
by an audit. In addition, this mechanism also increases the ability to maintain security
and containment of data in the forensics environment.
This approach requires you to work with your cloud services and architect teams to
determine an appropriate AWS account process that can be used for investigations. For
example, your cloud services teams could use AWS Organizations to generate new
accounts and assist you in preconfiguring those accounts using a templated or scripted
method.
View or Copy Data
Responders require access to logs or other evidence to analyze and must ensure that
they have the ability to view or copy data. At a minimum, the IAM permission policy for
the responders should provide read-only access so that they can investigate. To enable
appropriate access, you might consider some pre-built AWS Managed Policies, such as
SecurityAudit or ViewOnlyAccess appropriate access.
For example, responders might want to make a point-in-time copy of data, such as the
AWS CloudTrail logs, from an Amazon S3 bucket in one account to an Amazon S3
bucket in another account. The permissions provided by the ReadOnlyAccess managed
policy, for example, enable the responder to perform these actions. To understand how
to use the AWS Command Line Interface (CLI) to perform this, see How can I copy
objects between Amazon S3 buckets.
https://aws.amazon.com/organizations/
https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html#jf_security-auditor
https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html#jf_view-only-user
https://aws.amazon.com/premiumsupport/knowledge-center/move-objects-s3-bucket/
https://aws.amazon.com/premiumsupport/knowledge-center/move-objects-s3-bucket/
Amazon Web Services AWS Security Incident Response Guide
Page 20
Sharing Amazon EBS Snapshots
Many customers use Amazon Elastic Block Store (Amazon EBS) snapshots as part of
their investigation for security events that involve their Amazon EC2 instances.
Snapshots of Amazon EBS volumes are incremental backups. For more information
about Amazon EBS incremental snapshots, see Amazon EBS Snapshots.
To perform an investigation of an Amazon EBS volume in a separate, isolated account,
you must modify the permissions of the snapshot to share it with the AWS accounts that
you specify. Users that you have authorized can use the snapshots you share as the
basis to create their own EBS volumes, while your original snapshot remains
unaffected. For more information, see Sharing an
Amazon EBS Snapshot.
If your snapshot is encrypted, you must also share the custom KMS Customer Managed
Key (CMK) used to encrypt the snapshot. You can apply cross-account permissions to a
custom CMK either when it is created or at a later time. Snapshots are constrained to
the region in which they were created, but you can share a snapshot with another
region by copying the snapshot to that region. For more information, see Copying an
Amazon EBS Snapshot.
Sharing Amazon CloudWatch Logs
Logs that are recorded within Amazon CloudWatch Logs, such as Amazon VPC flow
logs, can be shared with another account (such as your centralized security account)
through a CloudWatch Logs subscription. For example, the log event data can be read
from a centralized Amazon Kinesis stream to perform custom processing and analysis.
Custom processing is especially useful when you collect logging data from across many
accounts. Ideally, create this configuration early in your cloud journey, before a security-
related event occurs. For more information, see Cross-Account Log Data Sharing with
Subscriptions.
Use Immutable Storage
When copying logs and other evidence to an alternative account, make sure that the
replicated data is protected. However, in addition to protecting the secondary evidence,
you must protect the integrity of the data at the source. Known as immutable storage,
these mechanisms protect the integrity of your data by preventing the data from being
tampered with or deleted.
Using the native features of Amazon S3, you can configure an Amazon S3 bucket to
protect the integrity of your data. By managing access permissions with S3 bucket
policies, configuring S3 versioning, and enabling MFA Delete, you can restrict how data
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSSnapshots.html
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-modifying-snapshot-permissions.html
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-copy-snapshot.html
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-copy-snapshot.html
https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CrossAccountSubscriptions.html
https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CrossAccountSubscriptions.html
https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingMFADelete.html
Amazon Web Services AWS Security Incident Response Guide
Page 21
can be written or read. This type of configuration is useful for storing investigation logs
and evidence, and is often referred to as write once, read many (WORM). You can also
protect the data by using server-side encryption with AWS Key Management Service
(KMS) and verifying that only appropriate IAM principals are authorized to decrypt the
data.
Additionally, if you want to securely keep data in a long-term storage after the
investigation is completed, consider moving the data from Amazon S3 to Amazon S3
Glacier using object lifecycle policies. Amazon S3 Glacier is a secure, durable, and
extremely low-cost cloud storage service for data archiving and long-term backup. It is
designed to deliver 99.999999999% durability, and provides comprehensive security
and compliance capabilities that can help meet even the most stringent regulatory
requirements.
Moreover, you can protect the data in Amazon S3 Glacier by using the Amazon S3
Glacier Vault Lock, which allows you to easily deploy and enforce compliance controls
for individual Amazon S3 Glacier vaults with a vault lock policy. You can specify security
controls, such as WORM, in a vault lock policy and lock the policy from future edits.
Once locked, the policy can no longer be changed. Amazon S3 Glacier enforces the
controls set in the vault lock policy to help achieve your compliance objectives, such as
for data retention. You can deploy a variety of compliance controls in a vault lock policy
using the AWS Identity and Access Management (IAM) policy language.
Launch Resources Near the Event
For responders who are new to the cloud, it can be tempting to try to conduct cloud
investigations on-premises where your existing tools are located. In our experience,
AWS customers who respond to incidents using cloud technologies achieve better
results—isolations can be automated, copies can be made more easily, evidence is
ready for analysis sooner, and the analysis can be completed faster.
The best practice is to perform investigations and forensics in the cloud, where the data
is, rather than attempting to transfer the data to a data center before you investigate.
You can use the secure compute and storage capabilities of the cloud practically
anywhere in the world to perform the secure response operations. Many customers
choose to pre-build a separate AWS account that is ready to perform an investigation,
though there might be cases where you choose to operate your analysis in the same
AWS account. If your organization is expected to retain records for compliance and
legal reasons, it might be prudent to maintain separate accounts for long-term storage
and legal activities.
https://aws.amazon.com/glacier/
https://aws.amazon.com/glacier/
https://docs.aws.amazon.com/amazonglacier/latest/dev/vault-lock.html
https://docs.aws.amazon.com/amazonglacier/latest/dev/vault-lock.html
Amazon Web Services AWS Security Incident Response Guide
Page 22
It is also a best practice to perform the investigation in the same AWS Region where the
event occurred, rather than replicating the data to another AWS Region. We
recommend this practice primarily because of the additional time required to transfer the
data between regions. For each AWS Region you choose to operate in, make sure that
both your incident response process and the responders abide by the relevant data
privacy laws. If you do need to move data between AWS Regions, consider the legal
implications of moving data between jurisdictions. It is generally a best practice to keep
the data within the same national jurisdiction.
If you believe a security event is impacting your security, identity, or communication
systems, you might need to seek alternative mechanisms and access to investigate and
remediate the impact. AWS offers you the ability to quickly launch new infrastructure
that can be used for secure, alternate work environments. For example, while you
investigate the potential severity of the situation, you might want to create a new AWS
account with the secure tools for your legal counsel, public relations, and security teams
to communicate and continue working. Services such as AWS WorkSpaces (for virtual
desktops), AWS WorkMail (for email), and AWS Chime (for communication) can provide
your response teams, leadership, and other participants with the capabilities and
connectivity they need to communicate, investigate, and remediate an issue.
Isolate
Resources
In the course of your investigation, you might need to isolate resources as part of your
response to a security anomaly. The intention behind isolating resources is to limit the
potential impact, prevent further propagation of affected resources, limit the unintended
exposure of data, and prevent further unauthorized access.
As with any response, other business, regulatory, legal, or other considerations can
apply. Make sure to weigh your intended actions against expected and unexpected
consequences. If your cloud teams use resource tags, these tags can help you identify
the criticality of the resource or the owner to contact.
Amazon Web Services AWS Security Incident Response Guide
Page 23
Launch Forensic Workstations
Some of your incident response activities might include analyzing disk images, file
systems, RAM dumps, or other artifacts that are involved in an incident. Many
customers build a customized forensic workstation that they can use to mount copies of
any affected data volumes (known as EBS snapshots). To do so, follow these basic
steps:
1. Choose a base Amazon Machine Image (AMI) (such as Linux or Windows) that
can be used as a forensic workstation.
2. Launch an Amazon EC2 instance from that base AMI.
3. Harden the operating system, remove unnecessary software packages, and
configure relevant auditing and logging mechanisms.
4. Install your preferred suite of open source or private toolkits, as well as any
vendor software and packages you need.
5. Stop the Amazon EC2 instance and create a new AMI from the stopped instance.
6. Create a weekly or monthly process to update and rebuild the AMI with the latest
software patches.
After the forensic system is provisioned using an AMI, your incident response team can
use this instance to create a new AMI to launch a new forensic workstation for each
investigation. The process for launching the AMI as an Amazon EC2 instance can be
preconfigured to simplify the deployment process. For example, you can create a
template of the forensic infrastructure resources you need within a text file and deploy it
into your AWS account through AWS CloudFormation.
When your resources are available to be deployed quickly from a template, your well-
trained forensic experts are able to use new forensic workstations for each
investigation, instead of reusing infrastructure. With this process, you can make sure
that there is no cross-contamination from other forensic examinations.
Instance Types for Workstations
Amazon EC2 provides a wide selection of instance types that are optimized for different
use cases. Instance types comprise varying combinations of CPU, memory, storage,
and networking capacity, and give you the flexibility to choose the appropriate mix of
resources for your applications. Each instance type includes one or more instance
sizes, which enables you to scale your resources to the requirements of your target
workload.
Amazon Web Services AWS Security Incident Response Guide
Page 24
AWS enhanced networking uses single root I/O virtualization (SR-IOV) to provide high-
performance networking capabilities on supported instance types. SR-IOV is a method
of device virtualization that provides higher I/O performance and lower CPU utilization
when compared to traditional virtualized network interfaces. Enhanced networking
provides higher bandwidth, higher packet per second (PPS) performance, and
consistently lower inter-instance latencies. There is no additional charge for using
enhanced networking. For information about which instance types support 10 or 25
Gbps network speeds, and other advanced capabilities, see Amazon EC2 Instance
Types.
Cloud Provider Support
AWS Support
AWS Support offers a range of plans that provide access to tools and expertise that
support the success and operational health of your AWS solutions. All support plans
provide 24×7 access to customer service, AWS documentation, whitepapers, and
support forums. If you need technical support and more resources to help plan, deploy,
and optimize your AWS environment, you can select a support plan that best aligns with
your AWS use case.
You should consider the Support Center in the AWS Console as the central point of
contact to get support for issues that affect your AWS resources. Access to AWS
Support is controlled by AWS Identity and Access Management (IAM). For more
information about getting access to AWS support features, see Accessing Support.
If you need to report abuse of Amazon EC2, contact the AWS Abuse team at:
https://aws.amazon.com/forms/report-abuse
DDoS Response Support
A Denial of Service (DoS) attack makes your website or application unavailable to end
users. Attackers use a variety of techniques that consume network or other resources,
disrupting access for legitimate end users. In its simplest form, a DoS attack against a
target is executed by a lone attacker from a single source.
In a Distributed Denial of Service (DDoS) attack, an attacker uses multiple sources,
which may be compromised or controlled by a group of collaborators, to orchestrate an
attack against a target. In a DDoS attack, each of the collaborators or compromised
hosts participates in the attack, generating a flood of packets or requests to overwhelm
the intended target.
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/enhanced-networking.html#supported_instances
https://aws.amazon.com/ec2/instance-types
https://aws.amazon.com/ec2/instance-types
https://aws.amazon.com/premiumsupport/
https://console.aws.amazon.com/support
http://docs.aws.amazon.com/awssupport/latest/user/getting-started.html#accessing-support
https://aws.amazon.com/forms/report-abuse
Amazon Web Services AWS Security Incident Response Guide
Page 25
AWS offers customers AWS Shield, which provides a managed DDoS protection
service that safeguards web applications running on AWS. AWS Shield provides
always-on detection and automatic inline mitigations that minimize application downtime
and latency, so there is no need to engage AWS Support to benefit from DDoS
protection. There are two tiers of AWS Shield: Standard and Advanced.
All AWS customers benefit from the automatic protections of AWS Shield Standard, at
no additional charge. AWS Shield Standard defends against most common, frequently
occurring network and transport layer DDoS attacks that target your website or
applications. When you use AWS Shield Standard with Amazon CloudFront and
Amazon Route 53, you receive comprehensive availability protection against all known
infrastructure (Layer 3 and 4) attacks.
For higher levels of protection against attacks targeting your web applications running
on Amazon Elastic Compute Cloud (Amazon EC2), Elastic Load Balancing (ELB),
Amazon CloudFront, and Amazon Route 53 resources, you can subscribe to AWS
Shield Advanced. Additionally, AWS Shield Advanced gives you 24×7 access to the
AWS DDoS Response Team (DRT). For more information about AWS Shield Standard
and AWS Shield Advanced, see AWS Shield.
https://aws.amazon.com/shield/
https://aws.amazon.com/ec2/
https://aws.amazon.com/elasticloadbalancing/
https://aws.amazon.com/cloudfront/
https://aws.amazon.com/route53/
https://aws.amazon.com/shield/
Amazon Web Services AWS Security Incident Response Guide
Page 26
Simulate
Security Incident Response Simulations
Security Incident Response Simulations (SIRS) are internal events that provide a
structured opportunity to practice your incident response plan and procedures during a
realistic scenario. SIRS events are fundamentally about being prepared and iteratively
improving your response capabilities. Some of the reasons customers find value in
performing SIRS activities include:
• Validating readiness
• Developing confidence – Learning from simulations and training staff
• Following compliance or contractual obligations
• Generating artifacts for accreditation
• Being agile – Incremental improvement with laser focus
• Becoming faster and improving tools
• Refining communication and escalation
• Developing comfort with the rare and the unexpected
For these reasons, the value derived from participating in a SIRS activity increases an
organization’s effectiveness during stressful events. Developing a SIRS activity that is
both realistic and beneficial can be a difficult exercise. Although testing your procedures
or automation that handles well-understood events has certain advantages, it is just as
valuable to participate in creative SIRS activities to test yourself against the unexpected.
Amazon Web Services AWS Security Incident Response Guide
Page 27
Simulation Steps
Regardless of whether you design your own SIRS, or have a trusted partner to provide
the groundwork, simulations generally follow these steps:
1. Find an issue of importance – Define the trigger that should cause a response.
2. Identify skilled security engineers – A simulation requires a builder and a
tester.
3. Build a realistic model system – The simulation must be realistic and
appropriate. If it is not realistic, participants might not value the exercise. If it is
too minimal, the exercise might be deemed trivial. Start with simple exercises
and work towards a full event.
4. Build and test the scenario elements – Relevant simulation material might
need to be built, such as logging artifacts, email notifications and alerts, and
potential runbooks.
5. Invite other security individuals and cross-organizational participants –
Invite everyone who needs to train and participate. If your general legal counsel,
executives, and public relations have a part in the simulation, you should also
invite them.
6. Run the simulation– Choose if your staff should expect the SIRS event, or if the
simulation should remain unannounced.
7. Celebrate, measure, improve, and repeat – The simulation has factors of
stress, and so it is important to encourage and celebrate the efforts of your
participants. After encouragement comes the opportunity to measure, improve,
and iterate for the next simulation. AWS encourages you to make a habit of these
activities.
Important – If you are planning to perform a Security Incident Response
Simulation, go to the Penetration Testing page and review the Other Simulated
Events section for the latest information on how to proceed.
https://aws.amazon.com/security/penetration-testing/
Amazon Web Services AWS Security Incident Response Guide
Page 28
Simulation Examples
Security simulations must be realistic to provide the expected value. When you or your
partners work toward creating your own simulations, always consider past, real-world
events as a valuable source for potential simulation exercises. Here are a few examples
that AWS customers have found useful to use for their initial simulations:
• Unauthorized changes to network configuration or resources
• Credentials that were mistakenly exposed publicly due to developer
misconfiguration
• Sensitive content that was mistakenly made publicly-accessible by developer
misconfiguration
• Isolation of a web server that is communicating with suspected malicious
IP addresses
In addition to the valuable, experiential learning, performing SIRS activities generates
outputs, such as lessons learned, that you can use as inputs into the next process of
your program—iteration.
Amazon Web Services AWS Security Incident Response Guide
Page 29
Iterate
The previous section defined some of the benefits of SIRS activities. Among these
advantages was gaining agility through incremental improvements. Simulations should
generate valuable outcomes that you can leverage to improve your security response.
They provide a feedback loop to the organization, about what is working and what is not
working. With this knowledge, you can incrementally create new procedures or update
existing ones to improve your response.
Runbooks
When a security anomaly is detected, containing the event and returning to a known
good state are important elements of a response plan. As an example, if the anomaly
occurred because of a security misconfiguration, the remediation might be as simple as
removing the variance through a redeployment of the resources with the proper
configuration. To do this, you will need to plan ahead and define your own security
response procedures, which are often called runbooks.
A runbook is the documented form of an organization’s procedures for conducting a task
or series of tasks. This documentation is usually stored either in an internal digital
system or on printed paper. You might currently have incident response runbooks, or
you might need to create them to be compliant to a security assurance framework.
However, when you manually follow written runbooks, you increase the potential that
you will make mistakes. Instead, we recommend that you automate all of your
repeatable tasks. Automation frees your response team from common tasks, and
makes them available for more important tasks, such as correlating events, practicing in
simulations, devising new response procedures, performing research, developing new
skills, and testing or building new tools. However, before you can decompose the tasks
into programmable logic and iterate towards proper automation, you must start by
writing a runbook.
Creating Runbooks
To create runbooks for the cloud, we recommend that you first focus on the alerts you
currently generate. If you generate an alert, it is important to investigate it. Start by
defining the manual descriptions of the processes you perform. After this, test the
processes and iterate on the runbook pattern to improve the core logic of your
response. Determine what the exceptions are, and what the alternative resolutions are
for those scenarios. For example, in a development environment, you might want to
terminate a misconfigured Amazon EC2 instance. But, if the same event occurred in a
Amazon Web Services AWS Security Incident Response Guide
Page 30
production environment, instead of terminating the instance, you might stop the instance
and verify with stakeholders that critical data will not be lost and that termination is
acceptable.
After you determine the best solution, you can deconstruct the logic into a code-based
solution, which can be used as a tool by many responders to automate the response
and remove variance or guess-work by your responders. This speeds up the lifecycle of
a response. The next goal is to enable this code to be fully automated by being invoked
by the alerts or events themselves, rather than them being executed by a human
responder.
Getting Started
If you’re not sure where to start, consider beginning with the alerts that could be
generated by AWS Trusted Advisor and AWS Config Rules. Then, focus on events
generated by Amazon GuardDuty and Amazon Macie. Information about Amazon
GuardDuty findings are available on the Amazon GuardDuty User Guide. Information
about Amazon Macie alerts are available on the Amazon Macie service pages in the
AWS Management Console.
Both Amazon GuardDuty and Amazon Macie send notifications through
Amazon CloudWatch Events when any change in the findings or alerts occurs. This
includes newly generated alerts and updates to existing alerts. You can set up the
Amazon CloudWatch Events rules to trigger AWS Lambda functions to perform event-
driven response. For more information, see the Event-Driven Response section.
Automation
Automation is a force multiplier, which means it scales the efforts of your responders to
match the speed of the organization. Moving from manual processes to automated
processes enables you to spend more time increasing the security of your AWS Cloud
environment.
Automating Incident Response
To automate security engineering and operations functions, you can use a
comprehensive set of APIs and tools from AWS. You can fully automate Identity
management, network security, data protection, and monitoring capabilities and deliver
them using popular software development methods that you already have in place.
When you build security automation, your system can monitor, review, and initiate a
https://aws.amazon.com/premiumsupport/technology/trusted-advisor/
https://aws.amazon.com/config/
https://aws.amazon.com/guardduty/
https://aws.amazon.com/macie/
https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types.html
Amazon Web Services AWS Security Incident Response Guide
Page 31
response, rather than having people monitor your security position and manually react
to events.
If your incident response teams continue to respond to alerts in the same way, they risk
alert fatigue. Over time, the team can become desensitized to alerts and can either
make mistakes handling ordinary situations or miss unusual alerts. Automation helps
avoid alert fatigue by using functions that process the repetitive and ordinary alerts,
leaving humans to handle the sensitive and unique incidents.
You can improve manual processes by programmatically automating steps in the
process. After you define the remediation pattern to an event, you can decompose that
pattern into actionable logic, and write the code to perform the logic. Responders can
then execute that code to remediate the issue. Over time, you can automate more and
more steps, and ultimately automatically handle whole classes of common incidents.
However, your objective should be to further reduce the time gap between detective
mechanisms and responsive mechanisms. Historically, this time gap can take hours,
days, or even months. An Incident Response survey by SANS in 2016 found that 21%
of respondents stated their time to detection took two to seven days, and only 29% of
respondents were able to remediate events within the same time frame. In the cloud,
you can reduce that response time gap to seconds by building event-driven response
capabilities.
Event-Driven Response
With an event-driven response system, a detective mechanism triggers a responsive
mechanism to automatically remediate the event. You can use event-driven response
capabilities to reduce the time-to-value between detective mechanisms and responsive
mechanisms. To create this event-driven architecture, you can use AWS Lambda,
which is a serverless compute service that runs your code in response to events and
automatically manages the underlying compute resources for you.
For example, assume that you have an AWS account with the AWS CloudTrail service
enabled. If AWS CloudTrail is ever disabled (through the cloudtrail:StopLogging
API), the response procedure is to enable the service again and investigate the user
that disabled the AWS CloudTrail logging. Instead of performing these steps manually in
the AWS Management Console, you can programmatically enable the logging again
(through the cloudtrail:StartLogging API). If you implement this with code, your
response objective is to perform this task as quickly as possible and notify the
responders that the response was performed.
https://www.sans.org/reading-room/whitepapers/incident/paper/37047
Amazon Web Services AWS Security Incident Response Guide
Page 32
You can decompose the logic into simple code to run in an AWS Lambda function to
perform these tasks. You can then use Amazon CloudWatch Events to monitor for the
specific cloudtrail:StopLogging event, and invoke the function if it occurs. When
this AWS Lambda responder function is invoked by Amazon CloudWatch Events, you
can pass it the details of the specific event with the information of the principal that
disabled AWS CloudTrail, when it was disabled, the specific resource that was affected,
and other relevant information. You can use this information to essentially perform a log
dive, and then generate a notification or alert with only the specific values that a
response analyst would require.
Ideally, the goal of event-driven response is for the Lambda responder function to
perform the response tasks and then notify the responder that the anomaly has been
successfully resolved with any pertinent contextual information. It is then up to the
human responder to decide how to determine why it occurred and how future
reoccurrences might be prevented. This feedback loop drives further security
improvement into your cloud environments. To achieve this objective, you must have a
culture that enables your security team to work closer with your development and
operations teams.
Amazon Web Services AWS Security Incident Response Guide
Page 33
Incident Response Examples
Service Domain Incidents
You can handle many service domain incidents exclusively through AWS APIs.
Identities
Amazon Web Services provides APIs to cloud services that are used by millions of
customers to build new applications and drive business outcomes. These APIs can be
invoked through many methods, such as by software development kits (SDKs), the
AWS CLI, and the AWS Management Console. To interact with AWS through these
methods, the AWS Identity and Access Management (IAM) service helps you securely
control access to AWS resources. You can use IAM to control who is authenticated
(signed in) and authorized (has permissions) to use resources at the Account Level. For
a list of AWS services that you can use with IAM, see AWS Services That Work with
IAM.
When you first create an AWS account, you begin with a single sign-on (SSO) identity
that has complete access to all AWS services and resources in the account. This
identity is called the AWS account root user and is accessed by signing in with the email
address and password that you used to create the account. We strongly recommend
that you do not use the root user for your everyday tasks, and particularly not for
administrative tasks. Instead, we recommend that you follow the best practice of using
the root user only to create your first IAM user, securely store the root user credentials,
and use them to perform only a few account and service management tasks. For more
information, see Create Individual IAM Users.
Although these APIs provide value to millions of customers, some of them can be
abused if the wrong individuals get access to your IAM account or root credentials. For
example, you can use the APIs to enable logging within your account, such as AWS
CloudTrail. However, if attackers get your credentials, they can also use the API to
disable these logs. You can prevent this type of abuse by configuring appropriate IAM
permissions that follow a least privilege model, and by properly protecting your IAM
credentials. For more information, see IAM Best Practices in the AWS Identity and
Access Management User Guide. If this type of event does occur, there are multiple
detective controls to identify that your AWS CloudTrail logging was disabled, including
AWS CloudTrail, AWS Config, AWS Trusted Advisor, and AWS CloudWatch Events.
https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html
https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html
https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#create-iam-users
https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html
Amazon Web Services AWS Security Incident Response Guide
Page 34
Resources
Other features that can be abused or misconfigured vary from organization to
organization based on how each customer operates in the cloud. For example, some
organizations intend to make certain data or applications publicly accessible, while
others keep their applications and data internal and confidential. Not all security events
are malicious in nature; some events might result from unintentional or improper
configurations. Consider which APIs or features have a high impact to your
organization, and whether you use them frequently or infrequently.
You can identify many security misconfigurations using tools and services. For example,
AWS Trusted Advisor provides a number of checks for best practices. Partners in the
AWS Partner Network (APN) also offer hundreds of industry-leading products that are
equivalent, identical to, or integrate with existing controls in your on-premises
environments. A number of these products and solutions have been prequalified by the
AWS Partner Competency Program. We encourage you to visit the Configuration and
Vulnerability Analysis section of the APN Security Competency program to browse
these solutions and to determine if they can satisfy your requirements.
Infrastructure Domain Incidents
The infrastructure domain typically includes your application’s data or network-related
activity, such as the traffic to your Amazon EC2 instances within the VPC and the
processes running in your Amazon EC2 instance operating systems.
For example, assume that your monitoring solution notified you of a potential security
anomaly on your Amazon EC2 instance. The following are common steps to address
this issue:
1. Capture the metadata from the Amazon EC2 instance, before you make any
changes to your environment.
2. Protect the Amazon EC2 instance from accidental termination by enabling
termination protection for the instance.
3. Isolate the Amazon EC2 instance by switching the VPC Security Group or
explicitly denying network traffic to the IP address of the instance with the
Network Access Control List.
4. Detach the Amazon EC2 instance from any AWS Auto Scaling groups.
5. Deregister the Amazon EC2 instance from any related Elastic Load Balancing
service.
https://aws.amazon.com/partners/competencies/
https://aws.amazon.com/security/partner-solutions/#Configuration_and_Vulnerability_Analysis
https://aws.amazon.com/security/partner-solutions/#Configuration_and_Vulnerability_Analysis
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/terminating-instances.html#Using_ChangingDisableAPITermination
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/terminating-instances.html#Using_ChangingDisableAPITermination
https://aws.amazon.com/autoscaling/
https://aws.amazon.com/elasticloadbalancing/
Amazon Web Services AWS Security Incident Response Guide
Page 35
6. Snapshot the Amazon EBS data volumes that are attached to the EC2 instance
for preservation and follow-up investigations.
7. Tag the Amazon EC2 instance as quarantined for investigation, and add any
pertinent metadata, such as the trouble ticket associated with the investigation.
You can perform all of the preceding steps using the AWS APIs, AWS SDKs, the AWS
CLI, and the AWS Management Console. To interact with AWS using these methods,
the AWS Identity and Access Management (IAM) service helps you securely control
access to AWS resources. You use IAM to control who is authenticated and authorized
to use resources at the Account Level. The IAM service provides the authentication and
authorization for you to perform these actions and interact with the service domain.
A snapshot of an Amazon EBS volume is a point-in-time, block-level copy of an EBS
data volume, which occurs asynchronously and might take time to complete. You can
create new EBS volumes from these copies and mount them to the forensic EC2
instance for deep analysis offline by forensic investigators. The following diagram shows
a simplified version of the outcome, and does not describe all of the network
components (such as subnets, routing tables, and network access control lists).
Figure 3 – EC2 Instance Isolation and Snapshots
Amazon Web Services AWS Security Incident Response Guide
Page 36
Investigation Decisions
At this point, you can choose between an offline investigation (immediately shut down
the instance) or an online investigation (keep the instance running). One advantage to
the offline investigation is that after the instance is shut down, it can no longer affect the
existing environment. Additionally, you can create a copy of the affected instance from
the EBS snapshots, and review it in an isolated AWS account with an isolated
environment that is designed specifically for your investigation. However, you can
choose to not shut down the instance immediately, if an online investigation enables
you to potentially capture volatile evidence from the host operating system, such as
memory or network traffic.
Capturing Volatile Data
Although you might not choose to perform the online investigation, it is important to
understand the necessary mechanisms to capture volatile data from an instance. An
online investigation requires interaction with your operating system that is running on
the Amazon EC2 instance. In this scenario, you need more than the AWS IAM service
to execute tasks on an Amazon EC2 instance. Although you could authenticate directly
to the machine using a standard method—such as Linux secure shell (SSH) or
Windows remote desktop (RDP)—manual interaction with the operating system is not a
best practice. We recommend that you programmatically use an automation tool to
execute tasks on a host.
Using AWS Systems Manager
The AWS Systems Manager Run Command helps you to remotely and securely
perform on-demand changes running Linux shell scripts and Windows PowerShell
commands on a targeted instance. Although you can invoke Run Command through
permissions in the AWS IAM service, you must first activate your Amazon EC2
instances as managed instances, install the SSM Agent on your machines (if not
installed by default), and configure the AWS IAM permissions. If you are interested in
using Run Command for automation or response activities, make sure to complete the
prerequisite activities before you have to perform an investigation.
Systems Manager, which includes Run Command, is integrated with AWS CloudTrail, a
service that captures API calls made by or on behalf of Systems Manager and delivers
the log files to an Amazon S3 bucket that you specify. Using the information collected
by AWS CloudTrail, you can determine what request was made, the source IP address
that made the request, who made the request, when it was made, and more. CloudTrail
https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html
Amazon Web Services AWS Security Incident Response Guide
Page 37
creates logs of all Systems Manager API actions, including API requests to execute
commands using Run Command or to create Systems Manager documents.
You can use the AWS Systems Manager Run Command service to invoke the SSM
Agent that executes Linux shell scripts and Windows PowerShell commands. These
scripts can load and execute specific tools to capture additional data from the host, such
as the Linux Memory Extractor (LiME) kernel module. You can then transfer the
memory capture to your forensic Amazon EC2 instance in the VPC network, or to an
Amazon S3 bucket for durable storage.
Automating the Capture
One method to invoke the SSM Agent is to target the Run Command through Amazon
CloudWatch Events when the instance is tagged with a specific tag. For example, if you
apply the Response=Isolate+MemoryCapture tag to an affected instance, you can
configure Amazon CloudWatch Events to trigger two actions: 1) a Lambda function that
performs the isolation activities, and 2) a Run Command that executes a shell command
to export the Linux memory through the SSM Agent. This tag-driven response is
another method of event-driven response.
Conclusion
As you continue your cloud journey, it is important for you to consider the
aforementioned fundamental security incident response concepts for your AWS
environment. You can combine the available controls, cloud capabilities, and
remediation options, to help you improve the security of your cloud environment. You
can start small and iterate as you adopt automation capabilities that improve your
response speed, so you are better prepared when security events occur.
Contributors
Contributors to this document include:
• Joshua Du Lac, Sr. Solutions Architect, Security Specialist, AWS Solutions
Architecture
• Nathan Case, Sr. Solutions Architect, Security Specialist, AWS Solutions
Architecture
• Paco Hope, Principal Consultant, AWS ProServe
Amazon Web Services AWS Security Incident Response Guide
Page 38
Additional Resources
For additional information, see:
• AWS Well-Architected
• Security Perspective of the AWS Cloud Adoption Framework (CAF)
• AWS Centralized Logging Solution
• Visualize AWS CloudTrail Logs using AWS Glue and Amazon QuickSight
• How to Visualize and Refine Your Network’s Security by Adding Security
Group
IDs to Your VPC Flow Logs
• How to Monitor Host-Based Intrusion Detection System Alerts on Amazon EC2
Instances
• Store and Monitor OS & Application Log Files with Amazon CloudWatch
• Identity and Access Management in Amazon S3
• Using Versioning (Amazon S3)
• Using MFA Delete
• Protecting Data Using Server-Side Encryption with AWS KMS–Managed Keys
(SSE-KMS)
• Incident Response with AWS Console and CLI
Media
• AWS re:Invent 2014 (SEC402): Intrusion Detection in the Cloud
• AWS re:Invent 2014 (SEC404): Incident Response in the Cloud
• AWS re:Invent 2015 (SEC308): Wrangling Security Events in The Cloud
• AWS re:Invent 2015 (SEC316): Harden Your Architecture with Security Incident
Response Simulations
• AWS re:Invent 2016 (SEC313): Automating Security Event Response, from Idea
to Code to Execution
• AWS re:Invent 2017 (SID302): Force Multiply Your Security Team with
Automation and Alexa
http://aws.amazon.com/well-architected
https://d0.awsstatic.com/whitepapers/AWS_CAF_Security_Perspective
https://aws.amazon.com/solutions/centralized-logging/
https://aws.amazon.com/blogs/big-data/streamline-aws-cloudtrail-log-visualization-using-aws-glue-and-amazon-quicksight/
https://aws.amazon.com/blogs/security/how-to-visualize-and-refine-your-networks-security-by-adding-security-group-ids-to-your-vpc-flow-logs/
https://aws.amazon.com/blogs/security/how-to-visualize-and-refine-your-networks-security-by-adding-security-group-ids-to-your-vpc-flow-logs/
https://aws.amazon.com/blogs/security/how-to-monitor-host-based-intrusion-detection-system-alerts-on-amazon-ec2-instances/
https://aws.amazon.com/blogs/security/how-to-monitor-host-based-intrusion-detection-system-alerts-on-amazon-ec2-instances/
https://aws.amazon.com/blogs/aws/cloudwatch-log-service/
https://docs.aws.amazon.com/AmazonS3/latest/dev/s3-access-control.html
https://docs.aws.amazon.com/AmazonS3/latest/dev/Versioning.html
https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingMFADelete.html
https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingKMSEncryption.html
https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingKMSEncryption.html
https://github.com/awslabs/aws-well-architected-labs/blob/master/Security/300_Incident_Response_with_AWS_Console_and_CLI/README.md
Amazon Web Services AWS Security Incident Response Guide
Page 39
• AWS re:Invent 2016 (SAC316): Security Automation: Spend Less Time Securing
Your Applications
• AWS re:Invent 2016 (SAC304): Predictive Security: Using Big Data to Fortify
Your Defenses
• AWS re:Invent 2017 (SID325): Amazon Macie: Data Visibility Powered by
Machine Learning for Security and Compliance Workloads
• AWS London Summit 2018: Automating Incident Response and Forensics in
AWS
Third-Party Tools
The following links to third-party tools are external and are not endorsed by AWS. AWS
offers no guarantees or representations of any kind about these tools or pages.
• AWS_IR – Python installable command line utility for mitigation of host and key
compromises
• MargaritaShotgun – Remote Memory Acquisition Tool
• ThreatPrep – Python module for evaluation of AWS account best practices
around incident handling readiness
• ThreatResponse Web – Web based analysis platform for use with the AWS_IR
command line tool.
• GRR Rapid Response – Remote live forensics for incident response
• Linux Write Blocker – The kernel patch and user-space tools to enable Linux
software write blocking
Industry References
• NIST SP 800-61R2: Computer Security Incident Handling Guide
Document Revisions
Date Description
June 2019 First publication
https://github.com/ThreatResponse/aws_ir
https://github.com/ThreatResponse/margaritashotgun
https://github.com/ThreatResponse/ThreatPrep
https://github.com/ThreatResponse/threatresponse_web
https://github.com/google/grr
https://github.com/msuhanov/Linux-write-blocker
http://dx.doi.org/10.6028/NIST.SP.800-61r2
Amazon Web Services AWS Security Incident Response Guide
Page 40
Appendix A – Examples
Example AWS CloudTrail Event
The following example shows that an IAM user named Alice used the AWS CLI to call
the Amazon EC2 StopInstancesaction by using ec2-stop-instances.
{“Records”: [
{
“eventVersion”: “1.0”,
“userIdentity”: {
“type”: “IAMUser”,
“principalId”: “EX_PRINCIPAL_ID”,
“arn”: “arn:aws:iam::123456789012:user/Alice”,
“accountId”: “123456789012”,
“accessKeyId”: “EXAMPLE_KEY_ID”,
“userName”: “Alice”
},
“eventTime”: “2014-03-06T21:01:59Z”,
“eventSource”: “ec2.amazonaws.com”,
“eventName”: “StopInstances”,
“awsRegion”: “us-east-2“,
“sourceIPAddress”: “205.251.233.176”,
“userAgent”: “ec2-api-tools 1.6.12.2”,
“requestParameters”: {
“instancesSet”: {“items”: [{“instanceId”: “i-ebeaf9e2”}]},
“force”: false
},
“responseElements”: {“instancesSet”: {“items”: [{
“instanceId”: “i-ebeaf9e2”,
“currentState”: {
“code”: 64,
“name”: “stopping”
},
“previousState”: {
“code”: 16,
“name”: “running”
}
}]}}
}]}
Amazon Web Services AWS Security Incident Response Guide
Page 41
Example AWS CloudWatch Event
The following Amazon CloudWatch Event example shows that an AWS IAM user
named jane-roe-test was found publicly exposed on www.github.com, and could
be abused by unauthorized users.
{
“check-name”: “Exposed Access Keys”,
“check-item-detail”: {
“Case ID”: “02648f3b-e18f-4019-8d68-ce25efe080ff”,
“Usage (USD per Day)”: “0”,
“User Name (IAM or Root)”: “jane-roe-test”,
“Deadline”: “1440453299248”,
“Access Key ID”: “AKIAIOSFODNN7EXAMPLE”,
“Time Updated”: “1440021299248”,
“Fraud Type”: “Exposed”,
“Location”: “www.github.com”
},
“status”: “ERROR”,
“resource_id”: “”,
“uuid”: “cce6d28f-e44b-4e61-aba1-5b4af96a0f59”
}
Example Infrastructure Domain CLI Activities
The following AWS CLI commands show an example of responding to an event within
the infrastructure domain. This example uses the AWS APIs to perform many of the
initial incident response activities described in this paper.
# Anomaly detected on IP X.X.X.X. Capture that instance’s metadata
> aws ec2 describe-instances –filters “Name=ip-
address,Values=X.X.X.X”
# Protect that instance from accidental termination
> aws ec2 modify-instance-attribute –instance-id i-abcd1234 —
attribute disableApiTermination –value true
Amazon Web Services AWS Security Incident Response Guide
Page 42
# Switch the EC2 instance’s Security Group to a restricted Security
Group
> aws ec2 modify-instance-attribute –instance-id i-abcd1234 —
groups sg-a1b2c3d4
# Detach from the Auto Scaling Group
> aws autoscaling detach-instances –instance-ids i-abcd1234 —
auto-scaling-group-name web-asg
# Deregister the instance from the Elastic Load Balancer
> aws elb deregister-instances-from-load-balancer –instances i-
abcd1234 –load-balancer-name web-load-balancer
# Create an EBS snapshot
> aws ec2 create-snapshot –volume vol-12xxxx78 –description
“ResponderName-Date-REFERENCE-ID”
# Create a new EC2 instance from the Forensic Workstation AMI
> aws ec2 run-instances –image-id ami-4n6x4n6x –count 1 —
instance-type c4.8xlarge –key-name forensicPublicKey –security-
group-ids sg-1a2b3c4d –subnet-id subnet-6e7f819e
# Create a new EBS volume copy from the EBS snapshot
> aws ec2 create-volume –region us-east-1 –availability-zone us-
east-1a –snapshot-id snap-abcd1234 –volume-type io1 –iops 10000
Amazon Web Services AWS Security Incident Response Guide
Page 43
# Attach the volume to the forensic workstation
> aws ec2 attach-volume –volume-id vol-1234abcd –instance-id i-
new4n6x –device /dev/sdf
# Create a security group rule to allow the new Forensic
Workstation to communicate to the contaminated instance.
> aws ec2 authorize-security-group-ingress –group-id sg-a1b2c3d4 –
-protocol tcp –port 0-65535 –source-group sg-1a2b3c4d
# Tag the contaminated instance with the ticket or reference ID
> aws ec2 create-tags -resources i-abcd1234 -tags
Key=Environment,Value=Quarantine:REFERENCE-ID
Amazon Web Services AWS Security Incident Response Guide
Page 44
Appendix B – Cloud Capability Definitions
Amazon Web Services offers over 150 cloud services and thousands of features. Many
of these provide native detective, preventative, and responsive capabilities, and others
can be used to architect custom security solutions. This section includes a subset of
those services that are most relevant to incident response in the cloud.
Logging and Events
AWS CloudTrail – AWS CloudTrail is a service that enables governance, compliance,
operational auditing, and risk auditing of your AWS account. With CloudTrail, you can
log, continuously monitor, and retain account activity related to actions across your
AWS infrastructure. CloudTrail provides event history of your AWS account activity,
including actions taken through the AWS Management Console, AWS SDKs, command
line tools, and other AWS services. This event history simplifies security analysis,
resource change tracking, and troubleshooting.
Validated log files are invaluable in security and forensic investigations. To determine
whether a log file was modified, deleted, or unchanged after CloudTrail delivered it, you
can use CloudTrail log file integrity validation. This feature is built-in using industry
standard algorithms: SHA-256 for hashing and SHA-256 with RSA for digital signing.
This makes it computationally infeasible to modify, delete or forge CloudTrail log files
without detection.
By default, the log files delivered by CloudTrail to your bucket are encrypted by Amazon
server-side encryption. You can optionally use the AWS Key Management Service
(KMS) managed keys (SSE-KMS) for your CloudTrail log files.
Amazon CloudWatch Events – Amazon CloudWatch Events delivers a near real-time
stream of system events that describe changes in AWS resources, or when API calls
are published by AWS CloudTrail. Using simple rules that you can quickly set up, you
can match events and route them to one or more target functions or streams.
CloudWatch Events becomes aware of operational changes as they occur. CloudWatch
Events can respond to these operational changes and take corrective action as
necessary, by sending messages to respond to the environment, activating functions,
making changes, and capturing state information. Some security services, such as
Amazon GuardDuty, produce their output in the form of CloudWatch Events.
AWS Config – AWS Config is a service that enables you to assess, audit, and evaluate
the configurations of your AWS resources. Config continuously monitors and records
https://aws.amazon.com/cloudtrail/
https://aws.amazon.com/config/
Amazon Web Services AWS Security Incident Response Guide
Page 45
your AWS resource configurations and enables you to automate the evaluation of
recorded configurations against desired configurations. With Config, you can review
changes in configurations and relationships between AWS resources, manually or
automatically. You can review detailed resource configuration histories, and determine
your overall compliance against the configurations specified in your internal guidelines.
This enables you to simplify compliance auditing, security analysis, change
management, and operational troubleshooting.
Amazon S3 Access Logs – If you store sensitive information in an Amazon S3 bucket,
you can enable S3 access logs to record every upload, download, and modification to
that data. This log is separate from, and in addition to, the CloudTrail logs that record
changes to the bucket itself (such as changing access policies and lifecycle policies).
Amazon CloudWatch Logs – You can use Amazon CloudWatch Logs to monitor,
store, and access your log files (such as your operating system, application, and custom
log files) from your Amazon Elastic Compute Cloud (Amazon EC2) instances using the
CloudWatch Logs agent. Additionally, Amazon CloudWatch Logs can capture logs from
AWS CloudTrail, Amazon Route 53 DNS Queries, VPC Flow Logs, Lambda functions,
and other sources. You can then retrieve the associated log data from CloudWatch
Logs.
Amazon VPC Flow Logs – VPC flow logs enable you to capture information about the
IP traffic going to and from network interfaces in your VPC. After you’ve created a flow
log, you can view and retrieve its data in Amazon CloudWatch Logs. VPC flow logs can
help you with a number of tasks. For example, you can use flow logs to troubleshoot
why specific traffic is not reaching an instance, which can help you diagnose overly
restrictive security group rules. You can also use flow logs as a security tool to monitor
the traffic to your instance.
AWS WAF Logs – AWS WAF now supports full logging of all web requests that are
inspected by the service. You can store these logs in Amazon S3 for compliance and
auditing needs, as well as to use them for debugging and additional forensics. These
logs help you to understand why certain rules are triggered and why certain web
requests are blocked. You can also integrate the logs with your SIEM and log analysis
tools.
Other AWS Logs – With the pace of innovation, we continue to deploy new features
and capabilities for customers practically every day, which means that there are dozens
of AWS services that provide logging and monitoring capabilities. For information about
the features available for each AWS service, see the AWS documentation for that
service.
Amazon Web Services AWS Security Incident Response Guide
Page 46
Visibility and Alerting
AWS Security Hub – AWS Security Hub gives you a comprehensive view of your high-
priority security alerts and compliance status across AWS accounts. With Security Hub,
you have a single place that aggregates, organizes, and prioritizes your security alerts
or findings from multiple AWS services, such as Amazon GuardDuty, Amazon
Inspector, and Amazon Macie, as well as from AWS Partner solutions. Your findings are
visually summarized on integrated dashboards with actionable graphs and tables. You
can also continuously monitor your environment using automated compliance checks
based on the AWS best practices and industry standards your organization follows.
Amazon GuardDuty – Amazon GuardDuty is a managed threat detection service that
continuously monitors for malicious or unauthorized behavior to help you protect your
AWS accounts and workloads. It monitors for activity such as unusual API calls or
potentially unauthorized deployments that indicate a possible account compromise.
GuardDuty also detects potentially compromised instances or reconnaissance by
attackers.
GuardDuty identifies suspected attackers through integrated threat intelligence feeds
and uses machine learning to detect anomalies in account and workload activity. When
a potential threat is detected, the service delivers a detailed security alert to the
GuardDuty console and AWS CloudWatch Events. This makes alerts actionable and
easy to integrate into existing event management and workflow systems.
Amazon Macie – Amazon Macie is an AI-powered security service that helps you
prevent data loss by automatically discovering, classifying, and protecting sensitive data
stored in AWS. Amazon Macie uses machine learning to recognize sensitive data such
as personally identifiable information (PII) or intellectual property, assigns a business
value, and provides visibility into where this data is stored and how it is being used in
your organization. Amazon Macie continuously monitors data access activity for
anomalies, and delivers alerts when it detects a risk of unauthorized access or
inadvertent data leaks.
AWS Config Rules – An AWS Config Rule represents the preferred configurations for a
resource and is evaluated against configuration changes on the relevant resources, as
recorded by AWS Config. You can see the results of evaluating a rule against the
configuration of a resource on a dashboard. Using Config Rules, you can assess your
overall compliance and risk status from a configuration perspective, view compliance
trends over time, and find which configuration change caused a resource to be out of
compliance with a rule.
Amazon Web Services AWS Security Incident Response Guide
Page 47
AWS Trusted Advisor – AWS Trusted Advisor is an online resource to help you reduce
cost, increase performance, and improve security by optimizing your AWS environment,
Trusted Advisor provides real time guidance to help you provision your resources
following AWS best practices. The full set of Trusted Advisor checks, including
CloudWatch Events integration, is available to Business and Enterprise support plan
customers.
Amazon CloudWatch – Amazon CloudWatch is a monitoring service for AWS Cloud
resources and the applications you run on AWS. You can use Amazon CloudWatch to
collect and track metrics, collect and monitor log files, set alarms, and automatically
react to changes in your AWS resources. Amazon CloudWatch can monitor AWS
resources, such as Amazon EC2 instances, Amazon DynamoDB tables, and Amazon
RDS DB instances, as well as custom metrics generated by your applications and
services, and any log files your applications generate. You can use Amazon
CloudWatch to get system-wide visibility into resource utilization, application
performance, and operational health. You can use these insights to react and keep your
application running smoothly.
AWS Inspector – Amazon Inspector is an automated security assessment service that
helps improve the security and compliance of applications deployed on AWS. Amazon
Inspector automatically assesses applications for vulnerabilities or deviations from best
practices. After performing an assessment, Amazon Inspector produces a detailed list of
security findings prioritized by level of severity. These findings can be reviewed directly
or as part of detailed assessment reports which are available through the Amazon
Inspector console or API.
Automation
AWS Lambda – AWS Lambda is a serverless compute service that runs your code in
response to events and automatically manages the underlying compute resources for
you. You can use AWS Lambda to extend other AWS services with custom logic, or
create your own back-end services that operate at AWS scale, performance, and
security. Lambda runs your code on high-availability compute infrastructure and
performs all the administration of the compute resources for you. This includes server
and operating system maintenance, capacity provisioning and automatic scaling, code
and security patch deployment, and code monitoring and logging. All you have to do is
supply the code.
AWS Step Functions – AWS Step Functions makes it easy to coordinate the
components of distributed applications and microservices using visual workflows. Step
Amazon Web Services AWS Security Incident Response Guide
Page 48
Functions provides a graphical console to arrange and visualize the components of your
application as a series of steps. This makes it simple to build and run multistep
applications. Step Functions automatically triggers and tracks each step, and retries
when there are errors, so your application executes in order and as expected.
Step Functions logs the state of each step, so when things do go wrong, you can
diagnose and debug problems quickly. You can change and add steps without writing
code, so you can easily evolve your application and innovate faster. AWS Step
Functions is part of the AWS Serverless Platform, and makes it simple to orchestrate
AWS Lambda functions for serverless applications. You can also use Step Functions for
microservices orchestration using compute resources such as Amazon EC2 and
Amazon ECS.
AWS Systems Manager – AWS Systems Manager gives you visibility and control of
your infrastructure on AWS. Systems Manager provides a unified user interface so you
can view operational data from multiple AWS services and enables you to automate
operational tasks across your AWS resources. With Systems Manager, you can group
resources by application, view operational data for monitoring and troubleshooting, and
take action on your groups of resources. Systems Manager can keep your instances in
their defined state, perform on-demand changes, such as updating applications or
running shell scripts, and perform other automation and patching tasks.
Secure Storage
Amazon S3 – Amazon S3 is object storage built to store and retrieve any amount of
data from anywhere. It is designed to deliver 99.999999999% durability, and stores data
for millions of applications used by market leaders in every industry. Amazon S3
provides comprehensive security and compliance capabilities that meet the most
stringent regulatory requirements. It gives customers flexibility in the methods they use
to manage data for cost optimization, access control, and compliance. Amazon S3
provides query-in-place functionality, which enables you to run powerful analytics
directly on your data at rest in Amazon S3. Amazon S3 is the most supported cloud
storage service available, with integration from the largest community of third-party
solutions, systems integrator partners, and other AWS services.
Amazon S3 Glacier – Amazon S3 Glacier is a secure, durable, and extremely low-cost
cloud storage service for data archiving and long-term backup. It is designed to deliver
99.999999999% durability, and provides comprehensive security and compliance
capabilities that can help meet the most stringent regulatory requirements. Amazon S3
Glacier provides query-in-place functionality, which enables you to run powerful
Amazon Web Services AWS Security Incident Response Guide
Page 49
analytics directly on your archive data at rest. To keep costs low yet suitable for varying
retrieval needs, Amazon S3 Glacier provides three options for access to archives, from
a few minutes to several hours.
Custom
The aforementioned services and features are not an exhaustive list. Amazon Web
Services is continuously adding new capabilities. For more information, we encourage
you to review the AWS What’s New and AWS Security pages. In addition to the security
services that AWS offers as native cloud services, you might be interested in building
your own capabilities on top of AWS services.
Although we recommend enabling a base set of security services within your accounts,
such as AWS CloudTrail, Amazon GuardDuty, and Amazon Macie, you might eventually
want to extend these capabilities to derive additional value from your log assets. There
are a number of partner tools available, such as those listed in our APN Security
Competency program. You might also want to write your own queries to search your
logs. With the extensive number of managed services that AWS offers, this has never
been easier. There are many additional AWS services that can assist you with
investigation that are outside the scope of this paper, such as Amazon Athena, Amazon
Elasticsearch Service, Amazon QuickSight, Amazon Machine Learning, and Amazon
EMR.
https://aws.amazon.com/new/
https://aws.amazon.com/security/
- Introduction
Before You Begin
The AWS CAF Security Perspective
Foundation of Incident Response
Educate
Shared Responsibility
Incident Response in the Cloud
Design Goals of Cloud Response
Cloud Security Incidents
Incident Domains
Indicators of Cloud Security Events
Understanding Cloud Capabilities
Data Privacy
AWS Response to Abuse and Compromise
Prepare – People
Define Roles and Responsibilities
Provide Training
Define Response Mechanisms
Create a Receptive and Adaptive Security Culture
Predicting Response
Partners and the Window of Response
The Unknown
Prepare – Technology
Prepare Access to AWS Accounts
Indirect Access
Direct Access
Alternative Access
Automation Access
Managed Services Access
Prepare Processes
Decision Trees
Use Alternative Accounts
View or Copy Data
Sharing Amazon EBS Snapshots
Sharing Amazon CloudWatch Logs
Use Immutable Storage
Launch Resources Near the Event
Isolate Resources
Launch Forensic Workstations
Instance Types for Workstations
Cloud Provider Support
AWS Support
DDoS Response Support
Simulate
Security Incident Response Simulations
Simulation Steps
Simulation Examples
Iterate
Runbooks
Creating Runbooks
Getting Started
Automation
Automating Incident Response
Event-Driven Response
Incident Response Examples
Service Domain Incidents
Identities
Resources
Infrastructure Domain Incidents
Investigation Decisions
Capturing Volatile Data
Using AWS Systems Manager
Automating the Capture
Conclusion
Contributors
Additional Resources
Media
Third-Party Tools
Industry References
Document Revisions
Appendix A – Examples
Example AWS CloudTrail Event
Example AWS CloudWatch Event
Example Infrastructure Domain CLI Activities
Appendix B – Cloud Capability Definitions
Logging and Events
Visibility and Alerting
Automation
Secure Storage
Custom
1
Information Security Risks Assessment: A Case Study
SAMUEL CRIS AYO, BONAVENTURE NGALA, OLASUNKANMI AMZAT,
ROBIN LAL KHOSHI, SAMARAPPULIGE ISURU MADUSANKA
{u1815973, u1637893, u1709040, u1740368, u1634440}@uel.ac.uk
ABSTRACT
Owing to recorded incidents of Information technology inclined organisations failing to respond effectively to threat
incidents, this project outlines the benefits of conducting a comprehensive risk assessment which would aid
proficiency in responding to potential threats. The ultimate goal is primarily to identify, quantify and control the key
threats that are detrimental to achieving business objectives.
This project carries out a detailed risk assessment for a case study organisation. It includes a comprehensive
literature review analysing several professional views on pressing issues in Information security. In the risk register,
five prominent assets were identified in respect to their owners. The work is followed by a qualitative analysis
methodology to determine the magnitude of the potential threats and vulnerabilities. Collating these parameters
enabled the valuation of individual risk per asset, per threat and vulnerability.
Evaluating a risk appetite aided in prioritising and determining acceptable risks. From the analysis, it was deduced
that human being posed the greatest Information security risk through intentional/ unintentional human error. In
conclusion, effective control techniques based on defence in-depth were devised to mitigate the impact of the
identified risks from risk register.
Keywords: Risks Assessment, Information Security, Security Controls, Risk Register, Risks Appetite.
1. INTRODUCTION
To make sure information or data stored in computers are not at risks of being compromised or tampered with,
organisations need to deploy Information security management techniques. A risk is an effect of uncertainty on
objectives and risk management as the coordinated activities to direct and control an organisation with regard to risk
[1]. Risk management process is the systematic application of management policies, procedures and practices to the
activities of communicating, consulting, establishing the context and identifying, analysing, evaluating, treating,
monitoring and reviewing risk. Risk assessment is the overall process of risk identification, risk analysis and risk
evaluation [1] [2]. Risk management maximises organisation output while minimising chances of unexpected
outcomes [3].
This brings us to security management and why organisations should ensure information security management
systems are in place. Information security management systems preserve the confidentiality, integrity and
availability [4] of information by applying a risk management process and gives confidence to interested parties that
risks are adequately managed. For this report, SparTax Collection Agency (SCA), a medium-sized sub-Sahara
African enterprise is the organisation this report will focus on because African economies are the most vulnerable to
cyber-attacks [5].
Africa is facing several Internet-related challenges concerning security risk, intellectual property infringement and
protection of personal data [6] which has, for instance, cost South African economy $573 million, the Nigerian
economy $200 million, and the Kenyan economy $36 million [6]. Small and Medium-sized Enterprises (SMEs)
account for over 95% of firms and 60%-70% of employment and generate a large share of new jobs in Organisation
for Economic Co-operation and Development (OECD) economies [7]. Similar trends are being observed globally,
and risks brought about by disruptive internet technologies such as the information security breaches. Because SCA
is also an SME just like the majority of other firms globally, the same techniques applied in this report can be
applied across several organisations globally.
2
SparTax Collection Agency (SCA) is an organisation contracted by the Finance Authority of one of the Sub-Sahara
African local governments to collect revenue in the form of taxes. The organisation has to be viewed as that which
uses taxpayers’ information with integrity to meet local government revenue obligations for it to be viewed as that
which focuses on the developmental interests of the local government. SCA deploys a Revenue Management
System (RMS) for all taxpayers account information and revenue management. The RMS is a one-stop platform
where all data is integrated and analysed. It is also integrated online to other third-party systems and tools of partner
agencies and institutions such as ports clearance systems, standards clearance system among others for coordinated
day-to-day operations. In addition, SCA has contracted three other companies (Lamogi+, A&A and PAK) to provide
other services of identifying new taxable businesses, maintaining and monitoring transit cargo real-time. The agency
has also contracted a third-party company MyCloud to provide additional cloud services as a backup to their data
centre.
The agency employs 1550 staff, 100 of which belong to the Information Technology (IT) and Information Security
(IS) department. Among them are 10% of the staff is responsible for Information Security Management (ISM) in the
agency while the rest with various levels of undocumented security clearances are charged with other IT support
services within the company. More than half of SCA’s staffs are on outsourced contract basis or internship and are
on a minimum wage payment plan, which has continuously been an issue of complaint among many staffs who feel
it is unfair. Fig.1 below shows the company’s management organisational structure. All the activities coordination at
SCA are dependent on the support staff at their respective workstations exchanging communications by email,
phone calls or SMS alerts over the public network infrastructure for incidents management and control.
Fig. 1. SparTax Collection Agency (SCA) Organisational Structure
The company has had one general-purpose information security management policy for the last five years, but only
department managers and selected staff members have been adequately trained on the policy. Implementation of the
policy across the company has never been of paramount significance. However, since June 2016, the agency has had
three major security breaches among other minor attempts leading to some undisclosed financial losses to the
company. It is on this background that SCA has been tasked to develop a clear and thorough ISM strategy and report
to be presented to the stakeholders.
Board of Directors
BoD
Chief Executive Officer
CEO
Chief Operations Officer
COO
Chief Information Officer
CIO
Public Relations
Officer PRO
Chief Finance Officer
CFO
Accounts +
Infrastructure Manager
Admin + Legal + Human
Resource Managers
IT + IS
Managers
Secretary
3
In Section 2 below, we shall review five publications relating to cybersecurity, data breach impacts, economic
valuation for Information Security investment, assessing Information Security value in organisations and
Information Security Investment Decisions making. Then under Section 3, we shall describe the scope of our
assessment, identify critical assets for the organisation, their threats and vulnerabilities and proceed to analyse the
results tabulated in the risk register regarding risk appetite, choice and impact of controls. The conclusion of final
work is presented in the last section.
2. LITERATURE REVIEW
2.1 Schatz et al analysed several existing definitions given to cybersecurity [8]. The approach was used to
derive an appropriate definition which was deemed fit based on several factors. These involved identifying the
predominant and acceptable definitions, expressing viewpoints from the contentious differences and finally
concluding on the best match through specific techniques. From the literature review conducted, viewpoints from
several distinct references where weighed against each other and it could be observed that the difference lied
between the scope of the concept, motive, opportunity and form of attack. A series of tools and techniques were
utilised to compare and extract notable similarities amongst top definitions from selected sources. Techniques used
involved inclusion and exclusion criteria which involved refining the search for definitions based on a series of best-
fit conditions. A text mining framework tool was also used to examine keyword similarities before which dataset
were normalised to standardise the character encoding. A stemming process was also carried out to reduce the
number of distinct word types and increase the frequency of occurrence of significant word types. This rigorous
process resulted in attributing values to the selected definitions to create an avenue for comparison. The aim was to
fish out the most relevant attributes from the definition pool. Finally, a co-occurrence network analysis method was
used to craft a new definition using a Minimum Spanning Tree (MST) network graph model in addition to filtering
the term frequency to disintegrate the information to the salient points further. The derived definition was proven to
be representative regarding semantic similarity and not just from a human-derived perspective. It was validated
through the same semantic analysis benchmarking by weighing it up against the existing definition, and it ranked
tops in this analysis.
Just as with any improvement, infallibility cannot be guaranteed, a significant limitation and area of improvement of
this paper has been identified. In my opinion, utilising techniques to determine key similarities from a set of
definitions which has arguably been subjectively deemed viable is not the ultimate approach to derive the most
qualitative and relevant definition. There is a possibility that the selected definitions are not optimum in existence
regarding relevance to what cybersecurity genuinely mean. Although the probability could be very slim, this
research could potentially be a situation of picking out a decent definition from a bad bunch. It is believed that
further analysis of more explicit definitions (including definitions defined in foreign languages) could yield a better-
improved definition. Also, as pointed out by Schatz, Bashroush and Wall [8], the new derived definition stemmed
from an iteration of sentences constructed manually, better still automatic means could be capable of iterating more
combinations leading to a more relevant definition. Nevertheless, the proposed definition has proved to be unbiased
and explicit given that it takes vital points from various viable sources.
2.2 According to Schatz and Bashroush [9], the impact of repeated data breach events on organisations’ market
value, examines the influence of information security breaches on organisations stock market value. The study
adopted the event study methodology, whereby data breaches for businesses category data was obtained from
Privacy Rights Clearinghouse (PRC), analysed and the findings projected to the broader economic impact of such
events. However, the quality and quantity of data obtained from PRC was not sufficient and mainly focused on the
United States of America (USA) based entities as acknowledged by Schatz and Bashroush [9]. The result, therefore,
gave a weak conclusion that organisations stock prize suffers from a publicly announced information security
breach.
4
Irrespective of the sample size, data breaches affect performance and reputation of organisations. Therefore,
organisations and investors should take more initiatives of having secure and continually managed and maintained
information systems. Also, [9] focuses on business breach category and does not factor in government breach
category which although most of them are not publicly traded in the stock market, their reputation, a key asset and to
that matter “value” is affected by breaches.
2.3 Economic Valuation for Information Security Investment: A Systematic Literate Review [10] addresses the
issue of economic evaluation for information security investment. Daniel Schatz and Rabih Bashroush have
conducted a systematic literature review on methods used by organisations to evaluate considered critical elements
of decisions regarding information security investments. They pinpoint out that even if there are researches
conducted to evaluate suitable approaches measuring expenditure of information security, there is a knowledge gap
in practitioners to identify key criteria regarding information security investment. The contributions are a
comparison framework, a catalogue of existing approaches; trends that help navigate existing work. Daniel Schatz
and Rabih Bashroush point out that there is no tangible return on investment and further explains how information
security measures aim to reduce loss. Therefore, it involves identification of current and future threats on assets,
identification of highest valued assets and implementation of controls to reduce or mitigate risks. It further points
out challenges faces by security professionals transferring risks into financial formulas. The Authors present
several
arguments presented by various research papers on multiple approaches taken by organisations.
The authors have conducted a systematic literature review (SLR) to provide structured and systematic methods to
search, examine and evaluate current research questions. It follows the guidance provided by Kitchnham and
Charters [11], Brereton et al. [12], Biochini et al. [13] and Cronin et al. [14]. The authors started the SLR process
with the construction and definition of five research questions. The authors have constructed a search mechanism to
capture relevant material which accommodates defined research questions. The authors have conducted systematic
searches in several databases for research papers. The search scope narrowed on relevance to computer science and
information security field. The results were filtered based on inclusion and exclusion criteria and database
refinements, and it reduced down the results to 270 from 779.
Further reductions have resulted in 25 papers and used for data extractions. Authors have extracted nine important
approach categories. After analysing the results, three main categories were chosen. They are Return on Investment
(ROI), Real Options Theory (ROT), and Utility Maximization (UM).
2.4 This study [15] describes a tested model that key constructs to consider when assessing the value of
organisation information security assets. The research focuses on practitioners and researchers in IT security field
and try to contribute significant knowledge on information security value chains in an organisation. The authors
have proposed an evidence-based model. It combines theoretical work with real-world scenarios for assessing
information security values in an organisation. The proposed model comprises five lament variables namely drivers,
threats, accounting aspects, business environment and security capabilities [16]. They represent the critical areas of
the context, how these lament variables relate to each other was investigated and were analysed. Then it was
examined which relationship is significant using the Partial Least Square – Structural Equation Modelling (PLS-
SEM) [17]. PLS-SEM model enhances support for the proposed model by authors. To verify the proposed model,
authors have collected a high volume of data and analysed using a survey instrument specially designed using the
structured equation modelling (SEM). The authors have emphasised that ignorance of relevant threats could have a
negative impact on the organisation and it has a positive correlation with the security maturity of the environment.
Security capabilities are therefore significant in accomplishing overall business values.
2.5 The study by Daniel and Rabih [18] follows a grounded theory approach focused on information security
investments and handling by experienced practitioners which are condensed into 15 principles. It highlights current
practices, the key drivers and challenges in security investment strategies as well as organisational business
environment factors relevant. Notable in the study is that decisions for Information security investments processes
are initiated by “driving factors” and adjusted by “Challenges and Constraints”. From this study, it’s found that
when information security investments support businesses to safely innovate, increase market agility, and enhance
customer trust, they become competitive as compared to conventional budgeting approaches where funds are
5
directed towards a ‘minimum protection/maximum compliance’ strategy rather than initiatives that contribute the
most value to the organisation. The study illustrates the need to have a decision support process along with
evidence-based approaches to avoid having problems. It encourages the adoption of standards such as ISO/IEC
27001 to identify control areas, not in line with control frameworks and ensures investments add value to an
organisation. When it came to security control effectiveness metrics, it was scarce and so the need to address the
shortfall. Controls that could add overall value to an organisation at comparable costs had multiple benefits. In the
study, practitioners are encouraged to adopt economic value approaches for financial valuations or performance
models to justify security investments. Failure to adopt these values should relegate them to compliance and audit
function. Eventually, risk reduction metrics are to be used to measure Information security program values.
The study [18] brought out the keys investment decision principles but faces a challenge in the diversity scope
which makes the finding partial. The study is however limited to the United Kingdom and a small portion in the
USA, all of which are developed economies compared to the rest of the developing economies. Since information
security is becoming a global issue, the study should be expanded to include the rest of the developing countries as
well, and the criteria for selecting practitioners should be elaborated more clearly.
3. RESULTS AND DISCUSSION
3.1 Purpose
Undertaking the risk assessment is to strategically identify the prominent threats and vulnerabilities that pose to
hinder the organisation from achieving its business objective. The result from the risk register would be utilised in
devising appropriate mitigation plans to reduce identified risk level to the barest minimum.
Fig . 2. Risk Assessment Flowchart (Adopted and modified from [19])
Results Documentation Risk assessment report
System Characterization
Threat Identification
Vulnerability
Identification
Likelihood Determination
Risk Valuation
Control Recommendation
Delineation of system
boundary
Interrogation of asset owners
Track record of previous attacks
List of threats for SCA
Interrogation of asset owners
Penetration test on assets
List of vulnerabilities for SCA
Track record of previous attacks
Interrogation of asset owners
Threat severity
Likelihood valuation
Quantification of combined
effect of asset, threat and
vulnerability i.e. A*T*V
Risk Register
Identified acceptance
level
risk
Recommended controls
Hardware, Software and other IT
systems within the scope of SCA
Risk Assessment Actions
6
3.2 Risk assessment methodology flowchart
The Fig.2 above gives a diagrammatic representation of the risk assessment methodology flowchart. It
includes an orderly step-by-step process of the stages involved in carrying out the risk assessment for the
organisation.
3.3 Scope and assets identified
After project sizing, we examine ISM of the significant assets to SCA according to management requirements. As
stated under the Introduction Section, SCA is a model organisation depicting the general trends in the ISM in sub-
Sahara Africa. We have followed a structural process to identify the organisation assets and their values using
TABLE.1, then identify and collect similar threats and vulnerabilities from the respective asset owners.
Eventually, we quantify the likelihood and impact of these threats with a commonly adopted industry model as
elaborated later below.
Asset
Values
Type of
effect
level
of effect
Company
embarrassment
level
Personal
safety
implication
Personal
privacy
infringement
Failure to
meet legal
obligations
Financial
loss (£)
Disruption to
activities (£)
(time & effort
to recover
from incident)
1 Insignificant Contained
within Work
Area at
worst
Minor
injury to
individual
Isolated
personal
detail
revealed
Civil suit
resulting in
less than £10k
damages
Up to 10k Up to 10k
2 Minor Contained
within
Company at
worst
Minor
injury to
several
people
Isolated
personal
detail
compromised
Civil suit
(above £10k).
Small fine (up
to £1k)
10k to
100k
10k to 100k
3 Significant Local public or
Press become
aware
Major
injury to
individual
Several
personal
details
revealed
Large fine
(above £10k)
100k to
500k
100k to 500k
4 Major National public
or Press become
aware
Major
injury to
several
people or
death of
individual
Several
personal
details
compromised
Custodial
sentence
imposed
500k to
1000k
500k to 1000k
5 Acute Senior Staff
forced to resign
or Company
fails
Death of
several
people
All personal
details
revealed
and/or
compromised
Multiple civil
or criminal
suits
Above
1000k
Above 1000k
TABLE.1 Asset Values using Impacts of Incidents Matrix
On review, justifications and approval from management of the completed project sizing, we summarized the top
five valuable assets as Pure Information in the form of Electronic data (data at rest, data in use and data in motion)
without which SCA’s business operations would be close to impossible, Physical IT hardware (mainly as Servers
and End User Electronics) which provide the technical supporting platforms on which all the organisation operates.
The other vital assets included the software Revenue Management System (RMS) used to process and manage
business information processes, Organisation Reputation (intangible asset) which determines whether its business
7
contracts be maintained or terminated in subsequent years and the Human Resource (staff) that are pillar in the
operational success of the organization and are also the weakest link in the security chain.
3.4 Risk register
Using Qualitative Risk Analysis approach, this Section presents the detailed Risk Register framework for the
organisation, highlighting assets threats, vulnerabilities and risks impact. A Threat is a potential cause of an incident
that may result in harm to a system or organisation; Vulnerability is a weakness of an asset or group of assets that
may be exploited by one or more threats and Impact is the result of Information Security incident, caused by a threat
which affects assets [20] [1] [4]. A risk assessment approach is used to identify vulnerabilities, threats and impacts
to which security controls will be applied.
Because of the logical simplicity and wide adaptability across several organisations, we have adopted the Asset
Values and Impacts Matrix (TABLE. 1) to get a qualitative value of assets affected by risk incidents; Threat and
Vulnerability Likelihood Table (TABLE .2) to quantify threat occurrences possibilities and quantify the degree of
vulnerability. It should be noted that the weighing and values/figures in these tables are not fixed based on any
known standard but rather on the logical significance of the interpretation as deemed fit by the organisation. In this
report, the asset owners are responsible for accurately collecting the threats and vulnerabilities of every asset and the
respective occurrences likelihood potentials whereas asset owners and suppliers are responsible for the value of the
assets to be used in the Risks Register generated in TABLE .3 below.
LIKELIHOOD
DESCRIPTION
INTERPRETATION
1 Negligible Once every 1000 years or less
2 Extremely Unlikely Once every 200 years
3 Very Unlikely Once every 50 years
4 Unlikely Once every 20 years
5 Feasible Once every 5 years
6 Probable Annually
7 Very Probable Quarterly
8 Expected Monthly
9 Confidently Expected Weekly
10 Certain Daily
TABLE.2 Threats and Vulnerability Likelihood Table
8
TABLE.3 Risk Assessment Register (the different assets in colour code)
RISK LINE ID No. Assets Owner Values (A) Threats
Likelihood
(T)
Vulnerabilities
Likelihood
(V)
Risks
(A*T*V)
16 Electronic Data CIO 5 Human error 8 Mental Stress 9 360
18 Electronic Data CIO 5 Human error 8 Employees Physical fatigue 9 360
17 Electronic Data CIO 5 Human error 8 Fear to Consult 8 320
14 Electronic Data CIO 5 SQL Injections 6 Execution of malfunctioned queries irrespective of warnings 9 270
15 Electronic Data CIO 5 SQL Injections 6 Outdated DBMS 9 270
2 Reputation CEO 5 Data breach 6 Existence of backdoor 8 240
7 Ruputation CEO 5 Fraud 6 Disgruntled employees 8 240
13 Electronic Data CIO 5 SQL Injections 6 Bad coding Designs 8 240
1 Reputation CEO 5 Data breach 6 Outdated Security Software 7 210
3 Reputation CEO 5 Data breach 6 Reliance of reputation on trust 7 210
25 Revenue Management System CIO 3 Cross-Site Scripting 7 Susceptibility to Malicious code 10 210
27 Revenue Management System CIO 3 Cross-Site Scripting 7 User input support through input field 10 210
4 Reputation CEO 5 Misuse of resources 6 Staff dishonesty 6 180
5 Reputation CEO 5 Misuse of resources 6 Unclear resources utilization guidelines 6 180
6 Reputation CEO 5 Misuse of resources 6 Poor resource management 6 180
8 Ruputation CEO 5 Fraud 6 Unclear System Access Clearance guidelines 6 180
9 Ruputation CEO 5 Fraud 6 Staff dishonesty (Integrity loss or failure) 6 180
11 Electronic Data CIO 5 Data theft 6 Disgruntled employees 6 180
12 Electronic Data CIO 5 Data theft 6 Disposal of Storage media without proper erasure 6 180
26 Revenue Management System CIO 3 Cross-Site Scripting 7 Support for various unsafe scripting technologies. 8 168
34 IT Hardware CIO 2 Power interruptions 9 Inability to operate without power supply 9 162
36 IT Hardware CIO 2 Power interruptions 9 Fluctuating power supply (Unstable Power Supply) 9 162
37 Staff COO 2 Social engineering 9 Human tendency to be gullible (getting something for nothing) 9 162
38 Staff COO 2 Social engineering 9 Inclination for immediate gratification 9 162
150
39 Staff COO 2 Social engineering 9 Inclination to Improved status gain 9 162
23 Revenue Management System CIO 3 Stack-Overflow attacks 6 Weaknesses in the programming language used to develop the systems 8 144
24 Revenue Management System CIO 3 Stack-Overflow attacks 6 Zero-day vulnerabilities 8 144
35 IT Hardware CIO 2 Power interruptions 9 Inability of backup power (UPS) to sustain long hours 8 144
19 Revenue Management System CIO 3 Denial Of Services 6 Low Memory Resources 6 108
20 Revenue Management System CIO 3 Denial Of Services 6 Limited Bandwidth 6 108
21 Revenue Management System CIO 3 Denial Of Services 6 Protocols in use such as Telnet 6 108
22 Revenue Management System CIO 3 Stack-Overflow attacks 6 Bad coding habits 6 108
42 Staff COO 2 Illness (Health) 7 Illnesses due to change of weather 7 98
10 Electronic Data CIO 5 Data theft 6 Breaching legal requirements 3 90
28 IT Hardware CIO 2 Heat 6 Susceptibility of Equipments to temperature variations 7 84
30 IT Hardware CIO 2 Heat 6 Susceptibility of Solder joints to melt at high temperatures 7 84
40 Staff COO 2 Illness (Health) 7 Weak immune systems due to genetic variations 6 84
41 Staff COO 2 Illness (Health) 7 Incomplete Immunisation to Common Diseases 6 84
43 Staff COO 2 Accidents 6 Ignorance to Precautions 7 84
44 Staff COO 2 Accidents 6 General carelessness and forgetfulness 7 84
45 Staff COO 2 Accidents 6 Tendency to take risks, being fearless 7 84
29 IT Hardware CIO 2 Heat 6 Susceptibility of Processor Chips to melt at high temperatures 6 72
31 IT Hardware CIO 2 Humidity 4 Non-water resistant Equipments 8 64
33 IT Hardware CIO 2 Humidity 4 Susceptibility to short circuiting due to water/moisture contact 7 56
32 IT Hardware CIO 2 Humidity 4 Susceptibility to corrosion due to rusting 5 40
ABOVE RISK
APPETITE
BELOW RISK
APPETITE
RISK APPETITE
9
3.5 Analysis
3.5.1 Risk Appetite
Risk appetite is the amount and type of risk that an organization is prepared to pursue, retain or take [21]. The
organisation management establishes the risk appetite.
Threat Impact Levels Heat Levels
ACUTE [Avoid]
MAJOR [Avoid]
SIGNIFICANT [Mitigate]
MINOR [Transfer] 2,10,10
INSIGNIFICANT
[Accept]
1,10,
10
<30% 30% 40% 50% 60% 70% 80% 90% 100%
Threat Occurrence Possibilities/Likelihoods
TABLE.4 Risk Register heat map
From the risk register in the TABLE.3, the Heat map (TABLE.4) is derived which is then shared with management
to determine the Risk Appetite. For this organisation, the risk appetite line is set midway between (asset, threat,
vulnerability) values (1, 10, 10) and (2, 10, 10) which respond to risks equal to 100 and 200 respectively. Our Risk
appetite is therefore 150. Any threat above this appetite is not acceptable and must be avoided or controlled whereas
any risks below 150 appetite line can be tolerated but subjected to handling guidelines of the organisation as
specified in the ISM policies. Threats categorised as acute, major and critical (RED) have to be avoided and
eliminated. Significantly harmful threats (YELLOW) are to be reduced by mitigation. Minor threats (GREEN)
should be transferred by collaborating with an insurer whilst accepted insignificant threats need to be monitored.
3.5.2 Impact Controls
Controls are those activities that are taken to manage identified risks [22]. A control or countermeasure is placed to
modify the risks and to counter threats. Controls can be used to prevent, deter, deflect, mitigate, detect and recover
from a security breach, incident or compromise. The possibility for harm to is called risk [23]. ISO/IEC 27001
determines controls by design or from other sources. Some of the sources are the code of practice and industry
standards. Although not all institutions can afford to purchase, install, operate and maintain expensive security
controls and related systems, the decisions on security controls to be applied have to balance considerations of
security risk and resource constraints. The identified control sets will change risks identified in the risk assessment
process. They will be able to work together to reduce risks. For the implemented controls, it is vital to check whether
new controls conflict with existing controls and whether there is any redundancy or how effectively they will work
together.
The risk register in TABLE.3 identifies Electronic Data, Reputation, Revenue Management System and Staff as
high-risk assets. The control mechanisms to be applied in this assessment will aim at achieving the highest
preventive techniques/controls of the respective threats. We shall adopt all three categories of control measures that
include administrative, Technical and physical. Combination of specific information security policies in line with
ISO270001 and NIST, elaborate monitoring, preventive, corrective, deterrent and discovery technical tools/measures
and physical security techniques are best suited for effective controls. Therefore for effective information security
adopting Least Privilege, Defense in Depth and separation of duties security principles approach, we incorporate
several controls measures proposed below to eliminate, reduce, transfer or let the risks be accepted.
Acceptable RISK
APPETITE:
150
NOT
Acceptable
Critical
Safe
Warning
Monitor
10
Least Privilege Security: no communications or activities to be permitted unless there is a need [3].
Defence in depth Security: use of multiple security techniques or layers of control to reduce exposure if one
security control is compromised [3].
Separation of Duties: minimise errors and make it more difficult to exploit access privileges for personal gain [3].
Administrative Controls
Use of “soft controls” like policies, change control, user registration, visitors logs, punishment for failure to comply,
roles, responsibilities and job descriptions. The following are specific Information Security Policies to ensure
proper information security culture in the organisation: Encryption policy, Secure Data Transmission Policy, data
lifecycle policy, Clean desk policy, Data breach policy, Digital signature acceptance policy, Disaster recovery plan
policy, Email policy (cooperate emails labelling according to origin for easy identification of phishing emails), Non-
disclosure agreement for service providers, Ethics policy, Password protection and construction policy, Security
response plan policy. Acceptable Use Policy (AUP) can be used to reduce risks regarding the organisation’s
resources particularly IT systems. These policies will ensure social engineering and human error control and the
overall information security management in the organisation will be improved. The policies should be reviewed
every two (2) years. Implement continues information security awareness and Policies training. As an administrative
control should also set up guidelines for competent and skilled personnel hiring along with Pre-employment
background checks to control hiring fraudulent incompetent staff. Eventually, adopt Data classification and
labelling, Separation of duties and Job rotations.
Technical Controls
The organisation should implement secure architecture with updated Firewalls, intrusion detection (IDS)/intrusion
prevention (IPS) and Data Leakage Prevention (DLP) systems, Virus scanners, patch management, antispyware,
Demilitarized Zones to control against data breaches, SQL injections, cross-site scripting and data theft. Data
encryption should be enforced to provide data confidentiality, role-based access and account management control to
manage staff access to information, Virtual Private Networks to provide secure communication channels. Routine
data backups and server images for fail recovery, audit logs for routine review abnormal behaviours in the systems.
Physical Controls
Use of mantraps and locks to equipment rooms, security guards and CCTV to provide deterrent and detective
controls, Badges, biometric access and swipe cards for access control against unauthorised access to facilities and
equipment. The installations and use of backup power generators and batteries will provide control on power
disruptions that affect the IT hardware and physical security.
3.5.3 Compensating Controls
A compensating control is one that meets the intent of the standard by reducing the exposure to an acceptable level,
but it may not match the prescribed control in the standard or policy [3]. It is common that control objectives may
not be fully achieved; hence, risks of irregularities in the business may exist. Management must therefore evaluate
the cost-benefit of implementing additional controls called compensating controls to reduce the risks further [24].
Compensating controls include the Administrative, Technical or Logical and Physical elements as already been
highlighted above.
3.5.4 Residual Risks
This is the remaining risk exposure level after implementing the recommended controls. It is calculated the same
way as elaborated in earlier sections above. We should now be able to provide the management with before and after
snapshots of how the recommended controls will lower the risks to the organisation [3].
11
4. FUTURE EXPANSIONS
A further expansion of this project would worth considering the cost-to-benefit repercussion of implementing the
stated controls. Thomas talks about a refined Facilitated Risk Analysis, and Assessment Process (FRAAP)
formulated from the bedrock of ISO 17799 which explains an optimised risk assessment process that takes into
consideration the cost effectiveness of suggested control measures [25]. He made it clear that the existence of a
threat does not necessarily mean an organisation is at risk.
The ultimate goal for mitigating risks is to protect the organisation’s resources while ensuring the business maintains
its objectives and mission. Hence, there could be situations whereby suggested controls could become infeasible for
the organisation. Implementing some controls could ironically be the threat that leads to a business downfall.
Controls should be practicable as such that the end justifies the means. Quantifying the overall cost of implementing
each of the stated controls against the organisation’s capability to implement them would create a room to determine
what controls should be alternated for a compensating control as discussed in section 3.3.3.
5. CONCLUSIONS
In summary, we identified five key organisation assets electronic data, IT hardware, organisation reputation, the
RMS software and staffs. The main threats faced by these assets are human errors from staffs, SQL injections, data
breaches, fraud, cross-site scripting, data theft, social engineering and power interruptions that are responsible for
the most prominent information security risks in the organisation. Appropriate industry-standard administrative,
technical and physical controls have been employed to prevent, detect, mitigate and reduce the exploitation of
vulnerabilities detected with the assets.
One fundamental limitation of this report is the scope of assets used. It is very rare to have an organisation with only
five key assets. We strongly recommend that ISM practitioners work hand in hand with all stakeholders to ensure
accurate information for all assets and their vulnerabilities are obtained. However, it should be noted that from this
report, one should be able to follow systematically the processes and technicalities undertaken in preparing an
information security risk assessment and management report. Irrespective of the choice of organisation for this
report, the same principles used in this report apply globally to all industry sectors.
In this organisation report, a qualitative approach was used to assess the risks. However, other organisations would
prefer to adopt more quantitative approaches which use hard metrics, such as pounds or dollars. It will be common
to find other terms like exposure factors, single loss expectancy, the annual rate of occurrences, annualised loss
expectancy and total cost of ownership that all end up being used to address the same issue of risks management. On
combining with Risk Analysis, the Total Cost of Ownership and Return on Investment calculations should factor
into proper budgeting.
12
REFERENCES
[1] ISO/IEC, Guide 73:2002 Risk Management Vocabulary Guidelines for use in standards, 2002.
[2] BSi and ISO/IEC, Information Technology- Code of Practice for Information Security Management, BSi ISO/IEC
17799:2000, 2000.
[3] W. Evan, Security Risk Management, Waltham: Syngress, 2011.
[4] C. Mike, S. David, M. ,. James and G. Darril, (ISC)2 CISSP certified information systems security professional official
study guide, 8E & CISSP official (ISC)2 practice tests, 2E., Indianapolis Sybex, 2018.
[5] Y. Shi, “African economies most vulnerable to cyber attacks: experts,” Xinhua News, 29 3 2018. [Online]. Available:
http://www.xinhuanet.com/english/2018-03/29/c_137075200.htm. [Accessed 26 11 2018].
[6] UN, “Policy Brief : Tackling the challenges of cybersecurity in Africa,” United Nations Economic Commission for Africa,
2014.
[7] OECD, “Small and Medium-sized Enterprises: Local Strength, Global Reach,” 2000.
[8] S. Daniel, B. Rabih and W. Julie, “Towards a More Representative Definition of Cyber Security.,” Journal of Digital
Forensics, Security and Law, vol. 12, no. 2, 2017.
[9] S. Daniel and B. Rabih, “The impact of repeated data breach events on organisations’ market value,” Information &
Computer Security, vol. 24, no. 1, pp. 73-92, 2016.
[10] S. Daniel and B. Rabih, “Economic valuation for information security investment: a systematic literature review.,”
Information Systems Frontiers, pp.1-24., pp. 1-24, 2016.
[11] B. Kitchman and S. Charters, “Guidelines for performing systematic literature reviews in software engineering,” 2007.
[12] B. Pearl, A. K. Barbara, B. David, T. Mark and K. Mohamed, “Lessons from applying the systematic literature review
process within the software engineering domain,” Journal of Systems and Software, vol. 80, no. 4, pp. 571-583, 2007.
[13] J. Biolchini, P. Mian, Ana and G. Travassos, “Systematic Review in Software Engineering.,” 2005.
[14] P. Cronin, F. Ryan and M. Coughlan, “Undertaking a literature review: a step-by-step approach. (Mark Allen Publishing),”
British Journal of Nursing, vol. 17, no. 1, pp. 38-43, 2008.
[15] S. Daniel and B. Rabih, “A Structural Model Approach for Assessing Information Security Value in Organizations,”
International Journal of Strategic Decision Sciences, vol. 9, no. 4, 2018.
[16] J. Pettigrew and J. Ryan, “Making Successful Security Decisions: A Qualitative,” IEEE Security & Privacy, vol. 10, no. 1,
pp. 60-68, 2012.
[17] N. Kock, “Using WarpPLS in e-collaboration studies: An overview of five main analysis steps. Advancing Collaborative
Knowledge Environments: New Trends in ECollaboration: New Trends in E-Collaboration,” 2011.
[18] S. Daniel and B. Rabih, “Corporate Information Security Investment Decisions: A Qualitative Data Analysis Approach,”
International Journal of Enterprise Information Systems, vol. 14, no. 2, 2018.
[19] G. Stoneburner, A. Goguen and A. Feringa, “Risk Management Guide for Information Technology Systems,” NIST
Publication 800-30, 2002.
[20] ISO/IEC:13335, Information technology — Security techniques — Management of information and communications
technology security, 2004.
[21] ISO:31000, Risk management — Guidelines, BSI Standards Publication, 2018.
[22] W. Michael and M. Herbert, Management of Information Security. 3rd ed., Course Technology. Cengage Learning, 2010.
[23] C. P. Pfleeger and S. L. Pfleeger, Analyzing Computer Security, Michigan: Prentice hall., 2011.
[24] F. T. Harold and K. Micki, Information Security Management Handbook, Auerbach Publications, 2007.
[25] T. R. Peltier, Information security risk analysis, Boca Raton : CRC Press, 2010.
[26] J. D. Lenaeus, L. R. O’Neil, R. M. Leitch, C. S. Glantz, G. P. Landine, J. L. Bryant, J. Lewis, G. Mathers, R. Rodger and C.
Johnson, “How to Implement Security Controls for an Information Security Program at CBRN Facilities,” UNICRI Project
19, 2015.
13
[27] C. P. Pfleeger and S. L. Pfleeger., “Analyzing Computer Security, A Threat/Vulnerability/Countermeasure Approach.,”
2012.
[28] E. Humphreys., “Implementing the ISO/IEC 27001 ISMS Standard. Second Edition.”.
[29] ISO/IEC:13335, Information technology — Security techniques — Management of information and communications
technology security, 2004.
[30] C. P. Pfleeger and S. L. Pfleeger, Security in Computing.4th edition, Prentice hall., 2007.
SANSInstitute
Information Security Reading Room
Case Study: Critical Controls
that Could Have Prevented
Target Breach
______________________________
Teri Radichel
Copyright SANS Institute 2020. Author Retains Full Rights.
This paper is from the SANS Institute Reading Room site. Reposting is not permitted without express
written permission.
http://www.sans.org/info/36909
http://www.sans.org/info/36914
!
[1.0%August%2014]%
!
! !
Case Study: Critical Controls that Could Have
Prevented Target Breach
GIAC (GSEC) Gold Certification
Author:
Teri Radichel, teri@radicalsoftware.com
Advisor: Stephen Northcutt
Accepted: August 5th 2014
Abstract
In December 2013 over 40 million credit cards were stolen from nearly 2000 Target
stores by accessing data on point of sale (POS) systems. This paper will explore known
issues in the Target breach and consider some of the Critical Controls that could have
been used to both prevent this breach and mitigate losses. From what is known about the
Target breach, there were multiple factors that led to data loss: vendors were subject to
phishing attacks, network segregation was lacking, point of sale systems were vulnerable
to memory scraping malware and detection strategies employed by Target failed. A
possible solution for preventing and mitigating similar breaches using a defense in depth
model will be presented using a multi-layered security strategy. Considerations of human
factors that contributed to the losses in this case will also be addressed.
Case Study: Critical Controls that Could Have Prevented Target Breach! 2
Teri Radichel, teri@radicalsoftware.com
1. Introduction
Target shoppers got an unwelcome holiday surprise in December 2013 when the
news came out 40 million Target credit cards had been stolen (Krebs, 2013f) by
accessing data on point of sale (POS) systems (Krebs, 2014b). Target later revised that
number to include private data for 70 million customers (Target, 2014). The breach
transpired between November 27 and December 15th 2014 (Clark, 2014). Over 11 GB of
data was stolen (Poulin, 2014). Target missed internal alerts and found out about the
breach when they were contacted by the Department of Justice (Elgin, 2014).
A series of steps were taken by the adversaries to obtain access to the credit card
data and retrieve it from Target’s systems. A break down in detection further increased
data loss. Sources suggest the breach transpired as follows:
1. Reconnaissance by attackers may have included a Google search that would
have supplied a great deal of information about how Target interacts with
vendors. Results would have revealed a vendor portal and a list of HVAC and
refrigeration companies (Krebs, 2014g). This reconnaissance would have also
revealed a detailed case study on the Microsoft web site that describes how
Target uses Microsoft virtualization software, centralized name resolution and
Microsoft System Center Configuration Manager (SCCM), to deploy security
patches and system updates. The case study describes the Target technical
infrastructure, including POS system information, in significant detail
(Microsoft, 2011).
2. An email containing malware was sent to a refrigeration vendor, Fazio
Mechanical, two months prior to the credit card breach. Malware installed on
vendor machine may have been Citadel – a password-stealing bot program
that is a derivative of the ZeuS banking trojan. The malware stole credentials
to an online vendor portal (Krebs, 2014d).
3. Next the criminals accessed Target’s systems via Fazio Mechanical’s
credentials via a vendor portal (Krebs, 2014d).
Case Study: Critical Controls that Could Have Prevented Target Breach! 3
Teri Radichel, teri@radicalsoftware.com
4. From this pivot point the attackers could have further infiltrated the network.
The specific details are not available but we can speculate that the criminals
used the used the attack cycle described in Mandiant’s APT1 report to look
find vulnerabilities in the vendor portal move laterally through the network via
back doors, reconnaissance and other vulnerable systems (Mandiant, 2014a).
Common network tools were used to do reconnaissance once inside the
network (iSight Partners, 2014).
5. Another Mandiant report on data breach trends describes how reconnaissance
in a retail attack uncovered misconfigured systems. A vulnerable domain
controller that could then be used to obtain access to POS systems. (Mandiant,
2014b). The Microsoft Target Case Study states “Except for centralized
authentication, domain name resolution, and endpoint monitoring services,
each retail store functions as an autonomous unit” (Microsoft, 2011) so the
attacker would know to look for these pivot points.
6. Once access was obtained to the necessary systems, malware was installed on
point of sale systems (Steinhafel, 2012). The number of POS machines that
were compromised in a short amount of time indicates that the software was
likely distributed to them via an automated update process. A Dell
SecureWorks report explains how the malware was installled using SCCM
(Jarvis & Milletary, 2014). The malware was custom software, undetectable
by virus scanners (Krebs, 2014a).
7. The software gathered credit card information from memory as cards were
swiped (Krebs, 2014b). The data was saved to a .dll file and stored in a
temporary NetBios share over ports 139, 443 or 80 (iSight Partners, 2014).
8. Components used by attackers communicated via an ICMP tunnel (Warner,
2014). The ICMP traffic consisted of PING packets with custom text messages
to indicate data movement from POS machines to compromised machine on
the corporate LAN (iSight Partners, 2014).
Case Study: Critical Controls that Could Have Prevented Target Breach! 4
Teri Radichel, teri@radicalsoftware.com
9. Other customized components were used to send raw commands over the
network that would not be discoverable by common network forensics tools
and bypass network controls (iSight Partners, 2014).
10. Reports indicate data was retrieved using the default user name and password
for BMC’s Performance Assurance for Microsoft Servers (Krebs, 2014e).
11. Data was moved to drop locations on hacked servers all over the world via
FTP. Hackers retrieved the data from drop locations which hackers accessed
to retrieve it (Krebs, 2014h).
12. While the attack was in progress, monitoring software (FireEye) alerted staff
in Bangalore, India. They in turn notified Target staff in Minneapolis but no
action was taken (Elgin, 2014).
13. Credit cards were then sold on the black market (Krebs, 2013c).
The cost of the breach was far reaching to both Target, customers, employees and
banks. High-ranking employees lost their jobs including the CEO (Gonsalves, 2014) and
CIO (Baldwin, 2014). Members of Target’s board of directors were threatened with
removal (Lublin, 2014). Banks had to refund money stolen from customers via their
credit cards and pay for replacement cards costing more than $200 million
(D’Innocenzio, 2014). Banks refunded most funds stolen from credit and debit cards, but
identity theft was at an all time high in the first half of 2014 due to large data breaches
including Target (Murray, 2014). More than 140 lawsuits have been filed against Target
(Webb, 2014). Banks sued Target’s PCI compliance auditor, Trustwave (Schwartz M. J.,
2014). Target is dealing with investigations involving the Department of Justice
(Hosenball, 2014), the FTC (Risen, 2014) and SEC (Michaels, 2014). Individual state
laws may result in fines and legal proceedings over and above PCI compliance fines.
States are passing even stricter laws as a result of recent breaches (Grande, 2014). Profits
dropped 46% in the fourth quarter of 2013 during the critical holiday season (Ziobro,
2014). Customer visits dropped in the new year prolonging the losses (Halkias, 2014).
Case Study: Critical Controls that Could Have Prevented Target Breach! 5
Teri Radichel, teri@radicalsoftware.com
Target passed PCI compliance audits prior to this breach, indicating they had
implemented security required by the credit card processing industry (Schwartz M. J.,
2013). Fazio Mechanical issued a statement claiming they were compliant with industry
standard information security regulations (Fazio, 2014). We can learn from the Target
breach that compliance with baseline standards isn’t enough (Mellow, Jr., 2014). A
comprehensive approach to security will consider all assets, not just those that fall under
compliance regulations. Each asset has a specific set of threats and vulnerabilities that
can be considered as part of a risk management program, rather than simply
implementing what is mandated for a subset of assets. As demonstrated in this breach,
many different assets were used to move throughout the network, so consideration of the
POS systems alone would not address the root causes that led up to this attack.
This paper explores a more holistic approach to security. Risk management
assesses and prioritizes security needs based on what can cause the most damage to a
company (SANS Institute, 2014b, p. 217), rather than relying on legal or industry
standard compliance. Defense in depth makes use of multiple layers of protection (SANS
Institute, 2014a, p. 6). The Critical Controls (SANS Institute, 2014c) are recommended
that may have either prevented this breach or mitigated the impact. Controls include not
only technology but also people who must audit, analyze and manage systems and
perform incident response activities. The Target breach is then replayed to demonstrate
an alternate scenario had this strategy been employed.
2. Security Strategy
2.1. Risk Management
PCI compliance alone is not a risk management strategy. Only assets related to
payment card processes are considered. Many businesses approach PCI compliance by
trying to minimize what is in scope for the PCI audit. Assets and implementation details
that may pose the greatest risks to the organization may fall outside of this scope and
therefore not be adequately addressed if PCI alone drives a business security decisions.
For example, at the time of the breach, the current PCI standard says consideration should
be made for data stored in memory but no specific requirements are defined (PCI
Case Study: Critical Controls that Could Have Prevented Target Breach! 6
Teri Radichel, teri@radicalsoftware.com
Security Standards Council, 2013a). Regulations cannot be developed, written and agreed
upon as fast as attackers can change their tactics. In fact, standards may inform
adversaries what security measures a business has implemented, so the attacker will
likely attack vulnerabilities not on the compliance checklist and assets that are out of
scope for PCI compliance audits. Even if the standards tried to define a complete security
checklist, auditors would likely not be able to find every infraction.
Vanessa Pegueros, CISO of DocuSign says: We are going through our PCI audit
right now. PCI Auditors cannot be expected to find every vulnerability and
security problem. The field is too complex and broad and auditors are not paid
enough nor do they have the expertise to go to that level of detail needed to
address the true risks. It is just not a cost effective exercise to try and find every
problem that exists (V. Pegueros,
personal communication, 2014).
Rather than relying on a mandated checklist, organizations will be better able to
mitigate losses by performing organization-wide risk management activities on a regular
basis. Vulnerabilities are system weaknesses that can be exploited. Threats are events that
have negative consequences. Threats and vulnerabilities for all systems, not just those
within scope for compliance audits, are identified. Threats and vulnerabilities are then
prioritized and fixed to limit risk to an acceptable level (SANS Institute, 2014b, pp. 214-
241). Constant re-evaluation is required as the threat landscape is always changing.
After threats and vulnerabilities
are identified for all systems, the risk
posed by each is carefully analyzed.
Generally, the vulnerabilities with the
highest likelihood of occurring and
most severe consequence in terms of
cost to the organization should be
prioritized highest and fixed first. This
has nothing to do with compliance and
everything to do with what poses the
greatest risk to the organization.
Figure 1 Risk Analysis Matrix
(Sans Institute, 2014b, p. 217)
Case Study: Critical Controls that Could Have Prevented Target Breach! 7
Teri Radichel, teri@radicalsoftware.com
Threat modeling and risk management in entirety is outside the scope of this
paper, but it is important to understand that a reliance on mandated compliance guidelines
was not enough to protect Target from monumental data loss. Threat Modeling:
Designing for Security by Adam Shostack (Shostack, 2014) covers this topic in depth.
Hacking Point of Sale: Payment Application Secrets, Threats and Solutions by Slava
Gomzin (Gomzin, 2014) presents specific vulnerabilities for POS systems. Companies
can also use common risk frameworks such as ISO 27001/27002/27005 or NIST 800-
30/800-53 (J. Popp, personal communication, 2014).
Businesses need to employ an adequate number of security professionals who
understand the business, the risks and the potential loss. Security staff needs to be vigilant
to understand new potential threats and vulnerabilities when they appear. New attacks
may appear in internal system logs or be reported in the industry as vulnerabilities or
security incidents or events. Organizations must understand that Advanced Persistent
Threats (APTs) are targeting them and the nature of the attacks (Ferraro, 2013).
2.2. Defense in Depth
“A security system is only as strong as its weakest link” (Ferguson, Schneieir, &
Tadayoshi, 2010). If you install a large, strong gate at the front of your property, but a
hole exists in the back fence large enough for a thief to enter, the gate can easily be
bypassed. Installing cameras to watch the hole in the back fence with, but not hiring
someone to monitor the cameras 24 x 7 will not prevent a burglary and renders the
cameras ineffective. Recent breaches demonstrate that persistent adversaries are
constantly seeking the weakest link to obtain access systems to steal data. Defense in
Depth is a layered approach to security created by the National Security Agency (NSA).
A single protection may fail so multiple levels of protections and controls are employed
to protect business assets (SANS Institute, 2014a, p. 6).
Many businesses that have experienced recent major breaches employ encryption
strategies. Unfortunately, encryption is often not properly implemented and deployed.
Encryption in and of itself does not protect systems. A robust security strategy is required
which protects entire systems in a comprehensive way in order for encryption to be
effective. For example, an encryption algorithm and large key may become useless if you
Case Study: Critical Controls that Could Have Prevented Target Breach! 8
Teri Radichel, teri@radicalsoftware.com
have the encryption key stored with the data. The hackers or malicious insiders will
simply gain access to the system and use the key to unencrypt the data (Ferguson,
Schneieir, & Tadayoshi, 2010, p. 12). For encryption to be effective, you must employ a
defense in depth strategy in which you also protect the key and protect access to systems
where the data needs to be unencrypted in order to be processed.
Target reportedly spent a great deal of money on security technology (Capacio,
2014). Although systems used encryption, the encryption was rendered useless because
the data was accessed in memory where it was unencrypted. Although some level of
segregation likely existed, vulnerable configuration and accounts allowed segregation
strategies to be bypassed. Despite the fact that they purchased expensive monitoring
software, staff was not sufficient, not well-trained or inadequate processes turned those
systems into a liability rather than an asset when it was determined that Target was
notified, but did nothing to stop the breach.
Defense in Depth requires layers of security, but the weakest link in each layer
may provide access to the next. It appears that there were vulnerabilities in each layer of
defense employed by Target that ultimately allowed the attackers to gain access to some
of their most sensitive data.
2.3. Critical Controls
In 2008, the federal government arranged a consortium of public and private
organizations to come up with a list of Critical Controls based on various other cyber
security lists and guidelines. Critical Controls are added to the list because they help
prevent and detect known attacks effectively (SANS Institute, 2014d). The Consortium
for Cybersecurity Action (CCA) regularly updates the Critical Controls (Dell Secure
Works, 2014). The following table lists the 20 Critical Controls. The Sans Institute web
site provides more details about each control at http://www.sans.org/critical-security-
controls (SANS Institute, 2014c).
The 20 Critical Controls
1: Inventory of Authorized and Unauthorized Devices
2: Inventory of Authorized and Unauthorized Software
3: Secure Configurations for Hardware and Software on Mobile Devices, Laptops,
Case Study: Critical Controls that Could Have Prevented Target Breach! 9
Teri Radichel, teri@radicalsoftware.com
Workstations, and Servers
4: Continuous Vulnerability Assessment and Remediation
5: Malware Defenses
6: Application Software Security
7: Wireless Access Control
8: Data Recovery Capability
9: Security Skills Assessment and Appropriate Training to Fill Gaps
10: Secure Configurations for Network Devices such as Firewalls, Routers, and Switches
11: Limitation and Control of Network Ports, Protocols, and Services
12: Controlled Use of Administrative Privileges
13: Boundary Defense
14: Maintenance, Monitoring, and Analysis of Audit Logs
15: Controlled Access Based on the Need to Know
16: Account Monitoring and Control
17: Data Protection
18: Incident Response and Management
19: Secure Network Engineering
20: Penetration Tests and Red Team Exercises
Figure 2 The 20 Critical Controls (SANS Institute 2014c)
3. Security Strategy Applied to Target Case
3.1. Risk Management as related to Target and POS systems
A risk-based approach to security would have involved analyzing threats and
vulnerabilities of all systems within the company on a regular basis. Risks would have
then been prioritized so that some of the vulnerabilities used to attack the systems in this
breach may have been prevented. Threat models created for systems throughout the data
centers and networks might have uncovered attacks that were used as pivot points to
reach the POS systems. Analyzing systems for vulnerabilities would have likely revealed
some of the flaws that were exploited by the attackers to gain system access. An
understanding of the data as it flowed through the system encrypted and unencrypted
might have revealed that data was residing unencrypted in memory where it would be
accessible by malicious software. Determining the most critical assets may have led to
additional logging, monitoring and log analysis for those systems. Analysis of threats and
vulnerabilities for all systems, not just those with most valuable data, could have been
used to prioritize security efforts to lower risk.
Case Study: Critical Controls that Could Have Prevented Target Breach! 10
Teri Radichel, teri@radicalsoftware.com
When asked about the Target Breach, Jason Popp says, “Even though the POS system
was one of the most valuable systems, the internet-facing vendor system had a higher risk
level. Additional controls on that internet facing environment may have prevented the
attack.” He also commented that the Target case study on the Microsoft web site pointed
out exactly what ports were open and what tools were available for the POS exploit (J.
Popp, personal communication, 2014).
3.2. Defense in Depth applied as a strategy in this case
Although many security measures were in place throughout the Target
infrastructure, additional layers of protection would have stopped the attack at various
points along the way. Applying a stronger Defense in Depth strategy would have ensured
that each level was not accessible from the next. Additional defenses on the POS system
itself could have further protected the data.
Even though encryption was used, the card data was available in memory at some
points on the POS systems. This card data was accessible because hackers were able to
infiltrate the network through other vulnerable systems to ultimately access the POS
machines. Had network controls and other system controls prevented access to the POS
machines at all, the card data would have been inaccessible.
Application whitelisting would have allowed only authorized software to run on
the POS system. Jason Popp, Group Manager of Security Architecture for a major retailer
suggests that a process separate from the POS system and software management tools
could have managed whitelisting (J. Popp, personal communication, 2014). Application
white listing could be done via hardware or software. Jose Diaz, Director, Business
Development & Technical Alliances at Thales eSecurity explains how code signing with
an HSM (hardware security module) which protects encryption keys would work: “The
code or application running in the POS system could have employed digital signatures,
with the signing key protected in a Hardware Security Module (HSM) to ensure only
legitimate code from the manufacturer could be installed in the devices” (J. Diaz,
personal communication, 2014).
As for the encryption itself, additional layers of protection could have been added
to protect card POS operating system memory. A tamper resistant security module
Case Study: Critical Controls that Could Have Prevented Target Breach! 11
Teri Radichel, teri@radicalsoftware.com
(TRSM) encrypts data in hardware, not software. Some POS models use a TRSM to
encrypt the data at point of swipe (Horton & McMillon, 2011). The card data goes
directly to the TRSM where it is encrypted. Even if malware got on the POS operating
system, it would have been reading encrypted data. Jeremy Eisenman of Thales eSecurity
explains, “Secure pin entry devices have been around for 40 years. Requirements are
strict around securing PINBLOCKS. Magnetic stripe track data has not been handled
with the same security controls even though swiped on the same PED” (J. Eisenman,
personal communication, 2014).
For true Point-to-Point Encryption (P2PE) a system would look similar to this
diagram from the Payment Card Industry’s guide on (PCI) Point-to-Point Encryption
(PCI Security Standards Council, 2013b):
Figure 3: PCI Point-to-Point Encryption Implementation
Jose Diaz of Thales eSecurity explains that payment terminals implemented
correctly already encrypt the PIN data on the cards but often not the data on the magnetic
Case Study: Critical Controls that Could Have Prevented Target Breach! 12
Teri Radichel, teri@radicalsoftware.com
stripe. When the PIN is received an encrypted PINBLOCK is created immediately at
entry. The cryptogram is sent over the network to a payment HSM that unencrypts and
then re-encrypts the PIN to the processor or issuer that can verify them. The retailer
should never store the PIN data.
He goes on to say: Using a PCI PIN Transaction Security (PTS) approved device
for reading the cards and encrypting sensitive data within the device, as described
in PCI Point-to-Point Encryption requirements, would have prevented having
clear sensitive data in the POS environment similar to what is done for PINs (J.
Diaz, personal communication, 2014).
3.3. Possible Implementation of Critical Controls
The Critical Controls are a prioritized list of controls that are chosen to prevent
known attacks. By reviewing the Target breach, the effectiveness of the Critical Controls
can be evaluated to determine if they would have helped prevent this attack. Each step the
hackers took to gain access is a point in the system where the attack could have
potentially been thwarted. Analysis of each action can determine if there is a Critical
Control that would prevent a similar attack in the future.
Attack vectors used in this breach are listed below. Next to each attack vector the
Critical Controls are listed that may have stopped this attack. The full list of 20 Critical
Controls are found on the SANS Institute web site at http://www.sans.org/critical-
security-controls (SANS Institute, 2014c).
Attack Vector Critical Control
Reconnaissance 9. Security Skills Assessment and
Appropriate Training to Fill Gaps: Use
security awareness training to make
employees aware of the danger of sharing
too much information.
15. Controlled Access Based on the Need
to Know: Remove vendor information and
Microsoft case study with detailed
information about Target technical
systems, processes and staff. Network
access could restrict access to vendor and
technical information.
Case Study: Critical Controls that Could Have Prevented Target Breach! 13
Teri Radichel, teri@radicalsoftware.com
Email attack, Malware installed on vendor
machine
5. Malware Defenses: Require vendors to
use commercial virus checking software
and other security precautions on the
systems used to interact with vendor
portals.
9. Security Skills Assessment and
Appropriate Training to Fill Gaps: Require
vendors to go through basic security
training or agree to train staff.
Use of vendor credentials 13. Boundary Defense: Limit network
access to vendor portal so anyone who
obtained the credentials would not be able
to access the vendor portal unless on a
network allowed to access that portal.
16. Account Monitoring and Control:
Require multi-factor authentication to log
into vendor portal. Monitor use of vendor
portal logins. Profile accounts for normal
activity and usage periods to spot
anomalies.
Exploited Vendor Portal Vulnerabilities 3. Secure Configurations for Hardware and
Software on Mobile Devices, Laptops,
Workstations, and Servers: Weakness may
have been in a component running on the
vendor portal server that could have been
prevented.
6. Application Software Security: A web
application firewall, monitoring, scanning
for vulnerabilities and testing may have
uncovered flaws in the vendor system.
Patching the system would have ensured
software was up to date with known
vulnerabilities patched.
20. Penetration Tests and Red Team
Exercises: Since this system is on the
perimeter at the first layer of defense
chances are a pen tester may have
uncovered the weaknesses in this system
given a password.
Network Infiltration and Communication 12. Controlled Use of Administrative
Privileges: Inappropriate access to
administration accounts may have allowed
Case Study: Critical Controls that Could Have Prevented Target Breach! 14
Teri Radichel, teri@radicalsoftware.com
attackers to install tools and bypass
network segregation boundaries.
Monitoring access may have indicated the
unexpected activity.
14. Maintenance, Monitoring, and Analysis
of Audit Logs: Monitor for anomalies
including malformed packets and packets
with unexpected sizes or data. Analyze
unexpected traffic to and from critical
systems. Do not rely on standard tools
alone. Custom attacks are designed to
bypass known capabilities of technical
tools.
19. Secure Network Engineering:
Segregate critical systems from the rest of
the network with tightly controlled access.
Misconfigured systems and vulnerable
Domain Controller
3. Secure Configurations for Hardware and
Software on Mobile Devices, Laptops,
Workstations, and Servers: Weakness may
have prevented inappropriate access or
exploitation of systems. Alerts could have
been generated by a HIDS when key server
configurations were changed.
16. Account Monitoring and Control:
Require multi-factor authentication for
critical accounts. Monitor accounts. Profile
accounts for normal activity and usage
periods to spot anomalies. Account
privileges should be limited to need to
know. Segregate account access across
network tiers. Change default passwords.
Disable and delete unneeded accounts.
Malware installed on POS systems 2. Inventory of Authorized and
Unauthorized Software: Whitelisting would
not have allowed the malware to be
installed on POS systems. Scanning for
configuration changes with a HIDS such as
Tripwire would have alerted staff to
configuration changes. Tripwire alerted
Sally Beauty to a credit card breach
however reports do not indicate if the
HIDS was installed on POS systems
(Krebs, 2014f) . Inventory software and
Case Study: Critical Controls that Could Have Prevented Target Breach! 15
Teri Radichel, teri@radicalsoftware.com
require it to provide identification tags in
logs. Virtualized instances of systems can
be periodically restored to a pristine
version.
3. Secure Configurations for Hardware and
Software on Mobile Devices, Laptops,
Workstations, and Servers: Secure
configuration of POS machine would have
likely turned off NetBIOS. In addition
blocking ports related to NetBIOS may
have prevented network access and shares
used to exfiltrate data.
5. Malware Defenses: Although virus-
scanning software would not have
prevented this attack, monitoring for
malicious software and a HIDS may have
helped uncover its existence if whitelisting
was not in place.
12. Controlled Use of Administrative
Privileges: Limited administrative
privileges may have prevented inserting
software to get into the deployment process
used to infect the POS systems with
malware. Monitoring access may have
indicated the unexpected activity.
Card data scraped from memory 6. Application Software Security:
Developers trained in security should
develop systems processing sensitive data.
Target software on POS machines was an
in-house product (iSight Partners, 2014).
17. Data Protection: P2PE for POS systems
from PCI compliant vendors may have
helped protect card data in memory.
Hardware encryption devices directly
connected to the pin pad would have kept
credit card data out of memory (Gomzin,
2014, p. 210). POI pin pads with tamper
resistant security module (TRSM)
implement hardware encryption (Gomzin,
2014, p. 188).
Data removed from POS machines to
corporate LAN
3. Secure Configurations for Hardware and
Software on Mobile Devices, Laptops,
Case Study: Critical Controls that Could Have Prevented Target Breach! 16
Teri Radichel, teri@radicalsoftware.com
Workstations, and Servers: Data could not
be moved using NetBIOS functionality.
13. Secure Network Engineering:
Implement network segregation that limits
access to critical systems to specific
addresses and ports. URL filtering for
egress capabilities limits datacenter system
outbound access.
Data moved to drop locations 17. Data Protection: Employ tools at
perimeters to monitor for sensitive data
leaving the company in clear text. Use Data
Loss Prevention systems if applicable.
Monitor traffic. Block known exfiltration
web sites.
Failure to respond to FireEye alerts 4. Continuous Vulnerability Assessment
and Remediation: continually assess the
environment and threats for new
vulnerabilities.
9. Security Skills Assessment and
Appropriate Training to Fill Gaps: Make
sure security staff is adequate to monitor
logs appropriately and well trained.
14. Maintenance, Monitoring, and Analysis
of Audit Logs: Hiring more staff or better
training staff to adequately monitor logs
may have helped mitigate losses.
17. Data Protection: Scan for sensitive data
and document where it is located. Ensure
locations are valid places for sensitive data
to reside.
18. Incident Response and Management:
Retrospective after incident may indicate
how better policies and procedures for
incident management could have prevented
this breach or minimized the losses.
20. Penetration Tests and Red Team
Exercises: Pen testing exercises to mimic
attacks and generate alerts could indicate
whether or not staff responds to alerts
appropriately.
Case Study: Critical Controls that Could Have Prevented Target Breach! 17
Teri Radichel, teri@radicalsoftware.com
Cards stolen on black market 17. Data Protection: EMV (Europay,
MasterCard and VISA), otherwise known
as chip and pin, is not explicitly named but
will add some help for cards used by
requiring a pin at the time the card is used
to authenticate the transaction. It would not
have completely prevented loss by
customers because in some cases devices
do not support or failover to the magnetic
stripe method (Gomzin, 2014, p. 215). This
technology protects the customer after the
data has been stolen because it prevents
using a cloned card in some cases. It does
not prevent stealing the data from a POS
system.
Figure 4 Critical Controls recommended for each step taken by attackers in Target breach.
4. Target Breach: An alternate outcome
By applying the recommended security strategies, a speculative alternative
outcome demonstrates how they may have stopped or mitigated the attack. A risk-based
approach to security would have included analyzing threats and vulnerabilities for all
systems on a regular basis to determine high-risk systems. Prioritization of risk would
have helped determine which Critical Controls to implement first based on possible
damage to the business. Risk analysis would have helped the company determine which
Critical Controls to implement first. Use of the Critical Controls to implement a stronger
Defense in Depth strategy may have stopped the attackers at different points before they
reached the credit card data.
Even if Target had not applied every single control listed, one or more of the
controls could have blocked each step of the attack. Although the breach is unfortunate
and unintended, it provides a case study that other businesses can use to understand the
threats and vulnerabilities that led up to it. The table below suggests specific actions that
could be taken to apply the recommended Critical Controls for each attack point. An
alternate outcome is presented, had the controls had been applied. Using a real world
example demonstrates why the Critical Controls are important and how they can help.
Attack Vector Result With Critical Controls Applied
Case Study: Critical Controls that Could Have Prevented Target Breach! 18
Teri Radichel, teri@radicalsoftware.com
Reconnaissance No revealing data such as the list of
vendors found on target web site.
No access to vendor portal web URL
unless coming from an approved network
address or VPN.
No case study would be published that had
details about the infrastructure of the
Target stores, systems, software or
maintenance processes.
Separation of duties would have prevented
insiders from having end-to-end system
knowledge or access.
Result: Hackers would have not known
vulnerabilities in advance of attack.
Email attack, Malware installed on vendor
machine
Vendor staff is familiar with phishing
attacks because Target required vendor
training.
Require commercial virus scanning
software that would have prevented
malware used in the attack on the vendor
machines (Poulin, 2014).
Result: Malware in phishing attack would
have failed. Hackers would not have
obtained access to vendor portal
credentials.
Use of vendor credentials Requiring a VPN or restricting network
access would have prevented an attacker
from accessing the vendor portal.
Multi-factor authentication would have
prevented the vendor from logging into the
portal if they did not have the MFA token.
This would have prevented exploiting
vulnerabilities in the vendor portal.
Result: Hacker with vendor credentials
could not access vendor portal.
Exploited Vendor Portal Vulnerabilities Periodically scanning the vendor portal
may have uncovered vulnerabilities that
could have been fixed such as SQL
Case Study: Critical Controls that Could Have Prevented Target Breach! 19
Teri Radichel, teri@radicalsoftware.com
Injection, XSS and other web site
vulnerabilities (Poulin, 2014).
Hardening the machine may have removed
vulnerabilities that exploited.
Preventing network access to all systems
and ports that were not required may have
prevented network infiltration.
Running applications under a non-
administrator account with no access to
other portions of the network may have
limited access.
Result: vendor portal cannot be used as a
pivot point.
Network Infiltration and Communication More staff trained in depth on network
traffic and security analysis to inspect
traffic and account activity for anomalies.
Correlation of logs and analysis of network
and account activity may have uncovered
anomalies indicative of an attack: Accounts
accessing unexpected resources,
unexpected traffic between systems, failed
login attempts or access, installation of
network reconnaissance tools, malformed
packets and packets of unusual sizes,
unexpected shares, unexpected increase in
traffic, traffic sent to unexpected location,
unexpected types of traffic (FTP traffic
going to Brazil, for instance).
Restrict accounts to a single network zone
if possible so access to one account does
not give access to other portions of the
network. Monitor unauthorized access
attempts.
Set up honey pots and honey tokens if
budget allows for detailed and constant
monitoring of these resources. Analyze all
access for malicious activity.
Prioritized logging as relates to traffic in
Case Study: Critical Controls that Could Have Prevented Target Breach! 20
Teri Radichel, teri@radicalsoftware.com
and out of POS systems. Additional
scrutiny is placed on any traffic changes in
or out of systems with critical data.
Tuning of alert systems to reduce false
positives. Adequate staff to allow review of
all alerts in a timely and adequate manner.
Strict firewall rules to segregate systems
and accounts limited to access specific
portions of the network.
Separation of duties prevents access across
different network layers.
Understand ICMP Attacks to determine
how they can be prevented (InfoSec
Institute, 2012).
Result: suspicious activity leads to
discovery of infiltration and problem is
resolved before hackers reach POS
systems. Accounts and systems limited in
access cannot be used as pivot points to
other parts of network.
Misconfigured systems and vulnerable
Domain Controller
Servers are hardened and set up with
known good configurations so hacker
cannot exploit flaws.
Configuration files do not contain sensitive
data that can be used by hackers to access
other systems, so they cannot determine
how to get to POS systems on the network.
Any sensitive data in configuration is
encrypted when possible. Encryption keys
and processing occurs in an HSM so cannot
be accessed by hacker directly from files
even if get onto the machine.
Configurations are monitored for changes
and changes are reviewed for flaws so any
misconfigurations would be fixed
immediately.
Critical systems and accounts require
Case Study: Critical Controls that Could Have Prevented Target Breach! 21
Teri Radichel, teri@radicalsoftware.com
multi-factor authentication.
Accounts are given minimal access for
specific purposes.
No default passwords would have been
accessible for any third party to use.
Result: Attacker may obtain access to one
machine or account but will be limited in
what they can access or do after reaching
that machine. Attack would have been
limited in scope and not been able to reach
POS machines.
Malware installed on POS systems Systems are patched and up to date so
known vulnerabilities cannot be exploited.
No remote access is allowed on POS
machines so attempts to log in remotely
fail.
Software is inventoried and white listed on
POS machines. New software would be
prevented from installing or running.
Applications are run under non-
administrator account. If hacker got access
to accounts running on system they would
not have ability to install software.
Strong passwords changed regularly
prevent attacker from brute force password
attack to escalate privileges and install
software.
A host intrusion detection device alerts to
any system changes if the attacker is able to
install the malware so it can be uncovered
and stopped immediately.
Target used custom-built POS software.
(iSight Partners, 2014). Software and
systems should be designed by people with
in depth knowledge of security could
potentially build additional protection and
logging into software that is processing
Case Study: Critical Controls that Could Have Prevented Target Breach! 22
Teri Radichel, teri@radicalsoftware.com
card data.
Limit access to centralized build and
installation systems. Audit all access to
these systems. Place additional controls on
gold images used for POS systems. Ensure
central management system and any
software images are properly signed,
managed, secured and audited (J. Popp,
personal communication, 2014).
Result: Would not be possible to install
malware on POS machines. Any changes to
POS configurations would generate alerts
to quickly resolve the problem.
Card data scraped from memory P2PE is employed to ensure credit card
data is encrypted end-to-end and never
accessible in memory to hackers in the
POS systems.
Consider using approved P2PE vendors
from PCI web site, but verify data is not
stored in memory or inappropriately with
appropriate testing.
POI pin pads with tamper resistant security
module (TRSM) use hardware encryption
to encrypt credit card data so it never enters
the memory on the machine and key is
protected. A pin pad should be used that
encrypts the magnetic stripe data using the
TRSM, not just the pin.
Result: credit card data would not have
been available to the memory scraping
malware.
Data removed from POS machines to
corporate LAN
Turn off NetBIOS and file and printer
sharing unless absolutely needed. Turn off
any other protocols not required such as
SMB and CIFS unless they are actually
needed. Available services can be used for
malicious activity. Extraneous protocols,
especially if not well monitored, may be
used to tunnel through firewalls. Block all
ports related to these services if not
required.
Case Study: Critical Controls that Could Have Prevented Target Breach! 23
Teri Radichel, teri@radicalsoftware.com
Inventory network devices and shares,
especially on critical systems with sensitive
data.
Additional logging and alerting for traffic
coming in or out of POS systems.
Result: NetBIOS ports could not have been
used to data.
Data moved to drop locations Implement strict access for data moving
out of the company via FTP or known file
transfer protocols.
Create a proxy specifically for data
movement such as FTP, SFTP and other
protocols used to send data to remote
locations. Carefully monitor traffic for
unexpected activity.
Monitor outbound traffic for unexpected
changes and anomalies.
Result: Data moving out of the
organization would have been spotted.
Breach would have been stopped sooner.
Failure to respond to FireEye alerts Separation of duties would have different
people monitoring systems than those who
have access to make changes to
configuration.
Adequate staff would be available to look
at alerts in detail and respond accordingly.
Processes would be appropriate and staff
would be well trained to handle alerts in
such a way that the breach would have
been uncovered.
Correlated logging using a SIEM (Security
Incident and Event Management) system
may have helped uncover the breach
sooner.
Result: The alerts would have been
analyzed differently and the data breach
Case Study: Critical Controls that Could Have Prevented Target Breach! 24
Teri Radichel, teri@radicalsoftware.com
would have been terminated sooner.
Cards stolen on black market Once the card data has been stolen it can be
used to create fake cards or facilitate
transactions. At that point, requiring a pin
that the owner of the card must know
would have prevented use of the cards
when sold on the black market if the device
was used on a card reader that supported
chip and pin technology. This is more for
fraud than data protection. Protection is
thwarted on manual entry and on failover
to MSR when the card reader or doesn’t
support the chip and pin technology and the
card still has a magnetic stripe (Gomzin,
2014, p. 214).
Result: Some of the data loss due to using
stolen cards could have been prevented.
Figure 5 Possible outcome at each step had recommended Critical Controls been in place.
5. Summary
Target invested heavily in security spending, and unfortunately hackers were still
able to find a way through their defenses. This breach makes it clear that PCI compliance,
legal and industry mandates do not provide adequate security for sensitive data due to
limitations in scope and an ever-changing threat landscape. Advanced Persistent Threats
are going to seek out and exploit the weakest link in any system, network or process.
They will use complex and lengthy attacks to mine data from companies any way they
can. They are constantly revising their strategy and seeking holes in the armor of business
security implementations. The adversary can adapt faster than the regulations can
possibly be put in place. Security must be approached more strategically as a way to
protect critical assets, business reputation and profitability.
The security strategy for a business should take into account the specific needs of
that particular business. Businesses must consider what assets are most valuable and what
threats pose the greatest risk using threat modeling and a risk management program.
Resources should be focused on the most critical and highest risk assets. Solutions should
be implemented most cost-effectively to mitigate that risk. This strategy requires an
analysis of the business impact, not a boilerplate template provided by an external
Case Study: Critical Controls that Could Have Prevented Target Breach! 25
Teri Radichel, teri@radicalsoftware.com
standards body. The cost and return on investment of various security tactics must be
analyzed to help make appropriate security implementation decisions. A complete
discussion of risk management is beyond the scope of this paper but resources were
provided for further reading.
Businesses should not rely on a single security tool or process to prevent data loss
or harm to the business. A layer of defenses including preventative and detective
measures should be employed. Due to the complex nature of security and the persistence
of the adversary, detection is crucial. A detailed understanding of networks, hardware,
software and processes is required to create a comprehensive plan. Using the Critical
Controls to implement layers of security helps thwart attacks by guarding against the
many different ways attackers gain access to systems.
An alternate outcome for the Target scenario was presented with Critical Controls
in place. Steps taken by the attackers could have been stopped at many different points
during the attack. Segregating the POS systems, end-to-end encryption, inventory of
systems and detailed logging would have kept thieves away from credit card data. Proper
encryption would have prevented card data from being read in memory. Adequate, well-
trained staff with time to appropriately analyze logs would have uncovered the malware
and network traffic to mitigate losses had the breach still occurred.
Case Study: Critical Controls that Could Have Prevented Target Breach! 26
Teri Radichel, teri@radicalsoftware.com
6. References
Baldwin, H. (2014, March 11). The other shoe drops for Target’s CIO. Retrieved from
Forbes: http://www.forbes.com/sites/howardbaldwin/2014/03/11/the-other-shoe-
drops-for-targets-cio/
Capacio, S. (2014, March 13). Target breach: Security warning ignored before heist.
Retrieved from myFOX9.COM:
http://www.myfoxtwincities.com/story/24968693/report-target-ignored-signs-of-
breach
Clark, M. (2014, May 5). Timeline of Target’s data breach and aftermath: How cybertheft
snowballed for the giant retailer. Retrieved from International Business Times:
http://www.ibtimes.com/timeline-targets-data-breach-aftermath-how-cybertheft-
snowballed-giant-retailer-1580056
Dell Secure Works. (2014). The 20 critical security controls. Retrieved from Dell Secure
Works: http://www.secureworks.com/resources/articles/other_articles/the-20-
critical-security-controls/
D’Innocenzio, A. (2014, 2 18). Target data breach cost banks more than $200 million.
Retrieved from THE HUFFINGTON POST:
http://www.huffingtonpost.com/2014/02/18/target-data-breach-
cost_n_4810787.html
Elgin, B. (2014, March 13). Missed alarms and 40 million stolen credit card numbers:
How target blew It. Retrieved from Bloomberg Businessweek:
http://www.businessweek.com/articles/2014-03-13/target-missed-alarms-in-epic-
hack-of-credit-card-data
Fazio, R. E. (2014, February 6). Statement on Target. Retrieved from Fazio Mechanical
Services: http://faziomechanical.com/Target-Breach-Statement
Ferguson, N., Schneieir, B., & Tadayoshi, K. (2010). Cryptography Engineering: Design
Principles and Pracctical Applications. Indianapolis: Wiley Publishing.
Ferraro, P. (2013, April 01). You are an APT target. Retrieved from SC Magazine:
http://www.scmagazine.com/you-are-an-apt-target/article/284408/
Gomzin, S. (2014). Hacking Point of Sale: Payment Application Secrets, Threats, and
Solutions. Indianapolis, IA: Wiley.
Gonsalves, A. (2014, May 5). Target CEO resignation highlights cost of security
blunders. Retrieved from CSO: http://www.csoonline.com/article/2151381/cyber-
attacks-espionage/target-ceo-resignation-highlights-cost-of-security-blunders.html
Case Study: Critical Controls that Could Have Prevented Target Breach! 27
Teri Radichel, teri@radicalsoftware.com
Grande, A. (2014, May 8). Post Target breach laws ratchet up pressure on companies.
Retrieved from Law 360: http://www.law360.com/articles/536057/post-target-
breach-laws-ratchet-up-pressure-on-companies
Halkias, M. (2014, March 7). Survey says: Target data breach still having an impact on
customer shopping decisions. Retrieved from Dallas News:
http://bizbeatblog.dallasnews.com/2014/03/survey-says-target-data-breach-still-
having-an-impact-on-customer-shopping-decisions.html/
Horton, T., & McMillon, R. (2011). Security technologies: Encryption and tokenization.
Retrieved from First Data: http://files.firstdata.com/downloads/thought-
leadership/primer-on-payment-security-technologies
Hosenball, J. F. (2014, January 29). Target says criminals attacked with stolen vendor
credentials. Retrieved from Reuters:
http://www.reuters.com/article/2014/01/30/us-usa-justice-target-
idUSBREA0S1AE20140130
InfoSec Institute. (2012). ICMP attacks. Retrieved from InfoSec Institute:
http://resources.infosecinstitute.com/icmp-attacks/
iSight Partners. (2014, January 14). KAPTOXA Point of sale compromise. Retrieved
from Security Current: www.securitycurrent.com/…/KAPTOXA-Point-of-Sale-
Compromise
Jarvis, K., & Milletary, J. (2014). Inside a Target point of sale breach. Austin: Dell
SecureWorks.
Krebs, B. (2014a, January 14). A closer look at the Target malware, part II. Retrieved
from Krebs on Security: http://krebsonsecurity.com/2014/01/a-closer-look-at-the-
target-malware-part-ii/#more-24401
Krebs, B. (2014b, January 14). A first look at the Target intrusion malware. Retrieved
from Krebs on Security: http://krebsonsecurity.com/2014/01/a-first-look-at-the-
target-intrusion-malware/
Krebs, B. (2013c, December 12). Cards stolen in Target breach flood underground
markets. Retrieved from Krebs on Security:
http://krebsonsecurity.com/2013/12/cards-stolen-in-target-breach-flood-
underground-markets/
Krebs, B. (2014d, 02). Email Attack on Vendor Set Up Breach at Target. Retrieved from
Kerbs On Security: Email Attack on Vendor Set Up Breach at
Targethttp://krebsonsecurity.com/2014/02/email-attack-on-vendor-set-up-breach-
at-target/
Case Study: Critical Controls that Could Have Prevented Target Breach! 28
Teri Radichel, teri@radicalsoftware.com
Krebs, B. (2014e, January 14). New clues in the Target breach. Retrieved from Krebs on
Security: http://krebsonsecurity.com/2014/01/new-clues-in-the-target-breach/
Krebs, B. (2014f, March 14). Sally Beauty hit by credit card breach. Retrieved from
Krebs on Security: http://krebsonsecurity.com/2014/03/sally-beauty-hit-by-credit-
card-breach/
Krebs, B. (2013g, December 13). Sources: Target investigating data breach. Retrieved
from Krebs on Security: http://krebsonsecurity.com/2013/12/sources-target-
investigating-data-breach/
Krebs, B. (2014h, February 2014). Target hackers broke in via HVAC company.
Retrieved from Krebs On Security: http://krebsonsecurity.com/2014/02/target-
hackers-broke-in-via-hvac-company/
Lublin, P. Z. (2014, May 28). ISS’s view on Target drectors is a signal on cybersecurity.
Retrieved from THE WALL STREET JOURNAL:
http://online.wsj.com/articles/iss-calls-for-an-overhaul-of-target-board-after-data-
breach-1401285278
Mandiant. (2014a). APT1: Exposing one of China’s cyber espionage units. Alexandria:
Mandiant.
Mandiant. (2014b). M Trends: beyond the breach. Alexandria: Mandiant.
Mellow, Jr., J. P. (2014, March 18). Target breach lesson: PCI compliance isn’t enough.
Retrieved from Tech News World:
http://www.technewsworld.com/story/80160.html
Michaels, D. (2014, July 3rd). SEC launches investigations of hacked firms. Retrieved
from The Boston Globe:
http://www.bostonglobe.com/business/2014/07/02/hacked-companies-face-sec-
scrutiny-over-disclosure-and-controls/rH1MlfdmqyKNHMu2yrusHP/story.html
Microsoft. (2011). Large retailer relies on virtual solution to deliver optimal shopping
experience. Retrieved from Microsoft Download Center:
http://download.microsoft.com/download/3/A/D/3AD464EA-F2B4-4E62-B11F-
14E37727557C/Target_Hyper-V_CS.PDF
Murray, T. D. (2014, 07 09). Six months after the Target security breach, report says
cases of identity theft are increasing. Retrieved from cleveland.com:
http://www.cleveland.com/business/index.ssf/2014/07/six_months_after_the_targ
et_se.html
NSA. (n.d.). Defense in depth. Retrieved from NSA:
http://www.nsa.gov/ia/_files/support/defenseindepth
Case Study: Critical Controls that Could Have Prevented Target Breach! 29
Teri Radichel, teri@radicalsoftware.com
PCI Security Standards Council. (2013a, July). Payment Card Industry (PCI). Retrieved
from PCI Security Standards Council Point-to-Point Encryption Solution
Requirements and Testing Procedures: Encryption, Decryption, and Key
Management within Secure Cryptographic Devices (Hardware/Hardware :
https://www.pcisecuritystandards.org/documents/P2PE_v1-1
PCI Security Standards Council. (2013b, November). Payment Card Industry (PCI) data
security standard: Requirements and security assessment procedures. Retrieved
from PCI Security Standards Council:
https://www.pcisecuritystandards.org/security_standards/index.php
Poulin, C. (2014, January 31). What retailers need to learn from the Target breach to
protect against similar attacks. Retrieved from Security Intelligence:
http://securityintelligence.com/target-breach-protect-against-similar-attacks-
retailers/#.U8sthsLn-pp
Risen, T. (2014, March 26). FTC investigates Target data breach. Retrieved from US
News & World Report: http://www.usnews.com/news/articles/2014/03/26/ftc-
investigates-target-data-breach
SANS Institute. (2014a). 401.2 Defense In-Depth. Bethesda: The SANS Institute.
SANS Institute. (2014b). 401.3 Internet Security Technologies. Bethesda: The SANS
Institute.
SANS Institute. (2014c). Critical security controls for effective cyber defense. Retrieved
from SANS Institute: http://www.sans.org/critical-security-controls
SANS Institute. (2014d). Critical security controls: A brief history. Retrieved from SANS
Institute: http://www.sans.org/critical-security-controls/history
Schwartz, M. J. (2013, December 21). Target breach: 10 facts. Retrieved from Dark
Reading: http://www.darkreading.com/attacks-and-breaches/target-breach-10-
facts/d/d-id/1113228
Schwartz, M. J. (2014, March 26). Target, PCI auditor Trustwave sued by banks.
Retrieved from Dark Reading:
http://www.darkreading.com/risk/compliance/target-pci-auditor-trustwave-sued-
by-banks/d/d-id/1127936
Shostack, A. (2014). Threat Modeling: Designing for Security. Indianapolis: John Wiley
& Sons, Inc.
Steinhafel, G. W. (2012, January 12). Target CEO: We are accountable for the breach.
(B. Quick, Interviewer)
Case Study: Critical Controls that Could Have Prevented Target Breach! 30
Teri Radichel, teri@radicalsoftware.com
Target. (2014, January 20). Target provides update on data breach and financial
performance. Retrieved from Target: http://pressroom.target.com/news/target-
provides-update-on-data-breach-and-financial-performance
Warner, G. (2014, January 19). Target “hacker tools” provide breach insight. Retrieved
from Malcovery Security: http://cdn2.hubspot.net/hub/241665/file-466107501-
pdf/Target.Lessons.Learned
Webb, T. (2014, June 25). Target lawyer suggests mediation for resolving data breach
lawsuits. Retrieved from TwinCities.com:
http://www.twincities.com/ci_26032089/target-lawyer-suggests-mediation-
resolving-data-breach-lawsuits
Ziobro, P. (2014, February 26). Target earnings slide 46% after data breach. Retrieved
from THE WALL STREET JOURNAL:
http://online.wsj.com/news/articles/SB10001424052702304255604579406694182
132568
Last Updated: April 7th, 2020
Upcoming SANS Training
Click here to view a list of all SANS Courses
SANS Asia Pacific Live Online June 2020 , IN Jun 22, 2020 – Jun 27, 2020 Live Event
SANS ICS Asia Pacific Live Online June 2020 , AU Jun 29, 2020 – Jul 03, 2020 Live Event
SANS Japan Live Online July 2020 , JP Jul 01, 2020 – Jul 11, 2020 Live Event
SANS Cyber Defence Australia June 2020 OnlineAU Jun 22, 2020 – Jul 04, 2020 Live Event
SANS OnDemand Books & MP3s OnlyUS Anytime Self Paced
http://www.sans.org/courses?utm_source=Print&utm_medium=Reading+Room+Paper&utm_content=Case_Study_Critical_Controls_that_Could_Have_Prevented_Target_Breach+Cover&utm_campaign=SANS+Courses
http://www.sans.org/link.php?id=59850&rrpt=Case_Study_Critical_Controls_that_Could_Have_Prevented_Target_Breach&rret=SANS_Asia_Pacific_Live_Online_June_2020
http://www.sans.org/link.php?id=59850&rrpt=Case_Study_Critical_Controls_that_Could_Have_Prevented_Target_Breach&rret=SANS_Asia_Pacific_Live_Online_June_2020
http://www.sans.org/link.php?id=62605&rrpt=Case_Study_Critical_Controls_that_Could_Have_Prevented_Target_Breach&rret=SANS_ICS_Asia_Pacific_Live_Online_June_2020
http://www.sans.org/link.php?id=62605&rrpt=Case_Study_Critical_Controls_that_Could_Have_Prevented_Target_Breach&rret=SANS_ICS_Asia_Pacific_Live_Online_June_2020
http://www.sans.org/link.php?id=59750&rrpt=Case_Study_Critical_Controls_that_Could_Have_Prevented_Target_Breach&rret=SANS_Japan_Live_Online_July_2020
http://www.sans.org/link.php?id=59750&rrpt=Case_Study_Critical_Controls_that_Could_Have_Prevented_Target_Breach&rret=SANS_Japan_Live_Online_July_2020
http://www.sans.org/link.php?id=55500&rrpt=Case_Study_Critical_Controls_that_Could_Have_Prevented_Target_Breach&rret=SANS_Cyber_Defence_Australia_June_2020
http://www.sans.org/link.php?id=55500&rrpt=Case_Study_Critical_Controls_that_Could_Have_Prevented_Target_Breach&rret=SANS_Cyber_Defence_Australia_June_2020
http://www.sans.org/link.php?id=1032&rrpt=Case_Study_Critical_Controls_that_Could_Have_Prevented_Target_Breach&rret=SANS_OnDemand
http://www.sans.org/link.php?id=1032&rrpt=Case_Study_Critical_Controls_that_Could_Have_Prevented_Target_Breach&rret=SANS_OnDemand
Risk Management for Cybersecurity:
Security Baselines
1
Risk Management for
Cybersecurity:
Security Baselines
Risk Management for Cybersecurity:
Security Baselines
2
Authors
Amanda Craig
Kaja Ciglic
Angela McKay
Contributors
© 2018 Microsoft Corporation. All rights reserved. This document is provided “as is.” Information and views expressed
in this document, including URL and other Internet Web site references, may change without notice. You bear the risk of
using it. Some examples are for illustration only and are fictitious. No real association is intended or inferred.
This document does not provide you with any legal rights to any intellectual property in any Microsoft product. You may
copy and use this document for your internal, reference purposes
Risk Management for Cybersecurity:
Security Baselines
3
Foreword
Technology is empowering people and organizations around the world. In 2017, students in
India developed a mobile app that can act as a personal assistant for the visually impaired,1
and organizations in Africa, Latin America, and Southeast Asia used cloud computing to access
affordable banking.2 But technology is also being exploited by those that use cyberweapons to
inflict harm. Botnets have cut off internet service for millions of people, and ransomware attacks
have disrupted operations at hospitals and universities. Billons have been lost to cybercriminals.
Recognizing both trends, governments are seeking to realize the benefits of the digital age while
managing associated cyber risks. In Europe, for instance, the Directive on security of network
and information systems (NIS Directive) is intended to boost cybersecurity across E.U. Member
States while supporting continuity across a Digital Single Market. In Singapore, the recently passed
Cybersecurity Act aims to protect critical information infrastructure in one of the world’s most
digitally connected societies.
Microsoft has decades of experience with advancing both innovation and security. We’re working
on next generation advances in cloud computing, Internet of Things (IoT), mixed reality, and
artificial intelligence, unlocking new potential for our customers.3 Meanwhile, our Digital Crimes
Unit is using cloud technologies and advanced analytics to fight cybercrime and improve the
security of our products and services.4 These investments make life tougher for cyber criminals
while making people and organizations safer.
We also endeavor to partner with governments as they foster more connected and resilient
societies. Around the world, we’ve built transparency centers to demonstrate the integrity and
security of our software to governments.5 As a technology provider, we also share what we’ve
learned from protecting our own environment and from working with public and private sector
customers, law enforcement agencies, and researchers. We want to advance cybersecurity risk
management by sharing our experience with government policymakers.
To that end, we are pleased to present this paper, which articulates considerations for governments
pursuing efforts to manage cyber risk across sectors and organizations critical to their national
resilience. We advocate for a common, foundational approach, sometimes referred to as a
“security baseline,” that can be used across sectors as well as across geographies. In addition, we
describe attributes of effective approaches to security baselines.
In recent years, we’ve seen that cross-border coordination and public-private partnership are
critical to disrupting cybercrime. Going forward, we know that broader coordination across
sectors and geographies will drive additional security improvements. We hope that governments
consider this paper as they develop and evolve cybersecurity policies and security baselines,
working toward a common, foundational approach that supports global alignment and
coordination. We look forward to your feedback and continued partnership.
Tom Burt
Corporate Vice President, Customer Security & Trust
Microsoft
1 https://news.microsoft.com/en-in/microsoft-hosts-first-ever-accessibility-summit-india-enhance-technology-access-people-disabilities/
2 https://blogs.microsoft.com/transform/feature/theres-a-bank-branch-in-your-neighborhood-no-matter-how-remote-it-is/#sm.0012n8sl
9sfdcwq10p225ckdxcbf0
3 https://azure.microsoft.com/en-us/blog/new-innovations-at-microsoft-build-2017-helping-developers-achieve-more/; https://blogs.
microsoft.com/iot/2017/09/25/microsoft-ignite-2017-leading-innovation-iot/; https://www.microsoft.com/en-us/hololens; https://www.
microsoft.com/en-us/research/research-area/artificial-intelligence/.
4 https://news.microsoft.com/download/presskits/DCU/docs/dcuFS_160115
5 https://enterprise.microsoft.com/en-us/trends/government-security-program-available-to-qualified-governments/
https://news.microsoft.com/en-in/microsoft-hosts-first-ever-accessibility-summit-india-enhance-techn
https://blogs.microsoft.com/transform/feature/theres-a-bank-branch-in-your-neighborhood-no-matter-ho
https://blogs.microsoft.com/transform/feature/theres-a-bank-branch-in-your-neighborhood-no-matter-ho
https://azure.microsoft.com/en-us/blog/new-innovations-at-microsoft-build-2017-helping-developers-ac
https://azure.microsoft.com/en-us/blog/new-innovations-at-microsoft-build-2017-helping-developers-ac
https://www.microsoft.com/en-us/hololens
https://news.microsoft.com/download/presskits/DCU/docs/dcuFS_160115
https://enterprise.microsoft.com/en-us/trends/government-security-program-available-to-qualified-gov
Risk Management for Cybersecurity:
Security Baselines
4
Introduction
Around the world, governments and enterprises are assessing and determining how
to most effectively manage a vast array of risks facing their operations. Among those
risks, cybersecurity is increasingly important. Information and communications
technology (ICT) underpins the functioning of many governments and critical
infrastructure organizations, and the complexity of cyber risks continues to intensify.
Recognizing this growing need for resilient ICT, organizations of all sizes are
evaluating how to manage cybersecurity risks.
In addition to advancing efforts to improve the security of their own operations,
governments are developing public policies to advance critical infrastructure
cybersecurity. There are dozens of ongoing regional and national initiatives that aim
to help critical infrastructure providers manage cybersecurity risks by using “security
baselines”6. Encouraging, enabling, and, when appropriate, requiring those providers
to better manage cyber risks is a sensible government priority. However, there
are also many challenges associated with cybersecurity risk management policies,
including determining the overall purpose of security baselines, the scope of sectors
or services that baselines may apply to, and the policy levers appropriate to foster
implementation of baselines.
The approaches that governments take in developing, evolving, and implementing
security baselines will have far-reaching impacts. Effective approaches will not only
increase both domestic and global security but also support innovation, productivity,
and economic opportunity. Less effective approaches will create heavy operational
and compliance costs for both businesses and governments without realizing the
intended and much-needed security benefits.
This paper responds to three key questions that governments may have as they
develop, evolve, and implement security baselines:
• First, what are security baselines, and how can they improve cybersecurity risk
management across critical sectors? These questions are considered in section one,
“Managing risk through security baselines”.
• Second, how should governments develop security baselines that help governments,
critical infrastructure providers, and other enterprises manage risks and make
continuous improvements in security? This question is considered in section two,
“Developing effective security baselines”. Both the processes used to develop effective
baselines and the attributes of effective baselines are discussed.
• Third, why should governments leverage best practices and global standards for
security baselines? This question is considered in section three, “Realizing economic,
security, and societal benefits”.
6 Security baselines help organizations manage cybersecurity risk by referencing or describing relevant policies, outcomes, activities,
practices, and controls, all of which organizations can use to build their cybersecurity risk management programs. Examples of
government initiatives that seek to improve critical infrastructure cybersecurity through the use of security baselines include: the
European Union’s Directive on security of network and information systems (NIS Directive), China’s Cybersecurity Law, Japan’s Critical
Infrastructure Protection Guidelines, Russia’s Law on Critical Information Infrastructure Protection, and Singapore’s Cybersecurity Act.
Similar developments are ongoing in Chile, Colombia, Kenya, South Africa, Ukraine, Vietnam, and other regions.
Risk Management for Cybersecurity:
Security Baselines
5
Contents
6
Managing risk through security baselines
11 Developing effective security baselines
18 Realizing economic, security, and societal benefits
20 Conclusion
Risk Management for Cybersecurity:
Security Baselines
6
80%Security Baseline
A foundational set of policies,
activities, practices and controls
intended to help manage
cybersecurity risk
They cover a range of risks that
are applicable across a variety of
environments
20%Unique RequirementsFunctional/Sectoral variations
Managing risk through security baselines
What are security baselines?
Security baselines are a foundational set of policies, outcomes, activities, practices, and
controls intended to help manage cybersecurity risk. They generally cover a wide range
of risk management policy goals, such as protecting against cyber threats or detecting
and responding to anomalies or incidents. They can also include more specific desired
outcomes (e.g., know your organizational risks), security activities or practices (e.g.,
conduct a risk assessment; document, review, and disseminate the results; and update the
assessment regularly), and security controls7 (e.g., security policies are defined, approved
by management, and communicated to employees and third parties), all of which should
contribute to achieving a set of risk management policy goals.
Security baselines are particularly useful in improving cybersecurity because they can
cover a range of risks that are applicable across a variety of environments. Most risks
faced by governments and enterprises are similar, so most “baseline”, or fundamental, risk
management activities are also similar. For example, all organizations need to think about
regularly reviewing and updating risk assessments, managing how resources are accessed
to prevent unauthorized users or behaviors, reviewing event logs to detect events in their
infrastructure, and planning for and mitigating the impact of incidents.
While security baselines can address a significant majority of cyber risks applicable across
organizations, there may also be risk scenarios that are unique to different sectors or to
different business functions within an enterprise. For example, within an enterprise, risks
to payment processing systems will likely be somewhat different than those relevant
for training systems. In the sectoral context, energy, financial services, and health care
companies may also face different risk scenarios or consequences. As such, security
baselines that apply across sectors may need to be augmented with a narrow set of
guidelines or requirements intended to mitigate the unique risk scenarios relevant to
different business functions or sectors.
7Security controls are technical, operational, or managerial measures implemented on a system to address security risk.
Risk Management for Cybersecurity:
Security Baselines
7
How can security baselines be used to help manage cyber risks?
Security baselines can be structured and implemented in different ways to help
organizations manage broadly applicable cybersecurity risks. Two approaches are
important for governments to consider: outcomes-focused and controls-based
approaches. While they differ, outcomes-focused and controls-based approaches are
complementary, and both can both provide risk management value for organizations.
Outcomes-focused approaches help organizations drive strategic risk management,
establishing the necessary processes, capabilities, and investments to address evolving
threats and to learn and improve continuously. Compared to a focus on security controls,
a focus on security “outcomes” tends to be more easily translatable across different parts
of and personnel within an organization, including IT practitioners implementing security
for different products and services, incident responders, managers of IT or business
functions, and executives. In addition, an outcomes-focussed approach ensures that, in
implementation, baselines are suffciently fexible to adapt to changes in technology and
the threat landscape.
Controls-based approaches describe security implementation activities that may help
organizations address risks. Controls are typically topic specific and technical, providing
prescriptive guidance that’s narrowly tailored for infrastructure and/or security roles (e.g.,
network operators or system administrators). Controls describe activities or requirements
that respond to basic cybersecurity risks, and they may be particularly useful for
organizations that have limited cybersecurity capabilities and would therefore benefit
from a clear checklist of activities to do. Common examples of controls-based baselines
include International Organization for Standardization (ISO) 27002 and The Center for
Internet Security’s “Top 20” controls8.
8Center for Internet Security Top 20 controls: https://www.cisecurity.org/critical-controls.cfm
https://www.cisecurity.org/critical-controls.cfm
Risk Management for Cybersecurity:
Security Baselines
8
Outcomes-focussed Controls-based
Organizational
audience
IT and security practitioners,
managers, and executives IT and security practitioners
Overall approach
Strategic approach to risk
management establishes “floor”
and processes for continuous
improvement
Compliance-focussed approach
establishes “ceiling” on what
should be done for security
Approach to
implementation
Describes “what” an organization
should do to improve security
Describes “how” an organization
should implement security
practices
Adaptability
Focus on outcomes rather than
on implementation techniques
enables adaptability
Focus on technical
implementation of prescriptive
guidance limits adaptability
Governments can leverage the best of both outcomes-focused and controls-based
approaches in developing or evolving security baselines. To do so, an outcomes-focused
approach should be the foundation and organizing structure of security baselines, and
controls-based approaches should be referenced as guidance where relevant. As desired
security outcomes remain relevant as technology and the threat landscape evolve, this
structure enables security baselines to be sufficiently adaptable. It also ensures that
prescriptive guidance, which may have varying relevance across sectoral or functional
contexts as well as dynamic operational environments, is integrated and available for
those that would benefit from it. Ultimately, outcomes-focused approaches that reference
controls as potential implementation techniques can provide practitioners with guideposts
while fostering critical focus on risk management processes, continuous improvement, and
strategic security investments.
Utilizing only or even primarily controls-based approaches has proven insuffcient for
managing the cybersecurity risks that organizations face today. In isolation, controls are
static and can result in a compliance-based mindset that sets an artifcial and unhelpful
“ceiling” on what should be done for security. For example, controls might require an
organization to persist in using outdated security practices, even though more effective
alternatives have become available. Controls-based approaches have also proven to be a
barrier to getting executives to understand and support necessary security investments.
On the other hand, outcomes-focused approaches enable organizations to engage a
broader internal audience, including executives. They also allow for greater flexibility in
adjusting and improving how organizations manage, upgrade, and develop new security
techniques by establishing a “floor,” or minimum set of expectations for security, that
organizations can exceed as new techniques are developed.
Risk Management for Cybersecurity:
Security Baselines
9
What sectors or services should security baselines apply to and why?
In the context of public policy, security baselines may apply to a specific sector or
across multiple sectors. In our experience, security baselines can easily apply across
multiple industry sectors, and there are two significant reasons why governments
should adopt such an approach.
First, most cybersecurity risks are similar, and cross-sector baselines will catalyze action
immediately and enable sectors to coordinate in managing common issues. Organizations
can then focus more attention on the unique risk scenarios that they may need to address
with specific mitigations above the baseline.
Second, cross-sector baselines help to address supply chain issues. Many critical
infrastructure organizations and governments leverage technologies and resources
from multiple organizations in other sectors. These supplier relationships impact both
enterprises’ and governments’ ability to manage security efficiently and to comply with
regulatory requirements that extend to third parties. Cross-sectoral baselines enable
organizations to pass regulatory or procurement-based requirements to downstream
suppliers, helping to create continuity and consistency. Alternatively, fragmentation
across sectoral requirements would force organizations to choose to comply with some
requirements over other conflicting ones. In addition, a fragmented approach would
result in inefficiency as companies and governments seek to demonstrate and assess
compliance. To the extent that compliance artifacts can be re-used for multiple customers
or regularly assessed in a consistent way by governments, vital resources can be saved and
redirected from compliance to security.
As governments develop security baselines that can be used consistently across multiple
sectors, they may also consider to which sectors those baselines should apply. Each
government must determine for itself which sectors are the most critical to its national
resiliency, though many governments prioritize energy, financial services, healthcare,
telecommunications and transportation. Moreover, across sectors, governments may
take various approaches to implementation, encouraging or enforcing the use of security
baselines in different ways—depending on the criticality of the sector and the level of
assurance that the government determines is necessary.
Risk Management for Cybersecurity:
Security Baselines
10
How do governments foster use of security baselines?
Depending on an enterprise’s maturity and/or a government’s needs and resources,
security baselines may be implemented through various approaches, including
proactively by enterprises themselves or as a result of government initiatives. Mature
enterprises may develop baselines or security policies for internal use, just as mature
governments may develop baselines to drive security improvements across ministries,
departments, and agencies. In addition, governments may foster use of security
baselines among critical infrastructure or other enterprises. Where governments
have an elevated need for assurance as well as sufficient resources, they may utilize
a regulatory approach. In other contexts, governments may find voluntary guidance,
coupled with relevant incentives (e.g., procurement requirements), more appropriate,
especially in consideration of the costs they incur in developing and ensuring
compliance with a regulatory regime. Irrespective of approach, the use of cross-
sector security baselines will drive positive behavior beyond those organizations
directly impacted by regulatory or voluntary approaches, compelling or incentivizing
downstream suppliers of governments or critical infrastructure organizations to
implement relevant baseline activities as well.
Risk Management for Cybersecurity:
Security Baselines
11
Utilizing an open, collaborative, and iterative
development process
In developing or evolving security baselines, a first step for any government
is to leverage and integrate the expertise and experience of stakeholders with
different backgrounds. Technology is integrated into many systems and services,
and stakeholders with different areas of expertise (e.g., technical, business, legal,
and policy) and in diverse roles (e.g., civil society, government, and industry)
will add unique perspectives that contribute to greater understanding and
improved implementation.
The owners and operators of critical infrastructure and of technology products
and services are important industry stakeholders in this discussion. In many
cases, such stakeholders have developed their own security baselines for internal
risk management and adhered to baselines based on external regulatory
or procurement requirements. Considering their range of experiences and
knowledge about infrastructure and technology systems, they can provide
valuable input on how baselines can be implemented, the challenges that must
be addressed, and opportunities to drive meaningful improvements.
To leverage and integrate diverse expertise, governments should focus on being
open and collaborative, creating an opportunity for the sharing of experiences,
perspectives, and ideas. In addition, governments benefit from using an iterative
process of policy development, with multiple chances for stakeholders to
provide input on drafts, recognizing that the most effective security baselines
will be developed and refined over time and with ample opportunity for
understanding and incorporating feedback.
I.
Developing effective security baselines
A holistic cybersecurity risk management approach is critical to ensuring organizational
engagement on tactical, operational, and strategic issues and to enabling continuous
improvement. To achieve a holistic approach, organizations must assess and manage
cybersecurity risk in the context of overall enterprise risk management. Governments that are
developing or evolving security baselines can promote and foster such a holistic cybersecurity
risk management approach by focusing on:
I. Utilizing an open, collaborative, and iterative development process;
II. Bridging risk management understanding both within and between organizations;
III. Advancing security through a risk-based and outcomes-focused approach; and
IV. Leveraging existing best practices to the greatest extent practicable.9
Below, this paper considers each of the above elements of an effective approach, describing
why each is important to risk management as well as valuable to governments and industry.
9See also, https://crx2.org/wp-content/uploads/2018/02/CR2_White_Paper . Cybersecurity Policy for Resilient Economies: A Global,
Cross-Sector Approach describes principles that align with I-IV.
https://crx2.org/wp-content/uploads/2018/02/CR2_White_Paper . Cybersecurity Policy for Resilient Economies: A Global, Cross-Sector Approach describes principles that align with I-IV
https://crx2.org/wp-content/uploads/2018/02/CR2_White_Paper . Cybersecurity Policy for Resilient Economies: A Global, Cross-Sector Approach describes principles that align with I-IV
Risk Management for Cybersecurity:
Security Baselines
12
An open, collaborative, and iterative approach can be achieved in various ways.
For one, governments can request comments or have a public consultation
on shared questions, proposals, or documents. With adequate time (e.g., 60
days) and multiple opportunities to comment on various drafts, organizations
can give questions and documents full consideration, provide meaningful
feedback, and ensure that their feedback is understood in context. For example,
the European Commission and the European Network and Information
Security Agency (ENISA) have launched numerous public consultations and
surveys, including on how best to partner with the private sector and on the
implementation of the NIS Directive.10
In addition, governments can host workshops, inviting stakeholders to discuss
ideas and provide immediate feedback. In convening government, industry, and
civil society stakeholders to develop the Framework for Improvement Critical
Infrastructure Cybersecurity (Cybersecurity Framework), for instance, the U.S.
National Institute of Standards and Technology (NIST) hosted numerous open
and collaborative workshops at which it drove conversations around aspects of
cybersecurity risk management and effective guidance for critical infrastructure
security. In addition, the Singaporean government has hosted workshops to
learn about industry perspectives on cybersecurity initiatives.
Alternatively, governments can take a structured but more centralized
approach, establishing internal working groups to study globally available
best practices and even creating partnerships with peer organizations in other
markets before making national proposals. For example, the Cybersecurity
Division of Japan’s Ministry of Economy, Trade, and Industry (METI) and NIST
have jointly supported a research group on the international standardization
of cybersecurity. That group is also studying legislation and standardization
of cybersecurity technology and submitting to the Japanese government a
cybersecurity proposal for local and global industry.
Bridging risk management understanding both within
and between organizations
A second key step for governments to consider as they develop security
baselines is the importance of integrating cybersecurity risk management
into broader enterprise risk management communications, processes, and
learnings. Risk management guidance consistently highlights the importance of
communication across organizations, both horizontally and vertically11. However,
cybersecurity risk management is a relatively new and technical topic for many
company managers, directors, and boards, so they may struggle with both
horizontal and vertical engagement on the issue.
II.
10https://www.enisa.europa.eu/news/enisa-news/european-commission-opens-public-consultation-on-2018contractual-ppp2019;
https://ec.europa.eu/eusurvey/runner/NIS_Dir_IncidentReporting_D
11 For instance, International Standardization Organization (ISO) 31000:2009 describes how organizations should establish internal
communication and reporting mechanisms that support accountability and ownership of risk, enable understanding of risk assessments,
and secure support for risk treatments or mitigations.
https://www.enisa.europa.eu/news/enisa-news/european-commission-opens-public-consultation-on-2018contractual-ppp20
19
https://www.enisa.europa.eu/news/enisa-news/european-commission-opens-public-consultation-on-2018contractual-ppp2019
Risk Management for Cybersecurity:
Security Baselines
13
Security baselines can support communication and bridge understanding across
both horizontal and vertical stakeholders, enabling more strategic decision
making and informed investments. To support communication and bridge
understanding, individuals and organizations must have a “common language”:
a shared way of interpreting, referencing, and using terms and concepts. In an
evolving field like cybersecurity, there is a heightened need to establish such
commonality. To do so effectively, a single document or reference point—for
example, a set of security baselines—must be understandable to and usable by
stakeholders with different expertise and roles, such as security practitioners
and business executives within one organization (or even by risk management
professionals across multiple organizations).
A common language and single reference point can stitch together the
perspectives and interests of stakeholders with varying expertise and roles,
which may require different types of information or levels of detail. For
example, security practitioners may benefit from more specific instruction
as they implement risk management steps to demonstrate compliance with
specific controls. Alternatively, executives may benefit from more abstracted
information that captures an organization’s readiness, resiliency, or maturity in
the context of desired security outcomes. A single document that demonstrates
the links between both specific and abstracted guidance will be meaningful
to both practitioners and executives, acting as a translator for both audiences.
Similarly, between or across multiple organizations, a single document can
facilitate communication around security learnings or act as a mechanism
for suppliers to share information with buyers about their risk management
practices.
Bridging cybersecurity risk management understanding across audiences by
using common language enables stakeholders to communicate in a meaningful
way about the risk landscape, resulting in more informed decisions about how
to prioritize and manage risks and creating continuity in security strategy,
planning, and investments. If executives can understand what practitioners are
aiming to achieve and regularly revisit progress on a relatively consistent set of
desired security outcomes, then they may better understand the strategic value
of resourcing practitioners to meet goals or to address gaps.
One approach that has been proven to create a common language and
to act as an effective bridge both within and between organizations is the
Cybersecurity Framework, developed by NIST in partnership with industry and
civil society stakeholders12. It does so by utilizing five overarching Functions (i.e.,
identify, protect, detect, respond, and recover), as well as multiple Categories,
Subcategories, and Informative References that disaggregate the high-level,
strategic Functions into concise statements of desired security outcomes
and, where applicable, potentially relevant controls and practices. In this way,
executives can quickly digest the purpose of the Functions, and managers
or practitioners can utilize the guidance in the Categories, Subcategories, or
Informative References that sit within each of those Functions. Ultimately,
this mapping enables all interested groups to have a common language and
grounded and meaningful dialogue about how to improve organizational
performance across or within particular Functions.
12 https://www.nist.gov/cyberframework
Risk Management for Cybersecurity:
Security Baselines
14
Advancing security through a risk-based and outcomes-
focused approach
For security baselines to be effective, they must enable enterprises to not
only focus on desired security outcomes but also prioritize among the risks
and capabilities that are most critical in their environments. Risk-based and
outcomes-focused security baselines enable enterprises to have sufficient
flexibility as they implement guidance or requirements, allowing their unique
infrastructure, operating environment, and business priorities to inform
decision-making. In turn, such flexibility means that enterprises can innovate,
integrating both security and productivity advancements into products and
services that benefit and better protect governments, enterprise customers,
and consumers. In addition, in a regulatory or procurement context, risk-based
and outcomes-focused security baselines focus government assessments of
products or services on meaningful criteria, helping to ensure that governments
understand the risks and mitigations that impact their environments.
III.
Risk-based approach: Focus security investments on priority technologies
and business functions
In adopting a risk-based approach to security, organizations identify, assess, and
manage risk in a prioritized way, recognizing that all activities involve some degree
of risk and that no organization has unlimited resources to apply to security. In
identifying and assessing risks, organizations focus on vulnerabilities, threats, and
consequences: vulnerabilities resulting from people, processes, and technology;
internal and external threats; and the consequences of a vulnerability being
exploited. In managing risks, organizations determine how to treat the risks that
they’ve identified and assessed, including by accepting, mitigating, transferring (e.g.,
via insurance), or avoiding risks. In using a risk-based approach, organizations use
their processes of identifying and assessing risks to inform decisions about how to
manage risks and make security investments, allocating greater organizational and
financial resources toward mitigating or transferring more significant risks.
Risk-based security baselines enable organizations to make security investment
decisions that best correlate with their risk profiles and business priorities. Different
sectors and organizations of various sizes may benefit from investing their security
resources differently (e.g., small and large financial institutions may be defending
against threat actors with varying resources and goals, necessitating different
defensive measures or detection capabilities). Likewise, organizations with different
functions or customers may face diverse threats. As such, risk-based security
baselines ensure that organizations have the flexibility to make risk management
decisions and scale up or down security investments in ways that are consistent with
their risk priorities. Risk-based security baselines also enable organizations to balance
investments in security with those that support efficient operations and continuous
improvement.
Risk Management for Cybersecurity:
Security Baselines
15
Outcomes-focused approach: Enable flexibility to keep pace with dynamic
technology and threats
In addition to being risk-based and prioritized, security baselines should be
outcomes-focused. As discussed above, both outcomes-focused and controls-
based guidance or requirements can have value in cybersecurity risk management.
However, governments should structure cross-sector security baselines around
security outcomes, articulating what organizations should aim to achieve (e.g.,
“control logical access to critical resources”) rather than how organizations should
implement security (e.g., “utilize two-factor authentication”), to ensure that the
baselines remain broadly and consistently applicable. Just as desired security
outcomes remain more relevant than controls as technology and the threat landscape
evolve, so do desired security outcomes remain more relevant than controls across
varying sectoral and functional contexts.
Outcomes-focused security baselines are critical to ensuring that both governments
and enterprises can utilize the most up-to-date products, services, and security
capabilities. As ICT innovation accelerates and threat actors continue to rapidly
evolve offensive techniques and strategies, governments and enterprises must also
be able to improve their defenses quickly. Rather than being locked in to using
technologies or capabilities that were state of the art when a particular control was
introduced, governments and enterprises must be able to deploy more secure or
convenient solutions as they become available, without the control having to be
revised continuously. Outcomes-focused approaches enable such agility.
The rapid pace of and variability among technology developments further
contributes to the need for outcomes-focused cross-sector security baselines. For ICT
and security organizations to continue to develop and deliver more secure solutions,
they must be able to innovate. In addition, as organizations simultaneously work to
develop new services with improved security features or new security capabilities,
they often take different approaches, resulting in significant variability in the
architecture of ICT products or services. Outcomes-focused security baselines enable
organizations to have the flexibility needed to implement requirements or guidance
in a way that complements those diverse and evolving architectures.
In addition to developing risk-based baselines, governments should focus on the
most important risks, ensuring that security baselines are as streamlined as possible.
While there is value in being comprehensive, doing so can also obfuscate important
details, potentially leading to overlooked risks. An all-encompassing approach is also
impossible to manage, as it is likely to result in confusion both when organizations
attempt to demonstrate compliance and when governments try to assess it. Risk
prioritization, by way of contrast, not only helps to ensure that the greatest threats
are mitigated, but also focuses attention and increases efficiency in demonstrating
security practices and assessing compliance.
Risk Management for Cybersecurity:
Security Baselines
16
As discussed above, a focus on outcomes in cross-sector baselines also leaves room
for sector-specific implementation or “how to” guidance, which should wholly
leverage and build on cross-sector security baselines but may also include more
prescriptive (i.e., controls-based) guidance as needed. Compared to cross-sector
security baselines, sector-specific implementation guidance can also be more rapidly
updated by governments and organizations through standards bodies, sector-
specific collaborations, or other mechanisms to reflect organizational and industry
learnings, changing threat models, and the development of innovative security
techniques or capabilities.
A recently published International Organization for Standardization (ISO)/
International Electrotechnical Commission (IEC) publication, ISO/IEC 27103, is
exemplary of an outcomes-focused, cross-sector approach.13 It is structured around
desired security outcomes, including both high-level desired outcomes (e.g.,
Protect) as well as more specific desired outcomes (e.g. Data at rest is protected). In
addition, ISO/IEC 27013 includes a range of ISO, ISO/IEC, and IEC standards, which
are mapped to specific desired outcomes, providing greater implementation detail
for practitioners to reference. By including not only ISO but also IEC standards, ISO/
IEC 27103 has increased applicability across sectors, and by including international
standards exclusively, it is particularly relevant globally.
13 https://www.iso.org/standard/72437.html; https://webstore.iec.ch/publication/62742
Risk Management for Cybersecurity:
Security Baselines
17
Leveraging existing best practices to the greatest extent
practicable
Leveraging existing best practices is the fourth key aspect of an effective
approach to developing security baselines. All stakeholders benefit from
leveraging existing best practices rather than starting from scratch, including
governments. The process of building out a set of risk management practices
from scratch is resource intensive. Instead, utilizing tried and tested methods
provides governments with a valuable starting point and more immediate
results, helping to raise the level of ecosystem cybersecurity and creating
opportunities for shared learning and exchange across governments.
Governments can leverage the substance or procedural aspects of existing best
practices without emulating methods of enforcement or the exact language
or content of a document. For example, a government developing regulatory
requirements may recognize the value of a set of best practices that has
been implemented through voluntary guidance in other markets. Likewise, a
government developing security baselines may find value in the structure and
much of the content of an existing best practice but iterate on top of it, making
adjustments in a way that is consistent with that government’s security or
assurance priorities.
Throughout this paper, numerous existing best practices have been referenced.
In the context of utilizing an open, collaborative, and iterative process for
developing security baselines, this paper referenced best practices implemented
by the European Commission, ENISA, NIST, Singapore, and Japan’s METI.
In addition, the substance of approaches from ISO/IEC 27103, the Center
for Internet Security’s “Top 20” controls, ISO 27001, and the Cybersecurity
Framework have been referenced.
There are also many examples of governments integrating existing best
practices as they develop new cybersecurity and risk management policies.
The Cybersecurity Framework, for instance, leverages and references ISO
27001, a global standard on information security, as well as Control Objective
for Information and Related Technologies (COBIT) and other international and
national best practices. Japan’s METI14 has translated and referenced various
NIST guidelines and documents for security policy and system operators15; The
Australian Securities & Investments Commission leveraged and referenced
the Cybersecurity Framework in outlining ‘health check prompts’ to help
organizations assess their cyber resilience16, and Public Safety Canada has noted
the relevance and applicability of the Cybersecurity Framework for advancing
cyber resiliency among Canadian organizations.17
IV.
14 http://www.meti.go.jp/policy/netsecurity/secdoc/ope_contents.html
15 http://www.nisc.go.jp/active/kihon/pdf/iot_framework2016
16 http://download.asic.gov.au/media/3062900/rep429-published-19-march-2015-1
17 https://www.publicsafety.gc.ca/cnt/rsrcs/pblctns/2016-fndmntls-cybr-scrty-cmmnty/index-en.aspx
http://www.meti.go.jp/policy/netsecurity/secdoc/ope_contents.html
http://www.nisc.go.jp/active/kihon/pdf/iot_framework2016
http://download.asic.gov.au/media/3062900/rep429-published-19-march-2015-1
https://www.publicsafety.gc.ca/cnt/rsrcs/pblctns/2016-fndmntls-cybr-scrty-cmmnty/index-en.aspx
Risk Management for Cybersecurity:
Security Baselines
18
Realizing economic, security, and
societal benefits
In today’s world, where people, data, and production constantly flow across borders,
leveraging existing best practices is especially critical. In recent decades, global production
and trade have resulted in enormous leaps in economic opportunity and technological
development. However, if global regulations, including those related to security baselines,
fragment or conflict, cross-border flows of resources will be disrupted, negatively
impacting growth and potentially curtailing the progress that has been made.
As such, the extent to which governments can synchronize security baselines and build
from existing best practices will have profound effects on a range of stakeholders as well
broader impacts on societal opportunity, economic development, and global security. For
governments, the process of building out a set of risk management practices from scratch
is resource intensive and time consuming; for large organizations that operate across
borders, having to comply with fragmented compliance requirements diverts resources
from security functions; and for local businesses, having to comply with fragmented
requirements limits market access. For all stakeholders, fragmentation increases the cost
of investing in or leveraging resources across borders. It reverses the global manufacturing
and outsourcing relationships that have helped to not only increase global economic
opportunity but also drive down the costs of developing and popularizing advanced
technologies like smart phones—which, in turn, support new business models and
operations across geographies.
Alternatively, focusing on policy alignment and building on existing best practices would
help to reduce compliance costs, advance security, and enable greater consistency. Greater
alignment of approaches across governments would create continuity and predictability,
positively impacting both global and local enterprises. A global organization would
have confidence in its ability to leverage resources and operate across borders without
unduly burdensome security and compliance costs; as such, it could continue to partner
with suppliers or customers across geographies. Likewise, a local organization would
have confidence in stable costs as it acts as a supplier of global organizations or invests
in new markets. Furthermore, there would be more opportunities for shared learning
and exchange across governments and enterprises, and the entire ecosystem would reap
security benefits from being able to rely on a culture of effective cross-border cooperation
among government authorities and industry stakeholders.
Importantly, as highlighted above, building from existing best practices and focusing
on policy alignment does not require that governments emulate the exact content of
or methods of enforcing an existing best practice. Rather, governments that start with
existing best practices, augment as needed, and contribute to the development of existing
best practices further global security.
Risk Management for Cybersecurity:
Security Baselines
19
Globally aligned security baselines
are not resource- or time-intensive to
develop, so potential security benefits
are realized quickly rather than
delayed amidst continued dependence
on technology for critical functions. In
addition, resources are not diverted
from building other government
skillsets needed to measure and
improve the effectiveness of security
baselines and ensure enterprises’
compliance. Moreover, the invaluable
ability to exchange learnings and
coordinate with other organizations is
realized.
Globally aligned security baselines
directly impact the security of
ministries, departments, and agencies
by enabling them to utilize products
and services from a broad set of
compliant technology and security
providers.
Globally aligned security baselines
directly impact small and mid-sized
local companies, which can operate
beyond their national market more
efficiently and leverage technology
from a range of suppliers, ensuring
access to best-in-class security.
Globally aligned security baselines
ensure that sufficient resources
are applied to security and risk
management rather than diverted
toward compliance. Throughout
the ecosystem, the impact of this is
multiplied, as third party suppliers are
also able to devote sufficient resources
to security and risk management
rather than diverting those resources
toward compliance.
Globally aligned security baselines
ensure that organizations continue
to invest in security innovation, as
organizations have confidence that
policies provide sufficient flexibility to
develop new techniques, capabilities,
and architectures.
Globally aligned security baselines
ensure that organizations continue
to invest in and leverage resources
across borders, maintaining the global
manufacturing and outsourcing
relationships that have helped to
not only increase global economic
opportunity but also drive down the
costs of developing and popularizing
advanced technologies.
Government Impact Industry Impact
Risk Management for Cybersecurity:
Security Baselines
20
Conclusion
Globally, dozens of countries are developing or evolving cybersecurity guidelines, regulations, and
standards that reference the need for security baselines for critical infrastructure. How governments
approach this effort will profoundly affect global security, societal opportunity, and economic
development. Utilizing an open, collaborative, and iterative process to develop an approach that
enables risk prioritization, focuses on desired security outcomes, and supports both horizontal and
vertical risk conversations will help organizations resource and implement security improvements
that are most relevant to their environments and priorities. In addition, utilizing an approach
that leverages the substance of existing best practices and is aligned with other governments’
efforts will be more efficient and effective for a range of stakeholders. All in all, the results for
governments, and their partners in the private sector and beyond, will be improved cybersecurity,
both locally and internationally, as well as continued societal opportunity and economic growth.
Risk Management for Cybersecurity:
Security Baselines
21
Version 1.0 – April 2018 i
Version 1.0 Center for
Internet Security® Risk
Assessment Method
For Reasonable Implementation and
Evaluation of CIS ControlsTM
Version 1.0 – April 2018 i
CIS RAM – Center for Internet Security® Risk Assessment Method (Version
1.0)
April 2018
This work is licensed under a Creative Commons Attribution-Non Commercial-No Derivatives 4.0
International Public License (the link can be found at https://creativecommons.org/licenses/by-nc-
nd/4.0/legalcode).
CIS RAM also incorporates the CIS Controls™ Version 7, which is licensed under a Creative
Commons Attribution-Non Commercial-No Derivatives 4.0 International Public License (the link
can be found at https://creativecommons.org/licenses/by-nc-nd/4.0/legalcode).
To further clarify the Creative Commons license related to the CIS Controls and CIS RAM, you
are authorized to copy and redistribute the content as a framework for use by you, within your
organization and outside of your organization for non-commercial purposes only, provided that (i)
appropriate credit is given to CIS, and (ii) a link to the license is provided. Additionally, if you
remix, transform or build upon the CIS Controls or CIS RAM, you may not distribute the modified
materials. Commercial use of the CIS Controls or CIS RAM is subject to the prior approval of
CIS® (Center for Internet Security, Inc.).
Background and Acknowledgements
The original content of CIS RAM was developed by HALOCK Security Labs. It is based on their
extensive experience helping clients and legal authorities deal with cybersecurity and due care
issues. Recognizing the universal need for a vendor-neutral, open, industry-wide approach to
these issues, HALOCK Security Labs approached CIS to make this work openly available to the
entire cybersecurity community. This generous contribution of intellectual property (and the
extensive work to generalize and tailor it to the CIS Controls) has been donated to CIS and is
now available and maintained as a CIS community-supported best practice.
As with all CIS work, we welcome your feedback, and we also welcome volunteers who wish to
participate in the evolution of this and other CIS products.
CIS gratefully acknowledges the contributions provided by HALOCK Security Labs and the
DoCRA Council in developing CIS RAM and the CIS RAM Workbook.
Significant contributions to Version 1 of CIS RAM were made by:
Principal Author:
Chris Cronin. Partner, HALOCK Security Labs
Contributing Authors:
Jim Mirochnik, Terry Kurzynski, and David Andrew, Partners, HALOCK Security Labs. Erik Leach
and Steve Lawn, HALOCK Security Labs. Paul Otto, Attorney, Hogan Lovells US LLP.
Review and vetting was provided by multiple members of the CIS staff.
Version 1.0 – April 2018 ii
Table of Contents
Foreword ………………………………………………………………………………………………………………….. iv
Who this risk assessment method is for……………………………………………………………………….. iv
What this document provides …………………………………………………………………………………….. v
The role of professional judgment ………………………………………………………………………………. v
Author’s Introduction ………………………………………………………………………………………………… vi
Structure of the Document ………………………………………………………………………………………… vii
Glossary …………………………………………………………………………………………………………………. viii
Risk Assessment Method Examples …………………………………………………………………………… x
Chapter 1: Risk Analysis Primer …………………………………………………………………………………. 2
CIS Risk Assessment Method for Due Care …………………………………………………………………. 3
Evolving Risk Analysis Methods …………………………………………………………………………………. 7
Overview of the CIS Risk Assessment Method ……………………………………………………………… 9
Selecting A Tier for Your Risk Assessment Instructions ………………………………………………… 12
Chapter 2: Control-Based Risk Assessment Instructions for Tier 1 Organizations…………. 15
The Risk Assessment Project ………………………………………………………………………………….. 15
Defining the Scope & Scheduling Sessions ………………………………………………………………… 17
Defining Risk Assessment Criteria ……………………………………………………………………………. 21
Defining Risk Acceptance Criteria …………………………………………………………………………….. 25
A Control-Based Risk Assessment Process ……………………………………………………………….. 27
Risk Treatment Recommendations …………………………………………………………………………… 38
Chapter 3: Asset-Based Risk Assessment Instructions for Tier 2 Organizations …………… 48
The Risk Assessment Project ………………………………………………………………………………….. 48
Defining the Scope & Scheduling Sessions ………………………………………………………………… 49
Defining Risk Assessment Criteria ……………………………………………………………………………. 53
Defining Risk Acceptance Criteria …………………………………………………………………………….. 59
An Asset-Based Risk Assessment Process ………………………………………………………………… 61
Risk Treatment Recommendations …………………………………………………………………………… 74
Chapter 4: Threat-Based Risk Assessment Instructions for Tiers 3 and 4 Organizations … 84
The Risk Assessment Project ………………………………………………………………………………….. 84
Defining Risk Assessment Criteria ……………………………………………………………………………. 85
Defining Risk Acceptance Criteria …………………………………………………………………………….. 92
A Threat-Based Risk Assessment Process…………………………………………………………………. 94
Risk Treatment Recommendations …………………………………………………………………………. 110
Chapter 5: Risk Analysis Techniques ………………………………………………………………………. 116
Risk Analysis Techniques ……………………………………………………………………………………… 116
Introduction …………………………………………………………………………………………………………. 116
Defining Impacts for Tier 1 organizations ………………………………………………………………….. 116
Defining Impacts for Tier 2, Tier 3, and Tier 4 organizations ………………………………………… 121
Estimating Likelihood Through “Defense-Readiness” Analysis ……………………………………… 127
Using Probability with Duty of Care Risk Analysis ………………………………………………………. 129
Version 1.0 – April 2018 iii
Noting How Realized Risk Might be Detected ……………………………………………………………. 133
Leveraging Duty of Care Risk Analysis for Maturity Models …………………………………………. 135
Interview Techniques ……………………………………………………………………………………………. 136
Evaluating Inherent Risk ……………………………………………………………………………………….. 139
Root Cause Analysis …………………………………………………………………………………………….. 140
Helpful Resources …………………………………………………………………………………………………. 142
Contact Information ……………………………………………………………………………………………….. 143
Version 1.0 – April 2018 iv
Foreword
The objective of the Center for Internet Security® Risk Assessment Method (“CIS RAM”) is to help
organizations plan and justify their implementation of CIS ControlsTM Version 7, whether those
controls are fully or partially operating. Few organizations can apply all controls to all information
assets, because – while reducing some risks – security controls also introduce new risks to
efficiency, collaboration, utility, productivity, or available funds and resources.
Laws, regulations, and information security standards all consider the need to balance security
against an organization’s purpose and its objectives, and require risk assessments to find and
document that balance. The risk assessment method described here provides a basis for
communicating cybersecurity risk among security professionals, business management, legal
authorities, and regulators using a common language that is meaningful to all parties.
The CIS RAM conforms to and supplements established information security risk assessment
standards, such as ISO/IEC 27005,1 NIST Special Publication 800-30,2 and RISK IT.3 By
conforming to these standards, the CIS RAM helps the reader conduct risk assessments
according to established standards. By supplementing these standards, the CIS RAM helps its
readers evaluate risks and safeguards using the concept of “due care” and “reasonable
safeguards” that the legal community and regulators use to determine whether organizations act
as a “reasonable person.”
The CIS® designed and prioritized the CIS Controls so that they would prevent or detect the most
common causes of cybersecurity events as determined by a community of information security
professionals. As a result, CIS Controls V7 has risk considerations at its core.
But because risks vary from one organization to the next, the risk analysis methods described in
this document can assist organizations in applying the CIS Controls so that they reasonably and
defensibly address the unique risks and resources at each organization.
Who this risk assessment method is for
Cybersecurity risk assessments are important tools for organizations that help them evaluate and
prioritize their risks, but also to determine when their risks are acceptable. This risk assessment
method is designed to be practical for a broad population of users, whether they are novices to
cybersecurity issues, capable of recognizing cybersecurity concerns, or experts.
Organizations that must demonstrate “reasonable” safeguards and risk management for
regulatory, contractual, or security management purposes may benefit from the use of the
method. Additionally, the CIS RAM is designed to promote meaningful communications and
consensus among technicians, non-technical management, security experts, risk managers, as
well as legal and regulatory professionals.
1 ISO/IEC 27005:2011 provided by the International Organization for Standardization.
2 NIST Special Publications 800-30 Rev. 1 provided by the National Institute of Standards and
Technology.
3 RISK IT Framework provided by ISACA.
Version 1.0 – April 2018 v
What this document provides
The CIS RAM guides readers to conduct risk assessments in a way that match the expectations
stated in laws, regulations, and information security standards. The CIS RAM accomplishes this
by providing instructions, templates, examples, and exercises to demonstrate its methods. These
substantiate the framework of a risk assessment.
The role of professional judgment
Using CIS RAM, the reader will be able to rapidly develop a risk register that communicates
reasonableness to many authorities and experts, but the reader will also need to bring their
professional judgment (theirs and the judgment of collaborating experts) to the task.
Professional judgment will help organizations determine the scope and boundaries of the risk
assessment, to define the organization’s mission, objectives, and obligations, to decide which
risks will be evaluated, to identify foreseeable threats, and to recommend risk treatment
safeguards.
Version 1.0 – April 2018 vi
Author’s Introduction
The information security community, regulators, attorneys, and managers all understand that
perfect cybersecurity is not possible. Even as organizations implement safeguards that are as
practical as CIS Controls V7, there are limitations to the degree that organizations can implement
security safeguards. Limited security resources (money, experts, and time), competing business
priorities, and the ever-changing threat landscape make it difficult for organizations to completely
implement a cybersecurity standard equally to all information assets.
Even without these challenges, organizations must operate in somewhat vulnerable environments
to fulfill their mission and achieve their objectives. For example, the security value of encryption is
obvious, yet information at some point must be unencrypted to serve its purpose. And sometimes
information must be unencrypted to enforce other security safeguards, such as data loss
prevention. But how does an organization know whether to accept the risk of those moments and
transactions when information is unencrypted? And how does it determine whether other
supporting safeguards are appropriately protecting the unencrypted information? There is no
single answer to that question or to other “grey area” cybersecurity questions that organizations
regularly encounter. To assist organizations in their security efforts, laws, regulations, the courts,
and information security professionals tell us to use risk assessments to answer for ourselves
whether we should accept or reduce risks.
Cybersecurity safeguards must be reasonable and appropriate. They must reduce the risk of
harm to organizations and to others, but they also must not create too great a burden on the
organizations that use those safeguards. The terms “reasonable” and “appropriate” are loaded
with many legal, regulatory, expert, and business meanings. But these meanings can be
addressed, documented, and justified using a well-constructed risk assessment.
By using the CIS RAM as part of their cybersecurity program, organizations will be more able to
adopt CIS Controls V7 in a way that can be successfully demonstrated as reasonable and
appropriate to internal management, authorities, security experts, and legal counsel who have an
interest in the organization’s success.
The CIS RAM document is designed to guide organizations step-by-step through their risk
assessment, regardless of their experience in conducting these assessments. We encourage
readers to work through each chapter that is suited for their organization, and to follow along with
the exercises, worksheets, and examples until their risk register is complete.
Chris Cronin
Partner, HALOCK Security Labs
Chair, DoCRA Council
Version 1.0 – April 2018 vii
Structure of the Document
Center for Internet® Security Risk Assessment Method (CIS RAM) is a documented process for
conducting risk assessments that address requirements for security, business, regulations, and
duty of care requirements. This document will describe the risk assessment method using the
following components:
• Instructions are the major portion of the CIS RAM. Instructions provide step-by-step guidance
for conducting a risk assessment as a project. Three sets of instructions are provided that
address the risk assessment method for organizations based on their risk management
maturity. Instructions may be further customized and adapted by each organization according
to their needs. Risk assessment techniques are provided at the end of the document to help
organizations further develop their risk assessment capabilities.
• Principles state the necessary and fundamental rules for assessing risks according to this
method. The principles are the fundamental characteristics of a risk assessment that
translates security concerns to regulatory, legal, and business expectations. As organizations
customize instructions and templates for their organization, these principles should remain.
Risk assessment processes that are developed and conducted without adherence to these
principles cannot be considered as “conforming” to the method.
• Examples demonstrate processes and steps. Examples will be accompanied by explanatory
scenarios to show the reader how each step is to be conducted. Examples are provided both
in this document, and in a separate document, the CIS_RAM_Workbook for ease of use.
• Templates model the risk assessment steps, risk analysis methods, and reporting. Templates
will assist in rapid adoption of the method’s processes by each organization, and will provide
for consistent risk assessment practices between organizations. Templates are provided in a
separate document, the CIS_RAM_Workbook for easy adoption of CIS RAM.
• Exercises encourage the reader to apply what they’ve learned in the instructions by using the
provided templates to design and conduct their own risk assessment.
• Background notes explain why a risk assessment step is taken, or why a principle is applied.
Background commentary enables risk practitioners to describe to interested parties how their
risk assessment addresses the needs of interested parties and authorities.
• The Glossary provides definitions for specialized terms used in this document. Because risk
management methods vary and audiences have variable experience in risk management, the
glossary will ensure consistent term usage and meaning.
—
This guide includes references a selection of controls from CIS Controls V7 as examples of
safeguards that are specifically selected to help protect organizations. Since such resources
change from time to time, please contact CIS or refer to our website for the most recent
information. (www.cisecurity.org)
Version 1.0 – April 2018 viii
Glossary
Appropriate: A condition in which risks to information assets will not foreseeably create harm that
is greater than what the organization or interested parties can tolerate.
Asset Class: A group of information assets that are evaluated as one set based on their similarity.
“Servers,” “end-user computers,” “network devices” are examples, as are “email servers,” “web
servers” and “authentication servers.”
Attack Path: A series of activities and information assets within the lifecycle of a security incident.
Attack Path Model: A description of how a specific attack path may occur within an environment.
Burden: The negative impact that a safeguard may pose to the organization, or to others.
Business Owners: Personnel who own business processes, goods, or services that information
technologies support. i.e. customer service managers, product managers, sales management.
Constituents: Individuals or organizations that may be benefit from effective security over
information assets, or may be harmed if security fails.
Control: A documented method for protecting information assets using technical, physical, or
procedural safeguards.
Control Objective: The intended outcome of a control.
Due Care: The amount of care that a reasonable person would take to prevent foreseeable harm
to others.
Duty of Care: The responsibility to ensure that no harm comes to others while conducting
activities, offering goods or services, or performing any acts that could foreseeably harm others.
Impact: The harm that may be suffered when a threat compromises an information asset.
Impact Score: The magnitude of impact that can be suffered. This is stated in plain language and
is associated with numeric scales, usually from ‘1’ to ‘3’ or ‘1’ to ‘5’.
Impact Type: A category of impact that estimates the amount of harm that may come to a party or
a purpose. The CIS RAM describes three impact types; Mission, Objectives, and Obligations.
Information Asset: Information or the systems, processes, people, and facilities that facilitate
information handling.
Inherent Risk: The likelihood of an impact occurring when a threat compromises an unprotected
asset.
Key Risk Indicator: Aggregations and trending analysis of measures that management may use
to understand their risk status.
Likelihood: The degree to which a threat is expected to create an impact. May be stated in terms
of frequency, foreseeability, or probability.
Measure: A repeatable, evidence-based indication that a safeguard achieves its control objective.
Observed Risk: The current risk as it appears to the risk assessor.
Probability: The product of statistical analysis that estimates the likelihood of an event.
Reasonable: A condition in which safeguards will not create a burden to the organization that is
greater than the risk it is meant to protect against.
Residual Risk: The risk that remains after a safeguard is applied. This concept is not directly used
by CIS RAM, but implies that risk is lowered when a safeguard is applied. Residual risk does not
take into account potential negative impacts to the organization when safeguards are applied.
Risk: An estimation of the likelihood that a threat will create an undesirable impact. In terms of
this method, risk may be expressed as the product of a likelihood and an impact.
Version 1.0 – April 2018 ix
Risk Analysis: The process of estimating the likelihood that an event will create an impact. The
foreseeability of a threat, the expected effectiveness of safeguards, and an evaluated result are
necessary components of risk analysis. Risk analysis may occur during a comprehensive risk
assessment, or as part of other activities such as change management, vulnerability
assessments, system development and acquisition, and policies exceptions.
Risk Assessment: A comprehensive project that evaluates the potential for harm to occur within a
scope of information assets, controls, and threats.
Risk Evaluation: The mathematical component of risk analysis that estimates the likelihood and
impact of a risk, and compares it to acceptable risk.
Risk Management: A process for analyzing, mitigating, overseeing, and reducing risk.
Risk Treatment Option: The selection of a method for addressing risks. Organizations may
choose to Accept, Reduce, Transfer, or Avoid risks.
Risk Treatment Plan: A comprehensive project plan for implementing risk treatment
recommendations.
Risk Treatment Recommendations: A listing of safeguards or processes that may be
implemented and operated to reduce the likelihood and/or impact of a risk.
Safeguard: Technologies, processes, and physical protections that prevent or detect threats
against information assets. Safeguards are implementations of controls.
Safeguard Risk: The risk posed by recommended safeguards. An organization’s mission or
objectives may be negatively impacted by a new security control. These impacts must be
evaluated to understand their burden on the organization, and to determine whether the burden is
reasonable.
Security: An assurance that characteristics of information assets are protected. Confidentiality,
Integrity, and Availability are common security characteristics. Other characteristics of information
assets such as velocity, authenticity, and reliability may also be considered if these are valuable
to the organization and its constituents.
Standard of Care: A set of practices, controls, or requirements that are known to improve
outcomes and reduce failures for practitioners of a specialized field or profession.
Steward: Personnel who are responsible for the security and proper operations of information
assets, (e.g. database administrator, records manager, or network engineer).
Threat: A potential or foreseeable event that could compromise the security of information assets.
Threat Model: A description of how a threat could compromise an information asset, given the
current safeguards and vulnerabilities around the asset.
Vulnerability: A weakness that could permit a threat to compromise the security of information
assets.
Version 1.0 – April 2018 x
Risk Assessment Method Examples
CIS RAM provides three sets of instructions that each describe a full risk assessment project.
Each set of instructions is designed for organizations of varying information security management
capabilities to increase the method’s usefulness.
All three sets of instructions present a fictional organization that is conducting an information
security risk assessment, and that improves its risk management capabilities over time. The
example organization begins the risk assessment in the first set of instructions as a security
novice with little involvement by business management. After a year of improving their security
posture and abilities, they assess risk in the second set of instructions using more refined
reasoning and methods, and in collaboration with business management. Finally, they mature
enough as a capable organization to take on complex risk analysis in the third set of instructions.
The example organization described in this document manufactures and services medical
devices (“diary devices”) that read biological information from patients that wear the devices. The
organization works in clinical environments to support the patients as well as the devices, and as
a result carries private health information about the patients. Because they work with military and
veterans’ organizations, many of their patients are active or former members of the armed forces.
As a result, the organization poses heightened risk and requires heightened scrutiny over their
cybersecurity controls.
The example organization is hypothetical and is not based on a known organization, technology,
or service. But the risks they encounter are commonly seen and managed by many types of
organizations. Example materials related to the example organization are provided in the
document CIS_RAM_Workbook in re-usable templates.
The reader will best develop an understanding of the risk assessment method by following
along with the workbook, and by entering their own examples in the spaces provided
within each sample worksheet.
Version 1.0 – April 2018 1
Center for Internet Security®
Risk Assessment Method
CIS RAM Version 1.0
April 2018
Version 1.0 – April 2018 2
Chapter 1: Risk Analysis Primer
CIA RAM describes a method for cybersecurity risk analysis that includes methods that are new
to most readers. Chapter 1 will provide an explanation and description of new concepts,
language, and processes to provide the reader with a solid foundation for the remaining chapters.
After completing Chapter 1, the reader will be directed to one of three chapters that provide
instructions for conducting risk assessments. Chapters 2, 3, and 4 present processes, materials,
and examples that are suitable for organizations with varying degrees of capability for conducting
risk assessments.
After completing the instructions chapters, all readers will benefit from the guidance, tips, and
deep dives presented in Chapter 5.
Version 1.0 – April 2018 3
CIS Risk Assessment Method for Due Care
Introduction
Laws, regulations, and information security standards do not expect that the public can or will
prevent all information security incidents. They instead make us responsible for looking ahead to
what might go wrong, and to use safeguards that are not overly burdensome to prevent that
harm. That is the essence of Duty of Care Risk Analysis4 (“DoCRA”) that the CIS RAM is based
on.
• Since 1993, all US regulations – whether or not they are related to information
security – require risk analysis to achieve a cost-benefit balance while achieving
compliance.5
• Information security standards have called on the public to use risk analysis when
designing security controls that match their environment.6
• Judges have used a “duty of care balance test” to determine liability in data breach
cases.7
• The Federal Trade Commission has consistently required that organizations use risk
assessments to determine the reasonableness of their security controls.8
• The General Data Protection Regulation (“GDPR”) that requires privacy protections
for EU residents, and bases its security requirements on risk analysis.9
Experts and authorities consistently require organizations to secure information and systems as
much as they can to prevent harm to others, but not to allow safeguards to be overly burdensome
to them or the public. And they point to risk assessments as the way to find the balance.
4 Also known the DoCRA Standard. https://www ra.org.
5 Executive Order 12866” signed in 1993 requires all federal regulation to be enforced using cost-
benefit analysis. The Office of Management and Budget enforces the order in part by requiring
that regulated organizations use risk assessments to identify effective controls that are
“reasonable.”
6 See ISO/IEC 27001:2013, NIST SP 800-53 Rev. 4, PCI-DSS v3.2
7 See Dittman v. UPMC, 154 A.3d 318 (Pa. Super. Ct. 2017), In re: Target Corporation Customer
Data Security Breach Litigation, Memorandum and Order, MDL No. 14-2522 (D. Minn. 2014)
8 Federal Trade Commission. “Commission Statement Marking the FTC’s 50th Data Security
Settlement.” www.ftc.gov/system/files/documents/cases/140131gmrstatement
9 General Data Protect Regulation. Directive 95/46/EC.
Version 1.0 – April 2018 4
Basis in Law and Regulation
CIS RAM’s risk analysis method was designed to provide common ground for security specialists
and business managers, and for legal and regulatory authorities who must evaluate the
sufficiency of security safeguards.
Risk analysis became the basis of regulatory law in 1993 when President Bill Clinton signed an
executive order, E.O. 12866,10 that required regulations to be enforced using a cost-benefit
analysis. The Office of Management and Budget determined that the best way to achieve cost-
benefit analysis was to embed risk analysis in all existing and new regulations.
Starting in 1999 the United States began enforcing regulations with information security and
privacy requirements that used risk analysis as the basis for compliance. The Gramm-Leach-
Bliley Act Safeguards Rule,11 the HIPAA Security Rule,12 and the Federal Trade Commission all
required that organizations conduct risk assessments to define their own compliance goals. Risk
assessments should help organizations determine for themselves the likelihood and impact of
threats that could harm the public, and ensure that safeguards would not be overly burdensome.
This risk analysis has been commonly described as “Risk = Impact x Likelihood.”
At about this time this same idea emerged independently among a separate set of professionals.
Domestic and international information security standards bodies developed risk assessment
methods such as NIST Special Publications 800-30, ISO 27005, and RISK IT to help the public
assess risks in information technology environments. These information security standards also
used the same equation used by U.S. regulators – “Risk = Impact x Likelihood” – to express the
foreseeability of harm that might come to information and information systems.
In parallel with the development of these two efforts (and since earlier in the twentieth century)
attorneys and judges debated in court rooms and in law journals about how to determine whether
someone acted as a “reasonable person” when a plaintiff sued for damages. These debates led
to the creation of the “Learned Hand Rule”13 (aka “the Calculus of Negligence”). The Hand Rule,
as it is now known, states that a burden to prevent harm should not be greater than the
probability of harm times the liability after a harmful event; or mathematically stated, B <= P x L.
Courts (variably) have extended this rule to “duty of care balancing tests” that determine whether
lack of foresight and less-than-reasonable safeguards led to harm.
But while these disciplines – law, information security, and regulations – all drew on a common
definition of risk, each seemed to be unaware of the other’s risk analysis methods. Even so, each
discipline searched for a universal translator that would allow the entire community of experts and
authorities to understand one another.
The CIS RAM provides that universal translator.
10 Executive Order 12866 – Regulatory Planning and Review, 58 FR 51735; October 4, 1993
11 Gramm Leach Bliley Act Safeguards Rule 16 CFR Part 314
12 HIPAA Security Rule 45 CFR Part 160 and Subparts A and C of Part 164
13 U.S. v. Carroll Towing, 159 F.2d 169 (2d Cir. 1947)
Version 1.0 – April 2018 5
CIS RAM Principles and Practices
CIS RAM adopts the three principles and ten practices from Duty of Care Risk Analysis. The
three principles state the characteristics of risk assessments that align to regulatory and legal
expectations. The ten practices describe features of risk assessments that make the three
principles achievable.
Principles
1. Risk analysis must consider the interests of all parties that may be harmed by the risk.
2. Risks must be reduced to a level that authorities and potentially affected parties would
find appropriate.
3. Safeguards must not be more burdensome than the risks they protect against.
Practices
1. Risk analysis considers the likelihood that certain threats could create magnitudes of
impact.
2. Risks and safeguards are evaluated using the same criteria so they can be compared.
3. Impact and likelihood scores have a qualitative component that concisely states the
concerns of interested parties, authorities, and the assessing organization.
4. Impact and likelihood scores are derived by a numeric calculation that permits
comparability among all evaluated risks, safeguards, and against risk acceptance criteria.
5. Impact definitions ensure that the magnitude of harm to one party is equated with the
magnitude of harm to others.
6. Impact definitions should have an explicit boundary between those magnitudes that
would be acceptable to all parties and those that would not be.
7. Impact definitions address; the organization’s mission or utility to explain why the
organization and others engage risk, the organization’s self-interested objectives, and the
organization’s obligations to protect others from harm.
8. Risk analysis relies on a standard of care to analyze current controls and recommended
safeguards.
9. Risk is analyzed by subject matter experts who use evidence to evaluate risks and
safeguards.
10. Risk assessments cannot evaluate all foreseeable risks. Risk assessments re-occur to
identify and address more risks over time.
Version 1.0 – April 2018 6
Table 1 aligns these principles and practices with the three disciplines of law, regulations, and
information security standards.
Table 1 - CIS RAM Principles and Practices Alignment to Law, Regulations, and Security Standards
CIS RAM and DoCRA Principles and Practices
Law
Regulations
Security
Standards
Risk analysis must consider the interests of all parties
that may be harmed by the risk.
Risks must be reduced to a level that authorities and
potentially affected parties would find appropriate.
Safeguards must not be more burdensome than the risks
they protect against.
Risk analysis considers the likelihood that certain threats
could create magnitudes of impact.
Risks and safeguards are evaluated using the same
criteria so they can be compared.
Impact and likelihood scores have a qualitative
component that concisely states the concerns of
interested parties, authorities, and the assessing
organization.
Impact and likelihood scores are derived by a numeric
calculation that permits comparability among all evaluated
risks, safeguards, and against risk acceptance criteria.
Impact definitions ensure that the magnitude of harm to
one party is equated with the magnitude of harm to
others.
Impact definitions should have an explicit boundary
between those magnitudes that would be acceptable to
all parties and those that would not be.
Impact definitions address; the organization’s mission or
utility to explain why the organization and others engage
risk, the organization’s self-interested objectives, and the
organization’s obligations to protect others from harm.
Risk analysis relies on a standard of care to analyze
current controls and recommended safeguards.
Risk is analyzed by subject matter experts who use
evidence to evaluate risks and safeguards.
Risk assessments cannot evaluate all foreseeable risks.
Risk assessments re-occur to identify and address more
risks over time.
Key: Fully addressed Partially addressed Not addressed
Organizations that conduct risk assessments using the CIS RAM will have a plan for
implementing CIS Controls V7 that is reasonable, and defensible to authorities and experts alike.
Version 1.0 – April 2018 7
Evolving Risk Analysis Methods
Evolving Classic Risk Concepts
To bridge information security risk analysis with legal and regulatory expectations, CIS RAM
builds on and extends a few classic risk analysis concepts. This section will briefly describe how
CIS RAM evolves risk evaluation, and definitions for “impact,” risk acceptance, and residual risk.
Calculating Risk Includes Multiple Impacts
CIS RAM uses the classic risk assessment calculation “Risk = Impact x Likelihood” with a few
modifications. Most significantly, risk is calculated by multiplying a likelihood value by multiple
impact values. These multiple impacts include impacts to the organization’s objectives, it’s
mission, and is obligations to protect others. Organizations should be aware of the many ways
that information security risk can create harm.
The risk calculation used by CIS RAM resembles the structure below:
“Risk = Max (Mission Impact, Objectives Impact, Obligations Impact) x Likelihood.”
The instructions provided later in this document clearly describe how this calculation works.
Organizations that use this extended calculation will consistently consider the many ways that
information security risks can create harm.
Impact Definitions Include Harm to Multiple Parties
To ensure fairness and balance, impact definitions will include potential harm to individuals and
organizations that may be impacted by risks. Impacts and impact magnitudes will be stated in
qualitative and quantitative form to easily communicate levels of risk to all interested parties, and
in a way that matters to each party.
Risk Acceptance Is Clearly Defined
CIS RAM provides organizations with clear guidance for defining acceptable risk that appears fair
to authorities and interested parties, and that can be consistently applied to all information
security risks.
Acceptable risk will consider whether a observed risk is “appropriate” (all potentially affected
parties would agree that the risk is acceptable), and whether a recommended safeguard is
“reasonable” (it does not create more of a burden than the risk it protects against).
By expanding the definition of risk acceptance by these two factors, organizations will have an
easily communicated rationale for accepting risk, or for prioritizing unacceptable risk.
“Residual Risk” is Known As “Safeguard Risk”
“Residual risk” has traditionally meant the reduced amount of risk that remains after a security
control has been implemented. Organizations have generally used “residual” to declare how a
planned security safeguard presents acceptable risk. CIS RAM evolves the notion of a “residual
risk” to “safeguard risk” to describe the risk that a new safeguard may pose.
The purpose behind evaluating residual risk this way is to address the fact that new controls often
have unintended consequences. Recall that impact definitions will be based on multiple factors,
such as an organization’s mission, its objectives, and its obligations (described in more detail
later in the document). Security controls may reduce the risk to security obligations by controlling
access to data, but may increase the risk to the organization’s mission which requires sharing the
data. Legal decisions and regulations consider these excessive safeguards as “burdens” because
they may harm the organization that is trying to protect the data.
Version 1.0 – April 2018 8
By evaluating safeguard risk using the same criteria that are used to evaluate risks, organizations
will be more cognizant of the true cost of controls, and will have a defensible way of stating
whether recommended controls are overly burdensome to them or the public.
Evolving Risk Acceptability
Figure 1 illustrates how CIS RAM evaluates “appropriate” risk using a simplified risk statement. In
this scenario, an organization is analyzing a risk of a lost device, and estimates the likelihood and
expected impact of the loss. Impact definitions estimate potential harm to the organization, and to
others.
Using a scale of ‘1’ to ‘3’, the organization multiplies the likelihood score by the higher of the two
impact scores to arrive at a risk score of ‘6’. In this example, an acceptable risk would be less
than ‘4’, so the score of ‘6’ is not appropriate. “Others” would not accept the possibility of this risk.
Note: The CIS RAM provides extensive guidance on how likelihood and impact scoring and
acceptable risk criteria are defined. The values in Figure 1 and Figure 2 are provided simply for
illustrative purposes.
Figure 1 - Simplified Risk Model Showing Inappropriate Risk
In Figure 2 the inappropriately high risk is matched with a recommended safeguard to encrypt all
devices. Because a safeguard is evaluated using the same criteria as the risk, the organization is
evaluating the burden of the safeguard. In this case, they believe there is a small likelihood (‘1’) of
a notable cost impact (‘2’). As a result, the safeguard risk calculates as ‘2’ which is lower than the
observed risk it is addressing (‘6’). As a result, this safeguard is reasonable.
Figure 2 – Simplified Risk Model Showing a Reasonable Safeguard
Version 1.0 – April 2018 9
Is This Extended Analysis Worthwhile?
Put simply, yes.
Information security controls are very often considered to be a hindrance to business. Users often
complain that security controls get in the way of productivity, efficiency, ease of collaboration and
communication, and other business-impacting concerns. Organizations should take these
complaints seriously. Fortunately, regulators have provided organizations with a means to
evaluate these concerns. Moreover, courts consider the burden of safeguards in lawsuits and
would understand the reasoning that this risk analysis provides.
By evaluating risks and their recommended safeguards using the same criteria, organizations
ensure that risk analysis addresses the concerns of all parties within and outside of their
organization, and provides evidence of their conscientious decision to regulators and judges.
Overview of the CIS Risk Assessment Method
Using Risk Assessments to Design and Evaluate CIS Controls V7
CIS Controls V7 was designed to address the most common causes of security incidents in the
general public. As a result, the CIS Controls are to a degree risk-prioritized, especially if
organizations implement the first five CIS Controls before implementing the remaining 15.
However, each organization has special circumstances, including the potential harm they may
cause to others, the need to operate somewhat vulnerable systems based on their mission, the
needs of their constituents, their available resources, and the foreseeability of threats in their
industry.
The risk assessment method described by CIS RAM will help organizations determine whether
their implementation of CIS Controls V7 – or their de-prioritization or customization of controls – is
reasonable and appropriate given security, legal, and regulatory considerations.
This risk assessment method describes multiple ways that organizations may evaluate, assess,
and design safeguards using the CIS Controls.
• In some cases, organizations may start simply and list the Controls to determine whether
their information assets are sufficiently resilient against foreseeable threats.
• More capable organizations may list their information assets first, then consider whether
associated CIS Controls sufficiently protect those assets against foreseeable threats.
• Organizations with a command of how threats operate may start with a list of known or
foreseeable threats against information assets and determine how controls should be
implemented to address them.
Each of these approaches relies on the organization’s ability to conduct that kind of analysis. And
those abilities depend on the involvement of business management in information security, the
availability of time and resources to examine information assets and risks, and the expertise of
the personnel for conducting the analysis.
Regardless, this risk assessment method will provide a model for organizations to evaluate risk
based on the harm they may pose to themselves or their constituency, and to determine whether
the burden of each of the CIS Controls – implemented as safeguards – are appropriate.
Risk Assessment Process
A risk assessment is a project that analyzes the risk posed by a set of information assets, and
recommends safeguards to address unacceptably high risks.
While the order of events in a risk assessment project will vary from organization to organization,
the following activities are generally applied:
Version 1.0 – April 2018 10
Analyze the Observed risk
• Define the Scope: Identify information assets that are being assessed as well as the owners
and stewards of the information assets.
• Schedule Sessions: Schedule the interviews and sessions for evidence review.
• Develop the Risk Assessment and Acceptance Criteria: Establish and define the criteria for
evaluating and accepting risk.
• Gather Evidence: Interview personnel, review documents, and observe safeguards.
• Model the Risks: Evaluate the current safeguards that would prevent or detect foreseeable
threats against the security of information assets.
• Risk Evaluation: Estimate the likelihood and impact of security breaches to calculate the risk
score, then determine whether identified risks are acceptable.
Propose Safeguards
• Propose Safeguards: Recommend safeguards from CIS Controls V7 that would reduce
unacceptable risks.
• Evaluate Proposed Safeguards: Risk-analyze the recommended safeguards to ensure that
they pose acceptably low risks without creating an undue burden.
Risk Assessment Criteria
Risk analysis requires a consistent, repeatable method for estimating and evaluating risk. Risk
assessment criteria provide organizations with measures for consistently rating the likelihood and
impact of foreseeable threats that may compromise the security of information assets.
Risk assessment criteria are often thought of in terms of a 3 x 3 grid or a 5 x 5 grid, with each
dimension representing either “likelihood” values or “impact” values. While scores of ‘1’ through
‘3’ or ‘1’ though ‘5’ are convenient for calculating risk as a product, they are not meaningful by
themselves. So criteria must also have a plain-language component that describes levels of
impact and likelihood that are meaningful to the organization.
Risk assessment criteria in a simplified format may appear similar to this:
Table 2 - Simplified Impact Criteria
Impact Score Impact Score Defined
1 No or minimal harm would result.
2 Harm would not be tolerable.
3 Harm may not be recoverable.
Table 3 - Simplified Likelihood Criteria
Likelihood Score Likelihood Score Defined
1 Not foreseeable.
2 Expected to occur.
3 Regular occurrence.
Version 1.0 – April 2018 11
Risk Acceptance Criteria
Laws and regulations require that organizations apply “reasonable” and “appropriate” safeguards
to ensure that the resulting risk is acceptable. The acceptability of risk can be demonstrated using
risk analysis that addresses the tolerability of the risk and the burden of safeguards that protect
against the risk.
While every organization will define its own risk tolerance, this method provides a process for
doing so using plain language and simple math. An example of defining risk acceptability is
provided in Table 4 using the simplified impact and likelihood criteria from above. Organizations
will develop their risk acceptance criteria by first defining what unacceptable risk is.
In this case the organization has determined its risk acceptance criteria by first deciding that it will
not accept a risk that may cause intolerable harm (as indicated by the red box).
Table 4 - Simplified Impact Criteria for Risk Acceptance
Impact Score Impact Level Impact Score Defined
1 Acceptable No or minimal harm would result.
2 Unacceptable Harm would not be tolerable.
3 High Harm may not be recoverable.
Then the organization determined that a threat that is expected to occur (and to create harm)
must be avoided (as indicated in the red box in Table 5).
Table 5 - Simplified Likelihood Criteria for Risk Acceptance
Likelihood Score Likelihood Score Defined
1 Not expected to occur
2 Expected to occur
3 Regular occurrence
And finally, the organization combined these limits to express their acceptable risk in both plain
language, and in mathematical terms.
Table 6 – Risk Acceptance Criteria
Version Definitions of Acceptable Risk
Plain language We must reduce risks that are expected to create intolerable harm.
Mathematical Acceptable Risk < 2 x 2; or Acceptable Risk < 4
Version 1.0 – April 2018 12
Background – “Reasonableness” and Risk Analysis
The “reasonable person” is used in law as a hypothetical person – or legal fiction – who
embodies the sum of our traditions, values, and responsibilities for taking care not to harm
others while we engage in public life. The reasonable person has been used in cases to
evaluate appropriate behavior for activities such as building and maintaining structures,
offering goods and services, or handling assets such as information and information
technologies. A reasonable person can engage in activities for their own benefit, but must take
care, using appropriate precautions, not to harm others in the process.
In litigation, a judge will often use a “duty of care” or “multi-factor” balancing test to determine
the degree to which a defendant was acting reasonably when a plaintiff was harmed. And in
regulations organizations must apply “reasonable” safeguards to protect others from harm.
A judge’s duty of care balancing test is very similar in structure to this risk assessment
method. An organization will consider foreseeable threats that their business may cause
others. They will determine how effectively they prevent that harm by using CIS Controls V7
as a standard for appropriate cybersecurity practices. They will estimate the likelihood and
impact of the expected harm of a foreseeable threat, and they will consider alternative
safeguards that effectively lower risks without being overly burdensome. In this way, judges
and cybersecurity practitioners use the same language to describe reasonable cybersecurity
practices.
In similar fashion, a regulator will ask regulated organizations to demonstrate the
reasonableness of their safeguards by reviewing the organization’s risk register. Since 1993
US federal regulations require that regulatory rules are not overly burdensome to the public,
and that a “cost-benefit” analysis is performed to determine whether regulatory actions are
overly burdensome and appropriate to protect the public. Regulatory agencies, including those
that govern cybersecurity rules and regulations, require risk assessments as the method for
balancing the potential harm to others against the cost of safeguards.
Selecting A Tier for Your Risk Assessment Instructions
This document is designed to be useful for organizations with varying levels of security
management capabilities. These capability levels align with Framework Implementation Tiers
(“Tiers”) as defined by the NIST Cybersecurity Framework.14 The Tiers indicate “how an
organization views cybersecurity risk and the processes in place to manage that risk.”15 The Tiers
are defined by NIST in the following way (abbreviated).
Tier 1: Partial
• Risk Management Process – Informal and ad hoc.
• Integrated Risk Management Program – Limited awareness within the organization.
• External Participation – Not coordinating with external entities.
14 Framework for Improving Critical Infrastructure Cybersecurity, Version 1.0, National Institute of
Standards and Technology. February 12, 2014
15 Ibid, pg. 9.
Version 1.0 – April 2018 13
Tier 2: Risk Informed
• Risk Management Process – Informed by organization risk objectives.
• Integrated Risk Management Program – Risk-informed, management-approved
processes and procedures.
• External Participation – Not coordinating with external entities.
Tier 3: Repeatable
• Risk Management Process – Enforced through policy, and updated with changes in the
environment and threats.
• Integrated Risk Management Program – Risk-informed policies and processes are used
enterprise-wide. Personnel are skilled and informed to work securely.
• External Participation – Receiving information from partners to make internal risk-based
decisions.
Tier 4: Adaptive
• Risk Management Process – Adaptive through lessons learned and continuous
improvement.
• Integrated Risk Management Program – Enterprise-wide culture of security awareness
and continuous improvement based on lessons learned and external information.
• External Participation – Sharing security and threat information with partners.
CIS RAM provides three sets of instructions, templates, exercises, and examples for conducting
risk assessments, each with increasing complexity. These three sets of materials are suitable for
Tier 1 organizations, Tier 2 organizations, and both Tier 3 and Tier 4 organizations. The reader
can determine which of these levels and documentation are best suited to them by reviewing the
characteristics provided below.
Tier 1 materials are well-suited to organizations with the following characteristics:
• NIST Tier: Tier 1 organizations. Tier 1 materials are best suited for organizations that do
not coordinate their information security plans and requirements throughout the
organization. Information security is largely driven by technology management.
• Expertise: The organization is able to identify generic threats, but not specific methods
for hacking systems, devices, and applications.
• Time: The organization can absorb the time needed to evaluate information risks at the
level of generic systems, devices, and applications.
Tier 2 materials are well-suited to organizations that enjoy more collaboration with business
management, and have more resources and capabilities for analyzing security risks and planning
programs.
• NIST Tier: Tier 2 organizations. Tier 2 materials are best suited for organizations that
have at least some collaboration with non-technical business management to define risk
criteria.
• Expertise: The organization has resources and capabilities to analyze common security
threats, and to plan risk-appropriate safeguards. However, they do not have on-hand
skills to model how threats would operate within their organization.
Version 1.0 – April 2018 14
• Time: The organization is able to invest sufficient time to analyze risks at the level of
specific systems, devices, and applications, and sub-components within those assets.
Tier 3 or 4 materials are well-suited to organizations that receive security and threat information
from outside sources, that have significant knowledge of information security topics, and time to
evaluate threat scenarios that risk assessments are based on.
• NIST Tier: Tiers 3 and 4 organizations. Tiers 3 or 4 materials are best suited for
organizations that are using risk-based criteria for enterprise-wide policies and
processes.
• Expertise: The organization has resources and capabilities to analyze security threats,
and to plan risk-appropriate safeguards, including the on-hand skills to model how threats
would operate within their organization.
• Time: The organization is able to invest time to analyze risks at the level of specific
systems, devices, and applications within the context of specific threats.
The reader should determine which level materials are best suited to their organization, and
should follow the instructions that are provided in that level. They may also decide to learn and
use the methods described in other instruction sets, but should stay within their level as much as
possible until they are comfortable with their existing risk assessment processes.
Version 1.0 – April 2018 15
Chapter 2: Control-Based Risk Assessment
Instructions for Tier 1 Organizations
Tier 1 risk assessment instructions are well-suited to organizations that fit the profile of Tier 1
organizations as described by the NIST Cybersecurity Framework. These organizations can be
identified as having the following characteristics:
• NIST Tier: Tier 1 organizations. Tier 1 materials are best suited for organizations that do
not coordinate their information security plans and requirements throughout the
organization. Information security is largely driven by technology management.
• Expertise: The organization is able to identify generic threats, but not specific methods
for hacking systems, devices, and applications.
• Time: The organization can absorb the time needed to evaluate information risks at the
level of generic systems, devices, and applications.
This chapter is comprised of sections that each address a specific activity within a risk
assessment. Readers should engage this chapter by first reading the text in each section, and
then conducting the exercises that are recommended for each section. The material presented in
the CIS RAM is substantially different from many other risk assessment standards and models,
so the reader should first understand the aim of each section, and then practice what they learn
using templates that are provided in the supplementary document CIS_RAM_Workbook.
While conducting their first CIS RAM-based risk assessment, organizations should be careful to
not try to “boil the ocean.” Regulatory bodies and information security standards alike understand
that not all risks can be identified in a single assessment. Organizations should continuously and
regularly assess risks to identify, understand, and manage risks over time.
The Risk Assessment Project
Overview
Risk assessments are projects with clear steps for preparing, conducting, and reporting risk
analysis. And while risk assessment projects can be modeled with a typical plan, each
organization’s project approach will vary depending on factors such as resource availability, and
will develop over time as organizations become more capable in their cybersecurity maturity. This
section will describe a risk assessment project, its components and variations, and will present
guidance for preparing the plan.
The Project Outline
Risk assessments are conducted using a series of steps that include typical actions, and roles as
illustrated in Table 7.
Table 7 – Example Risk Assessment Project Outline
Step Task Key Roles
1 Defining the Scope & Scheduling Sessions Executives, Management, Assessor
2 Defining Risk Assessment Criteria Management, Assessor
3 Defining Risk Acceptance Criteria Executives, Management, Assessor
Version 1.0 – April 2018 16
Step Task Key Roles
4 Risk Assessment (Control-Based)
4.1 Gather Evidence Personnel, Management, Assessor
4.2 Model the Threats Personnel, Management, Assessor
4.3 Risk Evaluation Assessor
5 Propose Safeguards
5.1 Evaluate Proposed Safeguards Assessor, Management
During Step 1 (Defining the Scope & Scheduling Sessions), the organization will determine which
information assets to include in their evaluation. They will also identify business owners and
technical stewards who will provide evidence and interviews to assess those assets. The risk
assessor will then schedule interview sessions with those owners and stewards.
In Step 2 (Defining Risk Assessment Criteria) the organization will define the rules by which they
assess and score risks. They will define their mission (the value they bring to others), and their
obligations (the potential for harm against others) to establish what they are trying to protect.
They will then define scoring schemas to be used for impact and likelihood estimation.
In Step 3 (Defining Risk Acceptance Criteria) the organization will establish their risk tolerance by
selecting a combination the likelihood of an impact that would be tolerable to all parties (the
organization and parties that may be harmed by realized risks).
In Step 4 (Risk Assessment – Control-Based) the risk assessor will evaluate the risks of the
information assets. For Tier 1 organizations, the analysis includes the following activities:
• “Gather Evidence” involves a review of documents, such as policies, procedures,
standards, and benchmarks. It also includes interviews with management and personnel.
Evidence gathering also entails observation of configurations, artifacts, facilities, records,
and work processes to determine whether they operate in secure or vulnerable ways.
Tier 1 organizations should also consider reviewing the configurations of controls and
looking for evidence of their effectiveness. This may be challenging for organizations at
this level. Vulnerability scanners and configuration scanners using SCAP policies may
provide efficient analysis of technical systems to assist in this analysis.
• “Model the Threats” entails the most variety in approaches that depend on the
cybersecurity maturity of the organization. Each organization, however, will model risks
with at least these components: considering the CIS Controls that should be in place to
protect information assets; determining whether those safeguards are effectively in place
to protect information assets; identifying vulnerabilities that may allow breaches of the
assets; and identifying threats that could take advantage of those vulnerabilities.
• During “Risk Evaluation” the organization will estimate the likelihood and impact of the
risks. The estimates will be based on the scoring and criteria that were established in
Step 2. The risk score will be automatically calculated to determine whether the current
implementations of CIS Controls are already reasonable.
During Step 5 (Propose Safeguards) the organization will consider how to address unreasonable
risks by selecting CIS Controls that should be implemented to address each risk, and specifically
Version 1.0 – April 2018 17
how the controls will be implemented. These safeguards may include security devices, physical
safeguards, training, oversight processes, or other methods. The risk assessor then will test the
reasonableness of the safeguards during “Evaluate Proposed Safeguards.” The risk assessor will
evaluate the proposed safeguards using the same criteria that were used to evaluate the risks.
A project plan template is available in the supplementary document CIS_RAM_Workbook.
Defining the Scope & Scheduling Sessions
Note: To best understand the content of this chapter, the reader should first read each section of
the chapter, then go through the recommended exercises at the end of each section to gain
practical knowledge of the section’s topics. The reader will be directed to use the templates that
are provided in the supplementary document CIS_RAM_Workbook to attempt their exercises.
Defining the Scope
Organizations should conduct risk assessments against a clearly defined scope of information
assets. A single theme usually bounds the scope of assets, such as “information assets that
contain sensitive information,” “the data center,” “engineering practice areas and technologies
that support them,” or a specific business division.
While it is possible to select unrelated information assets for an assessment – or a subset of
assets within a larger scope – the organization that receives the assessment and is making
investments and prioritization decisions based on its findings will be most comfortable when the
information assets are associated with a business entity or a business process. Otherwise, risk
assessment findings may seem scattered and unrelated.
Similarly, while assessing the risk of a set of information assets, it makes good sense to consider
a set of assets that can directly affect each other’s security. For example, a risk assessment that
examines a set of applications should also include the network devices that connect the
applications to other assets and other networks, as well as the processes that are used to
develop and manage those applications. These systems are directly connected to each other and
dependent on each other so their risks are easily associated with one another.
Organizations cannot examine all information assets comprehensively in a single risk
assessment, so their scope should consider the time and resources that are available for the
assessment. Risk assessors should consult security experts to help them determine which assets
to prioritize, and may use inherent risk analysis as described in Chapter 5 to assist in this
prioritization.
An example scoping table (Table 8) demonstrates the level of detail that may be appropriate for
an initial assessment plan and is provided in the workbook CIS_RAM_Workbook
Table 8 - Example Scoping Table
Asset Type Asset Class Business Owner Steward
Information IP and PII COO CIO
Application Applications Customer Experience Prod Mgr, Dev & Dev Ops
Servers Servers Dev Ops DevOps
Network Device Network Devices CIO Network Engineering
Process Dev, Promotion, Maint. Dev Ops Dev, DevOps
Process Vulnerability Mgt. CIO Security Team
Process Acct Setup, Maint. Customer Experience Application Management
Version 1.0 – April 2018 18
Asset Type Asset Class Business Owner Steward
Process Internal Audit Compliance Internal Audit
Process Device/System set-up CIO DevOps
Process Customer Support Customer Experience Application Management
Note that the scoping table includes business owner roles and steward roles. Business owners
are the (typically) non-technical managers who are responsible for the information and processes
that information assets support. Stewards are (typically) technical managers who are responsible
for the functionality and security of the information assets. By identifying information asset
ownership up front, the scoping table can be used to help plan interview sessions for the
remainder of the risk assessment.
Regardless of how the scope of the risk assessment is established, and how detailed the asset
listing is, there are a few helpful practices an organization should keep in mind as they identify
their information assets:
• Think of a set of similarly-situated assets as a single asset class. For example, all
database servers that use the same technology and the same maintenance and
administration methods may be considered one asset class. However, if one set of
database servers is different from others (for example, they hold sensitive information in
a DMZ while others process less-sensitive information in another zone), these may be
considered two assets because their inherent risks will be different, even if they are
managed identically.
• Information assets are not only technologies that store and transmit sensitive information.
Information assets are any information, technology, process, people, or facilities that may
impact the confidentiality, integrity, or availability of information.
• Include in the scope all information assets that are within the same zones (networks,
facilities, etc.) as any other in-scope information asset.
Version 1.0 – April 2018 19
Exercise:
The reader should develop their own scoping table using the “Scope - Tier 1” worksheet that is
provided in the supplementary document CIS_RAM_Workbook.
The reader should consider:
1. A set of information assets your organization is interested in focusing your security
resources on?
a. This set can be defined by processes, technologies, a class of information, or
a location.
2. What are the boundaries between this set of information assets and other information
assets not in this scope?
a. What systems, facilities, and network devices link these boundaries together,
or separate them?
b. Are these “boundary” assets included or excluded from the scope?
3. List information assets or asset classes that are within the scope.
a. List information assets or asset classes to a level of detail that the
organization has the time and resources to analyze. This may require
adjustment during the course of the assessment if the organization realizes it
has more time (or less time) than they originally planned to assess the
information assets.
Version 1.0 – April 2018 20
Scheduling Interview Sessions
Interview sessions will be topical, and should address one topic or closely related topics for each
conversation. Interview sessions can focus on CIS Controls, or information assets and asset
classes.
For example, interview sessions that focus on CIS Controls would bring together the personnel
and management who know how each control is implemented and operates. One session may be
dedicated to CIS Control 1 to understand how devices are inventoried. Another may be
scheduled to discuss CIS Control 2 to understand what safeguards are in place to inventory
software. Or, if the same personnel are knowledgeable about both safeguards, then perhaps one
session could combine both topics.
Similarly, if risk assessors schedule sessions around information assets or asset classes, then it
would be appropriate to include business owners and technical owners of those systems to
understand how associated CIS Controls are applied to each asset or asset class.
An example session for a web application may include product managers, application developers,
application administrators, and business owners. Topics in that session may include CIS Control
14, “Controlled Access Based on the Need to Know,” CIS Control 16, “Account Monitoring and
Control,” and CIS Control 18, “Application Software Security.”
How the organization groups and orders these topics is largely up to them, but risk assessors
should consider these pointers while scheduling interview sessions:
1. Be respectful of people’s time. While it is important to gather comprehensive information
about risks, organizations cannot gather all relevant information in the first one or two risk
assessments.
2. Work with managers to determine the most efficient and useful way to schedule
interviews, whether by CIS Controls or by information assets and asset classes.
3. Expect that some security safeguards will be applied differently to different information
assets and asset classes. For example, CIS Control 5, “Secure Configuration for
Hardware and Software on Mobile Devices, Laptops, Workstations and Servers,” and CIS
Control 16, “Account Monitoring and Control” may be implemented and overseen
differently for servers in different environments, or may be centrally controlled for servers,
but individually controlled for network devices. Plan on evaluating how these and similar
safeguards are applied to different asset classes.
4. Provide an agenda for reach interview to help participants prepare any materials or
information regarding the information assets or controls that may be discussed.
Scheduling Evidence Reviews
Risk assessors use evidence review sessions to examine information assets and; determine
whether they conform to CIS Controls, and evaluate whether they would be effective against
foreseeable threats.
The evidence review sessions should be scheduled following the interviews so that risk
assessors understand the general landscape of the security environment before trying to
understand why certain assets are configured the way they are.
During interviews, the risk assessor will learn about topics that should be more closely
understood through a review of configurations, system testing, or records review. Risk assessors
should note during or soon after the interview which safeguards they will want to examine further,
and inform the participants that they will likely be contacted later in the assessment to participate
on those evidence review sessions. Further, the assessor should ask which personnel,
processes, or information assets would be appropriate to examine to gather the appropriate
evidence. The evidence review sessions can then be scheduled at the end of the interview.
Version 1.0 – April 2018 21
Defining Risk Assessment Criteria
Introduction
Risk assessment criteria are the numerical and plain-language statements that an organization
uses to evaluate their cybersecurity risk. The most familiar form of risk calculations, “Risk =
Likelihood x Impact,” is the basis for risk analysis in the CIS RAM. But it is just the starting point
for risk analysis.
Risk assessment criteria must be meaningful to the organizations that use them, so they must be
tied to the potential benefit and harm that the organization may create. The impact of a
cybersecurity breach may harm the organization itself, it may harm the organization’s ability to
successfully achieve its mission, or it may harm others.
Because cybersecurity failures may harm parties both inside and outside an organization, risk
assessment criteria must be universally meaningful and must address the interests of all
potentially affected parties. Additionally, risk assessment criteria must demonstrate to authorities
that the organization considers the risk of harm to others as much as the risk of harm to
themselves, as stated in Principle 1.
While these requirements may seem complex, the method presented in this section will
sufficiently address them while using a technique that is simple to develop and use.
Risk Assessment Criteria Foundations
The risk analysis provided in the CIS RAM is at its root a question of balance between the
potential of future harm against the certain burden of a safeguard. Regulators and litigators have
long considered this balance as key to acting as a “reasonable person.” The core structure of a
risk statement is provided below to illustrate the core concept of balance.
Figure 3 - Balance Within Core Risk Analysis
Notice a few things right away with the model risk analysis in Figure 3.
• While organizations typically evaluate the observed risk to determine whether they should
address or accept it, this risk statement deliberately compares the observed risk to a
proposed safeguard.
• The criteria that evaluates the risk also evaluates the safeguard.
• The impact of the risk estimates the potential of harm to the organization and the
potential harm against others.
Risk assessors compare risks to their proposed safeguards to determine whether those
safeguards would create a foreseeably lower risk than the current state. To accomplish this, the
assessor evaluates the current state risk (or “observed risk”) and the proposed safeguard using
the same criteria to ensure comparability.
This comparison prevents organizations from implementing safeguards that are overly
burdensome, or that create new, unacceptable risks. For example, an organization that uses
software that is no longer supported by the vendor, but relies on that software for critical business
Version 1.0 – April 2018 22
purposes, should find alternative methods for identifying and controlling potential security risks
until they replace the software. If management recommends quickly changing out to inferior, but
secure software, the organization may suffer a greater impact to their mission than the security
risk they are trying to avoid.
While considering CIS Control 18: Application Software Security, a risk statement can be made to
estimate the foreseeability of an impactful threat. The risk can be stated as it appears in Table 9
(where the risk score ‘6’ is a product of the likelihood ‘2’ and the highest impact score ‘3’):
Table 9 - Example Core Risk Statement
Observed risk Likelihood Impact to Impact to
Us Others
Risk
Score
Hackers may exploit the unsupported,
but critical application.
2 2 3 6
A risk assessor should then recommend and evaluate a safeguard to reduce the unacceptably
high security risk, as illustrated in Table 10. Here, the organization would realize that the
likelihood of a negative impact to their mission is greater than the current state risk. This is an
obvious case of the burden being greater than the risk, and a recommended safeguard being
unacceptable.
Table 10 - Example Unreasonable Proposed Safeguard
Proposed
Safeguard
New Risk Likelihood Impact to
Us
Impact to
Others
Safeguard
Risk
Replace application
with inferior,
secure application.
Application will
operate
inefficiently.
3 3 1 9
When faced with this analysis, the organization must then find another way to address the risk.
This process will be described later in this chapter in the section Risk Treatment
Recommendations.
But what should be apparent is that without a definition of risk assessment criteria the likelihood
and impact scores are not meaningful. What would impacts or likelihoods of ‘1’, ‘2’, or ‘3’ mean,
anyway? The organization will need to create definitions for their likelihood and impact scores so
that they are meaningful to all interested parties, and so that they provide a consistent method for
risk evaluation.
Impact Definitions
Tier 1 organizations do not have a high degree of attention from management in operating
cybersecurity risk. In such organizations, risk assessment criteria can be developed in simple
terms that are business appropriate, but that do not use the business justifications that managers
often need in order to make decisions.
Risk assessment criteria are composed of impact definitions and likelihood definitions. In its
simplest form, an impact definition should consider the organization’s mission (the value the
organization provides others) and its obligations (the harm that it may cause others without
appropriate safeguards). A simple impact model for the example organization described in
Chapter 1 can look like Table 11.
Version 1.0 – April 2018 23
Table 11 – Example Impact Definitions
Impact
Score
Impact to Our Mission
Mission: Provide information to help
remote patients stay healthy.
Impact to Our Obligations
Obligations: Patients must not be harmed
by compromised information.
1 Patients continue to access helpful
information, and outcomes are on track.
No harm would come to patients.
2 Some patients cannot access the
information they need for good outcomes.
Few patients may be harmed after
compromise of information or services.
3 We can no longer provide helpful
information to remote patients.
Many patients may be harmed financially,
reputationally, or physically, up to and
including death.
Note that this example organization, a health technology manufacturer and service provider, has
defined the impact to their service as their “mission” and the impact to others as their “obligation.”
They are defining their mission in terms of their value to their constituency (patients who use their
service) and their obligations to prevent harm to those patients due to an information breach.
Also note that the impact score of ‘1’ (which is shaded grey to separate it from the higher scores)
describes impacts that would be generally understood as acceptable. If a breach led to a situation
where patients continued to access helpful information, and there was no foreseeable harm to
patients, then of course that would be interpreted as an acceptable impact. The organization
should not be satisfied with a breach that had no impact (its incident response procedures should
identify a root cause and address it so the breach does not re-occur), but in terms of risk
planning, such a risk could be considered “acceptable.”
The impact score of ‘2’ would be used to estimate a risk in which harm would come to the mission
of helping remote patients, or if some harm could come to the patients who rely on the
confidentiality, integrity, and availability of information. An impact at a level of ‘2’ would be
considered ‘not acceptable’ by the organization, its customers, regulatory agencies, or litigators.
Background – Impact Definitions
This document provides instructions for defining impacts and impact scores (magnitudes) in
this section with more in-depth instructions and examples in the “Risk Analysis Techniques”
chapter. The reader should understand before going further that organizations in most cases
should not define impacts exclusively using financial values. While cost is a common and
almost necessary consideration while evaluating risks and safeguards, if it is the only criterion,
the organization will communicate to their personnel, as well as to interested parties and
authorities, that cost is their only concern. The purpose that the organization serves and the
harm that may befall others must be part of the evaluation if risk is to be responsibly tied to the
potential of harm, and if the evaluation is to be understandable to regulators and legal
authorities.
Organizations should also consider having more than three impact types in their impact
definitions if they have more than one mission, multiple objectives, and many obligations that
they need to consider in their risk analysis. While this expansion may create an increasingly
wide risk register, it can help organizations feel comfortable all relevant interests were
considered in their risk analysis.
Version 1.0 – April 2018 24
So foreseeable risks (a likelihood of ‘2’) that are estimated with an impact of ‘2’ would likely not be
considered “acceptable,” But an unforeseeable risk (likelihood score of ‘1’) that would create an
impact of ‘2’ would be acceptable since the impact is considered not foreseeable.
The impact score of ‘3’ might be considered ‘catastrophic’ or ‘high’. The mission would fail
completely, and the obligations to patient customers could harm many people, up to and including
death (presumably because health information was inaccurate, or not available when it was
critically needed).
With these impact criteria defined this way, the health information provider could estimate the
impact portion of risk consistently. Some amount of knowledge about how risks would create
those impacts would be necessary while conducting the risk assessment, but well-informed
managers and personnel could provide plausible estimates of risk in a consistent basis using
these impact definitions.
An in-depth explanation of how to develop impact definitions with multiple examples is provided in
the chapter “Risk Analysis Techniques.”
Likelihood Definitions
This risk assessment method describes likelihood in terms of foreseeability. While risk likelihood
is often described in terms of statistical probability, CIS RAM favors foreseeability because it uses
simple terminology that aligns with common business practice, as well as the legal and regulatory
language used to determine reasonableness of safeguards that reduce risks. Recommendations
for aligning this likelihood model to probability methods are provided in the “Risk Analysis
Techniques” chapter. By combining probability with foreseeability, organizations may benefit from
both data-driven analysis and due care analysis.
The likelihood definition for a Tier 1 organization could be simply constructed, similar in structure
and depth to the impact definitions as shown in Table 12.
Table 12 – Example Likelihood Definitions
Likelihood
Score
Foreseeability
1 Not foreseeable. This is not plausible in the environment.
2 Foreseeable. This is plausible, but not expected.
3 Expected. We are certain this will occur at some time.
• “Not Foreseeable” implies that a threat is not plausible in the environment that is being
assessed. Loss of portable media may not be foreseeable during a risk assessment of a
hosted application.
• “Foreseeable” implies something that is plausible, but the organization would be
surprised if it occurred. A founding executive taking copies of sensitive data to
competitors may be considered foreseeable, even if it is not expected.
• “Expected” implies a threat that is not common, but that would eventually happen.
Phishing attacks or other social engineering attacks may be expected in many
environments.
When risk assessors estimate the likelihood of a threat, they will select scores ‘1’, 2’, or ‘3’ using
the foreseeability definition as their guidance. Organizations may add time-based limits to their
foreseeability definitions (i.e. “Foreseeable within planning thresholds,” “Expected within the five-
year plan” or “Not foreseeable in the next fiscal year”). If organizations do introduce time limits to
their likelihood definitions they should prioritize risk treatment investments to meet these
Version 1.0 – April 2018 25
timelines. That may be excessively challenging to many organizations, so they should proceed
with caution.
The simplicity of these definitions will assist Tier 1 organizations to quickly and consistently
estimate whether they expect impactful risks to occur.
The risk assessor will need to use their professional judgment to define impact types, and to
describe levels of impact that the organization must manage to. Because risk assessment criteria
are a declaration by the organization of what they will manage to in terms of harm to themselves
and harm to others, organizations should consult with legal counsel before finalizing these criteria
and making risk decisions based on them.
Defining Risk Acceptance Criteria
Introduction
Because risk assessments are essentially questions of balance, the criteria for accepting risk
should help determine whether balance was achieved. In CIS RAM risk acceptance has two
components:
• Appropriate risk: That the likelihood of an impact must be acceptable to all foreseeably
affected parties
• Reasonable risk: That the risk posed by a safeguard must be less than or equal to the
risk it protects against.
While these components have been demonstrated briefly in Chapter 1, the “appropriate risk” will
be described in more detail in this section. “Reasonable risk” will be described later in the Risk
Treatment Recommendations section further on.
Recall that impact definitions were worded so that the acceptable impact definitions would seem
appropriate to any person who read them. For Tier 1 organizations that use an impact score
range of ‘1’ through ‘3’ the range of acceptable impact scores is simply ‘1’. Definitions for impacts
that would score at least a ‘2’ would therefore represent impacts that an organization, and
presumably its interested parties, would find unacceptable.
Exercise:
The reader should develop their organization’s risk assessment criteria using the “Criteria -
Tier 1” worksheet that is provided in the supplementary document CIS_RAM_Workbook.
The reader should consider:
1. Working with a business management sponsor who can help ensure that the Mission
and Obligations definitions are sensible to the organization.
2. Working with legal counsel to help ensure that impact definitions address the interests
of all potentially affected parties, and to ensure that impact statements appear
equitable to all parties.
3. Referring to guidance for defining and scoring impact types in the “Risk Analysis
Techniques” chapter.
Version 1.0 – April 2018 26
Table 13 - Unacceptable Impacts
Impact
Score
Impact to Our Mission
Mission: Provide information to help
remote patients stay healthy.
Impact to Our Obligations
Obligations: Patients must not be harmed
by compromised information.
1 Patients continue to access helpful information and outcomes are on track. No harm would come to patients.
2 Some patients cannot access the information they need for good outcomes.
Few patients may be harmed after
compromise of information or services.
3 We can no longer provide helpful information to remote patients.
Many patients may be harmed financially,
reputationally, or physically, up to and
including death.
Similarly, likelihood scores for Tier 1 organizations ranged from ‘1’ through ‘3’ where the score of
‘2’ represented the lowest “foreseeability” score.
Table 14 - Unacceptable Likelihood
Likelihood
Score
Foreseeability
1 Not foreseeable. This is not plausible in the environment.
2 Foreseeable. This is plausible, but not expected.
3 Expected. We are certain this will occur at some time.
Tier 1 organizations should determine that they would safeguard against risks that reached a
threshold of unacceptability; for example, risks that could foreseeably (likelihood is ’2’) prevent
patients from getting access to information (impact is ‘2’) or cause a breach that may harm
patients (impact is ‘2’). So if Risk = Impact x Likelihood, then the organization would invest
against risks that are scored ‘4’ or greater. All lower risks can be accepted!
Table 15 - Risk acceptance criteria
Impact
Threshold x
Likelihood
Threshold =
Risk
Threshold
2 x 2 = 4
… therefore …
Acceptable Risk < 4
Consider how a reasonable risk would be described: If a risk cannot foreseeably (likelihood is ‘1’)
prevent the organization from providing helpful information to patients (impact is ‘3’) then that is
acceptable. It sounds acceptable to reasonable people, and 1 x 3 = 3 which is less than 4.
Also see how the calculation works when an acceptable impact of no harm to patients (‘1’) is
expected to occur (‘3’). 1 x 3 = 3, which is again less than ‘4’. This is an acceptable risk. While
risk heat maps are not used in CIS RAM, organizations can now consider that heat maps can
represent actual risk acceptability based on organizational requirements, and a duty of care to
others.
Version 1.0 – April 2018 27
Figure 4 - Example Risk Heat Map
Impact
Li
ke
lih
oo
d
1 2 3
3
2
1
The risk assessor will need to use their professional judgment to identify levels of acceptable risk.
Because risk acceptance criteria are a declaration by the organization of what they will tolerate in
terms of harm to themselves and harm to others, organizations should consult with legal counsel
before finalizing these criteria and making risk decisions based on them.
A Control-Based Risk Assessment Process
Introduction
Tier 1 organizations that use the CIS Controls, but that have not established a strong capability
for managing cybersecurity risk will find that control-based risk assessments are well-suited to
their needs.
This CIS Risk Assessment Method is designed to help organizations responsibly use the CIS
Controls to the degree that they are able, even if the controls cannot be implemented completely.
The risk assessment method helps Tier 1 organizations:
1. Model safeguards based on CIS Controls V7 that addresses their risks, while working
within their constraints.
2. Prioritize the safeguards they should implement, based on their organization’s risks.
Exercise:
The reader should define their organization’s risk acceptance criteria using the “Criteria - Tier
1” worksheet that is provided in the supplementary document CIS_RAM_Workbook.
The reader should consider:
1. Working with a business management sponsor who can help ensure that the risk
acceptance criteria are sensible to the organization.
2. Working with legal counsel to help ensure that the definition for risk acceptance
addresses the interests of all potentially affected parties, and to ensure that impact
statements appear equitable to all parties.
Version 1.0 – April 2018 28
3. Develop a practical plan for implementing CIS Controls V7 over time, and as resources
permit.
4. Document why their method of applying CIS Controls V7 is reasonable, given the
balance between their risk and their resources.
This section will describe a risk register that is available as a template in the supplementary
document CIS_RAM_Workbook.
The Risk Register
Up to this point, the organization has identified the information assets or asset classes that they
will be risk assessing. They have also developed risk assessment criteria and risk acceptance
criteria. Using the risk register template provided in the supplementary document
CIS_RAM_Workbook, the organization will see a list of CIS Controls and sub-controls that will act
as the main index, or driver, for modeling their risks.
A layout map of the risk register for a Tier 1 organization is depicted in Figure 5.
Figure 5 – Risk Register Layout Map
The risk register for Tier 1 organizations is a listing of identified risks and their recommended risk
treatments, also known as “safeguards.” Each row represents one risk and risk treatment
recommendation. The parts of the risk register are:
A. The column headers and guiding text help the reader or risk assessor understand the
information that is contained in the column.
B. The CIS Controls help the risk assessor consider controls that should be in place to
protect information assets.
C. The in-scope information assets or asset classes are identified.
D. The “threat model” includes the following three items:
a. How the organization implements the CIS Control (if they do) to protect the
information asset or asset class.
b. The vulnerability that may exist if the control is not fully implemented.
Version 1.0 – April 2018 29
c. The threat that may compromise the asset because of the vulnerability.
E. The risk evaluation estimates the likelihood that the threat would succeed and the
impacts to the mission and obligations if it did. The resulting risk score is then calculated
as a product of the likelihood and the higher of the two impact scores.
F. Risk treatments are recommended for risks that are evaluated as unacceptably high.
Safeguards that are based on CIS Controls V7 are described, and they are in turn
evaluated for the risk that they may pose to the mission and objectives. A “safeguard risk”
score is calculated which should be lower than the risk acceptance criteria, and the risk
that it is meant to address.
The Process
The risk assessor will analyze each risk by taking the following steps as diagrammed in Figure 6.
Figure 6 - Tier 1 Risk Analysis Diagram
1. Using the risk register template for Tier 1 organizations that is provided in
CIS_RAM_Workbook, read and consider the CIS Control that is stated in one of the risk
register rows.
2. Select information assets or asset classes that are listed in the asset inventory. Record
the selected assets in the “Information Asset” cell in that row.
a. If there are multiple information assets or asset classes to consider for each CIS
Control, either list them all in one cell in the information asset column, or add
multiple rows for the CIS Control so that each information asset is analyzed
separately. The decision should be based on how granular the risk assessor is
prepared to be in their analysis and planning, and how useful the distinction
between assets would be.
3. Gather evidence for how well the CIS Control is applied against the selected information
assets.
a. Evidence may be in the form of interviews, a review of configurations, or a review
of evidence, such as records and logs. This step requires knowledge and
experience in detecting vulnerabilities and understanding security threats.
Methods for gathering evidence are provided in the chapter “Risk Analysis
Techniques.”
4. Describe the safeguard that implements the CIS Controls and how the safeguard is
applied at the organization in the “Current Control” cell of that row.
5. Consider the difference between the CIS Control and the currently used safeguard and
determine whether there is a deficiency in how the control is currently deployed and
operating. If the current control is not implemented as described, how would this be
described as a vulnerability?
Version 1.0 – April 2018 30
a. Consider the objective of the CIS Control. For example, CIS Control 2.3 states
“Utilize software inventory tools throughout the organization to automate the
documentation of all software on business systems.” The sub-control’s objective
is to itemize all operating systems and applications that are in use so the
organization knows what software it should control. If the current control does not
meet the objective, then state the gap as a vulnerability in the vulnerability cell,
such as: “We do not have a current, automatically updated list of current
operating systems or applications that operate on our systems.”
6. Now consider the threat that could occur because of the vulnerability.
a. The above vulnerability could be paired with the threat: “Malware or hackers
could take advantage of software vulnerabilities that we did not know about or
protect against.”
7. Next, estimate the likelihood that the threat would succeed, and the impact it may create.
a. Likelihood estimation can be challenging at first, but the risk assessment criteria
was developed to provide some guidance in that estimation process. Further
guidance is provided in the “Risk Analysis Techniques” chapter later in this
document.
b. Impact scores should provide estimates of the impact that such a threat would
create. Consider the likelihood and impact scores as a pair. In other words,
“What is the likelihood that this impact would result?” Examples below will
provide further guidance.
8. The risk score will be automatically computed by multiplying the likelihood score by the
higher of the two impact scores.
Tier 1 Risk Assessment Example 1 – Knowing Whether a Current Safeguard is Enough
Let’s examine how this process works using risk analyses for our example Tier 1 organization.
While conducting their risk assessment, the organization starts with CIS Control 1.1 which
instructs them to deploy an automated asset inventory discovery tool. They know they don’t have
such a tool, and are concerned about the time and potential cost of researching and obtaining
one. Additionally, they don’t know whether this should be their top priority, given other items that
are on their mind, such as hardening field devices and vulnerability management. While CIS
Controls V7 provides clear guidance on the criticality of this important control, there may be other
areas of concern that should be addressed earlier, based on the organization’s environment.
Using the risk register template for Tier 1 organizations, the example organization first reviews
the control that they are analyzing.
Table 16 - CIS Control Example CIS Control 1.1
CIS
Control
Description
1.1 Utilize an active discovery tool to identify devices connected to the
organization's network and update the hardware asset inventory.
The risk assessor considers the information asset that the control would protect. In this case, they
would apply an asset inventory discovery tool to all network attachable devices. They could focus
purely on a class of assets, such as portable workstations, “headless” or “internet-of-things”
devices, smart phones, laptops, or devices in a specific network such as the corporate VLAN that
is used to connect wireless devices. But to make things simple for their first assessment, they
decide that the asset class they will assess will be “all devices.”
Version 1.0 – April 2018 31
Table 17 - Tier 1 Information Asset Example
Next, they must think through and record what their current control is, what resulting
vulnerabilities may exist, and what threats would be of concern to them. They realize that they
don’t have an automated tool that provides a regular inventory, but they do have a vulnerability
scanning tool that they occasionally use. That may be useful here.
But the control clearly has an objective, which is the automatic detection of all systems that
appear on the network. If the organization occasionally uses a vulnerability scanner, then a
vulnerability related to this control would be that new systems could join the network and not be
detected until the next vulnerability scan occurred. The resulting threat would be obvious:
Compromised systems may operate on the network between scans.
So the next three columns would look like this:
Table 18 - Threat Model Example
Control Vulnerability Threat
Vulnerability scans
occur occasionally and
may not identify all
Systems that have joined the
network between sporadic scans
will not be detected.
Hackers or malware may
attack and control
systems that have not
systems that have
been on the network
been detected,
controlled, and
between scans. monitored.
Now that the threat has been modeled, the risk assessor should estimate the likelihood and
impact of the risk. The organization must consider the likelihood that an impact would occur if the
threat were successful. Risk assessors should think of the likelihood and impact as a dependent
pairing. In this example, the organization may believe that multiple systems will join and leave
their network without detection. That is a highly likely scenario for them. But they may also
believe that the risk is foreseeable but unexpected for an undetected system to cause an impact if
the visitors they receive are employees of well-secured partner organizations.
In terms of the impact that people may suffer, the risk assessor considers how harm could be
done in this foreseeable but unlikely scenario. If an employee of a secured partner were to bring
in a laptop that was infected with malware that could spread to other systems on the network,
what harm could that do? If these partner employees join a network that contains a mix of
systems, some with highly sensitive information, then is it foreseeable but not expected that the
scenario could expose records that could cause harm to few patients, or many patients? Would
the mission be reduced to the point that some patients could not get information that could
improve health outcomes?
The organization determines that it is foreseeable but not expected that records for many patients
may be exposed in the risk scenario they modeled. They do not believe that the risk scenario
would affect their mission. So now they will add this information to their risk register to see how
the risk evaluates.
Recall the definitions for the impact and likelihood scores that the organization created. Impact
scores were defined earlier as shown in Table 19.
All devices.
Information Asset
Version 1.0 – April 2018 32
Table 19 – Example Impact Definitions
Impact
Score
Impact to Our Mission
Mission: Provide information to help
remote patients stay healthy.
Impact to Our Obligations
Obligations: Patients must not be harmed
by compromised information.
1 Patients continue to access helpful
information, and outcomes are on track.
No harm would come to patients.
2 Some patients cannot access the
information they need for good outcomes.
Few patients may be harmed after
compromise of information or services.
3 We can no longer provide helpful
information to remote patients.
Many patients may be harmed financially,
reputationally, or physically, up to and
including death.
Impact score ‘1’ is shaded to indicate that it is considered an acceptable impact to all parties. Also
recall that likelihood was defined with this next table.
Table 20 – Example Likelihood Definitions
Likelihood
Score
Foreseeability
1 Not foreseeable. This is not plausible in the environment.
2 Foreseeable. This is plausible, but not expected.
3 Expected. We are certain this will occur.
A risk that is foreseeable but not expected to occur (likelihood = 2) in a way that creates no
impact to the mission (mission impact = 1), but that would create harm to many patients
(obligations impact = 3) would appear as below.
Table 21 - Example Risk Estimation
Threat
Likelihood
Mission
Impact
Obligations
Impact
Risk Score
2 1 3 6
The risk score is the product of the likelihood score and the higher of the two impact scores,
which in this case is ‘2 x 3 = 6’.
Also recall that the risk acceptance criteria for the Tier 1 organization looked like this:
Table 22 - Risk acceptance criteria
Impact
Threshold x
Likelihood
Threshold =
Risk
Threshold
2 x 2 = 4
… therefore …
Acceptable Risk < 4
Version 1.0 – April 2018 33
Because acceptable risk is anything below ‘4’, and the observed risk associated with CIS Control
1.1 is ‘6’, the risk is unacceptably high.
We can bring these elements together to illustrate the point more clearly. (While the risk register
in the workbook displays this example in horizontal format, this risk is displayed in vertical format
for readability in this document.)
Table 23 - Example Risk for CIS Control 1.1
Risk Analysis Value
CIS Control 1.1
Description Utilize an active discovery tool to identify devices connected to the
organization's network and update the hardware asset inventory.
Information Asset All devices.
Control Vulnerability scans occur occasionally and may not identify all
systems that have been on the network between scans.
Vulnerability Systems that have joined the network between sporadic scans will
not be detected.
Threat Hackers or malware may attack and control systems that have not
been detected, controlled, and monitored.
Threat Likelihood 2
Mission Impact 1
Obligations Impact 3
Risk Score 6
Risk Acceptability Not Acceptable
So the organization realizes, based on its own criteria for scoring and accepting risk, that their
occasional use of vulnerability scans is not sufficient for addressing the risk of infected systems
joining the network. This risk is not acceptable because it is not “appropriate” (its risk is higher
than the acceptable score of “less than 4.”)
But they are not sure what to do about this risk, because they don’t know whether they will be
able to afford the time or budget to implement a more robust solution for CIS Control 1.1 (such as
a network access control appliance) and they have many more controls and risks to consider.
The method for identifying reasonable ways to implement safeguards will be addressed in the
Risk Treatment Recommendations section later in this chapter.
First, however, we will examine a few more of the CIS Controls and see how the Tier 1
organization analyzes them.
Tier 1 Risk Assessment Example 2 – Risk Acceptability in Different Contexts
Further along in the risk assessment, the Tier 1 organization considers CIS Control 3.4 that
states, “Deploy automated software update tools in order to ensure that the operating systems
are running the most recent security updates provided by the software vendor.” This is a
challenging control for many organizations. While the objective of automatic patching of
vulnerable systems is important, many systems and applications will fail when some security
patches interfere with their functionality.
Version 1.0 – April 2018 34
For example, applications that rely on code libraries that are replaced with more secure versions
during patching may fail. As a result, many organizations test patches before releasing them to
active systems and applications.
The Tier 1 organization believes that they are doing well in this regard. They have two
environments; a production environment in which their applications operate on the Internet, and a
corporate environment in which they run their business and application development
environment. When they run their sporadic vulnerability scans in their production environment,
they respond immediately to identified vulnerabilities that can be patched. In fact, they run their
vulnerability scans when they receive word of high-risk vulnerabilities from a threat information
service they subscribe to (for this example, a fictional service provider named “Threat Info
Service”). Their application stack is simple, and based completely on standard implementations of
the vendors’ application framework. So when the vendor sends patches, they can be applied
rapidly – even if manually – with little risk to the applications.
They believe their risk is low here in terms of security. But they are concerned about their patient
customers not being able to use their systems during patching downtimes. So they assess the
risk in this way.
Table 24 - Example Risk Analysis for CIS Control 3.4
Risk Analysis Value
CIS Control 3.4
Description Deploy automated software update tools in order to ensure that the
operating systems are running the most recent security updates
provided by the software vendor.
Information Asset All devices in Production Environment.
Control Vulnerability scans occur when Threat Info Service announces a
moderate-to-high vulnerability that needs patching. Team reliably
patches systems within 24 hours of announcement.
Vulnerability A 24-hour window of vulnerability remains with the current process.
Threat Hackers or malware may attack and control systems that have not
been patched within the 24-hour period after the vulnerability was
announced.
Threat Likelihood 1
Mission Impact 2
Obligations Impact 1
Risk Score 2
Risk Acceptability Acceptable
The Tier 1 organization has determined that its risk associated with CIS Control 3.4, at least in its
production environment, is acceptable because the risk is “appropriate” (it’s score is less than ‘4’).
This allows the organization to keep their current processes in place, and to focus on higher risks
first.
But they still have an internal network to consider. In this network they have an important
enterprise management application that relies on an older operating system, and that does not
work with more advanced patches to the operating system. The application vendor says they will
release a more secure version in the next year, and the Tier 1 organization knows that converting
Version 1.0 – April 2018 35
to the new version will be very burdensome. In the meantime, they have operating system
vulnerabilities in the enterprise management application environment that need to be addressed.
But they are afraid to apply those patches because they may break the application.
They evaluate the risk in their risk register with the values listed below.
Table 25 - Example Risk for CIS Control 3.4
Risk Analysis Value
CIS Control 3.4
Description Deploy automated software update tools in order to ensure that the
operating systems are running the most recent security updates
provided by the software vendor.
Information Asset Enterprise management application in the internal corporate
network.
Control Vulnerability scans occur when Threat Info Service announces a
moderate-to-high vulnerability that needs patching. Team patches
most systems within 24 hours of announcement.
Vulnerability Enterprise management application systems are unpatched for
more than one year.
Threat Hackers or malware may attack and control the enterprise
management application environment.
Threat Likelihood 2
Mission Impact 2
Obligations Impact 3
Risk Score 6
Risk Acceptability Unacceptable
They clearly have an unacceptable risk with how this control protects their corporate network (the
risk score of ‘6’ is inappropriately high). The enterprise management application is creating a risk
that should be addressed in some way. The organization will address this risk in the following
section, Risk Treatment Recommendations.
Tier 1 Risk Assessment Example 3 – Prioritized Risks
As the Tier 1 organization later considers its risk related to CIS Control 14.9, they will address a
common concern about log management; what events that are captured in logs and repositories
should the organization focus on? CIS Control 14.9 states, “Enforce detailed audit logging for
access to sensitive data or changes to sensitive data.”
The Tier 1 organization suspects that they will need to invest in their log management and SIEM
technologies soon, but they are also aware that choosing which log messages to capture,
prioritize, and alert on will require careful thought and lots of experience. Their main concern
regarding log management is detecting abuse of systems and data access. Morale has been low,
and they are in a competitive business that may cause internal employees to steal sensitive data
from their enterprise management application and provide it to a competitor.
Version 1.0 – April 2018 36
They are sure that they are not doing well enough with their access log review now, but they will
analyze this risk to evaluate and prioritize this risk. They will also use their risk treatment analysis
further on to determine what log management configurations are appropriate for their enterprise
management application.
Table 26 - Example Risk for CIS Control 14.9
Risk Analysis Value
CIS Control 14.9
Description Enforce detailed audit logging for access to sensitive data or
changes to sensitive data.
Information Asset Enterprise Management Application
Control Access logs are captured and stored locally, and not reviewed.
Vulnerability The organization is unaware of suspicious or inappropriate use.
Threat Rogue employees or hackers may use escalated privileges and
may access and abuse nonpublic information in the application.
Threat Likelihood 3
Mission Impact 2
Obligations Impact 3
Risk Score 9
Risk Acceptability Unacceptable
After having entered a few risks in the risk register, this analysis does not surprise them. They
were sure that by reviewing this control they would highlight a problem. And now they see that
this risk is both inappropriately high, and should be prioritized over the other risks that they
analyzed previously. By the time the risk assessment is complete, this risk will rank among the
first items that should be addressed (it has the maximum risk score of ‘9’). They will select and
design their risk treatment safeguard in the following step, Risk Treatment Recommendations.
Version 1.0 – April 2018 37
Exercise:
The reader should refer to the template Risk Register – Tier 1 that is provided in the
supplementary document CIS_RAM_Workbook. They may use the risk register template to
enter a set of risks that are associated with the CIS Controls and information assets that are in
scope of their assessment.
While doing this exercise, the reader should consider:
1. When one CIS control can be appropriately stated for the whole scope, an asset
class, or a stand-alone information asset.
2. Stating at least one risk per CIS control. One CIS Control may appear multiple times if
asset classes and information assets use the control differently.
3. Whether a control or information asset requires examination to understand its actual
configuration and effectiveness.
4. Whether the organization can tolerate the amount of effort and time that the risk
assessment requires.
a. Organizations should not try to “boil the ocean.” A risk assessment can only
be completed using available resources.
b. The organization should use high-level analysis (review of policies and
interviews) if they do not have extensive time and resources.
c. Information assets should be tested and examined in more detail as time
allows.
d. The organization should plan recurring risk assessments to identify more risks
over time.
5. Collaborating with information security subject matter experts to help model threats
that are foreseeable in the environment, and to help evaluate the effectiveness of
current safeguards.
The risk assessor will need to use their professional judgment to select the controls and
information assets and to model threats that should be analyzed in the risk assessment.
Information security experts may need to be included in the process to ensure that the risk
analysis is conducted appropriately.
Tier 1 Risk Assessment Summary
After having analyzed a set of risks, the Tier 1 organization begins to understand a few concepts
about risk analysis:
1. The CIS Controls can help Tier 1 organizations model threats by comparing their current
practices to known-good practices. The CIS Controls each identify a way to safeguard
systems, so they conversely show where and how something might go wrong.
2. Once impacts are defined in terms of acceptable, unacceptable, and high consequences,
they support a very rapid, consistent, and simple method for evaluating risks.
3. Similarly, when likelihoods are defined using easy-to-communicate terms, such as
foreseeability, risks can be easy to estimate while also being credible.
4. If a risk can be credibly assessed as not foreseeably creating an impact, or foreseeably
creating an acceptable impact, then an organization can reasonably accept that risk.
5. If a risk poses a higher risk score than other risks, it will likely be prioritized over other
risks during risk treatment design and planning.
Version 1.0 – April 2018 38
Risk Treatment Recommendations
Introduction
Organizations often think of security safeguards as obstacles to business and productivity.
Safeguards often cause personnel to take extra steps to get access to systems or information, or
to get approval for normal business activities. Safeguards require investments in time and money,
which compete with other priorities. And if they become too disruptive to the mission an
organization’s mission, security safeguards can become disliked and avoided.
In fact, disruptive safeguards often cause personnel to work around them just to get their jobs
done, which creates more risk.
But risk treatment recommendations can and should result in safeguards that are demonstrably
reasonable. And while obtaining a clear definition for “reasonable safeguards” has been a
challenge in the legal, regulatory, and information security communities, the CIS RAM provides a
practical solution. Risk assessors evaluate risk treatment recommendations to determine whether
a security safeguard is reasonable by; comparing the safeguard to the risk it is meant to reduce,
and by comparing the safeguard to the risk acceptance criteria.
Risk treatment recommendations are simple to evaluate once the risk assessment criteria and
initial risk analysis have been established. The process occurs over the following steps:
1. While examining an unacceptably high risk, review the CIS Control that corresponds with
the risk and recommend a feasible way for the organization to implement or improve that
control.
2. If that control is not feasible in the near-term, recommend other CIS Controls related to
the risk that can be used to reduce it.
3. Evaluate the risk of the recommended safeguard to understand the burden it would pose
to the organization. Then compare that safeguard risk to the risk acceptance criteria to
determine whether it is appropriate.
4. Also compare the evaluated risk of the recommended safeguard to the observed risk to
determine whether the safeguard is reasonable (safeguards with lower risk scores than
the observed risk are reasonable.)
5. Sort the risks by their risk score to prioritize the risks and risk treatments that the
organization will invest in.
This section demonstrates these steps in detail by describing the process, then by modeling risk
treatments for the unacceptably high risks that were evaluated in previous sections.
The reader should review the definitions of ‘reasonable’ and ‘appropriate’ that are provided in the
glossary. These terms will be used regularly in this section and have distinct meanings.
1. Appropriate: A condition in which risks to information assets will not foreseeably create
harm that is greater than the organization or its constituents can tolerate.
2. Reasonable: A condition in which safeguards will not create a burden to the organization
that is greater than the risk it is meant to protect against.
Risk Treatment Objectives
The objective of well-formed risk treatment recommendations is to create a prioritized list of
information security safeguards that would provide appropriate protections while not posing too
great a burden on the organization’s purpose.
The risk treatment recommendation exercises that are demonstrated in this section examine the
unacceptable risks that were illustrated earlier in the document and will select CIS Controls that
Version 1.0 – April 2018 39
would reduce those risks to a degree that is both reasonable (not overly burdensome) and
appropriate (not unacceptably harmful).
Recommending Risk Treatment Safeguards from CIS Controls V7
As we examine unacceptably high risks, we will recommend safeguards that are based on CIS
Controls V7. But some of the safeguards that an organization is prepared to implement and
operate may not be implemented exactly as described in CIS Controls V7. This process takes
into account how to select controls that address risks, and how to determine whether they are
designed in a way that makes sense in context of both the risk, and the potential burden to the
organization.
Recall the relationship between analyzed risks and their recommended risk treatments in Figure
7.
Figure 7 - Balance Within Core Risk Analysis
A risk and its proposed safeguard are both evaluated using the same criteria. If a proposed
safeguard has a higher risk (its “safeguard risk”) than the risk acceptance criteria, then it’s not
appropriate. If the safeguard has a higher score than the observed risk, then it’s not reasonable.
The exercises in this section will focus on matching completed risk analyses (in blue) with newly
recommended safeguards (in green).
Risk Treatment Example 1 – CIS Control 1.1
The first exercise that demonstrated risk analysis in Table 23 showed the Tier 1 organization that
its method for identifying and inventorying technical assets in its network was not sufficient. The
risk it posed to the organization was too high.
To recommend an appropriate safeguard the organization reviews the description for CIS Control
1.1 and they consider its objective. CIS Control 1.1 intends that organizations should actively and
passively inventory all IP systems that join an organization’s networks so they know what
technical assets to include in their risk management programs, safeguards, controls, and
processes.
They realize that the best solution for them will be to purchase and install an appliance that
actively identifies and catalogs IP hosts that join the network, allowing the IT staff to add detailed
information about each asset over time. At this time they don’t need to decide what the full feature
set should be (i.e. will it operate as a network access control device to enforce safe configurations
of systems, will it actively scan for software licenses, will it be integrated into a change
management database or service desk application, etc.).
Next they will evaluate what they believe the safeguard risks to be, and will determine whether
the safeguard risk is appropriate or not. This step is demonstrated in Table 27.
Note: The risk assessor will record how they will address their risk by stating either “Accept,”
“Reduce,” “Transfer,” or “Avoid.” Accepting and reducing risks will be intuitive to the reader. An
Version 1.0 – April 2018 40
organization may transfer a risk by contracting a third party that may handle the risk better, or by
acquiring an insurance policy against the risk. The organization may also avoid the risk by no
longer engaging in the processes, or handling the information assets that cause the risk.
Table 27 - Example Risk for CIS Control 1.1
Risk Analysis Value
CIS Control 1.1
Description Utilize an active discovery tool to identify devices
connected to the organization's network. This tool shall
automatically update the organization's hardware device
inventory when devices are discovered.
Information Asset All devices.
Control Vulnerability scans occur occasionally and may not identify
all systems that have been on the network between scans.
Vulnerability Systems that have joined the network between sporadic
scans will not be detected.
Threat Hackers or malware may attack and control systems that
have not been detected, controlled, and monitored.
Threat Likelihood 2
Mission Impact 1
Obligations Impact 3
Risk Score 6
Risk Acceptability Not Acceptable
Risk Treatment Option Reduce
Recommended Safeguard Purchase and implement an appliance that actively and
passively identifies IP hosts in all networks. Implement a
process for routinely adding information about assets to
the appliance. Appliance should optionally alert on new
hosts that join the network.
Safeguard Risk A moderate cost would have minimal impact on the
budget. Installation of the tool is likely not disruptive.
Moderate cost in personnel time to add information about
IP assets to the appliance database.
After a baseline is established, we will be able to
distinguish between organization-owned systems, and
systems that we do not control. Alerting can be set after
baseline is complete.
Safeguard Threat Likelihood 1
Safeguard Mission Impact 1
Safeguard Obligations
Impact
3
Safeguard Risk Score 3
Risk Acceptability Acceptable
Version 1.0 – April 2018 41
Review the risk assessment criteria and risk acceptance criteria for the Tier 1 organization and
observe that the organization believes that with the recommended safeguard in place the risk
would no longer be foreseeable.
The Tier 1 organization has determined that their recommended safeguard – an appliance that
can identify and inventory IP hosts and alert on new hosts – is an acceptable and reasonable
safeguard. The estimated safeguard risk is less than their acceptable level of risk, and is lower
than the originally evaluated risk that it is addressing.
Risk Treatment Example 2 – CIS Control 3.4
The Tier 1 organization’s second risk analysis involved their method for identifying and
addressing system patches in their production environment and their corporate environment.
They were comfortable with their patch management process in their production environment.
Even though they were not using the control described in CIS Control 3.4 as it was written, they
estimated that the likelihood and impact of the risk that their current methods exposed them to
met an acceptable level of risk.
Their risks in the corporate environment were higher, though. Their enterprise management
application had vulnerabilities that the manufacturer could not provide patches for, but expected
to address the known vulnerabilities in a major release soon. The organization believed the
release upgrade would be significantly disruptive in the short term, and was hoping to find an
alternative safeguard that would be reasonable and appropriate. So the organization will model
recommended risk treatments in Table 28 to identify such a safeguard.
Knowing that they could not implement CIS Control 3.4 as written, they consider the objective of
the control instead to see if there are alternative means of meeting the objective. They determine
that CIS Control 3.3 intends that patches are applied as quickly as is possible, which is not
Background – How Realistic Are Safeguard Risk Estimates?
Critical readers will question how the organization and their risk assessor will know whether
their safeguard risk estimations are realistic. After all, how can they know prospectively what
their risk would be in such a situation?
There are two important items to keep in mind while gaining comfort with this practice;
understanding the legal and regulatory expectations for risk management, and information
security standards for evaluating safeguards after they’ve been implemented.
Law and Regulation: Laws and regulations generally expect risk analysis to evaluate
safeguards that are required for achieving compliance, and expect that the risk analysis is
performed by appropriately skilled and informed people. These analyses do not guarantee
security that is sufficient against any threat, but they do provide a plan toward improved
security and compliance that is prioritized by the likelihood of harm, and that has no intolerable
harm as its goal.
Information Security Risk Management Standards: Information security risk assessment
standards that the CIS RAM is based on operate within fuller risk management programs and
cycles. ISO 27005 operates within the ISO 27000 family of standards, and NIST 800-30 works
within the NIST Special Publications. Each of these families of standards requires continuous
analysis of security safeguards, including analysis of controls after they’ve been implemented
to determine whether they are effective at addressing their security objectives. Recommended
safeguards should therefore be risk assessed again after implementation to be sure that they
achieve their intended objectives.
Version 1.0 – April 2018 42
feasible in this case. Because CIS Control 3.3 is not feasible, they turn to other CIS Controls to
see what alternatives are available to them.
The CIS® provides a document titled the CIS Community Attack Model16 that can be helpful to the
organization for finding alternative controls. The Community Attack Model (provided in the
CIS_RAM_Workbook in a tab titled “Attack Path Models,” and at the CIS website) associates the
CIS Controls with the way they reduce risks in each stage of an incident based on the functions
found in the NIST Cybersecurity Framework.17 This can be very helpful for identifying related
controls.
Figure 8 - Partial Community Attack Model
Risk assessors may reference the Community Attack Model to find controls that can be
complementary and alternative to the recommended safeguards they are assessing. If an
organization struggles to implement a sub-control, they could look for controls that play a similar
role in the Community Attack Model to find alternative controls that might help them meet the
same security objective. For example, if an organization cannot easily use audit logs to detect
delivery of a kind of threat, they may look to another control in the cell that intersects with the
16 The Community Attack Model may be accessed here: https://www.cisecurity.org/white-
papers/cis-community-attack-model/
17 Framework for Improving Critical Infrastructure Cybersecurity, Version 1.0, National Institute of
Standards and Technology. February 12, 2014
Version 1.0 – April 2018 43
detect row and the delivery column to find similar controls – and to eventually see network
intrusion detection controls, which may be more useful in their environment.
Given the intent of CIS Control 3 (of which CIS Control 3.4 is a member) to conduct continuous
vulnerability assessments, the risk assessor reviews the Community Attack Model and finds
“continuous vulnerability assessment” in multiple locations. It appears to be useful for Protecting
against Initial Recon, Protecting against Delivery, and protecting against Misuse / Escalate
Privilege (as well as other uses that are displayed in the remainder of the model not visible in
Figure 8).
The threat they are trying to address could be mitigated by protecting the system at delivery, and
to prevent attackers and malware from knowing what vulnerabilities are present. So the risk
assessor considers the possibility of network intrusion prevention systems (NIPS) and refers to
CIS Control 12 for “Boundary Defense” to see how that is described. While reviewing CIS Control
12’s sub-controls, they come across CIS Control 12.7 and see a description for an intrusion
prevention system (IPS) that might be appropriate for their risk. An IPS could detect and prevent
actions that match exploits to known vulnerabilities. Other options, such as putting the enterprise
planning application and its users in a separate VLAN could reduce the likelihood of an attack as
well, but there would be many systems in that VLAN, so the likelihood reduction might be small.
They recommend and evaluate a safeguard based on CIS Control 12.7.
Table 28 - Example Risk for CIS Control 3.4
Risk Analysis Value
CIS Control 3.4
Description Deploy automated software update tools in order to ensure
that the operating systems are running the most recent
security updates provided by the software vendor.
Information Asset Enterprise management application in the internal
corporate network.
Control Vulnerability scans occur when Threat Info Service
announces a moderate-to-high vulnerability that needs
patching. Team patches most systems within 24 hours of
announcement.
Vulnerability Enterprise management application systems are
unpatched for more than one year.
Threat Hackers or malware may attack and control enterprise
management application environment.
Threat Likelihood 2
Mission Impact 2
Obligations Impact 3
Risk Score 6
Risk Acceptability Unacceptable
Risk Treatment Option Reduce
Recommended Safeguard (CIS Control 12.7) Purchase and implement an IPS
solution to detect, alert on, and prevent attacks on the
Version 1.0 – April 2018 44
Risk Analysis Value
enterprise management application, and other vulnerable
systems in the environment.
Safeguard Risk A significant cost would have significant impact on the
budget. Installation of the tool in detection mode is likely
not disruptive. Installation of the tool in prevention mode is
likely disruptive.
Moderate cost in personnel time to implement and
configure the IPS system.
Safeguard Threat Likelihood 3
Safeguard Mission Impact 2
Safeguard Obligations
Impact
1
Safeguard Risk Score 6
Risk Acceptability Unacceptable
Using a safeguard based on CIS Control 12.7 in this planned deployment still evaluates as
unacceptable. The risk assessor is certain that the IPS in terms of budget and potential disruption
of service will prevent the organization from properly servicing some of their patient user
population (Likelihood = ‘3’; Mission Impact = ‘2’; Safeguard Risk Score = ‘6’). For a Tier 1
organization especially, implementing a tool that may create disruptions to business would be
intolerable, and would likely lead to increased frustration by non-technical management with
information security.
So the risk assessor considers deploying an open-source IPS in detection and alert mode
(Intrusion Detection System, or IDS), rather than a commercial IPS in prevention mode. This
would allow the team to be aware of suspicious activities and to respond without creating a failure
of business functions. After becoming familiar and comfortable with the IPS and seeing what
actions it alerts on, the technology team may be able to selectively block access to high-risk
systems, such as the enterprise management system.
They find a corresponding CIS Control after reviewing the sub-controls under CIS Control 12. The
risk assessor reads CIS Control 12.6 that states, “Deploy network-based Intrusion Detection
Systems (IDS) sensors to look for unusual attack mechanisms and detect compromise of these
systems at each of the organization's network boundaries.” This control can be the initial
safeguard, allowing the organization to improve the safeguard to an IPS (CIS Control 12.7) when
the organization is ready to block traffic that they understand better.
Table 29 models a variation to this recommended safeguard.
Table 29 - Example Risk Treatment Recommendation CIS Control 12.6 to reduce CIS Control 3.4 risk.
Risk Analysis Value
Risk Treatment Option Reduce
Recommended Safeguard (CIS Control 12.7) Acquire and implement an open-source
IPS solution to detect, and alert on attacks on the
enterprise management application, and other vulnerable
Version 1.0 – April 2018 45
Risk Analysis Value
systems in the environment. After gaining confidence in the
types of detected actions and alerts, deploy IPS capability
to protect high-risk systems.
Safeguard Risk Moderate cost in personnel time to implement and
configure the IPS system.
Safeguard Threat Likelihood 3
Safeguard Mission Impact 1
Safeguard Obligations
Impact
1
Safeguard Risk Score 3
Risk Acceptability Acceptable
The assessor is certain that the impact to the mission and obligations will not be affected using
the IPS as an IDS (in detect mode versus prevention mode). At this point, the risk assessor is
confident that they have a plan for implementing a safeguard that aligns with CIS Control 12.6
that would reduce the risk that was evaluated by their review of CIS Control 3.4.
Risk Treatment Example 3 – CIS Control 14.9
Finally, the Tier 1 organization’s risk analysis involving CIS Control 14.9 showed an unacceptable
risk for how they logged events on the enterprise management application. Given their concern
that disgruntled employees are expected to steal and abuse data in the environment, they realize
they will need to track access to the application, and be alerted on specific actions, such as large
data downloads.
The organization knows that log management systems and SIEMs can be readily implemented as
services and management would be friendlier to detecting abuses of access than to invest in the
more esoteric aspects of intrusion prevention. So they opt to recommend a commercial SIEM-as-
a-Service solution to address this risk.
Table 30 - Example Risk Treatment Recommendation for CIS Control 14.9
Risk Analysis Value
CIS Control 14.9
Description Enforce detailed audit logging for access to sensitive data
or changes to sensitive data.
Information Asset Enterprise Management Application
Control Access logs are captured and stored locally, and not
reviewed.
Vulnerability The organization is unaware of suspicious or inappropriate
use.
Threat Rogue employees or hackers using escalated privileges
and may access and abuse nonpublic information in the
application.
Version 1.0 – April 2018 46
Risk Analysis Value
Threat Likelihood 3
Mission Impact 2
Obligations Impact 3
Risk Score 9
Risk Acceptability Unacceptable
Risk Treatment Option Reduce
Recommended Safeguard Implement a SIEM-as-a-Service. To prevent being
overwhelmed by log messages and alerts, focus SIEM first
on high-risk systems, such as the enterprise management
application. Alert on any data manipulation and downloads
conducted by administrator accounts.
Safeguard Risk Initial tuning may be challenging, but will not interfere with
our mission or obligations.
Safeguard Threat Likelihood 2
Safeguard Mission Impact 1
Safeguard Obligations
Impact
1
Safeguard Risk Score 2
Risk Acceptability Acceptable
The organization is now comfortable that their risk treatment recommendations are reasonable
and appropriate, even though the plans do not include a complete implementation of all CIS
Controls to all in-scope assets.
Moreover, the organization knows that they have a basis to explain and defend their plan to
interested parties and authorities, and to defend the basis by which they accept certain risks.
The risk assessor will need to use their professional judgment to design and recommend
information security safeguards, and to evaluate prospectively the risk that they may pose.
Exercise:
The reader should use the template Risk Register – Tier 1 that is provided in the
supplementary document CIS_RAM_Workbook to enter risk treatment recommendations for
each risk that evaluated as unacceptably high.
The reader should consider:
1. Whether an existing safeguard can be improved, and how that would be done.
2. Whether a safeguard based on a different CIS Control would provide reasonable and
appropriate risk.
3. Collaborating with information security subject matter experts to help model the
potential effectiveness of recommended safeguards.
Version 1.0 – April 2018 47
Information security experts may need to be included in the process to ensure that the risk
analysis is conducted appropriately.
Risk Treatment Recommendations Summary
Risk treatment recommendations are a critical part of risk assessments to ensure that the
organization has developed a plan for addressing risks without creating other risks to the
organization or its constituents. Some of the benefits that have been demonstrated about this
process are:
1. Organizations can demonstrate to collaborating business managers how recommended
security safeguards can be implemented without creating too much of a burden on the
business mission.
2. Organizations can demonstrate to regulators and other legal authorities that safeguards
are reasonable because the risk of the safeguard (the “burden” to the organization) is not
greater than the risk that it is meant to reduce.
3. Organizations can demonstrate that recommended safeguards would be appropriate by
showing that they would not foreseeably create an impact that would be intolerable to the
organization or its constituents.
The process for evaluating risks and for recommending appropriate risk treatments has been
demonstrated at a general level. However, some questions likely remain for the reader about
evaluating safeguards, estimating likelihood, and the suitability of probability models in risk
analysis. These more detailed topics will be discussed in the forthcoming chapter “Risk Analysis
Techniques.”
Version 1.0 – April 2018 48
Chapter 3: Asset-Based Risk Assessment
Instructions for Tier 2 Organizations
Tier 2 risk assessment instructions are well-suited to organizations that fit the profile of Tier 2
organizations as described by the NIST Cybersecurity Framework. These organizations can be
identified as having the following characteristics:
• NIST Tier: Tier 2 organizations. Tier 2 materials are best suited for organizations that
have at least some collaboration with non-technical business management to define risk
criteria.
• Expertise: The organization has resources and capabilities to analyze common security
threats, and to plan risk-appropriate safeguards. However, they do not have on-hand
skills to model how threats would operate within their organization.
• Time: The organization is able to invest sufficient time to analyze risks at the level of
specific systems, devices, and applications, and sub-components within those assets.
This chapter is comprised of sections that each address a specific activity within a risk
assessment. Readers should engage this chapter by first reading the text in each section, and
then conducting the exercises that are recommended for each section. The material presented in
the CIS RAM is substantially different from many other risk assessment standards and models,
so the reader should first understand the aim of each section, and then practice what they learn
using templates that are provided in the supplementary document CIS_RAM_Workbook.
While conducting their first CIS RAM-based risk assessment, organizations should be careful to
not try to “boil the ocean.” Regulatory bodies and information security standards alike understand
that not all risks can be identified in a single assessment. Organizations should continuously and
regularly assess risks to identify, understand, and manage risks over time.
The Risk Assessment Project
Overview
Risk assessments are projects with clear steps for preparing, conducting, and reporting risk
analysis. And while risk assessment projects can be modeled with a typical plan, each
organization’s project approach will vary depending on factors such as resource availability, and
will develop over time as organizations become more capable in their cybersecurity maturity. This
section will describe a risk assessment project, its components and variations, and will present
guidance for preparing the plan.
The Project Outline
Risk assessments are conducted using a series of steps that include typical actions, and roles as
shown in Table 31.
Table 31 – Example Risk Assessment Project Outline
Step Task Key Roles
1 Defining the Scope & Scheduling Sessions Executives, Management, Assessor
2 Defining Risk Assessment Criteria Management, Assessor
3 Defining Risk Acceptance Criteria Executives, Management, Assessor
4 Risk Assessment (Asset-Based)
4.1 Gather Evidence Personnel, Management, Assessor
4.2 Model the Threats Personnel, Management, Assessor
Version 1.0 – April 2018 49
Step Task Key Roles
4.3 Risk Evaluation Assessor
5 Propose Safeguards
5.1 Evaluate Proposed Safeguards Assessor, Management
During Step 1 (Defining the Scope & Scheduling Sessions), the organization will determine which
information assets to include in their evaluation. They will also identify business owners and
technical stewards who will provide evidence and interviews to assess those assets. The risk
assessor will then schedule interview sessions with those owners and stewards.
In Step 2 (Defining Risk Assessment Criteria) the organization will define the rules by which they
assess and score risks. They will define their mission (the value they bring to others), their
objectives (their organizational definitions for success and failure), and their obligations (the
potential for harm against others) to establish what they are trying to protect. They will then define
scoring schemas to be used for impact and likelihood estimation.
In Step 3 (Defining Risk Acceptance Criteria) the organization will establish their risk tolerance by
selecting a combination of the likelihood of an impact that would be tolerable to all parties (the
organization and parties that may be harmed by realized risks).
In Step 4 (Risk Assessment – Asset-Based) the risk assessor will evaluate the risks of the
information assets. For Tier 2 organizations, the analysis includes the following activities:
• “Gather Evidence” involves a review of documents, such as policies, procedures,
standards, and benchmarks. It also includes interviews with management and personnel.
Evidence gathering also entails observation of configurations, artifacts, facilities, records,
and work processes to determine whether they operate in secure or vulnerable ways.
The levels of evidence gathering will be directly associated with the maturity of the
organization.
• In the “Model the Threats” activity, the organization will model risks with at least these
components; CIS Controls that should be in place to protect information assets,
safeguards that effectively protect information assets as described by the CIS Controls,
and vulnerabilities that result if safeguards are not sufficiently effective. The order in
which these components are considered depends on the maturity of the organization, as
will be described later in this document.
• During “Risk Evaluation” the organization will estimate the likelihood and impact of the
risks. The estimates will be based on the scoring and criteria that were established in
Step 2. The risk score will be automatically calculated to determine whether the current
implementations of CIS Controls are already reasonable.
During Step 5 (Propose Safeguards) the organization will consider how to address unreasonable
risks by selecting CIS Controls that should be implemented to address each risk, and specifically
how the controls will be implemented. These safeguards may include security devices, physical
safeguards, training, oversight processes, or other methods. The risk assessor then will test the
reasonableness of the safeguards during “Evaluate Proposed Safeguards.” The risk assessor will
evaluate the proposed safeguards using the same criteria that were used to evaluate the risks.
A project plan template is available in the supplementary document CIS_RAM_Workbook.
Defining the Scope & Scheduling Sessions
Note: The reader should use the worksheets provided in the supplementary document
CIS_RAM_Workbook while reading these instructions. The reader will best understand the
concepts and their use by practicing the methods described in this chapter.
Version 1.0 – April 2018 50
Defining the Scope
Organizations should conduct risk assessments against a clearly defined scope of information
assets. A single theme usually bounds the scope of assets, such as “information assets that
contain sensitive information,” “the data center,” “engineering practice areas and technologies
that support them,” or a specific business division.
While it is possible to select unrelated information assets for an assessment – or a subset of
assets within a larger scope – the organization that receives the assessment and is making
investments and prioritization decisions based on its findings will be most comfortable when the
information assets are associated with a business entity or a business process. Otherwise, risk
assessment findings may seem scattered and unrelated.
Similarly, while assessing the risk of a set of information assets, it makes good sense to consider
a set of assets that can directly affect each other’s security. For example, a risk assessment that
examines a set of applications should also include the network devices that connect the
applications to other assets and other networks, as well as the processes that are used to
develop and manage those applications. These systems are directly connected to each other and
dependent on each other so their risks are easily associated with one another.
Organizations cannot examine all information assets comprehensively in a single risk
assessment, so their scope should consider the time and resources that are available for the
assessment. Risk assessors should consult security experts to help them determine which
assets, threats, and risks to prioritize.
An example scoping table (Table 32) demonstrates the level of detail that is appropriate for an
initial assessment plan and is provided in the workbook CIS_RAM_Workbook.
Table 32 - Example Scoping Table
Asset Type Asset Name Business Owner Steward
Information Application Code COO CIO
Information Patient Information Customer Experience CIO
Application Patient Record (prod) Customer Experience Product Manager
Application Patent Record (dev) Customer Experience Software Development
Application DataMart Innovations Dept DevOps
Server ProductionAppSrvr1 Customer Experience DevOps
Server ProuctionDBServer2 Customer Experience DevOps
Server DevAppSrvr1 Software Development DevOps
Server DevDBServer2 Software Development DevOps
Server LDAP1 CIO DevOps
Server DNS1 CIO DevOps
Network Device Core Router CIO Network Engineering
Network Device DMZ Router CIO Network Engineering
Network Device Firewall 1 CIO Network Engineering
Network Device Firewall 2 CIO Network Engineering
Network Device Switch CIO Network Engineering
Process AppDev Customer Experience Software Development
Process Code Promotion Customer Experience DevOps
Process Maintenance Product Manager DevOps
Version 1.0 – April 2018 51
Asset Type Asset Name Business Owner Steward
Process Change Management Product Manager DevOps
Process Vulnerability Mgt CIO Security Team
Process Account Setup Customer Experience Application Management
Process Account Maintenance Customer Experience Application Management
Process New Client Onboarding Customer Experience Application Management
Process Internal Audit Compliance Internal Audit
Process Device/System set-up CIO DevOps
Process Customer Support Customer Experience Application Management
Note that the scoping table includes the business owner roles and steward roles. Business
owners are the (typically) non-technical managers who are responsible for the information and
processes that information assets support. Stewards are (typically) technical managers who are
responsible for the functionality and security of the information assets. By identifying information
asset ownership up front, the scoping table can be used to help plan interview sessions for the
remainder of the risk assessment.
Regardless of how the scope of the risk assessment is established, and how detailed the asset
listing is, there are a few helpful practices an organization should keep in mind as they identify
their information assets:
• Think of a set of similarly-situated assets as a single asset class. For example, all
database servers that use the same technology and the same maintenance and
administration methods may be considered one asset class. However, if one set of
database servers is different from others (for example, they hold sensitive information in
a DMZ while others process less-sensitive information in another zone), these may be
considered two assets because their risks will be different, even if they are managed
identically.
• Information assets are not only technologies that store and transmit sensitive information.
Information assets are any information, technology, process, people, or facilities that may
impact the confidentiality, integrity, or availability of information.
• Include in the scope all information assets that are within the same zones (networks,
facilities, etc.) as any other in-scope information asset.
The reader should develop their own scoping table using the scoping table template in the
supplementary document CIS_RAM_Workbook.
Version 1.0 – April 2018 52
Scheduling Interview Sessions
Interview sessions will be topical, and should address one topic or closely related topics for each
conversation. Interview sessions can focus on CIS Controls, or information assets and asset
classes.
For example, interview sessions that focus on CIS Controls would bring together the personnel
and management who know how each control is implemented and operates. One session may be
dedicated to CIS Control 1 to understand how devices are inventoried. Another may be
scheduled to discuss CIS Control 2 to understand what safeguards are in place to inventory
software. Or, if the same personnel are knowledgeable about both safeguards, then perhaps one
session could combine both topics.
Similarly, if risk assessors schedule sessions around information assets or asset classes, then it
would be appropriate to include business owners and technical owners of those systems to
understand how associated CIS Controls are applied to each asset or asset class.
An example session for a web application may include product managers, application developers,
application administrators, and business owners. Topics in that session may include CIS Control
14, “Controlled Access Based on the Need to Know,” CIS Control 16, “Account Monitoring and
Control,” and CIS Control 18, “Application Software Security.”
How the organization groups and orders these topics is largely up to them, but risk assessors
should consider these pointers while scheduling interview sessions:
1. Be respectful of people’s time. While it is important to gather comprehensive information
about risks, organizations cannot gather all relevant information in the first one or two risk
assessments.
2. Work with managers to determine the most efficient and useful way to schedule
interviews, whether by CIS Controls or by information assets and asset classes.
3. Expect that some security safeguards will be applied differently to different information
assets and asset classes. For example, CIS Control 5, “Secure Configuration for
Exercise:
The reader should develop their own scoping table using the “Scope - Tier 2” worksheet that is
provided in the supplementary document CIS_RAM_Workbook.
The reader should consider:
1. A set of information assets your organization is interested in focusing your security
resources on?
a. This set can be defined by processes, technologies, a class of information, or
a location.
2. What are the boundaries between this set of information assets and other information
assets not in this scope?
a. What systems, facilities, and network devices link these boundaries together,
or separate them?
b. Are these “boundary” assets included or excluded from the scope?
3. List information assets or asset classes that are within the scope.
a. List information assets or asset classes to a level of detail that the
organization has the time and resources to analyze. This may require
adjustment during the course of the assessment if the organization realizes it
has more time (or less time) than they originally planned to assess the
information assets.
Version 1.0 – April 2018 53
Hardware and Software on Mobile Devices, Laptops, Workstations and Servers,” and CIS
Control 16, “Account Monitoring and Control” may be implemented and overseen
differently for servers in different environments, or may be centrally controlled for servers,
but individually controlled for network devices. Plan on evaluating how these and similar
safeguards are applied to different asset classes.
4. Provide an agenda for reach interview to help participants prepare any materials or
information regarding the information assets or controls that may be discussed.
Scheduling Evidence Reviews
Risk assessors use evidence review sessions to examine information assets and; determine
whether they conform to CIS Controls, and evaluate whether they would be effective against
foreseeable threats.
The evidence review sessions should be scheduled following the interviews so that risk
assessors understand the general landscape of the security environment before trying to
understand why certain assets are configured the way they are.
During interviews, the risk assessor will learn about topics that should be more closely
understood through a review of configurations, system testing, or records review. Risk assessors
should note during or soon after the interview which safeguards they will want to examine further,
and inform the participants that they will likely be contacted later in the assessment to participate
on those evidence review sessions. Further, the assessor should ask which personnel,
processes, or information assets would be appropriate to examine to gather the appropriate
evidence. The evidence review sessions can then be scheduled at the end of the interview.
Techniques for reviewing evidence of the effectiveness of controls are presented later in the
chapter “Risk Analysis Techniques.”
Defining Risk Assessment Criteria
Introduction
Risk assessment criteria are the numerical and plain-language statements that an organization
uses to evaluate their cybersecurity risk. The most familiar form of risk calculations, “Risk =
Likelihood x Impact,” is the basis for risk analysis in the CIS RAM. But it is just the starting point
for risk analysis.
Risk assessment criteria must be meaningful to the organizations that use them, so they must be
tied to the potential benefit and harm that the organization may create. The impact of a
cybersecurity breach may harm the organization itself, it may harm the organization’s ability to
successfully achieve its mission, or it may harm others.
Because cybersecurity failures impact parties both inside and outside an organization, risk
assessment criteria must be universally meaningful and must address the interests of all
potentially affected parties. Additionally, risk assessment criteria must demonstrate to authorities,
such as regulators and litigators, that the organization considers the risk of harm to others as
much as the risk of harm to themselves.
While these requirements may seem complex, the method presented in this section will
sufficiently address them while using a technique that is simple to develop and use.
Risk Assessment Criteria Foundations
The risk analysis provided in the CIS RAM is at its root a question of balance between the
potential of future harm against the certain burden of a safeguard. Regulators and litigators have
Version 1.0 – April 2018 54
long considered this balance as key to acting as a “reasonable person.” The core structure of a
risk statement is provided below to illustrate the core concept of balance.
Figure 9 - Balance Within Core Risk Analysis
Notice a few things right away with the model risk analysis in Figure 9.
• While organizations typically evaluate the observed risk to determine whether they should
address or accept it, this risk statement deliberately compares the observed risk to a
proposed safeguard.
• The criteria that evaluates the risk also evaluates the safeguard.
• The impact of the risk estimates the potential of harm to the organization and the
potential harm against others.
Risk assessors compare risks to their proposed safeguards to determine whether those
safeguards would create a foreseeably lower risk than the current state. To accomplish this, the
assessor evaluates the current state risk (or “observed risk”) and the proposed safeguard using
the same criteria to ensure comparability.
This comparison prevents organizations from implementing safeguards that are overly
burdensome, or that create new, unacceptable risks. For example, an organization that uses
software that is no longer supported by the vendor, but relies on that software for critical business
purposes, should find alternative methods for identifying and controlling potential security risks
until they replace the software. If management recommends quickly changing out to inferior, but
secure software, the organization may suffer a greater impact to their mission than the security
risk they are trying to avoid.
While considering CIS Control 18: Application Software Security, a risk statement can be made to
estimate the foreseeability of an impactful threat. The risk can be stated as it appears in Table 33
(where the risk score ‘12’ is a product of the likelihood ‘3’ and the highest impact score ‘4’):
Table 33 - Example Core Risk Statement
Observed risk Likelihood Impact to Impact to
Us Others
Risk
Score
Hackers may exploit the unsupported,
but critical application.
3 3 4 12
A risk assessor should then recommend and evaluate a safeguard to reduce the high security
risk, as illustrated in Table 34. Here, the organization would realize that the likelihood of a
negative impact to their mission is greater than the current state risk. This is an obvious case of
the burden being greater than the risk, and a recommended safeguard being unreasonable.
Version 1.0 – April 2018 55
Table 34 - Example Unreasonable Proposed Safeguard
Proposed
Safeguard
New Risk Likelihood Impact to
Us
Impact to
Others
Safeguard
Risk
Replace application
with inferior,
secure application.
Application will
operate
inefficiently.
5 3 1 15
When faced with this analysis, the organization must then find another way to address the risk.
This process will be described later in this chapter in the section Risk Treatment
Recommendations.
But what should be apparent is that without a definition of risk assessment criteria the likelihood
and impact scores are not meaningful. What would impacts or likelihoods of ‘1’, ‘2’, ‘3’, ‘4’, or ‘5’
mean, anyway? The organization will need to create definitions for their likelihood and impact
scores so that they are meaningful to all interested parties, and so that they provide a consistent
method for risk evaluation.
Impact Definitions
Tier 2 organizations generally benefit from more business involvement in managing cybersecurity
risk than Tier 1 organizations. Because of that increased involvement, the risk assessment
criteria can be – and should be – more explicit and detailed than those used by Tier 1
organizations. Advanced organizations can consider more nuance in terms of business impacts
and tolerance, and can employ organizational objectives with more authority.
An impact definition for Tier 2 organizations can have at least three impact types, and five impact
scores (magnitudes) like the definition depicted in Table 35.
Table 35 – Example Impact Definitions
Impact
Score
Impact to Mission
Mission: Provide information to
help remote patients stay
healthy.
Impact to
Objectives
Objectives: Operate
profitably.
Impact to Obligations
Obligations: Patients must not
be harmed by compromised
information.
1 Patients continue to access
helpful information, and
outcomes are on track.
Profits are on target. Patients do not experience
loss of service or protection.
2 Some patients may not get all
the information they need as
they request it.
Profits are off target,
but are within
planned variance.
Patients may be concerned,
but not harmed.
3 Some patients cannot access
the information they need to
maintain good health
outcomes.
Profits are off
planned variance and
may take a fiscal
year to recover.
Some patients may be
harmed financially or
reputationally after
compromise of information or
services.
4 Many patients consistently
cannot access beneficial
information.
Profits may take
more than a fiscal
year to recover.
Many patients may be
harmed financially or
reputationally
5 We can no longer provide
helpful information to remote
patients.
The organization
cannot operate
profitably.
Some patients may be
harmed financially,
reputationally, or physically,
up to and including death.
Version 1.0 – April 2018 56
Tier 2 organizations that previously used Tier 1 risk analysis processes may build on their simpler
risk assessment criteria that used three levels of impact scoring. For the purposes of reference to
our example organization – a health information provider – they have gone through a year or two
of risk management and have gained the attention and confidence of business managers and
executives. As a result, their ability to assess cybersecurity risk using business criteria will also
improve.
We can see by comparing the risk assessment criteria for Tier 1 organizations in Chapter 2 to
Table 35 that the detailed descriptions of impacts have increased in two dimensions; the number
of impact scores (magnitudes) increased from three to five, and there is an additional impact type
for business objectives.
Tier 2 organizations will find that using a range of five impact scores (magnitudes) increases the
utility of risk prioritization at the end of the risk assessment. A three-by-three risk assessment
criteria model provides organizations with six possible risk scores; 1, 2, 3, 4, 6, and 9. This leads
to a somewhat course grouping that may cause risks of somewhat different urgencies to be
indistinguishable.
A five-by-five risk assessment criteria model allows for 14 possible risk scores of; 1, 2, 3, 4, 5, 6,
8, 9, 10, 12, 15, 16, 20, and 25. Now risks of somewhat different urgencies will likely be classified
into different risk scores and will be more easily distinguished while prioritizing them.
Also note that the impact scores of ‘1’ and ‘2’ in Table 35 are shaded grey to separate them from
the higher scores. Scores ‘1’ and ‘2’ describe impacts that would be generally thought of as
acceptable. The risk acceptance criteria process will be explained later in the document, but it is
useful to consider now that the scores ‘1’ and ‘2’ are consistent in their definition of impact scores
across all three impact types, and that the impact scores of ‘3’, ‘4’, or ‘5’ could consistently be
thought of as unacceptably high for all three impact types.
The example health information provider also has a new impact to consider in Table 35 to help
them include their business objectives in their risk analysis. Business objectives are more self-
focused than missions and obligations, and are aligned with success criteria commonly found in
business. Some examples include profitability, growth, maintaining accreditations, customer
satisfaction, or retaining a position in the marketplace.
Background – Impact Definitions
This document provides instructions for defining impacts and impact scores (magnitudes) in
this section with more in-depth instructions and examples in the “Risk Analysis Techniques”
chapter. The reader should understand before going further that organizations in most cases
should not define impacts exclusively using financial values. While cost is a common and
almost necessary consideration while evaluating risks and safeguards, if it is the only criterion,
the organization will communicate to their personnel, as well as to interested parties and
authorities, that cost is their only concern. The purpose that the organization serves and the
harm that may befall others must be part of the evaluation if risk is to be responsibly tied to the
potential of harm, and if the evaluation is to be understandable to regulators and legal
authorities.
Organizations should also consider having more than three impact types in their impact
definitions if they have more than one mission, multiple objectives, and many obligations that
they need to consider in their risk analysis. While this expansion may create an increasingly
wide risk register, it can help organizations feel comfortable all relevant interests were
considered in their risk analysis.
Version 1.0 – April 2018 57
Objectives align most directly with what is commonly thought of as the “cost” of a safeguard. But
rather than allowing an organization to arbitrarily decide that a safeguard costs too much, this
method of including cost in terms of impacts to objectives forces the organization to evaluate why
a cost would be excessive. Does the cost of the safeguard impede profitability goals? Does the
safeguard limit efficiency or growth? Those are certainly reasonable concerns, as long as the
profitability goals are in parity with the mission and obligations impacts. In other words, an
organization should not let profitability be more important than harm to others, or harm to their
ability to fulfill their mission. See “Note Regarding Use of Financial Costs as Objectives” in
Chapter 5.
Figure 10 - Objectives, Mission, Obligations
Organizations are well-served with this model because business management, technicians,
compliance personnel, and legal counsel all have their interests addressed in risk analysis that
uses these criteria.
An in-depth explanation of how to develop impact definitions with multiple examples is provided in
the chapter “Risk Analysis Techniques.”
Likelihood Definitions
The likelihood definition for a Tier 2 organization should also increase in nuance from the simpler
Tier 1 definition, and can do so by adding two more scores to the table as shown in Table 36.
Table 36 – Example Likelihood Definitions
Likelihood
Score
Foreseeability
1 Not foreseeable. This is not plausible in the environment.
2 Foreseeable. This is plausible, but not expected.
3 Expected. We are certain this will eventually occur.
4 Common. This happens repeatedly.
5 Current. This may be happening now.
• “Not Foreseeable” implies that a threat is not plausible in the environment that is being
assessed. Loss of portable media may not be foreseeable during a risk assessment of a
hosted application.
Objectives
• Self benefit
• Self risk
Mission
• Mutual benefit
• Mutual risk
Obligations
• Others' benefit
• Others' risk
Version 1.0 – April 2018 58
• “Foreseeable” implies something that is plausible, but the organization would be
surprised if it occurred. A founding executive taking copies of sensitive data to
competitors may be considered foreseeable, even if it is not expected.
• “Expected” implies a threat that is not common, but that would eventually happen.
Phishing attacks or other social engineering attacks may be expected in many
environments.
• “Common” implies something that happens repeatedly, such as mis-addressed emails
with sensitive information, malware attacks, or loss of laptops and mobile devices.
• “Current” implies threats that are rarely not present, such as port scanning on perimeter
devices, or sharing of information in quasi-public spaces such as pharmacy counters or
bank tellers.
When risk assessors estimate the likelihood of a threat, they will select scores ‘1’, 2’, ‘3’, ‘4’, or ‘5’
using the foreseeability definition as their guidance. Organizations may add time-based limits in
their foreseeability definitions (i.e. “Foreseeable within planning thresholds,” “Expected within the
five-year plan” or “Not foreseeable in the next fiscal year”). If organizations do introduce time
limits in their likelihood definitions they should prioritize risk treatment investments to meet these
timelines. That may be excessively challenging to many organizations, so they should proceed
with caution.
Developing the Risk Assessment Criteria
Because risk assessment criteria are meant to describe risk as it applies to the organization that
owns the risk, it is appropriate for the most senior management who are responsible for the
mission, objectives, and obligations to participate in developing and accepting the criteria.
Table 37 lists roles commonly involved in risk assessment criteria development, and the
interested perspective they bring to the definition effort.
Table 37 - Roles Involved in Defining Risk Assessment Criteria
Role Perspective
Chief Executive Officer
Chief Operations Officer
To ensure that the mission, objectives, and obligations of the
organization are appropriately defined, and to ensure that a
distinction between acceptable and unacceptable impacts are
appropriately delineated.
Chief Compliance Officer To ensure that the interests of regulatory agencies are
appropriately included in risk definitions.
Chief Financial Officer To ensure that objectives are appropriately defined, particularly
the distinction between acceptable and unacceptable impacts.
Chief Information Officer
Chief Technology Officer
To ensure that technical performance, service, and capabilities
are considered, and to include all types of information processes
beyond technology.
General Counsel
Outside Counsel
To ensure that obligations are appropriately defined and that they
compare well with the mission and objectives.
Internal Audit
Audit Committee
To ensure that the concerns of interested parties are well
represented in all impact definitions and scores.
Key Customers / Clients
Key Constituents
To ensure that their interests are included in the obligations
definition.
Version 1.0 – April 2018 59
The risk assessor will need to use their professional judgment to define impact types, and to
describe levels of impact that the organization must manage to. Because risk assessment criteria
are a declaration by the organization of what they will manage to in terms of harm to themselves
and harm to others, organizations should consult with legal counsel before finalizing these criteria
and making risk decisions based on them.
Defining Risk Acceptance Criteria
Introduction
Because risk assessments are essentially questions of balance, the criteria for accepting risk
should help determine whether balance was achieved. In CIS RAM risk acceptance has two
components:
• Appropriate risk: That the likelihood of an impact must be acceptable to all foreseeably
affected parties
• Reasonable risk: That the risk posed by a safeguard must be less than or equal to the
risk it protects against.
While these components have been demonstrated briefly in Chapter 1, the “appropriate risk” will
be described in more detail in this section. “Reasonable risk” will be described later in the Risk
Treatment Recommendations section further on.
After establishing the impact and likelihood definitions, Tier 2 organizations are now well
positioned to state their risk acceptance criteria. Recall that impacts were defined within impact
scores that ranged from ‘1’ to ‘5’. Acceptable impact scores ‘1’ and ‘2’ were defined in a manner
that would appear appropriate to interested parties (and are shaded grey to indicate their
acceptability), and the impact score ‘3’ was the lowest unacceptable score.
Exercise:
The reader should develop their organization’s risk assessment criteria using the “Criteria -
Tier 2” worksheet that is provided in the supplementary document CIS_RAM_Workbook.
The reader should consider:
1. Developing the risk assessment criteria in collaboration with a business managers
and legal counsel to ensure that the Mission, Objectives, and Obligations definitions
are sensible to the organization.
2. Working with legal counsel to help ensure that impact definitions appropriately
address the interests of all potentially affected parties, and to ensure that impact
statements appear equitable to all parties.
3. Referring to guidance for defining and scoring impact types in the “Risk Analysis
Techniques” chapter.
Version 1.0 – April 2018 60
Table 38 – Unacceptable Impacts
Impact
Score
Impact to Mission
Mission: Provide information to
help remote patients stay
healthy.
Impact to
Objectives
Objective: Operate
profitably.
Impact to Obligations
Obligations: Patients must not
be harmed by compromised
information.
1 Patients continue to access
helpful information, and
outcomes are on track.
Profits are on target. Patients do not experience
loss of service or protection.
2 Some patients may not get all
the information they need as
they request it.
Profits are off target,
but are within
planned variance.
Patients may be concerned,
but not harmed.
3 Some patients cannot access
the information they need to
maintain good health
outcomes.
Profits are off
planned variance and
may take a fiscal
year to recover.
Some patients may be
harmed financially or
reputationally after
compromise of information or
services.
4 Many patients consistently
cannot access beneficial
information.
Profits may take
more than a fiscal
year to recover.
Many patients may be
harmed financially or
reputationally
5 We can no longer provide
helpful information to remote
patients.
The organization
cannot operate
profitably.
Some patients may be
harmed financially,
reputationally, or physically,
up to and including death.
And similarly, likelihood scores were within a range of ‘1’ to ‘5’ as below. Once our example
organization develops their risk management maturity and are ready to refine their risk
distinctions, they may decide to not tolerate unacceptable impacts if they are foreseeable but not
expected (‘2’), or if they are expected to occur (’3’). This would be a decision best made by their
executives, and especially their compliance team, general counsel, and interested parties. But in
this case, the model will assume that they selected an unacceptable likelihood score of ‘3’.
Table 39 – Unacceptable Likelihood
Likelihood
Score
Foreseeability
1 Not foreseeable. This is not plausible in the environment.
2 Foreseeable. This is plausible, but not expected.
3 Expected. We are certain this will eventually occur.
4 Common. This happens repeatedly.
5 Current. This may be happening now.
So Tier 2 organizations would define their risk acceptance like this:
Table 40 - Risk acceptance criteria
Impact
Threshold x
Likelihood
Threshold =
Risk
Threshold
3 x 3 = 9
… therefore …
Acceptable Risk < 9
Version 1.0 – April 2018 61
An example of the heat map for this assessment criteria is shown in Figure 11. While risk heat
maps are not used in CIS RAM, organizations can now design heat maps that represent actual
risk acceptability based on organizational requirements, and a duty of care to others.
Figure 11 - Example Heat Map
Impact
Li
ke
lih
oo
d
1 2 3 4 5
5
4
3
2
1
The risk assessor will need to use their professional judgment to identify levels of acceptable risk.
Because risk acceptance criteria are a declaration by the organization of what they will tolerate in
terms of harm to themselves and harm to others, organizations should consult with legal counsel
before finalizing these criteria and making risk decisions based on them.
As organizations assess their risk using the CIS Controls V7 (modeled in the following section)
they will be able to automatically determine whether the risk evaluates as acceptable or not
without needing to consider the question differently in each case. A simple estimation of the
likelihood and impact will automatically determine how the organization should prioritize each risk,
and whether the organization can safely accept the risk as appropriate.
An Asset-Based Risk Assessment Process
Introduction
Tier 2 organizations enjoy collaborative relationships with non-technical management in
managing security risk. They also have the knowledge and experience to plausibly model security
threats against information assets. In this section, the example organization has become more
capable after a year of risk management and has earned a partnering relationship with non-
technical departments. They have learned that information assets should be analyzed based on
Exercise:
The reader should define their organization’s risk acceptance criteria using the “Criteria - Tier
2” worksheet that is provided in the supplementary document CIS_RAM_Workbook.
The reader should consider:
1. Working with a business management sponsor who can help ensure that the risk
acceptance criteria are sensible to the organization.
2. Working with legal counsel to help ensure that the definition for risk acceptance
addresses the interests of all potentially affected parties, and to ensure that impact
statements appear equitable to all parties.
Version 1.0 – April 2018 62
their situation and context, rather than as a single class of technical assets (a process used for
Tier 1 organizations to simplify their risk assessment efforts).
As a Tier 2 organization, their risk assessments will first consider the information assets that are
in scope of their assessment. As they consider those assets, they will think through the CIS
Controls that are appropriate for protecting those assets, they will consider vulnerabilities to those
controls, and they will model foreseeable threats that can take advantage of the vulnerabilities.
This order of analysis provides a distinct benefit to organizations that have a more mature
understanding of security risks and safeguards. It allows organizations to evaluate potential harm
that can come to specific assets and the CIS Controls that should protect them. Only then does it
evaluate the risks.
Organizations that model risks using CIS Controls V7 may find it challenging to consider how one
risk is influenced by other risks related to an asset. For example, if an FTP server allows third-
party employees to access it using shared credentials, then those third-party employees may
retain access to the FTP server after leaving their employer and raising a risk associated with CIS
Control 16.7 which recommends a process for revoking access upon termination. That would
likely appear as a high risk to the organization. But if the risk assessor also determines that the
FTP service allows only write capabilities (CIS Control 14.7), the risk associated with CIS Control
16.7 is likely reduced. Control-based risk assessments such as those used by Tier 1
organizations may miss that relationship and as a result may exaggerate the risk involved in CIS
Control 16.3.
In addition to risk analysis taking this slightly different order in their threat modeling, Tier 2
organizations will also estimate risk with more complex risk criteria. Because of their relationship
with business management, Tier 2 organizations will receive some pressure from business
managers to refine their prioritization of risks, and to evaluate risk using more explicitly business-
based impact criteria.
This section will describe and work through a Tier 2 organization’s risk assessment using the CIS
Controls, and will show how to evaluate risks using the risk assessment criteria that are
appropriate for Tier 2 organizations.
This section of the document will describe a risk register that is available as a template in the
supplementary document CIS_RAM_Workbook.
The Risk Register
As the Tier 2 organization prepares their risk assessment, they will assemble their list of
information assets and align them with the CIS Controls that are appropriate for protecting those
information assets. This section will demonstrate this process using the risk register template
provided in the supplementary document CIS_RAM_Workbook for Tier 2 organizations.
The layout map of a risk register for a Tier 2 organization is depicted in Figure 12.
Version 1.0 – April 2018 63
Figure 12 - Risk Register Layout Map
The risk register for Tier 2 organizations is a listing of identified risks and their recommended risk
treatments, also known as “safeguards.” Each row represents one risk and its accompanying risk
treatment recommendation. The parts of the risk register are:
A. The column headers and guiding text help the reader or risk assessor understand the
information that is contained in the column.
B. The information assets identify the items and processes that are being analyzed.
C. The CIS Controls help the risk assessor consider controls that should be in place to
protect information assets.
D. The “threat model” includes the following items:
a. A description of how the CIS control is implemented in the environment.
b. The vulnerability that may exist if the control is not fully implemented.
c. The threat that may compromise the asset because of the vulnerability.
E. The risk evaluation estimates the likelihood that the threat would succeed, and the
impacts to the mission, objectives, and obligations if it did. The evaluation includes the
resulting risk score, calculated as a product of the likelihood and the highest of the three
impact scores.
F. Risk treatments are recommended for risks that are evaluated as unacceptably high.
Safeguards that are based on the CIS Controls are described, and they are in turn
evaluated for the risk that they may pose to the mission and objectives. A “safeguard risk”
score is calculated which should be lower than the risk acceptance criteria, and the risk
that it is meant to address.
The Process
The Tier 2 risk assessor will analyze risks using an asset-based approach, starting the
assessment by considering the information assets that they intend to protect. Because this
process will invariably create more detail in the risk register (in the form of multiple rows on the
risk register for each asset and each applicable CIS Control) organizations may wish to start their
risk analysis using the Tier 1, control-based method. This method first analyzes how the CIS
Controls are generally applied to the environment. The Tier 2 risk assessor can then examine the
information assets that are protected differently from the standard practice in a separate row.
Version 1.0 – April 2018 64
The asset-based risk assessment process is illustrated in Figure 13.
Figure 13 - Risk Analysis Process for Tier 2 organizations
The asset-based risk assessment process for Tier 2 organizations is meant to ensure that each
information asset is protected by CIS Controls in ways that are appropriate for their particular risk.
This asset-based analysis is accomplished by following the steps listed below:
1. Select information assets or asset classes that are listed in the asset inventory. Record
the selected assets in the “Information Asset” cell in that row.
a. If the Tier 2 organization has already completed a risk register that evaluated all
of the CIS Controls as they are applied generally to the organization, then the
risk analysis may start by selecting assets that are listed in the risk register.
b. Organizations may wish to evaluate asset classes rather than individual assets
for efficiency. As an example, there are often a set of similar technologies that
are identically configured and managed. In such circumstances, listing these as
asset classes is appropriate because each of these items will be similar to the
set. Unique items like a core router, a load balancer, a single instance of an
application, or a one-off operating system should be analyzed on its own.
2. Model threats using the following approach:
a. Consider each information asset or asset class one-by-one.
b. Pair each information asset or asset class to the CIS Controls that are
appropriate to protect them. This is aided by the “Asset Type” categorization of
CIS Controls V7. For example, user desktops, application servers, multi-function
printers, and tablet computers are systems that can be paired with CIS Controls
that are categorized for “Systems.”
c. Add one row to the risk register for each pairing of a CIS Control and the
information asset or asset class.
d. Note: It will likely be too time-consuming to evaluate all suitable pairings between
information assets and applicable CIS Controls. While such analysis would be
optimal, it is more fitting for organizations to prioritize the pairing of information
assets and asset classes with the top five CIS Controls, and other controls that
may be of concern to the organization. Risk management is a continuous cycle
that will allow organizations to address more risks over time as their security
program matures.
3. Gather evidence for how well each asset is protected by its paired CIS Control.
a. Evidence may be in the form of interviews, a review of configurations, a
vulnerability test, a penetration test, an evaluation of a system or device using
SCAP policies, or a review of evidence such as records and logs.
4. Describe how the control is applied to the information asset or asset class in the “Current
Control” cell of that row.
Version 1.0 – April 2018 65
5. Consider the difference between the CIS Control and the current control and determine
whether there is a deficiency in how the control is currently deployed and operating. If the
current control is not implemented as described, how would this be described as a
vulnerability?
a. Consider the objective of the CIS Control. For example, CIS Control 10.3 states
“Test data integrity on backup media on a regular basis by performing a data
restoration process to ensure that the backup is properly working.” Its objective is
to ensure that backup data on storage media is retrievable when it is needed. If
the current control does not meet the objective, then state the gap as a
vulnerability in the vulnerability cell, such as: “We are not confident that our
backup data is retrievable from backup media.”
6. Now consider the threat that could occur because of the vulnerability.
a. The above vulnerability could be paired with the threat: “System failures may
result in a recovery of data as old as one month, or may require manual entry
from paper documents.”
7. Next, estimate the likelihood that the threat would succeed, and the impact it may create.
a. Likelihood estimation can be challenging at first, but the risk assessment criteria
provide some guidance in that estimation process. Guidance is also provided in
the “Risk Analysis Techniques” chapter.
b. Impact scores should provide estimates of the impact that such a threat would
create. Consider the likelihood and impact scores as a pair. In other words,
“What is the likelihood that this impact would result?” Examples below will
provide further guidance.
8. The risk score will be automatically computed by multiplying the likelihood score by the
highest of the three impact scores.
Tier 2 Risk Assessment Example 1 – Risk-Based Business Case
While conducting their risk assessment, the Tier 2 organization comes across a common
question that organizations deal with; when does a business reason justify exceptions to security
policies? This question arises as they consider CIS Control 15.9 which reads, “Disable wireless
peripheral access of devices (such as Bluetooth and NFC), unless such access is required for a
business purpose.”
Organizations commonly accept risks that come with policy exceptions, and do so by
documenting that risk acceptance. But if they make these decisions without careful, consistent
analysis in consideration of foreseeable impacts to themselves and others, then their risk
acceptance is itself risky.
In the case of CIS Control 15.9, the organization uses Bluetooth-accessible systems in regional
clinics to support their patients. Patients carry electronic “diary devices” that monitor their health
status and store health data as diaries. Bluetooth is used in clinics to connect diary device
controllers to the diary devices to read them for diagnostics, to receive data from the devices, and
to transmit updated firmware to those devices. This is undoubtedly worthy of a documented
business need. But is it still unreasonably risky to do so?
Using the risk register template for Tier 2 organizations that is provided in the document
CIS_RAM_Workbook, the organization first lists the information asset that they are evaluating.
Table 41 - Information Asset Example
Information Asset
Diary device controllers
Version 1.0 – April 2018 66
Then they come across the CIS Control that raises the question about business-acceptable risk.
Table 42 - CIS Control Example
CIS
Control
Description
15.9 Disable wireless peripheral access of devices (such as Bluetooth and NFC),
unless such access is required for a business purpose.
The risk assessor must then think through and record the threat model for this risk. Recall that the
threat model considers their current control, what resulting vulnerabilities may exist, and what
threats would be of concern to them. While the diary device controllers must pair with the diary
devices, the organization realizes that their Bluetooth-enabled diary device controllers and the
files located on them are likely accessible by attackers using readily available attacks methods.
So the next three columns of the risk register would look like this:
Table 43 - Threat Model Example
Control Vulnerability Threat
Each diary device is Diary device controllers are using Hackers may walk through
joined to the diary
device controller using
a one-time, six-digit
a deprecated version of Bluetooth
to support older diary devices.
Bluetooth devices can manipulate
clinics with Bluetooth
devices that are prepared
to hack diary device
code that is displayed
on the controller and
Bluetooth services on the diary
device controllers to gain access
controllers using attacks
such as Blueborne, and
entered at the device.
At this point, all file
transfers and firmware
to files and commands on the
controllers.
may access hundreds of
patient data files, as well
as firmware.
updates between
devices are enabled.
But this may not be the only risk that can be considered in this scenario. Another plausible risk
could be that the hacker could put compromised firmware on the diary device controllers to allow
them to control the devices after firmware upgrades. Denial of Service attacks may also happen.
Man-in-the-Middle attacks are also possible. Risk assessors may be concerned that an endless
number of threat models could be created for any pairing between information assets and CIS
Controls, making the risk assessment exercise never-ending. Of course, the risk assessor should
limit the amount of theorizing they do while modeling threats, focusing primarily on the most
plausible threat pairings given the security environment. As a Tier 2 organization, they should rely
on capable personnel and resources that help them focus on the most plausible threats for their
environment.
The threat model is now clearly stated and makes it possible for the organization to estimate the
likelihood and impact of the scenario. Recall the definitions for the impact and likelihood scores
that the Tier 2 organization created. Impact scores are restated in Table 44.
Version 1.0 – April 2018 67
Table 44 – Example Impact Definitions
Impact
Score
Impact to Mission
Mission: Provide information to
help remote patients stay
healthy.
Impact to
Objectives
Objective: Operate
profitably.
Impact to Obligations
Obligations: Patients must not
be harmed by compromised
information.
1 Patients continue to access
helpful information, and
outcomes are on track.
Profits are on target. Patients do not experience
loss of service or protection.
2 Some patients may not get all
the information they need as
they request it.
Profits are off target,
but are within
planned variance.
Patients may be concerned,
but not harmed.
3 Some patients cannot access
the information they need to
maintain good health
outcomes.
Profits are off
planned variance and
may take a fiscal
year to recover.
Some patients may be
harmed financially or
reputationally after
compromise of information or
services.
4 Many patients consistently
cannot access beneficial
information.
Profits may take
more than a fiscal
year to recover.
Many patients may be
harmed financially or
reputationally
5 We can no longer provide
helpful information to remote
patients.
The organization
cannot operate
profitably.
Some patients may be
harmed financially,
reputationally, or physically,
up to and including death.
Also recall that impact definitions for Tier 2 organizations include criteria for the organization’s
objectives because those organizations generally benefit from collaboration with business
management who are invested in the success of the information security program. These
managers often bring to the discussion the organization’s strategic and tactical goals for success.
But also note that this impact definition contains five magnitudes of impact. Five impact scores
help Tier 2 organizations refine their impact estimates in more tangible terms then tables with
three scoring levels, and help them refine their risk scoring to better distinguish between risks of
varying priority. Acceptable impact scores of ‘1’ and ‘2’ are shaded to set them apart from higher,
unacceptable impact scores.
Likelihoods were similarly defined with five potential scores for similar reasons, as shown in Table
45.
Table 45 – Example Likelihood Definitions
Likelihood
Score
Foreseeability
1 Not foreseeable. This is not plausible in the environment.
2 Foreseeable. This is plausible, but not expected.
3 Expected. We are certain this will eventually occur.
4 Common. This happens repeatedly.
5 Current. This may be happening now.
The organization believes that the threat model they documented above – that hackers could
hack into diary device controllers using something similar to a Blueborne attack - is foreseeable,
and perhaps may be expected to occur. While the scenario would likely not be expected for most
organizations, our example organization operates in environments where competitors and
Version 1.0 – April 2018 68
adversarial states have an active interest in compromising their systems, and have proven their
capability in the past. So they decide that their likelihood score for this risk will be ‘3’.
In that scenario, they also expect that their mission would be affected to the point where some
(not many) patients would lose their ability to get a functioning diary device, and would therefore
not access the information they need to maintain good health outcomes. They select a mission
impact of ‘3’.
Such an occurrence would cause the organization to massively and immediately re-invest in their
clinical infrastructure; an investment that they are not prepared to make now and that could take
more than a year to recover from. That would create an objectives impact of ‘4’.
And finally, they believe that each diary device controller would contain no more than 100 patient
records at any one time, given their work routines and service schedules. The patient information
could be used to harm patients reputationally if hackers knew how to trace the patient IDs in each
record to each patient’s health conditions, and then acted maliciously with that information. This is
not a plausible impact, so they select an obligations impact of ‘2’.
A risk that is expected to occur (likelihood = 3) in a way that prevents some patients from
accessing information (mission impact = 3), that would take more than a year to recover from
financially (objectives impact = 4), and that may cause concern but no harm to patients
(obligations impact = 2) would appear as such in Table 46.
Table 46 - Example Risk Estimation
Threat
Likelihood
Mission
Impact
Objectives
Impact
Obligations
Impact
Risk Score
3 3 4 2 12
The risk score is the product of the likelihood score and the higher of the three impact scores,
which in this case is ‘3 x 4 = 12’.
Also recall that the risk acceptance criteria for the Tier 2 organization looks like this:
Table 47 - Risk acceptance criteria
Impact
Threshold x
Likelihood
Threshold =
Risk
Threshold
3 x 3 = 9
… therefore …
Acceptable Risk < 9
An acceptable risk would be one that evaluates to anything below ‘9’. But the risk for how the
organization protects their diary device controllers using their implementation of CIS Control 15.9
is ‘12’ and is unacceptably high.
This risk analysis is demonstrated in Table 48 in a single table to bring all of these elements
together. For document display purposes, this one risk analysis is shown in vertical format rather
than horizontal as it would appear in a risk register. The examples that are described in this
section are contained in the workbook CIS_RAM_Workbook.
Version 1.0 – April 2018 69
Table 48 - Example Risk Analysis for Devices Protected by CIS Control 15.9
Risk Analysis Value
Information Asset Diary device controllers
CIS Control 15.9
Description Disable wireless peripheral access of devices (such as Bluetooth
and NFC), unless such access is required for a business purpose.
Control Each diary device is joined to the diary device controller using a
one-time, six-digit code that is displayed on the controller and
entered at the device. At this point, all file transfers and firmware
updates between devices are enabled.
Vulnerability Diary device controllers are using a deprecated version of
Bluetooth to support older diary devices. Bluetooth devices can
manipulate Bluetooth services on the diary device controllers to
gain access to files and commands on the controllers.
Threat Hackers may walk through clinics with Bluetooth devices that are
prepared to hack diary device controllers using attacks such as
Blueborne, and may access hundreds of patient data files, as well
as firmware.
Threat Likelihood 3
Mission Impact 3
Objectives Impact 4
Obligations Impact 2
Risk Score 12
Risk Acceptability Not Acceptable
So while there is a documented business need for these devices to operate Bluetooth services,
the risk of doing so with this device is still inappropriately high (since risk acceptance criteria is
less than ‘9’ and the observed risk score is ‘12’). The organization will want to address this with a
risk treatment safeguard, which will be demonstrated in the Risk Treatment Recommendations
section further in this chapter.
Because the risk assessment process for Tier 2 organizations starts at the asset, though, we do
have other opportunities to consider how other controls may protect the asset in a manner that
may reduce the risk we just observed.
We can examine how this process provides the Tier 2 organization with deeper risk insight with
the next two examples.
Tier 2 Risk Assessment Example 2 – Risk Reduction Through Related Controls
The Tier 2 organization is considering risks to its information assets by pairing the asset with CIS
Controls that are appropriate for protecting it. CIS Controls V7 assists in this pairing by providing
a classification scheme for the controls called “Asset Type.” If a diary device controller is a
system that has network connectivity, then the Tier 2 organization’s risk assessor can look
through the CIS Controls that are associated with “System” and “Network” families to identify
other controls that would be appropriate to protect the controllers.
Version 1.0 – April 2018 70
They have already evaluated that CIS Control 15.9 does not protect Bluetooth-connected diary
device controllers well enough. But they are not without alternatives. The organization thinks
through other controls that they use to protect their diary devices and come across CIS Control
16.3 which reads, “Require multi-factor authentication for all user accounts, on all systems,
whether managed onsite or by a third-party provider.”
This is interesting to them, because the diary devices use “soft tokens” in the form of certificates
that are intended to track the diary devices for inventory purposes. But the certificates are very
robust, and are tied to the file access privileges on the device controllers. Could this
implementation of CIS Control 16.3 pose an acceptable risk to the diary device controllers, and
could they reduce the risk cited for CIS Control 15.9?
The Tier 2 organization’s risk assessor tests this idea in Table 49. Note how the control is now
described using more detail than the first attempt at analyzing this risk.
Table 49 - Example Risk Analysis for Devices Protected by CIS Control 16.3
Risk Analysis Value
Information Asset Diary device controllers
CIS Control 16.3
Description Require multi-factor authentication for all user accounts, on all
systems, whether managed onsite or by a third-party provider.
Control While diary devices can connect to diary device controllers over
Bluetooth using a one-time, six-digit code, access to existing files
with patient information on the controller is granted using the
unique soft-cert on each diary device.
Vulnerability Six-digit codes may be guessed, or soft-certs may be stolen from
diary devices and stored on attacker systems.
Threat Hackers must steal soft-certs from diary devices, then guess one-
time six-digit codes to access patient files on diary device
controllers.
Threat Likelihood 1
Mission Impact 3
Objectives Impact 4
Obligations Impact 2
Risk Score 4
Risk Acceptability Acceptable
Given this method for two-factor authentication, the threat model for hackers acquiring patient
records from diary device controllers is no longer foreseeable using the threat model that the Tier
2 organization evaluated. And if that’s the case for the two-factor authentication control, then it
should also influence the risk associated with CIS Control 15.9 that was evaluated earlier. So the
risk assessor re-evaluates that risk again while referring to the controls identified for CIS Control
16.3 to see if they understand the risk differently. Again, note that the risk assessor described the
control with more detail than the first attempt, and added a condition to the threat against CIS
Control 16.3.
Version 1.0 – April 2018 71
Table 50 - Example Revised Risk Analysis for Devices Protected by CIS Control 15.9
Risk Analysis Value
Information Asset Diary device controllers
CIS Control 15.9
Description Disable wireless peripheral access of devices (such as Bluetooth
and NFC), unless such access is required for a business purpose.
Control [Supplemented by CIS Control 16.3] Each diary device is joined to
the diary device controller using a one-time, six-digit code that is
displayed on the controller and entered at the device. At this point,
all file transfers and firmware updates are enabled. However, files
may only be accessed by devices that use soft-certs that are
associated with access privileges on diary device controllers.
Vulnerability Diary device controllers are using a deprecated version of
Bluetooth to support older diary devices. Bluetooth devices with
seized soft-certs can manipulate Bluetooth services on the diary
device controllers to gain access to files and commands on the
controllers.
Threat Hackers may walk through clinics with Bluetooth devices that are
prepared with device-specific soft-certs to hack diary device
controllers using attacks such as Blueborne. Hackers must steal
soft-certs from diary devices, then guess one-time six-digit codes
to access patient files on diary device controllers.
Threat Likelihood 1
Mission Impact 3
Objectives Impact 4
Obligations Impact 2
Risk Score 4
Risk Acceptability Acceptable
As expected, the risk associated with CIS Control 15.9 is reduced because the likelihood of its
threat model is reduced when taking into account the implausibility of hackers accessing files on
the diary device controllers. In fact, the likelihood of the threat scenario is so low that the risk is
acceptable.
The asset-based approach to risk analysis clearly presents an advantage to organizations by
providing a more comprehensive and more realistic picture of the actual risk that an information
asset is exposed to.
Tier 2 Risk Assessment Example 3 – New Perspectives from Risk
Not all asset-based risk analyses will reduce risk estimations, of course. Some will highlight risks
that organizations rarely consider. In this example, the Tier 2 organization paired the CIS Controls
for Malware Defenses with the diary device controllers and realized they had a problem. CIS
Control 8.1 states, “Utilize centrally managed anti-malware software to continuously monitor and
defend each of the organization's workstations and servers.”
Version 1.0 – April 2018 72
But the diary device controller’s vendor does not support or provide an antivirus application for
their operating system – a customized Linux distribution. While the diary device controllers are
“headless” systems, they have web admin applications that provide administrative functions to
controller operators, and can be managed through terminal sessions over console ports. The
organization does not want to violate their support agreement with the vendor by compiling and
running an antivirus application on the controllers.
By running a risk analysis, the organization will determine whether the malware risk is high
enough to require antivirus software. Their finding is illustrated in Table 51.
Table 51 - Example Risk Analysis for Devices Protected by CIS Control 8.1
Risk Analysis Value
Information Asset Diary device controllers
CIS Control 8.1
Description Utilize centrally managed anti-malware software to continuously
monitor and defend each of the organization's workstations and
servers.
Control Anti-malware software is not permitted on the diary device
controllers.
Vulnerability Vulnerabilities are limited because common vectors for receiving
malware such as email clients and web browsers are not installed
on the controllers. Attackers would need to download malware
executables from the Internet using scripts or bash commands.
Command line, by design, is only accessible over terminal
connections to the console port.
Bluetooth attacks may still permit malware executables to be
uploaded to a file space associated with an anonymous account.
The web admin application on each controller has been tested as
vulnerable to arbitrary code execution, cross-site scripting, and
other attacks.
Threat Hackers may implant malware on diary device controllers through
Bluetooth misuse, and take advantage of web admin application
vulnerabilities to execute files or initiate scripts.
Threat Likelihood 3
Mission Impact 3
Objectives Impact 4
Obligations Impact 3
Risk Score 12
Risk Acceptability Unacceptable
This looks more serious to the organization than they would have originally thought. Still
concerned about attacks they have seen in the past, the organization realizes it is as likely for
them to be attacked through a web application vulnerability as it would be through a Bluetooth
vulnerability. Implanting a usable virus through a Bluetooth exploit or arbitrary file upload would
Version 1.0 – April 2018 73
require a hacker with patience and skill, so the likelihood score of ‘3’ for “Expected” seems more
suitable than a ‘4’ for “Common.”
The challenges the organization faces are multi-fold in this risk: They cannot install an anti-virus
application, nor a more secure web application on the diary device controllers, but the risk of
malware is clearly too high. They will evaluate possible safeguards while developing their risk
treatment recommendations in the next step of their risk assessment process later in this chapter.
Exercise:
The reader should refer to the template Risk Register – Tier 2 that is provided in the
supplementary document CIS_RAM_Workbook. They may use the risk register template to
enter a set of risks that are associated with the CIS Controls and information assets that are in
scope of their assessment.
While doing this exercise, the reader should consider:
1. Ensuring that all in-scope information assets or asset classes are assessed.
2. Not “boiling the ocean.” Not all assets can be practically evaluated against all
applicable CIS Controls in a single assessment. Prioritize controls that protect
information assets that appear vulnerable, or that protect high-value systems and
information.
3. Consider assessing all assets against the first five CIS Controls to address the most
common causes of cybersecurity incidents.
4. Whether a control or information asset requires examination to understand its actual
configuration and effectiveness.
5. Whether the organization can tolerate the amount of effort and time that the risk
assessment requires.
a. The organization should use high-level analysis (review of policies and
interviews) if they do not have extensive time and resources.
b. Information assets should be tested and examined in more detail as time
allows.
c. The organization should plan recurring risk assessments to identify more risks
over time.
6. Collaborating with information security subject matter experts to help model threats
that are foreseeable in the environment, and to help evaluate the effectiveness of
current safeguards.
The risk assessor will need to use their professional judgment to select the controls and
information assets and to model threats that should be analyzed in the risk assessment.
Information security experts may need to be included in the process to ensure that the risk
analysis is conducted appropriately.
Tier 2 Risk Assessment Summary
After having analyzed a set of risks against a single information asset, the Tier 2 organization
realizes the advantages of gaining a more comprehensive view of its risks:
1. When organizations consider impacts to their objectives, risk assessors include business
interests in their risk analysis, thus engaging non-technical collaborators in risk decision-
making.
Version 1.0 – April 2018 74
2. When organizations add impact scores (magnitudes) and likelihood scores they can
make more refined distinctions between risks and can prioritize them more reasonably.
3. Pairing information assets to multiple CIS Controls provides a more comprehensive and
perhaps accurate understanding of the actual risk to those assets.
4. Pairing information assets to multiple CIS Controls also prompts risk assessors to
consider threats that they may have otherwise neglected.
Risk Treatment Recommendations
Introduction
Organizations often think of security safeguards as obstacles to business and productivity.
Safeguards often cause personnel to take extra steps to get access to systems or information, or
to get approval for normal business activities. Safeguards require investments in time and money,
which compete with other priorities. And if they become too disruptive to an organization’s
mission and objectives, security safeguards can become disliked and avoided.
In fact, disruptive safeguards often cause personnel to work around them just to get their jobs
done, which creates more risk.
But risk treatment recommendations can and should result in safeguards that are demonstrably
reasonable. And while obtaining a clear definition for “reasonable safeguards” has been a
challenge in the legal, regulatory, and information security communities, the CIS RAM provides a
practical solution. Risk assessors evaluate risk treatment recommendations to determine whether
a security safeguard is reasonable by; comparing the safeguard to the risk it is meant to reduce,
and by comparing the safeguard to the risk acceptance criteria.
Risk treatment recommendations are simple to evaluate once the risk assessment criteria and
initial risk analysis have been established. The process occurs over the following steps:
1. While examining an unacceptably high risk, review the CIS Control that corresponds with
the risk and recommend a feasible way for the organization to implement or improve that
control.
2. If that control is not feasible in the near-term, recommend other CIS Controls related to
the risk that can be used to reduce it.
3. Evaluate the risk of the recommended safeguard to understand the burden it would pose
to the organization. Then compare that safeguard risk to the risk acceptance criteria to
determine whether it is appropriate.
4. Also compare the evaluated risk of the recommended safeguard to the observed risk to
determine whether the safeguard is reasonable (safeguards with lower risk scores than
the observed risk are reasonable.)
5. Sort the risks by their risk score to prioritize the risks and risk treatments that the
organization will invest in.
This section demonstrates these steps in detail by describing the process, then by modeling risk
treatments for the unacceptably high risks that were evaluated in previous sections.
The reader should review the definitions of ‘reasonable’ and ‘appropriate’ that are provided in the
glossary. These terms will be used regularly in this section and have distinct meanings.
1. Appropriate: A condition in which risks to information assets will not foreseeably create
harm that is greater than the organization or its constituents can tolerate.
2. Reasonable: A condition in which safeguards will not create a burden to the organization
that is greater than the risk it is meant to protect against.
Version 1.0 – April 2018 75
Risk Treatment Objectives
The objective of well-formed risk treatment recommendations is to create a prioritized list of
information security safeguards that would provide appropriate protections while not posing too
great a burden on the organization’s purpose.
The risk treatment recommendation exercises that are demonstrated in this section examine the
unacceptable risks that were illustrated earlier in the document and will select CIS Controls that
would reduce those risks to a degree that is both reasonable (not overly burdensome) and
appropriate (not unacceptably harmful).
Recommending Risk Treatment Safeguards from CIS Controls V7
As we examine unacceptably high risks, we will recommend safeguards that are based on CIS
Controls. But some of the safeguards that an organization is prepared to implement and operate
may not be implemented exactly as described in CIS Controls V7. This process takes into
account how to select controls that address risks, and how to determine whether they are
designed in a way that makes sense in context of both the risk, and the potential burden to the
organization.
Recall the relationship between analyzed risks and their recommended risk treatments in Figure
14.
Figure 14 - Balance Within Core Risk Analysis
A risk and its proposed safeguard are both evaluated using the same criteria. If a proposed
safeguard has a higher risk (its “safeguard risk”) than the risk acceptance criteria, then it’s not
appropriate. If the safeguard has a higher score than the observed risk, then it’s not reasonable.
The exercises in this section will focus on matching completed risk analyses (in blue) with newly
recommended safeguards (in green).
Risk Treatment Example 1 – CIS Control 8.1
The exercise that demonstrated risk analysis in Table 51 showed the Tier 2 organization that its
risk of malware on its diary device controllers (CIS Control 8.1) was too high. The organization
was not permitted to add anti-malware software to the device controllers.
To recommend safeguards that are based on alternative controls, the risk assessor reviews CIS
Control 8.1 to understand its objective. CIS Control 8.1 intends that all devices should actively
search for malware and intrusion activity, block the activity, and report it to security management
systems.
The organization faces a challenge when they realize that the diary device controller’s vendor
does not support malware protection on the controllers, and the organization may violate the
service terms of the vendor contract if they install available malware protection.
Until the device controller’s manufacturer distributes a more secure distribution of their product,
the organization will need to consider some safeguards to protect the vulnerable diary device
controllers. IT management recommended that the organization simply install malware protection
Version 1.0 – April 2018 76
on the controllers and take their chances with the vendor. But before committing to this plan, they
worked with the risk assessor to analyze the risk of doing that. Table 52 illustrates their analysis.
Note: The risk assessor will record how they will address their risk by stating either “Accept,”
“Reduce,” “Transfer,” or “Avoid.” Accepting and reducing risks will be intuitive to the reader. An
organization may transfer a risk by contracting a third party that may handle the risk better, or by
acquiring an insurance policy against the risk. The organization may also avoid the risk by no
longer engaging in the processes, or handling the information assets that cause the risk
Table 52 - Example Risk Treatment Recommendation for CIS Control 8.1
Risk Analysis Value
CIS Control 8.1
Description Utilize centrally managed anti-malware software to
continuously monitor and defend each of the organization's
workstations and servers.
Information Asset Diary device controllers.
Control Anti-malware software is not permitted on the diary device
controllers.
Vulnerability Vulnerabilities are limited because common vectors for
receiving malware such as email clients and web browsers
are not installed on the controllers. Attackers would need
to download malware executables from the Internet using
scripts or bash commands.
Command line, by design, is only accessible over terminal
connections to the console port.
Bluetooth attacks may still permit malware executables to
be uploaded to a file space associated with an anonymous
account. The web admin application on each controller has
been tested as vulnerable to arbitrary code execution,
cross-site scripting, and other attacks.
Threat Hackers may implant malware on diary device controllers
through Bluetooth misuse, and take advantage of web
admin application vulnerabilities to execute files or initiate
scripts.
Threat Likelihood 3
Mission Impact 3
Objectives Impact 4
Obligations Impact 3
Risk Score 12
Risk Acceptability Unacceptable
Risk Treatment Option Reduce
Recommended Safeguard Install anti-malware application and host-based intrusion
prevention agents on diary device controllers.
Version 1.0 – April 2018 77
Risk Analysis Value
Safeguard Risk Signature-identified malware and common volatile RAM
exploits will be detected, prevented, and reported to the
central management console.
If vendor sees the malware and IPS agents on controllers
during their quarterly service sessions, they may cancel
those service contracts, delaying service on faulty systems
until new images can be installed on the devices.
Safeguard Threat Likelihood 4
Safeguard Mission Impact 3
Safeguard Objectives
Impact
3
Safeguard Obligations
Impact
2
Safeguard Risk Score 12
Risk Acceptability Unacceptable
The organization has evaluated that management’s recommendation to install the anti-malware
agents is just as risky as the observed risk that they are trying to address. The estimated
safeguard risk equals that of the observed risk, but based on the organization’s concern that the
vendor was expected to force re-imaging on the diary device controllers meant that they expected
to compromise their mission and objectives.
The risk assessor can now advise management against installing the security software directly,
but then should provide alternatives.
Version 1.0 – April 2018 78
Risk Treatment Example 2 – CIS Control 8.1
As the organization considers an alternative risk treatment, they will turn to other CIS Controls to
see what alternatives are available to them.
CIS provides to the public a document titled the CIS Community Attack Model.18 The document
lists all of the CIS Controls and associates them with the role they play in each stage of incident
preparedness and response; planning, detection, and defense. By using the CIS Community
Attack model, an organization can find related and alternative CIS Controls that may substitute for
controls that they cannot sufficiently implement.
By reviewing the Community Attack Model (Figure 15), the risk assessor can quickly identify
which controls they should consider if CIS Control 8.1 is not feasible.
The Community Attack Model is provided in the CIS_RAM_Workbook in a tab titled “Attack Path
Models” for the reader’s convenience, and can be downloaded at the CIS website.
A partial snapshot of the framework demonstrates what the Tier 2 risk assessor found as they
searched for alternative controls.
18 The Community Attack Model may be accessed here: https://www.cisecurity.org/white-
papers/cis-community-attack-model/
Background – How Realistic Are Safeguard Risk Estimates?
Critical readers will question how the organization and their risk assessor will know whether
their safeguard risk estimations are realistic. After all, how can they know prospectively what
their risk would be in such a situation?
There are two important items to keep in mind while gaining comfort with this practice;
understanding the legal and regulatory expectations for risk management, and information
security standards for evaluating safeguards after they’ve been implemented.
Law and Regulation: Laws and regulations generally expect risk analysis to evaluate
safeguards that are required for achieving compliance, and expect that the risk analysis is
performed by appropriately skilled and informed people. These analyses do not guarantee
security that is sufficient against any threat, but they do provide a plan toward improved
security and compliance that is prioritized by the likelihood of harm, and that has no intolerable
harm as its goal.
Information Security Risk Management Standards: Information security risk assessment
standards that the CIS RAM is based on operate within fuller risk management programs and
cycles. ISO 27005 operates within the ISO 27000 family of standards, and NIST 800-30 works
within the NIST Special Publications. Each of these families of standards requires continuous
analysis of security safeguards, including analysis of controls after they’ve been implemented
to determine whether they are effective at addressing their security objectives. Recommended
safeguards should therefore be risk assessed again after implementation to be sure that they
achieve their intended objectives.
Version 1.0 – April 2018 79
Figure 15 - Partial Community Attack Model
Risk assessors may reference the Community Attack Model to find controls that can be
complementary and alternative to the recommended safeguards they are assessing. If an
organization struggles to implement a sub-control, they could look for controls that play a similar
role in the Community Attack Model to find alternative controls that might help them meet the
same security objective. For example, if an organization cannot easily use audit logs to detect
delivery of a kind of threat, they may look to another control in the cell that intersects with the
detect row and the delivery column to find similar controls – and to eventually see network
intrusion detection controls, which may be more useful in their environment.
Given the objectives of CIS Control 8.1 to protect systems against malware and identifiable
intrusions, the risk assessor reviews the Community Attack Model and finds anti-malware in cells
that address protecting against delivery, and for protecting against and detecting initial
compromise. Detecting delivery of malware seems to be a good place to start their defenses as it
is closest to the threat they are addressing in their risk analysis, so they review the CIS Controls
that are in the cell at the intersection of Detect and Delivery to consider options.
Network Intrusion Detection systems and Network Intrusion Prevention Systems (“IDS/IPS”) are
interesting to the organization as a network-layer protection. The risk assessor reviews the sub-
controls within CIS Control 12 “Boundary Defense” to see how IDS is described. CIS Control 12.6
“Deploy Network-based IDS Sensor” presents a compelling option for them because their current
use of the diary device controllers during clinical visits is within mobile wireless LANs that they
own and control. A lightweight IDS would be a plausible option in that case.
But would a lightweight IDS/IPS in those portable wireless LANs reduce their malware and
intrusion risk on their diary device controllers? They model CIS Control 12.6 as a safeguard
against this same risk to see if it would be reasonable.
Version 1.0 – April 2018 80
Table 53 - Example Risk Treatment Recommendation for CIS Control 8.1 using CIS Control 12.6
Risk Analysis Value
CIS Control 8.1
Description Utilize centrally managed anti-malware software to
continuously monitor and defend each of the organization's
workstations and servers.
Information Asset Diary device controllers.
Control Anti-malware software is not permitted on the diary device
controllers.
Vulnerability Vulnerabilities are limited because common vectors for
receiving malware such as email clients and web browsers
are not installed on the controllers. Attackers would need
to download malware executables from the Internet using
scripts or bash commands.
Command line, by design, is only accessible over terminal
connections to the console port.
Bluetooth attacks may still permit malware executables to
be uploaded to a file space associated with an anonymous
account. The web admin application on each controller has
been tested as vulnerable to arbitrary code execution,
cross-site scripting, and other attacks.
Threat Hackers may implant malware on diary device controllers
through Bluetooth misuse, and take advantage of web
admin application vulnerabilities to execute files or initiate
scripts.
Threat Likelihood 3
Mission Impact 3
Objectives Impact 4
Obligations Impact 3
Risk Score 12
Risk Acceptability Unacceptable
Risk Treatment Option Reduce
Recommended Safeguard [CIS Control 12.6] Add a lightweight IDS/IPS device to
portable LANs that operate in clinical visits were diary
device controllers are used.
Safeguard Risk IDS/IPS devices will detect recognizable attacks from other
hosts within the LAN that attempt to deliver and deploy
malware to controllers.
IDS/IPS may not detect malware payload from hosts that
connect to controllers over encrypted protocols.
Safeguard Threat Likelihood 2
Version 1.0 – April 2018 81
Risk Analysis Value
Safeguard Mission Impact 3
Safeguard Objectives
Impact
3
Safeguard Obligations
Impact
2
Safeguard Risk Score 6
Risk Acceptability Acceptable
Even though CIS Control 12.6 does not present a direct anti-malware solution this scenario does
present an acceptable risk, and a reasonable risk. The recommended risk treatment reduces the
likelihood of a successful attack on diary device controllers while not eliminating it in this case.
Management is satisfied that the recommended safeguard is appropriate, but that are also
interested in another option presented by CIS Control 12.11 to use two-factor authentication to
log into terminal sessions at the diary device controllers. If two-factor authentication provides
even lower risk, and the diary device controller vendor supports the option, then this may be a
better safeguard than the lightweight IDS/IPS.
Recall that diary devices already store encrypted soft-certs to help authenticate the devices to
their accounts on the controllers. Checking with the vendor, the organization sees that the soft-
cert option is available for administrator systems that connect to the controllers as well. When the
organization’s site administrators connect to the diary device controllers while on site, they
access terminal sessions using SSH, the only protocol available to them. Multiple soft-certs can
be used to both authenticate the SSH sessions, and to execute commands at the controllers.
They model this alternative risk treatment below.
Table 54 - Example Risk Treatment Recommendation for CIS Control 8.1 using CIS Control 12.11
Risk Analysis Value
CIS Control 8.1
Description Utilize centrally managed anti-malware software to
continuously monitor and defend each of the organization's
workstations and servers.
Information Asset Diary device controllers.
Control Anti-malware software is not permitted on the diary device
controllers.
Vulnerability Vulnerabilities are limited because common vectors for
receiving malware such as email clients and web browsers
are not installed on the controllers. Attackers would need
to download malware executables from the Internet using
scripts or bash commands.
Command line, by design, is only accessible over terminal
connections to the console port.
Bluetooth attacks may still permit malware executables to
be uploaded to a file space associated with an anonymous
account. The web admin application on each controller has
Version 1.0 – April 2018 82
Risk Analysis Value
been tested as vulnerable to arbitrary code execution,
cross-site scripting, and other attacks.
Threat Hackers may implant malware on diary device controllers
through web application exploits while they operate in
clinical settings.
Threat Likelihood 3
Mission Impact 3
Objectives Impact 4
Obligations Impact 3
Risk Score 12
Risk Acceptability Unacceptable
Risk Treatment Option Reduce
Recommended Safeguard [CIS Control 12.11] Require all usage of SSH and all
authentication on diary device controllers to use soft-certs
stored on client devices as a second factor of
authentication.
Safeguard Risk All attempts at accessing SSH services in diary device
controllers will be blocked unless clients use soft-certs to
access SSH sessions. Attackers may seize and re-use
soft-certs during 8-hour long clinical visits and may attack
controllers as a result.
Safeguard Threat Likelihood 1
Safeguard Mission Impact 3
Safeguard Objectives
Impact
3
Safeguard Obligations
Impact
2
Safeguard Risk Score 3
Risk Acceptability Acceptable
It appears that the safeguard risk obtained while using CIS Control 12.11 is much lower than the
safeguard risk modeled by the option to use CIS Control 12.6. And because the vendor already
supports multi-factor authentication, the solution is almost already configured. The organization
chooses to use CIS Control 12.11 as their risk treatment control to protect their diary device
controllers against malware until the vendor provides a more robust solution.
Version 1.0 – April 2018 83
The risk assessor will need to use their professional judgment to design and recommend
information security safeguards, and to evaluate prospectively the risk that they may pose.
Information security experts may need to be included in the process to ensure that the risk
analysis is conducted appropriately.
Risk Treatment Recommendations Summary
Risk treatment recommendations are a critical part of risk assessments to be sure that the
organization has developed a plan for addressing risks without creating other risks to the
organization or its constituents. Some of the benefits that have been demonstrated about this
process are:
1. Organizations can demonstrate to collaborating business managers how recommended
security safeguards can be implemented without creating too much of a burden on the
business mission and objectives.
2. Organizations can demonstrate to regulators and other legal authorities that safeguards
are reasonable because the safeguard risk of the safeguard (the “burden” to the
organization) is not greater than the risk that it is meant to reduce.
3. Organizations can demonstrate that recommended safeguards would be appropriate by
showing that they would not foreseeably create an impact that would be intolerable to the
organization or its constituents.
4. Organizations may find it valuable to evaluate multiple safeguards in case one safeguard
is more reasonable (creates an even lower risk) than another safeguard.
5. Risk assessors will find that their colleagues will understand and appreciate risks and
controls when risk assessors and subject matter experts collaborate on evaluating risk,
and planning safeguards.
The process for evaluating risks and for recommending appropriate risk treatments has been
demonstrated at a general level. However, some questions likely remain for the reader for
evaluating safeguards, estimating likelihood, and the suitability of probability models in risk
analysis. These more detailed topics will be discussed in the chapter “Risk Analysis Techniques.”
Exercise:
The reader should use the template Risk Register – Tier 2 that is provided in the
supplementary document CIS_RAM_Workbook to enter risk treatment recommendations for
each risk that evaluated as unacceptably high.
The reader should consider:
1. Whether an existing safeguard can be improved, and how that would be done.
2. Whether a safeguard based on a different CIS Control would provide reasonable and
appropriate risk.
3. Collaborating with information security subject matter experts to help model the
potential effectiveness of recommended safeguards.
Version 1.0 – April 2018 84
Chapter 4: Threat-Based Risk Assessment
Instructions for Tiers 3 and 4 Organizations
Tiers 3 and Tier 4 risk assessment instructions are well-suited to organizations that fit the profile
of Tier 3 and Tier 4 organizations as described by the NIST Cybersecurity Framework. These
organizations can be identified as having the following characteristics:
• NIST Tier: Tiers 3 and Tier 4 organizations. Tiers 3 and Tier 4 materials are best suited
for organizations that are using risk-based criteria for enterprise-wide policies and
processes.
• Expertise: The organization has resources and capabilities to analyze security threats,
and to plan risk-appropriate safeguards, including the on-hand skills to model how threats
would operate within their organization.
• Time: The organization is able to invest time to analyze risks at the level of specific
systems, devices, and applications within the context of specific threats.
This chapter is comprised of sections that each address a specific activity within a risk
assessment. Readers should engage this chapter by first reading the text in each section, and
then conducting the exercises that are recommended for each section. The material presented in
the CIS RAM is substantially different from many other risk assessment standards and models,
so the reader should first understand the aim of each section, and then practice what they learn
using templates that are provided in the supplementary document CIS_RAM_Workbook.
While conducting their first CIS RAM-based risk assessment, organizations should be careful to
not try to “boil the ocean.” Regulatory bodies and information security standards alike understand
that not all risks can be identified in a single assessment. Organizations should continuously and
regularly assess risks to identify, understand, and manage risks over time.
The Risk Assessment Project
Overview
Risk assessments are projects with clear steps for preparing, conducting, and reporting risk
analysis. And while risk assessment projects can be modeled with a project plan, each
organization’s project approach will vary depending on factors such as resource availability, and
will develop over time as organizations become more capable in their cybersecurity maturity. This
section will describe a basic risk assessment project, its components and variations, and will
present guidance for preparing the project plan.
How and When to Use Threat-Based Risk Analysis
The threat-based risk analysis that is described in this chapter requires considerably more effort
and expertise than the analysis methods used by Tier 1 and Tier 2 organizations. This is primarily
due an analysis step – attack path modeling – that precedes the risk assessment.
Attack path modeling provides organizations with valuable insight into information security risks
by analyzing how their information assets would respond to known attack scenarios.
For example, if an organization wants to understand their susceptibility to a trojan that exfiltrates
data from a specific database, they would map out plausible scenarios for how a trojan would
enter their environment, would be installed on a workstation, would gain privileges to the
database, would access data in the database, and would then send the stolen data to a target
system. The attack path model identifies these steps, and lists the information assets that would
Version 1.0 – April 2018 85
be included in that attack. This results in a listing of information assets and threats that would
compromise them. Risk assessors would then base their risk analysis on that list of assets and
threats.
This chapter will demonstrate how threat-based risk analysis offers useful insight into information
security risks, but the reader can understand how a comprehensive risk assessment using this
approach could be time-consuming.
Organizations that are beginning to practice threat-based risk analysis may want to answer
specific risk questions, rather than to plan an entire risk assessment based on its thorough
analysis. Some examples uses may be:
1. After having completed a risk assessment using the approach described for Tier 2
organizations, the risk assessor may want to understand how well-prepared information
assets are for preventing specific, current threats.
2. The accuracy of a specific asset’s risk score is being questioned because personnel
believe that the asset is well-protected by layers of security.
3. The comprehensiveness of a recent risk assessment is in question because interested
parties believe some asset vulnerabilities were well not thought out.
4. While planning risk remediation, management wonders whether resolving the risk for one
information asset will have a cascading and beneficial effect on a set of other assets.
For these scenarios and others like them, threat-based risk analysis can help organizations
evaluate risk within the context of a chain of events without having to apply such deep scrutiny to
every asset in the risk assessment scope.
Risk Assessment Project Management Project Outline
Risk assessments are projects that require planning, identification of assets and asset owners,
scheduling of sessions, and data gathering. CIS RAM provides detailed instruction for these
project management and planning steps in the chapters for Tier 1 and Tier 2 organizations that
may benefit from these tactical instructions.
Given the expected maturity of organizations Tier 3 and Tier 4 organizations, these instructions
will not be provided in this chapter. However, the reader may benefit from reviewing those
materials in those chapters before continuing with Chapter 4.
The supplementary document CIS_RAM_Workbook provides templates for project scheduling
and scoping Tier 3 and Tier 4 organizations, if needed.
Defining Risk Assessment Criteria
Introduction
Risk assessment criteria are the numerical and plain-language statements that an organization
uses to evaluate their cybersecurity risk. The most familiar form of risk calculations, “Risk =
Likelihood x Impact,” is the basis for risk analysis in the CIS RAM. But it is just the starting point
for risk analysis.
Risk assessment criteria must be meaningful to the organizations that use them, so they must be
tied to the potential benefit and harm that the organization may create. The impact of a
cybersecurity breach may harm the organization itself, it may harm the organization’s ability to
successfully achieve its mission, or it may harm others.
Because cybersecurity failures impact parties both inside and outside an organization, risk
assessment criteria must be universally meaningful and must address the interests of all
potentially affected parties. Additionally, risk assessment criteria must demonstrate to authorities,
Version 1.0 – April 2018 86
such as regulators and litigators, that the organization considers the risk of harm to others as
much as the risk of harm to themselves.
While these requirements may seem complex, the method presented in this section will
sufficiently address them while using a technique that is simple to develop and use.
Risk Assessment Criteria Foundations
The risk analysis provided in the CIS RAM is at its root a question of balance between the
potential of future harm against the certain burden of a safeguard. Regulators and litigators have
long considered this balance as key to acting as a “reasonable person.” The core structure of a
risk statement is provided below to illustrate the core concept of balance.
Figure 16 - Balance Within Core Risk Analysis
Notice a few things right away with the model risk analysis in Figure 16.
• While organizations typically evaluate the observed risk to determine whether they should
address or accept it, this risk statement deliberately compares the observed risk to a
proposed safeguard.
• The criteria that evaluates the risk also evaluates the safeguard.
• The impact of the risk estimates the potential of harm to the organization and the
potential harm against others.
Risk assessors compare risks to their proposed safeguards to determine whether those
safeguards would create a foreseeably lower risk than the current state. To accomplish this, the
assessor evaluates the current state risk (or “observed risk”) and the proposed safeguard using
the same criteria to ensure comparability.
This comparison prevents organizations from implementing safeguards that are overly
burdensome, or that create new, unacceptable risks. For example, an organization that uses
software that is no longer supported by the vendor, but relies on that software for critical business
purposes, should find alternative methods for identifying and controlling potential security risks
until they replace the software. If management recommends quickly changing out to inferior, but
secure software, the organization may suffer a greater impact to their mission than the security
risk they are trying to avoid.
While considering CIS Control 18: Application Software Security, a risk statement can estimate
the foreseeability of an impactful threat. The risk can be stated as it appears in Table 55 (where
the risk score ‘12’ is a product of the likelihood ‘3’ and the highest impact score ‘4’):
Version 1.0 – April 2018 87
Table 55 - Example Core Risk Statement
Observed risk Likelihood Impact to Impact to
Us Others
Risk
Score
Hackers may exploit the unsupported,
but critical application.
3 3 4 12
A risk assessor should then recommend and evaluate a safeguard to reduce the high security
risk, as illustrated in Table 56. Here, the organization would realize that the likelihood of a
negative impact to their mission is greater than the current state risk. This is an obvious case of
the burden being greater than the risk, and a recommended safeguard being unreasonable.
Table 56 - Example Unreasonable Proposed Safeguard
Proposed
Safeguard
New Risk Likelihood Impact to
Us
Impact to
Others
Safeguard
Risk
Replace application
with inferior,
secure application.
Application will
operate
inefficiently.
5 3 1 15
When faced with this analysis, the organization must then find another way to address the risk.
This process will be described later in this chapter in the section Risk Treatment
Recommendations.
But what should be apparent is that without a definition of risk assessment criteria the likelihood
and impact scores are not meaningful. What would impacts or likelihoods of ‘1’, ‘2’, ‘3’, ‘4’, or ‘5’
mean, anyway? The organization will need to create definitions for their likelihood and impact
scores so that they are meaningful to all interested parties, and so that they provide a consistent
method for risk evaluation.
Impact Definitions
Tier 3 and Tier 4 organizations generally benefit from more business involvement in managing
cybersecurity risk than Tier 1 organizations. Because of that increased involvement, the risk
assessment criteria can be – and should be – more explicit and detailed than those used by Tier
1 organizations. Advanced organizations can consider more nuance in terms of business impacts
and tolerance, and can employ organizational objectives with more authority.
An impact definition for Tier 3 and Tier 4 organizations can look like the one depicted in Table 57.
Version 1.0 – April 2018 88
Table 57 – Example Impact Definitions
Impact
Score
Impact to Mission
Mission: Provide information to
help remote patients stay
healthy.
Impact to
Objectives
Objectives: Operate
profitably.
Impact to Obligations
Obligations: Patients must not
be harmed by compromised
information.
1 Patients continue to access
helpful information, and
outcomes are on track.
Profits are on target. Patients do not experience
loss of service or protection.
2 Some patients may not get all
the information they need as
they request it.
Profits are off target,
but are within
planned variance.
Patients may be concerned,
but not harmed.
3 Some patients cannot access
the information they need to
maintain good health
outcomes.
Profits are off
planned variance and
may take a fiscal
year to recover.
Some patients may be
harmed financially or
reputationally after
compromise of information or
services.
4 Many patients consistently
cannot access beneficial
information.
Profits may take
more than a fiscal
year to recover.
Many patients may be
harmed financially or
reputationally
5 We can no longer provide
helpful information to remote
patients.
The organization
cannot operate
profitably.
Some patients may be
harmed financially,
reputationally, or physically,
up to and including death.
Tier 3 and Tier 4 organizations that previously used Tier 1 risk analysis processes may build on
their simpler risk assessment criteria that used three levels of impact scoring. For the purposes of
reference to our example organization – a health information provider – they have gone through a
year or two of risk management, have gained the attention and confidence of business managers
and executives. As a result, their ability to assess cybersecurity risk using business criteria will
also improve.
Background – Impact Definitions
This document provides instructions for defining impacts and impact scores (magnitudes) in
this section with more in-depth instructions and examples in the “Risk Analysis Techniques”
chapter. The reader should understand before going further that organizations in most cases
should not define impacts exclusively using financial values. While cost is a common and
almost necessary consideration while evaluating risks and safeguards, if it is the only criterion,
the organization will communicate to their personnel, as well as to interested parties and
authorities, that cost is their only concern. The purpose that the organization serves and the
harm that may befall others must be part of the evaluation if risk is to be responsibly tied to the
potential of harm, and if the evaluation is to be understandable to regulators and legal
authorities.
Organizations should also consider having more than three impact types in their impact
definitions if they have more than one mission, multiple objectives, and many obligations that
they need to consider in their risk analysis. While this expansion may create an increasingly
wide risk register, it can help organizations feel comfortable all relevant interests were
considered in their risk analysis.
Version 1.0 – April 2018 89
We can see by comparing the risk assessment criteria for Tier 1 organizations in Chapter 2 to
Table 57 that the detailed descriptions of impacts have increased in two dimensions; the number
of impact score options increased from three to five, and there is an additional impact definition
for business objectives.
Tier 3 and Tier 4 organizations will find that using a range of five scores increases the utility of
risk prioritization at the end of the risk assessment. A three-by-three risk assessment criteria
model provides organizations with six possible risk scores; 1, 2, 3, 4, 6, and 9. This leads to a
somewhat course grouping that may cause risks of somewhat different urgencies to be
indistinguishable.
A five-by-five risk assessment criteria model allows for 14 possible risk scores of; 1, 2, 3, 4, 5, 6,
8, 9, 10, 12, 15, 16, 20, and 25. Now risks of somewhat different urgencies will likely be classified
into different risk scores and will be more easily distinguished while prioritizing them.
Also note that the impact scores of ‘1’ and ‘2’ in Table 57 are shaded grey to separate them from
the higher scores. Scores ‘1’ and ‘2’ describe impact magnitudes that would be generally thought
of as acceptable. The risk acceptance criteria process will be explained later in the document, but
it is useful to consider now that the scores ‘1’ and ‘2’ are consistent in their definition of impact
magnitudes, and that the impact scores of ‘3’, ‘4’, or ‘5’ could consistently be thought of as
unacceptably high.
When the example health information provider graduates from using their Tier 1 instructions, that
also have a new impact type to consider. Table 57 uses an impact type for business objectives to
be considered in the organization’s risk analysis. Business objectives are more self-focused than
missions and obligations, and are aligned with success criteria commonly found in business.
Some examples include profitability, growth, maintaining accreditations, customer satisfaction, or
retaining a position in the marketplace.
Objectives align most directly with what is commonly thought of as the “cost” of a safeguard. But
rather than allowing an organization to arbitrarily decide that a safeguard costs too much, this
method of including cost in terms of impacts to objectives forces the organization to evaluate why
a cost would be excessive. Does the cost of the safeguard impede profitability goals? Does the
safeguard limit efficiency or growth? Those are certainly reasonable concerns, as long as the
profitability goals are in parity with the mission and obligations impacts. In other words, an
organization should not let profitability be more important than harm to others, or harm to their
ability to fulfill their mission.
See “Note Regarding Use of Financial Costs as Objectives” in Chapter 5.
Figure 17 - Objectives, Mission, Obligations
Organizations are well-served with this model because business management, technicians,
compliance personnel, and legal counsel all have their interests addressed in risk analysis that
uses these criteria.
Objectives
• Self benefit
• Self risk
Mission
• Mutual benefit
• Mutual risk
Obligations
• Others' benefit
• Others' risk
Version 1.0 – April 2018 90
An in-depth explanation of how to develop impact definitions with multiple examples is provided in
the chapter “Risk Analysis Techniques.”
Likelihood Definitions
The likelihood definition for a Tier 3 and Tier 4 organization should also increase in nuance from
the simpler Tier 1 definition, and can do so by adding two more scores to the table as shown in
Table 58.
Table 58 – Example Likelihood Definitions
Likelihood
Score
Foreseeability
1 Not foreseeable. This is not plausible in the environment.
2 Foreseeable. This is plausible, but not expected.
3 Expected. We are certain this will eventually occur.
4 Common. This happens repeatedly.
5 Current. This may be happening now.
• “Not Foreseeable” implies that a threat is not plausible in the environment that is being
assessed. Loss of portable media may not be foreseeable during a risk assessment of a
hosted application.
• “Foreseeable” implies something that is plausible, but the organization would be
surprised if it occurred. A founding executive taking copies of sensitive data to
competitors may be considered foreseeable, even if it is not expected.
• “Expected” implies a threat that is not common, but that would eventually happen.
Phishing attacks or other social engineering attacks may be expected in many
environments.
• “Common” implies something that happens repeatedly, such as mis-addressed emails
with sensitive information, malware attacks, or loss of laptops and mobile devices.
• “Current” implies threats that are rarely not present, such as port scanning on perimeter
devices, or sharing of information in quasi-public spaces such as pharmacy counters or
bank tellers.
When risk assessors estimate the likelihood of a threat, they will select scores ‘1’, 2’, ‘3’, ‘4’, or ‘5’
using the foreseeability definition as their guidance. Organizations may add time-based limits in
their foreseeability definitions (i.e. “Foreseeable within planning thresholds,” “Expected within the
five-year plan” or “Not foreseeable in the next fiscal year”). If organizations do introduce time
limits in their likelihood definitions they should prioritize risk treatment investments to meet these
timelines. That may be excessively challenging to many organizations, so they should proceed
with caution.
Developing the Risk Assessment Criteria
Because risk assessment criteria are meant to describe risk as it applies to the organization that
owns the risk, it is appropriate for the most senior management who are responsible for the
mission, objectives, and obligations to participate in developing and accepting the criteria.
Table 59 lists roles commonly involved in risk assessment criteria development, and the
interested perspective they bring to the definition effort.
Version 1.0 – April 2018 91
Table 59 - Roles Involved in Defining Risk Assessment Criteria
Role Perspective
Chief Executive Officer
Chief Operations Officer
To ensure that the mission, objectives, and obligations of the
organization are appropriately defined, and to ensure that a
distinction between acceptable and unacceptable impacts are
appropriately delineated.
Chief Compliance Officer To ensure that the interests of regulatory agencies are
appropriately included in risk definitions.
Chief Financial Officer To ensure that objectives are appropriately defined, particularly
the distinction between acceptable and unacceptable impacts.
Chief Information Officer
Chief Technology Officer
To ensure that technical performance, service, and capabilities
are considered, and to include all types of information processes
beyond technology.
General Counsel
Outside Counsel
To ensure that obligations are appropriately defined and that they
compare well with the mission and objectives.
Internal Audit
Audit Committee
To ensure that the concerns of interested parties are well
represented in all impact definitions and scores.
Key Customers / Clients
Key Constituents
To ensure that their interests are included in the obligations
definition.
The risk assessor will need to use their professional judgment to define impact types, and to
describe levels of impact that the organization must manage to. Because risk assessment criteria
are a declaration by the organization of what they will manage to in terms of harm to themselves
and harm to others, organizations should consult with legal counsel before finalizing these criteria
and making risk decisions based on them.
Exercise:
The reader may develop their organization’s risk assessment criteria using the “Criteria - Tier
3 & 4” worksheet that is provided in the supplementary document CIS_RAM_Workbook.
The reader should consider:
1. Developing the risk assessment criteria in collaboration with a business managers
and legal counsel to ensure that the Mission, Objectives, and Obligations definitions
are sensible to the organization.
2. Working with legal counsel to help ensure that impact definitions appropriately
address the interests of all potentially affected parties, and to ensure that impact
statements appear equitable to all parties.
3. Referring to guidance for defining and scoring impact types in the “Risk Analysis
Techniques” chapter.
Version 1.0 – April 2018 92
Defining Risk Acceptance Criteria
Introduction
Because risk assessments are essentially questions of balance, the criteria for accepting risk
should help determine whether balance was achieved. In CIS RAM risk acceptance has two
components:
• Appropriate risk: That the likelihood of an impact must be acceptable to all foreseeably
affected parties
• Reasonable risk: That the risk posed by a safeguard must be less than or equal to the
risk it protects against.
While these components have been demonstrated briefly above, the first component will be
described in more detail in this section. The second component will be described later in the Risk
Treatment Recommendations section further on.
After establishing the impact and likelihood definitions, Tier 3 and Tier 4 organizations are now
well positioned to state their risk acceptance criteria. Recall that impacts were defined within
scores that ranged from ‘1’ to ‘5’. Acceptable impact scores ‘1’ and ‘2’ were defined in a manner
that would appear appropriate to interested parties (and are shaded grey to indicate their
acceptability), and the impact score ‘3’ was the lowest unacceptable score.
Table 60 – Example Impact Definitions
Impact
Score
Impact to Mission
Mission: Provide information to
help remote patients stay
healthy.
Impact to
Objectives
Objective: Operate
profitably.
Impact to Obligations
Obligations: Patients must not
be harmed by compromised
information.
1 Patients continue to access
helpful information, and
outcomes are on track.
Profits are on target. Patients do not experience
loss of service or protection.
2 Some patients may not get all
the information they need as
they request it.
Profits are off target,
but are within
planned variance.
Patients may be concerned,
but not harmed.
3 Some patients cannot access
the information they need to
maintain good health
outcomes.
Profits are off
planned variance and
may take a fiscal
year to recover.
Some patients may be
harmed financially or
reputationally after
compromise of information or
services.
4 Many patients consistently
cannot access beneficial
information.
Profits may take
more than a fiscal
year to recover.
Many patients may be
harmed financially or
reputationally
5 We can no longer provide
helpful information to remote
patients.
The organization
cannot operate
profitably.
Some patients may be
harmed financially,
reputationally, or physically,
up to and including death.
And similarly, likelihood scores were within a range of ‘1’ to ‘5’ as below. Once our example
organization develops their risk management maturity and are ready to refine their risk
distinctions, they may decide to not tolerate unacceptable impacts if they are foreseeable but not
expected (‘2’), or if they are expected to occur (’3’). This would be a decision best made by their
executives, and especially their compliance team, general counsel, and interested parties. But in
this case, the model will assume that they selected a threshold score of ‘3’.
Version 1.0 – April 2018 93
Table 61 – Example Likelihood Definitions
Likelihood
Score
Foreseeability
1 Not foreseeable. This is not plausible in the environment.
2 Foreseeable. This is plausible, but not expected.
3 Expected. We are certain this will eventually occur.
4 Common. This happens repeatedly.
5 Current. This may be happening now.
So Tier 3 and Tier 4 organizations would define their risk acceptance like this:
Table 62 - Risk acceptance criteria
Impact
Threshold x
Likelihood
Threshold =
Risk
Threshold
3 x 3 = 9
… therefore …
Acceptable Risk < 9
An example of the heat map for this assessment criteria is shown below. Note that this heat map
is defined not just by numbers and colors, but now by a set of criteria that address business
issues and a duty of care to protect others.
Figure 18 - Example Heat Map
Impact
Li
ke
lih
oo
d
1 2 3 4 5
5
4
3
2
1
Version 1.0 – April 2018 94
The risk assessor will need to use their professional judgment to identify levels of acceptable risk.
Because risk acceptance criteria are a declaration by the organization of what they will tolerate in
terms of harm to themselves and harm to others, organizations should consult with legal counsel
before finalizing these criteria and making risk decisions based on them.
As organizations assess their risk using CIS Controls V7 (modeled in the following section) they
will be able to automatically determine whether the risk evaluates as acceptable or not without
needing to consider the question differently in each case. A simple estimation of the likelihood
and impact will automatically determine how the organization should prioritize each risk, and
whether the organization can safely accept the risk as a “reasonable” option.
A Threat-Based Risk Assessment Process
Introduction
Tier 3 and Tier 4 organizations benefit from collaboration with business management. They also
have refined knowledge of how cyberattacks work. And due to their contact with outside parties
have considerably more data about on-the-ground effectiveness of their security safeguards.
Because Tier 3 and Tier 4 organizations have these advantages, their ability to analyze and
respond to risk should be more refined than their peers with less maturity.
The risk analysis method described in this section is based on an “attack path” model. An attack
path, sometimes called a “kill chain,” is the route that an attack takes to compromise information
assets. For example, ransomware attacks involve many attack stages, starting from the hacker’s
reconnaissance, through preparation and delivery of exploits, initial compromise, privilege abuse,
through to the final control of the targeted storage volume and data.
And while not all attacks are planned (some are automated, drive-by attacks, and some are
accidental) they can be modeled in an attack path to understand what chain of safeguards would
fail in order for a threat to successfully compromise an asset.
The attack path for the ransomware example above would start with the attacker targeting an
organization that would likely pay a ransom to access their critical information. They would
research key personnel in the organization to refine their target, and then would develop an
exploit for that personnel. They may place the exploit on an Internet server that is accessible to
the victim, and would craft an email message for the victim that links to the exploit. When the
victim interacts with the email message, they would download the ransomware which then would
run on their computer. The attacker could then use the ransomware to encrypt the hard drive, and
depending on the variation of ransomware, either lock the information, or copy it to an Internet
server that the attacker controls.
Exercise:
The reader should define their organization’s risk acceptance criteria using the “Criteria – Tier
3 & 4” worksheet that is provided in the supplementary document CIS_RAM_Workbook.
The reader should consider:
1. Working with a business management sponsor who can help ensure that the risk
acceptance criteria are sensible to the organization.
2. Working with legal counsel to help ensure that the definition for risk acceptance
addresses the interests of all potentially affected parties, and to ensure that impact
statements appear equitable to all parties.
Version 1.0 – April 2018 95
This attack path can be drawn to include a set of information assets that the organization could
control, and that would be exploited in the attack, such as; information about their employees and
their jobs, email servers, email clients, firewalls, content filters, proxy servers, malware protection
appliances and software, operating systems, hard drives, and yes, people.
Figure 19 - Example Attack Path and Information Assets
Using the risk analysis steps that were previously described for Tier 1 and Tier 2 organizations, a
risk assessor can use risk analysis to determine how well prepared each information asset is for
preventing or detecting specific attacks as they are in play.
This “attack path” approach to risk analysis requires a preliminary analysis step before working in
the risk register. That analysis step – attack path modeling – documents the lifecycle of an attack,
and identifies information assets or asset classes that would be involved in the attack. The
information developed in this preliminary analysis provides the risk assessor with a list of
information assets that would be involved in a type of attack, and allows the assessor to evaluate
the risks they face based on how well their safeguards align with the CIS Controls.
This section will describe and work through a Tier 3 and Tier 4 organization’s attack path analysis
and risk register using the CIS Controls to model risk-appropriate safeguards. The risk register
and attack path model worksheet described in this section are available as templates in the
supplementary document CIS_RAM_Workbook.
The Risk Register
The Tier 3 and Tier 4 organization’s risk register is much like the layout of the risk registers
shown in Tier 1 and Tier 2 instructions, but establishes attack path models and threats as the
basis for analysis. This section will demonstrate the risk assessment processes for Tier 3 and
Tier 4 organizations using the risk register template provided in the supplementary document
CIS_RAM_Workbook for Tier 3 and Tier 4 organizations.
The layout map of a risk register for a Tier 3 and Tier 4 organization is depicted in Figure 20.
Version 1.0 – April 2018 96
Figure 20 - Risk Register Layout Map
The risk register for Tier 3 and Tier 4 organizations is a listing of identified risks and their
recommended risk treatments, also known as “safeguards.” Each row represents one risk and its
risk treatment recommendation. The parts of the risk register are:
A. The column headers and guiding text to help the reader or risk assessor understand the
information that is contained in the column.
B. Attack models and threats that are actions within an attack path.
C. The information assets within the attack path that are being analyzed.
D. The CIS Controls text that helps the risk assessor consider controls that should be in
place to protect information assets in the context of the attack path.
E. How the organization implements the CIS Control (if they do) to protect the information
asset, and any vulnerabilities that would allow the threat to compromise the asset.
F. The risk evaluation, including the likelihood that the threat would succeed, the impacts to
the mission, objectives, and obligations if it did, and the resulting risk score.
G. The recommended implementation of CIS Controls that would reduce risks to an
acceptable level, and the safeguard risk calculation to estimate the risk of that
recommendation.
Attack Path Models
The Tier 3 and Tier 4 organization will develop a set of attack path models to document the
detailed steps that foreseeable attacks would follow, and to identify the information assets that
would be involved in that attack path. This helps the risk assessor evaluate risks based on how
foreseeable threats behave. Attack path modeling allows risk assessors to ask questions such as,
“How well positioned are we against this type of attack,” “Am I thinking of threats to assets the
way an attacker would?” and “Is my risk evaluation for this asset based on the likelihood and
impact of other information assets that would be involved in the attack?”
The attack path models worksheet that risk assessors will use to design attack paths is built upon
the CIS Community Attack Model, a document provided by CIS® that associates CIS Controls
with the stages of cybersecurity planning, detection, and defense. This section will demonstrate
the process for modeling attack paths that assessors will use to analyze risks in the Tier 3 and
Tier 4 organization’s risk register. A template and examples of this process is provided in the
supplementary document CIS_RAM_Workbook.
Version 1.0 – April 2018 97
The attack path models worksheet is depicted in Figure 21.
Figure 21 - Attack Path Models
The attack path models worksheet is made up of two main parts; the Community Attack Model at
the top, and the attack path models at the bottom. The Community Attack Model above depicts
the stages of an attack as they relate to CIS Controls that could prevent or detect each stage.
The attack path models below list types of information security incidents that may occur, and
identify what actions and information assets would be involved in each stage of the incident.
The Process
The risk assessor will start their assessment by modeling attack paths in the attack path model
worksheet. The worksheet will result in a set of attack path models (one row per model), and will
state the actions and assets that may be involved in each attack.
The risk assessor will then use the risk register to analyze each attack path (one stage in the
attack path per row in the risk register). The assessor will evaluate each stage of an attack path
just as they would analyze each risk in Tier 1 and Tier 2 assessments.
Tier 3 and Tier 4 organizations may wish to start their risk analysis by first analyzing risks using
the processes described for Tier 1 or Tier 2 organizations, then by examining specific threats on
an attack path basis. This ensures that all in-scope information assets and all CIS Controls will be
addressed in the risk register, along with the more specific and detailed risks that are analyzed
using this threat-based process.
Community Attack Model
Attack Path Model
Version 1.0 – April 2018 98
Figure 22 - Risk Analysis Process for Tier 3 and Tier 4 organizations
The risk assessment process for Tier 3 and Tier 4 organizations ensures that information assets
are analyzed in terms of the risk they pose when multi-phase attacks occur in the environment.
This threat-based analysis is accomplished by following the steps listed below:
1. Using the Attack Path Model worksheet, the risk assessor creates a new row in the
worksheet to name a type of cybersecurity attack or security incident, such as “Data
seizure through web application,” or “Mis-delivery of patient information.”
2. The risk assessor then moves right across the new row to describe each stage of the
attack or incident. The description would include an affected information asset, and how
the attack would compromise the asset at each stage.
3. The risk assessor can then refer to each cell across an attack path row to populate a risk
register. The risk assessor can copy the attack path model name, threats, and
information assets that are in each attack path model row to the risk register, with one
row per model / threat / asset grouping.
4. While considering the controls that should be addressed in each row of the risk register,
the risk assessor should refer to the Community Attack Model grid at the top of the Attack
Path Model worksheet to determine which controls should be in place to detect or prevent
the threat.
5. The risk assessor will then review the CIS Controls listed in each risk register row, and
will gather evidence for how well each asset is protected by safeguards that are
associated with the CIS Control.
a. Evidence may be in the form of interviews, a review of configurations, or a review
of records and logs.
6. The risk assessor will then describe how the control is applied to the information asset or
asset class in the “Current Control” cell of that row.
7. Next, the assessor will consider the difference between the CIS Control and the currently
applied safeguard to determine whether there is a deficiency in how the control is
currently deployed and operating. If the current safeguard is not implemented as
described or in a way that is likely deficient against the threat, then the assessor will state
this as a vulnerability.
a. Risk assessors should consider the objective of the CIS Control as they analyze
risks. For example, CIS Control 16.11 states “Automatically lock workstation
sessions after a standard period of inactivity.” The control’s objective is to
prevent unauthorized people from using unattended user sessions. If the current
control does not meet the objective, then the assessor should state the gap as a
vulnerability in the vulnerability cell, such as: “Unattended workstations may be
used by personnel who are not authorized access to those systems, or to
applications that are assigned to the absent user.”
8. Now consider the threat that could occur because of the vulnerability.
Version 1.0 – April 2018 99
a. The above vulnerability could be paired with this threat: “Malicious personnel
may abuse the privileges of authorized users and may execute unauthorized
transactions or data downloads.”
9. Next, estimate the likelihood that the threat would succeed, and the impact it may create.
a. Likelihood estimation can be difficult, but the risk assessment criteria was
developed to provide some guidance in that estimation process. Guidance is
provided in the Methods for Evaluating Likelihood section of the “Risk Analysis
Techniques” chapter later in the document
b. Impact scores should provide estimates of the impact that such a threat would
create. Consider the likelihood and impact scores as a pair. In other words,
“What is the likelihood that this impact would result?” Examples below will
provide further guidance.
10. The risk score will be automatically computed in the risk register by multiplying the
likelihood score by the highest of the three impact scores.
Tier 3 and Tier 4 Risk Assessment Example 1 – Ransomware at Email Servers
The Tier 3 and Tier 4 organization has expressed their concern about ransomware and wants to
know what their exposure is to it. They want to know what they are doing now to prevent
ransomware and what other investments they need to make in order to be appropriately
protected. Additionally, the organization is concerned about two web application vulnerabilities,
one that would allow data seizure, and the other that will allow arbitrary code execution through
vulnerable sites.19
The risk assessor knows to consider each of these concerns as attack path models, and sets out
to document each one.
By using the Attack Path Model worksheet, the risk assessor creates a row titled, “Ransomware”
and begins documenting the attack path as shown in Table 63. The table is shown in a vertical
format for ease of display in this document, but is in horizontal format in the template provided in
CIS_RAM_Workbook.
Each stage of an attack path model is described using the Community Attack Model format. For
each stage in the model the risk assessor will describe how the attack will compromise an
information asset.
19 This document will only explore how the first attack path model will be defined and risk
assessed. However, the other two scenarios are provided in the Attack Path Model worksheet as
further examples of the attack path modeling process.
Version 1.0 – April 2018 100
Table 63 - Attack Path Model (Ransomware)
Attack Path Stage Attack Path Action
Attack Path Model Ransomware
Initial Recon
Hackers determine who in the organization has access to
sensitive information.
Asset: Public information and social media sites that
describe personnel and responsibilities.
Acquire/Develop Tools
Moderately skilled hackers may develop phishing email
and ransomware exploits that target selected personnel.
Asset: Out of our control.
Delivery
Hacker sends phishing email to selected personnel.
Asset: Email server, SMTP gateway.
Initial Compromise
Personnel open phishing email and trigger an install of
the ransomware payload.
Asset: Email client, end-user OS, personnel, proxy
server.
Misuse/Escalate Privilege
Malware encrypts the local storage volume.
Asset: End-user OS, storage volume.
Internal Recon Not applicable
Lateral Movement Not applicable
Establish Persistence See Misuse/Escalate Privilege.
Execute Mission Objectives
Hackers require payment for release of information back
to us.
Asset: Cash or data.
As a result of this detailed description of the attack path, the risk assessor can now itemize each
of these stages in the risk register as the basis of their risk analysis. So they create a set of rows
in their risk register that include the information as displayed in the partial risk register shown in
Table 64 and provided more fully in CIS_RAM_Workbook.
Version 1.0 – April 2018 101
Table 64 - Partial Risk Register with Attack Path Model
Attack Path
Model
Threat Information Asset
Ransomware Initial Recon: Hackers determine
who in the organization has
access to sensitive information.
Public information and social media
sites that describe personnel and
responsibilities.
Ransomware Delivery: Hacker sends phishing
email to selected personnel.
Email server, SMTP gateway.
Ransomware Initial Compromise: Personnel
open phishing email and trigger
an install of the ransomware
payload.
Email client
Ransomware Initial Compromise: Personnel
open phishing email and trigger
an installation of the ransomware
payload.
End-user OS
Ransomware Initial Compromise: Personnel
open phishing email and trigger
an install of the ransomware
payload.
Personnel
Ransomware Initial Compromise: Personnel
open phishing email and trigger
an install of the ransomware
payload.
Proxy server
Ransomware Misuse/Escalate Privilege:
Malware encrypts the local
storage volume.
End-user OS
Ransomware Misuse/Escalate Privilege:
Malware encrypts the local
storage volume.
Storage volume
Ransomware Execute Mission Objectives:
Hackers require payment for
release of information back to us.
Cash or data
Each row in this risk register establishes a relationship between the attack path model (in this
case, “Ransomware”), a threat that could occur at each stage of the ransomware attack, and the
information asset or asset class it would occur on. Note that items labeled “Not applicable” and
“Not in our control” in Table 63 are not provided rows in the partial risk register in Table 64. This
is because there is little the organization can do to address these steps in the attack path for the
ransomware scenario.
Also note that many information assets and many kinds of threats can be considered within an
attack path. The risk assessor must determine the amount of detail and variety of asset/threat
pairings they intend to include in their assessment. Attack path modeling can take significant
time. Because of this, risk assessors will need to consider the amount of time and resources they
have available to conduct their analysis, and must select a degree of detail based on that
Version 1.0 – April 2018 102
availability. Starting with obvious assets and threats for the first assessment may be enough,
knowing that in subsequent assessments more variety can be added to the model.
As a result of this analysis, the organization scours the Internet for mentions of privileged
personnel and their roles. They remove as much sensitive information from those sites as they
can. They realize that there are other ways to target privileged personnel, but this is considered a
prudent step.
The first risk that the assessor analyzes in this attack path is the use of the email server and
SMTP gateway that may receive and relay a phishing message to a targeted end-user. The
organization believes they have good safeguards to manage this risk, but they check the
Community Attack Model to be sure.
Figure 23 - CIS Control Selection from Community Attack Model
This risk was identified in the attack path model in Table 63 in the “delivery’ stage, so while
assessing the risk the risk assessor will review the email server and SMTP gateway because of
their delivery role in the attack, and will name them as assets in the risk register, as shown in
Table 64. As the assessor references the Community Attack Model, they will look at the
intersection between the Delivery column and the Protect row to find “Continuous vulnerability
assessment,” “firewall,” “mail gateway filtering,” “web filtering,” “secure remote access,” and
“NIPS (network intrusion prevention system).”
Considering the threat of email targeting specific users, and the organization’s use of email
filtering and sandboxing on their corporate server, the risk assessor reviews sub-controls under
CIS Control 7 “Email and Web Browser Protections.” Among those sub-controls the risk assessor
considers CIS Control 7.8 “Implement DMARC and Enable Receiver-Side Verification” and CIS
Control 7.10 “Sandbox all Email Attachments.” They know that DMARC controls related to CIS
Control 7.8 rely on more community cooperation before they can be reliable, and even then could
be by-passed by determined attackers. They also know that determined attackers can get past
Version 1.0 – April 2018 103
the organization’s email sandboxing technologies. They forego analyzing this risk because they
also use anti-malware on their email server and SMTP gateway, which appears one row down
the Delivery column in the Detect row.
The risk assessor decides to analyze the risk involved with their anti-malware email module by
referring to CIS Control 8.1, as described in Table 65.
Table 65 - Example Risk Analysis for Email Server in a Ransomware Attack Path Model
Attack Path Model Ransomware
Threat Hackers may target personnel using their personal email accounts,
thus bypassing the corporate email server.
Information Asset Email server and SMTP gateway
CIS Control 8.1
Description Utilize centrally managed anti-malware software to continuously
monitor and defend each of the organization's workstations and
servers.
Control Advanced malware detection and prevention operates within the
SMTP gateway. It detects and quarantines attachments and
hyperlinks associated with malicious files and suspicious or
blocked URLs.
Vulnerability End-users may be victims of phishing over personal email services
that they can access from offices and on work computers.
Threat Likelihood
Mission Impact
Objectives Impact
Obligations Impact
Risk Score
Risk Acceptability
Note that the assessor has not yet evaluated this risk. Rather, the risk assessor will evaluate
each risk in the attack path after considering how that set of risks affect each other. For our
example attack path model in Table 63, all nine risks will be written out before each one is
evaluated. This is done to ensure that the likelihood and impact of each risk is based on a
foreseeable scenario, and not in isolation of each asset which may cause some risks to be
estimated arbitrarily high or low.
Working further down the attack path model in Table 63, the organization next considers the risk
they may suffer at desktop email clients which are targeted during the Initial Compromise in this
ransomware attack path. After considering the vulnerability in the previous risk analysis that end-
users may still receive phishing messages through their personal email accounts, email client
risks are fresh in the risk assessor’s mind. The risk assessor reviews the Community Attack
Model in Figure 24 to identify CIS Controls that intersect between Initial Compromise and Protect
and they see that for this stage anti-malware and CIS Control 8.1 is again an appropriate control
to include in their evaluation. They describe the risk associated with their implementation of CIS
Control 8.1 at desktop email clients in Table 66.
Version 1.0 – April 2018 104
Figure 24 - CIS Control Selection from Community Attack Model
Table 66 - Example Risk Analysis for Email Client in a Ransomware Attack Path Model
Attack Path Model Ransomware
Threat Personnel open phishing email and trigger an installation of
ransomware payload. Email may be received through personal
email accounts.
Information Asset Email client
CIS Control 8.1
Description Utilize centrally managed anti-malware software to continuously
monitor and defend each of the organization's workstations and
servers.
Control Signature-based anti-virus on each desktop. Anti-virus filters
suspicious web URLs using a dictionary that is updated monthly.
Vulnerability Advanced malware prevention is not included in endpoint
protection applications on end-user workstations (other than URL
filtering). End-users may be victims of phishing over personal email
services that they can access from offices and on work computers.
Threat Likelihood
Mission Impact
Objectives Impact
Obligations Impact
Risk Score
Risk Acceptability
Version 1.0 – April 2018 105
This risk may evaluate as unacceptably high when the whole attack path is considered.
Moreover, this risk appears to be independent of the first risk involving the email server and
SMTP gateway. As robust as the corporate SMTP server may be at preventing ransomware
phishing, the assessor is concerned that the risk of ransomware phishing may still be
unacceptably high because the SMTP gateway only protects corporate email accounts, not
personal email accounts hosted by other services.
The risk assessor named a proxy server as an information asset at the “initial compromise” stage
in the attack path model in Table 63 because their proxy server blocks outbound requests for
known-bad IP addresses and domains, including known malware hosts. So the risk assessor
again references the Community Attack model, looking at the Initial Compromise column and
sees that the “web filtering” function of the proxy server is not in that column. Moreover, the
organization is not using the remaining controls in the Protect and Detect rows of that column, so
they cannot refer to those controls in their “Current Controls” column.
The Community Attack Model, while being very helpful to organizations that model attack paths,
is a working document that will constantly develop as threat behaviors change, and as controls
change to meet new challenges. In the case of this organization, they identify the role of a proxy
server (a web filtering tool) for Protecting against the Initial Compromise of a malware attack. The
proxy server prevents the malware from downloading payload from a known-bad web resource.
But because the Community Attack Model does not reference web filtering in the intersection of
Protect and Initial Compromise, the organization adds that control to that cell. They have
identified a case for using web filtering for disrupting ransomware and should record it for future
use.
The risk assessor decides to evaluate the risk associated with the proxy server to see if they may
help reduce the risk appropriately. The assessor models the risk in Table 67.
Table 67 - Example Risk Analysis for Proxy Server in a Ransomware Attack Path Model
Attack Path Model Ransomware
Threat Personnel open phishing email and trigger an installation of the
ransomware payload. Email may be received through personal
email accounts.
Information Asset Proxy server
CIS Control 7.4
Description Enforce network-based URL filters that limit a system's ability to
connect to websites not approved by the organization. This filtering
shall be enforced for each of the organization's systems, whether
they are physically at an organization's facilities or not.
Control All Internet traffic for systems within corporate LANs and DMZ have
URLs filtered against a subscription service that blocks sessions
with known-bad hosts, and blocks URLs not categorized as safe by
that service.
Vulnerability Laptops and mobile devices bypass the proxy server when used
outside of the corporate network. Ransomware may attack systems
when they are out of the corporate network.
Threat Likelihood
Mission Impact
Version 1.0 – April 2018 106
Attack Path Model Ransomware
Objectives Impact
Obligations Impact
Risk Score
Risk Acceptability
The risk assessor sees that the proxy server appears more robust than the end-point protection
at end-user systems, but it still has shortcomings. The proxy server is not able to enforce URL
blocking on systems that are not on the corporate network when a ransomware phishing attack
occurs.
While all nine risks in the attack path would be evaluated as a set for the actual risk assessment,
this section will evaluate the three example risks to demonstrate the group evaluation process.
The remainder of the risks are fully evaluated in the worksheet “Risk Register – Tier 3 & 4” in the
CIS_RAM_Workbook.
Recall the definitions for the impact and likelihood scores that the Tier 2, and Tier 3 and Tier 4
organizations created. The impact scores are shown in Table 68.
Table 68 – Example Impact Definitions
Impact
Score
Impact to Mission
Provide information to help
remote patients stay healthy.
Impact to
Objectives
Operate profitably.
Impact to Obligations
Patients may be harmed if
information is compromised.
1 Patients continue to access
helpful information, and
outcomes are on track.
Profits are on target. Patients do not experience
loss of service or protection.
2 Some patients may not get all
the information they need as
they request it.
Profits are off target,
but are within
planned variance.
Patients may be concerned,
but not harmed.
3 Some patients cannot access
the information they need to
maintain good health
outcomes.
Profits are off
planned variance and
may take a fiscal
year to recover.
Some patients may be
harmed financially or
reputationally after
compromise of information or
services.
4 Many patients consistently
cannot access beneficial
information.
Profits may take
more than a fiscal
year to recover.
Many patients may be
harmed financially or
reputationally
5 We can no longer provide
helpful information to remote
patients.
The organization
cannot operate
profitably.
Some patients may be
harmed financially,
reputationally, or physically,
up to and including death.
Likelihoods were similarly defined with five potential scores, as shown in Table 69.
Table 69 – Example Likelihood Definitions
Likelihood
Score Foreseeability
1 Not foreseeable. This is not plausible in the environment.
2 Foreseeable. This is plausible, but not expected.
Version 1.0 – April 2018 107
Likelihood
Score Foreseeability
3 Expected. We are certain this will eventually occur.
4 Common. This happens repeatedly.
5 Current. This may be happening now.
The organization will now go back and review the risks associated with the ransomware attack
path to estimate the likelihood and impact of each threat, but in consideration of the other
ransomware risks.
The risk assessor will review those risks side-by-side in the abbreviated table below.
Table 70 – Comparative Risks in a Ransomware Attack Path Model
Attack Path
Model
Ransomware
Information
Asset
Email Server Email Client Proxy Server
Threat Hackers may target personnel
using their personal email
accounts, thus bypassing the
corporate email server.
Personnel open phishing email
and trigger an installation of
ransomware payload. Email
may be received through
personal email accounts.
Personnel open phishing email
and trigger an installation of the
ransomware payload. Email
may be received through
personal email accounts.
CIS Control 8.1 8.1 7.4
Description Utilize centrally managed anti-
malware software to
continuously monitor and
defend each of the
organization's workstations
and servers.
Utilize centrally managed anti-
malware software to
continuously monitor and
defend each of the
organization's workstations
and servers.
Enforce network-based URL
filters that limit a system's ability
to connect to websites not
approved by the organization.
This filtering shall be enforced
for each of the organization's
systems, whether they are
physically at an organization's
facilities or not.
Control Advanced malware detection
and prevention operates within
the SMTP gateway. It detects
and quarantines attachments
and hyperlinks associated with
malicious files and suspicious
or blocked URLs.
Signature-based anti-virus on
each desktop. Filtering of
suspicious web URLs using a
dictionary that is updated
monthly.
All Internet traffic for systems
within corporate LANs and DMZ
have URLs filtered against a
subscription service that blocks
sessions with known-bad hosts,
and blocks URLs not
categorized as safe by that
service.
Vulnerability End-users may be victims of
phishing over personal email
services that they can access
from offices and on work
computers.
Advanced malware prevention
is not included in endpoint
protection applications on end-
user workstations (other than
URL filtering). End-users may
be victims of phishing over
personal email services that
they can access from offices
and on work computers.
Laptops and mobile devices
bypass the proxy server when
used outside of the LAN.
Ransomware may attack
systems when they are out of
the office LAN.
Threat
Likelihood
2 3 3
Mission
Impact
3 3 3
Objectives
Impact
4 4 4
Version 1.0 – April 2018 108
Attack Path
Model
Ransomware
Obligations
Impact
4 4 4
Risk Score 8 12 12
Risk
Acceptability
Acceptable Unacceptable Unacceptable
After evaluating each of the risks in the attack path model, the risk assessor (and by extension,
their organization) is comfortable with the ability of the SMTP gateway to protect users from
ransomware phishing attacks that pass through the corporate email server. But they are less
comfortable with the risk of those attacks coming in from personal email accounts while end-
users use their laptops away from the office. The risk analyses for the email client and proxy
server are identical in this case and are shown in Table 71.
Table 71 - Example Risk Estimation
Threat
Likelihood
Mission
Impact
Objectives
Impact
Obligations
Impact
Risk Score
3 3 4 4 12
The risk score is the product of the likelihood score and the higher of the three impact scores,
which in this case is ‘3 x 4 = 12’.
Also recall that the risk acceptance criteria for the Tier 3 and Tier 4 organization looks like this:
Table 72 - Risk acceptance criteria
Impact
Threshold x
Likelihood
Threshold =
Risk
Threshold
3 x 3 = 9
… therefore …
Acceptable Risk < 9
An acceptable risk would be one that evaluates to anything below ‘9’. But the risk of ransomware
is as high as ‘12’ and is therefore unacceptable.
By analyzing additional risks in the ransomware attack path, such as protections at the end-user’s
operating system or storage volume, the organization may further mitigate these three risks by
other safeguards, such as timely and reliable data backups, or logical controls that prevent
sensitive data from being accessed by laptops. But what is known is that in terms of ransomware,
there is a continuing risk to the organization that has not been resolved by the SMTP gateway
and proxy server.
Version 1.0 – April 2018 109
Exercise:
The reader should refer to the template Risk Register – Tier 2 that is provided in the
supplementary document CIS_RAM_Workbook. They may use the risk register template to
enter a set of risks that are associated with the attack path models, CIS Controls, and
information assets that are in scope of their assessment.
While doing this exercise, the reader should consider:
1. That threat-based analysis requires considerable effort and may be implausible as a
method for conducting a complete, comprehensive risk assessment.
2. Conducting threat-based analysis within a risk register that was completed using a
Tier 1 or Tier 2 approach. Threat-based analysis can be used to answer specific risk
questions, such as:
a. How realistic is a specific risk score that appears to exaggerate or downplay a
stand-alone risk?
b. Are there risks we have not already considered in our environment?
c. How well positioned are we to protect ourselves against a specific threat?
d. What is the most effective investment we can make to reduce a single risk
that would only be realized within a threat path?
3. Not “boiling the ocean.” Not all assets can be practically evaluated against all
applicable CIS Controls in a single assessment. Prioritize evaluating threats that
appear more likely than others, due to past experience or other research.
4. Whether a control or information asset requires examination to understand its actual
configuration and effectiveness.
5. Whether the organization can tolerate the amount of effort and time that the risk
assessment requires.
a. The organization should use high-level analysis (review of policies and
interviews) if they do not have extensive time and resources.
b. Information assets should be tested and examined in more detail as time
allows.
c. The organization should plan recurring risk assessments to identify more risks
over time.
6. Collaborating with information security experts to help model threats that are
foreseeable in the environment, and to help evaluate the effectiveness of current
safeguards.
The risk assessor will need to use their professional judgment to select the controls and
information assets and to model threats that should be analyzed in the risk assessment.
Information security experts may need to be included in the process to ensure that the risk
analysis is conducted appropriately.
Version 1.0 – April 2018 110
Tier 3 Risk Assessment Summary
After having analyzed a set of risks against a single information asset, the Tier 2 organization
realizes the advantages of gaining a more comprehensive view of its risks:
1. Modeling threats through attack paths enables Tier 3 and Tier 4 organizations to evaluate
cybersecurity risks more comprehensively than by viewing information assets individually.
2. The risk involved at one asset will influence the risk of other assets, which is a more
realistic picture of risk within a networked environment.
3. Because attack paths are aligned with the Community Attack Model, risk assessors are
assisted by the CIS community in identifying the CIS Controls that are best suited for
preventing and detecting attacks at various stages and assets in the attack path.
After evaluating the risks against information assets we have identified many that were
unacceptably high and that should be provided with recommended safeguards to reduce their
risk. We will walk through and illustrate this process in the Risk Treatment Recommendations
section below.
Risk Treatment Recommendations
Introduction
Organizations often think of security safeguards as obstacles to business and productivity.
Safeguards often cause personnel to take extra steps to get access to systems or information, or
to get approval for normal business activities. Safeguards require investments in time and money,
which compete with other priorities. And if they become too disruptive to an organization’s
mission and objectives, security safeguards can become disliked and avoided.
In fact, disruptive safeguards often cause personnel to work around them just to get their jobs
done, which creates more risk.
But risk treatment recommendations can and should result in safeguards that are demonstrably
reasonable. And while obtaining a clear definition for “reasonable safeguards” has been a
challenge in the legal, regulatory, and information security communities, the CIS RAM provides a
practical solution. Risk assessors evaluate risk treatment recommendations to determine whether
a security safeguard is reasonable by; comparing the safeguard to the risk it is meant to reduce,
and by comparing the safeguard to the risk acceptance criteria.
Risk treatment recommendations are simple to evaluate once the risk assessment criteria and
initial risk analysis have been established. The process occurs over the following steps:
1. While examining an unacceptably high risk, review the CIS Control that corresponds with
the risk and recommend a feasible way for the organization to implement or improve that
control.
2. If that control is not feasible in the near-term, recommend other CIS Controls related to
the risk that can be used to reduce it.
3. Evaluate the risk of the recommended safeguard to understand the burden it would pose
to the organization. Then compare that safeguard risk to the risk acceptance criteria to
determine whether it is appropriate.
4. Also compare the evaluated risk of the recommended safeguard to the observed risk to
determine whether the safeguard is reasonable (safeguards with lower risk scores than
the observed risk are reasonable.)
5. Sort the risks by their risk score to prioritize the risks and risk treatments that the
organization will invest in.
This section demonstrates these steps in detail by describing the process, then by modeling risk
treatments for the unacceptably high risks that were evaluated in previous sections.
Version 1.0 – April 2018 111
The reader should review the definitions of ‘reasonable’ and ‘appropriate’ that are provided in the
glossary. These terms will be used regularly in this section and have distinct meanings.
1. Appropriate: A condition in which risks to information assets will not foreseeably create
harm that is greater than the organization or its constituents can tolerate.
2. Reasonable: A condition in which safeguards will not create a burden to the organization
that is greater than the risk it is meant to protect against.
Risk Treatment Objectives
The objective of well-formed risk treatment recommendations is to create a prioritized list of
information security safeguards that would provide appropriate protections while not posing too
great a burden on the organization’s purpose.
The risk treatment recommendation exercises that are demonstrated in this section examine the
unacceptable risks that were illustrated earlier in the document and will select CIS Controls that
would reduce those risks to a degree that is both reasonable (not overly burdensome) and
appropriate (not unacceptably harmful).
Recommending Risk Treatment Safeguards from CIS Controls V7
As we examine unacceptably high risks, we will recommend safeguards that are based on CIS
Controls V7. But some of the safeguards that an organization is prepared to implement and
operate may not be implemented exactly as described in CIS Controls V7. This process takes
into account how to select controls that address risks, and how to determine whether they are
designed in a way that makes sense in context of both the risk, and the potential burden to the
organization.
Recall the relationship between analyzed risks and their recommended risk treatments in Figure
25.
Figure 25 - Balance Within Core Risk Analysis
A risk and its proposed safeguard are both evaluated using the same criteria. If a proposed
safeguard has a higher risk (its “safeguard risk”) than the risk acceptance criteria, then it’s not
appropriate. If the safeguard has a higher score than the observed risk, then it’s not reasonable.
The exercises in this section will focus on matching completed risk analyses (in blue) with newly
recommended safeguards (in green).
Version 1.0 – April 2018 112
The Tier 3 and Tier 4 organization identified two unacceptable risks by modeling a ransomware
attack path over several information assets. The first of these unacceptable risks involved email
clients that personnel use to access personal email, and how that exposed the organization to
ransomware phishing attacks. The risk is shown again in Table 73.
Table 73 - Example Risk Analysis for Email Client in a Ransomware Attack Path Model
Risk Analysis Value
Threat Personnel open phishing email and trigger an installation of
ransomware payload. Email may be received through personal
email accounts.
Information Asset Email client
CIS Control 8.1
Description Utilize centrally managed anti-malware software to continuously
monitor and defend each of the organization's workstations and
servers.
Control Signature-based anti-virus on each desktop. Filtering of suspicious
web URLs using a dictionary that is updated monthly.
Vulnerability Advanced malware prevention is not included in endpoint
protection applications on end-user workstations (other than URL
filtering). End-users may be victims of phishing over personal email
services that they can access while working from home using work
computers.
Threat Likelihood 3
Background – How Realistic Are Safeguard Risk Estimates?
Critical readers will question how the organization and their risk assessor will know whether
their safeguard risk estimations are realistic. After all, how can they know prospectively what
their risk would be in such a situation?
There are two important items to keep in mind while gaining comfort with this practice;
understanding the legal and regulatory expectations for risk management, and information
security standards for evaluating safeguards after they’ve been implemented.
Law and Regulation: Laws and regulations generally expect risk analysis to evaluate
safeguards that are required for achieving compliance, and expect that the risk analysis is
performed by appropriately skilled and informed people. These analyses do not guarantee
security that is sufficient against any threat, but they do provide a plan toward improved
security and compliance that is prioritized by the likelihood of harm, and that has no intolerable
harm as its goal.
Information Security Risk Management Standards: Information security risk assessment
standards that the CIS RAM is based on operate within fuller risk management programs and
cycles. ISO 27005 operates within the ISO 27000 family of standards, and NIST 800-30 works
within the NIST Special Publications. Each of these families of standards requires continuous
analysis of security safeguards, including analysis of controls after they’ve been implemented
to determine whether they are effective at addressing their security objectives. Recommended
safeguards should therefore be risk assessed again after implementation to be sure that they
achieve their intended objectives.
Version 1.0 – April 2018 113
Risk Analysis Value
Mission Impact 3
Objectives Impact 4
Obligations Impact 2
Risk Score 12
Risk Acceptability Not Acceptable
But because this risk was identified while evaluating an attack path, the organization considers
the recommended safeguards in that same context. They compare this risk with the other
unacceptable risks in the attack path in Table 74 to determine whether one safeguard would
address both risks in the attack. Both risks have the same risk score, but for different reasons:
Laptops are not protected against advanced malware through the end-point protection software,
and laptops do not benefit from the proxy server while out of the office.
They can either add advanced malware protection to their endpoints, or they can extend the
proxy server to the DMZ and force laptops to resolve network queries through that proxy server
while out of the office.
So they model these options below.
Note: The risk assessor will record how they will address their risk by stating either “Accept,”
“Reduce,” “Transfer,” or “Avoid.” Accepting and reducing risks will be intuitive to the reader. An
organization may transfer a risk by contracting a third party that may handle the risk better, or by
acquiring an insurance policy against the risk. The organization may also avoid the risk by no
longer engaging in the processes, or handling the information assets that cause the risk
Table 74 – Comparative Risks in a Ransomware Attack Path Model
Attack Path
Model
Ransomware
Information Asset Email Client Proxy Server
Threat Personnel open phishing email and trigger an
installation of ransomware payload. Email
may be received through personal email
accounts.
Personnel open phishing email and trigger an
installation of the ransomware payload. Email
may be received through personal email
accounts.
CIS Control 8.1 7.6
Description Utilize centrally managed anti-malware
software to continuously monitor and defend
each of the organization's workstations and
servers.
Enforce network-based URL filters that limit a
system's ability to connect to websites not
approved by the organization. This filtering
shall be enforced for each of the organization's
systems, whether they are physically at an
organization's facilities or not.
Control Signature-based anti-virus on each desktop.
Filtering of suspicious web URLs using a
dictionary that is updated monthly.
All Internet traffic for systems within corporate
LANs and DMZ have URLs filtered against a
subscription service that blocks sessions with
known-bad hosts, and blocks URLs not
categorized as safe by that service.
Vulnerability Advanced malware prevention is not included
in endpoint protection applications on end-
user workstations (other than URL filtering).
End-users may be victims of phishing over
personal email services that they can access
from offices and on work computers.
Laptops and mobile devices bypass the proxy
server when used outside of the LAN.
Ransomware may attack systems when they
are out of the office LAN.
Version 1.0 – April 2018 114
Attack Path
Model
Ransomware
Threat Likelihood 3 3
Mission Impact 3 3
Objectives Impact 4 4
Obligations
Impact
4 4
Risk Score 12 12
Risk
Acceptability
Unacceptable Unacceptable
Risk Treatment
Option
Reduce Reduce
Recommended
Safeguard
Add advanced malware protection module to
end-point protection.
Extend proxy server to the DMZ and force
laptops to use it as a gateway.
Safeguard Risk Unexpected cost would be within the budget
plan threshold if modules are restricted to
laptops this year, and extended to remaining
system next year.
Threat of malware would no longer be
expected. No impact to our mission.
Laptops that use personal VPNs may bypass
the proxy service.
If the proxy service is unavailable, it may cause
users to not use Internet resources while
working out of the office.
Proxy servers are not able to detect local
attacks on systems.
Safeguard Threat
Likelihood
2 3
Safeguard
Mission Impact
1 2
Safeguard
Objectives Impact
2 2
Safeguard
Obligations
Impact
1 4
Safeguard Risk
Score
4 12
Safeguard Risk
Acceptability
Acceptable Unacceptable
The Tier 3 and Tier 4 organization now has the information it needs to determine and document
why their recommended safeguard is to add advanced malware prevention at their laptops first,
then desktops in the following fiscal year. Desktops will be covered well by the proxy server when
operated in their permanent home – the office network.
Version 1.0 – April 2018 115
The risk assessor will need to use their professional judgment to design and recommend
information security safeguards, and to evaluate prospectively the risk that they may pose.
Information security experts may need to be included in the process to ensure that the risk
analysis is conducted appropriately.
Risk Treatment Recommendations Summary
Risk treatment recommendations are a critical part of risk assessment to be sure that the
organization has developed a plan for addressing risks without creating other risks to the
organization or its constituents. Some of the benefits that have been demonstrates about this
process are:
1. Organizations can demonstrate to collaborating business managers how recommended
security safeguards can be implemented without taxing the business purpose by
evaluating the risk of the safeguards against the mission and objectives of the
organization.
2. Organizations can demonstrate to regulators and other legal authorities that safeguards
are reasonable because the expected risk of the safeguard (the “burden” to the
organization) is not greater than the risk that it reduces.
3. Organizations can demonstrate that recommended safeguards would be “appropriate” by
showing that they would not foreseeably create an impact that would be intolerable to the
organization or its constituents.
4. Recommended risk treatments can be considered in terms of the attack path for Tier 3
and Tier 4 organizations. As the maturity of an organization’s security capabilities grows,
so does the sophistication and perhaps efficiency of their risk treatment
recommendations.
The process for evaluating risks and for recommending appropriate risk treatments has been
demonstrated at a general level. However, some questions likely remain for the reader for
evaluating safeguards, estimating likelihood, and the suitability of probability models in risk
analysis. These more detailed topics are presented in the next chapter.
Exercise:
The reader should use the template “Risk Register – Tiers 3 or 4” that is provided in the
supplementary document CIS_RAM_Workbook to enter risk treatment recommendations for
each risk that evaluated as unacceptably high.
The reader should consider:
1. Whether an existing safeguard can be improved, and how that would be done.
2. Whether a safeguard based on a different CIS Control would provide reasonable and
appropriate risk.
3. Collaborating with information security subject matter experts to help model the
potential effectiveness of recommended safeguards.
Version 1.0 – April 2018 116
Chapter 5: Risk Analysis Techniques
The instructions, examples, and templates described in this section are best understood through
experience. The reader will benefit from using the examples that are provided in the
supplementary document CIS_RAM_Workbook to best understand the instructions in this
chapter.
Risk Analysis Techniques
Introduction
The example risk assessment processes described in this document are broadly applicable to
many cases and environments. However, there are many reasons why an organization will
modify the processes and templates that are provided in the CIS RAM.
Methods for estimating likelihood or probability, assessing safeguards and policies, considering
risks of non-technical safeguards, and determining which risks to assess or to ignore all present
opportunities for customizing risk assessments to specific environments.
This section describes several customization methods for analyzing risks that organizations may
consider as part of their cybersecurity risk assessments.
Defining Impacts for Tier 1 organizations
Perhaps the most important early step in the risk assessment is to develop effective impact
definitions. The CIS RAM is based on Duty of Care Risk Analysis principles to enable
organizations to make conscientious evaluations of their current and intended risk. A risk
assessment that results from the CIS RAM should show whether information security safeguards
are appropriate to the public, while being reasonable to the organization. The core of this analysis
is the impact definitions, and the balance and consensus that they are meant to establish.
This section will provide guidance for defining impact types effectively.
Table 75 – Summary Evaluation of Impact Definition
Benefits Limits
- Consistent method to evaluate risk
impacts.
- Satisfies “cost-benefit” analysis that
regulators use.
- Satisfies “duty of care balance test”
that courts rely on.
- Balances business interests with
public interest.
- Poorly defined impact definitions can
frustrate risk assessors.
- Poorly “balanced” impact definitions
may not reduce legal liabilities.
The primary purpose of impact definitions is to provide risk assessors with a consistent method
for scoring risks that is fair to all potentially affected parties. A risk evaluation should demonstrate
as much concern for the organization as it does for others.
To make this possible, impact definitions should be designed with the concept of balance firmly in
mind.
Recall the impact definitions used for Tier 1 organizations shown in Figure 26. Two columns
address the interests of the organization’s purpose and the parties who may be effected by
Version 1.0 – April 2018 117
information security risk. Each of these columns is considered an “impact type.” The “Impact to
Our Mission” column addresses the main purpose for the two parties to enjoin in the risk … the
beneficial reason for customers and the organization to share information. The safety of the
organization’s patient customers is considered in the “Impact to Obligations” column.
Figure 26 - Example Impact Definitions
Now consider the impact scores, and the red boundary that separates score ‘1’ from scores ‘2’
and ‘3’. This boundary marks the division between impacts that would presumably be acceptable
to all parties, and those that would not be.
Consider how impacts for score ‘1’ would appear to the organization, patient customers, and legal
authorities. The organization using this impact definition is stating that they would accept impacts
from threats if they result in conditions similar to how score ‘1’ is defined. This would indicate that;
patients would continually be able to access the information they needed, and patients would not
be foreseeably harmed as a result of a threat.
Then consider how impacts for score ‘2’ are defined. Threats that would foreseeably result in an
impact score of ‘2’ could mean that some patients who cannot access information may not
maintain good health outcomes. That scenario is clearly an unacceptable impact to the
organization’s mission, and would not make it worthwhile for patients to entrust their information
with that organization. The impact score of ‘2’ for obligations would be unacceptable because
some of the patient customers could foreseeably be harmed financially or reputationally as a
result of an incident – presumably because of identity theft or a system outage.
All of these features of an impact definition make it effective for estimating risk in a way that is
equitable to all potentially affected parties, and even for driving consensus within the organization
that uses it. After all, the interests and purpose of the organization are addressed as well as the
interests of the public.
Organizations can build effective impact definitions by thoughtfully defining their impact areas,
and then by carefully defining their impact scores.
Defining Impact Areas
The CIS RAM describes two impact areas that should be included in a Tier 1 organization’s risk
evaluation; Impact to Mission and Impact to Obligations. Each of these impact areas address the
interests of people or organizations who may be affected by information security risk. They each
play a significant and unique role in analyzing risk, and should be defined within those roles, as
described below.
Version 1.0 – April 2018 118
Defining Mission
Definition: An organization’s mission is the value it provides others, and that requires that they
engage in risk together to achieve that value. A college educates its students, but students must
give personal and financial information to those colleges in order to receive the education.
Retailers provide products to customers, but in many cases customers turn over their financial
information to those organizations to receive those products. Cloud service providers offer
Internet-based functionality to business customers, but those customers must turn over business
process or operations to those services as a result. So “mission” is a way of asking, “What’s in it
for the others?” who engage in risk with the organization.
Example Mission Definitions should have the following characteristics:
• Concisely state the benefit the organization provides that encourages others to enjoin
them in information security risk.
• Convey a simple fact that can be observed and measured.
• Describe something that the organization already manages to, and that personnel will
recognize as important to the organization.
Example 1: A custom manufacturer uses their customers’ intellectual property to quickly make
components that are perfect upon delivery. Their mission definition may be, “To provide
customers with products that meet their unique specifications, without fail.” The message is
simple, it can be measured, and the organization likely recognizes this as something that they
manage to. Moreover, the definition can be useful when a risk assessor tries to determine what
core values may be harmed is a risk were to occur, or if a safeguard is too burdensome to the
mission. If the risk assessor recommends a control that prevents customers from sending their
intellectual capital, or that prevents the manufacturer from storing it or sharing it among drafter
and engineers, then the mission would clearly be negatively impacted.
Example 2: A community bank states their mission as, “We promote opportunities to households
and small businesses by providing affordable financial products and advisory services.” They
could say that their mission is to lend and borrow money, but they are thinking ahead to what they
do not want to compromise about that mission, and that is to serve their community. But again,
they have a concise definition that states why others would enjoin in risk with them, that states a
simple, observable, and measurable fact, and that would be familiar to personnel who work at the
bank.
Example 3: A telecommunications company is heavily relied upon to provide communication
services that are now considered fundamental to a functioning society. Additionally, they carry
tremendous amounts of private information about their customers, often at considerable
perceived risk by the public. But consumers subscribe to these services for considerable benefit.
The telecommunications company defines their mission this way, “To instantaneously and
transparently connect our customers with the people, organizations, information, and
communication platforms that they care about.” This mission definition is less concise, but it may
be as concise as they could get, considering the complexity of typical telecommunications
services. The definition is measurable, and it would very likely be recognizable by their personnel
as an important value.
Defining Obligations
Definition: An organization’s obligations, at least in terms of information security, are to prevent
foreseeable harm that may come to others as a result of an information security compromise.
These types of harm are commonly associated with identify theft, theft of funds, or lost services
Version 1.0 – April 2018 119
and data. But it is critical to keep in mind that obligations should explicitly state the harm that may
come to others so that risk assessors, management, and interested parties know that the
organization is careful to protect others from harm. So “obligations” are a way of asking, “What
foreseeable harm could come to others that we should prevent?”
A Good Obligations Definition should have the following characteristics:
• Concisely state the organization’s intent to prevent harm that information security
incidents may cause others.
• Convey a simple fact that can be observed and measured.
• Describe something that the organization already manages to, and that personnel will
recognize as important to the organization.
Example 1: The custom manufacturer is concerned about the harm that their customers may
suffer if their intellectual capital – their product designs – are leaked to the public and to the
customers’ competitors. Their customers often provide specifications for components that would
reveal secrets about new products. The manufacturer states their obligations this way, “Our
customers’ intellectual property must be kept confidential to preserve their market advantage.”
The definition is concise, it states a foreseeable harm to others that must be guarded against, t
could be measured, and personnel would know that protection of customers’ intellectual property
is important.
Example 2: The community bank knows that their customers are in a particularly vulnerable
position. They are often taking on risk while buying homes or starting businesses, and have less
room for error. A missed paycheck or even slight misuse of financial information could mean the
difference between success and failure for them. So the community bank uses this as their
obligations definition, “We must protect our customers’ reputation and financial future against
misuse of their financial or personal information.” Again, this definition is concise, it is
measurable, and it would be known and recognized by the bank’s personnel.
Example 3: The telecommunications company is a complex organization that can imagine
multiple kinds of harm that could result from an information security compromise. An organization
with many obligations (or missions or objectives) may state them in their definitions. For example,
the telecommunications company realizes that they may foreseeably breach personal
communications about their customers, and their communication services may fail when critical
applications depend on them. They will state two obligations, “We must protect our customers’
communications records to prevent reputational or financial harm. We must meet our service
level agreements with customers to prevent harm that may result from unreliable connectivity.”
As an example, the top row of the impact definitions for the manufacturer would start to take
shape as in the table below.
Table 76 - Impact Area Definitions Example (Partial)
Impact to Our Mission
Impact to Obligations
To provide customers with products that meet
their unique specifications, without fail.
Our customers’ intellectual property must be
kept confidential to preserve their market
advantage.
Version 1.0 – April 2018 120
Defining Impact Scores
After defining impact areas, the organization will need to define impact scores for each impact
area. Each score (‘1’ through ‘3’) will have one definition per impact area, as shown in Figure 26.
There are a few principles that organizations should consider as they define their risk scores.
Consider the scores as having the following meanings:
Table 77 - Impact Scoring Guidance
Impact
Score Guidance
1 An impact that would be acceptable to the mission, objectives, and obligations. An
impact would be noticeable, but is likely unavoidable even after significant investment
in controls. It would be considered tolerable by all affected parties.
2 An impact that would be considered unacceptable by any party. While the impact may
be recoverable through additional efforts, investment, or time, the organization could
have reduced the risk of that impact with security controls.
3 The impact would be catastrophic. The mission, objectives, and/or obligations would
no longer be feasible.
Score ‘1’ is shaded to indicate that these impacts should be defined in a way that would be
acceptable to all parties.
As impact score definitions are written, the organization should think through how impacts to their
mission and obligations would appear at each of these levels.
The manufacturer’s impact score definitions are shown below to illustrate the point.
Table 78 - Example Impact Score Definitions
Impact Score Impact to Our Mission Impact to Obligations
Defined
To provide customers with products
that meet their unique specifications,
without fail.
Our customers’ intellectual property
must be kept confidential to preserve
their market advantage.
1
Occasional orders cannot be fulfilled.
Information about jobs may be
known, but nothing that can harm
customers' market position.
2
Products are delivered outside of
spec and customers believe that we
cannot produce custom products
without fail.
A single customer experiences
market repercussions based on a
security incident.
3
We can no longer produce reliable,
custom products.
Customers can no longer expect
confidentiality protection when
working with us.
When reading an impact definition horizontally across one score, note that the impact definition in
each impact area are equally harmful to all parties. This is a critically important feature of Duty of
Care risk analysis. It ensures that risk analysis is equitable. No party’s harm is considered more
or less tolerable than any other party’s harm. What’s acceptable to one equates to what is
Version 1.0 – April 2018 121
acceptable to all (the shaded score ‘1’). What is catastrophic to one equates to what would be
catastrophic to all.
Example impact definitions for all three example organizations are provided in the supplementary
document CIS_RAM_Workbook in the tab “Example Impact Definitions” to assist the reader’s
comfort and familiarity with this subject.
Defining Impacts for Tier 2, Tier 3, and Tier 4 organizations
Perhaps the most important early step in the risk assessment is to develop effective impact
definitions. The CIS RAM is based on Duty of Care Risk Analysis principles to enable
organizations to make conscientious evaluations of their current and intended risk. A risk
assessment that results from the CIS RAM should show whether information security safeguards
are appropriate to the public, while being reasonable to the organization. The core of this analysis
is the impact definitions, and the balance and consensus that they are meant to establish.
This section will provide guidance for defining impact types effectively.
Table 79 – Summary Evaluation of Impact Definition
Benefits Limits
- Consistent method to evaluate risk
impacts.
- Satisfies “cost-benefit” analysis that
regulators use.
- Satisfies “duty of care balance test”
that courts rely on.
- Balances business interests with
public interest.
- Poorly defined impact definitions can
frustrate risk assessors.
- Poorly “balanced” impact definitions
may not reduce legal liabilities.
The primary purpose of impact definitions is to provide risk assessors with a consistent method
for scoring risks that is fair to all potentially affected parties. A risk evaluation should demonstrate
as much concern for the organization as it does for others.
To make this possible, impact definitions should be designed with the concept of balance firmly in
mind.
Recall the impact definitions used for Tier 2, Tier 3 and Tier 4 organizations shown in Figure 27.
Three columns address the interests of the parties who may be effected by information security
risk. Each of these columns is considered an “impact type.” The organization itself is considered
by evaluating the potential impacts to their ability to succeed in the “Impact to Objectives” column.
The safety of the organization’s patient customers is considered in the “Impact to Obligations”
column. And the “Impact to Mission” column addresses the main purpose for the two parties to
enjoin in the risk … the beneficial reason for customers and the organization to share information.
Version 1.0 – April 2018 122
Figure 27 - Example Impact Definitions
Now consider the impact scores, and the red boundary that separates scores ‘1’ and ‘2’ from
scores ‘3’, ‘4’, and ‘5’. This boundary marks the division between impacts that would presumably
be acceptable to all parties, and those that would not be.
Consider how impacts for scores ‘1’ and ‘2’ would appear to the organization, patient customers,
and legal authorities. The organization using this impact definition is stating that they would
accept impacts from threats if they result in conditions similar to how scores ‘1’ and ‘2’ are
defined. Threats that are scored with an impact as high as ‘2’ would indicate that; not all patients
would receive the information they needed, profits would be off-target, but within planned
variance, and patients would be concerned about a security incident, but would not suffer harm.
Then consider how impacts for scores of ‘3’ are defined. Threats that would foreseeably result in
an impact score of ‘3’ could mean that some patients who cannot access information may not
maintain good health outcomes. That scenario is clearly an unacceptable impact to the
organization’s mission, and would not make it worthwhile for patients to entrust their information
with that organization. In terms of the objectives, the organization’s profitability would be off-plan
and would require a fiscal year to recover. Again, this is unacceptable and should be invested
against so the scenario is avoided. And finally, the impact score of ‘3’ for obligations would be
unacceptable because some of the patient customers could foreseeably be harmed financially or
reputationally as a result of an incident – presumably because of identity theft.
All of these features of an impact definition make it effective for estimating risk in a way that is
equitable to all potentially affected parties, and even for driving consensus within the organization
that uses it. After all, the interests and purpose of the organization are addressed as well as the
interests of the public.
Organizations can build effective impact definitions by thoughtfully defining their impact areas,
and then by carefully defining their impact scores.
Defining Impact Areas
The CIS RAM describes three impact areas that should be included in risk evaluation; Impact to
Mission, Impact to Objectives, and Impact to Obligations. Each of these impact areas address the
interests of people or organizations who may be affected by information security risk. They each
Version 1.0 – April 2018 123
play a significant and unique role in analyzing risk, and should be defined within those roles, as
described below.
Defining Mission
Definition: An organization’s mission is the value it provides others, and that requires that they
engage in risk together to achieve that value. A college educates its students, but students must
give personal and financial information to those colleges in order to receive the education.
Retailers provide products to customers, but in many cases customers turn over their financial
information to those organizations to receive those products. Cloud service providers offer
Internet-based functionality to business customers, but those customers must turn over business
process or operations to those services as a result. So “mission” is a way of asking, “What’s in it
for the others?” who engage in risk with the organization.
Example Mission Definitions should have the following characteristics:
• Concisely state the benefit the organization provides that encourages others to enjoin
them in information security risk.
• Convey a simple fact that can be observed and measured.
• Describe something that the organization already manages to, and that personnel will
recognize as important to the organization.
Example 1: A custom manufacturer uses their customers’ intellectual property to quickly make
components that are perfect upon delivery. Their mission definition may be, “To provide
customers with products that meet their unique specifications, without fail.” The message is
simple, it can be measured, and the organization likely recognizes this as something that they
manage to. Moreover, the definition can be useful when a risk assessor tries to determine what
core values may be harmed is a risk were to occur, or if a safeguard is too burdensome to the
mission. If the risk assessor recommends a control that prevents customers from sending their
intellectual capital, or that prevents the manufacturer from storing it or sharing it among drafter
and engineers, then the mission would clearly be negatively impacted.
Example 2: A community bank states their mission as, “We promote opportunities to households
and small businesses in our community by providing affordable financial products and advisory
services.” They could say that their mission is to lend and borrow money, but they are thinking
ahead to what they do not want to compromise about that mission, and that is to serve their
community. But again, they have a concise definition that states why others would enjoin in risk
with them, that states a simple, observable, and measurable fact, and that would be familiar to
personnel who work at the bank.
Example 3: A telecommunications company is heavily relied upon to provide communication
services that are now considered fundamental to a functioning society. Additionally, they carry
tremendous amounts of private information about their customers, often at considerable
perceived risk by the public. But consumers subscribe to these services for considerable benefit.
The telecommunications company defines their mission this way, “To instantaneously and
transparently connect our customers with the people, organizations, information, and
communication platforms that they care about.” This mission definition is less concise, but it may
be as concise as they could get, considering the complexity of typical telecommunications
services. The definition is measurable, and it would very likely be recognizable by their personnel
as an important value.
Defining Objectives
Definition: An organization’s objectives are more inwardly focused and more selfish. As people
commonly think of the “burden” of a safeguard, they often think of “objectives” and most often of
Version 1.0 – April 2018 124
financial burden, or “cost.” But cost is an overly-narrow and potentially hazardous risk metric.
Organizations should want to stay away from analysis that associates financial amounts to levels
of harm that others would suffer. “We won’t spend $200,000 to protect our customers’ privacy,” is
a terrible message to send to personnel, to customers, and to the public. Rather, organizations
should think about indicators that they are succeeding or failing as on organization, independently
of their mission definition. So “objectives” are a way of asking, “How do we know we are a
successful organization?”
A Good Objectives Definition should have the following characteristics:
• Concisely state indicators of success that are independent of the mission definition.
• Convey a simple fact that can be observed and measured.
• Describe something that the organization already manages to, and that personnel will
recognize as important to the organization.
Example 1: The custom manufacturer has a five-year plan to expand into two new markets and
quadruple its production and profits. They know not to associate dollars to potential harm to
others, but growth in productivity and profitability can still be properly stated as an objective. Their
objectives definition may be, “To quadruple our production and profits in five years through
expansion into two new markets.” The message is concise and independent of the mission,20 can
be observed and measured, and would be known by personnel, but particularly by management
whose goals would be aligned with the five-year plan.
Example 2: The community bank’s mission is a compelling one, and they may want to associate
the success of their bank with the success of their community. But they must operate as a viable
financial institution if they are to service their community members. So their objectives will be
targeted to that goal. They believe that they need to maintain a certain return-on-assets ratio to
off-set future financial risk and state it this way, “We must retain a return-on-assets of 1.25%
year-over-year.” This definition is a concise indicator of success that can be easily measured, and
that personnel, and certainly managers and officers, would already be operating to.
Example 3: The telecommunications company knows one thing very well; that regardless of their
earnings, their growth in consumer base, their growth in capital investments, or their reputation …
if they slip below their “top two” status in their competitive market, they will be targeted for
acquisition. They define their objectives this way, “To grow our subscriber base, communications
capital, and revenue faster than our competition and to remain number one or two in the
marketplace.” Again, this is less concise, but the company relies on many moving parts to be
successful. The objectives definition can be measured, and personnel are certainly aware of the
goals and are responsible for managing to them.
Note Regarding Use of Financial Costs as Objectives: Organizations that wish to state their
impacts in terms of financial costs should carefully consider the message they send to
colleagues, interested parties, and authorities as they define their objectives impact scores. If an
unacceptable impact score (‘3’) for objectives states, for example, “$100,000,” and the same
score (‘3’) for obligations is “Up to 100 customers would have their information stolen and
abused” or something similar, then is the organization saying, “We would not spend $100,000 to
20 The success of the objectives may be dependent on the success of the mission, but the
definition of the of the objectives is not relying on the definition of the mission.
Version 1.0 – April 2018 125
protect 100 customers?” If so, are they prepared for how their colleagues, the public, and legal
authorities will perceive that message?
By focusing on the magnitude of impacts against objectives (even the noble cause of profitability
or financial performance) in terms of harm to the organization (their ability to operate profitably, or
recover profitability after an event) they can present their risk balance responsibly.
This qualitative approach to evaluating impacts to financial objectives is still useful by describing
the cost of recommended safeguards and evaluating the magnitude that the cost will have on the
objectives. Such case-by-case comparisons would still state financial value of the proposed
safeguard, but that financial value would be weighed against an operating principal called
“profitability” or “financial performance” which regulations and courts already include in their
definition of “burden.”
Defining Obligations
Definition: An organization’s obligations, at least in terms of information security, are to prevent
foreseeable harm that may come to others as a result of an information security compromise.
These types of harm are commonly associated with identify theft, theft of funds, or lost services
and data. But it is critical to keep in mind that obligations should explicitly state the harm that may
come to others so that risk assessors, management, and interested parties know that the
organization is careful to protect others from harm. So “obligations” are a way of asking, “What
foreseeable harm could come to others that we should prevent?”
A Good Obligations Definition should have the following characteristics:
• Concisely state the organization’s intent to prevent harm that information security
incidents may cause others.
• Convey a simple fact that can be observed and measured.
• Describe something that the organization already manages to, and that personnel will
recognize as important to the organization.
Example 1: The custom manufacturer is concerned about the harm that their customers may
suffer if their intellectual capital – their product designs – are leaked to the public and to the
customers’ competitors. Their customers often provide specifications for components that would
reveal secrets about new products. The manufacturer states their obligations this way, “Our
customers’ intellectual property must be kept confidential to preserve their market advantage.”
The definition is concise, it states a foreseeable harm to others that must be guarded against, t
could be measured, and personnel would know that protection of customers’ intellectual property
is important.
Example 2: The community bank knows that their customers are in a particularly vulnerable
position. They are often taking on risk while buying homes or starting businesses, and have less
room for error. A missed paycheck or even slight misuse of financial information could mean the
difference between success and failure for them. So the community bank uses this as their
obligations definition, “We must protect our customers’ reputation and financial future against
misuse of their financial or personal information.” Again, this definition is concise, it is
measurable, and it would be known and recognized by the bank’s personnel.
Example 3: The telecommunications company is a complex organization that can imagine
multiple kinds of harm that could result from an information security compromise. An organization
with many obligations (or missions or objectives) may state them in their definitions. For example,
the telecommunications company realizes that they may foreseeably breach personal
communications about their customers, and their communication services may fail when critical
applications depend on them. They will state two obligations, “We must protect our customers’
Version 1.0 – April 2018 126
communications records to prevent reputational or financial harm. We must meet our service
level agreements with customers to prevent harm that may result from unreliable connectivity.”
As an example, the top row of the impact definitions for the manufacturer would start to take
shape as in the table below.
Table 80 - Impact Area Definitions Example (Partial)
Impact
Score Impact to Our Mission Impact to Objectives Impact to Obligations
To provide customers with
products that meet their
unique specifications,
without fail.
To quadruple our
production and profits in
five years through
expansion into two new
markets.
Our customers’ intellectual
property must be kept
confidential to preserve
their market advantage.
Defining Impact Scores
After defining impact areas, the organization will need to define impact scores for each impact
area. Each score (‘1’ through ‘5’) will have one definition per impact area, as shown in Figure 27.
There are a few principles that organizations should consider as they define their risk scores.
Consider the scores as having the following meanings:
Table 81 - Impact Scoring Guidance
Impact
Score Guidance
1 An impact that would be negligible for the mission, objectives, and obligations.
If any impact were to occur, it would not be noticeable.
2 An impact that would be acceptable to the mission, objectives and obligations. An
impact would be noticeable, but is likely unavoidable even after significant investment
in controls. It would be considered tolerable by all affected parties.
3 An impact that would be considered unacceptable by any party. While the impact may
be recoverable through additional efforts, investment, or time, the organization could
have reduced the risk of that impact with security controls.
4 An impact that would be considered large, but recoverable. Significant efforts and
investments would need to be made to recover for all parties.
5 The impact would be catastrophic. The mission, objectives, and/or obligations would
no longer be feasible.
Scores ‘1’ and ‘2’ are shaded to indicate that these impacts should be defined in a way that would
be acceptable to all parties.
As impact score definitions are written, the organization should think through how impacts to their
mission, objectives, and obligations would appear at each of these levels.
The manufacturer’s impact score definitions are shown below to illustrate the point.
Version 1.0 – April 2018 127
Table 82 - Example Impact Score Definitions
Impact
Score
Impact to Our Mission
Impact to Objectives
Impact to Obligations
Defined
To provide customers with
products that meet their
unique specifications, without
fail.
To quadruple our
production and profits in
five years through
expansion into two new
markets.
Our customers’ intellectual
property must be kept
confidential to preserve
their market advantage.
1 Customers receive excellent products, as needed.
Our growth plan remains
on target.
All intellectual property is
protected.
2
Occasional orders cannot be
fulfilled.
Our annual targets are off
year-by-year, but within
planned variance.
Information about jobs may
be known, but nothing that
can harm customers'
market position.
3
Contracted work for few
customers cannot be
completed as planned.
Our growth is too low for
one year, but can be
recovered to meet the
five-year goal.
Information about a job
leaks, and a customer
needs to investigate
whether it created harm.
Even if direct harm would
not result.
4
Products are delivered outside
of spec and customers believe
that we cannot produce
custom products without fail.
We cannot meet the five-
year growth plan.
A single customer
experiences market
repercussions based on a
security incident.
5
We can no longer produce
reliable, custom products.
We cannot operate
profitably.
Customers can no longer
expect confidentiality
protection when working
with us.
When reading an impact definition horizontally across one score, note that the impact definition in
each impact area are equally harmful to all parties. This is a critically important feature of Duty of
Care risk analysis. It ensures that risk analysis is equitable. No party’s harm is considered more
or less tolerable than any other party’s harm. What’s acceptable to one equates to what is
acceptable to all (the shaded scores ‘1’ and ‘2’). What is catastrophic to one equates to what
would be catastrophic to all.
Example impact definitions for all three example organizations are provided in the supplementary
document CIS_RAM_Workbook in the tab “Example Impact Definitions” to assist the reader’s
comfort and familiarity with this subject.
Estimating Likelihood Through “Defense-Readiness” Analysis
The CIS RAM presents a standardized method for estimating the likelihood of an incident by
focusing on how a threat could interact with a vulnerability. This concept of foreseeability is easily
communicated to broad audiences, and is embedded in legal and regulatory language, so it is a
useful construct for likelihood estimation. However, some organizations need more rigor while
estimating likelihood and can achieve that by evaluating the characteristics of a successful or
failed attack in their environment.
Version 1.0 – April 2018 128
Table 83 – Summary Evaluation of Defense-Readiness Analysis
Benefits Limits
- Consistent method to evaluate likelihood
- Supports evidence-based estimation
- Not based on an established standard
- Evidence-based criteria are optional
Borrowing from Binary Risk Analysis,21 “defense-readiness analysis” asks a series of questions
about attacks and safeguards to estimate the ability of a control to detect or prevent foreseeable
threats.22 A risk assessor can quickly evaluate defense-readiness by asking a set of questions
such as these:
1. Is this threat expected either because it is a common cause of incidents, or because the
skills and resources needed to enact the threat are common?
2. Does the control leave the asset exposed to this threat occasionally or partially?
3. Are there no other safeguards or conditions between the asset and the threat?
4. Is the vulnerability present on a frequent or consistent basis?
Organizations that use a 1 through 5 likelihood scale could then derive the likelihood score
reducing the maximum score of ‘5’ by ‘1’ for each ‘yes’ response that they provide to the fortitude
questions. Organizations that use a 1 through 3 likelihood scale may choose to assign .5 points
per response to arrive at scores between 1 and 3.
As an example of this analysis process, an organization is concerned that its software developers
have access to the production environment. CIS Control 18.9 states, “Maintain separate
environments for production and nonproduction systems. Developers should not have
unmonitored access to production environments.” The threat model they are evaluating relates to
promotion of unsecure or malfunctioning code to the production environment. The organization
currently has a policy that requires code review and approval prior to promoting code to
production, but many software developers have access to the production environment in case
they need to respond to emergencies.
To estimate the likelihood of the risk, they answer the defense-readiness analysis questions
below.
Table 84 – Defense-Readiness Analysis Example
Defense-Readiness Analysis Question
Response
(1 = ”Yes”, 0 = ”No”)
Is this threat expected either because it is a common cause
of incidents, or because the skills and resources needed to
enact the threat are common?
1
21 http://binary.protect.io (accessed January 3, 2018)
22 While Binary Risk Analysis provides a rigorous analytic process, it must be modified to address
the concepts of “reasonable” and “appropriate” that are central to the CIS RAM and the legal and
regulatory sphere.
Version 1.0 – April 2018 129
Defense-Readiness Analysis Question
Response
(1 = ”Yes”, 0 = ”No”)
Does the control leave the asset exposed to this threat
occasionally or partially? 1
Are there no other safeguards or conditions between the
asset and the threat? 0
Is the vulnerability present on a frequent or consistent
basis? 1
Likelihood score (Sum of responses). 4
The organization arrives at a likelihood score of ‘4’ after their analysis. If a careless or hurried
programmer is the threat in this scenario, then the organization responds with these scores for
the following reasons.
1. The threat is a common cause for breaches, and requires common skills to access the
production environment and promote code, so the organization responds with ‘1’.
2. The logical access safeguards that protect the production environment always permit
programmers to promote code, so the organization responds to this question with a ‘1’.
3. Because the programmers generally adhere to policies, secure coding practices, and
documented workflows, there are other safeguards that would prevent the promotion of
harmful code to the production environment. So the organization answers with a ‘0’.
4. And the vulnerability is consistently present so the organization responds again with a ‘1’.
Finally, they add the responses to achieve their likelihood score, which is in this case ‘4’.
Organizations should be aware that defense-readiness analysis is not necessarily evidence-
based, and does not comprehensively examine all aspects of control strength. The benefit of
defense-readiness analysis is to help organizations systematically, thoughtfully, and consistently
estimate their likelihood scores based on internal and external criteria.
For example, an organization can also consistently analyze defense-readiness by asking
questions similar to those below:
1. Is the asset in this threat scenario attractive to well-resourced hackers?
2. Is this attack a common cause for breaches in our industry?
3. Has this control been evaluated as effective using a penetration test, or other rigorous
test?
4. Is our time to detect-and-prevent this attack’s impact shorter than the time the attack
needs to create an impact?
Defense-readiness can take evidence into consideration by reviewing information security data
about their environment (if they have implemented the tools necessary to gather that information),
and by reviewing known causes for information security events, incidents, and breaches.
Using Probability with Duty of Care Risk Analysis
Some organizations have useful sources of data to conduct probability analysis to help them
determine the likelihood of risks. Probability analysis requires statistical methods, well-honed
estimation skills, and good data to determine the likelihood of an event, or of events with certain
impacts.
Version 1.0 – April 2018 130
Table 85 - Summary Evaluation of Using Probability with Duty of Care Risk Analysis
Benefits Limits
- Supports evidence-based estimation
- Risk assessors may rely on professional
rigor to improve risk estimation over time.
- Statistical estimates must address all
impact types to properly evaluate each
risk on a due-care basis.
This section will propose an approach to link probability analysis to “duty of care” assessments,
but will not present a comprehensive method for doing so, nor will it provide an explanation of the
probability analysis that this section refers to. Readers who use probability analysis for
information security management are encouraged to explore integration methods like those
described here.
Probability analysis is complementary to the risk evaluation methods described in the CIS RAM,
but readers should understand their differences.
1. With the right guidance, applying probability models to individual cybersecurity risks is
(probably) simpler than the reader may imagine.23
2. Probability is evidence-based and can help organizations model increasingly realistic
threat scenarios, especially as the rigor of their methods increases.
3. Probability is built upon decades of sound methodology, driven by professional
statisticians, using universally recognized processes for reducing uncertainty.
Organizations that can use probability methods should do so.
4. Probability models often result in ranges or curves, rather than discrete scores such as
those produced by the RAM. Ranges of possible outcomes resemble “estimation” better
than a discrete value does. However, ranges and curves are more difficult to compare
and prioritize than discrete scores.
5. Cybersecurity threat scenarios are varied, and therefore require a variety of probability
methods to estimate their likelihood. This makes their raw results hard to compare and
rank. A Monte Carlo simulation that provides a single value (for example, a “22%” chance
an unencrypted laptop will be stolen) and a Bayes model that provides a curve describing
several possibilities of likelihoods of dollar impact (such as “13% chance of $750,000 loss
and 24% chance of 177,000 loss) are not readily comparable. And comparing them to a
single risk acceptance criterion will be similarly difficult.
6. Probability models on their own do not naturally align with duty of care questions posed
by regulations or litigation. Regulations and litigation insist on evaluating “due care” by
balancing different kinds of things (safety of customers versus the value of services
provided to them, for example). Statistical models that describe impact in terms of one
thing (i.e. cost of an impact) miss other real consequences of cybersecurity breaches,
such as harm to others, or the burden of too-stringent safeguards (i.e. reduction in
services, risks to personnel safety, difficulty in operating profitably, or the benefits that an
23 Douglas Hubbard of Hubbard Research has published many books on the subject, the latest of
which focuses exclusively on cybersecurity. Hubbard, Douglas and Richard Seierson. How to
Measure Anything in Cybersecurity. Hoboken, NJ: John Wiley & Sons, Inc., 2016.
Version 1.0 – April 2018 131
organization provides to others, etc.). When all impacts are evaluated in terms of dollars,
juries and judges tend to see the risk assessment unfavorably.24
But organizations that are well-trained in statistics and estimation should use probability modeling
and simulations to feed their Duty of Care analysis. How, then, would such an organization
accomplish this using the CIS RAM?
Such organizations cold “translate” the output of their probability models (such as Bayesian
distributions, Monte Carlo simulations, or estimates) into the likelihood scores or risk scores that
are used in the risk register.
Consider the case of a Bayesian distribution for the risk of malware causing a breach on an end-
user system, given the use of a robust malware prevention system. The risk probability can be
calculated as such:
P(malware breach | malware prevention) = P(malware | malware prevention) P(malware breach |
malware) + (1 – P(malware | malware prevention) P(malware breach | ~malware) = (.05)(.75) +
(.95)(.01) = 4.7%.25
Recall that the impact scoring table for a Tier 2 or Tier 3 and Tier 4 organization has five values
that describe levels of foreseeability. An organization can very easily add a column to their
likelihood definitions table (as in Table 86) to state how they associate foreseeability with
probability.
Note: The probability values provided in Table 86 are illustrative only. Each organization could
determine for themselves how to associate foreseeability with probability while defining their risk
assessment criteria. Over time, the organization should review and update this table.
Table 86 – Example Likelihood Definitions Aligned with Probability
Likelihood
Score
Foreseeability Probability %
1 Not foreseeable < .5%
2 Foreseeable but not expected < 5%
3 Expected to occur < 10%
4 A common occurrence < 25%
5 May be happening now <= 100%
The organization’s probability of malware given their robust malware prevention system is 4.7%,
which is below 5% (the organization’s definition for “Foreseeable but not expected” likelihood).
This guides them to select the Likelihood value of ‘2’ for the risk of malware infection. They would
then select the impact scores for such a scenario to derive their risk score.
24 Viscusi, W. Kip, “Jurors, Judges, and the Mistreatment of Risk by the Courts.” Journal of Legal
Studies, vol. XXX (January 2001).
25 Note: The CIS RAM does not expect that readers understand or use probability analysis. This
calculation is shown only to demonstrate how probabilistic analysis can be coordinated with the
CIS RAM.
Version 1.0 – April 2018 132
And because some probability analysis results in multiple possibilities within a range (i.e. a 1%
chance of a complete system failure, or a 15% chance of a partial system failure) a risk register
may simply show the same risk twice, but with two different risk evaluations.
Results such as these – multiple risks within a range – are often caused by a precondition that
may or may not be in place when the threat occurs. For example, a low risk of a complete system
failure may be associated with normal operating conditions, and a higher risk may be associated
with a busy season or other non-typical circumstance. Two risks on the risk register could then
describe the two risks differently and call out their dependence on the precondition (i.e. risk one is
associated with the busy season, risk 2 is associated with normal operations.).
Many probability models produce a range of both likelihood and impact scores, such as the
Bayesian distribution depicted in Figure 28.
Figure 28 - Probability Curve Example
A benefit to such a probability range is that it estimates both the likelihood and impact values of a
risk. At its greatest likelihood, there appears to be about a 24.9% probability of a $1MM impact. At
its lowest likelihood, there appears to be below 1% probability of a cost of $20MM or greater. This
allows the client to either state a high likelihood of a lower cost, or a lower likelihood of a higher
cost. The organization could model both of these scenarios to determine which creates the
greater risk score to address that risk.
Pairing the probability curve to the modified likelihood definitions table (Table 86), the highest
probability score (less than 25%) appears to be at the upper edge of a likelihood score of ‘4’.
If the organization’s impact scoring table refers to cost or budget impacts (perhaps in the
Objectives column) then $1MM would be considered within the context of those impact values.
For example, the organization may determine that a $1MM loss would take more than one year to
recover from, indicating an impact value of ‘4’ under their Objectives column in Table 87. That
Version 1.0 – April 2018 133
would leave them with a risk score of ‘16’ by multiplying the likelihood score of ‘4’ and the impact
score of ‘4’.
Table 87 – Example Impact Definitions
Impact
Score
Impact to Mission
Mission: Provide information to
help remote patients stay
healthy.
Impact to
Objectives
Objectives: Operate
profitably.
Impact to Obligations
Obligations: Patients must not
be harmed by compromised
information.
1 Patients continue to access
helpful information, and
outcomes are on track.
Profits are on target. Patients do not experience
loss of service or protection.
2 Some patients may not get all
the information they need as
they request it.
Profits are off target,
but are within
planned variance.
Patients may be concerned,
but not harmed.
3 Some patients cannot access
the information they need to
maintain good health
outcomes.
Profits are off
planned variance and
may take a fiscal
year to recover.
Some patients may be
harmed financially or
reputationally after
compromise of information or
services.
4 Many patients consistently
cannot access beneficial
information.
Profits may take
more than a fiscal
year to recover.
Many patients may be
harmed financially or
reputationally
5 We can no longer provide
helpful information to remote
patients.
The organization
cannot operate
profitably.
Some patients may be
harmed financially,
reputationally, or physically,
up to and including death.
While organizations may be pleased with the ease by which they can align their probability
outputs to their due-care risk assessment criteria, probability should be modeled against all
impact criteria. Risk analysis that only considers financial impacts to the organization misses a
necessary component of cybersecurity risk analysis; estimating and taking responsibility for the
potential harm that others may suffer. As well, the organization must evaluate the risk of
safeguards using the same probability models.
For thorough and practical guidance on using probability analysis for cybersecurity decision-
making, consult the book, How to Measure Anything in Cybersecurity by Douglas Hubbard.26
Noting How Realized Risk Might be Detected
Risk assessments provide organizations with insight into how security incidents and breaches will
foreseeably occur. This provides organizations with an opportunity to tie their risk register to their
processes for security log management and alerting, for incident response planning, and for
security awareness training. All these benefits can be added to a risk register by adding a single
column “Realized Risk.”
26 Hubbard, Douglas W., Richard Seiersen. How to Measure Anything in Cybersecurity. Hoboken,
NJ: John Wiley & Sons, Inc., 2016
Version 1.0 – April 2018 134
This column, which could follow the threat model on any of the risk registers that are illustrated in
this document, would describe how the organization would know if an attack or error was in
progress, or if an incident or event had occurred.
Consider the following risks:
Table 88 - Realized Risks Column Example
Current Control
Vulnerability
Threat
Realized Risk
Vulnerability scans
occur occasionally and
may not identify all
systems that have been
on the network between
scans.
Systems that have
joined the network
between sporadic
scans will not be
detected.
Hackers or malware
may attack and control
systems that have not
been detected,
controlled, and
monitored.
IP traffic is sent to
or from hosts
whose MAC
addresses are not
in the vulnerability
scan output.
Vulnerability scans
occur when Threat Info
Service announces a
moderate-to-high
vulnerability that needs
patching. Team reliably
patches systems within
24 hours of
announcement.
A 24-hour window of
vulnerability remains
with the current
process.
Hackers or malware
may attack and control
systems that have not
been patched within
the 24-hour period
after the vulnerability
was announced.
Unusual traffic
sent to the
unpatched
systems.
Vulnerability scans
occur when Threat Info
Service announces a
moderate-to-high
vulnerability that needs
patching. Team patches
most systems within 24
hours of announcement.
Enterprise
management
application systems
are unpatched for more
than one year.
Hackers or malware
may attack and control
enterprise
management
application
environment.
SQL command
strings sent from
client browsers
and from form
fields and URL
requests.
The organization now has a simple way to know what to look out for in terms of log-able events,
to add escalation indicators to their incident response plan document, and to use in information
security awareness training (especially for those realized risk indicators that are recognizable by
general personnel).
Using Realized Risk for Monitoring: In the case of the first “realized risk” notation, the
organization may decide to detect risks by comparing MAC addresses in ARP caches to those in
their vulnerability scan output. With the right tools or scripting skills, this may be simple to achieve
for them.
Using Realized Risk for Incident Response: The organization may note in their incident response
plan that they need to take action when a MAC address appears for an unknown device (which
would be hyper-vigilant in this case, but to illustrate the point).
Using Realized Risk for Training and Awareness: And the organization may use this as an
opportunity to describe to systems engineers and help desk personnel information that may help
them detect and investigate other unexpected activities on the network.
Version 1.0 – April 2018 135
Leveraging Duty of Care Risk Analysis for Maturity Models
Many organizations use maturity models to evaluate the security capabilities in their environment.
Maturity model evaluations ask questions about specific security controls or control groups so
evaluators can determine how formalized an organization’s security program is. Maturity models
can be aligned to CIS RAM risk assessments by aligning a control in the maturity model with a
corresponding CIS control in a risk register to determine the risk acceptability of the maturity
score.
Table 89 - Summary Evaluation of Using Duty of Care Risk Analysis for Maturity Models
Benefits Limits
- Organizations may continue to
evaluate the formalization of their
security programs.
- Some moderate maturity scores may
be sufficient if aligned with reasonable
risks.
- Some authorities who insist on
evaluating organizations solely with
maturity models may not accept
moderate maturity scores that align
with reasonable risk.
Maturity model evaluations generally ask organizations a set of control descriptions, and provide
multiple-choice values as optional responses to the control description. For example, control
descriptions for vulnerability management may state something similar to this:
Vulnerabilities are resolved within three business days.
Optional responses would be similar to this (though responses vary from one maturity model to
the next):
0 = Not in place
1 = Ad hoc
2 = Documented
3 = Consistently applied
4 = Tested and corrected
5 = Continuously improved.
If an organization applies this process and they check for success with subsequent weekly tests,
but do not improve their test, they would answer with a “4.”
If this organization also conducts a CIS RAM risk assessment, they will have examined this
control in a risk format in their risk register. In this case, they would have examined CIS Control
3.6 “Compare back-to-back vulnerability scans.” They may have determined that the likelihood
and impact of foreseeable threats is acceptably low. If their risk analysis tells the organization that
their existing review process is acceptable in terms of risk, then they can also note that in their
maturity evaluation this way.
Table 90 - Example Maturity Model Mapped to Risk
Control Existing Control Maturity Score Risk
Acceptance
Vulnerabilities
are resolved
Weekly vulnerability scans
review findings to determine
whether any vulnerabilities
4
Accept
Version 1.0 – April 2018 136
Control Existing Control Maturity Score Risk
Acceptance
within three
business days.
were identified in previous
scans.
By aligning a maturity score with a risk score, the organization can determine whether they need
to, or wish to, further formalize the control. In this way, the organization can continue to evaluate
their security program using maturity scores, but not feel compelled to continuously improve
unless there is a risk-related reason for doing so.
Interview Techniques
Risk assessment interviews are critical moments for understanding and modeling risk and should
be approached differently than for a compliance assessment or an audit. In a risk assessment,
assessors ask about existing safeguards, as in an audit, but in the context of how foreseeable
threats may compromise information assets given those safeguards.
Table 91 – Summary Evaluation of Interview Techniques
Benefits Limits
- Increases risk awareness among
interviewees.
- Observes key personnel knowledge of
risk issues.
- Personnel descriptions of safeguards
and risks may not be accurate.
In a compliance assessment or audit, the assessor generally reports a “pass” or “fail” or even a
“partial pass” by observing whether a required control is present. An auto-closing door with an
auditable lock may be “compliant” with a security standard. An operating firewall may qualify as a
“pass” for an audit of the network perimeter. Encryption between an application server and a
database server may be marked as “green” or “low risk” on a report. But in a risk assessment, the
risk assessor brings knowledge to the interview (and later the control configuration review) that
stress-tests the described safeguards.
For example, does the firewall’s ruleset contain no more than the minimal rules and policies that
are required for business? Who gets to change the firewall’s policies and how is their access
tracked? Who has access to the firewall’s CLI and webadmin interfaces, and from what
networks? Is the webadmin interface even active? How is firmware upgraded? How are firewall
event logs reviewed and analyzed? Is access enforced through multi-factor methods? Does the
firewall fail open?
As respondents provide each answer, the risk assessor should then consider a corresponding
threat to help them model the risk. It may be appropriate to model risks with the respondent
present, or after the interview. This depends on a number of factors, including the risk assessor’s
comfort in improvising threat scenarios for each response about a safeguard. But ideally, the risk
assessment interview will involve discussions about threats so that full risk discussions inform
follow-up questions.
Consider how the interview questions above would play out when an interviewee’s responses are
paired with threats.
Version 1.0 – April 2018 137
Table 92 - Interview Threat Pairings
Interview Question Response Paired Threat
Does the firewall’s ruleset
contain no more than the
minimal rules and policies that
are required for business?
No. Some temporary policies
may still be operating.
Hackers like to exploit firewall
rules that provide access to
internal systems and services.
What are the chances they will
find permissive policies on the
firewall now?
(Note: This is an excellent
example of a safeguard to
observe later).
Who gets to change the
firewall’s policies and how is
their access tracked?
Two administrators have
privileges with unique
accounts. All firewall changes
are logged and alerted to the
security team.
Two administrators seems to
be a low number. Do they
share their passwords with
other administrators to help
out when needed?
Is the webadmin interface
even active?
It is, but only for internal
networks.
Attackers or malware may try
to log onto the webadmin
application using guessed or
stolen credentials. How do you
prevent that from happening?
Is access enforced through
multi-factor methods?
Yes. Each administrator uses
an application on their cell
phone to receive an out-of-
band, six-figure code that lasts
one minute.
Could an unauthorized person
access their phone while at a
system that can log into the
webadmin interface with
stolen credentials?
By responding to answers with plausible threats, the risk assessor can drive a more interesting
interview about whether a control is sufficiently designed, and can give them indicators of what
safeguards and configurations they would want to follow up on during subsequent configuration
reviews.
In addition to pairing interviewee responses with plausible threats, organizations should plan their
risk assessment discussions along the lines of a structure, or planned conversation. This helps
ensure that the risk assessor addresses a set of subjects that must be understood during a risk
assessment, and allows them to rely on a plan rather than to exhaust themselves with constant
improvisation.
Consider using one or more of these rubrics to set the rhythm of risk assessment interviews.
Rubric 1: “Full Lifecycle of Use,” or “Process Audit.” This method forces risk assessment
participants to think of information assets as something that changes over the course of its usage.
The process is generally useful for assessors who have experience in security operations,
because it requires them to have practical knowledge of how information assets are developed
and managed.
An example of a full lifecycle of use interview process will illustrate the point.
1. An information asset’s lifecycle starts with defining the business requirements that it is
being built for.
2. Then technical specifications are listed to prepare the information asset to satisfy the
business requirements.
3. A hardening standard would then be selected to build the asset from
Version 1.0 – April 2018 138
4. The information asset is then built, installed, or deployed with primary access rights.
5. More access rights are established, and the information asset if configured.
6. The information asset is included in common security processes, such as log
management, vulnerability management, change management, penetration testing, and
patch management schedules and routines.
7. And finally, it ends its lifecycle by being de-commissioned, lost, stolen, or damaged.
The lifecycle of an information asset provides a risk assessor indications of whether and how
safeguards are applied to the information asset.
So if early interview questions determine that there is no rigorous process for identifying business
requirements or technical specifications for server deployments, then safeguards that will be
discussed further on, such as log management and change management, will be assessed with
the knowledge that initial requirements for the server are not reliably known. A server’s hardening
and configurations processes may permit too many services and access privileges because
business requirements and technical specifications are the appropriate stages for determining the
least capabilities and least privileges for a server.
By the time the risk assessor arrives at questions regarding log management, they would also
know to ask, “How do you know that the servers logs are appropriate to the risks and function of
the system?” For vulnerability management, the risk assessor could ask, “How do you know the
difference between a vulnerability service that is business-appropriate and one that is not?” And
“How do you test patches, upgrades, and configuration changes if you don’t know which
business-critical services you may interrupt?
Again, this process is appropriate for experienced security professionals, or individuals who have
experience in technical operations and understand how previous stages of an information asset’s
lifecycle can influence the effectiveness of safeguards in later stages.
Rubric 2: “Security Management Lifecycle” The security management lifecycle of an information
asset resembles maturity model evaluations used in other security assessment methods. For
those not familiar with maturity models, they resemble something similar to the below table.
Table 93 - Example Maturity Model
Maturity Level Description
1 – Ad hoc Not consistent in practice.
2 – Documented Documents state requirements for processes and configurations.
3 – Implemented Requirements are applied to information assets as safeguards.
4 – Evidenced Tests demonstrate that safeguards are effective.
5 – Detect & Correct Management detects when failures occur and improve identified flaws.
Many assessments impose maturity models such as the one depicted above. In these
assessments, assessors often rely on the selection of a maturity score as their total description
of a safeguard. But without an understanding of an information asset’s resilience to foreseeable
threats, the acceptability of a control will be difficult to evaluate.
Despite this weakness, a maturity model can be useful in evaluating risk. For instance, while a
risk assessor is evaluating a control to determine its resilience against threats, they could use the
maturity model to understand the likelihood of current and future risk.
An example risk assessment conversation about server hardening demonstrates this process
below.
Version 1.0 – April 2018 139
Assessor (Asking the “1 - Ad hoc” question): Do you harden your servers to a known good
standard?
Systems Engineer: Yes, our servers are deployed using images based on SCAP policies that
support each operating system version.
Assessor (Asking the “2 - Documented” question): How do you know which SCAP policies to
apply to each server?
Systems Engineer: We have standards that list each implemented operating system and
version, and that state the SCAP policy version to use for each operating system.
Assessor (Asking the “3 - Implemented” question): How many servers in production now are
based on SCAP policies?
Systems Engineer: All servers were built within the last year, so all are configured with its
matching SCAP policy as its baseline.
Assessor (Asking the “4 - Evidenced” question): Are they still configured to the hardening
standard they started with?
Systems Engineer: I think so. Some settings must have changed for new requirements or
troubleshooting. Sometimes we make temporary changes that we don’t always change back.
Assessor (Asking the “5 - Detect & Correct” question): How do you know when a server is no
longer configured to match its SCAP policy?
Systems Engineer: Vulnerability assessments show when there are vulnerabilities, so that’s one
way. But we are not strictly checking for compliance against the SCAP policy after the servers
have been deployed.
Now the organization knows that they started out configuring servers securely, but that the
servers begin to diverge from their known-secure configuration and the organization may not
detect it to correct it, unless the vulnerability scanning software compares server configurations to
their SCAP policies.
Risk assessment interview methods can help drive the discovery and analysis in many ways, and
no single method is ideal. Organizations should consider attempting a variety of methods to see
which work best in different scenarios. But if there is one rule to apply in developing an interview
style it is this: Be flexible to the environment, the capability of the participants and assessors, and
the nature of the information you are trying to obtain. Sticking with one method throughout an
assessment will miss opportunities to discover risk.
Evaluating Inherent Risk
Some organizations are interested in understanding the “inherent risk” of a scope of information
assets. “Inherent risk” is defined in the Glossary as, “The likelihood of an impact when a threat
compromises an unprotected asset.” A risk register that evaluates “inherent risk” would be nearly
identical to the templates provided in the CIS_RAM_Workbook but would not note or consider
controls that are in place to protect information assets.
Organizations that look for inherent risk often want to determine things such as:
1. What potential liabilities do we face in Venture A versus Venture B?
2. If we move a business process into a cloud service, what is the risk/reward of option A
which uses all of our data, versus Option B with uses some of our data?
3. If we engage this business process / technology / facility, what new regulatory
requirements will we bear?
4. What is the current benefit of our existing security program?
Version 1.0 – April 2018 140
And while inherent risk analysis may provide quick answers to these questions, they appear to
pose a fictional state for most situations. They appear to imagine environments in which there are
truly no security controls. A quick analysis can describe the benefits and limits of inherent risk
analysis in Table 93.
Table 94 – Summary Evaluation of Evaluating Inherent Risk
Benefits Limits
- Aligns with some security evaluation
standards, such as the FFIEC
Cybersecurity Assessment Tool.
- Provides a basis for a quick estimation
of potential liabilities of certain
ventures or technical architecture
decisions.
- May help raise awareness among non-
technical management of the need to
continue to invest in information
security programs, safeguards and
awareness.
- Assumes a fictional condition without
controls.
- Does not evaluate the potential
burdens (whether low or high) of
safeguards in business propositions,
which be material to the attractiveness
of the proposition.
If risk assessors do intend to add inherent risk analysis to their risk registers, they can do so in
the templates provided in the CIS_RAM_Workbook by adding columns to the left of the observed
risk columns. The risk register could then compare the potential of full and immediate
compromise of the assets to the current state of controls, and the proposed state of controls.
Organizations should first determine what value this analysis provides.
Root Cause Analysis
Because organizations will be identifying weaknesses in safeguards, and will propose risk
treatments to address those risks, they will need to understand the actual cause of the
vulnerabilities to ensure that the vulnerabilities do not re-occur. This process of identifying the
underlying causes for weaknesses or failures is called “root cause analysis.”
Table 95 – Summary Evaluation of Root Cause Analysis
Benefits Limits
- Helps the organization reduce the
likelihood of recurrence of the weakness.
- Helps the organization simultaneously
address other weaknesses that may
result from the root cause.
- May be difficult to identify the actual root
cause as the organization starts using
the process.
- Root cause analysis may lead to one
root cause when other root causes may
be missed.
A generally accepted practice for identifying root causes is to conduct a “five whys” exercise.
This entails the risk assessor to recurringly identify the underlying reason for a problem and the
causes of the problem, until a “root cause” of the problem is identified.
Root cause analysis looks similar to the diagram below.
Version 1.0 – April 2018 141
Figure 29 - Root Cause Analysis Model
While root cause analysis is classically conducted by asking, ”why” five times to more deeply
uncover the root cause of a problem, this example arrived at a plausible root cause after asking
“why” four times. This is because an organization may uncover the root cause with more or fewer
questions than five.
In this case, the risk assessor will have noted that a web page is vulnerable to a SQL injection
attack. If their recommended risk treatment was simply, “filter all form objects on the page to
prevent special characters, the application developers would fix the one identified error, and then
likely repeat the error the next time they had an emergency application change.
After this root cause analysis, however, the organization knows to both address the identified
weakness (the unfiltered input at the application page) and the root cause (the lack of security
coding during or immediately after emergency changes).
Root cause analysis should be part of all vulnerability assessments, whether they occur during a
risk assessment, an audit, or after a security incident as management determines lessons
learned.
Version 1.0 – April 2018 142
Helpful Resources
CIS (Center for Internet Security)
CIS (Center for Internet Security, Inc.) is a forward-thinking, non-profit entity that harnesses the
power of a global IT community to safeguard private and public organizations against cyber
threats. Our CIS Controls™ and CIS Benchmarks™ are the global standard and recognized best
practices for securing IT systems and data against the most pervasive attacks. These proven
guidelines are continuously refined and verified by a volunteer, global community of experienced
IT professionals. CIS is home to the Multi-State Information Sharing and Analysis Center® (MS-
ISAC®), the go-to resource for cyber threat prevention, protection, response, and recovery for
U.S. State, Local, Tribal, and Territorial government entities. (www.cisecurity.org)
HALOCK Security Labs
Established in 1996, HALOCK Security Labs is an information security professional services firm
based in Schaumburg, IL. For more than 20 years, HALOCK has provided Purpose Driven Security
services to help organizations achieve their mission and objectives through sound security
practices. HALOCK uses their deep background in the legal and regulatory landscape, security
technologies and standards, business governance, and data analytics to provide evidence-based
security analysis and guidance to their clients. (www.halock.com)
For guidance in implementing the CIS RAM: (www.halock.com/cisram)
DoCRA Council
The DoCRA Council maintains and educates risk practitioners on the use of the Duty of Care
Risk Analysis (DoCRA) Standard that CIS RAM is based on. While DoCRA is applicable to
evaluation of information security risk, it is designed to be generally applicable to other areas of
business that must manage risk and regulatory compliance. (www ra.org)
International Organization for Standardization (ISO®)
ISO provides to information security professionals a set of standards and certifications for
managing information security through an information security management system (“ISMS”).
ISO 27001 is a risk-based method for organizations to secure information assets so that they
support the business context, and requirements of interested parties. ISO 27005 is an information
security risk assessment process that aligns with CIS RAM.( https://www.iso.org/isoiec-27001-
information-security.html)
National Institute of Standards and Technology (NIST)
NIST provides a series of standards and recommendations for securing systems and information,
known as “Special Publications” in the SP 800 series. NIST SP 800-30 provides guidance for
assessing information security risk, NIST SP 800-37 and NIST SP 800-39 each present
approaches for managing information security risk within an organization. While these
approaches are designed to address federal information systems and reference roles within
federal agencies, their principles and practices are generally applicable to many organizations. (
https://csrc.nist.gov/publications/sp)
NIST also provides the Framework for Improving Critical Infrastructure (“Cybersecurity
Framework”). The framework organizes information security controls within a structure that
prepares for and responds to cybersecurity incidents. The Cybersecurity Framework aligns its
categories and sub-categories of controls with those of other control documents, including the
CIS Controls. (https://www.nist.gov/framework)
Version 1.0 – April 2018 143
Information Systems Audit and Control Association (ISACA®)
Well known for their IT assurance standards and certifications, ISACA provides an information
security risk management framework known as Risk IT. Risk IT bases its risk analysis method on
ISO 31000, and adds risk governance and response to the analysis to provide a lifecycle of IT
risk management. (http://www.isaca.org/Knowledge-Center/Risk-IT-IT-Risk-
Management/Pages/default.aspx)
Binary Risk Analysis (BRA)
Binary Risk Analysis is published as version 1.0. The analysis method is presented as a
worksheet and an application at the hosting website. The BRA provides risk analysts with a
concise and consistent process for evaluating information security risks by breaking down the
components of a threat scenario, including the capabilities to defend against variably robust and
common threats. (http://binary.protect.io)
Fair Institute
Fair Institute maintains and educates risk analysists on the use of Factor Analysis of Information
Risk. The FAIR method is similar to BRA in that it provides a consistent method for evaluating
information risk based on characteristics of the components of information risks.
https://www.fairinstitute.org/
All references to tools or other products in this document are provided for informational purposes only, and
do not represent the endorsement by CIS of any particular company, product, or technology.
Contact Information
CIS
31 Tech Valley Drive
East Greenbush, NY 12061
518.266.3460
controlsinfo@cisecurity.org
HALOCK Security Labs
1834 Walden Office Sq. Ste 200
Schaumburg, IL 60173
847.221.0200
cisram@halock.com