Notice2024-31479
Notice of Availability of Security Requirements for Restricted Transactions Under Executive Order 14117
Primary source
Metadata and text below are from the Federal Register, a public-domain U.S. government work. Always verify the official published version before relying on it for any legal matter.
Published
January 8, 2025
Issuing agencies
Homeland Security Department
Abstract
CISA is announcing publication of finalized security requirements for restricted transactions pursuant to Executive Order (E.O.) 14117, "Preventing Access to Americans' Bulk Sensitive Personal Data and United States Government-Related Data by Countries of Concern." In October 2024, CISA published proposed security requirements for restricted transactions which would apply to classes of restricted transactions identified in regulations issued by the Department of Justice (DOJ). CISA solicited comment on those proposed security requirements and considered that public feedback when developing the final security requirements. This notice also provides CISA's responses to the public comments received.
Full Text
<html>
<head>
<title>Federal Register, Volume 90 Issue 5 (Wednesday, January 8, 2025)</title>
</head>
<body><pre>
[Federal Register Volume 90, Number 5 (Wednesday, January 8, 2025)]
[Notices]
[Pages 1528-1536]
From the Federal Register Online via the Government Publishing Office [<a href="http://www.gpo.gov">www.gpo.gov</a>]
[FR Doc No: 2024-31479]
-----------------------------------------------------------------------
DEPARTMENT OF HOMELAND SECURITY
[Docket No. CISA-2024-0029]
Notice of Availability of Security Requirements for Restricted
Transactions Under Executive Order 14117
AGENCY: Cybersecurity and Infrastructure Security Agency (CISA), DHS.
ACTION: Notice of availability
-----------------------------------------------------------------------
SUMMARY: CISA is announcing publication of finalized security
requirements for restricted transactions pursuant to Executive Order
(E.O.) 14117, ``Preventing Access to Americans' Bulk Sensitive Personal
Data and United States Government-Related Data by Countries of
Concern.'' In October 2024, CISA published proposed security
requirements for restricted transactions which would apply to classes
of restricted transactions identified in regulations issued by the
Department of Justice (DOJ). CISA solicited comment on those proposed
security requirements and considered that public feedback when
developing the final security requirements. This notice also provides
CISA's responses to the public comments received.
DATES: January 8, 2025.
ADDRESSES: Docket: For access to the docket to read background
documents or comments received, go to <a href="http://www.regulations.gov">www.regulations.gov</a>, and insert
the docket number, CISA-2024-0029, into the ``Search'' box, and follow
the prompts.
FOR FURTHER INFORMATION CONTACT: Alicia Smith, Senior Policy Counsel,
Cybersecurity and Infrastructure Security Agency,
<a href="/cdn-cgi/l/email-protection#22676d71474157504b565b7047535162414b51430c464a510c454d54"><span class="__cf_email__" data-cfemail="88cdc7dbedebfdfae1fcf1daedf9fbc8ebe1fbe9a6ece0fba6efe7fe">[email protected]</span></a>, 202-316-1560.
SUPPLEMENTARY INFORMATION:
I. Background
On February 28, 2024, the President issued E.O. 14117 entitled
``Preventing Access to Americans' Bulk Sensitive Personal Data and U.S.
Government-Related Data by Countries of Concern'' (the ``Order''),
pursuant to his authority under the Constitution and laws of the United
States, including the International Emergency Economic Powers Act (50
U.S.C. 1701 et seq.) (``IEEPA''), the National Emergencies Act (50
U.S.C. 1601 et seq.), and section 301 of Title 3, United States Code.
In the Order, the President expanded the scope of the national
emergency declared in E.O. 13873 of May 15, 2019, ``Securing the
Information and Communications Technology and Services Supply Chain,''
and further addressed the national emergency with additional measures
in E.O. 14034 of June 9, 2021, ``Protecting Americans' Sensitive Data
from Foreign Adversaries.'' Specifically, Section 2(a) of E.O. 14117
directs the Attorney General, in coordination with the Secretary of
Homeland Security and in consultation with the heads of relevant
agencies, to issue, subject to public notice and comment, regulations
that prohibit or otherwise restrict United States persons from engaging
in any acquisition, holding, use, transfer, transportation, or
exportation of, or dealing in, any property in which a foreign country
or national thereof has any interest (``transaction''), where the
transaction: (i) involves bulk sensitive personal data or United States
Government-related data, as defined by final rules implementing the
Order; (ii) is a member of a class of transactions that has been
determined by the Attorney General to pose an unacceptable risk to the
national security of the United States because the transactions may
enable countries of concern or covered persons to access bulk sensitive
personal data or United States Government-related data in a manner that
contributes to the national emergency described in the Order; and (iii)
meets other criteria specified by the Order.\1\
---------------------------------------------------------------------------
\1\ The other criteria do not directly impact the development of
the security requirements but are related to DOJ's implementation of
the Order's directive via their regulations. See E.O. 14117, sec.
2(a)(iii)--(v), 89 FR 15421, 15423 (Mar. 1, 2024).
---------------------------------------------------------------------------
Among other things, the Order, at Section 2(c), instructs the
Attorney General, in coordination with the Secretary of Homeland
Security and in consultation with the heads of relevant agencies, to
issue regulations identifying specific categories of transactions
(``restricted transactions'') that meet the criteria described in (ii)
above for which the Attorney General determines that security
requirements, to be established by the Secretary of Homeland Security
through the Director of CISA, adequately mitigate the risks of access
by countries of concern or covered persons \2\ to bulk sensitive
personal data
[[Page 1529]]
or United States Government-related data. In turn, Section 2(d) directs
the Secretary of Homeland Security, acting through the Director of
CISA, to propose, seek public comment on, and publish those security
requirements. Section 2(e) delegates to the Secretary of Homeland
Security the President's powers under IEEPA as necessary to carry out
Section 2(d).
---------------------------------------------------------------------------
\2\ Section 2(c)(iii) of the Order requires the Attorney General
to identify, with the concurrence of the Secretaries of State and
Commerce, countries of concern and, as appropriate, classes of
covered persons for the purposes of the Order.
---------------------------------------------------------------------------
On October 29, 2024, CISA published a Federal Register notice,
Request for Comment on Security Requirements for Restricted
Transactions Under Executive Order 14117 (the ``October 29 Request for
Comment''), announcing the release of the ``Proposed Security
Requirements for Restricted Transactions'' \3\ directed by E.O. 14117
Section 2(d) and requesting public comment on the proposal. See 89 FR
85976. The proposed security requirements were developed to apply to
the classes of restricted transactions identified in DOJ's notice of
proposed rulemaking (NPRM), ``Provisions Pertaining to Preventing
Access to U.S. Sensitive Personal Data and Government-Related Data by
Countries of Concern or Covered Persons,'' and published in the Federal
Register on the same day as the proposed security requirements. See 89
FR 86116.
---------------------------------------------------------------------------
\3\ The proposed security requirements were posted at <a href="https://www.cisa.gov/resources-tools/resources/proposed-security-requirements-restricted-transactions">https://www.cisa.gov/resources-tools/resources/proposed-security-requirements-restricted-transactions</a>.
---------------------------------------------------------------------------
The DOJ NPRM proposed to require, consistent with E.O. 14117, that
United States persons engaging in restricted transactions must comply
with the final security requirements by incorporating the standards by
reference. See proposed 28 CFR 202.248, 202.401, 202.402.
The security requirements were divided into two sections:
organizational- and covered system-level requirements (Section I) and
data-level requirements (Section II). The listed requirements were
selected with the intent of directly mitigating the risk of access to
covered data, with additional requirements included to ensure effective
governance of that access, as well as approaches for establishing an
auditable basis for compliance purposes. The security requirements
further included a definitions section. To the extent the requirements
used a term already proposed to be defined in the DOJ rulemaking,
CISA's use of that term in the security requirements would carry the
same meaning. The October 29 Request for Comment described the proposed
security requirements and definitions, and further provided a non-
exhaustive list of twelve questions to assist members of the public in
formulating their comments.
CISA received 24 comments on the proposed security requirements and
considered them while developing the final security requirements.
Comments submitted in response to the October 29 Request for Comment
are available in the docket associated with this notice available at
<a href="https://www.regulations.gov">https://www.regulations.gov</a> (Docket CISA-2024-0029). DOJ's NPRM
received 75 comments, which are available in the docket associated with
that NPRM at <a href="https://www.regulations.gov">https://www.regulations.gov</a> (Docket DOJ-NSD-2024-0004-
0001). DOJ shared comments with CISA that DOJ received in response to
the NPRM that provided feedback that could impact the security
requirements. These comments include one confidential comment that
contained CISA equities and was provided to DOJ by a foreign
government.
II. Response to Public Comments
A. In General
CISA reviewed and considered all comments received in response to
the October 29 Request for Comment. Overall, many commenters
appreciated the flexibility that CISA provided regarding implementation
of the security requirements as well as the use of existing frameworks.
Some commenters, however, felt that application of the security
requirements as proposed may be burdensome. Others requested
clarification of certain definitional terms and the scope of the
security requirements. Some commenters also provided specific feedback
on technical elements of the proposed security requirements. CISA
addresses those comments in the following sections and explains where
CISA made changes to its proposal to address the feedback received.\4\
---------------------------------------------------------------------------
\4\ CISA also participated in several stakeholder engagement
sessions organized by DOJ. While CISA did not receive written
feedback during these sessions, many points raised by stakeholders
in these sessions were echoed in the written comments received in
response to the October 29 Request for Comment.
---------------------------------------------------------------------------
B. Specific Topics
1. Responses to Questions in CISA's Notice
In the October 29 Request for Comment, CISA included a non-
exhaustive list of twelve questions to assist the public in providing
comments in response to the notice. See 89 FR 85980. The comments CISA
received on those questions, and CISA's adjudication of those comments,
are summarized below.
Robustness, Burden, and Flexibility of Proposed Security Requirements
In the October 29 Request for Comment, CISA solicited comments on
whether the proposed security requirements were sufficiently robust to
mitigate the risks of access to Americans' bulk sensitive personal data
or government-related data by countries of concern (question 1). CISA
also asked whether the security requirements provided sufficient
flexibility for the types of restricted transactions typically engaged
in by U.S. entities to avoid overburdening commercial activities not
involving covered data (question 3).\5\
---------------------------------------------------------------------------
\5\ Other aspects of question 3 related to the clarity and
specificity of the security requirements are addressed separately
below.
---------------------------------------------------------------------------
Many commenters either suggested or explicitly stated that the
security requirements were sufficiently robust to mitigate the risk of
access to covered data by countries of concern, but may be too
prescriptive or burdensome to implement.\6\ For instance, while
commenters generally appreciated CISA's use of established frameworks
like the National Institute of Standards and Technology (NIST)
Cybersecurity Framework (CSF), a small number of commenters questioned
whether CISA's security requirements extend beyond those frameworks and
suggest more prescriptive mandates that may be difficult to
implement.\7\ Other commenters acknowledged that organizations that
will be required to comply with this rule already employ some level of
sophisticated cyber defense measures, but it will take time for
organizations to understand, interpret, and fully implement the
requirements,\8\ particularly for small- and medium-sized
businesses.\9\ One financial sector association noted that, for
financial institutions with large, diverse networks, implementation
would be resource-intensive and may not be feasible in some
circumstances.\10\
---------------------------------------------------------------------------
\6\ See, e.g., Comment submitted by Information Technology
Industry Council, CISA-2024-0029-0015; Comment submitted by
ACT[verbar]The App Association, CISA-2024-0029-0001.
\7\ See, e.g., Comment submitted by Bank Policy Institute, CISA-
2024-0029-0011.
\8\ See, e.g., Comment submitted by U.S. Chamber of Commerce,
CISA-2024-0029-0017.
\9\ See, e.g., Comment submitted by Consumer Technology
Association, CISA-2024-0029-0013.
\10\ See, e.g., Comment submitted by Bank Policy Institute,
CISA-2024-0029-0011.
---------------------------------------------------------------------------
Several commenters expressed appreciation for the flexibility
embedded in the data-level requirements in Section II, noting that
flexibility encourages a risk-based but
[[Page 1530]]
tailored approach to securing transactions, and would help ensure the
requirements stay up-to-date as standards are updated and technology
advances.\11\ For that reason, many commenters encouraged CISA to
extend such flexibility to the organizational- and system-level
requirements in Section I.\12\
---------------------------------------------------------------------------
\11\ See, e.g., Comment submitted by Workday, CISA-2024-0029-
0019.
\12\ See, e.g., Comment submitted by U.S. Chamber of Commerce,
CISA-2024-0029-0017; Comment submitted by Workday, CISA-2024-0029-
0019; Comment submitted by Information Technology Industry Council,
CISA-2024-0029-0015; Comment submitted by ACT[verbar]The App
Association, CISA-2024-0029-0001.
---------------------------------------------------------------------------
Some commenters suggested that organizations be permitted to employ
alternative compensating controls on covered systems where requirements
are otherwise infeasible.\13\ Others urged CISA to model the security
requirements on existing regulatory regimes administered by other U.S.
government agencies (e.g., the Federal Communications Commission and
the Department of Commerce), which direct organizations to develop
cyber risk management plans aligned with the CSF, or create avenues for
reciprocity in instances where U.S. entities entering into restricted
transactions are subject to and have demonstrated compliance with
certain existing data or cybersecurity regulatory regimes.\14\
Commenters suggested that not providing the requested flexibility,
modeling, or reciprocity would increase the burden on parties engaged
in restricted transactions.\15\
---------------------------------------------------------------------------
\13\ See, e.g., Comment submitted by Information Technology
Industry Council, CISA-2024-0029-0015.
\14\ See, e.g., Comment submitted by CTIA--The Wireless
Association and NCTA--The internet & Television Association, CISA-
2024-0029-0021; Comment submitted by USTelecom--The Broadband
Association, CISA-2024-0029-0018.
\15\ See, e.g., Comment submitted by Information Technology
Industry Council, CISA-2024-0029-0015; Comment submitted by U.S.
Chamber of Commerce, CISA-2024-0029-0017; Comment submitted by
Workday, CISA-2024-0029-0019; Comment submitted by Oracle, CISA-
2024-0029-0014.
---------------------------------------------------------------------------
CISA considered these options but ultimately concluded that the
overall structure and approach of the original security requirements
provide as much flexibility as reasonably practicable while still
addressing the national security risks identified by DOJ. CISA assesses
that granting reciprocity where U.S. entities entering into restricted
transactions are subject to and have demonstrated compliance with
certain existing data or cybersecurity regulatory regimes is not a
workable solution to address the national security risks associated
with restricted transactions. Other regulatory regimes are not
necessarily designed to address the specific risks at issue here.
Therefore, CISA cannot assume that a cyber risk management plan
developed to comply with another regulatory regime will necessarily be
designed in a way that mitigates the risk of covered persons or
countries of concern gaining access to covered data. Further, even if
CISA were to do a comparison to map the security requirements against
the requirements in other regulatory regimes and identify existing
regulatory regimes that cover all of the security requirements today,
CISA could not control for the possibility that those regulations may
be changed to no longer align with the security requirements,
particularly in light of the different goals of these regulations.
That said, CISA is taking a number of steps to make the final
security requirements less burdensome and address specific concerns
about technical feasibility or ease of implementation with respect to
individual requirements. Specifically in the following sections of the
security requirements:
<bullet> I.A.1.a: CISA acknowledges the challenge of maintaining an
accurate asset inventory in dynamic environments, and revises I.A.1.a
to require documented inventories only ``to the maximum extent
practicable,'' and eliminated the requirement to inventory MAC
addresses, which is not possible in some situations such as cloud
environments. CISA also clarified that these inventories can themselves
be dynamically curated.
<bullet> I.A.3: CISA addresses commenters' concerns about the
rigidity, utility, and feasibility of the proposed vulnerability
remediation timelines, and substantially revises the vulnerability
remediation timelines to prioritize critical assets and allow entities
engaged in restricted transactions to remediate vulnerabilities within
a risk-informed span of time. CISA assesses that these new requirements
appropriately balance the risks of exploitation of vulnerable covered
systems with the operational burden of patching systems.
<bullet> I.A.5: In response to comments about the level of effort
required to implement the security requirements across large
enterprises,\16\ CISA revises the requirement for any network
interfacing with a covered system to facilitate visibility into
connections between assets to be implemented ``to the extent
technically feasible'' instead of ``to the maximum extent
practicable.''
---------------------------------------------------------------------------
\16\ See, e.g., Comment submitted by U.S. Chamber of Commerce,
CISA 2024-0029-0017.
---------------------------------------------------------------------------
<bullet> I.A.6: To grant organizations additional flexibility in
how they choose to perform change management, CISA significantly
reduces the burden around installation of new hardware and/or software
by removing the reference to ``firmware'' and requirements for either
allowlists or approvals to address specific software versions.\17\
---------------------------------------------------------------------------
\17\ See, e.g., Comment submitted by Bank Policy Institute,
CISA-2024-0029-0011.
---------------------------------------------------------------------------
<bullet> I.B.2: CISA seeks to introduce flexibility and alleviate
confusion around the meaning of the term ``immediately'' by revising
the requirement to revoke access to covered systems for terminated
employees or employees with changed roles from ``immediately'' to
``promptly,'' with clarifying examples of what would be considered
``promptly.'' CISA recognizes the ambiguity of ``immediately'' and
assesses that the clarifying examples appropriately balance operational
complexity and the security benefits of promptly revoking access to
covered data upon termination or change of an employee's role.
<bullet> I.B.3: Acknowledging the term ``disabled'' is ambiguous
and that commenters requested CISA clarify that the requirement was to
implement a process, CISA clarifies language around security log
retention to state that organizations are required to implement a
notification process when security logs are not being produced and/or
retained as expected rather than referring to logs being disabled.
<bullet> I.B.4 [removed]: To reduce burden on implementing
organizations, CISA removes the requirement to maintain organizational
policies and processes to ensure that unauthorized media and hardware
are not connected to covered assets. CISA assesses that in light of
CISA's updates to the definition of the term ``covered system,'' the
other requirements are sufficient to protect covered systems, and this
requirement is no longer necessary. [Note that, as a result of this
deletion, requirements I.B.5 and 6 are now I.B.4 and 5.]
<bullet> I.B.5 [renumbered I.B.4] CISA clarifies that deploying
``deny by default'' is not as burdensome as some commenters assumed by
noting the idea of ``deny by default'' does not only include the use of
network firewalls but may also be implemented in other ways, such as
via authentication of users and other information systems to the
covered system. CISA assesses that, as clarified, this requirement is
important to ensure that unauthorized systems and users do not
inappropriately have access to data within covered systems.
[[Page 1531]]
At the same time, when crafting the proposed security requirements,
CISA did so with the goal of balancing regulatory burden, technical
feasibility, and flexibility with the underlying national security
needs. As such, CISA determined that certain recommendations, such as
extending the flexible implementation approach in the data-level
requirements to the organizational- and system-level requirements,
would undermine security to the detriment of the overall regime. CISA
notes that the organizational- and system-level requirements are scoped
only to a limited subset of covered systems that interact with data of
particular sensitivity (per the DOJ rule) and are neither considered
nor intended to comprise the entirety of an effective cybersecurity
program; rather, they are a selected set of practices and preconditions
that CISA concluded are necessary to effectively implement the data-
level requirements.
Clarifying Terms and Applications
CISA asked whether the security requirements were sufficiently
clear for organizations to verify compliance (question 3) and/or
sufficient to provide U.S. persons engaged in restricted transactions
confidence that the logical and physical access controls are
sufficiently managed to deny access to covered persons or countries of
concern (question 2). CISA also asked about areas where additional
interpretive guidance would be helpful to U.S. entities in determining
which data-level requirements should be applied based on the nature of
the transaction and the data at hand (question 6).
Some commenters requested that CISA clarify the definition of
``covered system,'' specifically as it relates to endpoints (e.g.,
workstations/laptops), to make clear that the definition only applies
to systems that handle covered data qualified as bulk under DOJ's
definition.\18\ One commenter observed that ``this interpretation is of
critical importance as it represents the difference between
organizations considering how they secure a collection of specific
systems as opposed to an enterprise-wide retooling, the latter of which
would be extremely challenging and unnecessarily burdensome.'' \19\
---------------------------------------------------------------------------
\18\ See, e.g., Comment submitted by U.S. Chamber of Commerce,
CISA-2024-0029-0017.
\19\ Comment submitted by U.S. Chamber of Commerce, CISA-2024-
0029-0017.
---------------------------------------------------------------------------
In response, CISA revises the definition of ``covered system'' to
reflect that a covered system is limited to systems that interact with
covered data in bulk form and not user endpoints that ordinarily read
or view sensitive personal data (other than sensitive personal data
that constitutes government-related data) but do not ordinarily
interact with sensitive personal data in bulk form. Of note, because
government-related data is not subject to any bulk data threshold in
the DOJ rulemaking, any system that interacts with government-related
data would still be considered a covered system. Organizations
implementing the security requirements need to carefully consider how
this clarification applies to their particular information systems,
transactions, and manners of interacting with covered data.
CISA also received comments requesting that, in defining ``covered
systems'' and ``covered data,'' CISA include an explicit reference to
exempt transactions by specifically exempting data that is subject to
an exemption from the definition of covered systems and covered
data.\20\
---------------------------------------------------------------------------
\20\ See, e.g., Comment submitted by WorkDay, CISA-2024-0029-
0019.
---------------------------------------------------------------------------
CISA notes that both definitions in the security requirements
require the system and/or data to be used ``as part of a restricted
transaction.'' Per the definitions in the DOJ rulemaking, an exempt
transaction is definitionally not a restricted transaction and thus an
information system that exclusively participates in transactions with
covered persons that are exempt (e.g., an internal human resources
system that only deals in data subject to the corporate group
exemption) would not be considered a covered system under the
definition. Because CISA assesses that the definition already excludes
such systems, CISA does not make any changes to the definition in
response to these comments. However, consistent with changes to the DOJ
rulemaking to switch the order of the terms ``government-related data''
and ``bulk U.S. sensitive personal data'' to avoid the possibility of
confusion as to whether the bulk thresholds apply to government-related
data, CISA has revised the definition of ``covered data'' to switch the
order of these terms in the definition.
Mapping to Other Frameworks
In the October 29 Request for Comment, CISA inquired about the
utility of mapping requirements to other standards, such as ISO/IEC
27001 or NIST Special Publication 800-171 (question 12). Some
commenters recommended this approach, noting that such mapping would be
helpful to allow organizations to better understand how existing
processes or controls they are already using can be applied and
understood in the context of the security requirements.\21\ Other
commenters suggested additional candidates (e.g., CISA's Encrypted DNS
Implementation Guidance).\22\
---------------------------------------------------------------------------
\21\ See, e.g., Comment submitted by Information Technology
Industry Council, CISA-2024-0029-0015; Comment submitted by
ACT[verbar]The App Association, CISA-2024-0029-0023.
\22\ See, e.g., Comment submitted by Infoblox, CISA-2024-0029-
0020.
---------------------------------------------------------------------------
CISA determined additional mapping is better suited to interpretive
guidance because these frameworks include detailed security control
sets, and such guidance will need to further clarify the intent and
extent of the mapping to these controls. CISA decided not to include
additional mapping in the final security requirements themselves but
remains open to providing additional mapping through future
interpretive guidance.
2. Other Comments on the Security Requirements
Extent to Which Covered Persons May Access Covered Data
Several commenters inquired if CISA's security requirements were
intended to prevent all access to covered data by covered persons or to
prevent unauthorized or unmitigated access.\23\ That is, commenters
sought clarity on whether any degree of access by covered persons to
covered data is permissible when implementing the security
requirements. Commenters noted, for instance, that the chapeau of
Section II of the security requirements indicated that entities were
required to prevent covered persons or countries of concern from
gaining access to covered data, which would appear to render the
transaction no longer covered by DOJ's rule.\24\ Commenters explained
that under their reading, the requirement to prevent access to covered
data by covered persons or countries of concern arguably takes the
transaction out of the DOJ rule's definition of restricted transaction
altogether.\25\ Commenters noted, however, that CISA's security
requirements were developed to suggest the efficacy of controls such as
data minimization, masking, and privacy-enhancing techniques in
mitigating the
[[Page 1532]]
risk of access to covered data by covered persons or countries of
concerns.
---------------------------------------------------------------------------
\23\ See, e.g., Comment submitted by U.S. Chamber of Commerce,
CISA-2024-0029-0017; Comment submitted by the Consumer Technology
Association, CISA-2024-0029-0013; Comment submitted by National
Foreign Trade Council, CISA-2024-0029-0022.
\24\ See, e.g., Comment submitted by U.S. Chamber of Commerce,
CISA-2024-0029-0017.
\25\ See, e.g., Comment submitted by Bank Policy Institute,
CISA-2024-0029-0011.
---------------------------------------------------------------------------
To address the feedback raised in these comments, CISA affirms that
the security requirements are meant to prevent access to covered data
by countries of concern unless specific efforts outlined in the
security requirements are taken to mitigate the national security risks
associated with such access.
More specifically, in the chapeau to the data-level requirements in
Section II, CISA proposed that U.S. persons should ``implement a
combination of the following mitigations that, taken together, is
sufficient to fully and effectively prevent access to covered data by
covered persons and/or countries of concern.'' CISA proposed that this
approach would mitigate the national security risks associated with
access to covered data by covered persons and/or countries of concern.
As described in the Order, DOJ's NPRM, and CISA's proposed security
requirements and the October 29 Request for Comment, access to covered
data by covered persons and/or countries of concern poses a range of
threats to national security and foreign policy, including providing
countries of concern with information they need or can use to engage in
malicious cyber-enabled activities and malign foreign influence;
blackmail and espionage against U.S. persons; intimidate activists,
academics, journalists, dissidents, political figures, or members of
non-governmental organizations or marginalized communities; curb
political opposition; limit freedoms of expression, peaceful assembly,
or association; or enable other forms of suppression of civil
liberties. See 89 FR 85978. In the security requirements, CISA proposed
to address these risks at the data level by requiring that covered
persons be denied access to the underlying covered data--either by
denying access outright or by only allowing covered persons access to
covered data that had been manipulated in a way (e.g., encryption, de-
identification) that would effectively mitigate the risks from
permitting direct access to the underlying data.
In response to comments on this issue, CISA clarifies the chapeau
language for the data-level requirements in the final security
requirements to state that U.S. persons should ``implement a
combination of the following mitigations that, taken together, is
sufficient to fully and effectively prevent access to covered data that
is linkable, identifiable, unencrypted, or decryptable using commonly
available technology by covered persons and/or countries of concern.''
This clarification establishes that the adoption of the data-level
requirements does not mean no access to covered data is permissible,
but that certain data-level requirements must be implemented to achieve
a level of minimization of that access and/or covered data sufficient
to mitigate the national security risks identified by DOJ.
Under the DOJ regulation, covered data transactions include
regulated categories of transactions that involve covered person or
country of concern access to covered data, regardless of whether the
data is encrypted, anonymized, pseudonymized, or de-identified. As DOJ
explains in its rulemaking, encryption, pseudonymization, and de-
identification are not completely effective in all cases and can in
some cases be reversed or undermined. At the same time, the
transactions identified by DOJ as restricted have important economic
value relative to their national security risk and are allowed to
proceed if they meet the CISA-developed security requirements. CISA was
thus tasked with determining an appropriate balance on mitigating the
national security risks associated with such access to covered data.
While CISA considered whether it could adopt other options for
data-level requirements that would still permit access to at least some
unmitigated covered data to covered persons, CISA ultimately determined
that allowing covered persons or countries of concern access to covered
data without application of an effective combination of techniques
identified in the data-level requirements (such as pseudonymization,
de-identification, aggregation, and encryption) would not effectively
mitigate the unacceptable national security risks identified by DOJ
resulting from enabling access to such data by covered persons and
countries of concern. Thus, the final security requirements permit
organizations to undertake restricted transactions either by directly
denying covered person/country of concern access to covered data itself
or by applying techniques such as pseudonymization, de-identification,
aggregation, and encryption in the manner prescribed in the security
requirements to reduce the risks to national security while still
allowing for a form of access to an appropriately mitigated version of
the covered data (in conjunction with implementation of the
organizational- and system-level requirements).
As noted in the DOJ regulation's definition of access, the
implementation of data processing techniques (as outlined in the data-
level requirements) before sharing data is irrelevant to the
determination of whether a transaction involves ``access'' and is thus
a covered data transaction. However, restricted transactions are
explicitly permitted to proceed through application of the security
requirements, effectively mitigating the national security risks
identified by DOJ.
The following examples discuss several applicable scenarios. In all
cases (with the exception of example 4), these examples assume that the
organization has conducted the required data risk assessment required
in Section I.C of the security requirements and determined that the
specific requirements implemented are sufficient to ``fully and
effectively prevent access to covered data that is linkable,
identifiable, unencrypted, or decryptable using commonly available
technology by covered persons and/or countries of concern.'' The
examples (with the exception of example 4) also assume that the
organization complies with other applicable requirements in the DOJ's
rule.
Example 1: A U.S. person retains a cloud provider headquartered in
a country of concern to store encrypted covered data through a vendor
agreement. Per the DOJ rulemaking, the cloud provider is a covered
person, and such a transaction would constitute a covered data
transaction. The U.S. person implements the security requirements,
including the requirements around encryption and encryption keys. Such
a transaction could proceed if the U.S. person fully implements the
security requirements.
Example 2: A U.S. business that deals in covered data is executing
an investment agreement with a covered person. The investment agreement
provides that the U.S. business will share with the covered person
investor sensitive personal data about individual consumers that meets
DOJ's relevant bulk threshold. The organization implements the security
requirements before sharing data with the covered person investor (for
example by aggregating data and/or de-identifying it along with
implementing the other security requirements). Such data is still
considered covered data. The sharing of data in the investment
agreement is still a restricted transaction but can proceed due to the
implementation of the security requirements.
Example 3: A U.S. organization hires a covered person in a country
of concern (or retains their services by contract) into a role whose
duties include access to covered data. As part
[[Page 1533]]
of entering into the employment agreement (or vendor agreement), the
organization implements the security requirements (including the
organizational- and system-level requirements) and only shares de-
identified covered data with the covered person in a way that minimizes
linkability in accordance with the security requirements. Such a
restricted transaction would be allowed to proceed.
Example 4: Same as Example 3, except that instead of de-identifying
the covered data, the organization knowingly authorizes the employee or
vendor to have access to covered data (e.g., to bulk U.S. sensitive
personal data) without applying efforts to de-identify, pseudonymize,
encrypt, or otherwise implement the data-level security requirements.
In this example, the U.S. organization knowingly gave a covered person
access to covered data through an employment or vendor agreement
without implementing the security requirements. As such, the U.S.
organization knowingly engaged in a restricted transaction that fails
to comply with the requirements of subpart D of 28 CFR part 202 and
thus is engaged in a covered data transaction that is not authorized
pursuant to 28 CFR 202.401.
Example 5: Same as Example 3, except the employee or vendor's
duties do not require access to covered data but do include general
access to the organization's networks and information systems,
including potentially covered systems, within which covered data may be
stored. The organization implements the security requirements,
including the data-level requirement of denying access to covered data
for that covered person. Because the transaction could afford a covered
person access to covered data, but the organization employed controls
to prevent it, such an employment or vendor agreement could proceed as
a restricted transaction.
Vulnerability Management (I.A.3)
In the proposed security requirements, CISA proposed that
organizations should patch vulnerabilities that are known to be
exploited, critical, or high within an outlined timeframe. CISA
proposed this approach for consistency with the standard to which
Federal Agencies are held under Binding Operational Directives (BOD)
22-01 and 19-02. CISA received several comments on this subject
suggesting that CISA's approach was technically challenging to
implement and not sufficiently risk-based.\26\ One commenter, for
instance, stated that the remediation timelines proposed were too
aggressive, and noted that NIST Special Publication 800-53 directs
remediation to occur in accordance with a risk-assessment rather than
prescribing specific timelines.\27\ Another commenter recommended that
CISA change the timelines for remediation to no shorter than 30 days,
stating that CISA's proposed timeframes of 14 and 15 days were
unreasonable and impracticable.\28\ Commenters indicated that this
requirement may cause organizations to expend their limited resources
addressing vulnerabilities that do not necessarily pose the greatest
risk to their organizations.\29\
---------------------------------------------------------------------------
\26\ See, e.g., Comment submitted by Bank Policy Institute,
CISA-2024-0029-0011; Comment submitted by Consumer Technology
Association, CISA-2024-0029-0013; Comment submitted by USTelecom,
CISA-2024-0029-0018; Comment submitted by Information Technology
Industry Council, CISA-2024-0029-0015.
\27\ See, e.g., Comment submitted by Bank Policy Institute,
CISA-2024-0029-0011
\28\ See, e.g., Comment submitted by Consumer Technology
Association, CISA-2024-0029-0013.
\29\ See, e.g., Comment submitted by the Bank Policy Institute,
CISA-2024-0029-0011.
---------------------------------------------------------------------------
CISA considered this feedback carefully and concluded that an
alternate approach to vulnerability management could effectively
respond to the identified risks while being less burdensome in
implementation. In the final security requirements, CISA adopts a new
approach that requires organizations to remediate known exploited
vulnerabilities (KEVs) in internet-facing systems in a risk-based
manner that prioritizes the most critical assets first, with all such
vulnerabilities remediated within 45 calendar days. This approach is
based on the approach to patching outlined in the CISA Cross-Sector
Cybersecurity Performance Goals (CPGs) and the CSF. To compensate for
the additional flexibility being provided through the revised
requirement, CISA determined that it was necessary to require that
entities engaged in restricted transactions establish a process to
evaluate, after patching, whether any internet-facing covered systems
with KEVs were compromised prior to the patch being applied. Based on
its operational experience, CISA notes that KEVs on internet-facing
systems are commonly exploited with access persisting beyond the time
of patching. A KEV is a vulnerability that is currently being
exploited, based on information known to CISA.\30\ Through this change,
CISA intends to reduce the operational burden of vulnerability
management and maximize its impact on addressing known cybersecurity
risks to covered systems.
---------------------------------------------------------------------------
\30\ See generally Cybersecurity and Infrastructure Security
Agency, Reducing the Significant Risk of Known Exploited
Vulnerabilities, <a href="https://www.cisa.gov/known-exploited-vulnerabilities">https://www.cisa.gov/known-exploited-vulnerabilities</a> (last visited Dec. 1, 2024) (listing CISA's
requirements for listing a KEV).
---------------------------------------------------------------------------
Multi-Factor Authentication and Password Length (I.B.1)
In the proposed security requirements, CISA proposed that
organizations should implement multi-factor authentication (MFA) for
access to covered systems or, if not technically feasible and/or
enforced, implement passwords of a minimum of 16 characters. CISA
proposed this approach based on the CSF and the CISA CPGs. Commenters
suggested that CISA's approach would be clearer if CISA incorporated
NIST Special Publication 800-63B (SP 800-63B)'s definition of
Authentication Assurance Levels (AALs) and only required 16-character
passwords if technically feasible.\31\
---------------------------------------------------------------------------
\31\ See, e.g., Comment submitted by Workday, CISA-2024-0029-
0019; Comment submitted by USTelecom--The Broadband Association,
CISA-2024-0029-0018.
---------------------------------------------------------------------------
In the final security requirements, CISA added a reference to
NIST's AAL definition to clarify that CISA considers any authenticator
that implements AAL2 or AAL3 (as defined in the latest version of SP
800-63B or any of its supplements) as qualifying as MFA for purposes of
this requirement. This includes syncable cryptographic authenticators
(colloquially known as ``passkeys''). However, CISA notes that ``Multi-
factor authentication'' is a broadly understood term in the industry
and declines to remove its use from the security requirements. CISA
also updates the requirement for 16-character passwords to instead
require 15-character passwords in situations without MFA. This change
reduces burden on organizations and aligns CISA's requirement with the
CPGs. However, CISA declines to further reduce the number of required
characters, even where 15-character passwords are not technically
feasible. This requirement is taken from the CISA CPGs where
sufficiently strong passwords are suggested for all password-protected
IT assets, with an understanding that some operational technology (OT)
assets may not be able to technically support such passwords. CISA does
not believe such OT assets are likely to host covered data and did not
receive any comments suggesting otherwise. CISA concludes that
information systems that host covered data be required to either
implement
[[Page 1534]]
MFA (including ``passwordless'' methods) or have 15-character minimum
passwords in instances where MFA is not technically feasible and/or
enforced (such as when MFA is partially enforced due to technical
limitations). CISA believes that organizations should implement MFA in
all situations where it is technically feasible to do so and where it
is not, must ensure 15-character passwords are used in covered systems.
CISA assesses that this approach is a reasonable requirement that is
well grounded in industry best practices. Technologies such as password
managers may be used to reduce the operational burden of such
passwords.
Access To Log Systems (I.B.3)
One commenter \32\ requested that CISA clarify whether authorized
access to the security logging system is intended to be limited to
those users who are authorized to access the covered system itself or,
more generally, users performing security duties in the organization.
---------------------------------------------------------------------------
\32\ See Comment submitted by The Business Software Alliance,
CISA-2024-0029-0024.
---------------------------------------------------------------------------
CISA declines to make any changes to the text of the final security
requirements in response to this comment, but notes that the security
requirements specify that users who access or modify such log data are
only required to be ``authorized and authenticated.'' CISA does not
intend that individuals who are ``authorized and authenticated'' to
access or modify collected logs must also be authorized to access
covered systems.
Data Risk Assessment (I.C)
Several commenters raised questions and concerns about the data
risk assessment. Some commentors were concerned about whether the risk
assessment was to be shared with DOJ or CISA, while others had some
concerns about the potential cost impact and compliance burden of
developing it. Others also noted that DOJ included audit and reporting
requirements in its rule and that the addition of another compliance
report under CISA's requirements would be too burdensome.\33\
---------------------------------------------------------------------------
\33\ See, e.g., Comment submitted by The Consumer Technology
Association, CISA-2024-0029-0013.
---------------------------------------------------------------------------
In response to these comments, and to deconflict with DOJ's audit
and reporting requirements, CISA makes minor changes to this
requirement, specifically clarifying this risk assessment is intended
for internal use only as a tool to inform data protection (not for
documentation or disclosure to a government agency), and, to further
reduce implementation burden, that documenting the assessment is not
required.\34\ CISA also supplies additional detail specifying that the
plan be reviewed internally by the organization.
---------------------------------------------------------------------------
\34\ CISA defers to DOJ regarding whether such a risk assessment
may be subject to audit or other review as part of compliance
aspects of the DOJ rulemaking.
---------------------------------------------------------------------------
Data-Level Requirements and What Constitutes ``Sufficiency'' (II,
Chapeau)
Comments pertaining to the data-level requirements were largely
positive, noting an appreciation for the level of flexibility that was
perceived by many to be in contrast with the system-level requirements.
For instance, one commenter said that allowing organizations
flexibility to determine which combination of data-level requirements
are sufficient to address risks, based on their unique risk profile
``presents the best chance of achieving Executive Order 14117's
ultimate objective to secure'' sensitive U.S. data.\35\ However, some
commenters took issue with the requirement to fully and effectively
prevent access to covered data, and requested guidance and/or
clarification about what constitutes a ``sufficient'' combination of
data-level requirements to prevent access. CISA also received some
feedback from interagency partners on further clarifying the specific
encryption requirements.
---------------------------------------------------------------------------
\35\ See, e.g., Comment submitted by Bank Policy Institute,
CISA-2024-0029-0011.
---------------------------------------------------------------------------
Given that commenters generally agreed that the data-level
requirements as written achieved their intended aim, CISA made only
minor revisions. Commenters asked CISA to clarify that requirements
around the version of Transport Layer Security (TLS) used were limited
to connections that were already using TLS, which CISA clarified by
including requirements for the version of TLS in II.B.1 rather than as
a separate requirement (II.B.2). CISA also consulted with other federal
agency partners on the topic of encryption and is adding an explanation
of what level of encryption CISA considers sufficient for the purposes
of these security requirements based on these consultations. CISA
recognizes the appeal of a prescriptive (and predictable) standard but
maintains there is no one-size-fits-all solution given the varied
nature of restricted transactions. Additionally, the question of what
is sufficient to prevent access is a compliance matter and not a
technical implementation matter. E.O. 14117 sec. 2(d)(ii) gives the
Attorney General authority to issue enforcement guidance regarding
these security requirements, in consultation with the Director of CISA.
CISA will coordinate with DOJ if it determines further guidance on the
meaning of ``sufficient'' is appropriate.
Framework Mapping
Many commenters expressed appreciation for the fact that CISA
leveraged existing, well-known cybersecurity and privacy frameworks,
and found the mapping between frameworks and specific requirements
especially helpful. However, some commenters expressed concern that
CISA's approach was not conducive to harmonizing cyber regulations to
the greatest degree practicable across the government and suggested
that CISA's mapping to the CSF, NIST's Privacy Framework (PF), and CPGs
may be confusing, noting that the CSF is the primary risk management
framework used by some organizations.
After considering these comments, CISA continues to assess that its
method of mapping the security requirements to the CSF, PF, and CPGs is
the optimal way to minimize the burden on organizations while still
allowing as much flexibility in implementation as possible.
First, as noted in the proposed security requirements and as CISA
has preserved in the final security requirements, references to these
frameworks are intended to help readers understand which aspects of
existing frameworks, guidance, or other resources the security
requirements are based upon; understanding and applying the security
requirements does not require a reader to understand and apply those
references. As such, the references should only serve to be a helpful
reference where readers find them useful, while those who find the
references confusing or who do not use these other resources as part of
their organizational compliance structure can disregard the mapping.
Second, the Order requires CISA to base its security requirements
on the CSF and the PF. CISA has evidenced compliance with this
requirement by reference to these frameworks explicitly. This means
that the only framework CISA could eliminate the mapping to is the
CPGs. Given that many commenters expressed appreciation for the CPG
mapping and that the CPGs are, themselves, based on the CSF, CISA
assesses that the inclusion of the CPGs should not be overly difficult
or confusing, especially for the cybersecurity personnel and designated
accountable officials responsible for ensuring that U.S. entities
engaging in
[[Page 1535]]
restricted transactions adhere to the final security requirements.
3. Out of Scope or Related to DOJ's NPRM
Several commenters raised questions, concerns, or feedback that
were outside of the authorities and direction provided to CISA in E.O.
14117. Commenters also raised issues that were related to the
implementation of DOJ's regulations rather than the proposed security
requirements themselves.
While CISA reviewed this feedback and shared relevant comments with
DOJ to consider as they drafted their final rule, issues specific to
the DOJ rule itself are beyond the scope of this notice. Conversely, in
some instances, DOJ received comments on its NPRM that more directly
related to CISA's proposed security requirements. Where DOJ shared such
comments with CISA, CISA reviewed and considered this feedback as part
of developing the final security requirements, as reflected above.
4. Continued Stakeholder Engagement
CISA also received a few comments requesting additional stakeholder
engagement on the development of these security requirements. For
example, one comment requested an extension of the comment period by 17
days to provide stakeholders extra time to provide robust and
considered input.
CISA appreciates the commenters' desire to provide the most useful,
robust, and thoughtful feedback possible in the time allotted for
comments. However, CISA decided not to extend the comment period given
the pressing national security interests underlying the need for DOJ's
rule, and E.O. 14117's requirement that the rule incorporate CISA's
security requirements.
Other commenters requested that CISA establish an ongoing
stakeholder engagement process to receive continued feedback on the
security requirements even after they have been finalized. Some of the
commenters noted that these security requirements could be burdensome
to implement effectively, and others emphasized that experience
applying the security requirements could lead stakeholders to identify
areas for improvement.
CISA appreciates stakeholder interest in ensuring that the security
requirements remain current and applicable over time and will consider
the best way to receive and incorporate relevant feedback in the future
to the extent changes to the security requirements become necessary or
desirable. However, at this time, CISA does not intend to establish a
formal process for receiving additional feedback on the security
requirements given that the comment period has closed, and CISA must
finalize the security requirements so that they can be incorporated by
reference into DOJ's final rule.
One commenter expressed concern about the security requirements
being a ``quasi-rule,'' indicating that CISA could change the security
requirements at any point in the future without ``procedural
protections'' for impacted entities.\36\
---------------------------------------------------------------------------
\36\ See, e.g., Comment submitted by The Business Software
Alliance, CISA-2024-0029-0024.
---------------------------------------------------------------------------
CISA appreciates the concern raised by the commenter and confirms
that CISA has no intention of changing these security requirements
without providing the public notice of any future changes. As discussed
above, CISA notes that while the Order directed DOJ to propose a rule
and finalize that rule to implement its directive, the Order did not
provide the same direction to CISA for promulgating the security
requirements. By design, the security requirements themselves are not a
rule governed by the process laid out in the Administrative Procedure
Act, 5 U.S.C. 553. While this allows CISA to update the security
requirements quickly, tracking new developments in technology and data
security, such updated security requirements will not be enforceable
against entities regulated by DOJ's rule unless DOJ updates its rule to
change the version of the security requirements incorporated therein by
reference. In other words, commenters can be assured that they will not
be subjected to new security requirements without receiving requisite
procedural protections for implementing the change, as required by law.
III. Description of Final Security Requirements
The security requirements are intended to address national-security
and foreign-policy threats that arise when countries of concern \37\
and covered persons access U.S. government-related data or bulk U.S.
sensitive personal data that may be implicated by the categories of
restricted transactions. Additional background on the purpose for these
security requirements was included in CISA's notice announcing the
release of the proposed security requirements. See 89 FR 85978. The DOJ
Final Rule requires, consistent with E.O. 14117, that United States
persons engaging in restricted transactions comply with the final
security requirements by incorporating the security requirements by
reference into the regulations. 28 CFR 202.401.
---------------------------------------------------------------------------
\37\ Terms used in CISA's security requirements that are defined
in the DOJ rulemaking have the same meaning in the security
requirements as provided in the DOJ rulemaking.
---------------------------------------------------------------------------
The security requirements remain divided into two sections:
organizational- and covered system-level requirements (Section I) and
data-level requirements (Section II). The listed requirements were
selected with the intent of directly mitigating the risk of access to
covered data, with additional requirements included to ensure effective
governance of that access, as well as approaches for establishing an
auditable basis for compliance purposes. Requirements that directly
mitigate the risk of access include I.B.1-2, I.B.4-5, and all data-
level requirements (II.A, II.B, II.C, and II.D). Requirements included
as a mechanism for ensuring proper implementation and governance of
those access controls include all controls in I.A. Additional
requirements incorporated as a mechanism for ensuring auditable
compliance of the aforementioned access controls include I.B.3 and I.C.
These requirements reflect a minimum set of practices that CISA
assesses are required for effective data protection, as informed by
CISA's operational experience. These requirements were designed to be
representative of broadly accepted industry best practices and are
intended to address the needs of national security without imposing an
unachievable burden on industry.
The final security requirements largely maintain the same design as
the proposed security requirements. The security requirements are
designed to mitigate the risk of sharing U.S. government-related data
or bulk U.S. sensitive personal data with countries of concern or
covered persons through restricted transactions.\38\ They do this by
imposing conditions specifically on the covered data that may be
accessed
[[Page 1536]]
as part of a restricted transaction, on the covered systems more
broadly (both terms CISA defines within the security requirements), and
on the organization as a whole. While the requirements on covered
systems and on an organization's governance of those systems apply more
broadly than to the data at issue and the restricted transaction
itself, CISA continues to assess that implementation of these
requirements is necessary to validate that the organization has the
technical capability and sufficient governance structure to
appropriately select, successfully implement, and continue to apply the
data-level security requirements in a way that addresses the risks
identified by DOJ for the restricted transactions. For example, to
ensure and validate that a covered system denies covered persons access
to covered data, it is necessary to maintain audit logs of accesses as
well as organizational processes to utilize those logs. Similarly, it
is necessary for an organization to develop identity management
processes and systems to establish an understanding of which persons
may have access to different data sets.
---------------------------------------------------------------------------
\38\ CISA notes that the security requirements are, as required
by the Order, designed to ``address the unacceptable risk posed by
restricted transactions, as identified by the Attorney General.''
E.O. 14117 Sec. 2(d). They are not intended to reflect a
comprehensive cybersecurity program. For example, several areas
addressed in CISA's CPGs, available at <a href="https://www.cisa.gov/cross-sector-cybersecurity-performance-goals">https://www.cisa.gov/cross-sector-cybersecurity-performance-goals</a>, are not reflected in the
proposed data security requirements, even though the CPGs themselves
are a common set of protections that CISA recommends all critical
infrastructure entities voluntarily implement to meaningfully reduce
the likelihood and impact of known risks and adversary techniques.
As the operational lead for federal cybersecurity and national
coordinator for critical infrastructure security and resilience,
CISA recommends that all U.S. persons implement cybersecurity best
practices in light of the risk and potential consequence of cyber
incidents.
---------------------------------------------------------------------------
In addition to requirements on covered systems, applying security
requirements on the covered data itself that may be accessed in a
restricted transaction is also necessary to address the risks. The
specific requirements that are most technologically and logistically
appropriate for different types of restricted transactions may vary.
For example, some transactions may be amenable to approaches that
minimize data or process it in such a way that does not reveal covered
data to covered persons. In other cases, techniques such as access
control and encryption may be more appropriate to deny any access by
covered persons to unmitigated covered data. The security requirements
provide multiple options to mitigate risk, though all the options build
upon the foundation of the requirements imposed on covered systems and
the organization as a whole. While U.S. persons \39\ engaging in
restricted transactions will be required to implement all the
organizational- and system-level requirements, such persons will have
some flexibility to determine which combination of data-level
requirements are sufficient to fully and effectively prevent access to
covered data that is linkable, identifiable, unencrypted, or
decryptable using commonly available technology by covered persons and/
or countries of concern, based on the nature of the transaction and the
data at issue.
---------------------------------------------------------------------------
\39\ As noted above, for the purposes of the security
requirements, to the extent CISA uses a term that is defined in the
DOJ rulemaking, CISA uses that definition. Therefore, CISA is using
the term U.S. persons as defined by the DOJ Final Rule. That
definition reads ``any United States citizen, national, or lawful
permanent resident; any individual admitted to the United States as
a refugee under 8 U.S.C. 1157 or granted asylum under 8 U.S.C. 1158;
any entity organized solely under the laws of the United States or
any jurisdiction within the United States (including foreign
branches); or any person in the United States.'' 28 CFR 202.256.
---------------------------------------------------------------------------
Finally, the security requirements include a definitions section.
To the extent the requirements use a term already defined in the DOJ
rulemaking, CISA's use of that term in the security requirements would
carry the same meaning. For the purpose of these security requirements,
CISA includes definitions for five terms used exclusively in the
security requirements:
<bullet> Asset. CISA defines the term to mean data, personnel,
devices, systems, and facilities that enable the organization to
achieve business purposes. This definition is derived from the CSF
version 1.1, which defined asset as ``[t]he data, personnel, devices,
systems, and facilities that enable the organization to achieve
business purposes.''
<bullet> Covered data. CISA defines the term to mean the two
categories of data identified by the Order and that DOJ is regulating
through its rulemaking--government-related data or bulk U.S. sensitive
personal data.
<bullet> Covered system. CISA defines this term as a specific type
of information system that is used to conduct a number of activities
related to covered data as part of a restricted transaction. These
activities are drawn from a combination of the activities in the
definition of information system in the security requirements and the
activities in the DOJ rulemaking's definition of access. See 28 CFR
202.201. The term means an information system used to obtain, read,
copy, decrypt, edit, divert, release, affect, alter the state of, view,
receive, collect, process, maintain, use, share, disseminate, or
dispose of (collectively, ``interact with'') covered data as part of a
restricted transaction, regardless of whether the data is encrypted,
anonymized, pseudonymized, or de-identified. ``Covered system'' does
not include an information system (e.g., an end user workstation) that
has the ability to view or read sensitive personal data (other than
sensitive personal data that constitutes government-related data) but
does not ordinarily interact with such data in bulk form.
<bullet> Information system. CISA defines this term consistent with
the definition in the Paperwork Reduction Act (PRA), 44 U.S.C.
3502.\40\ The term means a discrete set of information resources
organized for the collection, processing, maintenance, use, sharing,
dissemination, or disposition of information.
---------------------------------------------------------------------------
\40\ 6 U.S.C. 650(14) (which applies to all of Title XXII of the
Homeland Security Act of 2002, which, in turn, contains most of
CISA's authorities) defines Information System as having the meaning
given the term in the Paperwork Reduction Act, 44 U.S.C. 3502, and
specifically includes ``industrial control systems, such as
supervisory control and data acquisition systems, distributed
control systems, and programmable logic controllers.'' 6 U.S.C.
650(14). However, given CISA's assumption that this type of
operational technology is unlikely to be implicated by DOJ's
regulations, CISA is not including the operational technology-
related prong here.
---------------------------------------------------------------------------
<bullet> Network. CISA defines this term, which CISA developed
consistent with the definition of the term in NIST Special Publication
800-171 rev. 3, Protecting Controlled Unclassified Information in
Nonfederal Systems and Organizations. The term would mean a system of
interconnected components, which may include routers, hubs, cabling,
telecommunications controllers, key distribution centers, and technical
control devices.
The publication of the finalized security requirements for
restricted transactions pursuant to Executive Order (E.O.) 14117,
``Preventing Access to Americans' Bulk Sensitive Personal Data and
United States Government-Related Data by Countries of Concern'' can be
found on CISA's website: <a href="https://www.cisa.gov/resources-tools/resources/EO-14117-security-requirements">https://www.cisa.gov/resources-tools/resources/EO-14117-security-requirements</a>. The Director of CISA, Jennie
M. Easterly, has delegated the authority to approve and electronically
sign this document to Nitin Natarajan, who is the Deputy Director of
CISA, for purposes of publication in the Federal Register.
Nitin Natarajan,
Deputy Director, Cybersecurity and Infrastructure Security Agency,
Department of Homeland Security.
[FR Doc. 2024-31479 Filed 1-3-25; 8:45 am]
BILLING CODE 9111-LF-P
</pre><script data-cfasync="false" src="/cdn-cgi/scripts/5c5dd728/cloudflare-static/email-decode.min.js"></script></body>
</html>Indexed from Federal Register on January 8, 2025.
This is legal information, not legal advice. Laws vary by jurisdiction and change frequently. Always verify current law with official sources and consult a licensed attorney in your jurisdiction for advice on your specific situation.