May 2023, Stockholm

TRUESEC

ID.AM-07 Sensitive data and We would like to see this control expanded to
corresponding metadata are | include Information Classification in general, as
inventoried and tracked part of taking inventory of devices, software and

services. This classification can then lead to
specific measures for specific types of
information and data.

ID.AM-08 Systems, devices, and A very important control, but we think it belongs
software are managed in the PR category where it was previously. We
throughout their life cycle, are talking about specific protective actions here,
including pre-deployment not actions related to identification of assets.
checks, preventive
maintenance, transfers, end-
of-life, and disposition
(formerly PR.DS-3, PR.IP-2,

PR.MA-1, and PR.MA-2)

ID.RA-03 Threats, both internal and How is this different from ID.RA-02 (“Cyber threat
external, are identified and intelligence is received from information sharing
recorded forums and sources”)

ID.RA-04 Potential business impacts “impacts and likelihoods” of
and likelihoods are what? Vulnerabilities? Threats? Risks?
identified and recorded

ID.RA-O6 Risk responses are chosen, | Very good, this needed to be expanded a
prioritized, planned, tracked, | bit. Any risk analysis is useless unless it results
and communicated in actual responsive measures.

(formerly ID.RA-6 and
RS.MI-3)

ID.RA-O7 Changes are managed, This one looks like it doesn’t really belong in the
assessed for risk impact, ID.RM subcategory. Change Management is
and recorded (formerly part | very important, and should maybe have its own
of PR.IP-3) subcategory under PR.

Important to differentiate between types of
changes such as software development, patch
management, network configurations, application
configurations and master data changes.

ID.RA-09 Processes for receiving, We feel like this could be coordinated with ID.RA-
analyzing, and responding 01
to vulnerability disclosures
are established (formerly
RS.AN-5)

O3S3Nux.


May 2023, Stockholm

TRUESEC

RC.RP-01 The incident recovery plan “Incident Recovery Plan” is not something we
is executed talk about very often. Most customers won't
really know what this is. Is it the same thing as a
DR Plan, or something else?
Needs to be clarified.
RC.RP-02 Recovery actions are How is this different from the execution of the IR
determined, scoped, Plan mentioned in RC.RP-01?
prioritized, and performed
RC.RP-03 The integrity of backups and | Shouldn't this integrity be tested continuously?
other restoration assets is
verified before using them
for restoration

O3S3Nux.


May 2023, Stockholm

PR.DS-09

Data is managed throughout
its life cycle, including
discovery, maintenance, and
destruction (formerly PR.IP-
6)

TRUESEC

Good clarification

PR.DS-10

The confidentiality, integrity,
and availability of data-in-
use is protected (formerly
PR.DS-5)

Very good to include data-in-use in this
subcategory.

PR.DS-11

Backups of data are
conducted, protected,
maintained, and tested
(formerly PR.IP-4)

Should this be a part of the RC
category? Backups themselves have no
purpose besides enabling a recovery.

PR.PS-01

Configuration management
practices are applied (e.g.,
least functionality, least
privilege) (formerly PR.IP-1,
PR.IP-3, PR.PT-2, and
PR.PT-3)

To me “least privilege” is an access principle

rather than a configuration management practice.

PR.PS-03

Hardware is maintained,
replaced, and removed
commensurate with risk

Glad to see verbiage about repair of equipment
being removed.

PR.PS-04

Log records are generated
for cybersecurity events and
made available for
continuous monitoring
(formerly PR.PT-1)

We think this belongs in the DE category.

PR.PS-06

Backups of platform
software are conducted,
protected, maintained, and
tested

Very similar to PR.DS-11

We feel like this also belongs in the RC category.

PR.PS-08

Supply chain security
practices are integrated and
their performance is
monitored throughout the
technology product and
service life cycle

This is very similar to some of the ID.SC.
controls.

PR.IR-O1

Response and recovery
plans (e.g., incident

response plan, business
continuity plan, disaster

We feel like this belongs in the RS category.

O3S3Nux.


May 2023, Stockholm

TRUESEC

ID.RA-10 Exceptions to security Incomplete sentence
measures are reviewed,
tracked, and compensated
for

ID.SC-06 Supplier termination and A very good addition. A lot of people forget to
transition processes include | think about what happens to their data after an
security considerations agreement is over.

This should be spelled out in the agreement
itself.

ID.IM Improvements to As mentioned above, | feel like this is more a
organizational cybersecurity | measure of maturity than an actual control.
risk management processes
and activities are identified

And, a//work in cybersecurity should be
continually improved.

PR.AA-02 Identities are proofed and We get a lot of questions about what this control
bound to credentials based | is asking for, and we feel it needs to be
on the context of clarified. Are we making sure that access that is
interactions (formerly granted to the actual person the request was
PR.AC-6) made for?

PR.AA-06 Account activities and We think this needs to be clarified. “Account
access events are audited activities” can mean almost anything. | don't
and monitored to enforce think we want an organization to log everything
authorized access (formerly
PR.AC-1 and PR.AC-3)

We also want to be careful to use the word
“audited” by itself, as many would interpret this
as being part of a formal IT Audit. “Logged” and
“Reviewed” are useful synonyms, depending on
the scenario.

As a monitoring control, should this be a part of
the DE category?

PR.AA-07 Physical access to assets is | We think we need to clarify that we mean “digital
managed, monitored, and assets”, and even so we may want to clarify that
enforced (formerly PR.AC-2 | we are referring to centralized assets such as
and PR.PT-4) servers and network equipment.

We don’t think we want to “manage, monitor and
enforce” access to client devices, for instance.

O3S3Nux.


May 2023, Stockholm

TRUESEC

DE.CM-03 Personnel activity and This is another control that confuses many
technology usage are customers (and consultants).
monitored to find adverse
cybersecurity events Similar to DE.CM-02, | think it’s possible to
(formerly DE.CM-3 and monitor personnel activity as a way to indicate a
DE.CM-7) threat to the digital environment, but it’s not
necessarily an adverse cybersecurity event.
DE.CM-06 External service providers We should decide: Either supply chain security
and the services they is its own subcategory and then it should be
provide are monitored to consolidated to ID.SC, or it needs to be part of
find adverse cybersecurity every other subcategory.
events (formerly DE.CM-6
and DE.CM-7)
RS-MA-01 The incident response plan An oddly worded control. The old language
is executed (formerly RS.RP- | (“Response plan is executed during or after an
1) incident”) was better, in our eyes.
Perhaps the control should make sure there is
such a thing as an incident response plan, and
that it’s a documented process.
RS.MA-04 Incidents are escalated or How is this different from DE.AE-08?
elevated as needed
(formerly RS.AN-2)
In our mind this control falls under Incident
Management, and logically belongs in the RS
category.
RS.AN-03 Analysis is performed to In our eyes this is two different
determine what has taken functions: Determining “What has taken place”
place during an incident and | is an incident management function, while
the root cause of the determining “the root cause” most frequently
incident belongs in a problem management function.
RS.CO-05 Voluntary information Most customers have a hard time figuring out
sharing occurs with external | what this means in reality.
stakeholders to achieve
broader cybersecurity
situational awareness
RC Restore assets and We would expect to see more controls related to
operations that were backups and DR to be part of this category.
impacted by a cybersecurity
incident.

O3S3Nux.


TRUESEC

May 2023, Stockholm

Suggestions for NIST Cybersecurity Framework 2.0
Truesec response

1. Background

We who work with CSF here at Truesec appreciate NIST’s efforts to improve the Cyber Security
Framework (CSF) to better reflect the cyber security landscape's rapid threat changes.

Truesec is a cyber security company that deals with a lot of incidents and works fulltime helping our
customers with improving its cyber security posture and complying with statutory requirements. CSF has
been a valuable resource for our customers, and we are pleased to have the opportunity to offer our
insights and recommendations to further improve the framework.

As Cybersecurity Strategists at Truesec we regularly perform what we call a Holistic Cybersecurity
Assessment, which is based on the NIST CSF 2.0 framework. This means we have put the controls in
the CSF 2.0 in front of a variety of customers of different sizes and lines of business.

We favor a broader definition of supply chain resilience that looks beyond technical cyber risk and takes
a broader approach to understanding what is needed to ensure continuity of service and operational
continuity against non-technical risks such as administration, management, transfer of ownership,
service degradation and concentration risk.

We have applied to the regulatory authorities' consideration of operational resilience the concept of
‘Resilience by Design', assumes supplier failure by default and takes a two-pronged approach to
mitigation associated risks which include, preventing supply chain failures (through cyber resilience
solutions); and a reduction in the risk and impact of supply chain failures.

2. Recommendations

We recommend that NIST expand the response and recover capabilities to include more granularity

incident management and recovery planning guidance. We see that many organizations are facing an
increasing number of cyber-attacks and must be prepared to respond and recover effectively. It would
be great if NIST could support with more detailed guidance on incident response and recovery planning,
it would really help organizations improve their cyber security resilience.

Another possibility for improvement would be to reassign some of the CSF subcategories to different
function areas. Make sure that all subcategories from the protection categories are included within the
recovery function.

This would allow for more accurate characterization of the organization's capacity and maturity, as well
as reducing the risk of abuse of subcategory scores in risk measurements. The above considerations
regarding risk measurements are particularly important because of the potential for incorrect reporting
and decision-making.

Because practitioners usually equate the Protect function with "prevention" it is common for
organizations to include PR scores as factors in estimation probability of loss event.

O3S3Nux.


May 2023, Stockholm

TRUESEC

recovery plan, contingency

plan) are communicated

and maintained (formerly

PR.IP-9)

PR.IR-O2 The organization's networks | The wording of this control is very general, and |
and environments are feel like it overlaps many of the other controls
protected from unauthorized | (which have more specific language in them).
logical access and usage
(formerly PR.AC-3, PR.AC-5,

PR.DS-7, and PR.PT-4) The old PR.AC-5 was an important control in that
it was one of the few places we could point to
network segregation and segmentation. If this
requirement still is part of this new control it’s not
obvious to me.

Development security (such as addressed by the
old PR.DS-7 control) needs to be a subcategory
of its own in our mind.

DE.AE-05 Incident alert thresholds are | It would be more clear if we continued using the
established term “Adverse Event” in this control (as we do in

the preceding DE.AE controls).

DE.AE-08 Adverse cybersecurity This sounds very similar to DE.AE-05. If it’s
events are categorized and _ | different it needs to be clarified.
potential incidents are
escalated for triage

It also may make more sense to consolidate with
RS controls such as RS.MA-03

DE.CM-01 Networks and network Good consolidation of controls.
services are monitored to
find adverse cybersecurity
events (formerly DE.CM-1,

DE.CM-4, DE.CM-5, and

DE.CM-7)

DE.CM-02 The physical environment is | The way it’s worded this is a bit
monitored to find adverse contradictory. An adverse even in the physical
cybersecurity events environment could constitute a threat to the

digital environment, but it’s not necessarily a
cybersecurity event.

e.g. someone opening the door to the wiring
closet.

O3S3Nux.


May 2023, Stockholm

TRUESEC

established based on mean “Cybersecurity strategy” here, where risk
organizational context, risk management is one component.

management strategy, and

priorities and are

communicated (formerly

ID.GV-1)

GV.PO-02 The same policies used While we would love to be able to push our own
internally are applied to policies and procedures onto all our suppliers, |
suppliers just don’t see it being realistic. | agree supply

chain security is critically important, but | would
prefer to see an organization have a structured
method and documented process with different
levels of security requirements for suppliers
based on the relationship, the number of
technical integrations and a classification of the
type of information that is exchanged.

ID.AM-01 Inventories of physical Should we look for devices that are “managed
devices managed by the by the organization” here, or those that are used
organization are maintained | to access the organization's applications and

information? In a BYOD scenario, for instance,
we still want to have insight into a user’s devices.

ID.AM-03 Representations of the Good consolidation of controls from 1.1
organization’s authorized
network communication and
network data flows are
maintained (formerly ID.AM-

3 and DE.AE1)

ID.AM-04 Inventories of external We think we need to modernize the language in
assets and suppliers are this control to make it clear that this includes
maintained laaS, PaaS, SaaS and cloud services as well as

Apps. Almost everything an organization does
today is on some level an “external asset”,
depending on how we define the term.

IT.AM-05 Assets are prioritized based | A lot of organizations we deal with get stuck on
on classification, criticality, the word “prioritized” in this control.
resources, and
organizational value

We would prefer it be worded something along
the lines of “Assets are classified based on
criticality and organizational value, and
operational and security resources are allocated
accordingly”.

O3S3Nux.


May 2023, Stockholm

GV.RM-07, GV.RM-
08

Risk management strategy
is reviewed and adjusted to
ensure coverage of
organizational requirements
and risks.

Effectiveness and adequacy
of cybersecurity risk
management strategy and
results are assessed and
reviewed by organizational
leaders

TRUESEC

This is the first example of controls which we feel
shouldn't be controls in themselves but should
be part of a maturity ladder for the associated
controls (Risk Management, in this case).

Surely the performance of a// controls should be
“reviewed and adjusted” and have their
“effectiveness and adequacy ... assessed and
reviewed”?

This is our major complaint about version 1.1 of
the NIST CSF: Some of what are referred to as
controls are actually measures of maturity rather
than actual controls. In some cases there is a
question of whether the process is documented,
but not in all. In other cases there is a questions
of whether the process is improved upon
continually, but not in all.

GV.RR Cybersecurity roles and This is another area which we feel come closer
responsibilities are to measuring maturity than providing actual
coordinated and aligned cybersecurity. We want to have roles and
with all internal and external | responsibilities identified for a// controls, in our
stakeholders to enable mind.
accountability, performance
assessment, and continuous
improvement (formerly
ID.GV-2)

GV.RR-03 Roles and responsibilities We think this belongs more in the area of
for customers, partners, and | Organizational Context rather than RR, which to
other third-party me has a somewhat more limited scope.
stakeholders are
established and
communicated (formerly
ID.AM-6)

GV.RR-07 Cybersecurity is included in | It's unclear what is included in this control,
human resources practices | outside of what is expressed in the PR.AT
(e.g., training, subcategory.
deprovisioning, personnel
screening) (formerly PR.IP-

11)
GV.PO-01 Policies, processes, and We feel like some organizations will stumble on

procedures for managing
cybersecurity risks are

the word “risk” here. We are talking about “risk
management strategy”, but | think we actually

O3S3Nux.


TRUESEC

May 2023, Stockholm

3. Regulations and other frameworks

Truesec recommends that NIST provide more detailed guidance on how CSF 2.0 can be integrated with
other cybersecurity standards and frameworks, e.g., ISO 27001, IEC 62443, NIST SP 800-171 and
Cloud Security Alliance CMM.

Many organizations must adhere to multiple frameworks and standards for cybersecurity and being able
to offer extended guidance on how to implement CSF 2.0 alongside standards and the other
frameworks really helps reduce the overall cost and effort required to comply.

Truesec recommends that NIST adapt CSF 2.0 to the EU's General Data Protection Regulation (GDPR)
and the EU's NIS 2 directive and provide more.

Aligning CSF 2.0 with other standards and frameworks will help promote global cybersecurity best
practices and facilitate compliance with multiple regulatory requirements using a common cybersecurity
framework.

Truesec also suggests that NIST should develop more detailed guidance on how to measure the
effectiveness of using CSF 2.0. Organizations must understand the effectiveness of their cyber security
program and be able to track progress made over time. It would provide more guidance on how to
measure the effectiveness of cybersecurity programs and help organizations identify areas of
improvement and optimize their cyber security resources.

4. Feedback on the current concept paper

CTION TEXT FEEDBA'

Gv We agree with breaking this out as its own

category.

GV.OC The organization's risk We feel like the focus here is too much on
context, including mission, Cybersecurity Risk Management. A lot of smaller
mission priorities, organizations do not have a formalized risk
stakeholders, objectives, process, but they may still perform measures

and direction, is understood | according to the controls in this sub-category.
(formerly ID.BE)

GV.OC-01 Organizational mission is We would prefer a focus on alignment between
understood in order to IT and the rest of the organization rather than
prioritize cybersecurity risk having this control be about IT understanding the
management (formerly organizational mission.

ID.BE-2 and |ID.BE-3)

GV.OC-04 Critical objectives, Together we need to clarify how this control is
capabilities, and services different from GV.OC-01.

that stakeholders expect are
determined and
communicated (formerly
ID.BE-4 and ID.BE-5)

O3S3Nux.