2016-22174
Federal Register, Volume 81 Issue 181 (Monday, September 19, 2016)
[Federal Register Volume 81, Number 181 (Monday, September 19, 2016)]
[Rules and Regulations]
[Pages 64271-64319]
From the Federal Register Online via the Government Publishing Office [www.gpo.gov]
[FR Doc No: 2016-22174]
[[Page 64271]]
Vol. 81
Monday,
No. 181
September 19, 2016
Part II
Commodity Futures Trading Commission
-----------------------------------------------------------------------
17 CFR Parts 37, 38, and 49
System Safeguards Testing Requirements; Final Rule
Federal Register / Vol. 81 , No. 181 / Monday, September 19, 2016 /
Rules and Regulations
[[Page 64272]]
-----------------------------------------------------------------------
COMMODITY FUTURES TRADING COMMISSION
17 CFR Parts 37, 38, and 49
RIN 3038-AE30
System Safeguards Testing Requirements
AGENCY: Commodity Futures Trading Commission.
ACTION: Final rule.
-----------------------------------------------------------------------
SUMMARY: The Commodity Futures Trading Commission (``Commission'' or
``CFTC'') is adopting final rules amending its current system
safeguards rules for designated contract markets, swap execution
facilities, and swap data repositories, by enhancing and clarifying
current provisions relating to system safeguards risk analysis and
oversight and cybersecurity testing, and adding new provisions
concerning certain aspects of cybersecurity testing. The final rules
clarify the Commission's current system safeguards rules for all
designated contract markets, swap execution facilities, and swap data
repositories by specifying and defining the types of cybersecurity
testing essential to fulfilling system safeguards testing obligations.
These testing types are vulnerability testing, penetration testing,
controls testing, security incident response plan testing, and
enterprise technology risk assessment. The final rules also clarify
current rule provisions respecting: The categories of risk analysis and
oversight that statutorily-required programs of system safeguards-
related risk analysis and oversight must address; system safeguards-
related books and records obligations; the scope of system safeguards
testing; internal reporting and review of testing results; and
remediation of vulnerabilities and deficiencies. In addition, the final
rules adopt new provisions set forth in the Commission's Notice of
Proposed Rulemaking, applicable to covered designated contract markets
(as defined) and all swap data repositories, establishing minimum
frequency requirements for conducting certain types of cybersecurity
testing, and requiring performance of certain tests by independent
contractors.
DATES:
Effective date: This rule is effective September 19, 2016.
Compliance dates: (1) Designated contract markets, swap execution
facilities, and swap data repositories must be in full compliance with
the vulnerability testing requirements of this rule within 180 calendar
days after the effective date. (2) Designated contract markets, swap
execution facilities, and swap data repositories must be in full
compliance with the penetration testing requirements of this rule
within one year after the effective date. Such compliance must include
having conducted and completed penetration testing that complies with
this rule within one year after the effective date. In the case of
covered designated contract markets and swap data repositories, such
compliance must include penetration testing conducted and completed by
an independent contractor as required by this rule. (3) Designated
contract markets, swap execution facilities, and swap data repositories
must be in full compliance with the controls testing requirements of
this rule within one year after the effective date. Covered designated
contract markets and swap data repositories must have testing of key
controls by an independent contractor as required by this rule
completed within three years after the effective date. (4) Designated
contract markets, swap execution facilities, and swap data repositories
must be in full compliance with the security incident response plan
testing requirements of this rule within 180 calendar days after the
effective date. Such compliance must include having created and
completed testing of a security incident response plan within 180 days
after the effective date. (5) Designated contract markets, swap
execution facilities, and swap data repositories must be in full
compliance with the enterprise technology risk assessment requirements
of this rule within one year after the effective date. Such compliance
must include having completed an enterprise technology risk assessment
that complies with this rule within one year after the effective date.
(6) Designated contract markets, swap execution facilities, and swap
data repositories must be in full compliance with the requirements of
this rule for updating their business continuity-disaster recovery
plans and emergency procedures within one year after the effective
date. Such compliance must include having completed an update of such
plans and procedures within one year after the effective date. (7)
Designated contract markets must be in full compliance with the
requirements of this rule respecting required production of annual
total trading volume within 30 calendar days of the effective date. (8)
Designated contract markets, swap execution facilities, and swap data
repositories must be in full compliance with the system safeguards-
related books and records requirements of this rule, which are part of
such entities' current books and records requirements under current
Commission regulations and statutory core principles, as of the
effective date. (9) Designated contract markets, swap execution
facilities, and swap data repositories must be in full compliance with
all other provisions of these final rules within one year after the
effective date.
FOR FURTHER INFORMATION CONTACT: Rachel Berdansky, Deputy Director,
Division of Market Oversight, 202-418-5429, [email protected]; David
Taylor, Associate Director, Division of Market Oversight, 202-418-5488,
[email protected], or David Steinberg, Associate Director, Division of
Market Oversight, 202-418-5102, [email protected]; Commodity Futures
Trading Commission, Three Lafayette Centre, 1155 21st Street NW.,
Washington, DC 20851.
SUPPLEMENTARY INFORMATION:
I. Background
A. The Need for Cybersecurity Testing
On December 15, 2015, the Commission issued a Notice of Proposed
Rulemaking (``NPRM'') proposing to amend its system safeguards rules
for designated contract markets (``DCMs''), swap execution facilities
(``SEFs''), and swap data repositories (``SDRs'').\1\
---------------------------------------------------------------------------
\1\ System Safeguards Testing Requirements, Proposed Rule, 80 FR
80139, 80140 (Dec. 23, 2015).
---------------------------------------------------------------------------
As detailed in the NPRM, cyber threats to the financial sector
continue to expand, increasing the need for enhanced cybersecurity
testing. Such testing should focus on the entity's ability to detect,
contain, respond to, and recover from cyber attacks. It should also
address detection, containment, and recovery from compromise of data
integrity--perhaps the greatest threat with respect to financial sector
data--in addition to compromise of data availability or
confidentiality. As noted in the NPRM, cybersecurity testing is a well-
established best practice both generally and for financial sector
entities.\2\
---------------------------------------------------------------------------
\2\ Id. at 80142.
---------------------------------------------------------------------------
Cybersecurity testing is also supported internationally. The
recently published Guidance on cyber resilience for financial market
infrastructures issued by the Committee on Payments and Market
Infrastructures and the Board of the International Organization of
Securities Commissions (``CPMI-IOSCO Guidance'') provides that:
Testing is an integral component of any cyber resilience
framework. All elements of a cyber resilience framework should be
[[Page 64273]]
rigorously tested to determine their overall effectiveness before
being deployed within an FMI, and regularly thereafter. This
includes the extent to which the framework is implemented correctly,
operating as intended and producing desired outcomes. Understanding
the overall effectiveness of the cyber resilience framework in the
FMI and its environment is essential in determining the residual
cyber risk to the FMI's operations, assets, and ecosystem.\3\
---------------------------------------------------------------------------
\3\ Committee on Payments and Market Infrastructures (CPMI) and
Board of the International Organization of Securities Commissions
(IOSCO), Guidance on cyber resilience for financial market
infrastructures (June 2016) section 7.1, at 18, available at https://www.iosco.org/library/pubdocs/pdf/IOSCOPD535.pdf.
The CPMI-IOSCO Guidance also states that a financial market
infrastructure ``should establish a comprehensive testing program to
validate the effectiveness of its cyber resilience framework on a
regular and frequent basis,'' employing appropriate cyber threat
intelligence to inform its testing methods, and using the results to
support ongoing improvement of its cyber resilience.\4\
---------------------------------------------------------------------------
\4\ Id., section 7.2 at 18.
---------------------------------------------------------------------------
B. Summary of the Proposed System Safeguards Testing Requirements Rule
1. Fundamental Goals
The NPRM identified two principal goals. The first goal was
clarification of current cybersecurity testing requirements for all
DCMs, SEFs, and SDRs, along with clarification, amplification, and
harmonization of other current system safeguards rule provisions. The
second goal was the addition of new rule provisions for covered DCMs
(as defined) and SDRs, establishing minimum frequency requirements for
conducting certain types of cybersecurity testing, and requiring
performance of certain tests by independent contractors.
2. Categories of Risk Analysis and Oversight Applicable to All DCMs,
SEFs, and SDRs
The system safeguards provisions of the Commodity Exchange Act
(``Act'' or ``CEA'') and Commission regulations applicable to all DCMs,
SEFs, and SDRs require these entities to maintain a program of risk
analysis and oversight to identify and minimize sources of operational
risk.\5\ Commission regulations concerning system safeguards provide
that the program of risk analysis and oversight required of each such
entity must address specified categories of risk analysis and oversight
to identify and minimize sources of operational risk.\6\ The NPRM
proposed clarification of what is already required of all DCMs, SEFs,
and SDRs regarding the six current categories which their programs of
risk analysis and oversight must address, by further defining those
categories.\7\ It also added and defined another category, enterprise
risk management and governance, in order to clarify a requirement
already implicit in the statutory mandate to maintain a program of
system safeguards risk analysis and oversight. As set out in the NPRM,
all seven categories and their definitions are grounded in generally
accepted best practices.\8\
---------------------------------------------------------------------------
\5\ 7 U.S.C. 5h(f)(14), 7(d)(20), and 24a(c)(8); 17 CFR 37.1400,
38.1050, and 49.24(a)(1).
\6\ 17 CFR 38.1051(a) and (b) (for DCMs); 17 CFR 37.1401(a);
Appendix A to Part 37, Core Principle 14 of Section 5h of the Act--
System Safeguards (a) Guidance (1) Risk analysis and oversight
program (for SEFs); 17 CFR 49.24(b) and (c) (for SDRs).
\7\ The six current categories include information security;
business continuity-disaster recovery (``BC-DR'') planning and
resources; capacity and performance planning; systems operations;
systems development and quality assurance; and physical security and
environmental controls.
\8\ 80 FR 80139, 80143 (Dec. 23, 2015).
---------------------------------------------------------------------------
3. Requirements To Follow Best Practices, Ensure Testing Independence,
and Coordinate BC-DR Plans
The Commission's current regulations for DCMs and SDRs and its
guidance for SEFs provide that such entities should follow best
practices in addressing the categories which their programs of system
safeguards risk analysis and oversight are required to include.\9\ They
provide that such entities should ensure that their system safeguards
testing, whether conducted by contractors or employees, is conducted by
independent professionals (i.e., persons not responsible for
development or operation of the systems or capabilities being
tested).\10\ They further provide that such entities should coordinate
their business continuity-disaster recovery (``BC-DR'') plans with the
BC-DR plans of market participants and essential service providers.\11\
The NPRM proposed making these provisions mandatory for all DCMs, SEFs,
and SDRs, thus aligning the rules for these entities with the
Commission's rules for derivatives clearing organizations
(``DCOs'').\12\
---------------------------------------------------------------------------
\9\ See Sec. 38.1051(b) (for DCMs); Appendix A to Part 37, Core
Principle 14 of Section 5h of the Act--System Safeguards (a)
Guidance (1) Risk analysis and oversight program (for SEFs); Sec.
49.24 (c) (for SDRs).
\10\ See Sec. 38.1051(h) (for DCMs); Appendix A to Part 37,
Core Principle 14 of Section 5h of the Act--System Safeguards (a)
Guidance (2) Testing (for SEFs); Sec. 49.24(j) (for SDRs).
\11\ See Sec. 38.1051(i) (for DCMs); Appendix A to Part 37,
Core Principle 14 of Section 5h of the Act--System Safeguards (a)
Guidance (3) Coordination (for SEFs); Sec. 49.24(k) (for SDRs).
\12\ 80 FR 80139, 80146 (Dec. 23, 2015).
---------------------------------------------------------------------------
4. Updating of Business Continuity-Disaster Recovery Plans and
Emergency Procedures
The NPRM proposed amending the current system safeguards rules
requiring all DCMs, SEFs, and SDRs to maintain a business continuity-
disaster recovery plan and emergency procedures, by adding a
requirement for such plans and procedures to be updated as frequently
as required by appropriate risk analysis, but at a minimum at least
annually.\13\
---------------------------------------------------------------------------
\13\ Id. at 80147.
---------------------------------------------------------------------------
5. System Safeguards-Related Books and Records Obligations
The Commission's current system safeguards rules for all DCMs,
SEFs, and SDRs contain a provision addressing required production of
system safeguards-related documents to the Commission on request.\14\
As noted in the NPRM, production of all such books and records is
already required by the Act and Commission regulations, notably by
Commission regulation Sec. 1.31.\15\ The NPRM proposed amending these
document production provisions to further clarify requirements for
document production by all DCMs, SEFs, and SDRs relating to system
safeguards.\16\
---------------------------------------------------------------------------
\14\ 17 CFR 38.1051(g) and (h) (for DCMs); 17 CFR 37.1401(f) and
(g) (for SEFs); 17 CFR 49.24(i) and (j) (for SDRs).
\15\ 17 CFR 1.31; see also 17 CFR 38.1051(g) and (h); 17 CFR
37.1401(f) and (g); 17 CFR 49.24(i) and (j).
\16\ 80 FR 80139, 80147 (Dec. 23, 2015). The NPRM specified that
the obligation to produce books and records includes production of:
Current copies of BC-DR plans and emergency procedures; assessments
of operational risks or system safeguards-related controls; reports
concerning system safeguards testing and assessment, whether
performed by independent contractors or employees; and all other
books and records requested by Commission staff in connection with
Commission oversight of system safeguards.
---------------------------------------------------------------------------
6. Cybersecurity Testing Requirements for DCMs, SEFs and SDRs
a. Clarification of Current Testing Requirements for All DCMs, SEFs,
and SDRs
The Commission's current system safeguards rules for DCMs, SEFs,
and SDRs mandate that each such entity must conduct testing and review
sufficient to ensure that its automated systems are reliable, secure,
and have adequate scalable capacity.\17\ The NPRM proposed clarifying
this system safeguards and cybersecurity testing requirement, by
specifying and defining five types of system safeguards testing and
assessment that a DCM, SEF, or SDR necessarily must perform to fulfill
[[Page 64274]]
the requirement.\18\ These testing and assessment types included
vulnerability testing, both external and internal penetration testing,
controls testing, security incident response plan testing, and
enterprise technology risk assessment. As set out in the NPRM, each of
these types of testing is a generally recognized best practice for
system safeguards.\19\ Providing this clarification of the testing
provisions of the current system safeguards rules is a primary purpose
of this final rule. The NPRM proposed high-level, minimum requirements
for these types of testing, recognizing that the particular ways in
which DCMs, SEFs, and SDRs conduct such testing may change as accepted
standards and industry best practices develop over time and are
reflected in the DCM's, SEF's, or SDR's risk analysis. The NPRM
provisions regarding each of the testing types are set out in
additional detail in the discussion below concerning comments received.
---------------------------------------------------------------------------
\17\ 17 CFR 38.1051(h) (for DCMs); 17 CFR 37.1401(g) (for SEFs);
17 CFR 49.24(j) (for SDRs).
\18\ 80 FR 80139, 80147 (Dec. 23, 2015).
\19\ The Commission's current rules and guidance provide that a
DCM's, SEF's, or SDR's entire program of risk analysis and
oversight, which includes testing, should be based on generally
accepted standards and best practices with respect to the
development, operation, reliability, security, and capacity of
automated systems. See 17 CFR 38.1051(h) (for DCMs); Appendix A to
Part 37, Core Principle 14 of Section 5h of the Act--System
Safeguards (a) Guidance (1) Risk analysis and oversight program (for
SEFs); 17 CFR 49.24(j) (for SDRs). Each of the types of testing
addressed in this NPRM--vulnerability testing, penetration testing,
controls testing, security incident response plan testing, and
enterprise technology risk assessment--has been a generally
recognized best practice for system safeguards since before the
testing requirements of the Act and the current regulations were
adopted. The current system safeguards provisions of the CEA and the
Commission's regulations became effective in August 2012. Generally
accepted best practices called for each type of testing specified in
the proposed rule well before that date, as shown in the following
examples. Regarding all five types of testing, see, e.g., NIST SP
800-53A, Rev. 1, Guide for Assessing the Security Controls in
Federal Information Systems and Organizations (``NIST 800-53A Rev.
1''), at E1, F67, F230, F148, and F226, June 2010, available at:
http://csrc.nist.gov/publications/nistpubs/800-53A-rev1/sp800-53A-rev1-final.pdf. Regarding vulnerability testing, see, e.g., NIST SP
800-53A Rev. 1, at F67, June 2010, available at: http://csrc.nist.gov/publications/nistpubs/800-53A-rev1/sp800-53A-rev1-final.pdf; and NIST SP 800-115, Technical Guide to Information
Security Testing and Assessment, at 5-2, September 2008, available
at: http://csrc.nist.gov/publications/nistpubs/800-115/SP800-115.pdf. Regarding penetration testing, see, e.g., NIST Special
Publication (``SP'') 800-53A, Rev. 1, at E1, June 2010, available
at: http://csc.nist.gov/publications/nistpubs/800-53A-rev1/sp800-53A-rev1-final.pdf; and NIST 800-115, at 4-4, September 2008,
available at: http://csrc.nist.gov/publications/nistpubs/800-115/SP800-115.pdf. Regarding controls testing, see, e.g., NIST 800-53A,
Rev. 1, at 13 and Appendix F1, June 2010, available at: http://csrc.nist.gov/publications/nistpubs/800-53A-rev1/sp800-53A-rev1-final.pdf. Regarding security incident response plan testing, see,
e.g., NIST 800-53A, Rev. 1, at F148, June 2010, available at http://csrc.nist.gov/publications/nistpubs/800-53A-rev1/sp800-53A-rev1-final.pdf. Regarding enterprise technology risk assessment, see,
e.g., NIST 800-53A, Rev.1, at F226, June 2010, available at: http://csrc.nist.gov/publications/nistpubs/800-53A-rev1/sp800-53A-rev1-final.pdf.
---------------------------------------------------------------------------
b. New Minimum Testing Frequency and Independent Contractor Testing
Requirements for Covered DCMs and All SDRs
The NPRM proposed that covered DCMs (as defined) and all SDRs would
be subject to new minimum testing frequency requirements with respect
to some of the proposed types of system safeguards testing.\20\ To
strengthen the objectivity and reliability of the testing, assessment,
and information available to the Commission regarding covered DCM and
SDR system safeguards, the NPRM also proposed that for certain types of
testing, covered DCMs and SDRs would be subject to new independent
contractor testing requirements.\21\ Establishing such minimum
frequency and independent contractor requirements regarding
cybersecurity testing by covered DCMs and SDRs is a primary purpose of
this final rule. As noted in the NPRM, the proposed minimum frequency
requirements and the requirement for some testing to be conducted by
independent contractors are grounded in generally accepted standards
and best practices.\22\ The NPRM provisions regarding the minimum
frequency and independent contractor requirements are set out in
additional detail below in the discussion of comments received.
---------------------------------------------------------------------------
\20\ 80 FR 80139, 80148 (Dec. 23, 2015).
\21\ Id.
\22\ Id.
---------------------------------------------------------------------------
7. Additional Testing-Related Risk Analysis and Oversight Program
Requirements Applicable to All DCMs, SEFs, and SDRs
The NPRM also clarified the current testing requirements for DCMs,
SEFs, and SDRs by specifying and defining three other aspects of risk
analysis and oversight programs that are necessary to fulfillment of
the testing requirements and achievement of their purposes.\23\ These
three aspects are: (1) The scope of testing and assessment, (2)
internal reporting and review of test results, and (3) remediation of
vulnerabilities and deficiencies revealed by testing. As set out in the
NPRM, all three of these risk analysis and oversight program aspects
are grounded in generally recognized best practices for system
safeguards.\24\
---------------------------------------------------------------------------
\23\ 80 FR 80139, 80159 (Dec. 23, 2015).
\24\ Id.
---------------------------------------------------------------------------
a. Scope of Testing and Assessment
The NPRM proposed that the scope of all testing and assessment
required by the Commission's system safeguards regulations for DCMs,
SEFs, and SDRs should be broad enough to include all testing of
automated systems and controls necessary to identify any vulnerability
which, if exploited or accidentally triggered, could enable an intruder
or unauthorized user or insider to interfere with the entity's
operations or with fulfillment of its statutory and regulatory
responsibilities; to impair or degrade the reliability, security, or
capacity of the entity's automated systems; to add to, delete, modify,
exfiltrate, or compromise the integrity of any data related to the
entity's regulated activities; or to undertake any other unauthorized
action affecting the entity's regulated activities or the hardware or
software used in connection with those activities.\25\ The NPRM noted
that testing scope should be based on proper risk analysis.\26\
---------------------------------------------------------------------------
\25\ Id.
\26\ Id. at 80160.
---------------------------------------------------------------------------
b. Internal Reporting and Review
The NPRM called for a DCM's, SEF's, or SDR's senior management and
its Board of Directors receive and review reports of the results of all
testing and assessment required by Commission rules.\27\ It also called
for DCMs, SEFs, and SDRs to establish and follow appropriate procedures
for remediation of issues identified through such review, and for
evaluation of the effectiveness of the organization's testing and
assessment protocols.\28\ As noted in the NPRM, these requirements are
grounded in best practices.\29\
---------------------------------------------------------------------------
\27\ Id.
\28\ Id.
\29\ Id.
---------------------------------------------------------------------------
c. Remediation
The NPRM called for each DCM, SEF, and SDR to analyze the results
of the testing and assessment required by the applicable system
safeguards rules, in order to identify all vulnerabilities and
deficiencies in its systems, and to remediate those vulnerabilities and
deficiencies to the extent necessary to enable it to fulfill the
applicable system safeguards requirements and meet its statutory and
regulatory obligations.\30\ The NPRM proposed requiring that such
remediation be timely in light of appropriate risk analysis with
respect to the risks presented.\31\ As noted in the
[[Page 64275]]
NPRM, such remediation is grounded in best practices.\32\
---------------------------------------------------------------------------
\30\ Id.
\31\ Id.
\32\ Id.
---------------------------------------------------------------------------
8. Required Production of Annual Total Trading Volume
The NPRM defined ``covered DCM'' as a DCM whose annual total
trading volume is five percent or more of the annual total trading
volume of all DCMs regulated by the Commission.\33\ It did so for the
purpose of applying the proposed minimum system safeguards testing
frequency and independent contractor testing requirements, discussed
above, to such covered DCMs. The NPRM noted that this would give DCMs
that have less than five percent of the annual total trading volume of
all DCMs more flexibility regarding the testing they must conduct,
while still requiring all DCMs to conduct testing of all the types
addressed in the NPRM.\34\ To provide certainty to DCMs as to whether
they currently met the definition of a covered DCM, the NPRM called for
each DCM to report to the Commission annually its annual total trading
volume for the preceding year, and for the Commission to notify each
DCM annually of the percentage of the annual total trading volume of
all DCMs which is constituted by that DCM's annual total trading volume
for the preceding year.\35\ The NPRM therefore called for each DCM to
report its annual total trading volume for 2015 to the Commission
within 30 calendar days of the effective date of the final rule, and to
report its annual total volume for 2016 and each subsequent year
thereafter to the Commission by January 31 of 2017 and of each calendar
year thereafter.\36\ The NPRM's definition of covered DCM also
addressed cases where a DCM that had been a covered DCM ceased to meet
the definitional requirements for covered DCM status, by providing that
a covered DCM having annual total trading volume of less than five
percent of the combined annual total trading volume of all regulated
DCMs for two consecutive calendar years would cease to be a covered DCM
as of March 1 of the calendar year following such two consecutive
calendar years.\37\ This two-year period permitted completion of the
proposed two-year cycle for independent contractor-conducted controls
testing.
---------------------------------------------------------------------------
\33\ Id. at 80148.
\34\ Id.
\35\ Id. at 80160, 80161.
\36\ Id.
\37\ Id. at 80148.
---------------------------------------------------------------------------
C. Overview of Comments Received
The comment period for the NPRM closed on February 23, 2016. The
Commission received nine comment letters addressing the NPRM. Comments
were provided by: The Chicago Mercantile Exchange (``CME'') Group DCMs,
the CME SEF, and the CME SDR (collectively, ``CME''); Intercontinental
Exchange, Inc. (``ICE'') Futures U.S., ICE Swap Trade, and ICE Trade
Vault (collectively, ``ICE''); the Minneapolis Grain Exchange
(``MGEX''); the North American Derivatives Exchange (``Nadex''); the
CBOE Futures Exchange (``CFE''); the Depository Trust and Clearing
Corporation Data Repository (``DDR''); Tradeweb Markets LLC
(``Tradeweb''); the Wholesale Markets Broker's Association, Americas
(``WMBAA''), whose members include BGC SEF, GFI SEF, Tradition SEF, and
Tullett Prebon SEF; and FireEye, a third-party cybersecurity service
provider.\38\
---------------------------------------------------------------------------
\38\ All comment letters are available on the Commission Web
site at: http://comments.cftc.gov/PublicComments/CommentList.aspx?id=1650.
---------------------------------------------------------------------------
Most commenters expressed broad support for the proposed system
safeguards testing rules. ICE stated that it supports the Commission's
efforts to improve, clarify, and enhance its rules relating to system
safeguards and address cybersecurity testing, calling clarification and
enhancement of these rules in response to escalating and evolving
cybersecurity threats ``timely and welcome,'' and noting that
cybersecurity and system safeguards are paramount to the functioning of
the derivatives markets. MGEX said it appreciates and supports the
efforts the Commission has put forth to address the growing risk that
cyber threats pose to trading markets. Nadex stated that it ``commends
the Commission's undertaking of this endeavor,'' that it agrees with
the general thrust of the proposed rule, and that it appreciates the
Commission's efforts to clarify and enhance the current system
safeguards regulations, align requirements with industry standards, and
ensure that registrants are meeting compliance thresholds. CFE noted
its agreement with the NPRM's approach featuring principles-based
testing standards deeply rooted in industry best practices. DDR
commended the Commission for its efforts to strengthen system
safeguards and cybersecurity testing, and called the proposed rules
``constructive steps in addressing key issues.'' Tradeweb stated that
it strongly supports the principles-based testing standards in the
NPRM. WMBAA said that it appreciates the Commission's efforts to
clarify current system safeguards rule and cybersecurity testing
requirements.
Many commenters also offered suggestions and recommendations for
clarification or modification of specific NPRM provisions. These
comments are addressed as appropriate in connection with the discussion
below of the final rule provisions to which they relate. Certain
comments requested further clarification relating to definitions
provided in the NPRM. Any definitional changes in the final rule are
provided for clarification only and do not impose new substantive
obligations not included in the NPRM.
D. Advanced Notice of Proposed Rulemaking Regarding Minimum Testing
Frequency and Independent Contractor Testing Requirements for Covered
SEFs
1. ANPRM Provisions
The NPRM included an Advanced Notice of Proposed Rulemaking
(``ANPRM'') concerning Commission consideration of whether to propose
in a future NPRM that the most systemically important SEFs should be
subject to the same minimum testing frequency and independent
contractor testing requirements proposed in the NPRM for covered DCMs
and SDRs.\39\ In announcing its intent to consider such a proposal, the
Commission expressed its belief that, because these requirements were
essential to the effectiveness of covered DCM cybersecurity testing and
the adequacy of their programs of risk analysis and oversight, it is
appropriate to consider whether the same requirements should be applied
to the most systemically important SEFs. In the ANPRM, the Commission
took note that the SEF market is still in the early stages of
development. It also suggested that one possible definition of
``covered SEF'' could be SEFs for which the annual total notional value
of all swaps traded on or pursuant to the rules of the SEF is ten
percent or more of the annual total notional value of all swaps traded
on or pursuant to the rules of all SEFs regulated by the Commission.
However, the ANPRM stated that the Commission would also consider
whether annual total notional value or annual total number of swaps
traded would provide a more appropriate definition, and whether any
definition should apply to swaps in each asset class separately or to
all swaps combined regardless of asset class. The Commission requested
comments regarding each of these
[[Page 64276]]
considerations, possible costs and benefits and how they could be
quantified or estimated, and any other aspects of the ANPRM.
---------------------------------------------------------------------------
\39\ 80 FR 80139, 80148 (Dec. 23, 2015).
---------------------------------------------------------------------------
2. Comments Received
The Commission received several comments concerning the ANPRM.
Tradeweb called for careful consideration by the Commission, in
dialogue with the SEFs to whom any proposal would potentially apply,
before issuance of an NPRM on this subject. Tradeweb suggested that,
because the SEF market is still in an early stage of development and a
covered SEF concept could have a disproportionate impact on the
commercial viability of certain SEFs, both the definition of ``covered
SEF'' and the potential costs and benefits involved would require
further study and discussion with the industry. To that end, Tradeweb
urged the Commission to convene a roundtable or working group of SEFs
to discuss the nature and scope of any future SEF-specific system
safeguards NPRM before moving forward with such a proposal. Tradeweb
advised the Commission to consider the cross-border scope and impact of
any future NPRM, and to solicit comment from international regulators
either independently or as part of the suggested roundtable or working
group.
Several commenters suggested that any future requirements proposed
should apply to all SEFs. Tradeweb called for any future proposal to
avoid putting certain SEFs at a competitive disadvantage, and to cover
all SEFs rather than only systemically important SEFS. WMBAA
recommended that the Commission decline to propose a ``covered SEF''
concept, arguing that: (1) SEF operations do not raise the same
systemic concerns attendant on failure of major DCMs or DCOs; (2)
products traded on SEFs are fungible across multiple platforms; (3) in
the present early stage of the SEF market, individual SEFs could be
``covered'' one year but not the next, leading to uncertainty; and (4)
the present unsettled nature of the SEF regulatory environment would
make adoption of a ``covered SEF'' concept premature. CME called for
the Commission to adopt the same risk based system safeguards
requirements for all SEFs, leaving testing frequency to be determined
by risk analysis, and avoiding an independent contractor testing
requirement.
Tradeweb and WMBAA also suggested that the costs associated with
imposition of ``covered SEF'' requirements could well exceed any
benefits derived. However, no commenters offered specific information
concerning possible costs.
3. Further Commission Consideration
The Commission has considered and evaluated the comments received
concerning the ANPRM. The Commission agrees with the comments
suggesting that further consideration and consultation with both the
industry and other relevant regulators and stakeholders would be
appropriate and helpful before issuance of any future NPRM regarding
``covered SEFs.'' The Commission also notes the current lack of
specific cost and benefit information regarding this concept, and the
current absence of a consensus on how ``covered SEF'' would be best
defined in light of the characteristics of swaps and the swap market.
Accordingly, the Commission will engage in appropriate consultation
prior to determining whether to issue a future NPRM regarding ``covered
SEFs.''
II. The Final Rules
A. Categories of Risk Analysis and Oversight--Sec. Sec. 37.1401(a),
38.1051(a), and 49.24(b).
1. Proposed Rule
As noted above, the NPRM proposed clarification of what is already
required of all DCMs, SEFs, and SDRs regarding the categories which
their programs of risk analysis and oversight must address, by further
defining the six categories addressed by the current rules.\40\ It also
added and defined another category, enterprise risk management and
governance, doing so to clarify a requirement already implicit in the
statutory mandate to maintain a program of system safeguards risk
analysis and oversight.\41\ As set out in the NPRM, all seven
categories and their definitions are grounded in generally accepted
best practices.\42\
---------------------------------------------------------------------------
\40\ 80 CFR 80139, 80147 (Dec. 23, 2015).
\41\ Id. at 80143.
\42\ Id.
---------------------------------------------------------------------------
2. Comments Received
The Commission received three comments on this topic. Two
commenters, CME and DDR, concurred with the NPRM's addition of the
category of enterprise risk analysis and governance to the list of
categories that programs of risk analysis and oversight must address,
and suggested clarifications in this respect. CME stated that it
recognizes the importance of effective Board oversight, and asked the
Commission to confirm that such oversight may appropriately be
delegated to Board level committees. CME also asked the Commission to
confirm that the final rule will allow regulated entities flexibility
of organizational design concerning how their programs of risk analysis
and oversight address the enterprise risk management and governance
category, and will not require that an entity's enterprise risk
management function conduct all components of this category. DDR agreed
with the Commission that active supervision of system safeguards by
both senior management and the Board of Directors promotes more
efficient, effective, and reliable risk management, and will better
position regulated entities to strengthen the integrity, resiliency,
and availability of their automated systems. Noting its agreement that
regulated entities should give their boards access to the appropriate
system safeguards and cyber resiliency information so as to enable
effective oversight, DDR suggested that the final rules should
acknowledge that there are multiple ways a regulated entity can ensure
that its board is appropriately informed. One commenter, MGEX,
questioned why this NPRM proposed adding the category of enterprise
risk management and governance, while the Commission's parallel Notice
of Proposed Rulemaking addressed to DCOs did not, citing this as an
inconsistency between the two NPRMs.\43\
---------------------------------------------------------------------------
\43\ See 80 FR 80139, 80113 (Dec. 23, 2015).
---------------------------------------------------------------------------
MGEX commented that the NPRM proposed a requirement for all DCMs,
SEFs, and SDRs to have a program of risk analysis and oversight,
without defining such a program. MGEX also stated that the lists of
topics specified in the NPRM as included in each category to be
addressed in the required program of risk analysis and oversight were
overly prescriptive, citing as an example the list of topics the NPRM
specified as included in the category of information security. MGEX
suggested that the specified categories should be principles-based and
should look to evolving best practices.
3. Final Rule
The Commission has considered and evaluated the comments concerning
addition of the category of enterprise risk analysis and governance to
the list of categories which must be addressed by the program of system
safeguards-related risk analysis and oversight which the CEA requires
all DCMs, SEFs, and SDRs to establish and maintain. For the reasons set
forth below, the Commission is adopting the list of categories as
proposed.
[[Page 64277]]
The Commission continues to believe that addition of the category
of enterprise risk analysis and governance is appropriate because this
clarifies a requirement already implicit in the statutory mandate to
maintain a program of system safeguards risk analysis and
oversight.\44\ The Commission confirms that the addition of this
category does not require that the listed elements of this category be
conducted through a particular organizational structure or by
particular DCM, SEF, or SDR staff; rather, the final rule provides
flexibility in this regard.
---------------------------------------------------------------------------
\44\ 80 FR 80139, 80143 (Dec. 23, 2015).
---------------------------------------------------------------------------
The Commission agrees with the comments acknowledging the
importance of effective Board of Directors oversight of system
safeguards, which the Commission believes is essential to establishing
and maintaining the top-down, organization-wide culture of adherence to
cybersecurity principles that is required for resilience in today's
cybersecurity threat environment. In addition, the Commission agrees
with CME's comment that Board of Directors oversight of system
safeguards may appropriately be delegated to a Board-level committee or
committees, and with DDR's comment that there are a variety of ways in
which a DCM, SEF, or SDR can ensure that its Board is sufficiently and
appropriately informed to enable it to provide appropriate system
safeguards and cybersecurity oversight. In the Commission's view,
providing the Board with information sufficient to enable it to provide
active, appropriate, knowledgeable, and effective oversight of system
safeguards and cybersecurity is the key in this regard.
The Commission has also considered and evaluated MGEX's comment
asserting that the NPRM proposed establishment of a requirement for
DCMs, SEFs, and SDRs to have a program of system safeguards risk
analysis and oversight, without defining such a program, and its
comment concerning the lists of topics specified in the NPRM as
included in each category to be addressed in the required program of
risk analysis and oversight. The requirement for regulatees to have a
program of system safeguards risk analysis and oversight was mandated
by Congress in the CEA itself, and thus is required by law.\45\ The
NPRM's references to it did not propose creation of a new requirement
in this regard. The Commission's current system safeguards regulations
define the program of risk analysis and oversight by specifying the
categories of risk analysis and oversight which the program must
address. As noted above and in the NPRM, the category of enterprise
risk management and governance is implicit and inherent in the
statutory requirement itself, and supported by generally accepted
standards and best practices.\46\
---------------------------------------------------------------------------
\45\ CEA section 5(d)(20)(A), 17 U.S.C. 7(d)(20).
\46\ 80 FR 80139, 80143 (Dec. 23, 2015).
---------------------------------------------------------------------------
The Commission agrees with MGEX that the required categories of
risk analysis and oversight should be principles-based, but disagrees
that the NPRM lists of topics included in each category consist of
static lists of controls. As set out in detail in the NPRM, each of the
aspects cited in the NPRM for the various categories that the required
program of risk analysis and oversight must address is rooted in
generally accepted standards and best practices.\47\ Because the
Commission's current system safeguards rules and guidance provide that
DCMs, SEFs, and SDRs should follow generally accepted best practices
and standards regarding system safeguards, these entities' programs of
risk analysis and oversight should already be addressing each of the
aspects included in the NPRM for each risk analysis and oversight
category. As the NPRM explicitly states, the aspects specified in the
NPRM for each category do not provide all-inclusive or static lists;
rather, they highlight important aspects of the categories that are
already recognized as best practices.\48\ An important benefit of the
adherence-to-best-practices approach taken in the Commission's current
system safeguards rules, the NPRM generally, and the NPRM provisions
addressing the categories in particular, is precisely that such best
practices can evolve over time as the cybersecurity field evolves. In
addition, the Commission continues to believe, as it stated in the
NPRM, that risk analysis and oversight programs that address each of
the aspects listed in the NPRM for the risk analysis and oversight
categories are essential to maintaining effective system safeguards in
today's cybersecurity threat environment.\49\
---------------------------------------------------------------------------
\47\ Id.
\48\ Id.
\49\ Id. at 80145.
---------------------------------------------------------------------------
B. Requirement To Follow Generally Accepted Standards and Best
Practices--Sec. Sec. 37.1401(b), 38.1051(b), and 49.24(c)
1. Proposed Rule
The NPRM retained the substance of the Commission's current system
safeguards rule provision calling for DCMs, SEFs, and SDRs to adhere to
generally accepted standards and best practices in their required
programs of system safeguards risk analysis and oversight. The only
change proposed in the NPRM was language adjustment to clarify that
such adherence is mandatory for all DCMs, SEFs, and SDRs.\50\
---------------------------------------------------------------------------
\50\ Id. at 80146.
---------------------------------------------------------------------------
2. Comments Received
Several commenters, including CME, Nadex, DDR, Tradeweb, and WMBAA,
agreed with the Commission that an entity's program of risk analysis
and oversight should follow generally accepted standards and best
practices. CME requested that the Commission confirm that generally
accepted best practices not explicitly cited in the NPRM may also be
used in this regard. CME also asked the Commission to confirm that the
intent of this provision is that a regulated entity should take
generally accepted best practices into account as it designs a program
of risk analysis and oversight tailored to its risks and its
appropriate analysis of those risks, rather than to codify particular
best practices.
3. Final Rule
The Commission has considered and evaluated the comments concerning
the requirement that a DCM's, SEF's, or SDR's required program of risk
analysis and oversight should follow generally accepted standards and
best practices. For the reasons set forth below, the Commission is
adopting this provision as proposed.
As CME asked the Commission to confirm, the best practices cited in
the NPRM do not constitute an exclusive or codified list.\51\ DCMs,
SEFs, and SDRs should take generally accepted best practices and
standards into account as they conduct appropriate and current analysis
of individual risks and conducts appropriate and effective oversight
with respect to such risks. A program of risk analysis and oversight
should consider all generally accepted sources of best practices in
addressing the particular risks and circumstances of the entity in
question in an effective and appropriate way. In the Commission's view,
the requirement to follow generally accepted standards and best
practices is one of the most important requirements of the Commission's
system safeguards rules. Best practices evolve over time in conjunction
with the changing cybersecurity threat environment. The agility that a
best practices approach therefore provides is crucial to effective
resilience with respect to cybersecurity and system
[[Page 64278]]
safeguards. In addition, ongoing development of best practices benefits
from private sector expertise and input, as well as from public sector
contributions. Such private sector expertise and input is important to
effective cybersecurity. The Commission also observes that requiring
financial sector entities to follow best practices with respect to
system safeguards and cybersecurity is an effective key to harmonizing
the oversight of cybersecurity conducted by different financial
regulators. Some financial regulators, such as the FFIEC agencies, are
themselves sources of generally accepted best practices. Regulatory
oversight of cybersecurity generally follows best practices, most
sources of which are largely consonant with each other.
---------------------------------------------------------------------------
\51\ Id.
---------------------------------------------------------------------------
C. Business Continuity-Disaster Recovery Plan--Sec. Sec. 37.1401(c),
38.1051(c), and 49.24(d)
1. Proposed Rule
The Commission's current rules concerning the business continuity-
disaster recovery (``BC-DR'') plans of DCMs, SEFs, and SDRs require
that these entities maintain BC-DR plans and resources, emergency
procedures, and backup facilities sufficient to enable timely recovery
and resumption of their operations and fulfillment of their
responsibilities and obligations as registrants, and specify recovery
time. The NPRM proposed further alignment of these provisions with
generally accepted standards and best practices by adding a requirement
for DCMs, SEFs, and SDRs to update their BC-DR plans and emergency
procedures at a frequency determined by an appropriate risk analysis,
but at a minimum no less frequently than annually.\52\
---------------------------------------------------------------------------
\52\ Id. at 80147.
---------------------------------------------------------------------------
2. Comments Received
CME stated that it agreed with the Commission's proposal to require
updating of BC-DR plans and emergency procedures at least annually and
more frequently if necessitated by other circumstances.
3. Final Rule
The Commission has considered and evaluated the comment concerning
the frequency of updates to BC-DR plans and emergency procedures, with
which it agrees. As noted above, updating such plans at a frequency
determined by risk analysis but no less frequently than annually is
supported by generally accepted standards and best practices. The
Commission is adopting this provision as proposed.
D. Books and Records Requirements--Sec. Sec. 37.1401(g), 38.1051(g),
and 49.24(i)
1. Proposed Rule
As noted above, the Commission's current system safeguards rules
for all DCMs, SEFs, and SDRs contain a provision addressing required
production of system safeguards-related documents to the Commission on
request.\53\ The NPRM proposed amending these document production
provisions to further clarify requirements for system safeguards-
related document production.\54\ Specifically, the NPRM proposed
requiring each DCM, SEF, or SDR to provide to the Commission, promptly
on the request of Commission staff: Current copies of its BC-DR plans
and emergency procedures; all assessments of its operational risks or
system safeguards-related controls; all reports concerning system
safeguards testing and assessment; and all other books and records
requested in connection with Commission oversight of system
safeguards.\55\
---------------------------------------------------------------------------
\53\ 17 CFR 38.1051(g) and (h) (for DCMs); 17 CFR 37.1401(f) and
(g) (for SEFs); 17 CFR 49.24(i) and (j) (for SDRs).
\54\ 80 FR 80139, 80147 (Dec. 23, 2015).
\55\ Id.
---------------------------------------------------------------------------
2. Comments Received
Two commenters, CME and WMBAA, recognized the Commission's
established authority to require production of records, but asked the
Commission to continue to work with DCMs, SEFs, and SDRs to find ways
that highly sensitive system safeguards-related materials can be made
available to Commission staff in ways that maximize protection of their
confidentiality. WMBAA suggested that this could be accomplished in
appropriate cases by having CFTC staff review highly sensitive
information at a registrant's location or in a non-electronic, non-
reproducible format.
ICE, suggested that, with respect to parent firms that own both
CFTC-regulated and non-CFTC-regulated entities, the Commission should
avoid requiring production of documents discussing risks at the firm-
wide level, and limit its production requests to documents focused
solely on the risks of CFTC-regulated entities. In contrast, WMBAA
noted that a registrant's systems, such as SEF systems, are often a
subset of a larger financial services company's systems, and share
cybersecurity defenses, procedures, and testing with the parent entity
as a whole, rather than standing alone with respect to cybersecurity.
WMBAA suggested that it would be contrary to best practices for CFTC
oversight to focus solely on the risks and cybersecurity protections of
the CFTC-regulated entity's systems, without considering the related
systems and protections of the parent entity.
3. Final Rule
The Commission has considered and evaluated the comments concerning
the books and records provisions of the NPRM. For the reasons set forth
below, the Commission is adopting these provisions as proposed.
The established requirements of the Commission's regulations
regarding production of books and records are essential to the
Commission's ability to fulfill its oversight responsibilities. The
Commission also recognizes that the cybersecurity and system safeguards
information of DCMs, SEFs, and SDRs can be sensitive. As noted by
commenters, Commission staff conducting cybersecurity oversight work
regularly with regulated entities to find ways for sensitive
cybersecurity information to be made available to the Commission while
minimizing the risk of inappropriate disclosure.
The Commission has also considered and evaluated the comments
concerning production of books and records that address the system
safeguards risks and cybersecurity protections of parent companies. The
Commission agrees with WMBAA's observation that the automated systems,
programs of system safeguards-related risk analysis and oversight,
cybersecurity defenses and testing, and BC-DR plans and resources of
CFTC-regulated DCMs, SEFs, and SDRs owned by parent financial sector
companies that also own entities not regulated by the Commission are
frequently shared across the parent company. Indeed, this is presently
the case with respect to the parent companies of all DCMs, SEFs, and
SDRs regulated by the Commission which are subsidiaries of a parent
company. The Commission disagrees with ICE's suggestion that production
of books and records addressing parent-wide system safeguards risks and
risk analysis and oversight programs should not be required. Production
of all of the books and records specified in the NPRM books and records
provision is already required by the Act and Commission regulations,
notably by Commission regulation Sec. 1.31.\56\ Because DCMs, SEFs,
and SDRs often share system safeguards and cybersecurity risks, system
safeguards risk analysis and oversight programs, automated systems,
business continuity-disaster recovery
[[Page 64279]]
plans, and other system safeguards and cybersecurity resources with
their parent companies, the suggested limitation would in many cases--
including the case of ICE itself--cripple the oversight of system
safeguards risks and risk analysis and oversight programs for which the
CEA makes the Commission responsible, and thus would harm the public
interest. The Commission will continue to exercise its authority to
require production of all books and records relating to the system
safeguards of DCMs, SEFs, and SDRs, including those relating to the
system safeguards risks and risk analysis and oversight programs of
parent companies where such risks or such programs are shared in whole
or in part by a DCM, SEF, or SDR.
---------------------------------------------------------------------------
\56\ 80 FR 80139, 80147 (Dec. 23, 2015).
---------------------------------------------------------------------------
E. System Safeguards Testing--Sec. Sec. 37.1401(h), 38.1051(h), and
49.24(j)
The provisions of the NPRM addressing automated system testing by
DCMs, SEFs, and SDRs retained the language of the Commission's current
rules requiring these entities to conduct regular, periodic, objective
testing and review of their automated systems to ensure their
reliability, security, and adequate scalable capacity.\57\ They also
retained the language of the current rules requiring regular, periodic
testing and review of the business continuity-disaster recovery
capabilities of such entities. The NPRM proposed further clarification
of the current rules by specifying that such testing and review must
include vulnerability testing, penetration testing, controls testing,
security incident response plan testing, and enterprise technology risk
assessment, and defining certain terms related to such testing.\58\
---------------------------------------------------------------------------
\57\ Id. at 80147, 80148.
\58\ Id.
---------------------------------------------------------------------------
1. Definitions--Sec. Sec. 37.1401(h)(1), 38.1051(h)(1), and
49.24(j)(1)
a. Proposed Rule
For the purposes of the testing sections of the Commission's system
safeguards rules, the NPRM defined the following terms relating to
system safeguards testing and assessment by DCMs, SEFs, and SDRs:
Controls; controls testing; enterprise technology risk assessment;
external penetration testing; internal penetration testing; key
controls; security incident; security incident response plan; security
incident response plan testing; and vulnerability testing. With respect
to testing by DCMs, the NPRM also defined the following term: Covered
designated contract market.\59\
---------------------------------------------------------------------------
\59\ Id. at 80148.
---------------------------------------------------------------------------
b. Comments Received
Five commenters, CME, ICE, MGEX, DDR, and WMBAA, provided comments
concerning some of the definitions proposed in the NPRM.
(1) External and internal penetration testing.
ICE recommended that the definitions of external and internal
penetration testing specify that such testing should include scenario
or capture-the-flag testing intended to compromise the system
holistically via all available means including technical exploit,
social engineering, and lateral traversal. ICE also suggested that the
Commission clarify that penetration testing is not intended to include
application-specific tests, and recommended that the final rule should
avoid specifying parameters for internal penetration testing, in order
to allow each regulated entity to determine its own testing
methodology. Tradeweb suggested that external penetration testing
should be defined to mean penetration testing conducted over the
internet. WMBAA suggested that the final rule should not focus on
testing from a SEF system's perimeter, but should focus on all the
systems supporting the SEF's functionality, whether those of the SEF
itself or of its parent company.
(2) Controls and Key Controls
As part of its recommendation that the final rule eliminate all
requirements for controls testing (addressed in the discussion of
controls testing below), ICE recommended that the final rule should
remove the proposed definitions of controls and key controls.
(3) Covered Designated Contract Market
MGEX commented that the definitional distinction between covered
and non-covered DCMs is a valuable concept that recognizes the lower
systemic risk posed by smaller entities.\60\ However, CME commented
that the distinction is unnecessarily complex and imposes undue
burdens, and suggested that the final rule adopt a uniform set of
standards for all DCMs. CME also suggested that if the covered DCM
concept were to be retained, the Commission should consider
alternatives to annual DCM reporting of total annual trading volume,
because the Commission currently receives volume reports pursuant to
DCM Core Principle 8 and part 16 of the Commission's regulations.
---------------------------------------------------------------------------
\60\ MGEX commented that the Commission should use a similar
definition to distinguish between larger and smaller derivatives
clearing organizations (``DCOs''). MGEX also made these comments in
its comment letter concerning the Commission's NPRM regarding system
safeguards testing by DCOs, available at: http://comments.cftc.gov/PublicComments/ViewComment.aspx?id=60651&SearchText=. Since testing
by DCOs is not addressed by this final rule, but will be addressed
in the final rule regarding DCO system safeguards testing, these
comments are most appropriately addressed in the DCO system
safeguards testing final rule, and are addressed there.
---------------------------------------------------------------------------
(4) Security Incident
The NPRM defined ``security incident'' as a cyber security or
physical security event that actually or potentially jeopardizes
automated system operation, reliability, security, or capacity, or the
availability, confidentiality, or integrity of data. No comments were
received concerning the NPRM definition. However, the Commission
received a comment from the Options Clearing Corporation (``OCC'')
concerning the identical definition included in the parallel Notice of
Proposed Rulemaking issued by the Commission on December 15, 2015,
proposing to amend its system safeguards rules for DCOs.\61\ OCC argued
that including in the definition events that ``potentially'' jeopardize
automated systems or data renders the definition vague, and could be
interpreted to include most, if not all, cybersecurity events
experienced by a DCO. OCC suggested amending the definition to replace
``potentially jeopardizes'' with ``has a significant likelihood of
jeopardizing.''
---------------------------------------------------------------------------
\61\ 80 FR 80113 (Dec. 23, 2015). The OCC comment letter is
available at http://comments.cftc.gov/PublicComments/ViewComment.aspx?id=60650&SearchText=.
---------------------------------------------------------------------------
Some comments also addressed terms that were used but not defined
in the NPRM. Although the NPRM did not define the terms ``recovery'' or
``resumption,'' DDR commented that, in its view, the NPRM distinguished
between resumption of critical functions following a cyber incident on
the one hand, and recovery in the sense of restoration of capabilities
or services impaired due to a cyber event. Noting that this distinction
is consistent with the definitions of these terms in the CMPI-IOSCO
Guidance on Cyber Resilience for Financial Market Infrastructures--
Consultative Report of November 24, 2015,\62\ DDR stated that in this
respect the NPRM appropriately recognized differences among financial
market infrastructures with respect to varying requirements for
recovery and resumption timeframes.
---------------------------------------------------------------------------
\62\ CPMI-IOSCO, Guidance on Cyber Resilience for Financial
Market Infrastructures--Consultative Report (Nov. 2015), at 26,
available at https://www.iosco.org/library/pubdocs/pdf/IOSCOPD513.pdf.
---------------------------------------------------------------------------
[[Page 64280]]
CME, ICE, and MGEX commented concerning the NPRM's use of the terms
``independent contractor'' and ``independent professional.'' CME
asserted that neither term is clearly defined in either the
Commission's current rules or the NPRM. ICE called on the Commission to
clarify in the final rule that entity employee groups such as the
internal audit function are considered to be independent professionals
not responsible for the development of operation of the systems or
capabilities tested or assessed in the area of system safeguards. While
not commenting directly on these definitions, MGEX expressed the view
that having independent testing performed is a key and costly feature
proposed in the NPRM.
c. Final Rule
The Commission has considered and evaluated the comments concerning
the definitions proposed in the NPRM. For the reasons discussed below,
the final rule will amend the definition of security incident, and
otherwise retain the definitions as proposed.
(1) External and Internal Penetration Testing
The Commission agrees with ICE's suggestion that penetration
testing that attempts to compromise an entity's systems holistically
through means including technical exploit, social engineering, and
lateral traversal is appropriate to today's cybersecurity threat
environment. The Commission also agrees with ICE's recommendation that
the final rule should avoid specifying particular internal penetration
testing parameters in order to give DCMs, SEFs, and SDRs flexibility in
determining their particular methodology for such testing, and believes
that approach is also appropriate regarding external penetration
testing. Best practices indicate that with respect to penetration
testing, entities should regularly ``update the list of attack
techniques and exploitable vulnerabilities used in penetration testing
based on an organizational assessment of risk or when significant new
vulnerabilities or threats are identified and reported.'' \63\ Where
penetration testing that attempts to compromise systems holistically
through means including technical exploit, social engineering, and
lateral traversal is called for by appropriate risk analysis, as it may
be in most or even all cases, the final rule will require penetration
testing using such means, by virtue of its requirement for all DCMs,
SEFs, and SDRs to follow best practices, and its requirement for all
DCMs, SEFs, and SDRs to make the scope of their cybersecurity testing
broad enough to include all testing that their programs of risk
analysis and current cybersecurity threat analysis indicate is
necessary. The Commission notes that essential penetration testing
methods and techniques may change over time, based on an entity's
appropriate risk analysis, technological changes, and the evolving
nature of cybersecurity threats. The Commission disagrees with
Tradeweb's suggestion that external penetration testing should be
defined as testing conducted over the Internet. Best practices indicate
that external penetration testing should be conducted from multiple
vectors including remote access, virtual private network connections,
and any separate environments or local area network segments, as well
as the internet.\64\ In addition, such testing should include not only
Iinternet based or network-layer based tests but also application-layer
assessments. The Commission agrees with WMBAA's comment that
penetration testing must include testing of all systems supporting a
regulated entity's functionality or involved in the entity's system
safeguards, whether the systems belong to the entity itself or to the
entity's parent company.
---------------------------------------------------------------------------
\63\ NIST SP 800-53A, Rev. 4, Assessing Security and Privacy
Controls in Federal Information Systems and Organizations--Building
Effective Assessment Plans, at E-1, http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53Ar4.pdf.
\64\ See, e.g., Security Standards Council, Payment Card
Industry Data Security Standards, Apr. 2016, v. 3.2 (``PCI DSS''),
available at https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-2.pdf, Information Supplement: Penetration Testing
Guidance, at 5-8, available at https://www.pcisecuritystandards.org/documents/Penetration_Testing_Guidance_March_2015.pdf; and Center
for Internet Security, Critical Security Controls, at 68-69,
available at https://www.cisecurity.org/critical-controls/.
---------------------------------------------------------------------------
(2) Covered Designated Contract Market
The Commission has considered and evaluated the comments for and
against the NPRM's definitional distinction between covered and non-
covered DCMs. The Commission continues to believe that the NPRM's
proposed requirements regarding the minimum frequencies at which
various types of cybersecurity testing should be conducted and
regarding the use of independent contractors to perform specified tests
are important and appropriate in today's cybersecurity threat
environment. As noted in the NPRM, these requirements aim to strengthen
the objectivity and reliability of the testing and assessment
information available to the Commission regarding system safeguards,
and to ensure the effectiveness and timeliness of both cybersecurity
testing and programs of risk analysis and oversight.\65\ Additionally,
the use of independent contractors for many types of testing is
consonant with best practices. The Commission also continues to believe
that application of these requirements to DCMs whose annual total
trading volume is five percent or more of the annual total trading
volume of all DCMs regulated by the Commission is appropriate. This
approach reduces possible costs and burdens for smaller and less
systemically critical DCMs, by giving them additional flexibility
regarding their cybersecurity testing. The fact that smaller DCMs will
still be required to conduct testing of all the types addressed in the
final rule means that this approach will not impair the fundamental
goals of the CEA and the Commission's system safeguards regulations.
The NPRM also proposed offering such added flexibility to SEFs, which
like non-covered DCMs are required to conduct all of the specified
types of testing but not made subject to the minimum frequency and
independent contractor requirements. The Commission continues to
believe this to be appropriate as well, for the same reasons.\66\
---------------------------------------------------------------------------
\65\ 80 FR 80139, 80148 (Dec. 23, 2015).
\66\ Id.
---------------------------------------------------------------------------
The Commission declines CME's suggestion that it rely on DCM volume
reports submitted pursuant to part 16 of the Commission's regulations.
The Commission notes that while it receives daily trade information
from DCMs pursuant to part 16, it does not receive total annual trading
volume information from DCMs.\67\ The Commission believes that DCM
submission of annual trading volume requirement is essential for the
Commission to accurately evaluate whether a particular DCM must comply
with the frequency and independent contractor requirements as a covered
DCM. The Commission believes that annual total trading volume
information is readily available to DCMs, and that DCMs generally
calculate their annual trading volume in the usual course of business.
The Commission does not believe that looking up the amount of a DCM's
annual total trading volume and reporting that amount to the Commission
once a year, something that can be done by email in thirty minutes
[[Page 64281]]
or less, can reasonably be said to impose an undue burden on a DCM.
---------------------------------------------------------------------------
\67\ Core Principle 8 is inapplicable here, because it requires
DCMs to publish daily volume information but does not require
submission of that information to the Commission.
---------------------------------------------------------------------------
(3) Security Incident
The Commission has considered and evaluated OCC's comment
concerning the definition of ``security incident'' included in the
Commission's parallel NPRM proposing amendment of its system safeguards
rules for DCOs. The Commission is amending the definition as the
comment suggested, defining security incident as a cyber security or
physical security event that ``actually jeopardizes or has a
significant likelihood of jeopardizing'' automated systems or data. The
definition included in the DCO NPRM is identical to the one included in
the NPRM regarding DCMs, SEFs, and SDRs. The Commission issued the two
NPRMs simultaneously and in parallel, and intended that the final rules
issued in connection with both NPRMs should be closely aligned.
Accordingly, the Commission believes the comment received is germane to
both final rules. The Commission also notes that the amendment of this
definition does not expand the definition's reach but rather narrows it
somewhat, and therefore lightens any costs or burdens involved to at
least some degree.
(4) Recovery and Resumption
With respect to DDR's comment regarding the terms ``recovery'' and
``resumption,'' the Commission notes that the NPRM did not, and the
final rule will not, define these terms or make any change to the
language or the requirements of the Commission's current system
safeguards rules for DCMs, SEFs, or SDRs regarding recovery and
resumption of operations and fulfillment of responsibilities and
obligations as a registered entity.
(5) Independent Contractor and Independent Professional
The Commission has considered and evaluated the various comments
concerning the terms ``independent contractor'' and ``independent
professional'' used in the NPRM.\68\ The Commission notes that both
terms are effectively defined in the Commission's current system
safeguards rules for DCMs and SDRs and its current system safeguards
rules and guidance for SEFs.\69\ These current provisions call for the
system safeguards testing required of all DCMs, SEFs, and SDRs to be
conducted by qualified, independent professionals, who may be
independent contractors or employees of the DCM, SEF, or SDR, but
should not be persons responsible for development or operation of the
systems or capabilities being tested.\70\
---------------------------------------------------------------------------
\68\ 80 FR 80139, 80146 through 80161 (Dec. 23, 2015).
\69\ 17 CFR Sec. Sec. 38.1051(h) (for DCMs); 37.1401 (g) and
Appendix B to Part 37, Core Principle 14 of Section 5h of the Act--
System Safeguards (C)(a)(2) (for SEFs); 49.24(j) (for SDRs).
\70\ Id.
---------------------------------------------------------------------------
Accordingly, for purposes of the current system safeguards rules,
independent contractors are qualified system safeguards professionals
who are not employees of the DCM, SEF, or SDR. The current rules use
the terms independent contractor and employee as they are legally
defined and generally used.\71\ The Commission believes that the
distinction between independent contractor and employee is well settled
and understood, and does not need additional definition in the system
safeguards rules.
---------------------------------------------------------------------------
\71\ See, e.g., Black's Law Dictionary, Tenth Ed. (Thomson
Reuters, St. Paul, MN, 2014) (``Employee. Someone who works in the
service of another person (the employer) under an express or implied
contract of hire, under which the employer has the right to control
the details of work performance.'') (``Independent Contractor.
Someone who is entrusted to undertake a specific project but who is
left free to do the assigned work and to choose the method for
accomplishing it.'')
---------------------------------------------------------------------------
With respect to system safeguards testing, the current rules
provide that employees conducting required testing must be independent
in that they are not employees responsible for development or operation
of the systems or capabilities being tested. The Commission believes
that this distinction between employees with sufficient independence to
appropriately conduct required system safeguards testing and those who
lack such independence is also sufficiently clear, and does not require
additional definition. The NPRM used, and the final rule will retain,
this language from the current system safeguards rules. Where this
requirement is included, the testing in question must be conducted by
employees who are independent, which means employees not responsible
for developing or operating what is being tested.\72\ Employees who are
part of the internal audit function of a DCM, SEF, or SDR, are one
example of employees having appropriate independence. Other employees
who possess the specified degree of independence and have
qualifications the DCM, SEF, or SDR believes are appropriate may also
be suitable in such cases.
---------------------------------------------------------------------------
\72\ This requirement is included in the final rule provisions
concerning most types of testing, but as discussed below is not
included in the SIRP testing provision.
---------------------------------------------------------------------------
One clarification may be helpful with respect to testing required
to be performed by independent contractors, as distinct from testing
performed by persons performing the internal audit function. As noted
above, the internal audit function is a required aspect of the
enterprise risk management and governance category which must be
included in the program of risk analysis and oversight that a DCM, SEF,
or SDR must maintain. It is an integral part of, and a responsibility
of, the regulated entity, whether carried out in-house or outsourced.
The NPRM proposed required testing by independent contractors in part
to give the Commission's system safeguards oversight a third source of
system safeguards information on which to rely, in addition to the
entity's employees and its internal audit function.\73\ It also
proposed independent contractor testing to give the regulated entity
the benefit of a truly outside perspective concerning system
safeguards, not colored by beginning from the institutional point of
view, something that best practices say is important as noted earlier.
Accordingly, testing performed by persons executing the internal audit
function will not fulfill the requirement for testing by independent
contractors, whether it is performed by employees executing the
internal audit function or by internal audit contractors to whom a DCM,
SEF, or SDR outsources part or all of its internal audit function.
---------------------------------------------------------------------------
\73\ 80 FR 80139, 80148 (Dec. 23, 2015).
---------------------------------------------------------------------------
2. Vulnerability Testing--Sec. Sec. 37.1401(h)(2), 38.1051(h)(2), and
49.24(j)(2)
a. Proposed Rule
The NPRM called for all DCMs, SEFs, and SDRs to conduct
vulnerability testing of a scope sufficient to satisfy the requirements
in the proposed rule.\74\ It proposed requiring all such entities to
conduct vulnerability testing at a frequency determined by an
appropriate risk analysis, with a minimum frequency requirement of
quarterly vulnerability testing for covered DCMs and SDRs.\75\ The NPRM
called for vulnerability testing to include automated vulnerability
scanning, conducted on an authenticated basis where indicated by
appropriate risk analysis, with compensating controls where scanning is
conducted on an unauthenticated basis. The NPRM called for covered DCMs
and SDRs to engage independent contractors to conduct two of the
minimum quarterly vulnerability tests required of them each
[[Page 64282]]
year.\76\ It provided that all other vulnerability testing by covered
DCMs and SDRs, and all vulnerability testing by non-covered DCMs and
SEFs, should be conducted either by independent contractors or by
employees not responsible for development or operation of the systems
or capabilities being tested.\77\
---------------------------------------------------------------------------
\74\ 80 FR 80139, 80148 through 80151 (Dec. 23, 2015).
\75\ Id. at 80149, 80150.
\76\ Id. at 80150.
\77\ Id. at 80150, 80151.
---------------------------------------------------------------------------
b. Comments Received
(1) Requirement for Vulnerability Testing
Several commenters, including CME, ICE, and Nadex, agreed that the
NPRM's call for vulnerability testing was appropriate, because such
testing is critical to identification and remediation of cybersecurity
vulnerabilities. CME stated that vulnerability testing, of a scope
aligned with risk analysis, should be embedded in an organization's
systems development life cycle, in order to promote a culture of
awareness as early and close to the first line of defense as possible.
(2) Vulnerability Testing Frequency
Commenters, including CME and ICE, supported the minimum quarterly
vulnerability testing frequency requirement for covered DCMs and SDRs.
CME noted that at least quarterly testing is likely to be an
appropriate frequency for most organizations where critical assets are
concerned. Regarding the requirement to test as often as indicated by
appropriate risk analysis, CME agreed that vulnerability testing
frequency should be aligned with appropriate risk analysis. MGEX called
for the final rule to leave the frequency of vulnerability testing to
be determined by regulatees. ICE argued that regulatees should not be
subject to a formal risk assessment to potentially determine a higher
vulnerability testing frequency. Nadex asked the Commission to confirm
that the level of detail in the risk assessment used to determine
appropriate vulnerability testing frequency is that called for by
generally accepted standards and best practices.
(3) Automated Scanning and Authenticated Scanning
Commenters raised no issue with the NPRM requirement for
vulnerability testing to include automated vulnerability scanning. ICE
called for removal of the requirement for automated scanning to include
authenticated scanning, arguing that this requirement would increase
the cost and time of a scan, increase risk through creation of an
operating system login on a new system, and have limited utility in the
context of financial system infrastructure.
(4) Vulnerability Testing by Independent Contractors
A number of commenters argued that the use of independent
contractors for vulnerability testing could undesirably increase risks.
CME suggested that outsider access to systems can broaden both
operations risk and the risk of disclosure of sensitive information,
and noted that there is a limited supply of independent contractors
with appropriate qualifications for vulnerability testing. ICE
commented that vulnerability scanners can be hazardous to systems, can
cause issues during deployment, and require a high level of care to
avoid live system jeopardy, including both intimate network knowledge
and change control interaction. In short, ICE stated, third-party
vulnerability scanning would be costly and potentially dangerous
without adding value. DDR stated that vulnerability testing by
independent contractors would introduce unnecessary risk to critical
infrastructure and heighten the risk of systems outages. These
commenters therefore requested that the final rule eliminate the
independent contractor requirement for vulnerability testing, and
permit such testing to be conducted by entity employees not responsible
for development or operation of the systems or capabilities tested. CME
suggested that allowing such employees to conduct vulnerability testing
has been proven effective, allows testing by those with the greatest
knowledge and experience concerning the systems tested, and has the
benefit of promoting an organizational culture of cybersecurity
awareness. DDR recommended that SDR employees conduct vulnerability
testing, and that independent contractors review testing procedures to
confirm that they are effective and consonant with industry standards.
c. Final Rule
The Commission has considered and evaluated the comments concerning
vulnerability testing. For the reasons set out below, the final rule
will call for vulnerability testing and include the proposed
vulnerability testing frequency requirements, but will not require that
automated vulnerability scanning include authenticated scanning, and
will not require the use of independent contractors as proposed.
(1) Requirement for Vulnerability Testing
The Commission agrees with commenters that vulnerability testing is
critical to identification and remediation of cybersecurity
vulnerabilities. It is an essential component of an effective program
of risk analysis and oversight, and an essential means of fulfilling
the testing requirements of the Commission's current system safeguards
rules.
(2) Vulnerability Testing Frequency
The Commission agrees with the comments supporting the minimum
quarterly vulnerability testing requirement for covered DCMs and SDRs,
and agrees that, in today's cybersecurity environment, most
organizations should conduct such testing at least quarterly. The
Commission also agrees that, beyond the minimum frequency proposed for
covered DCMs and SDRs, all DCMs, SEFs, and SDRs should conduct
vulnerability testing as frequently as indicated by appropriate risk
analysis. The Commission disagrees with the suggestion that the
frequency of vulnerability testing should simply be left to these
entities themselves. It is essential for such testing to be conducted
as frequently as indicated by analysis of a particular entity's risks,
which is likely in most cases to call for testing at least quarterly.
The risk analysis referred to in the NPRM in this connection is the
appropriate risk analysis which each DCM, SEF, and SDR must conduct and
maintain as an integral part of the program of risk analysis and
oversight that the CEA requires. ICE apparently misunderstood the NPRM
as calling for a separate, formal risk analysis made for the specific
purpose of determining vulnerability testing frequency. That is not
required; what is required is vulnerability testing as often as
indicated by the ongoing, appropriate risk analysis inherent in a
regulatee's required program of risk analysis and oversight. As
provided in the current system safeguards rules and in the NPRM, the
program of risk analysis required of a DCM, SEF, or SDR, and the risk
analyses inherent in that program, are indeed to be conducted in light
of generally accepted standards and best practices.\78\
---------------------------------------------------------------------------
\78\ 80 FR 80139, 80149, 80150 (Dec. 23, 2015).
---------------------------------------------------------------------------
(3) Automated Scanning and Authenticated Scanning
No commenters disagreed with the proposed requirement for
vulnerability testing to include automated
[[Page 64283]]
vulnerability scanning. In light of ICE's suggestion that the proposed
requirement for automated scanning to include authenticated scanning
could increase costs, burdens, and risks while having limited utility
for DCMs, SEFs, and SDRs, the Commission has decided to remove the
authenticated scanning requirement from the final rule. Instead, the
final rule provides that automated vulnerability scanning must follow
best practices. The Commission notes that, to the extent that best
practices require or come to require authenticated scanning, such
scanning would be mandatory pursuant to the requirement to follow best
practices, and would be addressed in system safeguards examinations.
(4) Vulnerability Testing by Independent Contractors
The Commission has carefully considered the multiple comments
suggesting that use of independent contractors for vulnerability
testing could undesirably increase risks, raise hazards for automated
systems, and increase costs and dangers without adding value. The
Commission has also noted the comment that vulnerability testing
conducted by employees not responsible for development or operation of
the systems or capabilities tested has been proven effective, provides
expertise valuable in vulnerability testing, and promotes an
organizational culture of cybersecurity awareness. For these reasons,
and in order to reduce costs and burdens to the extent practicable
while still achieving the purposes of the CEA and of the NPRM, the
final rule does not include the proposed requirement for covered DCMs
and SDRs to have some vulnerability testing conducted by independent
contractors. Instead, the final rule permits all DCMs, SEFs, and SDRs
to conduct all required vulnerability testing by using either
independent contractors or entity employees not responsible for
development or operation of the systems or capabilities being tested.
The Commission acknowledges the value of DDR's recommendation that
independent contractors evaluate the effectiveness of the regulatee's
vulnerability testing procedures and their consistency with best
practices. While the final rule's vulnerability testing provisions will
not incorporate such a requirement, the Commission observes that such
independent validation of vulnerability testing procedures should
likely be included as part of a regulatee's controls testing program.
3. External Penetration Testing--Sec. Sec. 37.1401(h)(3),
38.1051(h)(3), and 49.24(j)(3)
a. Proposed Rule
The NPRM called for all DCMs, SEFs, and SDRs to conduct external
penetration testing of a scope sufficient to satisfy the requirements
in the proposed rule.\79\ It proposed requiring all such entities to
conduct external penetration testing at frequency determined by an
appropriate risk analysis, with a minimum frequency requirement of
annual external penetration testing for covered DCMs and SDRs.\80\ The
NPRM called for covered DCMs and SDRs to engage independent contractors
to conduct the annual external penetration test required of them.\81\
It provided that all other external penetration testing by covered DCMs
and SDRs, and all external penetration testing by non-covered DCMs and
SEFs, should be conducted either by independent contractors or by
employees not responsible for development or operation of the systems
or capabilities being tested.\82\
---------------------------------------------------------------------------
\79\ 80 FR 80139, 80152 (Dec. 23, 2015).
\80\ Id. at 80152, 80153.
\81\ Id. at 80153.
\82\ Id. at 80152, 80153.
---------------------------------------------------------------------------
b. Comments Received
(1) Requirement for External Penetration Testing
Commenters raised no issue with the NPRM's call for external
penetration testing. CME noted that penetration testing is a
significant component of the program to identify and minimize sources
of operational risk required of all DCMs, SEFs, and SDRs. CME also
approved the flexibility concerning penetration test design provided in
the NPRM. Nadex noted its agreement with the NPRM's penetration testing
requirement.
(2) External Penetration Testing Frequency
Commenters also raised no issue with the requirement for all DCMs,
SEFs, and SDRs to conduct external penetration testing at a frequency
determined by appropriate risk analysis. CME noted that many risk based
factors should inform the frequency of such testing. Several commenters
also supported the annual minimum frequency requirement for external
penetration testing by covered DCMs and SDRs. CME stated that annual
external penetration testing generally will be appropriate, ICE stated
that it agrees with the annual requirement, and Nadex agreed with the
NPRM's penetration testing requirements. MGEX called for the final rule
to leave the frequency of external penetration testing to be determined
by regulatees. ICE argued that regulatees should not be subject to a
formal risk assessment to potentially determine a higher penetration
testing frequency.
(3) External Penetration Testing by Independent Contractors
Most commenters raised no issue with the requirement for covered
DCMs and SDRs to have the required annual external penetration test
conducted by independent contractors. DDR commented generally that an
SDR should have flexibility regarding whether to have testing conducted
by independent contractors or employees not responsible for development
or operation of the systems or capabilities tested, based on the risks
of that SDR.
c. Final Rule
The Commission has considered and evaluated the comments concerning
external penetration testing. For the reasons discussed below, the
final rule will include the NPRM provisions regarding such testing as
proposed.
(1) Requirement for External Penetration Testing
The Commission agrees with commenters that external penetration
testing is a significant and essential component of an effective
program of system safeguards risk analysis and oversight. Such testing
is an essential means of fulfilling the testing requirement in the
Commission's current system safeguards rules.
(2) External Penetration Testing Frequency
The Commission agrees with the comment that many risk based factors
should inform the frequency of external penetration testing, and notes
that this is true for all DCMs, SEFs, and SDRs. The Commission also
agrees with the comments supporting the minimum frequency requirement
of annual external penetration testing by covered DCMs and SDRs. As
noted in the NPRM, this requirement is supported by generally accepted
standards and best practices, which make it clear that such testing at
least annually is essential to adequate system safeguards in today's
cybersecurity environment. For this reason, the Commission disagrees
with the suggestion that the frequency of such testing by covered DCMs
and SDRs should be left to determination by those entities themselves.
The proposal's minimum requirement was for a single
[[Page 64284]]
annual test; although, as noted in the NPRM, adequate risk analysis
could well require more frequent testing in light of the risks faced by
a particular regulatee.\83\ A separate, formal risk analysis made for
the specific purpose of determining external penetration testing
frequency is not required. Rather, external penetration testing is
required as often as indicated by the ongoing, appropriate risk
analysis inherent in a regulatee's statutorily-required program of risk
analysis and oversight, conducted in light of generally accepted
standards and best practices.
---------------------------------------------------------------------------
\83\ Id. at 80152.
---------------------------------------------------------------------------
(3) External Penetration Testing by Independent Contractors
In determining the final rule's provisions regarding external
penetration testing by independent contractors, the Commission has
noted that, as set forth above, most commenters raised no issue with
this requirement for covered DCMs and SDRs. As noted in the NPRM,
generally accepted standards and best practices make it clear that
independent testing by third party service providers is an essential
component of an adequate testing regime, and that this is notably the
case with respect to penetration testing.\84\ The Commission believes
that the independent viewpoint and approach provided by independent
contractors, who can conduct a penetration test from the perspective of
an outside adversary uncolored by insider assumptions or blind spots,
will benefit covered DCM and SDR programs of risk analysis and
oversight. Independent contractor penetration testing will strengthen
Commission oversight of system safeguards, by providing an important,
credible third source of information in addition to what is available
from covered DCM or SDR staff and from the internal audit function of
those entities. In light of these considerations, the Commission
disagrees with the comments suggesting elimination of the requirement
for the minimum annual external penetration test of a covered DCM or
SDR to be conducted by independent contractors.
---------------------------------------------------------------------------
\84\ Id. at 80153.
---------------------------------------------------------------------------
4. Internal Penetration Testing--Sec. Sec. 37.1401(h)(4),
38.1051(h)(4), and 49.24(j)(4)
a. Proposed Rule
The NPRM called for all DCMs, SEFs, and SDRs to conduct internal
penetration testing of a scope sufficient to satisfy the requirements
in the proposed rule.\85\ It proposed requiring all such entities to
conduct external penetration testing at a frequency determined by an
appropriate risk analysis, with a minimum frequency requirement of
annual internal penetration testing for covered DCMs and SDRs.\86\ The
NPRM provided that all internal penetration testing by DCMs, SEFs, or
SDRs should be conducted either by independent contractors or by
employees not responsible for development or operation of the systems
or capabilities being tested.\87\
---------------------------------------------------------------------------
\85\ 80 FR 80139, 80152 (Dec. 23, 2015).
\86\ Id. at 80152, 80153.
\87\ Id.
---------------------------------------------------------------------------
b. Comments Received
(1) Requirement for Internal Penetration Testing
Commenters raised no issue with the NPRM's call for internal
penetration testing. As noted above concerning external penetration
testing, CME noted that penetration testing generally is a significant
component of the program to identify and minimize sources of
operational risk required of all DCMs, SEFs, and SDRs, and approved the
flexibility concerning penetration test design provided in the NPRM.
Also as noted above, Nadex stated its agreement with the NPRM's
penetration testing requirements.
(2) Internal Penetration Testing Frequency
Commenters also raised no issue with the requirement for all DCMs,
SEFs, and SDRs to conduct internal penetration testing at a frequency
determined by appropriate risk analysis. As noted above, CME stated
that many risk based factors should inform the frequency of penetration
testing generally. With respect to the requirement for covered DCMs and
SDRs to conduct internal penetration testing at least annually, ICE
stated agreement with the proposal. Nadex agreed with the proposed
penetration testing requirements generally. On the basis that that
there is a scarcity of potential employees with the skill set required
to conduct internal penetration testing without introducing risks into
the production environment and other sensitive environments, CME
suggested making annual internal penetration testing an objective
rather than a requirement, so that covered DCMs and SDRs can prioritize
truly effective testing over less skilled testing done merely to
satisfy the annual requirement. As noted above, MGEX called for the
final rule to leave the frequency of penetration testing to be
determined by regulatees. ICE argued that regulatees should not be
subject to a formal risk assessment to potentially determine a higher
penetration testing frequency.
(3) Who Should Perform Internal Penetration Testing
Commenters raised no issue with the NPRM provision giving all DCMs,
SEFs, and SDRs the choice of whether to have internal penetration
testing performed by independent contractors or by employees not
responsible for development or operation of the systems or capabilities
tested.
c. Final Rule
The Commission has considered and evaluated the comments concerning
internal penetration testing. For the reasons discussed below, the
final rule will include the NPRM's internal penetration testing
provisions as proposed.\88\
---------------------------------------------------------------------------
\88\ 80 FR 80139, 80152, 80153 (Dec. 23, 2015).
---------------------------------------------------------------------------
(1) Requirement for Internal Penetration Testing
The Commission agrees with commenters that external penetration
testing is a significant and essential component of an effective
program of system safeguards risk analysis and oversight. Such testing
is an essential means of fulfilling the testing requirement in the
Commission's current system safeguards rules.
(2) Internal Penetration Testing Frequency
The Commission agrees with the comment that many risk based factors
should inform the frequency of internal penetration testing, and notes
that this is true for all DCMs, SEFs, and SDRs. It also agrees with the
comments supporting the minimum frequency requirement of annual
internal penetration testing by covered DCMs and SDRs. As noted in the
NPRM, this requirement, like the parallel requirement regarding
external penetration testing, is supported by generally accepted
standards and best practices, which make it clear that such testing at
least annually is essential to adequate system safeguards in today's
cybersecurity environment.\89\ Accordingly, the Commission disagrees
with the suggestions that annual internal penetration testing by
covered DCMs and SDRs should be a mere objective, or that the frequency
of such testing by covered DCMs and SDRs should be left to
determination by those entities themselves. The Commission also notes,
as it stated in the NPRM, that
[[Page 64285]]
adequate risk analysis could well require more frequent testing in
light of the risks faced by a particular regulatee.\90\ A separate,
formal risk analysis made for the specific purpose of determining
internal penetration testing frequency is not required. Rather,
internal penetration testing is required as often as indicated by the
ongoing, appropriate risk analysis inherent in a regulatee's required
program of risk analysis and oversight, conducted in light of generally
accepted standards and best practices.
---------------------------------------------------------------------------
\89\ Id.
\90\ Id.
---------------------------------------------------------------------------
(3) Who Should Perform Internal Penetration Testing
The Commission continues to believe, as provided in the NPRM, that
it is appropriate to give all DCMs, SEFs, and SDRs the choice of
whether to have internal penetration testing performed by independent
contractors or by employees not responsible for development or
operation of the systems or capabilities tested.\91\ Commenters raised
no issue with this provision.
---------------------------------------------------------------------------
\91\ Id. at 80153.
---------------------------------------------------------------------------
5. Controls Testing--Sec. Sec. 37.1401(h)(5), 38.1051(h)(5), and
49.24(j)(5)
a. Proposed Rule
The NPRM called for each DCM, SEF, and SDR to conduct controls
testing of a scope sufficient to satisfy the scope requirements in the
proposed rule, including testing of each control included in the
entity's program of risk analysis and oversight.\92\ It proposed each
such entity to conduct controls testing at frequency determined by an
appropriate risk analysis, with a minimum frequency requirement for
covered DCMs and SDRs calling for testing of all controls every two
years.\93\ The NPRM provided that covered DCMs and SDRs could conduct
such testing on a rolling basis over the minimum two-year period or
over the minimum period determined by appropriate risk analysis,
whichever is shorter.\94\ The NPRM called for covered DCMs and SDRs to
engage independent contractors to conduct testing of key controls no
less frequently than every two years.\95\ It provided that all other
controls testing by covered DCMs and SDRs, and all controls testing by
non-covered DCMs and SEFs, should be conducted either by independent
contractors or by employees not responsible for development or
operation of the systems or capabilities being tested.\96\
---------------------------------------------------------------------------
\92\ Id. at 80153, 80154.
\93\ Id. at 80154.
\94\ Id.
\95\ Id.
\96\ Id. at 80154, 80155.
---------------------------------------------------------------------------
b. Comments Received
(1) Requirement for Controls Testing
CME and Nadex approved of the NPRM's call for controls testing. CME
stated that the NPRM correctly identified controls testing as a crucial
part of a program of risk analysis and oversight, and agreed with the
categories which the current rules and the NPRM specify as included in
such a program. CME also agreed with the NPRM's flexible approach to
using best practices to inform the design and implementation of
controls testing in light of risk analysis. ICE called for the final
rule to eliminate the requirement for controls testing, arguing that
many controls do not require testing, that few organizations have a
static universe of controls, and that control weaknesses will come to
light in vulnerability and penetration testing. Tradeweb asked the
Commission to provide further guidance on how controls testing differs
from vulnerability testing, whether Service Organization Controls
(``SOC'') 1 and 2 reports prepared in accordance with the American
Institute of Certified Public Accountants' Statement on Standards for
Attestation Engagements (``SSAE'') Number 16 could be used for controls
testing purposes, and whether penetrations tests could be used to
fulfill controls testing requirements.
(2) Controls Testing Frequency
Regarding the minimum controls testing frequency of every two years
proposed for covered DCMs and SDRs, CME commented that some less
critical controls do not warrant testing on a two-year cycle, and cited
best practices permitting controls testing on a three-year cycle. CME
suggested that the final rule should call for the minimum controls
testing frequency for covered DCMs and SDRs to be determined by risk
analysis (as the NPRM proposed for non-covered DCMs and SEFs), or
alternatively that a minimum frequency cycle of three years would be a
reasonable alternative to the NPRM's proposed two-year cycle. CME
suggested that, while many organizations will implement a two-year
schedule for at least the testing of key controls, either of CME's
proposed alternatives would make controls testing more cost effective,
and increase focus on the most critical controls.
(3) Who Should Perform Controls Testing
CME commented that effective testing of key controls can be done by
employees not responsible for development or operation of the controls
tested, as well as by independent contractors, and that such
independent employees' familiarity with the organization's controls can
improve the efficiency and effectiveness of controls testing.
Accordingly, CME suggested that, while independent contractor controls
testing may be beneficial, the final rule should not exclude controls
testing by independent employees, for example employees such as
internal audit staff. DDR also commented that, where the NPRM proposed
to require independent contractor testing, the final rule should give
flexibility to use either independent contractors or independent
employees. ICE suggested that the final rule should not require key
controls testing at all. In support, ICE argued that the concept of key
controls is not universally adopted; that risk analysis relies on
testing of all controls in concert; that a testing requirement directed
at key controls could result in organizations documenting fewer
controls; and that the key controls testing proposal would impose a
large burden for little or no practical improvement in security. MGEX
stated that the NPRM required testing of all controls on a rolling
basis by independent contractors every two years.
c. Final Rule
The Commission has considered and evaluated the comments concerning
controls testing. For the reasons discussed below, the Commission is
adopting the NPRM's requirement for all DCMs, SEFs, and SDRs to conduct
testing of all their system safeguards-related controls, its
requirement for such testing by all such entities to be conducted as
often as indicated by appropriate risk analysis, and its requirement
for independent contractor testing of the key controls of covered DCMs
and SDRs. However, for the reasons discussed below concerning controls
testing frequency, the Commission is modifying the proposed controls
testing minimum frequency requirement for covered DCMs and SDRs, to
call for testing of their key controls--including independent
contractor testing of such controls--within a three-year rather than a
two-year period.
[[Page 64286]]
(1) Requirement for Controls Testing
The Commission agrees with commenters that controls testing is a
crucial part of a program of risk analysis and oversight and that best
practices should inform the design and implementation of controls
testing in light of risk analysis. In today's rapidly-changing
cybersecurity threat environment, regular, ongoing controls testing
that verifies over time the effectiveness of each system safeguards
control used by a DCM, SEF, or SDR is essential to ensuring the
continuing overall efficacy of the entity's system safeguards. The
Commission disagrees with the suggestion that the final rule should not
require any controls testing. As noted in the NPRM, generally accepted
standards and best practices call for such testing.\97\ Moreover, in
conducting oversight of system safeguards, Commission staff have found
a significant number of instances, at both larger and smaller entities,
where (a) system malfunctions, market halts, and the success of cyber
intrusions were caused by failures of both key and non-key controls;
(b) such problems could have been prevented had the controls in
question been tested; and (c) testing of the relevant controls had been
entirely omitted or not done for substantial periods of time. The
controls testing requirement set out in the NPRM is designed to remedy
such situations, and ensure that controls testing by all DCMs, SEFs,
and SDRs follows best practices. By design, the NPRM did not prescribe
the design of the overall program of controls testing or the particular
tests it may include. Various forms of testing, including vulnerability
testing, penetration testing, SSAE16 SOC1 or SOC2 assessments, and
others, may well contribute in varying degrees--subject to their
particular natures and limitations--to an overall program for the
testing of controls as called for by the NPRM. The Commission notes
that the depth and coverage of a single assessment may not be
sufficient to meet the final rule's testing scope requirements
discussed below. It also notes that the proposed controls testing
requirement gives DCMs, SEFs, and SDRs the flexibility to determine the
appropriate combination of testing methods and techniques necessary to
determine whether their controls are implemented correctly, operating
as intended, and enabling them to meet the system safeguards
requirements of the Commission's rules.
---------------------------------------------------------------------------
\97\ 80 FR 80139, 80152 (Dec. 23, 2015).
---------------------------------------------------------------------------
(2) Controls Testing Frequency
The Commission has noted the best practices cited by CME supporting
controls testing on a three-year cycle. After due consideration, the
Commission agrees that a three-year rather than two-year minimum
controls testing frequency requirement for covered DCMs and SDRs may
reduce costs and burdens, while providing beneficial flexibility in
overall controls testing program design and still ensuring that the
fundamental purposes of the CEA and the Commission's system safeguards
rules are achieved. The NPRM called for covered DCMs and SDRs, as well
as non-covered DCMs and SEFs, to conduct controls testing as frequently
as appropriate risk analysis requires.\98\ The Commission notes that
this fundamental frequency requirement could well require a controls
testing cycle shorter than three years, as acknowledged in the comment
on this point. In light of these considerations, the final rule
requires all DCMs, SEFs, and SDRs to test the controls included in
their programs of risk analysis and oversight as frequently as
appropriate risk analysis requires. At a minimum, it will require
covered DCMs and SDRs to conduct the required key controls testing--
including key controls testing by independent contractors as discussed
below--no less frequently than every three years. As proposed in the
NPRM, it will permit covered DCMs and SDRS to conduct such testing on a
rolling basis, but require this to be done over the course of the
minimum period or the period determined by an appropriate risk
analysis, whichever is shorter.
---------------------------------------------------------------------------
\98\ 80 FR 80139, 80154 (Dec. 23, 2015).
---------------------------------------------------------------------------
(3) Who Should Perform Controls Testing
The Commission agrees with the comments noting that testing of key
controls by both independent contractors and employees not responsible
for development or operation of the controls tested can be valuable and
effective. As noted in the NPRM, best practices recognize the value of,
and recommend, both such approaches.\99\ The Commission notes that the
NPRM did not propose barring covered DCM or SDR employees from testing
key controls; rather, it proposed that covered DCM and SDR testing of
key controls include independent contractor testing of all such
controls within the minimum period. As with penetration testing, the
Commission believes that independent contractor testing of key controls
will strengthen covered DCM and SDR programs of risk analysis and
oversight, by providing a valuable outsider perspective concerning
crucial safeguards uncolored by insider assumptions or blind spots. The
Commission further believes that independent contractor testing of key
controls will strengthen Commission oversight of system safeguards, by
providing an important, credible third source of information concerning
crucial safeguards in addition to what is available from covered DCM or
SDR staff and from the internal audit function of those entities. As
noted above, because best practices call for controls testing, the
Commission disagrees with the comment suggesting that the final rule
should not require testing of key controls by either independent
contractors or employees. The NPRM did not require independent
contractor testing of all controls, but rather required independent
contractor testing of the key controls of covered DCMs and SDRs.\100\
---------------------------------------------------------------------------
\99\ Id. at 80154, 80155.
\100\ Id.
---------------------------------------------------------------------------
6. Security Incident Response Plan Testing--Sec. Sec. 37.1401(h)(6),
38.1051(h)(6), and 49.24(j)(6)
a. Proposed Rule
The NPRM called for each DCM, SEF, and SDR to conduct security
incident response plan (``SIRP'') testing of a scope sufficient to
satisfy the scope requirements in the proposed rule.\101\ It called for
each such entity's SIRP to include, without limitation, the entity's
definition and classification of security events, its policies and
procedures for reporting and communicating internally and externally
concerning security incidents, and the hand-off and escalation points
in its security incident response process.\102\ It proposed permitting
each such entity to coordinate its SIRP testing with its BC-DR plan or
other testing required by the applicable system safeguards rules.\103\
The NPRM proposed requiring all DCMs, SEFs, and SDRs to conduct SIRP
testing at a frequency determined by an appropriate risk analysis, with
a minimum frequency requirement of annual SIRP testing for covered DCMs
and SDRs.\104\ Finally, the NPRM called for all DCMs, SEFs, and SDRs to
have SIRP testing conducted by either independent contractors or
employees not responsible for development or operation of the systems
or capabilities tested.\105\
---------------------------------------------------------------------------
\101\ Id. at 80155 through 80157.
\102\ Id.
\103\ Id. at 80157.
\104\ Id.
\105\ Id.
---------------------------------------------------------------------------
[[Page 64287]]
b. Comments Received
(1) Requirement To Maintain and Test a SIRP
Several commenters agreed with the NPRM's call for each DCM, SEF,
and SDR to maintain and test a SIRP meeting the requirements in the
proposal. CME called SIRPs an important tool for all entities in their
efforts to be ready to face inevitable cyber attacks. CME noted its
appreciation for the proposal's flexibility for entities to design
their SIRP testing in light of their risk analysis, and for the
proposal's approval of coordination of SIRP testing with other types of
testing. ICE and Nadex also stated support for the NPRM's SIRP testing
provision. However, while Tradeweb stated that having a SIRP is
essential to the functioning of a SEF, it argued that the SIRP testing
requirement should be reduced to annual review and approval of the SIRP
by a SEF employee responsible for information security.
(2) SIRP Testing Frequency
No commenters expressed disagreement with the proposed requirement
for all DCMs, SEFs, and SDRs to conduct SIRP testing as often as
indicated by appropriate risk analysis. Regarding the proposed
requirement for covered DCMs and SDRs to test their SIRPs once a year
at a minimum, CME commented that at least annual SIRP testing is
appropriate in today's cybersecurity environment.
(3) Who Should Conduct SIRP Testing
No commenters expressed disagreement with the proposed general
requirement giving DCMs, SEFs, and SDRs the choice of whether to have
SIRP testing conducted by independent contractors or employees.
However, CME suggested that the final rule should permit SIRP testing
to be led by an independent employee who is not responsible for
development or operation of what is tested but who is responsible for
design of the SIRP itself. CME stated that this would allow the entity
to leverage its employees with expertise in crisis and risk management
and in incident response and planning, for both planning and testing
purposes, in a way that is optimal for the entity's system safeguards.
c. Final Rule
The Commission has considered and evaluated the comments concerning
SIRP testing. For the reasons discussed below, the Commission is
adopting the proposed requirements for each DCM, SEF, and SDR to
maintain a SIRP (as defined and described) and test it as often as
indicated by appropriate risk analysis, and the proposed requirement
for each covered DCM and SDR to conduct SIRP testing at least annually.
It is modifying the proposed provisions regarding who may conduct SIRP
testing, to permit testing to be led or conducted either by independent
contractors or by any entity employee.
(1) Requirement To Maintain and Test a SIRP
The Commission agrees with commenters that maintaining and testing
a SIRP is important for effective system safeguards in today's
cybersecurity environment. The Commission confirms that the proposed
SIRP testing requirement is indeed intended to give DCMs, SEFs, and
SDRs flexibility concerning the format and design of their SIRP
testing, and concerning its coordination with other types of testing,
so long as the entity's SIRP testing is consonant with appropriate risk
analysis and enables fulfillment of the proposed scope requirements.
The Commission disagrees with the suggestion that the requirement to
test the SIRP should be reduced to mere annual review and approval of
the SIRP by an employee responsible for information security. As noted
in the NPRM, best practices emphasize that SIRP testing is crucial to
effective cyber incident response in today's cybersecurity
environment.\106\ Failure to practice the cyber incident response
process can delay or paralyze timely response and cause severe
consequences.
---------------------------------------------------------------------------
\106\ 80 FR 80139, 80155 through 80156 (Dec. 23, 2015).
---------------------------------------------------------------------------
(2) SIRP Testing Frequency
The Commission notes that no commenters disagreed with the
requirement to conduct SIRP testing as often as indicated by
appropriate risk analysis, and agrees with the comment that at least
annual SIRP testing is appropriate for covered DCMs and SDRs in today's
cybersecurity environment.
(3) Who Should Conduct SIRP Testing
The Commission has considered the suggestion that allowing SIRP
testing to be led by an employee responsible for design of the SIRP
itself could improve system safeguards in general and SIRP testing in
particular. The Commission believes that this could provide useful
benefits and flexibility to DCMs, SEFs, and SDRs, without impairing the
purposes of the CEA and the Commission's regulations which SIRP testing
is designed to advance. In addition, SIRP testing differs from the
other types of testing specified in the final rule, in that what is
tested is not automated systems but the security incident response plan
itself, or in other words what people do if a security incident
happens. Accordingly, the final rule calls for SIRP testing by all
DCMs, SEFs, and SDRs to be conducted by either independent contractors
or employees, without restricting which employees may lead or conduct
the testing.
7. Enterprise Technology Risk Assessment--Sec. Sec. 37.1401(h)(7),
38.1051(h)(7), and 49.24(j)(7)
a. Proposed Rule
The NPRM called for each DCM, SEF, and SDR to conduct enterprise
technology risk assessment (``ETRA'') of a scope sufficient to satisfy
the scope requirements in the proposed rule.\107\ It called for each
DCM, SEF, and SDR to conduct an ETRA as often as required by
appropriate risk analysis, and for covered DCMs and SDRs to do this at
least annually.\108\ It stated that all regulatees could conduct ETRAs
by using independent contractors or employees not responsible for
development or operation of the systems or capabilities being
assessed.\109\
---------------------------------------------------------------------------
\107\ Id. at 80157 through 80159.
\108\ Id. at 80158.
\109\ Id. at 80158, 80159.
---------------------------------------------------------------------------
b. Comments Received
(1) ETRA Requirement
CME agreed that regular risk assessments should drive ongoing
efforts to address cyber risks. Nadex stated its general agreement with
the proposed ETRA requirement. ICE argued that the ETRA requirement is
already adequately addressed by current Commission rules, and called
for omission of the ETRA requirement in the final rule. ICE also argued
that the proposed ETRA requirement is not cyber-specific and does not
focus on the confidentiality, availability, or integrity of data.
Tradeweb agreed that assessment of technology risks is essential, but
argued that the ETRA requirement is duplicative of the other proposed
testing requirements.
(2) ETRA Frequency and Scope
CME suggested that ETRAs would benefit from incorporating the
results of controls testing and other testing, and suggested that it
would be beneficial and less costly to align the requirement for
completing an ETRA with the applicable frequency requirement for
controls testing. Nadex requested clarification of whether the ETRA
could incorporate the results of other required
[[Page 64288]]
testing as reported to management and the board of directors, or
whether a full stand-alone assessment is required. Tradeweb suggested
that an annual full assessment would be burdensome and costly, and
suggested that, in lieu of repeated full assessments, annual review and
approval of previous assessments should be sufficient.
(3) Who Should Conduct ETRAs
No commenters expressed disagreement with the NPRM provision
calling for ETRAs to be conducted by either independent contractors or
employees not responsible for development or operation of the systems
or capabilities assessed. ICE suggested that ETRAs should be carried
out by enterprise risk program staff rather than information security
staff.
c. Final Rule
The Commission has considered and evaluated the comments concerning
ETRAs. For the reasons discussed below, the Commission is adopting the
proposed requirements, but is adding a provision in the final rule
stating that a DCM, SEF, or SDR that has conducted an enterprise
technology risk assessment as required may conduct subsequent
assessments by updating the previous assessment.
(1) ETRA Requirement
The Commission agrees with the comment that regular risk
assessments should drive ongoing efforts to address cyber risks. The
Commission continues to believe that conducting regular ETRAs is
essential to meeting the testing requirements of its current system
safeguards rules and maintaining system safeguards resiliency in
today's cybersecurity environment. Regular, ongoing identification,
estimation, and prioritization of risks that could result from
impairment of the confidentiality, integrity, or availability of data
and information or the reliability, security, and capacity of automated
systems is crucial to effective system safeguards. As noted in the
NPRM, regular performance of ETRAs is a well-established best
practice.\110\ The proposed ETRA requirement is designed to provide an
overarching vehicle through which a DCM, SEF, or SDR draws together and
uses the results and lessons learned from each of the types of
cybersecurity and system safeguards testing addressed in the proposed
rule, in addition to other methods of risk identification, in order to
identify and mitigate its system safeguards-related risks. ETRAs can
also inform the design of the other types of testing. As such, the ETRA
requirement it is not duplicative of the other testing requirements,
but rather an enhancement of their value. The Commission also notes
that, as discussed above, multiple NPRM provisions to be adopted in the
final rule call for determinations made in light of the appropriate
risk analysis that is required by the CEA. Accordingly, a regulatee's
current ETRA summarizing in writing both its analysis of its system
safeguards risks and the basis for that analysis and for the entity's
system safeguards decisions will be a key tool for Commission
determination of the adequacy of the entity's compliance with system
safeguards requirements. The Commission therefore disagrees with the
suggestion that the final rule should omit the ETRA requirement.
---------------------------------------------------------------------------
\110\ Id. at 80158.
---------------------------------------------------------------------------
(2) ETRA Frequency and Scope
While the Commission agrees that the results of other types of
testing can usefully inform ETRAs, the Commission believes that, as
best practices provide, regularly updated ETRAs are crucial to the
effectiveness of system safeguards in today's rapidly changing
cybersecurity environment. The Commission therefore does not accept the
suggestion that ETRAs should only be required as often as a complete
cycle of controls testing is completed, not least because the final
rule is adopting the suggestion to lengthen that cycle to three rather
than two years. The Commission reiterates that the results of other
required forms of system safeguards testing can and should be
incorporated in ETRAs, and in turn should be informed and driven by
ETRAs. Because ETRAs that provide current assessment of current risks
are essential to effective programs of system safeguards risk analysis
and oversight, as discussed above, the Commission disagrees with the
suggestion that annual review and reapproval of previous assessments
would be sufficient. However, the Commission believes that thorough
updating of a previous assessment conducted in compliance with the ETRA
requirements set out in the NPRM can be sufficient to fulfill the
purposes of an appropriate ETRA, and can reduce costs and burdens
without impairment of the purposes of the CEA and the system safeguards
rules. Accordingly the final rule clarifies that such updating of a
previous fully compliant ETRA, in light of current risks and
circumstances, can fulfill the ETRA requirement. The Commission
emphasizes that best practices require all DCMs, SEFs, and SDRs to
conduct risk assessment and monitoring on an ongoing basis, as
frequently as the entity's risks and circumstances require. The final
rule requirement for covered DCMs and SDRs to prepare a written
assessment on at least an annual basis does not eliminate the need for
a covered DCM or SDR to conduct risk assessment and monitoring on an
ongoing basis, as best practices require. Rather, the minimum frequency
requirement is intended to formalize the risk assessment process and
ensure that it is documented at a minimum frequency.
(3) Who Should Conduct ETRAs
The NPRM's call for ETRAs to be conducted by either independent
contractors or employees not responsible for development or operation
of the systems or capabilities assessed drew no objections from
commenters. The Commission also notes that the NPRM did not prescribe
whether enterprise risk program staff, information security staff, or
both should conduct ETRAs, but deliberately left flexibility to DCMs,
SEFs, and SDRs in this regard, so long as the employees conducting the
ETRA have the independence specified.
F. Scope of Testing and Assessment--Sec. Sec. 37.1401(k), 38.1051(k),
and 49.24(l)
1. Proposed Rule
The NPRM called for the scope of all system safeguards testing and
assessment to be broad enough to include all testing of automated
systems and controls necessary to identify any vulnerability which, if
triggered, could enable an intruder or unauthorized user to take any of
a number of undesirable actions.\111\ These actions were specified to
include interfering with the regulatee's operations or fulfillment of
its statutory and regulatory responsibilities; impairing or degrading
the reliability, security, or capacity of the regulatee's automated
systems; adding to, deleting, modifying, exfiltrating, or compromising
the integrity of data; or taking any other unauthorized action
affecting the regulatee's regulated activities or the hardware or
software used in connection with them.\112\
---------------------------------------------------------------------------
\111\ 80 FR 80139, 80159 (Dec. 23, 2015).
\112\ Id.
---------------------------------------------------------------------------
2. Comments Received
A number of commenters suggested that the scope provisions of the
NPRM were overbroad, and that the proposed requirement to perform
``all'' testing necessary to identify ``any'' vulnerability was
impossible to achieve in practice. CME argued that it is infeasible to
conduct testing to identify
[[Page 64289]]
``any'' potential vulnerability, and called for the final rule to
provide that testing scope should be risk-based, to enable focus on the
most likely scenarios and highest value information assets. CME
suggested that the NPRM's overbroad scope provision could impose
outsized costs without yielding commensurate benefits. ICE stated that
it is impossible to predict and test for all cyber attack scenarios.
Nadex agreed with the general thrust of the proposed scope provision,
but argued that the requirement to identify ``any'' vulnerability was
too broad, and that it is unrealistic and likely impossible to
guarantee testing that could provide 100 percent security against all
vulnerabilities or unauthorized actions. WMBAA stated concern that the
proposed scope provision would set a standard impracticable for
regulatees to achieve, because no regulatee could guarantee that
``any'' vulnerability would be uncovered by testing, and because it is
impracticable to test all potential avenues for penetrating regulatee
systems. WMBAA questioned whether any penetration testing firm would be
willing to certify that its testing procedures met such a standard.
Nadex, CFE, Tradeweb, and WMBAA suggested that the NPRM scope provision
could be read as imposing a strict liability standard under which any
successful cyber attack would mean a violation of the testing scope
provisions must have occurred. CME, Nadex, CFE, DDR, Tradeweb, and
WMBAA requested that the Commission consider establishing ``safe
harbor'' provisions under which an entity that has made good faith
efforts to adhere to one or more designated cybersecurity frameworks or
statements of cybersecurity best practices would be deemed to be in
compliance with the system safeguards rules. Nadex called for the final
rule scope provision to limit responsibility to a reasonableness
standard. Nadex also asked the Commission to clarify that the current
cybersecurity threat analysis a regulatee should consider in assessing
potential cyber adversary capabilities to determine testing scope is
limited to the organization's internal risk assessments.
3. Final Rule
The Commission has considered and evaluated the comments concerning
the testing scope provision of the NPRM.\113\ For the reasons discussed
below, the Commission is modifying the scope provision in the final
rule to call for the scope of testing to be based on appropriate risk
and threat analysis.
---------------------------------------------------------------------------
\113\ 80 FR 80139, 80159 (Dec. 23, 2015).
---------------------------------------------------------------------------
The Commission does not intend the scope provision of the testing
rule to create any sort of strict liability standard with respect to
system safeguards testing. On the contrary, the Commission recognizes
that in today's cybersecurity environment no entity can be expected to
be immune from cyber intrusions. As noted in the NPRM, one fundamental
goal of the Commission's system safeguards and cybersecurity testing
rules is enhancing regulatees' ability to detect, contain, respond to,
and recover from cyber intrusion when they happen.\114\ In conducting
oversight of the system safeguards of DCMs, SEFs, and SDRs, the
Commission looks and will continue to look to what a reasonable and
prudent DCM, SEF, or SDR would do with respect to system safeguards in
light of generally accepted standards and best practices, and in light
of informed risk analysis appropriate to the circumstances and risks
faced by the DCM, SEF or SDR in question. The Commission does not
believe that the mere fact that a DCM, SEF, or SDR has suffered a cyber
intrusion means that that entity has failed to comply with system
safeguards rules. The Commission would be concerned when examination
shows that a DCM, SEF, or SDR failed to follow the best practices that
a reasonable entity in its circumstances and facing its risks should
follow.
---------------------------------------------------------------------------
\114\ Id. at 80156.
---------------------------------------------------------------------------
The Commission also recognizes that no program of cybersecurity
testing can be expected to detect every possible vulnerability or
avenue of intrusion. Here, too, the touchstone is what system
safeguards testing a reasonable and prudent DCM, SEF, or SDR would
conduct in light of generally accepted standards and best practices,
and in light of informed risk analysis appropriate to the circumstances
and risks faced by the DCM, SEF or SDR in question. The Commission
evaluates, and will continue to evaluate, system safeguards testing in
that light.
Given today's rapidly changing cyber threat environment and the
resulting continuous evolution of generally accepted standards and best
practices with respect to system safeguards, the Commission does not
believe it would be appropriate to label compliance with any one source
of best practices as written at a particular point in time as a ``safe
harbor'' with respect to system safeguards compliance. The Commission
believes that the appropriate way to address the concerns underlying
the comments seeking designation of such safe harbors is the standard
discussed above: Reasonable and prudent system safeguards testing in
light of generally accepted standards and best practices, and in light
of informed risk analysis appropriate to the circumstances and risks
faced by the DCM, SEF or SDR in question.
The Commission disagrees with the comment asking confirmation that
the current cybersecurity threat analysis a DCM, SEF, or SDR should
consider in designing its system safeguards testing is limited to the
organization's internal risk assessments. As noted in the NPRM, a DCM,
SEF, or SDR acting as a reasonable and prudent regulatee would act in
light of best practices and the current cybersecurity threat
environment should obtain and consider threat analysis available from
outside sources in addition to conducting its own threat analysis.
For those reasons, the Commission agrees with the comments
suggesting that the scope provisions of the final rule should call for
testing scope to be based on appropriate risk and threat analysis. In
order to provide the clarity requested by commenters, the final rule
calls for the scope of system safeguards testing to include the testing
that the regulatee's program of risk analysis and oversight and its
current cybersecurity threat analysis indicate is necessary to identify
risks and vulnerabilities that could enable the deleterious actions by
intruders or unauthorized users listed in the scope provisions of the
proposed rules. The Commission agrees with the comments suggesting that
this approach will avoid imposing undue burdens and costs, while
supporting the purposes of the CEA and the Commission's system
safeguards rule.
G. Internal Reporting and Review--Sec. Sec. 37.1401(l), 38.1051(l),
and 49.24(m)
1. Proposed Rule
The NPRM called for DCM, SEF, and SDR senior management and boards
of directors to receive and review reports setting forth the results of
the testing and assessment required by the system safeguards
rules.\115\ It also called for these entities to establish and follow
procedures for remediation of issues identified through such review,
and for evaluation of the effectiveness of testing and assessment
protocols.\116\
---------------------------------------------------------------------------
\115\ 80 FR 80139, 80160 (Dec. 23, 2015).
\116\ Id.
---------------------------------------------------------------------------
[[Page 64290]]
2. Comments Received
a. Board and Senior Management Oversight
Several commenters agreed with the NPRM's call for oversight of
system safeguards and cybersecurity by boards of directors and senior
management. CME and MGEX recognized the importance of effective board
oversight and the need to keep the board and senior management up to
date in this regard. DDR said it agreed with the Commission that active
board and senior management supervision of system safeguards promotes
more efficient, effective, and reliable risk management. However, ICE
argued that internal reporting and review of test results should be
limited to reports to senior management, and that boards of directors
should not be required to review even high-level, high-priority test
findings, but instead should only be apprised of enterprise-level high
risk issues when identified thresholds (unspecified by ICE) are
crossed.
b. Level of Detail for Board and Senior Management Review
Commenters requested clarification concerning what level of detail
the NPRM called for boards and senior management to review in terms of
test results. ICE, MGEX, and Nadex noted that test result reports can
be voluminous, technical, and complex, and that requiring boards and
senior management to review each such document could produce an undue
burden without commensurate benefits. MGEX and Nadex therefore asked
the Commission to clarify in the final rule that what is required is
board and management review of appropriate summaries and compilations
of test and assessment results. DDR suggested it should be the
regulatee's responsibility to provide the board and senior management
with the level of test result information appropriate for enabling
their effective oversight of system safeguards. DDR asked the
Commission to confirm in the final rule that there are multiple ways
this can be done. Nadex also asked the Commission to clarify that board
consideration of test results in the course of regularly scheduled
meetings would be an acceptable way of fulfilling this requirement.
3. Final Rule
The Commission has considered and evaluated the comments concerning
the internal reporting and review provision of the NPRM.\117\ For the
reasons discussed below, the Commission is adopting the provision as
proposed.
---------------------------------------------------------------------------
\117\ 80 FR 80139, 80160 (Dec. 23, 2015).
---------------------------------------------------------------------------
a. Board and Senior Management Oversight
The Commission agrees with the comments recognizing the importance
of effective board of directors and senior management of system
safeguards, and the resulting need to keep the board and senior
management informed appropriately concerning the results of
cybersecurity testing and assessment. In today's cybersecurity threat
environment, active board and senior management supervision of system
safeguards is essential to the enterprise-wide, effective risk
management that the CEA and Commission regulations require of DCMs,
SEFs, and SDRs. Such active supervision would be impossible if board
members and senior managers were not appropriately apprised of the
results of cybersecurity testing and assessment, and thus lacked an
essential level of knowledge of the organization's system safeguards
risks. As noted in the NPRM, generally accepted standards and best
practices emphasize the importance of board and senior management
oversight of cybersecurity, and make it clear that the absence of
proactive board and senior management involvement in cybersecurity can
make regulatees more vulnerable to successful cyber attacks.\118\
Accordingly, best practices call for directors to either have the
appropriate level of experience and knowledge of information technology
and related risks themselves or obtain the assistance of expert
consultants in this regard. In the Commission's view, protection of the
public interest and the economic security of the United States with
respect to derivatives markets in today's cybersecurity threat
environment demands no less. For these reasons, the Commission
disagrees with the suggestion that boards of directors should not be
involved in internal reporting and review of cybersecurity test
results.
---------------------------------------------------------------------------
\118\ 80 FR 80139, 80160 (Dec. 23, 2015).
---------------------------------------------------------------------------
b. Level of Detail for Board and Senior Management Review
The Commission also agrees with the comments suggesting that test
result reports can be voluminous, technical, and complex, and that
effective board of directors and senior management oversight of system
safeguards does not require board or senior management review of every
detail of each such report. The Commission further agrees with the
comments suggesting that DCMs, SEFs, and SDRs should provide their
boards and senior management with a level of test result information
that enables their effective, knowledgeable oversight of cybersecurity
and system safeguards in light of the risks faced by their
organizations. While the internal reporting and review provision of the
final rule requires that the board receive and review test results, it
does not prevent an organization from including additional, clarifying
documents, such as executive summaries or compilations, with the
required reports. Board and senior management review of appropriate
summaries and compilations of test and assessment results can be an
effective and acceptable way of fulfilling the internal reporting and
review requirement, provided that such summaries give board members and
senior management sufficiently detailed information to enable them to
conduct effective and informed oversight. The appropriate level of
information should also enable boards and senior management to fulfill
this provision's requirement for them to evaluate the overall
effectiveness of testing and assessment protocols, and direct and
oversee appropriate remediation of issues identified through their
review of test results. As noted in the NPRM, best practices call for
boards and senior management to review the overall effectiveness of the
testing program.\119\
---------------------------------------------------------------------------
\119\ 80 FR 80139, 80160 (Dec. 23, 2015).
---------------------------------------------------------------------------
H. Remediation--Sec. Sec. 37.1401(m), 38.1051(m), and 49.24(n)
1. Proposed Rule
The NPRM called for each DCM, SEF, and SDR to analyze the results
of the testing and assessment required by the system safeguards rules
in order to identify all vulnerabilities and deficiencies in its
systems.\120\ It proposed requiring each such entity to remediate those
vulnerabilities and deficiencies to the extent necessary to enable the
entity to meet the requirements of the system safeguards rules and of
its statutory and regulatory responsibilities.\121\ It called for such
remediation to be timely in light of appropriate risk analysis with
respect to the risks presented.
---------------------------------------------------------------------------
\120\ 80 FR 80139, 80160 (Dec. 23, 2015).
\121\ Id.
---------------------------------------------------------------------------
2. Comments Received
Nadex and Tradeweb suggested that the proposed requirement to
identify and remediate ``all'' vulnerabilities and deficiencies in a
regulatee's systems was impossible to achieve in practice. Nadex
observed that other discussion in the NPRM indicated Commission intent
to
[[Page 64291]]
require remediation of vulnerabilities and deficiencies identified in
the testing results, and suggested amending the final rule to make this
clear. Noting that remediation after a cyber attack often takes time,
Tradeweb argued that regulatees should not be penalized for that fact,
and requested Commission guidance on what constitutes timely
remediation, perhaps including specification that remediation over nine
to twelve months would be timely.
3. Final Rule
The Commission has considered and evaluated the comments concerning
the remediation provision of the NPRM. For the reasons discussed below,
the Commission is modifying the remediation provision in the final rule
require DCMs, SEFs, and SDRs to: (1) Identify and document the
vulnerabilities and deficiencies revealed by the testing called for in
the system safeguards rules; and (2) conduct and document an
appropriate analysis of the risks presented, in order to determine and
document whether to remediate or accept each such risk. The Commission
is adopting the requirement for the entity to remediate such risks in a
timely manner in light of appropriate risk analysis as proposed.
The Commission agrees with commenters that a requirement calling
for a DCM, SEF, or SDR to remediate all vulnerabilities and
deficiencies could be read as overbroad and impossible in practice. As
suggested in a comment, the intent of the NPRM remediation provision
was in fact to require remediation of the vulnerabilities and
deficiencies disclosed through the regulatee's program of risk analysis
and oversight, which includes testing of appropriate scope. In response
to the comments received, the Commission is narrowing the remediation
requirement to address remediation or acceptance of the vulnerabilities
and deficiencies of which the entity is aware or through an appropriate
program of risk analysis and oversight should be aware, rather than the
remediation of all vulnerabilities and deficiencies. This revision is
being made to reduce burdens and costs to the extent possible without
impairing the purposes of the CEA and the Commission's system
safeguards regulations. Best practices call for organizations to
conduct appropriate risk analysis with respect to vulnerabilities and
deficiencies disclosed by testing, in order to determine whether to
remediate or accept the risks presented.\122\ Documentation of such
analysis and decisions is needed for both an effective program of risk
analysis and effective Commission oversight of system safeguards. The
NPRM proposal to require identification of vulnerabilities was intended
to include their documentation. Effective remediation would be
impossible without documentation of both the vulnerabilities in
question and the remediation steps needed. Accordingly, the Commission
believes regulatees would create such documentation in the normal
course of business. However, because documentation was not explicitly
required in the proposal, the Commission is treating the final rule
documentation requirement as a possible, slight additional burden. The
Commission notes, however, that in the context of the burden reduction
resulting from requiring regulatees to identify and remediate the
vulnerabilities of which they are or should be aware, rather than to
identify ``all'' vulnerabilities as proposed in the NPRM, the overall
effect of the final rule remediation provision represents a
considerable reduction in burden and cost over what was proposed.
---------------------------------------------------------------------------
\122\ For clarity, the Commission notes that it sees the term
``remediation'' as including mitigation and avoidance of risks as
discussed in some sources of best practices. See, e.g., NIST SP 800-
39, at 41-43.
---------------------------------------------------------------------------
The Commission is aware that appropriate and effective remediation
following a cyber attack often must proceed over a reasonable period of
time, determined by the nature of the intrusion and the mitigation
steps needed, and it takes this fact into account in determining
whether remediation is timely. The Commission does not believe it is
practicable to codify specific periods of time as constituting timely
remediation, since what is timely and appropriate depends on the
particular circumstances and risks involved in a given situation.
III. Related Matters
A. Regulatory Flexibility Act
The Regulatory Flexibility Act (``RFA'') requires federal agencies,
in promulgating rules, to consider the impact of those rules on small
entities.\123\ The rules adopted herein will affect DCMs, SEFs, and
SDRs. The Commission has previously established certain definitions of
``small entities'' to be used by the Commission in evaluating the
impact of its rules on small entities in accordance with the RFA.\124\
The Commission previously determined that DCMs, SEFs, and SDRs are not
small entities for the purpose of the RFA.\125\ The Commission received
no comments on the impact of the rules contained herein on small
entities. Therefore, the Chairman, on behalf of the Commission and
pursuant to 5 U.S.C. 605(b), certifies that the final rules will not
have a significant economic impact on a substantial number of small
entities.
---------------------------------------------------------------------------
\123\ 5 U.S.C. 601 et seq.
\124\ See 47 FR 18618 through 18621 (Apr. 30, 1982).
\125\ See 47 FR 18618, 18619 (Apr. 30, 1982) discussing DCMs; 78
FR 33548 (June 4, 2013) discussing SEFs; 76 FR 54575 (Sept. 1, 2011)
discussing SDRs.
---------------------------------------------------------------------------
B. Paperwork Reduction Act
1. Introduction
The Paperwork Reduction Act of 1995 (``PRA'') \126\ imposes certain
requirements on Federal agencies, including the Commission, in
connection with their conducting or sponsoring any collection of
information, as defined by the PRA. The final rules contain
recordkeeping and reporting requirements that are collections of
information within the meaning of the PRA. In accordance with the
requirements of the PRA, the Commission may not conduct or sponsor, and
a person is not required to respond to, a collection of information
unless it displays a currently valid OMB control number.
---------------------------------------------------------------------------
\126\ 44 U.S.C. 3501 et seq.
---------------------------------------------------------------------------
As discussed below, the final rules contain provisions that qualify
as collections of information, for which the Commission has already
sought and obtained control numbers from OMB. The titles for these
collections of information are ``Part 38--Designated Contract Markets''
(OMB Control Number 3038-0052), ``Part 37--Swap Execution Facilities''
(OMB Control Number 3038-0074), and ``Part 49--Swap Data Repositories;
Registration and Regulatory Requirements'' (OMB Control Number 3038-
0086). With the exception of Sec. 38.1051(n) that requires all DCMs to
submit annual trading volume information to the Commission, the final
rules will not impose any new recordkeeping or reporting requirements
that are not already accounted for in existing collections 3038-
0052,\127\ 3038-0074,\128\ and 3038-0086.\129\
---------------------------------------------------------------------------
\127\ See OMB Control No. 3038-0052, available at http://www.reginfo.gov/public/do/PRAOMBHistory?ombControlNumber=3038-0052.
\128\ See OMB Control No. 3038-0074, available at http://www.reginfo.gov/public/do/PRAOMBHistory?ombControlNumber=3038-0074.
\129\ See OMB Control No. 3038-0086, available at http://www.reginfo.gov/public/do/PRAOMBHistory?ombControlNumber=3038-0086.
---------------------------------------------------------------------------
2. Clarifications of Collections 3038-0052, 3038-0074, and 3038-0086
As stated in the NPRM, all DCMs, SEFs, and SDRs are already subject
to
[[Page 64292]]
system safeguard-related books and records obligations.\130\ The final
rules amend Sec. Sec. 38.1051(g), 37.1041(g), and 49.24(i) to clarify
the system safeguard-related books and records obligations for all
DCMs, SEFs, and SDRs. The Commission is adopting these provisions as
proposed. Specifically, Sec. Sec. 38.1051(g), 37.1041(g), and 49.24(i)
require all DCMs, SEFs, and SDRs to provide the Commission with the
following system safeguards-related books and records promptly upon
request of any Commission representative: (1) Current copies of the BC-
DR plans and other emergency procedures; (2) all assessments of the
entity's operational risks or system safeguard-related controls; (3)
all reports concerning system safeguards testing and assessment
required by this chapter, whether performed by independent contractors
or employees of the DCM, SEF, or SDR; and (4) all other books and
records requested by Commission staff in connection with Commission
oversight of system safeguards pursuant to the Act or Commission
regulations, or in connection with Commission maintenance of a current
profile of the entity's automated systems. The NPRM invited public
comment on the accuracy of its estimate that no additional
recordkeeping or information collection requirements or changes to the
existing collection requirements would result from the proposed
clarifying amendments.\131\ The Commission did not receive any comments
that addressed whether additional recordkeeping or information
collection requirements or changes to existing collection requirements
would result from the adoption of the proposed rules.\132\ In light of
the above, the Commission believes that Sec. Sec. 38.1051(g),
37.1041(g), and 49.24(i) do not impact the burden estimates currently
provided for in OMB Control Numbers 3038-0052, 3038-0074, and 3038-
0086.
---------------------------------------------------------------------------
\130\ 80 FR 80139, 80162 (Dec. 23, 2015).
\131\ Id.
\132\ As discussed in the preamble, the Commission received
comment letters from WMBAA, CME, and ICE concerning the books and
records obligations generally.
---------------------------------------------------------------------------
3. Revision to Collection 3038-0052
The final DCM rules will require a new information collection which
is covered by OMB Control No. 3038-0052. Commission regulation Sec.
38.1051(n) requires each DCM to provide to the Commission its annual
total trading volume for calendar year 2015 and each calendar year
thereafter. This information is required for 2015 within 30 calendar
days of the effective date of the final rules, and for 2016 and
subsequent years by January 31 of the following calendar year.
The Commission requested comment concerning the accuracy of its
estimate concerning the proposed reporting requirements in Sec.
38.1051(n).\133\ Although the Commission did not receive any comment
concerning the accuracy of its estimate, the Commission received a
comment from CME that the Commission should consider alternatives to
the reporting requirements in proposed Sec. 38.1051(n) because the
Commission currently receives daily trade reports regarding volume
pursuant to DCM Core Principle 8 and part 16 of the Commission's
regulations. The Commission notes that while it receives daily trade
information from DCMs pursuant to part 16, it does not receive total
annual trading volume from DCMs. Additionally, the Commission believes
that Core Principle 8 is inapplicable because it requires DCMs to
publish daily volume, but does not require submission of that
information to the Commission. The Commission's rules do not currently
require the submission of annual trading volume, which is essential for
the Commission to accurately evaluate whether a particular DCM must
comply with the enhanced system safeguard requirements. The Commission
believes that DCMs generally calculate their annual trading volume in
the usual course of business and any associated costs incurred by DCMs
to comply with this provision will be minimal.
---------------------------------------------------------------------------
\133\ 80 FR 80139, 80163 (Dec. 23, 2015).
---------------------------------------------------------------------------
Currently, there are 15 registered DCMs that will be required to
comply with the annual trading volume information. Consistent with its
estimate in the NPRM, the Commission estimates that the information
collection required associated with the final rule will impose an
average of 0.5 hours annually per respondent.\134\ The estimated annual
burden for 3038-0052 was calculated as follows:
---------------------------------------------------------------------------
\134\ Id.
---------------------------------------------------------------------------
Estimated number of respondents: 15.
Annual responses by each respondent: 1.
Total annual responses: 15.
Estimated average hours per response: 0.5.
Aggregate annual reporting burden: 7.5.
The final rule requiring the submission of annual trading volume
information to the Commission will result in an annual cost burden of
approximately $24.80 per respondent.\135\ The Commission based its
calculation on an hourly wage of $49.59 for a Compliance Officer.\136\
---------------------------------------------------------------------------
\135\ Id.
\136\ In arriving at a wage rate for the hourly costs imposed,
Commission staff used the National Industry-Specific Occupational
Employment and Wage Estimates, published in May (2015 Report). The
hourly rate for a Compliance Officer in the Securities and Commodity
Exchanges section as published in the 2015 Report was $49.59 per
hour. In the NPRM, the Commission's estimate of $22.015 per
respondent was based on the hourly wage of $44.03 for a Compliance
Officer in the 2014 Report. 80 FR 80139, 80163 (Dec. 23, 2015).
---------------------------------------------------------------------------
Accordingly, the Commission intends to amend existing collection
3038-0052 to account for the submission of annual trading volume
information to the Commission. The amendment will add an estimated
annual burden of 7.5 hours to the existing collection, which currently
includes an annual reporting burden of 8,670 hours. Therefore, the new
annual reporting burden for collection 3038-0052 will be 8,677.5 hours.
C. Consideration of Costs and Benefits
1. Introduction
Section 15(a) of the CEA requires the Commission to consider the
costs and benefits of its discretionary actions before promulgating a
regulation under the CEA or issuing certain orders.\137\ Section 15(a)
further specifies that the costs and benefits shall be evaluated in
light of five broad areas of market and public concern: (1) Protection
of market participants and the public; (2) efficiency, competitiveness,
and financial integrity of futures markets; (3) price discovery; (4)
sound risk management practices; and (5) other public interest
considerations. In adopting the final system safeguard rules for DCMs,
SEFs, and SDRs, the Commission has considered the costs and benefits
resulting from its discretionary determinations with respect to the
section 15(a) factors.
---------------------------------------------------------------------------
\137\ 7 U.S.C. 19(a).
---------------------------------------------------------------------------
To further the Commission's consideration of the costs and benefits
imposed by its regulations, the Commission invited comments from the
public on all aspects of the Consideration of Costs and Benefits
section of the NPRM. The Commission specifically invited responses to a
series of questions regarding costs and benefits, and specifically
invited commenters to provide data or other information quantifying
such costs and benefits. The Commission received one comment that
provided quantitative information pertaining to the costs associated
with certain proposed provisions.\138\ CME estimated that the
[[Page 64293]]
additional cost that it would incur over a two year period is over $7.2
million.\139\ A number of other commenters did not provide specific
cost estimates, but provided comments concerning the costs generally.
The Commission is addressing both types of comments in the discussion
that follows. As discussed more fully below, the Commission believes
that the changes to the final regulations will reduce the overall costs
of compliance as compared to the NPRM.
---------------------------------------------------------------------------
\138\ CME provided cost estimates for the proposed independent
contractor requirements, conducting ETRAs, and controls testing.
\139\ CME noted that its cost estimate also includes costs
associated with the Commission's parallel NPRM that addresses system
safeguards for DCOs. Additionally, CME noted that its estimate
``does not separate out the costs for clearing, trading, or data
reporting.''
---------------------------------------------------------------------------
As stated in the NRPM, Commission staff collected preliminary
information from some DCMs and SDRs regarding their current costs
associated with conducting vulnerability testing, external and internal
penetration testing, controls testing, and enterprise technology risk
assessments (``DMO Preliminary Survey'').\140\ Some of the cost
estimates provided by the DCMs and SDRs included estimates at the
parent company level of the DCM and SDR because the entities were
unable to apportion the actual costs to a particular entity within
their corporate structure.\141\ In some cases, apportioning costs could
be further complicated by sharing of system safeguards among DCMs,
SEFs, SDRs, or DCOs. Therefore, in the data collected for the DMO
Preliminary Survey, it was difficult in some cases to distinguish
between the system safeguard-related costs of DCMs, SEFs, SDRs, and
DCOs. This distinction was highlighted by CME in its comment letter by
noting that its cost estimates do not separate out costs for clearing,
trading, or data reporting. Given the lack of quantitative data
provided in the comments, the Commission is relying on the data
collected from the DMO Preliminary Survey concerning the costs for
conducting vulnerability testing, external and internal penetration
testing, controls testing, and enterprise technology risk
assessments.\142\
---------------------------------------------------------------------------
\140\ 80 FR 80139, 80165 (Dec. 23, 2015). The Commission notes
that the DCMs and SDRs that provided the information for the DMO
Preliminary Survey requested confidential treatment.
\141\ It is not uncommon for entities within the same corporate
structure to share automated systems and system safeguard programs.
\142\ The estimates from the DMO Preliminary Survey provided in
this section are presented as simple cost averages of the affected
entities', without regard to the type of entity. By definition,
averages are meant to serve only as a reference point; the
Commission understands that due to the nature of the requirements in
relation to the current practices at a covered DCM or an SDR, some
entities may go above the average while others may stay below.
---------------------------------------------------------------------------
2. Baseline for Final Rules
The Commission recognizes that any economic effects, including
costs and benefits, should be evaluated with reference to a baseline
that accounts for current regulatory requirements. As stated in the
NPRM, the baseline for this cost and benefit consideration is the set
of current requirements under the Act and the Commission's regulations
for DCMs, SEFs, and SDRs.\143\ The Act requires each DCM, SEF, and SDR
to develop and maintain a program of system safeguards-related risk
analysis and oversight to identify and minimize sources of operational
risk.\144\ Additionally, the Act mandates that each DCM, SEF, and SDR
must develop and maintain automated systems that are reliable, secure,
and have adequate scalable capacity, and must ensure system
reliability, security, and capacity through appropriate controls and
procedures.\145\ The Commission's current system safeguards rules for
DCMs, SEFs, and SDRs mandate that, in order to achieve these statutory
requirements, each DCM, SEF, and SDR must conduct testing and review
sufficient to ensure that its automated systems are reliable, secure,
and have adequate scalable capacity.\146\
---------------------------------------------------------------------------
\143\ 80 FR 80139, 80164 (Dec. 23, 2015).
\144\ CEA section 5(d)(20) (for DCMs); CEA section 5h(f)(14)
(for SEFs); CEA section 21(f)(4)(A) and 17 CFR 49.24(a) (for SDRs).
\145\ Id.
\146\ 17 CFR 38.1051(h) (for DCMs); 17 CFR 37.1401(g) (for
SEFs); 17 CFR 49.24(j) (for SDRs).
---------------------------------------------------------------------------
The final rules clarify the system safeguards and cybersecurity
testing requirements for DCMs, SEFs, and SDRs, by specifying and
defining five types of system safeguards testing that a DCM, SEF, or
SDR necessarily must perform to fulfill the testing requirement. For
the following reasons, the Commission believes that the final rules
calling for each DCM, SEF, and SDR to conduct each of these types of
testing and assessment will not impose any new costs on DCMs, SEFs, and
SDRs. Each of the types of testing and assessment required under the
final rules--vulnerability testing, penetration testing, controls
testing, security incident response plan testing, and enterprise
technology risk assessment--is a generally recognized best practice for
system safeguards. Moreover, the Commission believes that it is
essentially impossible for a DCM, SEF, or SDR to fulfill its current
obligation to conduct testing sufficient to ensure the reliability,
security, and capacity of its automated systems without conducting each
type of testing addressed by the final rules. This has been true since
before the testing requirements of the Act and the current regulations
were adopted, and it would be true today even if the Commission were
not adopting the final rules.\147\ If compliance with the clarified
testing requirements herein results in costs to DCMs, SEFs, and SDRs,
the Commission believes that those are costs associated with compliance
with current testing requirements and not the final rules.\148\
---------------------------------------------------------------------------
\147\ The Commission's current rules and guidance provide that a
DCM's, SEF's, or SDR's entire program of risk analysis and
oversight, which includes testing, should be based on generally
accepted standards and best practices with respect to the
development, operation, reliability, security, and capacity of
automated systems. See Appendix A to Part 37, Core Principle 14 of
Section 5h of the Act--System Safeguards (a) Guidance (1) Risk
analysis and oversight program (for SEFs); 17 CFR 38.1051(h) (for
DCMs); 17 CFR 49.24(j) (for SDRs). Each of the types of testing
addressed in the final rules--vulnerability testing, penetration
testing, controls testing, security incident response plan testing,
and enterprise technology risk assessment--has been a generally
recognized best practice for system safeguards since before the
testing requirements of the Act and the current regulations were
adopted. The current system safeguards provisions of the CEA and the
Commission's regulations became effective in August 2012. Generally
accepted best practices called for each type of testing specified in
the final rule well before that date, as shown in the following
examples. Regarding all five types of testing, see, e.g., NIST SP
800-53A, Rev. 1, Guide for Assessing the Security Controls in
Federal Information Systems and Organizations (``NIST 800-53A Rev.
1''), at E1, F67, F230, F148, and F226, June 2010, available at
http://csrc.nist.gov/publications/nistpubs/800-53A-rev1/sp800-53A-rev1-final.pdf. Regarding vulnerability testing, see, e.g., NIST SP
800-53A Rev. 1, at F67, June 2010, available at http://csrc.nist.gov/publications/nistpubs/800-53A-rev1/sp800-53A-rev1-final.pdf; and NIST SP 800-115, Technical Guide to Information
Security Testing and Assessment, at 5-2, September 2008, available
at http://csrc.nist.gov/publications/nistpubs/800-115/SP800-115.pdf.
Regarding penetration testing, see, e.g., NIST Special Publication
(``SP'') 800-53A, Rev. 1, at E1, June 2010, available at http://csc.nist.gov/publications/nistpubs/800-53A-rev1/sp800-53A-rev1-final.pdf; and NIST 800-115, at 4-4, September 2008, available at
http://csrc.nist.gov/publications/nistpubs/800-115/SP800-115.pdf.
Regarding controls testing, see, e.g., NIST 800-53A, Rev. 1, at 13
and Appendix F1, June 2010, available at http://csrc.nist.gov/publications/nistpubs/800-53A-rev1/sp800-53A-rev1-final.pdf.
Regarding security incident response plan testing, see, e.g., NIST
800-53A, Rev. 1, at F148, June 2010, available at http://csrc.nist.gov/publications/nistpubs/800-53A-rev1/sp800-53A-rev1-final.pdf. Regarding enterprise technology risk assessment, see,
e.g., NIST 800-53A, Rev. 1, at F226, June 2010, available at http://csrc.nist.gov/publications/nistpubs/800-53A-rev1/sp800-53A-rev1-final.pdf.
\148\ MGEX commented that it has defined and implemented a
system that it believes conforms to industry best practices. MGEX
further commented that unless each organization's structure is
identical to the CFTC's rulemakings, there will be a cost of
compliance. Throughout this section, the Commission has articulated
areas where it believes the new rules will impose new costs relative
to the current requirements. Accordingly, unless otherwise stated,
the Commission believes that any additional costs incurred by DCMs,
SEFs, and SDRs are attributable to the current requirements.
---------------------------------------------------------------------------
[[Page 64294]]
The Commission believes that new costs will be imposed by the
minimum testing frequency and independent contractor requirements for
covered DCMs and SDRs included in the final rules. In addition, the
final rules that make it mandatory for all DCMs (covered and non-
covered), SEFs, and SDRs to follow best practices, ensure testing
independence, and coordinate BC-DR plans will also impose new costs. As
discussed more fully below in Section C.3.b., the language in the final
rules make these currently recommended provisions mandatory and the
Commission believes this modification will result in new costs relative
to current practice. Finally, the Commission believes that the final
rules requiring all DCMs (covered and non-covered), SEFs, and SDRs to
update BC-DR plans and emergency procedures no less frequently than
annually, and the requirement for all DCMs to report their total annual
trading volume to the Commission each year will also impose new costs
relative to the current requirements.
The Commission expects that the costs and benefits may vary
somewhat among the covered DCMs and SDRs. For example, some covered
DCMs and SDRs are larger or more complex than others, and the new
requirements may impact covered DCMs and SDRs differently depending on
their size and the complexity of their systems.\149\ The Commission
believes that it is not possible to precisely estimate the additional
costs for covered DCMs and SDRs that may be incurred as a result of
this rulemaking, as the actual costs will be dependent on the
operations and staffing of the particular covered DCM and SDR, and to
some degree, the manner how they choose to implement compliance with
the new requirements.
---------------------------------------------------------------------------
\149\ Based on information obtained from the DMO Preliminary
Survey and the Commission's system safeguard compliance program, the
Commission understands that most large DCMs (that are likely to be
covered DCMs) and SDRs currently conduct system safeguard testing at
the minimum frequency for most of the tests required by the final
rules. Additionally, the Commission understands that most large DCMs
and SDRs currently engage independent contractors for the testing
required by the final rules.
---------------------------------------------------------------------------
While certain costs are amenable to quantification, other costs are
not easily estimated, such as the costs to the public or market
participants in the event of a cybersecurity incident at a DCM, SEF, or
SDR. The public interest is served by these critical infrastructures
performing their functions. The final regulations are intended to
mitigate the frequency and severity of system security breaches or
functional failures, and therefore, provide an important if
unquantifiable benefit to the public interest.
The discussion of costs and benefits that follows begins with a
summary of each final rule and a consideration of the corresponding
costs and benefits and the associated comments. At the conclusion of
this discussion, the Commission considers the costs and benefits of the
rules collectively in light of the five factors set forth in section
15(a) of the CEA.
3. Summary of Final Rules and Discussion of Costs and Benefits
a. Categories of Risk Analysis and Oversight: Sec. Sec. 38.1051(a),
37.1401(a), and 49.24(b)
(1) Summary of Final Rules
The final rules concerning the categories of risk analysis and
oversight clarify what is already required of all DCMs, SEFs, and SDRs
regarding the categories which their programs of risk analysis and
oversight must address by further defining the six categories addressed
by the current rules. The six categories are: (1) Information security;
(2) Business-continuity disaster recovery planning and resources; (3)
Capacity and performance planning; (4) Systems operations; (5) Systems
development and quality assurance; and (6) Physical security and
environmental controls. In addition, the final rules add and define
enterprise risk management as a seventh category.
(2) Costs and Discussion of Comments
MGEX stated that because the categories of risk analysis and
oversight identified by the Commission in the DCM, SEF, and SDR NPRM
differ from the Commission's parallel DCO NPRM, the lack of consistency
increases the compliance burden of a combined DCM and DCO entity. The
Commission acknowledges that its DCM, SEF, and SDR NPRM included the
additional category of enterprise risk management and governance.\150\
---------------------------------------------------------------------------
\150\ 80 FR 80139, 80143 (Dec. 23, 2015).
---------------------------------------------------------------------------
MGEX also argued that because the two NPRMs differ on the component
parts of a program of risk analysis and oversight, it is difficult to
conclude that these programs are pre-existing requirements that do not
have a cost of compliance. The Commission disagrees with MGEX. As noted
in the DCO NPRM, DCO's face a wider array of risks than DCMs, and
therefore enterprise risk management requirements for DCOs are not
limited to the system safeguards context, but need to be addressed in a
more comprehensive fashion and possibly in a future rulemaking.\151\
The requirement for DCMs, SEFs, and SDRs to have a program of system
safeguards risk analysis and oversight was mandated by Congress in the
CEA itself, and thus is already required by law.\152\ The Commission's
current system safeguards regulations define the program of risk
analysis and oversight by specifying the categories of risk analysis
and oversight which the program must address. The category of
enterprise risk management and governance is implicit and inherent in
the statutory requirement itself, and supported by generally accepted
standards and best practices.\153\ The final rules make enterprise risk
management and governance an explicitly listed category for the sake of
clarity. If compliance with the clarifications regarding the categories
of risk analysis and oversight results in additional costs, the
Commission believes that those are costs associated with compliance
with current requirements, not the final rules.
---------------------------------------------------------------------------
\151\ Id. at 80123.
\152\ CEA section 5(d)(20)(A), 17 U.S.C. 7(d)(20).
\153\ See, e.g., NIST SP 800-39, Managing Information Security
Risk: Organization, Mission, and Information System View (March
2011) (``NIST SP 800-39''), available at http://csrc.nist.gov/publications/nistpubs/800-39/SP800-39-final.pdf.
---------------------------------------------------------------------------
MGEX further argued that the specific and itemized content of some
of the categories of risk analysis and oversight are overly
prescriptive and should be principles based. MGEX noted information
security controls as one example that is overly prescriptive. The
Commission agrees with MGEX that the categories of risk analysis and
oversight should be principles based, but disagrees with MGEX's
assertion that the NPRM lists of topics included in each category
consist of a static list of controls. As set out in detail in the NPRM,
each of the aspects of the various categories that the program of risk
analysis and oversight must address is rooted in generally accepted
standards and best practices.\154\ Because the Commission's current
system safeguards rules and guidance provide that DCMs, SEFs, and SDRs
should follow generally accepted best practices and standards regarding
system safeguards, these entities' programs of risk analysis and
oversight should already be addressing each of the aspects included in
the NPRM for each risk analysis and oversight category.\155\
---------------------------------------------------------------------------
\154\ 80 FR 80139, 80143 (Dec. 23, 2015).
\155\ See Sec. 38.1051(b) (for DCMs); Appendix A to Part 37,
Core Principle 14 of Section 5h of the Act--System Safeguards (a)
Guidance (1) Risk analysis and oversight program (for SEFs); Sec.
49.24(c) (for SDRs).
---------------------------------------------------------------------------
[[Page 64295]]
CME requested that the Commission confirm that the final rule will
allow regulated entities flexibility of organizational design
concerning how their programs of risk analysis and oversight address
enterprise risk management and governance, and will not require that an
entity's enterprise risk management function conduct all components of
this category. As discussed in the preamble, the Commission confirms
that the addition of enterprise risk management and governance does not
require that the listed elements of this category be conducted through
a particular organizational structure; rather, the final rule provides
flexibility in this regard.
(3) Benefits
The primary benefit of the final rules is clarity to all DCMs,
SDRs, and SEFs with regard to administering their programs of risk
analysis and oversight. The final rules provide definitions for each
category of risk analysis and oversight and highlight important aspects
of each category that are recognized as best practices. An important
benefit of the adherence-to-best-practices approach taken in the
Commission's final system safeguards rules is that best practices can
evolve over time as the cybersecurity field evolves. In addition, the
Commission believes that all seven categories of risk analysis and
oversight are essential to maintaining effective system safeguards in
today's cybersecurity threat environment.
b. Requirements To Follow Best Practices, Ensure Testing Independence,
and Coordinate BC-DR Plans: Sec. Sec. 38.1051(b), 37.1401(b), and
49.24(c) (best practices); 38.1051(h)(2)(iii), (3)(iii), (4)(ii),
(5)(iii), and (7)(ii), 37.1401(h)(2)(iii), (3)(ii), (4)(ii), (5)(ii),
and (7)(ii), and 49.24(2)(iii), (4)(ii), and (7)(ii) (testing
independence); 38.1051(i), 37.1401(i), and 49.24(k) (BC-DR plans)
(1) Summary of Final Rules
The final rules make mandatory for DCMs, SEFs, and SDRs the
provisions concerning best practices, testing independence, and
coordination of BC-DR plans recommended but not made mandatory in the
Commission's current rules.
(2) Costs
The Commission did not receive any comments addressing the costs of
these provisions. The Commission's current rules for DCMs and SDRs, and
its guidance for SEFs, provide that such entities should follow best
practices in addressing the categories which their programs of risk
analysis and oversight are required to include.\156\ The current rules
and guidance also provide that such entities should ensure that their
system safeguards testing, whether conducted by contractors or
employees, is conducted by independent professionals (persons not
responsible for development or operation of the systems or capabilities
being tested).\157\ They further provide that such entities should
coordinate their BC-DR plans with the BC-DR plans of market
participants and essential service providers.\158\ Because the final
rules will make these currently recommended provisions mandatory, it is
anticipated that they will impose new costs relative to current
practice.
---------------------------------------------------------------------------
\156\ See Sec. 38.1051(b) (for DCMs); Appendix A to Part 37,
Core Principle 14 of Section 5h of the Act--System Safeguards (a)
Guidance (1) Risk analysis and oversight program (for SEFs); Sec.
49.24(c) (for SDRs).
\157\ See Sec. 38.1051(h) (for DCMs); Appendix A to Part 37,
Core Principle 14 of Section 5h of the Act--System Safeguards (a)
Guidance (2) Testing (for SEFs); Sec. 49.24(j) (for SDRs).
\158\ See Sec. 38.1051(i) (for DCMs); Appendix A to Part 37,
Core Principle 14 of Section 5h of the Act--System Safeguards (a)
Guidance (3) Coordination (for SEFs); Sec. 49.24(k) (for SDRs).
---------------------------------------------------------------------------
(3) Benefits
Making the provisions concerning following best practices, ensuring
testing independence, and coordinating BC-DR plans mandatory will align
the system safeguards rules for DCMs, SEFs, and SDRs with the
Commission's system safeguards rules for DCOs, which already contain
mandatory provisions in these respects. As stated in the preamble, the
Commission believes that the requirement to follow generally accepted
standards and best practices is one of the most important requirements
of its system safeguards rules. Best practices can evolve over time, in
light of the changing cybersecurity threat environment. The agility
that a best practices approach provides is crucial to effective
resilience with respect to cybersecurity and system safeguards.
Further, the ongoing development and evolution of best practices
benefits from private sector expertise and input, as well as from
public sector contributions. Such private sector expertise and input is
important to effective cybersecurity. The Commission also observes that
requiring financial sector entities to follow best practices with
respect to system safeguards and cybersecurity is an effective key to
harmonizing the oversight of cybersecurity conducted by different
financial regulators. The Commission also believes that clarity
concerning what is required benefits DCMs, SEFs, and SDRs, and the
public interest.
c. Updating of Business Continuity-Disaster Recovery Plans and
Emergency Procedures: Sec. Sec. 38.1051(c), 37.1401(c), and 49.24(d)
(1) Summary of Final Rules
The final rules require a DCM, SEF, or SDR to update its BC-DR plan
and emergency procedures at a frequency determined by an appropriate
risk analysis, but at a minimum no less frequently than annually.
(2) Costs
The Commission did not receive any comments addressing the costs of
this aspect of the proposed rules. The Commission's current system
safeguards rules provide that DCMs, SEFs, and SDRs must maintain BC-DR
plans and emergency procedures, but do not specify a frequency in which
such plans and procedures must be updated.\159\ As a result of the
minimum annual frequency requirement, the final rules impose new costs
relative to the requirements of the current rules.\160\ The entities
will incur the additional recurring costs associated with investing in
the resources and staff necessary to updating the BC-DR and emergency
plans at least annually.
---------------------------------------------------------------------------
\159\ Commission regulations Sec. Sec. 38.1051(c) (for DCMs),
37.1401(b) (for SEFs), and 49.24(d) (for SDRs); 17 CFR 38.1051(c);
17 CFR 37.1401(b); 17 CFR 49.24(d).
\160\ The Commission understands from conducting its oversight
of DCMs, SEFs, and SDRs that many of these entities currently update
their respective BC-DR plans and emergency procedures at least
annually.
---------------------------------------------------------------------------
(3) Benefits
The Commission notes that updating BC-DR plans and emergency
procedures at least annually is a generally accepted best practice, as
it follows NIST and other standards. These standards highlight the
importance of updating such plans and procedures at least annually to
help enable the organization to better prepare for cyber security
incidents. Specifically, the NIST standards provide that once an
organization has developed a BC-DR plan, ``the organization should
implement the plan and review it at least annually to ensure the
organization is following the roadmap for maturing the capability and
fulfilling their [sic] goals for incident response.'' \161\
---------------------------------------------------------------------------
\161\ NIST SP 800-53 Rev. 4, Physical and Environmental
Protection (PE) control family, available at http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf;
FFIEC, Operations IT Examination Handbook, at 15-18, available at
http://ithandbook.ffiec.gov/ITBooklets/FFIEC_ITBooklet_Operations.pdf.
---------------------------------------------------------------------------
[[Page 64296]]
d. Required System Safeguards-Related Books and Records Obligations:
Sec. Sec. 38.1051(g), 37.1041(g), and 49.24(i)
(1) Summary of Final Rules
The final rules require a DCM, SEF, or SDR, in accordance with
Commission regulation Sec. 1.31,\162\ to provide the Commission with
the following system safeguards-related books and records promptly upon
request of any Commission representative: (1) Current copies of the BC-
DR plans and other emergency procedures; (2) all assessments of the
entity's operational risks or system safeguards-related controls; (3)
all reports concerning system safeguards testing and assessment
required by this chapter, whether performed by independent contractors
or employees of the DCM, SEF, or SDR; and (4) all other books and
records requested by Commission staff in connection with Commission
oversight of system safeguards pursuant to the Act or Commission
regulations, or in connection with Commission maintenance of a current
profile of the entity's automated systems.
---------------------------------------------------------------------------
\162\ Commission regulation Sec. 1.31(a)(1) specifically
provides that all books and records required to be kept by the Act
or by the regulation shall be kept for a period of five years from
the date thereof and shall be readily accessible during the first 2
years of the 5-year period. All such books and records shall be open
to inspection by any representative of the Commission or the United
States Department of Justice. See 17 CFR 1.31(a)(1).
---------------------------------------------------------------------------
(2) Costs and Discussion of Comments
The Commission believes that the final rules do not impose any new
costs.\163\ All DCMs, SEFs, and SDRs are already subject to system
safeguard-related books and records requirements. The final rules
clarify the system safeguard recordkeeping and reporting requirements
for these registered entities. Because the final rules only clarify
current requirements and because the production of system-safeguard
records is already required by the current rules, the Commission
believes that the final rules do not impose any additional costs on
DCMs, SEFs, and SDRs.
---------------------------------------------------------------------------
\163\ See also PRA discussion above.
---------------------------------------------------------------------------
Although the Commission did not receive any comments specifically
addressing the costs of the books and records obligations, two
commenters addressed whether, and in what circumstances, books and
records obligations would reach the parent firm. ICE commented that
with respect to parent firms that own both CFTC-regulated and non-CFTC-
regulated entities, the Commission should avoid requiring production of
documents discussing risks at the firm-wide level. To this end, ICE
argued that the Commission should limit its production requests to
documents focused solely on the risks of CFTC-regulated entities.
However, WMBAA observed that the automated systems, programs of system
safeguards-related risk analysis and oversight, cybersecurity defenses
and testing, and BC-DR plans and resources of CFTC-regulated DCMs,
SEFs, and SDRs owned by parent financial sector companies that also own
entities not regulated by the Commission are frequently shared across
the parent company. The Commission agrees with WMBAA's comment, and
notes that this is presently the case with respect to all DCMs, SEFs,
and SDRs regulated by the Commission that are owned by the same parent
company. Thus, the Commission disagrees with ICE's suggestion that
production of books and records addressing parent-wide system
safeguards risks and risk analysis and oversight programs should not be
required. A system safeguards document that is a book and record of a
DCM, SEF, or SDR is required to be produced as a book and record
subject to the Commission's rules, regardless of whether the parent
company decides to share resources among CFTC regulated and non-CFTC
regulated entities. The production of all of the books and records
specified in the NPRM books and records provisions is already required
by the Act and Commission regulations.\164\
---------------------------------------------------------------------------
\164\ 80 FR 80139, 80147 (Dec. 23, 2015).
---------------------------------------------------------------------------
(3) Benefits
The recordkeeping requirements for DCMs, SEFs, and SDRs allow the
Commission to effectively monitor a DCM's, SEF's, or SDR's system
safeguards program and compliance with the Act and the Commission's
regulations. In addition, such requirements enable Commission staff to
perform examinations of DCMs, SEFs, and SDRs, and identify practices
that may be inconsistent with the Act and Commission regulations.
Further, making all system safeguard-related documents available to the
Commission upon request informs the Commission of areas of potential
weaknesses, or persistent or recurring problems, across DCMs, SEFs, and
SDRs.
e. Definitions: Sec. Sec. 38.1051(h)(1), 37.1041(h)(1), and
49.24(j)(1)
(1) Summary of Final Rules
The final rules include definitions for the following terms: (1)
Controls; (2) controls testing; (3) enterprise technology risk
assessment; (4) external penetration testing; (5) internal penetration
testing; (6) key controls; (7) security incident; (8) security incident
response plan; (9) security incident response plan testing; and (10)
vulnerability testing. Additionally, Sec. 38.105(h)(1) includes the
definition for covered DCM.
(2) Costs and Benefits
The definitions specified in the final rules provide context to the
specific system safeguard tests and assessments that a DCM, SEF, or SDR
is required to conduct on an ongoing basis. Accordingly, the costs and
benefits of these terms are attributable to the substantive testing
requirements and are discussed in the cost and benefit considerations
related to the final rules describing the requirements for each test.
However, the Commission notes that some comments addressed terms that
were used but not defined in the NPRM and are relevant to the
consideration of costs for the final rules. In particular, as discussed
in the preamble, CME, ICE, and MGEX commented concerning the NPRM's use
of the terms ``independent contractor'' and ``independent
professional.'' CME asserted that neither term is clearly defined in
either the Commission's existing rules or the NPRM. ICE called on the
Commission to clarify in the final rule that entity employee groups
such as the internal audit function are considered to be independent
professionals not responsible for the development of operation of the
systems or capabilities tested or assessed in the area of system
safeguards. ICE stated that not allowing internal auditors to conduct
certain system safeguards or information security testing could add
substantial costs to the regulated entities. While not commenting
directly on these definitions, MGEX expressed the view that having
independent testing performed is a key and costly feature proposed in
the NPRM.
The Commission's current system safeguards rules for DCMs and SDRs
and its current system safeguards rules and guidance for SEFs provide
that independent contractors are qualified system safeguards
professionals who are not employees of the DCM, SEF, or SDR.\165\ The
current rules use the terms independent contractor and employee as they
are legally defined and generally used.\166\ The Commission believes
that
[[Page 64297]]
the distinction between independent contractor and employee is well
settled and understood, and does not need additional definition in the
system safeguards rules. With respect to system safeguards testing, the
current rules provide that employees conducting required testing must
be independent in that they are not employees responsible for
development or operation of the systems or capabilities being tested.
The Commission believes that this distinction between employees with
sufficient independence to appropriately conduct required system
safeguards testing and those who lack such independence is also
sufficiently clear, and does not require additional definition. The
NPRM used, and the final rule will retain, this language from the
current system safeguards rules. Where this requirement is included,
the testing in question must be conducted by employees who are
independent, which means employees not responsible for developing or
operating what is being tested. Employees who are part of the internal
audit function of a DCM, SEF, or SDR, are one example of employees
having appropriate independence. Other employees who possess the
specified degree of independence and have qualifications the DCM, SEF,
or SDR believes are appropriate may also be suitable in such cases.
---------------------------------------------------------------------------
\165\ 17 CFR Sec. Sec. 38.1051(h) (for DCMs); 37.1401(g) and
Appendix B to Part 37, Core Principle 14 of Section 5h of the Act--
System Safeguards (C)(a)(2) (for SEFs); 49.24(j) (for SDRs).
\166\ See, e.g., Black's Law Dictionary, Tenth Ed. (Thomson
Reuters, St. Paul, MN, 2014) (``Employee. Someone who works in the
service of another person (the employer) under an express or implied
contract of hire, under which the employer has the right to control
the details of work performance.'') (``Independent Contractor.
Someone who is entrusted to undertake a specific project but who is
left free to do the assigned work and to choose the method for
accomplishing it.'')
---------------------------------------------------------------------------
As discussed in the preamble, one clarification may be helpful with
respect to testing required to be performed by independent contractors,
as distinct from testing performed by persons performing the internal
audit function. The internal audit function is a required aspect of the
enterprise risk management governance category which must be included
in the program of risk analysis and oversight that a DCM, SEF, or SDR
must maintain. It is an integral part of, and a responsibility of, the
regulated entity, whether carried out in-house or outsourced. The NPRM
proposed required testing by independent contractors in part to give
the Commission' system safeguards oversight a third source of system
safeguards information on which to rely, in addition to the entity's
employees and its internal audit function.\167\ It also proposed
independent contractor testing to give the regulated entity the benefit
of a truly outside perspective concerning system safeguards, not
colored by beginning from the institutional point of view. Accordingly,
testing performed by persons executing internal audit function will not
fulfill the requirement for testing by independent contractors, whether
it is performed by employees executing the internal audit function or
by internal audit contractors to whom a DCM, SEF, or SDR outsources
part or all of its internal audit function.
---------------------------------------------------------------------------
\167\ 80 FR 80139, 80148 (Dec. 23, 2015).
---------------------------------------------------------------------------
f. Vulnerability Testing: Sec. Sec. 38.1051(h)(2), 37.1401(h)(2), and
49.24(j)(2)
(1) Summary of Final Rules
The final rules define vulnerability testing as testing of a DCM's,
SEF's, or SDR's automated systems to determine what information may be
discoverable through a reconnaissance analysis of those systems and
what vulnerabilities may be present on those systems. Additionally, the
final rules require a DCM, SEF, or SDR to conduct vulnerability testing
that is sufficient to satisfy the testing scope requirements in new
Sec. Sec. 38.1051(k), 37.1401(k), and 49.24(l), at a frequency
determined by an appropriate risk analysis. Moreover, such
vulnerability testing shall include automated vulnerability scanning
and follow best practices in this regard. At a minimum, covered DCMs
and SDRs are required to conduct vulnerability testing no less
frequently than quarterly. For all DCMs, SEFs, and SDRs, vulnerability
testing may be conducted by either independent contractors or employees
of the entity that are not responsible for development or operation of
the systems or capabilities being tested.
(2) Costs and Discussion of Comments
(a) Vulnerability Testing Requirement for All DCMs, SEFs, and SDRs
As stated in the NPRM and above in the Baseline discussion, the Act
requires each DCM, SEF, and SDR to develop and maintain a program of
system safeguards-related risk analysis and oversight to identify and
minimize sources of operational risk.\168\ The Act mandates that in
this connection each DCM, SEF, and SDR must develop and maintain
automated systems that are reliable, secure, and have adequate scalable
capacity, and must ensure system reliability, security, and capacity
through appropriate controls and procedures.\169\
---------------------------------------------------------------------------
\168\ 80 FR 80139, 80164, 80167 (Dec. 23, 2015). CEA section
5(d)(20) (for DCMs); CEA section 5h(f)(14) (for SEFs); CEA section
21(f)(4)(A) and 17 CFR 49.24(a) (for SDRs).
\169\ Id.
---------------------------------------------------------------------------
The Commission's current system safeguards rules for DCMs, SEFs,
and SDRs mandate that, in order to achieve these statutory
requirements, each DCM, SEF, and SDR must conduct testing and review
sufficient to ensure that its automated systems are reliable, secure,
and have adequate scalable capacity.\170\ The Commission believes, as
the generally accepted standards and best practices noted in the NPRM
make clear, that it is essentially impossible for a DCM, SEF, or SDR to
fulfill its current obligation to conduct testing sufficient to ensure
the reliability, security, and capacity of its automated systems
without conducting vulnerability testing.\171\ If compliance with the
current testing requirements as clarified by the final rules results in
costs to a DCM, SEF, or SDR beyond those it already incurs in this
connection, the Commission believes that such additional costs are
attributable to compliance with the current rules and not to the final
rules. Accordingly, the Commission believes that clarifying the rules
will not impose any new costs for DCMs, SEFs, and SDRs.
---------------------------------------------------------------------------
\170\ Commission regulations Sec. Sec. 38.1051(h) (for DCMs),
37.1401(g) (for SEFs), and 49.24(j) (for SDRs). 17 CFR 38.1051(h);
17 CFR 37.1401(g); and 17 CFR 49.24(j).
\171\ 80 FR 80139, 80164 (Dec. 23, 2015). See, e.g., NIST SP
800-53A Rev. 1, at F67, June 2010, available at http://csrc.nist.gov/publications/nistpubs/800-53A-rev1/sp800-53A-rev1-final.pdf; and NIST SP 800-115, Technical Guide to Information
Security Testing and Assessment, at 5-2, September 2008, available
at http://csrc.nist.gov/publications/nistpubs/800-115/SP800-115.pdf.
---------------------------------------------------------------------------
(b) Authenticated Scanning Requirement for All DCMs, SEFs, and SDRs
The NPRM called for vulnerability testing to include automated
vulnerability scanning, conducted on an authenticated basis where
indicated by appropriate risk analysis, with compensating controls
where scanning is conducted on an unauthenticated basis.\172\ No
commenters disagreed with the proposed requirement for vulnerability
testing to include automated vulnerability scanning. ICE argued that
the Commission should remove the authenticated vulnerability scanning
requirement from vulnerability testing because such scanning increases
the quantity of findings, potentially diluting and obscuring important
results. Additionally, ICE stated that introducing authentication
increases the cost and time of a scan and increases risk by requiring
an operating system login to be created and maintained on a new system.
In light of the possibility that the proposed requirement for
[[Page 64298]]
automated scanning to include authenticated scanning could increase
costs, burdens, and risks while having limited utility for DCMs, SEFs,
and SDRs, the Commission is removing the authenticated scanning
requirement from the final rules. Instead, the final rules provide that
automated vulnerability scanning shall follow best practices.\173\ The
Commission believes that removal of the authenticated scanning
requirement will reduce the costs of compliance where best practices do
not require authenticated scanning.
---------------------------------------------------------------------------
\172\ Id. at 80150.
\173\ To the extent that best practices require or come to
require authenticated scanning, such scanning would be mandatory
pursuant to the requirement to follow best practices, and would be
addressed in system safeguards examinations.
---------------------------------------------------------------------------
(c) Vulnerability Testing Frequency Requirement for Covered DCMs and
SDRs
The final rules require covered DCMs and SDRs to conduct
vulnerability testing no less frequently than quarterly.\174\ The
Commission's current rules require DCMs and SDRs to conduct regular,
periodic, objective testing of their automated systems.\175\
Accordingly, the final rules will impose new costs relative to the
requirements of the current rules.\176\ MGEX stated that the frequency
of conducting vulnerability testing should be determined by the
regulatees and avoid prescriptive, static requirements.\177\ ICE argued
that regulatees should not be subject to a formal risk assessment to
potentially determine a higher vulnerability testing frequency. The
Commission notes that the minimum frequency requirement is supported by
generally accepted standards and best practices.\178\ Therefore, the
Commission disagrees with the suggestion that the frequency of such
testing should be left to the entities themselves. Accordingly, the
Commission also notes that the final rule requires all DCMs, SEFs, and
SDRs to conduct such testing as frequently as indicated by appropriate
risk analysis.
---------------------------------------------------------------------------
\174\ Based on the information collected in the DMO Preliminary
Survey, the Commission understands that most large DCMs and SDRs
currently conduct vulnerability testing at least quarterly.
\175\ See Commission regulations Sec. Sec. 38.1051(h) (for
DCMs) and 49.24(j) (for SDRs); 17 CFR 38.1051(h); 17 CFR 49.24(j).
\176\ As stated in the NPRM, the Commission's current system
safeguards rules provide that all DCMs must conduct testing to
ensure the reliability, security, and capacity of their automated
systems, and thus, to conduct vulnerability testing, external and
internal penetration testing, controls testing, enterprise
technology risk assessments, and to have and test security incident
response plans in a way governed by appropriate risk analysis. The
proposed rules avoided applying the addition minimum frequency
requirements to non-covered DCMs, in order to give smaller DCMs with
fewer resources additional flexibility regarding the testing they
must conduct. 80 FR 80168 (Dec. 23, 2015). For purposes of the final
rules, the Commission continues to believe that such a reduced
burden for smaller DCMs is appropriate.
\177\ MGEX also commented that a smaller entity, such as MGEX,
that is a combined DCM and DCO would not be able to take advantage
of the reasonable carve-out for non-covered DCMs, because it would
have to meet the highest common denominator of the DCM and DCO
rulemakings. As stated in the Commission's parallel DCO rulemaking,
the Commission has worked to harmonize the regulations applicable to
DCOs and DCMs and the regulations track each other very closely. To
the extent that an entity operating as a non-covered DCM incurs
additional costs as a result of operating a DCO that must comply
with the minimum frequency and independent contractor requirements,
such costs are attributable to the final DCO regulations.
\178\ PCI DSS, Requirement 11.2 Regularly test security systems
and processes, at 51, available at https://www.pcisecuritystandards.org/documents/navigating_dss_v20.pdf.
---------------------------------------------------------------------------
(d) Independent Contractor Requirement for Covered DCMs and SDRs
The NPRM called for covered DCMs and SDRs to engage independent
contractors to conduct two of the quarterly vulnerability tests each
year.\179\ As explained in the preamble, a number of commenters argued
that the use of independent contractors for vulnerability testing could
undesirably increase risks. The Commission agrees with the commenters
and the final rules do not include the requirement for covered DCMs and
SDRs to have some vulnerability testing conducted by independent
contractors. Instead, the final rules provide these entities with the
flexibility to engage either independent contractors or use entity
employees who are not responsible for the development or operation of
the systems or capabilities being tested. The Commission believes that
this will reduce costs and burdens for all covered DCMs and SDRs.\180\
---------------------------------------------------------------------------
\179\ Id. at 80150.
\180\ CME commented that the NPRM's independent contractor
requirements that apply to vulnerability testing will result in an
additional cost of $1.1 million every two years.
---------------------------------------------------------------------------
(e) Cost Estimates for Covered DCMs and SDRs
The Commission did not receive comments addressing the total costs
for conducting vulnerability testing. As discussed above in the costs
section concerning the minimum frequency requirement, the final rules
will impose new costs on covered DCMs and SDRs. The data collected from
the DMO Preliminary Survey, suggests that on average, a covered DCM or
SDR currently spends approximately $3,495,000 annually on vulnerability
testing. As stated in the NPRM, the Commission recognizes that the
actual costs may vary widely as a result of numerous factors including,
the size of the organization, the complexity of the automated systems,
and the scope of the test.\181\ Additionally, although the Commission
believes that all covered DCMs and SDRs have policies and procedures in
place for vulnerability testing, the Commission acknowledges that
affected entities may need to dedicate time to reviewing and revising
their current policies and procedures to ensure that they are
sufficient in the context of the final rules. The Commission believes
that any costs incurred by the entities as result of such review will
be minor.
---------------------------------------------------------------------------
\181\ Id. at 80168.
---------------------------------------------------------------------------
(3) Benefits
Vulnerability testing identifies, ranks, and reports
vulnerabilities that, if exploited, may result in an intentional or
unintentional compromise of a system.\182\ The complex analysis and
plan preparation that a DCM, SEF, or SDR undertakes to complete
vulnerability testing, including designing and implementing changes to
existing plans, are likely to contribute to a better understanding by
management of the challenges the entity might face in a cyber threat
scenario. In turn, the entity will be better prepared to address those
challenges. Improved preparation helps reduce the possibility of market
disruptions. Regularly conducting vulnerability tests enables a DCM,
SEF, or SDR to mitigate the impact that a cyber threat to, or a
disruption of, the entity's operations would have on market
participants, and more broadly, the stability of the U.S. financial
markets. Accordingly, the Commission believes that such testing
strengthens a DCM's, SEF's, and SDR's automated systems, thereby
protecting market participants and swaps data reporting parties from a
disruption in services.
---------------------------------------------------------------------------
\182\ See Security Standards Council, PCI-DSS Information
Supplement: Penetration Testing Guidance, p. 3, available at:
https://www.pcisecuritystandards.org/documents/Penetration_Testing_Guidance_March_2015.pdf.
---------------------------------------------------------------------------
With respect to the minimum frequency requirement for covered DCMs
and SDRs, the Commission believes that such entities have a significant
incentive to conduct vulnerability testing at least quarterly in order
to identify the latest threats to the organization and reduce the
likelihood that attackers could exploit vulnerabilities. Best practices
also support the requirement that vulnerability testing be conducted no
less frequently than quarterly. For example, PCI DSS standards provide
that entities should run internal and external network vulnerability
scans ``at
[[Page 64299]]
least quarterly,'' as well as after any significant network changes,
new system component installations, firewall modifications, or product
upgrades.\183\ Moreover, the Commission believes that the minimum
frequency requirement provides additional clarity to covered DCMs and
SDRs concerning what is required in this respect. As noted above in the
costs section for this provision, the final rules also provide
flexibility for DCMs, SEFs, and SDRs to have vulnerability testing
conducted by either independent contractors or entity employees who are
not responsible for development or operation of the systems or
capabilities being tested.
---------------------------------------------------------------------------
\183\ PCI DSS, Requirement 11.2 Regularly test security systems
and processes, at 51, available at https://www.pcisecuritystandards.org/documents/navigating_dss_v20.pdf.
---------------------------------------------------------------------------
g. External Penetration Testing: Sec. Sec. 38.1051(h)(3),
37.1401(h)(3), and 49.24(j)(3)
(1) Summary of Final Rules
The final rules define external penetration testing as attempts to
penetrate a DCM's, SEF's or SDR's automated systems from outside the
systems' boundaries to identify and exploit vulnerabilities.
Additionally, the final rules require a DCM, SEF, or SDR to conduct
external penetration testing that is sufficient to satisfy the scope
requirements in new Sec. Sec. 38.1051(k), 37.1401(k), and 49.24(l), at
a frequency determined by an appropriate risk analysis. At a minimum,
covered DCMs and SDRs are required to conduct external penetration
testing no less frequently than annually. Covered DCMs and SDRs also
are required to engage independent contractors to perform the required
annual external penetration test, although the entity could have other
external penetration testing conducted by employees who are not
responsible for development or operation of the systems or capabilities
being tested.
(2) Costs and Discussion of Comments
(a) External Penetration Testing for All DCMs, SEFs, and SDRs
As stated in the NPRM and above in the Baseline discussion, the Act
requires each DCM, SEF, and SDR to develop and maintain a program of
system safeguards-related risk analysis and oversight to identify and
minimize sources of operational risk.\184\ The Act mandates that in
this connection each DCM, SEF, and SDR must develop and maintain
automated systems that are reliable, secure, and have adequate scalable
capacity, and must ensure system reliability, security, and capacity
through appropriate controls and procedures.\185\
---------------------------------------------------------------------------
\184\ 80 FR 80139, 80164, 80169 (Dec. 23, 2015). CEA section
5(d)(20) (for DCMs); CEA section 5h(f)(14) (for SEFs); CEA section
21(f)(4)(A) and 17 CFR 49.24(a) (for SDRs).
\185\ Id.
---------------------------------------------------------------------------
The Commission's current system safeguards rules for DCMs, SEFs,
and SDRs mandate that, in order to achieve these statutory
requirements, each DCM, SEF, and SDR must conduct testing and review
sufficient to ensure that its automated systems are reliable, secure,
and have adequate scalable capacity.\186\ The Commission believes, as
the generally accepted standards and best practices noted in the NPRM
make clear, that it is essentially impossible for a DCM, SEF, or SDR to
fulfill its current obligation to conduct testing sufficient to ensure
the reliability, security, and capacity of its automated systems
without conducting external penetration testing.\187\ If compliance
with the current testing requirements as clarified by the final rules
results in costs to a DCM, SEF, or SDR beyond those it already incurs
in this connection, the Commission believes that such additional costs
are attributable to compliance with the current rules and not to the
final rules. Accordingly, the Commission believes that clarifying the
rules will not impose any new costs for DCMs, SEFs, and SDRs.
---------------------------------------------------------------------------
\186\ Commission regulations Sec. Sec. 38.1051(h) (for DCMs),
37.1401(g) (for SEFs), and 49.24(j) (for SDRs). 17 CFR 38.1051(h);
17 CFR 37.1401(g); and 17 CFR 49.24(j).
\187\ 80 FR 80139, 80164 (Dec. 23, 2015). See, e.g., NIST
Special Publication (``SP'') 800-53A, Rev. 1, at E1, June 2010,
available at: http://csc.nist.gov/publications/nistpubs/800-53A-rev1/sp800-53A-rev1-final.pdf; and NIST 800-115, at 4-4, September
2008, available at: http://csrc.nist.gov/publications/nistpubs/800-115/SP800-115.pdf.
---------------------------------------------------------------------------
(b) External Penetration Testing Frequency Requirement for Covered DCMs
and SDRs
The final rules require covered DCMs and SDRs to conduct external
penetration testing no less frequently than annually. The Commission's
current rules require DCMs and SDRs to conduct regular, periodic,
objective testing of their automated systems.\188\ Because the current
rules do not specify the frequency of such testing, the final rules
will impose new costs relative to the requirements of the current
rules.\189\ MGEX commented that the frequency of conducting external
penetration testing should be left up to the organizations themselves.
The Commission notes that external penetration testing is supported by
generally accepted standards and best practices, which make it clear
that testing at least annually is essential to adequate system
safeguards in today's cybersecurity environment.\190\ Therefore, the
Commission disagrees with the suggestion that the frequency should be
left to the determination of the entities themselves. Accordingly, the
Commission also notes that the final rule requires all DCMs, SEFs, and
SDRs to conduct such testing as frequently as indicated by appropriate
risk analysis.
---------------------------------------------------------------------------
\188\ See Commission regulations Sec. Sec. 38.1051(h) (for
DCMs) and 49.24(j) (for SDRs); 17 CFR 38.1051(h); 17 CFR 49.24(j).
\189\ Based on the information collected in the DMO Preliminary
Survey, the Commission understands that most large DCMs and SDRs
currently conduct external penetration testing at the minimum
frequency specified in the final rule.
\190\ NIST, SP 800-115, Technical Guide to Information Security
Testing and Assessment, Section 5.2.2, at 5-5, available at http://csrc.nist.gov/publications/nistpubs/800-115/SP800-115.pdf.
---------------------------------------------------------------------------
(c) Independent Contractor Requirement for Covered DCMs and SDRs
The final rules also require that the annual external penetration
test conducted by a covered DCM or SDR be conducted by an independent
contractor. Current Commission regulations Sec. Sec. 38.1051(h) and
49.24(j) provide that testing of automated systems should be conducted
by qualified, independent professionals.\191\ The qualified independent
professionals may be independent contractors or employees of a DCM or
SDR as long as they are not responsible for development or operation of
the systems or capabilities being tested. Therefore, the final rules
will impose new costs relative to the requirements of the current
rules.\192\
---------------------------------------------------------------------------
\191\ Id.
\192\ Based on the information collected in the DMO Preliminary
Survey, the Commission understands that most large DCMs and SDRs
currently engage independent contractors to conduct external
penetration testing.
---------------------------------------------------------------------------
DDR commented generally that an SDR should have flexibility
regarding whether to have testing conducted by independent contractors
or employees not responsible for the development or operation of the
systems or capabilities being tested, based on the risks of that SDR.
The Commission disagrees with DDR's comment. As discussed more fully in
the preamble and noted below in the benefits section related to this
provision, the Commission believes that the independent viewpoint and
approach provided by independent contractors, who can conduct a
penetration test from the perspective of an outside adversary uncolored
by insider assumptions or blind spots, will benefit covered DCM and SDR
programs of risk analysis and oversight. The Commission also notes that
best
[[Page 64300]]
practices support using independent contractors.\193\
---------------------------------------------------------------------------
\193\ Council on CyberSecurity, CSC 20-1, available at http://www.counciloncybersecurity.org/critical-controls/.
---------------------------------------------------------------------------
(d) Cost Estimates for Covered DCMs and SDRs
The Commission did not receive any comments addressing the total
costs for conducting external penetration testing. CME, however,
estimated that the independent contractor requirements in the Proposal,
which apply to external penetration testing, will result in an
additional cost of $1.1 million every two years. The data collected
from the DMO Preliminary Survey suggests that on average a covered DCM
or SDR spends approximately $244,625 annually on external penetration
testing. The Commission recognizes that the actual costs may vary
widely as a result of many factors, including the size of the
organization, the complexity of the automated systems, and the scope of
the test. Where a covered DCM or SDR does not currently use an
independent contractor to conduct the external penetration test, the
Commission expects that such entities may incur some additional minor
costs as a result of the need to establish and implement internal
policies and procedures that are reasonably designed to address the
workflow associated with the test. For example, the Commission expects
that such policies and procedures may include communication and
cooperation between the entity and independent contractor,
communication and cooperation between the entity's legal, business,
technology, and compliance departments, appropriate authorization to
remediate vulnerabilities identified by the independent contractor,
implementation of the measures to address such vulnerabilities, and
verification that these measures are effective and appropriate. Covered
DCMs and SDRs that currently do not use independent contractors for the
external penetration test may also need to dedicate time to reviewing
and revising their current policies and procedures to ensure that they
are sufficient in the context of the new requirements. The Commission
believes that any costs incurred by the entities as result of such
review will be minor.
(3) Benefits
External penetration testing benefits DCMs, SEFs, and SDRs by
identifying the extent to which their systems can be compromised before
an attack is identified.\194\ Such testing is conducted from outside a
DCM's, SEF's, or SDR's security perimeter to help reveal
vulnerabilities that could be exploited by an external attacker. The
Commission believes that external penetration testing strengthens DCM,
SEF, and SDR systems, thereby protecting the entity and market
participants from a disruption in services. A disruption in services at
any of these entities could potentially disrupt the functioning of the
broader financial markets.
---------------------------------------------------------------------------
\194\ FFIEC, Information Security IT Examination Handbook, at
81, available at http://ithandbook.ffiec.gov/ITBooklets/FFIEC_ITBooklet_InformationSecurity.pdf.
---------------------------------------------------------------------------
The requirement for annual external penetration testing at covered
DCMs and SDRs to be performed by an independent contractor is intended
to ensure that these entities' system safeguards programs of risk
analysis and oversight include the benefits provided when independent
contractors perform such testing. The Commission believes that
independent contractor testing has particular value with respect to
external penetration testing because the test is conducted from the
viewpoint of an outsider and against the current tactics, techniques,
and threat vectors of current threat actors as revealed by current
threat intelligence.
h. Internal Penetration Testing: Sec. Sec. 38.1051(h)(4),
37.1401(h)(4), and 49.24(j)(4)
(1) Summary of Final Rules
The final rules define internal penetration testing as attempts to
penetrate a DCM's, SEF's, or SDR's automated systems from inside the
systems' boundaries to identify and exploit vulnerabilities.
Additionally, the final rules require a DCM, SEF, or SDR to conduct
internal penetration testing that is sufficient to satisfy the scope
requirements in new Sec. Sec. 38.1051(k), 37.1401(k), and 49.24(l), at
a frequency determined by an appropriate risk analysis. At a minimum,
covered DCMs and SDRs are required to conduct the internal penetration
testing no less frequently than annually. All DCM, SEFs, or SDRs may
engage independent contractors to conduct the test, or the entity may
use employees of the entity who are not responsible for development or
operation of the systems or capabilities being tested.
(2) Costs and Discussion of Comments
(a) Internal Penetration Testing for All DCMs, SEFs, and SDRs
As stated in the NPRM and above in the Baseline discussion, the Act
requires each DCM, SEF, and SDR to develop and maintain a program of
system safeguards-related risk analysis and oversight to identify and
minimize sources of operational risk.\195\ The Act mandates that in
this connection each DCM, SEF, and SDR must develop and maintain
automated systems that are reliable, secure, and have adequate scalable
capacity, and must ensure system reliability, security, and capacity
through appropriate controls and procedures.\196\
---------------------------------------------------------------------------
\195\ 80 FR 80139, 80164, 80170 (Dec. 23, 2015). CEA section
5(d)(20) (for DCMs); CEA section 5h(f)(14) (for SEFs); CEA section
21(f)(4)(A) and 17 CFR 49.24(a) (for SDRs).
\196\ Id.
---------------------------------------------------------------------------
The Commission's current system safeguards rules for DCMs, SEFs,
and SDRs mandate that, in order to achieve these statutory
requirements, each DCM, SEF, and SDR must conduct testing and review
sufficient to ensure that its automated systems are reliable, secure,
and have adequate scalable capacity.\197\ The Commission believes, as
the generally accepted standards and best practices noted in the NPRM
make clear, that it is essentially impossible for a DCM, SEF, or SDR to
fulfill its current obligation to conduct testing sufficient to ensure
the reliability, security, and capacity of its automated systems
without conducting internal penetration testing.\198\ If compliance
with the current testing requirements as clarified by the final rules
results in costs to a DCM, SEF, or SDR beyond those it already incurs
in this connection, the Commission believes that such additional costs
are attributable to compliance with the current rules and not to the
final rules. Accordingly, the Commission believes that clarifying the
rules will not impose any new costs for DCMs, SEFs, and SDRs.
---------------------------------------------------------------------------
\197\ Commission regulations Sec. Sec. 38.1051(h) (for DCMs),
37.1401(g) (for SEFs), and 49.24(j) (for SDRs). 17 CFR 38.1051(h);
17 CFR 37.1401(g); and 17 CFR 49.24(j).
\198\ 80 FR 80139, 80164 (Dec. 23, 2015). See, e.g., NIST
Special Publication (``SP'') 800-53A, Rev. 1, at E1, June 2010,
available at: http://csc.nist.gov/publications/nistpubs/800-53A-rev1/sp800-53A-rev1-final.pdf; and NIST 800-115, at 4-4, September
2008, available at: http://csrc.nist.gov/publications/nistpubs/800-115/SP800-115.pdf.
---------------------------------------------------------------------------
(b) Internal Penetration Testing by Independent Contractors or
Employees of the DCM, SEF, or SDR
The Commission continues to believe, as provided in the NPRM, that
it is appropriate to give all DCMs, SEFs, and SDRs the flexibility of
whether to have internal penetration testing performed by independent
contractors or by employees not responsible for
[[Page 64301]]
development or operation of the systems or capabilities tested.\199\
---------------------------------------------------------------------------
\199\ Id. at 80153.
---------------------------------------------------------------------------
(c) Internal Penetration Testing Frequency Requirement for Covered DCMs
and SDRs
The final rules require covered DCMs and SDRs to conduct internal
penetration testing no less frequently than annually. The Commission's
current rules require DCMs and SDRs to conduct regular, periodic,
objective testing of their automated systems.\200\ Because the current
rules do not specify the frequency of such testing, the final rules
will impose new costs.\201\ CME commented that there is a scarcity of
potential employees with the skill set required to conduct internal
penetration testing without introducing risks into the production
environment and other sensitive environments. For this reason, CME
suggested making annual internal penetration testing an objective
rather than a requirement, so that covered DCMs and SDRs can prioritize
truly effective testing over less skilled testing done merely to check
the annual requirement box. MGEX called for the final rule to leave the
frequency of penetration testing to be determined by regulatees. The
Commission notes that the minimum annual frequency requirement is
supported by generally accepted standards and best practices, which
make it clear that such testing at least annually is essential to
adequate system safeguards in today's cybersecurity environment.\202\
Thus, the Commission disagrees with the suggestions that annual
internal penetration should be a mere objective, or that the frequency
of such testing by covered DCMs and SDRs should be left to
determination by those entities themselves. The Commission also notes
that the final rule requires all DCMs, SEFs, and SDRs to conduct such
testing as frequently as indicated by appropriate risk analysis.
---------------------------------------------------------------------------
\200\ See Commission regulations Sec. Sec. 38.1051(h) (for
DCMs) and 49.24(j) (for SDRs); 17 CFR 38.1051(h); 17 CFR 49.24(j).
\201\ Based on the information from the DMO Preliminary Survey,
the Commission understands that most large DCMs and SDRs currently
conduct internal penetration testing at the minimum frequency
specified in the final rule.
\202\ PCI DSS standards, at 96 through 97, available at https://www.pcisecuritystandards.org/security_standards/index.php.
---------------------------------------------------------------------------
(d) Cost Estimates for Covered DCMs and SDRs
The Commission did not receive comments addressing the total costs
for conducting internal penetration testing. However, based on the data
from the DMO Preliminary Survey, the Commission estimates that the
current average cost for a covered DCM or SDR conducting internal
penetration testing is approximately $410,625 annually. The Commission
recognizes that the actual costs may vary significantly as a result of
numerous factors, including the size of the organization, the
complexity of the automated systems, and the scope of the test. The
Commission also recognizes that large DCMs and SDRs may undertake an
evaluation, on an initial and ongoing basis, regarding internal
policies and procedures for internal penetration testing that may need
to be revised. The Commission believes that these costs will be minor.
(3) Benefits
By attempting to penetrate a DCM's, SEF's or SDR's automated
systems from inside the systems' boundaries, internal penetration tests
allow the respective entities to assess system vulnerabilities from
attackers that penetrate their perimeter defenses and from trusted
insiders, such as former employees and contractors. In addition to
being an industry best practice, the Commission believes that annual
internal penetration testing is important because such potential
attacks by trusted insiders generally pose a unique and substantial
threat due to their more sophisticated understanding of a DCM's, SEF's,
or SDR's systems. Moreover, ``[a]n advanced persistent attack may
involve an outsider gaining a progressively greater foothold in a
firm's environment, effectively becoming an insider in the process. For
this reason, it is important to perform penetration testing against
both external and internal interfaces and systems.'' \203\
---------------------------------------------------------------------------
\203\ FINRA, Report on Cybersecurity Practices (February 2015),
at 22, available at https://www.finra.org/sites/default/files/p602363%20Report%20on%20Cybersecurity%20Practices_0.pdf.
---------------------------------------------------------------------------
As discussed above in the costs section for this provision, the
final rules address the required minimum frequency for covered DCMs and
SDRs to perform internal penetration testing. Best practices support
both external and internal penetration testing on at least an annual
basis. NIST calls for at least annual penetration testing of an
organization's network and systems.\204\ The FFIEC calls for
penetration testing of high risk systems at least annually, and for
quarterly testing and verification of the efficacy of firewall and
access control defenses.\205\ Data security standards for the payment
card industry provide that entities should perform both external and
internal penetration testing ``at least annually,'' as well as after
any significant network changes, new system component installations,
firewall modifications, or product upgrades.\206\ The Commission
believes the specified frequency levels will increase the likelihood
that the affected entities will be adequately protected against the
level of cybersecurity threat now affecting the financial sector.
---------------------------------------------------------------------------
\204\ NIST, SP 800-115, Technical Guide to Information Security
Testing and Assessment, Section 5.2.2, at 5-5, available at http://csrc.nist.gov/publications/nistpubs/800-115/SP800-115.pdf.
\205\ FFIEC, Information Security IT Examination Handbook, at
82, available at http://ithandbook.ffiec.gov/ITBooklets/FFIEC_ITBooklet_InformationSecurity.pdf.
\206\ PCI DSS, Requirements 11.3.1 and 11.3.2., available at
https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-1.pdf.
---------------------------------------------------------------------------
i. Controls Testing: Sec. Sec. 38.1051(h)(5), 37.1401(h)(5), and
49.24(j)(5)
(1) Summary of Final Rules
The final rules define controls testing as an assessment of the
DCM's, SEF's, or SDR's market controls to determine whether such
controls are implemented correctly, are operating as intended, and are
enabling the entity to meet the system safeguard requirements
established by the respective chapters. Additionally, the final rules
require a DCM, SEF, or an SDR to conduct controls testing that is
sufficient to satisfy the scope requirements in new Sec. Sec.
38.1051(k), 37.1401(k), and 49.24(l), at a frequency determined by an
appropriate risk analysis. Covered DCMs and SDRs are required to test
the key controls in the entity's risk analysis and oversight no less
frequently than every three years. Such testing may be conducted on a
rolling basis over the course of the minimum three-year period or over
a minimum period determined by an appropriate risk analysis, whichever
is shorter. Covered DCMs and SDRs also are required to engage
independent contractors to test and assess their key controls no less
frequently than every three years. The entities may conduct any other
controls testing by using either independent contractors or employees
of the DCM or SDR who are not responsible for development or operation
of the systems or capabilities being tested.
(2) Costs and Discussion of Comments
(a) Controls Testing for All DCMs, SEFs, and SDRs
As stated in the NPRM and above in the Baseline discussion, the Act
requires each DCM, SEF, and SDR to develop and maintain a program of
system safeguards-related risk analysis and
[[Page 64302]]
oversight to identify and minimize sources of operational risk.\207\
The Act mandates that in this connection each DCM, SEF, and SDR must
develop and maintain automated systems that are reliable, secure, and
have adequate scalable capacity, and must ensure system reliability,
security, and capacity through appropriate controls and
procedures.\208\
---------------------------------------------------------------------------
\207\ 80 FR 80139, 80164, 80172 (Dec. 23, 2015). CEA section
5(d)(20) (for DCMs); CEA section 5h(f)(14) (for SEFs); CEA section
21(f)(4)(A) and 17 CFR 49.24(a) (for SDRs).
\208\ Id.
---------------------------------------------------------------------------
The Commission's current system safeguards rules for DCMs, SEFs,
and SDRs mandate that, in order to achieve these statutory
requirements, each DCM, SEF, and SDR must conduct testing and review
sufficient to ensure that its automated systems are reliable, secure,
and have adequate scalable capacity.\209\ The Commission believes, as
the generally accepted standards and best practices noted in the NPRM
make clear, that it is essentially impossible for a DCM, SEF, or SDR to
fulfill its current obligation to conduct testing sufficient to ensure
the reliability, security, and capacity of its automated systems
without conducting controls testing.\210\ If compliance with the
current testing requirements as clarified by the final rules results in
costs to a DCM, SEF, or SDR beyond those it already incurs in this
connection, the Commission believes that such additional costs are
attributable to compliance with the current rules and not to the final
rules. Accordingly, the Commission believes that clarifying the rules
will not impose any new costs for DCMs, SEFs, and SDRs.
---------------------------------------------------------------------------
\209\ Commission regulations Sec. Sec. 38.1051(h) (for DCMs),
37.1401(g) (for SEFs), and 49.24(j) (for SDRs). 17 CFR 38.1051(h);
17 CFR 37.1401(g); and 17 CFR 49.24(j).
\210\ 80 FR 80139, 80172 (Dec. 23, 2015). See, e.g., NIST 800-
53A, Rev. 1, at 13 and Appendix F1, June 2010, available at http://csrc.nist.gov/publications/nistpubs/800-53A-rev1/sp800-53A-rev1-final.pdf.
---------------------------------------------------------------------------
(b) Controls Testing Frequency Requirement for Covered DCMs and SDRs
The final rules require a covered DCM or SDR to test each key
control included in its program of system safeguards-related risk
analysis and oversight no less frequently than every three years rather
than the two-year cycle proposed in the NPRM. The Commission's current
rules require DCMs and SDRs to conduct regular, periodic, objective
testing of their automated systems.\211\ Therefore, the final rules
will impose new costs relative to the requirements of the current
rules.\212\ CME commented that some less critical controls do not
warrant testing on a two-year cycle, and cited best practices
permitting controls testing on a three-year cycle. CME suggested that
the final rule should call for the minimum controls testing frequency
for covered DCMs and SDRs to be determined by risk analysis (as the
NPRM proposed for non-covered DCMs and SEFs), or alternatively that a
minimum frequency cycle of three years would be a reasonable
alternative to the NPRM's proposed two-year cycle. CME also suggested
that, while many organizations will implement a two-year schedule for
at least the testing of key controls, either of CME's proposed
alternatives would make controls testing more cost effective, and
increase focus on the most critical controls. The Commission agrees
that a three-year rather than two-year minimum controls testing
frequency requirement for covered DCMs and SDRs may reduce costs and
burdens, while providing beneficial flexibility in overall controls
testing program design and still ensuring that the fundamental purposes
of the CEA and the Commission's system safeguards rules are achieved.
---------------------------------------------------------------------------
\211\ See Commission regulations Sec. Sec. 38.1051(h) (for
DCMs) and 49.24(j) (for SDRs); 17 CFR 38.1051(h); 17 CFR 49.24(j).
\212\ Based on the information collected in the DMO Preliminary
Survey, the Commission understands that at least some of the large
DCMs and SDRs currently conduct key controls testing at the
frequency level specified in the final rule.
---------------------------------------------------------------------------
(c) Independent Contractor Requirement for Covered DCMs and SDRs
The final rules also require a DCM or SDR to engage an independent
contractor to test and assess the key controls no less frequently than
every three years. Current Commission regulations Sec. Sec. 38.1051(h)
and 49.24(j) provide that testing of automated systems should be
conducted by qualified, independent professionals. The qualified
independent professionals may be independent contractors or employees
of a DCM or SDR as long as they are not responsible for development or
operation of the systems or capabilities being tested. Accordingly, the
final rules will impose new costs relative to the requirements of the
current rules.\213\ CME commented that, while independent contractor
controls testing may be beneficial, the final rule should not exclude
controls testing by independent employees, such as internal audit
staff. DDR also commented that, where the NPRM proposed to require
independent contractor testing, the final rule should give flexibility
to use either independent contractors or independent employees. ICE
suggested that the final rule should not require key controls testing,
by independent contractors or otherwise, because it imposes a large
burden for little or no practical improvement in security. The
Commission notes that generally accepted standards and best practices
call for key controls testing by independent contractors.\214\
Therefore, the Commission disagrees with comments suggesting that the
final rule should not require testing of key controls by independent
contractors. Independent contractor testing of key controls will
strengthen Commission oversight of system safeguards by providing an
important, credible third source of information concerning crucial
safeguards in addition to what is available from covered DCM or SDR
staff and from the internal audit function of those entities. While the
Commission recognizes that covered DCMs and SDRs will incur additional
costs to engage independent contractors, the Commission believes that
extending the minimum testing frequency for such testing by independent
contractors from two to three years will reduce costs and burdens.
---------------------------------------------------------------------------
\213\ Based on the information collected in the DMO Preliminary
Survey, the Commission understands that most large DCMs and SDRs
currently engage independent contractors to conduct key controls
testing.
\214\ NIST SP 800-53A Rev. 4, at 17-18, available at http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53Ar4.pdf.
---------------------------------------------------------------------------
(d) Cost Estimates for Covered DCMs and SDRs
Based on the information from the DMO Preliminary Survey, the
Commission estimates that the average cost for a covered DCM or SDR to
conduct controls testing is approximately $2,724,000 annually.\215\ As
discussed above in the costs section concerning the minimum frequency
and independent contractor requirements, the final rules will impose
new costs on covered DCMs and SDRs. CME estimated that conducting
controls testing in the manner proposed by the Commission will result
in an additional cost of $5.6 million over a two-year period. However,
the Commission believes that the modification of the minimum frequency
requirement from two to three years will reduce costs and burdens.
Consistent with all of the system safeguard-related tests required
[[Page 64303]]
in the final rules, the Commission recognizes that the actual costs may
vary widely as a result of numerous factors including, the size of the
organization, the complexity of the automated systems, and the scope of
the test. With respect to a covered DCM or SDR that does not currently
use an independent contractor to conduct key controls testing, the
Commission expects that these entities may incur some minor costs as a
result of the need to establish and implement internal policies and
procedures that are reasonably designed to address the workflow
associated with the test. For example, the Commission expects that such
policies and procedures may include the communication and cooperation
between the entity and independent contractor; communication and
cooperation between the entity's legal, business, technology, and
compliance departments; appropriate authorization to remediate
deficiencies identified by the independent contractor; implementation
of the measures to address such deficiencies; and verification that
these measures are effective and appropriate. While the Commission
believes that all covered DCMs and SDRs have policies and procedures in
place for controls testing conducted by internal staff, the Commission
acknowledges that the affected entities may dedicate time in reviewing
and revising their current policies and procedures to ensure that they
are sufficient in the context of the new requirements. The Commission
believes that any costs incurred by the entities as result of such
review will be minor.
---------------------------------------------------------------------------
\215\ One of the Cybersecurity Roundtable participants noted
that with respect to the costs for a properly scoped program of
controls testing there is no single answer to this question because
it depends on the number of an organization's applications and the
amount of money spent across the industry varies greatly. See CFTC
Roundtable, at 258-59.
---------------------------------------------------------------------------
(3) Benefits
Controls testing is essential in determining risk to an
organization's operations and assets, to individuals, to other
organizations, and to the nation resulting from the use of the
organization's systems.\216\ In other words, controls testing is vital
because it allows firms to be nimble in preventing, detecting, or
recovering from an attack.\217\ The Commission believes that the
complex analysis and plan preparation that DCMs, SEFs, and SDRs
undertake with respect to controls testing, including designing and
implementing changes to existing plans, likely contributes to a better
understanding by management of the challenges the entity would face in
a cyber threat scenario. Consequently, these entities should be better
prepared to meet these challenges. This improved preparation also would
help reduce the possibility of market disruptions and financial losses
to market participants. Moreover, regularly conducting controls testing
enables DCMs, SEFs, and SDRs to mitigate the impact that a cyber threat
to, or a disruption of, operations would have on market participants,
and more broadly, the stability of the U.S. financial markets.
Accordingly, the Commission believes that such testing strengthens
DCMs, SEFs, and SDRs automated systems, thereby protecting market
participants and swaps data reporting parties from a disruption in
services.
---------------------------------------------------------------------------
\216\ NIST SP 800-53A, Assessing Security and Privacy Controls
in Federal Information Systems and Organizations, rev. 4 (``NIST SP
800-53A''), p. 3, available at: http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53Ar4.pdf.
\217\ CFTC Roundtable, at 43-44.
---------------------------------------------------------------------------
As noted above in the costs section for this provision, the final
rules require a covered DCM or SDR to test each key control included in
its program of system safeguards-related risk analysis oversight no
less frequently than every three years. The Commission believes that it
is essential for each key control to be tested at least this often in
order to confirm the continuing adequacy of the entity's system
safeguards in today's cybersecurity threat environment. Additionally,
the frequency requirement would benefit the affected entities by
providing additional clarity concerning what is required of them in
this respect. The final rules also permit such testing to be conducted
on a rolling basis over the course of the three-year period or over a
minimum period determined by an appropriate risk analysis, whichever is
shorter. The rolling basis provision is designed to provide a covered
DCM or SDR flexibility in conducting the key controls testing during
the required minimum frequency period. This flexibility is intended to
reduce burdens to the extent possible while still ensuring the needed
minimum testing frequency. The Commission also notes that testing on a
rolling basis is consistent with industry best practices.\218\
---------------------------------------------------------------------------
\218\ NIST SP 800-53A Rev. 4, at 17-18, available at http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53Ar4.pdf.
---------------------------------------------------------------------------
Additionally, the final rules require a covered DCM or SDR to
engage independent contractors to test and assess each of the entity's
key controls no less frequently than every three years. Independent
testing of key controls is consistent with best practices.
Significantly, the NIST Standards note the important benefits of
independent testing and call for controls testing to include assessment
by independent assessors, free from actual or perceived conflicts of
interest, in order to validate the completeness, accuracy, integrity,
and reliability of test results.\219\ Accordingly, in light of best
practices and the current cyber threat level to the financial sector,
the Commission believes that the covered DCM and SDR independent
contractor testing requirement for key controls would provide these
substantial benefits.
---------------------------------------------------------------------------
\219\ Id.
---------------------------------------------------------------------------
j. Security Incident Response Plan Testing: Sec. Sec. 38.1051(h)(6),
37.1401(h)(6), and 49.24(j)(6)
(1) Summary of Final Rules
The final rules define security incident response testing as
testing of a DCM's, SEF's, or SDR's security incident plan to determine
the plan's effectiveness, identifying its potential weaknesses or
deficiencies, enabling regular plan updating and improvement, and
maintaining organizational preparedness and resiliency with respect to
security incidents. In addition, the methods of conducting security
incident response plan testing may include checklist completion, walk-
through or table-top exercises, simulations, and comprehensive
exercises. The final rules require covered DCMs and SDRs to conduct
such testing at a frequency determined by an appropriate risk analysis,
but at a minimum no less frequently than annually. All DCMs, SEFs, and
SDRs may conduct such testing by engaging either independent
contractors or employees of the entity.
(2) Costs and Discussion of Comments
(a) Requirement To Maintain and Test a Security Incident Response Plan
for All DCMs, SEFs, and SDRs
As stated in the NPRM and above in the Baseline discussion, the Act
requires each DCM, SEF, and SDR to develop and maintain a program of
system safeguards-related risk analysis and oversight to identify and
minimize sources of operational risk.\220\ The Act mandates that in
this connection each DCM, SEF, and SDR must develop and maintain
automated systems that are reliable, secure, and have adequate scalable
capacity, and must ensure system reliability, security, and capacity
through appropriate controls and procedures.\221\
---------------------------------------------------------------------------
\220\ 80 FR 80139, 80164, 80174 (Dec. 23, 2015). CEA section
5(d)(20) (for DCMs); CEA section 5h(f)(14) (for SEFs); CEA section
21(f)(4)(A) and 17 CFR 49.24(a) (for SDRs).
\221\ Id.
---------------------------------------------------------------------------
The Commission's current system safeguards rules for DCMs, SEFs,
and SDRs mandate that, in order to achieve
[[Page 64304]]
these statutory requirements, each DCM, SEF, and SDR must conduct
testing and review sufficient to ensure that its automated systems are
reliable, secure, and have adequate scalable capacity.\222\ The
Commission believes, as the generally accepted standards and best
practices noted in the NPRM make clear, that it is essentially
impossible for a DCM, SEF, or SDR to fulfill its current obligation to
conduct testing sufficient to ensure the reliability, security, and
capacity of its automated systems without conducting security incident
response plan testing.\223\ If compliance with the current testing
requirements as clarified by the final rules results in costs to a DCM,
SEF, or SDR beyond those it already incurs in this connection, the
Commission believes that such additional costs are attributable to
compliance with the current rules and not to the final rules.
Accordingly, the Commission believes that clarifying the rules will not
impose any new costs for DCMs, SEFs, and SDRs.
---------------------------------------------------------------------------
\222\ Commission regulations Sec. Sec. 38.1051(h) (for DCMs),
37.1401(g) (for SEFs), and 49.24(j) (for SDRs). 17 CFR 38.1051(h);
17 CFR 37.1401(g); and 17 CFR 49.24(j).
\223\ 80 FR 80139, 80174 (Dec. 23, 2015). See, e.g., NIST 800-
53A, Rev. 1, at F148, June 2010, available at http://csrc.nist.gov/publications/nistpubs/800-53A-rev1/sp800-53A-rev1-final.pdf.
---------------------------------------------------------------------------
As noted in the preamble, Tradeweb agreed that having a security
incident response plan is essential to the functioning of a SEF, but
suggested that the plan need only be reviewed annually and approved by
an individual at the SEF in charge of information security. Tradeweb
commented that requiring repeated testing of such plans is burdensome
and unduly costly. The Commission disagrees with the suggestion that
the requirement to test the security incident response plan should be
reduced to mere annual review and approval of the plan by an employee
responsible for information security. Best practices emphasize that
security incident response plan testing is crucial to effective cyber
incident response in today's cybersecurity environment.\224\ The
Commission notes that failure to practice the cyber incident response
process can delay or paralyze timely response and cause severe
consequences. While the Commission recognizes that security incident
response testing will impose costs, these costs are attributable to the
current requirements.
---------------------------------------------------------------------------
\224\ NIST SP 800-84, Guide to Test, Training, and Exercise
Programs for IT Plans and Capabilities, at 2-4 (citing NIST SP 800-
53, Rev. 4, Security and Privacy Controls for Federal Information
Systems and Organizations).
---------------------------------------------------------------------------
(b) Security Incident Response Plan Testing by Independent Contractors
or Employees of the DCM, SEF, or SDR
The NPRM called for all DCMs, SEFs, and SDRs to have security
incident response plan testing by either independent contractors or
employees not responsible for development or operation of the systems
or capabilities tested.\225\ CME suggested that the Commission permit
an independent employee responsible for incident response both design
an organization's security incident response plan and be responsible
for testing the plan. CME stated that this would allow an entity to
leverage its employees with expertise in crisis and risk management and
in incident response and planning, for both planning and testing
purposes, in a way that is optimal for the entity's system safeguards.
The Commission has considered CME's suggestion and believes that this
could provide useful benefits and flexibility to all DCMs, SEFs, and
SDRs, without impairing the purposes of the CEA and the Commission's
regulations which security incident response plan testing is designed
to advance. Accordingly, the final rules require security incident
response plan testing by all DCMs, SEFs, and SDRs to be conducted by
either independent contractors or entity employees, without restricting
which employees may lead or conduct the testing.
---------------------------------------------------------------------------
\225\ Id. at 80157.
---------------------------------------------------------------------------
(c) Security Incident Response Plan Testing Frequency Requirement for
Covered DCMs and SDRs
The final rules require covered DCMs and SDRs to conduct security
incident response plan testing at least annually. The Commission's
current rules require DCMs and SDRs to conduct regular, periodic,
objective testing of their automated systems.\226\ Accordingly, the
final rules will impose new costs relative to the requirements of the
current rules. The Commission notes that annual security incident
response plan testing is consistent with industry best practices.\227\
---------------------------------------------------------------------------
\226\ See Commission regulations Sec. Sec. 38.1051(h) (for
DCMs) and 49.24(j) (for SDRs); 17 CFR 38.1051(h); 17 CFR 49.24(j).
\227\ NIST SP 800-84, Guide to Test, Training, and Exercise
Programs for IT Plans and Capabilities, at 2-4 (citing NIST SP 800-
53, Rev. 4, Security and Privacy Controls for Federal Information
Systems and Organizations).
---------------------------------------------------------------------------
(d) Cost Estimates for Covered DCMs and SDRs
The Commission did not receive any comments addressing the costs of
conducting security incident response plan testing for covered DCMs and
SDRs. To the extent that the final rules impose additional costs on
covered DCMs and SDRs, the Commission believes that such costs may vary
widely as result of numerous factors, including the size of the
organization, the complexity of its automated systems, and the scope of
the test.\228\ Additional costs incurred by the affected entities could
include time in reviewing and revising current policies and procedures,
initially and on an ongoing basis, concerning security incident
response testing to ensure that they are sufficient in the context of
the new requirements. In such cases, the Commission believes that any
costs would be minimal.
---------------------------------------------------------------------------
\228\ Based on the Commission's experience in administering the
system safeguard compliance program, the Commission believes that
many large DCMs and SDRs currently conduct security incident
response plan testing at the minimum frequency specified in the
final rule.
---------------------------------------------------------------------------
(3) Benefits
Security incident response plans, and adequate testing of such
plans, reduce the damage caused by breaches of a DCM's, SEF's, or SDR's
network security. Network security breaches are highly likely to have a
substantial negative impact on an entity's operations. They can
increase costs through lost productivity, lost current and future
market participation or swap data reporting, compliance penalties, and
damage to the DCM's, SEF's, or SDR's reputation and brand. Moreover,
the longer a cyber intrusion continues, the more its impact may be
compounded.
The final rules provide clarity to covered DCMs and SDRs concerning
the minimum testing frequency for security incident response plans. The
Commission believes that the frequency requirement would increase the
likelihood that these entities could mitigate the duration and impact
in the event of a security incident by making them better prepared for
such an incident. Therefore, a covered DCM or SDR may also be better
positioned to reduce any potential impacts to its automated system
operation, reliability, security, or capacity; or the availability,
confidentiality, or integrity of its futures and swaps data.
k. Enterprise Technology Risk Assessment: Sec. Sec. 38.1051(h)(7),
37.1401(h)(7), and 49.24(j)(7)
(1) Summary of Final Rules
The final rules define enterprise technology risk assessment as an
assessment that includes an analysis of threats and vulnerabilities in
the context
[[Page 64305]]
of mitigating controls. In addition, the assessment identifies,
estimates, and prioritizes risks to the entity's operations or assets,
or to market participants, individuals, or other entities, resulting
from impairment of the confidentiality, integrity, and availability of
data and information or the reliability, security, or capacity of
automated systems. The final rules require covered DCMs and SDRs to
conduct an ETRA at a frequency determined by an appropriate risk
analysis, but at a minimum no less frequently than annually. The final
rules provide that all DCMs, SEFs, and SDRs may conduct ETRAs by using
independent contractors, or employees of the entity who are not
responsible for development or operation of the systems or capabilities
being assessed.
(2) Costs and Discussion of Comments
(a) ETRAs for All DCMs, SEFs, and SDRs
As stated in the NPRM and above in the Baseline discussion, the Act
requires each DCM, SEF, and SDR to develop and maintain a program of
system safeguards-related risk analysis and oversight to identify and
minimize sources of operational risk.\229\ The Act mandates that in
this connection each DCM, SEF, and SDR must develop and maintain
automated systems that are reliable, secure, and have adequate scalable
capacity, and must ensure system reliability, security, and capacity
through appropriate controls and procedures.\230\
---------------------------------------------------------------------------
\229\ 80 FR 80139, 80164, 80175 (Dec. 23, 2015). CEA section
5(d)(20) (for DCMs); CEA section 5h(f)(14) (for SEFs); CEA section
21(f)(4)(A) and 17 CFR 49.24(a) (for SDRs).
\230\ Id.
---------------------------------------------------------------------------
The Commission's current system safeguards rules for DCMs, SEFs,
and SDRs mandate that, in order to achieve these statutory
requirements, each DCM, SEF, and SDR must conduct testing and review
sufficient to ensure that its automated systems are reliable, secure,
and have adequate scalable capacity.\231\ The Commission believes, as
the generally accepted standards and best practices noted in the NPRM
make clear, that it is essentially impossible for a DCM, SEF, or SDR to
fulfill its current obligation to conduct testing sufficient to ensure
the reliability, security, and capacity of its automated systems
without conducting ETRAs.\232\ If compliance with the current testing
requirements as clarified by the final rules results in costs to a DCM,
SEF, or SDR beyond those it already incurs in this connection, the
Commission believes that such additional costs are attributable to
compliance with the current rules and not to the final rules.
Accordingly, the Commission believes that clarifying the rules will not
impose any new costs for DCMs, SEFs, and SDRs.
---------------------------------------------------------------------------
\231\ Commission regulations Sec. Sec. 38.1051(h) (for DCMs),
37.1401(g) (for SEFs), and 49.24(j) (for SDRs). 17 CFR 38.1051(h);
17 CFR 37.1401(g); and 17 CFR 49.24(j).
\232\ 80 FR 80139, 80175 (Dec. 23, 2015). See, e.g., NIST 800-
53A, Rev.1, at F226, June 2010, available at http://csrc.nist.gov/publications/nistpubs/800-53A-rev1/sp800-53A-rev1-final.pdf.
---------------------------------------------------------------------------
(b) ETRAs by Independent Contractors or Employees of the DCM, SEF, or
SDR
The Commission did not receive any comments addressing the costs of
the proposed rules which called for ETRAs to be conducted by either
independent contractors or employees not responsible for development or
operation of the systems or capabilities. The Commission is adopting
the proposed requirements and all DCMs, SEFs, and SDRs will have the
same flexibility in the final rules.
(c) ETRA Frequency Requirement for Covered DCMs and SDRs
The final rules require covered DCMs and SDRs to conduct ETRAs at
least annually. The Commission's current rules require DCMs and SDRs to
conduct regular, periodic, objective testing of their automated
systems.\233\ Therefore, the final rules will impose new costs relative
to the requirements of the current rules.\234\ CME suggested that ETRAs
would benefit from incorporating the results of controls testing and
other testing, and suggested that it would be beneficial and less
costly to align the requirement for completing an ETRA with the
applicable frequency requirement for controls testing. Tradeweb
suggested that an annual full assessment would be burdensome and
costly, and suggested that, in lieu of repeated full assessments,
annual review and approval of previous assessments should be
sufficient. The Commission believes that, as best practices provide,
regularly updated ETRAs are crucial to the effectiveness of system
safeguards in today's rapidly changing cybersecurity environment.\235\
The Commission does not accept the suggestion that ETRAs should only be
required as often as a complete cycle of controls testing is completed,
not least because the final rule is adopting the suggestion to lengthen
that cycle to three rather than two years. Because ETRAs that provide
current assessment of current risks are essential to effective programs
of system safeguards risk analysis and oversight, the Commission
disagrees with the suggestion that annual review and re-approval of
previous assessments would be sufficient. However, the Commission
believes that thorough updating of a previous assessment conducted in
compliance with the ETRA requirements set out in the NPRM can be
sufficient to fulfill the purposes of an appropriate ETRA, and can
reduce costs and burdens without impairment of the purposes of the CEA
and the system safeguards rules. Accordingly, the final rules clarify
that such updating of a previous fully compliant ETRA, in light of
current risks and circumstances, can fulfill the ETRA requirement.
---------------------------------------------------------------------------
\233\ See Commission regulations Sec. Sec. 38.1051(h) (for
DCMs) and 49.24(j) (for SDRs); 17 CFR 38.1051(h); 17 CFR 49.24(j).
\234\ Based on the information from the DMO Preliminary Survey,
the Commission understands that most large DCMs and SDRs currently
conduct ETRAs at the minimum frequency specified in the final rule.
\235\ FINRA, Report on Cybersecurity Practices (February 2015),
at 14, available at https://www.finra.org/sites/default/files/p602363%20Report%20on%20Cybersecurity%20Practices_0.pdf.
---------------------------------------------------------------------------
(d) Cost Estimates for Covered DCMs and SDRs
CME estimated that the Commission's proposed ETRA requirement would
result in an additional cost of $500,000 every two years. Based on the
information from the DMO Preliminary Survey, the current average cost
for covered DCMs and SDRs conducting the assessment is approximately
$1,347,950 annually. However, the Commission notes that actual costs
may vary widely among the affected entities due to the size of the
organization, the complexity of the automated systems, and the scope of
the assessment. The Commission recognizes that the affected entities
may undertake an evaluation, on an initial and ongoing basis, regarding
internal policies and procedures that may need to be revised. If such
an evaluation is required, the Commission believes that any incremental
costs will be minor.
(3) Benefits
The Commission believes that ETRAs are an essential component of a
comprehensive system safeguard program. ETRAs can be viewed as a
strategic approach through which DCMs, SEFs, and SDRs identify risks
and align their systems goals accordingly. The Commission believes that
these requirements are necessary to support a strong risk management
framework, thereby helping to protect DCMs, SEFs, SDRs, and market
participants, and helping to mitigate the risk of market disruptions.
The final rules provide clarity to covered DCMs and SDRs concerning
the
[[Page 64306]]
minimum assessment frequency. Best practices support annual or more
frequent assessment of technology and cybersecurity risk. For example,
FINRA states that firms conducting appropriate risk assessment do so
either annually or on an ongoing basis throughout the year, in either
case culminating in an annual risk assessment report.\236\ The
Commission believes that the frequency requirement would better
position covered DCMs and SDRs to identify, estimate, and prioritize
the risks facing them in today's cybersecurity threat environment.
---------------------------------------------------------------------------
\236\ FINRA, Report on Cybersecurity Practices (February 2015),
at 14, available at https://www.finra.org/sites/default/files/p602363%20Report%20on%20Cybersecurity%20Practices_0.pdf.
---------------------------------------------------------------------------
l. Scope for Testing and Assessment: Sec. Sec. 38.1051(k), 37.1401(k),
and 49.24(l)
(1) Summary of Final Rules
The final rules provide that the scope for all system safeguards
testing and assessment must be broad enough to include the testing of
automated systems and controls that the entity's required program of
risk analysis and oversight and its current cybersecurity threat
analysis indicate is necessary to identify risks and vulnerabilities
that could enable an intruder or unauthorized user or insider to: (1)
Interfere with the entity's operations or with fulfillment of the
entity's statutory and regulatory responsibilities; (2) impair or
degrade the reliability, security, or adequate scalable capacity of the
entity's automated systems; (3) add to, delete, augment, modify,
exfiltrate, or compromise the integrity of any data related to the
entity's regulated activities; or (4) undertake any other unauthorized
action affecting the entity's regulated activities or the hardware or
software used in connection with those activities.
(2) Costs and Benefits and Discussion of Comments
The Commission believes that the costs and benefits associated with
the scope for testing and assessment are generally attributable to the
substantive testing requirements; therefore they are generally
discussed in the cost and benefit considerations related to the rules
describing the requirements for each test or assessment. However, as
discussed in the preamble, a number of commenters suggested that the
scope provisions of the NPRM were overbroad, and that the proposed
requirement to perform ``all'' testing necessary to identify ``any''
vulnerability was impossible to achieve in practice. CME suggested that
the NPRM's overbroad scope provision could impose outsized costs
without yielding commensurate benefits. In order to provide the clarity
requested by commenters, the final rules call for the scope of system
safeguards testing to be based on appropriate risk and threat analysis.
In other words, it should include the testing that the regulatee's
program of risk analysis and oversight and its current cybersecurity
threat analysis indicate is necessary to identify risks and
vulnerabilities that could enable the deleterious actions by intruders
or unauthorized users listed in the scope provisions of the proposed
rules. The Commission agrees with the comments suggesting that this
approach avoids imposing undue burdens and costs, while supporting the
purposes of the CEA and the Commission's system safeguards rules.
m. Internal Reporting and Review: Sec. Sec. 38.1051(l), 37.1401(l),
and 49.24(m)
(1) Summary of Final Rules
The final rules require the senior management and the Board of
Directors of the DCM, SEF, or SDR to receive and review reports setting
forth the results of all testing and assessment required by the
respective sections. In addition, the final rules require the DCM, SEF,
or SDR to establish and follow appropriate procedures for the
remediation of issues identified through such review, as provided in
Sec. Sec. 38.1051(m), 37.1401(m), and 49.24(n) (Remediation), and for
evaluation of the effectiveness of testing and assessment protocols.
(2) Costs and Discussion of Comments
The final rules clarify the testing requirements by specifying and
defining certain aspects of DCM, SEF, and SDR risk analysis and
oversight programs that are necessary to fulfillment of the testing
requirements and achievement of their purposes. As stated in the NPRM,
this clarification includes review of system safeguard testing and
assessments by senior management and the DCM's, SEF's, or SDR's Board
of Directors, which is recognized as best practice for system
safeguards.\237\ The Commission believes, as the generally accepted
standards and best practices noted in the NPRM make clear, that it is
essentially impossible for a DCM, SEF, or SDR to fulfill its current
obligation to conduct testing sufficient to ensure the reliability,
security, and capacity of its automated systems without performing
appropriate internal reporting and review of test results.\238\ If
compliance with the current testing requirements as clarified by the
final rules results in costs to a DCM, SEF, or SDR beyond those it
already incurs, the Commission believes that such additional costs
would be attributable to compliance with the current regulations and
not to the final rules. Accordingly, the Commission believes that
clarifying the rules will not impose any new costs for DCMs, SEFs, and
SDRs.
---------------------------------------------------------------------------
\237\ 80 FR 80139, 80176 (Dec. 23, 2015).
\238\ See, e.g., NIST SP 800-115, Technical Guide to Information
Security Testing and Assessment, at 6-10--6-12, September 2008,
available at http://csrc.nist.gov/publications/nistpubs/800-115/SP800-115.pdf.
---------------------------------------------------------------------------
ICE, MGEX, and Nadex commented that test result reports can be
voluminous, technical, and complex, and that requiring boards and
senior management to review each such document could produce an undue
burden without commensurate benefits. As discussed in the preamble, the
Commission notes that effective board of directors and senior
management oversight of system safeguards does not require board or
senior management review of every detail of each such report. Board and
senior management review of appropriate summaries and compilations of
test and assessment results can be an effective and acceptable way of
fulfilling the internal reporting and review requirement, provided that
such summaries give board members and senior management sufficiently
detailed information to enable them to conduct effective and informed
oversight. The appropriate level of information should also enable
boards and senior management to evaluate the overall effectiveness of
testing and assessment protocols, and direct and oversee appropriate
remediation of issues identified through their review of test results.
(3) Benefits
The Commission believes that internal reporting and review are an
essential component of a comprehensive and effective system safeguard
program. While senior management and the DCM's, SEF's, or SDR's board
of directors will have to devote resources to reviewing testing and
assessment reports, active supervision by senior management and the
board of directors promotes responsibility and accountability by
affording them greater opportunity to evaluate the effectiveness of the
testing and assessment protocols. Moreover, the attention by the board
of directors and senior management should help to promote a focus on
such reviews and issues, and enhance communication and coordination
regarding such reviews and issues among the business, technology,
legal,
[[Page 64307]]
and compliance personnel of the DCM, SEF, and SDR. Active supervision
by senior management and the board of directors also promotes a more
efficient, effective, and reliable DCM and SDR risk management and
operating structure. Consequently, DCMs, SEFs, and SDRs should be
better positioned to strengthen the integrity, resiliency, and
availability of their automated systems.
n. Remediation: Sec. Sec. 38.1051(m), 37.1401(m), and 49.24(n)
(1) Summary of Final Rules
The final rules require DCMs, SEFs, and SDRs to identify and
document the vulnerabilities and deficiencies in the entity's systems
revealed by the testing and assessment in the respective sections. The
entity shall conduct and document an appropriate risk analysis of the
risks presented by such vulnerabilities and deficiencies, to determine
and document whether to remediate or accept each risk. When an entity
determines to remediate a vulnerability or deficiency, it must
remediate in a timely manner given the nature and magnitude of the
associated risk. The Commission did not receive any comments regarding
the costs and benefits of the proposed rules.
(2) Costs and Discussion of Comments
The final rules clarify the testing requirements by specifying and
defining certain aspects of DCM, SEF, and SDR risk analysis and
oversight programs that are necessary to fulfillment of the testing
requirements and achievement of their purposes. This clarification
includes remediation. As stated in the NPRM, remediation of
vulnerabilities and deficiencies revealed by cybersecurity testing is a
best practice and a fundamental purpose of such testing.\239\ The
Commission believes, as the generally accepted standards and best
practices noted in the NPRM make clear, that it is essentially
impossible for a DCM, SEF, or SDR to fulfill its current obligation to
conduct testing sufficient to ensure the reliability, security, and
capacity of its automated systems without performing remediation.\240\
If compliance with the current testing requirements as clarified by the
final rules results in costs to a DCM, SEF, or SDR beyond those it
already incurs, the Commission believes that such additional costs
would be attributable to compliance with the current regulations and
not to the final rules. Accordingly, the Commission believes that
clarifying the rules will not impose any new costs for DCMs, SEFs, and
SDRs. However, as discussed below, the Commission is amending two
aspects in the final rules where it believes the net effect will reduce
the overall costs and burdens relative to the proposed rules.
---------------------------------------------------------------------------
\239\ 80 FR 80139, 80167 (Dec. 23, 2015).
\240\ See, e.g., NIST SP 800-115, Technical Guide to Information
Security Testing and Assessment, at 6-10--6-12, September 2008,
available at http://csrc.nist.gov/publications/nistpubs/800-115/SP800-115.pdf.
---------------------------------------------------------------------------
Nadex and Tradeweb suggested that the proposed requirement to
identify and remediate ``all'' vulnerabilities and deficiencies in a
regulatee's systems was impossible to achieve in practice. Nadex
observed that other discussion in the NPRM indicated Commission intent
to require remediation of vulnerabilities and deficiencies identified
in the testing results, and suggested amending the final rule to make
this clear. Noting that remediation after a cyber attack often takes
time, Tradeweb argued that regulatees should not be penalized for that
fact, and requested Commission guidance on what constitutes timely
remediation, perhaps including specification that remediation over nine
to twelve months would be timely. As discussed in the preamble, the
Commission agrees with commenters that a requirement calling for a DCM,
SEF, or SDR to remediate all vulnerabilities and deficiencies could be
read as overbroad and impossible in practice. Accordingly, the
Commission is narrowing the remediation requirement to address
remediation or acceptance of the vulnerabilities and deficiencies of
which an entity is aware or through an appropriate program of risk
analysis and oversight should be aware, rather than the remediation of
all vulnerabilities and deficiencies. This revision is being made to
reduce burdens and costs to the extent possible without impairing the
purposes of the CEA and the Commission's system safeguards regulations.
The aspect of the final rules that could impose a slight additional
cost relative to the proposed rules is the explicit requirement that
all DCMs, SEFs, and SDRs document the vulnerabilities and deficiencies
in its systems revealed by the required testing and assessment,
document an appropriate analysis of the risks presented by such
vulnerabilities, and document its decision concerning whether to
remediate or accept each risk and the remediation steps chosen. As
stated in the preamble, the NPRM proposal to require identification of
vulnerabilities was intended to include their documentation. Effective
remediation would be impossible without documentation of both the
vulnerabilities in question and the remediation steps needed. However,
because documentation was not explicitly required in the proposal, the
Commission is treating the documentation requirement in the final rules
as a possible slight additional cost. The Commission notes, however,
that the narrowing of remediation requirement in the final rules
represents a considerable reduction in burdens and costs and will more
than offset the burdens and costs associated with the documentation
requirement.
(3) Benefits
The Commission believes that effective remediation is a critical
component of a comprehensive and effective system safeguard program.
Moreover, remediation may reduce the frequency and severity of systems
disruptions and breaches. In addition, remediation helps to ensure that
DCMs, SEFs, and SDRs dedicate appropriate resources to address system
safeguard-related deficiencies in a timely fashion. Remediation also
places an emphasis on mitigating harm to market participants while
promoting market integrity. Without a requirement for timely
remediation, the impact of vulnerabilities or deficiencies identified
by the testing or assessment could persist and have a detrimental
effect on the futures and swaps markets generally as well as market
participants.
o. Required Production of Annual Trading Volume: Sec. 38.1051(n)
(1) Summary of Final Rule
The final rule requires each DCM to provide its annual total
trading volume to the Commission for calendar year 2015 and each
calendar year thereafter. This information is required for 2015 within
30 calendar days of the effective date of the final version of this
rule, and required for 2016 and subsequent years by January 31 of the
following calendar year.
(2) Costs and Discussion of Comments
As discussed in the PRA section, the Commission did not receive any
comments concerning the accuracy of its estimate that each DCM would
spend approximately $22.00 annually to comply with the proposed
requirement. However, CME stated that the Commission should consider
alternatives to the reporting requirements in proposed Sec. 38.1051(n)
because the Commission currently receives daily trade reports regarding
volume pursuant to DCM Core Principle 8 and part 16 of the Commission's
regulations. The Commission notes that while it receives daily trade
information from DCMs pursuant to part 16, it does not receive total
annual trading volume
[[Page 64308]]
from DCMs. Additionally, the Commission believes that Core Principle 8
is inapplicable because it requires DCMs to publish daily volume, but
does not require submission of that information to the Commission. The
submission of annual trading volume is essential for the Commission to
accurately evaluate whether a particular DCM must comply with the
enhanced system safeguard requirements. The Commission believes that
all DCMs generally calculate their annual trading volume in the usual
course of business and many of the DCMs already publish this
information on their web site. The Commission also believes that each
DCM would spend approximately half an hour to prepare and file the
trading volume information with Commission at a cost of approximately
$24.80 annually.\241\
---------------------------------------------------------------------------
\241\ 80 FR 80139, 80177 (Dec. 23, 2015). In arriving at a wage
rate for the hourly costs imposed, Commission staff used the
National Industry-Specific Occupational Employment and Wage
Estimates, published in May (2015 Report). The hourly rate for a
Compliance Officer in the Securities and Commodity Exchanges as
published in the 2015 Report was $49.59 per hour. In the NPRM, the
Commission's estimate of $22.00 per respondent was based on the
hourly wage of $44.03 for a Compliance Officer in the 2014 Report.
80 FR 80139, 80163 (Dec. 23, 2015).
---------------------------------------------------------------------------
(3) Benefits
The Commission believes that it is necessary to require all DCMs to
provide the Commission with annual trading volume information.
Otherwise, the Commission would be unable to accurately evaluate
whether a particular DCM would be subject to the enhanced covered DCM
requirements. As stated in the final rule, the Commission will provide
each DCM with its percentage of the combined annual trading volume of
all DCMs regulated by the Commission for the preceding calendar year
within 60 calendar days of the effective date of the final rule, and
for subsequent years by February 28. Therefore, all DCMs will receive
certainty from the Commission regarding whether they must comply with
the provisions applicable to covered DCMs. This requirement will
support more accurate application of the final rules.
4. Section 15(a) Factors
a. Protection of Market Participants and the Public
The Commission believes that the final rules will benefit the
futures and swaps markets by promoting more robust automated systems
and therefore fewer disruptions and market-wide closures, systems
compliance issues, and systems intrusions. Fewer disruptions mean that
investors will be able to trade more predictably, reducing the
likelihood of investors facing difficulty in, for example, liquidating
positions. Because automated systems play a central and critical role
in today's electronic financial market environment, oversight of DCMs,
SEFs, and SDRs with respect to automated systems is an essential part
of effective oversight of both futures and swaps markets. In addition,
providing the Commission with reports concerning system safeguards
testing and assessments required by the rules will facilitate the
Commission's oversight of futures and swaps markets, augment the
Commission's efforts to monitor systemic risk, and will further the
protection of market participants and the public by helping to ensure
that automated systems are available, reliable, secure, have adequate
scalable capacity, and are effectively overseen. As a result, the
Commission also expects fewer interruptions to the systems that
directly support the respective entities, including matching engines,
regulatory and surveillance systems, and the dissemination of market
data, which should help ensure compliance with the relevant statutory
and regulatory obligations. Moreover, market participants will benefit
from systems that are secure and able to protect their anonymity with
respect to positions in the marketplace and other aspects of their
personally-identifiable information.
b. Efficiency, Competitiveness, and Financial Integrity of the Markets
A DCM or SEF that has system safeguard policies and procedures in
place, including the timely remediation of vulnerabilities and
deficiencies in light of appropriate risk analysis, will promote
overall market confidence and could lead to greater market efficiency,
competitiveness, and perceptions of financial integrity. Safeguarding
the reliability, security, and capacity of DCM, SEF, and SDR computer
systems is essential to mitigation of systemic risk for the nation's
financial sector as a whole. A comprehensive testing program capable of
identifying operational risks will enhance the efficiency, and
financial integrity of the markets by increasing the likelihood that
trading remains uninterrupted and transactional data and positions are
not lost.\242\ A DCM or SEF with such a program also promotes
confidence in the markets, and encourages liquidity and stability.
Moreover, the ability of a DCM or SEF to recover and resume trading
promptly in the event of a disruption of their operations, or an SDR to
recover and resume its swap data recordkeeping and reporting function,
is highly important to the U.S. economy and ensuring the resiliency of
the automated systems is a critical part of the Commission's mission.
Because SDRs hold data needed by financial regulators from multiple
jurisdictions, safeguarding such systems will also be essential to
mitigation of systemic risk world-wide. Notice to the Commission
concerning the results of system safeguard tests performed by DCMs,
SEFs, and SDRs will assist the Commission's oversight and its ability
to assess systemic risk levels. It would present unacceptable risks to
the U.S. financial system if futures and swaps markets that comprise
critical components of the world financial system, and SDRs that hold
data concerning swaps, were to become unavailable for an extended
period of time for any reason, and adequate system safeguards are
essential to the mitigation of such risks.
---------------------------------------------------------------------------
\242\ During the CFTC Roundtable, one of the participants noted
that ``if data is disclosed about activity in the markets, that is a
survivable event from a resiliency perspective, but if we don't know
who owns what and what their positions are, then there are no
markets.'' CFTC Roundtable, at 71.
---------------------------------------------------------------------------
c. Price Discovery
Any interruption in trading on a DCM or SEF can distort the price
discovery process by preventing prices from adjusting to new
information. Similarly, any interruption in the operations of an SDR
will reduce the transparency of swap prices, thereby making it more
difficult for traders to observe prices, and leading to the potential
for higher trading costs. Interruptions in SDR operations also hamper
the Commission's ability to examine potential price discrepancies and
other trading inconsistencies in the swaps market. Therefore, reliable
functioning computer systems and networks are essential in protecting
the price discovery process. The Commission believes that the final
rules will reduce the incidence and severity of automated system
security breaches and functional failures. In addition, the Commission
views the final rules as likely to facilitate the price discovery
process by mitigating the risk of operational market interruptions from
disjoining forces of supply and demand. The presence of thorough system
safeguards testing signals to the market that a DCM or SEF is a
financially sound place to trade, thus attracting greater liquidity
which leads to more accurate price discovery.
[[Page 64309]]
d. Sound Risk Management Practices
The final rules will benefit the risk management practices of both
the regulated entities and the participants who use the facilities of
those entities. Participants who use DCMs or SEFs to manage commercial
price risks should benefit from markets that behave in an orderly and
controlled fashion. If prices move in an uncontrolled fashion due to a
cybersecurity incident, those who manage risk may be forced to exit the
market as a result of unwarranted margin calls or deterioration of
their capital. In addition, those who want to enter the market to
manage risk may only be able to do so at prices that do not reflect the
actual supply and demand fundamentals due to the effects of a
cybersecurity incident. Relatedly, participants may have greater
confidence in their ability to unwind positions because market
disruptions would be less common. With respect to SDRs, the Commission
believes that the ability of participants in the swaps market to report
swap transactions to an SDR likewise serve to allow participants to
better observe swap prices, hence lowering trading costs. Fewer
interruptions of SDR operations also serve to improve regulators'
ability to monitor risk management practices through better knowledge
of open positions and SDR services related to various trade,
collateral, and risk management practices. The Commission notes
regulator access (both domestic and foreign) to the data held by an SDR
is essential for regulators to be able to monitor the swap market and
certain participants relating to systemic risk.
5. Antitrust Considerations
Section 15(b) of the CEA requires the Commission to take into
consideration the public interest to be protected by the antitrust laws
and endeavor to take the least anticompetitive means of achieving the
objectives of the CEA in issuing any order or adopting any Commission
rule or regulation. The Commission does not anticipate that the
amendments adopted herein would promote or result in anticompetitive
consequences or behavior.
IV. Compliance Dates
A. Comments Received
For final rules issued by the Commission and published in the
Federal Register, the Commission has discretion to set both the date on
which a final rule becomes effective following its publication (the
``effective date'') and the date on which it will begin enforcement of
regulatory provisions (the ``compliance date'').\243\ In setting forth
effective dates and compliance dates, the Commission considers the
nature and particular provisions of the rule in question, comments
received, available enforcement resources, and the goals and purposes
of the CEA and the rule.
---------------------------------------------------------------------------
\243\ See Heckler v. Chaney, 470 U.S. 821 (1985).
---------------------------------------------------------------------------
The Commission received comments concerning when full compliance
with the provisions of the system safeguards testing requirements rule
should be enforced for designated contract markets, swap data
repositories, and swap execution facilities. Tradeweb suggested that
the Commission specify an adequate implementation period of 9 to 12
months for the final rule, to allow regulatees sufficient time to
prepare and implement additional policies and procedures needed to
comply with the rule. CFE commented that the Commission should provide
an implementation period sufficient to allow regulatees to review the
final rules, compare them with their current testing and current risk
analysis and oversight programs, and implement any changes needed. CFE
noted that when the Securities and Exchange Commission (``SEC'')
adopted its comparable Regulation Systems Compliance and Integrity
(``Regulation SCI''), that regulation became effective 60 days after
Federal Register publication, and the SEC adopted a compliance date of
nine months after the effective date. CFE urged the Commission to take
the same approach.
The Commission has considered these comments, agrees with them, and
has determined to provide an effective date and compliance dates for
system safeguards testing effectively incorporating commenters'
suggestions, as set forth below.
The Commission notes that various aspects of the final rule require
compliance within a specified period of time, such as performance of
certain types of testing quarterly or annually. A starting point is
needed for measurement of such periods. Because cybersecurity testing
is crucial to resilience in today's cybersecurity threat environment,
the Commission believes that prudence and protection of the public
interest require starting the ``clock'' for measuring the periods
within which the various types of testing required by the final rule
must be conducted as soon as possible, by setting the earliest possible
effective date for the rule. Starting the clock in this way does not
mean that instant compliance is required; rather, the effective date
provides the starting point for measuring the implementation period
provided between the effective date and the compliance date on which a
given provision of the rule is enforceable. Within this implementation
period, a regulated entity can review the rule's requirements, compare
them with current testing and risk analysis and oversight practices,
implement any needed changes, and come into compliance with the rule.
For these reasons, the Commission has determined to set the
effective date of this final rule as the date of its publication in the
Federal Register, and to set the compliance dates applicable to the
various provisions of the final rule as set forth below.
1. For vulnerability testing, the compliance date shall be 180
calendar days after the effective date. DCMs, SEFs, and SDRs must be
conducting vulnerability testing that complies with this final rule by
that compliance date.
2. For both external and internal penetration testing, the
compliance date shall be one year after the effective date. DCMs, SEFs,
and SDRs must conduct and complete penetration testing that complies
with this final rule by that compliance date. Covered DCMs and SDRs
must engage an independent contractor to conduct and complete
penetration testing that complies with this final rule by that
compliance date.
3. For controls testing, the compliance date shall be one year
after the effective date. DCMs, SEFs, and SDRs must be conducting
controls testing that complies with this final rule by that compliance
date. Covered DCMs and SDRs must engage an independent contractor to
conduct and complete testing of all key controls within three years of
the effective date.
4. For SIRP testing, the compliance date shall be 180 days after
the effective date. DCMs, SEFs, and SDRs must have a SIRP and complete
testing of the SIRP by that compliance date.
5. For enterprise technology risk assessment, the compliance date
shall be one year after the effective date. DCMs, SEFs, and SDRs must
complete an ETRA that complies with this final rule by that compliance
date.
6. For required updating of BC-DR plans and emergency procedures,
the compliance date shall be one year after the effective date. DCMs,
SEFs, and SDRs must complete an update of their BC-DR plans and
emergency procedures by that compliance date.
7. For required production by DCMs of their annual total trading
volume, the compliance date shall be 30 calendar days after the
effective date.
[[Page 64310]]
8. For system safeguards books and records requirements, the
compliance date shall be the effective date.
9. For all other aspects of the final rule, the compliance date
shall be one year after the effective date. DCMs, SEFs, and SDRs must
be in full compliance with the final rule by that compliance date.
List of Subjects in 17 CFR Parts 37, 38, and 49
System safeguards testing requirements.
For the reasons set forth in the preamble, the Commodity Futures
Trading Commission amends 17 CFR chapter I as follows:
PART 37--SWAP EXECUTION FACILITIES
0
1. The authority citation for part 37 continues to read as follows:
Authority: 7 U.S.C. 1a, 2, 5, 6, 6c, 7, 7a-2, 7b-3, and 12a, as
amended by Titles VII and VIII of the Dodd Frank Wall Street Reform
and Consumer Protection Act, Pub. L. 111-203, 124 Stat. 1376.
0
2. Amend Sec. 37.1401 as follows:
0
a. Revise paragraphs (a) and (b);
0
b. Remove paragraph (f);
0
c. Redesignate paragraphs (c) through (e) as paragraphs (d) through
(f);
0
d. Add new paragraph (c);
0
e. Revise paragraph (g);
0
f. Redesignate paragraph (h) as paragraph (j); and
0
g. Add new paragraphs (h), (i), (k), (l), and (m).
The revisions and additions read as follows:
Sec. 37.1401 Requirements.
(a) A swap execution facility's program of risk analysis and
oversight with respect to its operations and automated systems shall
address each of the following categories of risk analysis and
oversight:
(1) Enterprise risk management and governance. This category
includes, but is not limited to: Assessment, mitigation, and monitoring
of security and technology risk; security and technology capital
planning and investment; board of directors and management oversight of
technology and security; information technology audit and controls
assessments; remediation of deficiencies; and any other elements of
enterprise risk management and governance included in generally
accepted best practices.
(2) Information security. This category includes, but is not
limited to, controls relating to: Access to systems and data (including
least privilege, separation of duties, account monitoring and control);
user and device identification and authentication; security awareness
training; audit log maintenance, monitoring, and analysis; media
protection; personnel security and screening; automated system and
communications protection (including network port control, boundary
defenses, encryption); system and information integrity (including
malware defenses, software integrity monitoring); vulnerability
management; penetration testing; security incident response and
management; and any other elements of information security included in
generally accepted best practices.
(3) Business continuity-disaster recovery planning and resources.
This category includes, but is not limited to: Regular, periodic
testing and review of business continuity-disaster recovery
capabilities, the controls and capabilities described in paragraph (c),
(d), (j), and (k) of this section; and any other elements of business
continuity-disaster recovery planning and resources included in
generally accepted best practices.
(4) Capacity and performance planning. This category includes, but
is not limited to: Controls for monitoring the swap execution
facility's systems to ensure adequate scalable capacity (including
testing, monitoring, and analysis of current and projected future
capacity and performance, and of possible capacity degradation due to
planned automated system changes); and any other elements of capacity
and performance planning included in generally accepted best practices.
(5) Systems operations. This category includes, but is not limited
to: System maintenance; configuration management (including baseline
configuration, configuration change and patch management, least
functionality, inventory of authorized and unauthorized devices and
software); event and problem response and management; and any other
elements of system operations included in generally accepted best
practices.
(6) Systems development and quality assurance. This category
includes, but is not limited to: Requirements development; pre-
production and regression testing; change management procedures and
approvals; outsourcing and vendor management; training in secure coding
practices; and any other elements of systems development and quality
assurance included in generally accepted best practices.
(7) Physical security and environmental controls. This category
includes, but is not limited to: Physical access and monitoring; power,
telecommunication, and environmental controls; fire protection; and any
other elements of physical security and environmental controls included
in generally accepted best practices.
(b) In addressing the categories of risk analysis and oversight
required under paragraph (a) of this section, a swap execution facility
shall follow generally accepted standards and best practices with
respect to the development, operation, reliability, security, and
capacity of automated systems.
(c) A swap execution facility shall maintain a business continuity-
disaster recovery plan and business continuity-disaster recovery
resources, emergency procedures, and backup facilities sufficient to
enable timely recovery and resumption of its operations and resumption
of its ongoing fulfillment of its responsibilities and obligations as a
swap execution facility following any disruption of its operations.
Such responsibilities and obligations include, without limitation:
Order processing and trade matching; transmission of matched orders to
a designated clearing organization for clearing, where appropriate;
price reporting; market surveillance; and maintenance of a
comprehensive audit trail. A swap execution facility's business
continuity-disaster recovery plan and resources generally should enable
resumption of trading and clearing of swaps executed on or pursuant to
the rules of the swap execution facility during the next business day
following the disruption. Swap execution facilities determined by the
Commission to be critical financial markets are subject to more
stringent requirements in this regard, set forth in Sec. 40.9 of this
chapter. A swap execution facility shall update its business
continuity-disaster recovery plan and emergency procedures at a
frequency determined by an appropriate risk analysis, but at a minimum
no less frequently than annually.
* * * * *
(g) As part of a swap execution facility's obligation to produce
books and records in accordance with Sec. 1.31 of this chapter, Core
Principle 10 (Recordkeeping and Reporting), and Sec. Sec. 37.1000 and
37.1001, a swap execution facility shall provide to the Commission the
following system safeguards-related books and records, promptly upon
the request of any Commission representative:
(1) Current copies of its business continuity-disaster recovery
plans and other emergency procedures;
(2) All assessments of its operational risks or system safeguards-
related controls;
[[Page 64311]]
(3) All reports concerning system safeguards testing and assessment
required by this chapter, whether performed by independent contractors
or by employees of the swap execution facility; and
(4) All other books and records requested by Commission staff in
connection with Commission oversight of system safeguards pursuant to
the Act or Commission regulations, or in connection with Commission
maintenance of a current profile of the swap execution facility's
automated systems.
(5) Nothing in Sec. 37.1401(g) shall be interpreted as reducing or
limiting in any way a swap execution facility's obligation to comply
with Core Principle 10 (Recordkeeping and Reporting) or with Sec. 1.31
of this chapter or with Sec. Sec. 37.1000 or 37.1001.
(h) A swap execution facility shall conduct regular, periodic,
objective testing and review of its automated systems to ensure that
they are reliable, secure, and have adequate scalable capacity. It
shall also conduct regular, periodic testing and review of its business
continuity-disaster recovery capabilities. Such testing and review
shall include, without limitation, all of the types of testing set
forth in paragraph (h) of this section.
(1) Definitions. As used in this paragraph (h):
Controls means the safeguards or countermeasures employed by the
swap execution facility in order to protect the reliability, security,
or capacity of its automated systems or the confidentiality, integrity,
and availability of its data and information, and in order to enable
the swap execution facility to fulfill its statutory and regulatory
responsibilities.
Controls testing means assessment of the swap execution facility's
controls to determine whether such controls are implemented correctly,
are operating as intended, and are enabling the swap execution facility
to meet the requirements established by this section.
Enterprise technology risk assessment means a written assessment
that includes, but is not limited to, an analysis of threats and
vulnerabilities in the context of mitigating controls. An enterprise
technology risk assessment identifies, estimates, and prioritizes risks
to swap execution facility operations or assets, or to market
participants, individuals, or other entities, resulting from impairment
of the confidentiality, integrity, and availability of data and
information or the reliability, security, or capacity of automated
systems.
External penetration testing means attempts to penetrate the swap
execution facility's automated systems from outside the systems'
boundaries to identify and exploit vulnerabilities. Methods of
conducting external penetration testing include, but are not limited
to, methods for circumventing the security features of an automated
system.
Internal penetration testing means attempts to penetrate the swap
execution facility's automated systems from inside the systems'
boundaries, to identify and exploit vulnerabilities. Methods of
conducting internal penetration testing include, but are not limited
to, methods for circumventing the security features of an automated
system.
Key controls means those controls that an appropriate risk analysis
determines are either critically important for effective system
safeguards or intended to address risks that evolve or change more
frequently and therefore require more frequent review to ensure their
continuing effectiveness in addressing such risks.
Security incident means a cyber security or physical security event
that actually jeopardizes or has a significant likelihood of
jeopardizing automated system operation, reliability, security, or
capacity, or the availability, confidentiality or integrity of data.
Security incident response plan means a written plan documenting
the swap execution facility's policies, controls, procedures, and
resources for identifying, responding to, mitigating, and recovering
from security incidents, and the roles and responsibilities of its
management, staff and independent contractors in responding to security
incidents. A security incident response plan may be a separate document
or a business continuity-disaster recovery plan section or appendix
dedicated to security incident response.
Security incident response plan testing means testing of a swap
execution facility's security incident response plan to determine the
plan's effectiveness, identify its potential weaknesses or
deficiencies, enable regular plan updating and improvement, and
maintain organizational preparedness and resiliency with respect to
security incidents. Methods of conducting security incident response
plan testing may include, but are not limited to, checklist completion,
walk-through or table-top exercises, simulations, and comprehensive
exercises.
Vulnerability testing means testing of a swap execution facility's
automated systems to determine what information may be discoverable
through a reconnaissance analysis of those systems and what
vulnerabilities may be present on those systems.
(2) Vulnerability testing. A swap execution facility shall conduct
vulnerability testing of a scope sufficient to satisfy the requirements
set forth in paragraph (k) of this section.
(i) A swap execution facility shall conduct such vulnerability
testing at a frequency determined by an appropriate risk analysis.
(ii) Such vulnerability testing shall include automated
vulnerability scanning, which shall follow generally accepted best
practices.
(iii) A swap execution facility shall conduct vulnerability testing
by engaging independent contractors or by using employees of the swap
execution facility who are not responsible for development or operation
of the systems or capabilities being tested.
(3) External penetration testing. A swap execution facility shall
conduct external penetration testing of a scope sufficient to satisfy
the requirements set forth in paragraph (k) of this section.
(i) A swap execution facility shall conduct such external
penetration testing at a frequency determined by an appropriate risk
analysis.
(ii) A swap execution facility shall conduct external penetration
testing by engaging independent contractors or by using employees of
the swap execution facility who are not responsible for development or
operation of the systems or capabilities being tested.
(4) Internal penetration testing. A swap execution facility shall
conduct internal penetration testing of a scope sufficient to satisfy
the requirements set forth in paragraph (k) of this section.
(i) A swap execution facility shall conduct such internal
penetration testing at a frequency determined by an appropriate risk
analysis.
(ii) A swap execution facility shall conduct internal penetration
testing by engaging independent contractors, or by using employees of
the swap execution facility who are not responsible for development or
operation of the systems or capabilities being tested.
(5) Controls testing. A swap execution facility shall conduct
controls testing of a scope sufficient to satisfy the requirements set
forth in paragraph (k) of this section.
(i) A swap execution facility shall conduct controls testing, which
includes testing of each control included in its program of risk
analysis and oversight, at a frequency determined by an appropriate
risk analysis. Such testing may be conducted on a rolling basis.
[[Page 64312]]
(ii) A swap execution facility shall conduct controls testing by
engaging independent contractors or by using employees of the swap
execution facility who are not responsible for development or operation
of the systems or capabilities being tested.
(6) Security incident response plan testing. A swap execution
facility shall conduct security incident response plan testing
sufficient to satisfy the requirements set forth in paragraph (k) of
this section.
(i) A swap execution facility shall conduct such security incident
response plan testing at a frequency determined by an appropriate risk
analysis.
(ii) A swap execution facility's security incident response plan
shall include, without limitation, the swap execution facility's
definition and classification of security incidents, its policies and
procedures for reporting security incidents and for internal and
external communication and information sharing regarding security
incidents, and the hand-off and escalation points in its security
incident response process.
(iii) A swap execution facility may coordinate its security
incident response plan testing with other testing required by this
section or with testing of its other business continuity-disaster
recovery and crisis management plans.
(iv) A swap execution facility may conduct security incident
response plan testing by engaging independent contractors or by using
employees of the swap execution facility.
(7) Enterprise technology risk assessment. A swap execution
facility shall conduct enterprise technology risk assessment of a scope
sufficient to satisfy the requirements set forth in paragraph (k) of
this section.
(i) A swap execution facility shall conduct enterprise technology
risk assessment at a frequency determined by an appropriate risk
analysis. A swap execution facility that has conducted an enterprise
technology risk assessment that complies with this section may conduct
subsequent assessments by updating the previous assessment.
(ii) A swap execution facility may conduct enterprise technology
risk assessments by using independent contractors or employees of the
swap execution facility who are not responsible for development or
operation of the systems or capabilities being assessed.
(i) To the extent practicable, a swap execution facility shall:
(1) Coordinate its business continuity-disaster recovery plan with
those of the market participants it depends upon to provide liquidity,
in a manner adequate to enable effective resumption of activity in its
markets following a disruption causing activation of the swap execution
facility's business continuity-disaster recovery plan;
(2) Initiate and coordinate periodic, synchronized testing of its
business continuity-disaster recovery plan with those of the market
participants it depends upon to provide liquidity; and
(3) Ensure that its business continuity-disaster recovery plan
takes into account the business continuity-disaster recovery plans of
its telecommunications, power, water, and other essential service
providers.
* * * * *
(k) Scope of testing and assessment. The scope for all system
safeguards testing and assessment required by this part shall be broad
enough to include the testing of automated systems and controls that
the swap execution facility's required program of risk analysis and
oversight and its current cybersecurity threat analysis indicate is
necessary to identify risks and vulnerabilities that could enable an
intruder or unauthorized user or insider to:
(1) Interfere with the swap execution facility's operations or with
fulfillment of its statutory and regulatory responsibilities;
(2) Impair or degrade the reliability, security, or adequate
scalable capacity of the swap execution facility's automated systems;
(3) Add to, delete, modify, exfiltrate, or compromise the integrity
of any data related to the swap execution facility's regulated
activities; or
(4) Undertake any other unauthorized action affecting the swap
execution facility's regulated activities or the hardware or software
used in connection with those activities.
(l) Internal reporting and review. Both the senior management and
the Board of Directors of a swap execution facility shall receive and
review reports setting forth the results of the testing and assessment
required by this section. A swap execution facility shall establish and
follow appropriate procedures for the remediation of issues identified
through such review, as provided in paragraph (m) of this section, and
for evaluation of the effectiveness of testing and assessment
protocols.
(m) Remediation. A swap execution facility shall identify and
document the vulnerabilities and deficiencies in its systems revealed
by the testing and assessment required by this section. The swap
execution facility shall conduct and document an appropriate analysis
of the risks presented by such vulnerabilities and deficiencies, to
determine and document whether to remediate or accept the associated
risk. When the swap execution facility determines to remediate a
vulnerability or deficiency, it must remediate in a timely manner given
the nature and magnitude of the associated risk.
Appendix B to Part 37 [Amended]
0
3. In appendix B to part 37, in section 2, remove and reserve Core
Principle 14 of Section 5h of the Act--System Safeguards.
PART 38--DESIGNATED CONTACT MARKETS
0
4. The authority citation for part 38 continues to read as follows:
Authority: 7 U.S.C. 1a, 2, 6, 6a, 6c, 6d, 6e, 6f, 6g, 6i, 6j,
6k, 6l, 6m, 6n, 7, 7a-2, 7b, 7b-1, 7b-3, 8, 9, 15, and 21, as
amended by the Dodd-Frank Wall Street Reform and Consumer Protection
Act, Pub. L. 111-203, 124 Stat. 1376.
0
5. In Sec. 38.1051, revise paragraphs (a), (b), (c), (g), (h), and
paragraph (i) introductory text and add paragraphs (k), (l), (m), and
(n) to read as follows:
Sec. 38.1051 General Requirements.
(a) A designated contract market's program of risk analysis and
oversight with respect to its operations and automated systems shall
address each of the following categories of risk analysis and
oversight:
(1) Enterprise risk management and governance. This category
includes, but is not limited to: Assessment, mitigation, and monitoring
of security and technology risk; security and technology capital
planning and investment; board of directors and management oversight of
technology and security; information technology audit and controls
assessments; remediation of deficiencies; and any other elements of
enterprise risk management and governance included in generally
accepted best practices.
(2) Information security. This category includes, but is not
limited to, controls relating to: Access to systems and data (including
least privilege, separation of duties, account monitoring and control);
user and device identification and authentication; security awareness
training; audit log maintenance, monitoring, and analysis; media
protection; personnel security and screening; automated system and
communications protection (including network port control, boundary
defenses, encryption); system and information integrity (including
malware defenses, software integrity monitoring); vulnerability
management;
[[Page 64313]]
penetration testing; security incident response and management; and any
other elements of information security included in generally accepted
best practices.
(3) Business continuity-disaster recovery planning and resources.
This category includes, but is not limited to: Regular, periodic
testing and review of business continuity-disaster recovery
capabilities, the controls and capabilities described in paragraphs
(c), (d), (j), and (k) of this section; and any other elements of
business continuity-disaster recovery planning and resources included
in generally accepted best practices.
(4) Capacity and performance planning. This category includes, but
is not limited to: Controls for monitoring the designated contract
market's systems to ensure adequate scalable capacity (including
testing, monitoring, and analysis of current and projected future
capacity and performance, and of possible capacity degradation due to
planned automated system changes); and any other elements of capacity
and performance planning included in generally accepted best practices.
(5) Systems operations. This category includes, but is not limited
to: System maintenance; configuration management (including baseline
configuration, configuration change and patch management, least
functionality, inventory of authorized and unauthorized devices and
software); event and problem response and management; and any other
elements of system operations included in generally accepted best
practices.
(6) Systems development and quality assurance. This category
includes, but is not limited to: Requirements development; pre-
production and regression testing; change management procedures and
approvals; outsourcing and vendor management; training in secure coding
practices; and any other elements of systems development and quality
assurance included in generally accepted best practices.
(7) Physical security and environmental controls. This category
includes, but is not limited to: Physical access and monitoring; power,
telecommunication, and environmental controls; fire protection; and any
other elements of physical security and environmental controls included
in generally accepted best practices.
(b) In addressing the categories of risk analysis and oversight
required under paragraph (a) of this section, a designated contract
market shall follow generally accepted standards and best practices
with respect to the development, operation, reliability, security, and
capacity of automated systems.
(c) A designated contract market shall maintain a business
continuity-disaster recovery plan and business continuity-disaster
recovery resources, emergency procedures, and backup facilities
sufficient to enable timely recovery and resumption of its operations
and resumption of its ongoing fulfillment of its responsibilities and
obligations as a designated contract market following any disruption of
its operations. Such responsibilities and obligations include, without
limitation: Order processing and trade matching; transmission of
matched orders to a designated clearing organization for clearing;
price reporting; market surveillance; and maintenance of a
comprehensive audit trail. The designated contract market's business
continuity-disaster recovery plan and resources generally should enable
resumption of trading and clearing of the designated contract market's
products during the next business day following the disruption.
Designated contract markets determined by the Commission to be critical
financial markets are subject to more stringent requirements in this
regard, set forth in Sec. 40.9 of this chapter. Electronic trading is
an acceptable backup for open outcry trading in the event of a
disruption. A designated contract market shall update its business
continuity-disaster recovery plan and emergency procedures at a
frequency determined by an appropriate risk analysis, but at a minimum
no less frequently than annually.
* * * * *
(g) As part of a designated contract market's obligation to produce
books and records in accordance with Sec. 1.31 of this chapter, Core
Principle 18 (Recordkeeping), and Sec. Sec. 38.950 and 38.951, a
designated contract market shall provide to the Commission the
following system safeguards-related books and records, promptly upon
the request of any Commission representative:
(1) Current copies of its business continuity-disaster recovery
plans and other emergency procedures;
(2) All assessments of its operational risks or system safeguards-
related controls;
(3) All reports concerning system safeguards testing and assessment
required by this chapter, whether performed by independent contractors
or by employees of the designated contract market; and
(4) All other books and records requested by Commission staff in
connection with Commission oversight of system safeguards pursuant to
the Act or Commission regulations, or in connection with Commission
maintenance of a current profile of the designated contract market's
automated systems.
(5) Nothing in this paragraph (g) shall be interpreted as reducing
or limiting in any way a designated contract market's obligation to
comply with Core Principle 18 (Recordkeeping) or with Sec. 1.31 of
this chapter, or with Sec. 38.950 or Sec. 38.951.
(h) A designated contract market shall conduct regular, periodic,
objective testing and review of its automated systems to ensure that
they are reliable, secure, and have adequate scalable capacity. It
shall also conduct regular, periodic testing and review of its business
continuity-disaster recovery capabilities. Such testing and review
shall include, without limitation, all of the types of testing set
forth in this paragraph (h). A covered designated contract market, as
defined in this section, shall be subject to the additional
requirements regarding minimum testing frequency and independent
contractor testing set forth in this paragraph (h).
(1) Definitions. As used in paragraph (h) of this section:
Controls means the safeguards or countermeasures employed by the
designated contract market in order to protect the reliability,
security, or capacity of its automated systems or the confidentiality,
integrity, and availability of its data and information, and in order
to enable the designated contract market to fulfill its statutory and
regulatory responsibilities.
Controls testing means assessment of the designated contract
market's controls to determine whether such controls are implemented
correctly, are operating as intended, and are enabling the designated
contract market to meet the requirements established by this section.
Covered designated contract market means a designated contract
market whose annual total trading volume in calendar year 2015, or in
any subsequent calendar year, is five percent (5%) or more of the
combined annual total trading volume of all designated contract markets
regulated by the Commission for the year in question, based on annual
total trading volume information provided to the Commission by each
designated contract market pursuant to the procedure set forth in this
chapter. A covered designated contract market that has annual total
trading volume of less than five percent (5%) of the combined annual
total trading volume of all
[[Page 64314]]
designated contract markets regulated by the Commission for three
consecutive calendar years ceases to be a covered designated contract
market as of March 1 of the calendar year following such three
consecutive calendar years.
Enterprise technology risk assessment means a written assessment
that includes, but is not limited to, an analysis of threats and
vulnerabilities in the context of mitigating controls. An enterprise
technology risk assessment identifies, estimates, and prioritizes risks
to designated contract market operations or assets, or to market
participants, individuals, or other entities, resulting from impairment
of the confidentiality, integrity, and availability of data and
information or the reliability, security, or capacity of automated
systems.
External penetration testing means attempts to penetrate the
designated contract market's automated systems from outside the
systems' boundaries to identify and exploit vulnerabilities. Methods of
conducting external penetration testing include, but are not limited
to, methods for circumventing the security features of an automated
system.
Internal penetration testing means attempts to penetrate the
designated contract market's automated systems from inside the systems'
boundaries, to identify and exploit vulnerabilities. Methods of
conducting internal penetration testing include, but are not limited
to, methods for circumventing the security features of an automated
system.
Key controls means those controls that an appropriate risk analysis
determines are either critically important for effective system
safeguards or intended to address risks that evolve or change more
frequently and therefore require more frequent review to ensure their
continuing effectiveness in addressing such risks.
Security incident means a cyber security or physical security event
that actually jeopardizes or has a significant likelihood of
jeopardizing automated system operation, reliability, security, or
capacity, or the availability, confidentiality or integrity of data.
Security incident response plan means a written plan documenting
the designated contract market's policies, controls, procedures, and
resources for identifying, responding to, mitigating, and recovering
from security incidents, and the roles and responsibilities of its
management, staff and independent contractors in responding to security
incidents. A security incident response plan may be a separate document
or a business continuity-disaster recovery plan section or appendix
dedicated to security incident response.
Security incident response plan testing means testing of a
designated contract market's security incident response plan to
determine the plan's effectiveness, identify its potential weaknesses
or deficiencies, enable regular plan updating and improvement, and
maintain organizational preparedness and resiliency with respect to
security incidents. Methods of conducting security incident response
plan testing may include, but are not limited to, checklist completion,
walk-through or table-top exercises, simulations, and comprehensive
exercises.
Vulnerability testing means testing of a designated contract
market's automated systems to determine what information may be
discoverable through a reconnaissance analysis of those systems and
what vulnerabilities may be present on those systems.
(2) Vulnerability testing. A designated contract market shall
conduct vulnerability testing of a scope sufficient to satisfy the
requirements set forth in paragraph (k) of this section.
(i) A designated contract market shall conduct such vulnerability
testing at a frequency determined by an appropriate risk analysis. At a
minimum, a covered designated contract market shall conduct such
vulnerability testing no less frequently than quarterly.
(ii) Such vulnerability testing shall include automated
vulnerability scanning, which shall follow generally accepted best
practices.
(iii) A designated contract market shall conduct vulnerability
testing by engaging independent contractors or by using employees of
the designated contract market who are not responsible for development
or operation of the systems or capabilities being tested.
(3) External penetration testing. A designated contract market
shall conduct external penetration testing of a scope sufficient to
satisfy the requirements set forth in paragraph (k) of this section.
(i) A designated contract market shall conduct such external
penetration testing at a frequency determined by an appropriate risk
analysis. At a minimum, a covered designated contract market shall
conduct such external penetration testing no less frequently than
annually.
(ii) A covered designated contract market shall engage independent
contractors to conduct the required annual external penetration test.
The covered designated contract market may conduct other external
penetration testing by using employees of the covered designated
contract market who are not responsible for development or operation of
the systems or capabilities being tested.
(iii) A designated contract market which is not a covered
designated contract market shall conduct external penetration testing
by engaging independent contractors or by using employees of the
designated contract market who are not responsible for development or
operation of the systems or capabilities being tested.
(4) Internal penetration testing. A designated contract market
shall conduct internal penetration testing of a scope sufficient to
satisfy the requirements set forth in paragraph (k) of this section.
(i) A designated contract market shall conduct such internal
penetration testing at a frequency determined by an appropriate risk
analysis. At a minimum, a covered designated contract market shall
conduct such internal penetration testing no less frequently than
annually.
(ii) A designated contract market shall conduct internal
penetration testing by engaging independent contractors, or by using
employees of the designated contract market who are not responsible for
development or operation of the systems or capabilities being tested.
(5) Controls testing. A designated contract market shall conduct
controls testing of a scope sufficient to satisfy the requirements set
forth in paragraph (k) of this section.
(i) A designated contract market shall conduct controls testing,
which includes testing of each control included in its program of risk
analysis and oversight, at a frequency determined by an appropriate
risk analysis. Such testing may be conducted on a rolling basis. At a
minimum, a covered designated contract market shall conduct testing of
its key controls no less frequently than every three years. The covered
designated contract market may conduct testing of its key controls on a
rolling basis over the course of three years or the period determined
by such risk analysis, whichever is shorter.
(ii) A covered designated contract market shall engage independent
contractors to test and assess the key controls included in its program
of risk analysis and oversight no less frequently than every three
years. The covered designated contract market may conduct any other
controls testing required by this section by using independent
contractors or employees of the covered designated contract market who
are not responsible for development or
[[Page 64315]]
operation of the systems or capabilities being tested.
(iii) A designated contract market which is not a covered
designated contract market shall conduct controls testing by engaging
independent contractors or by using employees of the designated
contract market who are not responsible for development or operation of
the systems or capabilities being tested.
(6) Security incident response plan testing. A designated contract
market shall conduct security incident response plan testing sufficient
to satisfy the requirements set forth in paragraph (k) of this section.
(i) A designated contract market shall conduct such security
incident response plan testing at a frequency determined by an
appropriate risk analysis. At a minimum, a covered designated contract
market shall conduct such security incident response plan testing no
less frequently than annually.
(ii) A designated contract market's security incident response plan
shall include, without limitation, the designated contract market's
definition and classification of security incidents, its policies and
procedures for reporting security incidents and for internal and
external communication and information sharing regarding security
incidents, and the hand-off and escalation points in its security
incident response process.
(iii) A designated contract market may coordinate its security
incident response plan testing with other testing required by this
section or with testing of its other business continuity-disaster
recovery and crisis management plans.
(iv) A designated contract market may conduct security incident
response plan testing by engaging independent contractors or by using
employees of the designated contract market.
(7) Enterprise technology risk assessment. A designated contract
market shall conduct enterprise technology risk assessment of a scope
sufficient to satisfy the requirements set forth in paragraph (k) of
this section.
(i) A designated contract market shall conduct an enterprise
technology risk assessment at a frequency determined by an appropriate
risk analysis. At a minimum, a covered designated contract market shall
conduct an enterprise technology risk assessment no less frequently
than annually. A designated contract market that has conducted an
enterprise technology risk assessment that complies with this section
may conduct subsequent assessments by updating the previous assessment.
(ii) A designated contract market may conduct enterprise technology
risk assessments by using independent contractors or employees of the
designated contract market who are not responsible for development or
operation of the systems or capabilities being assessed.
(i) To the extent practicable, a designated contract market shall:
* * * * *
(k) Scope of testing and assessment. The scope for all system
safeguards testing and assessment required by this part shall be broad
enough to include the testing of automated systems and controls that
the designated contract market's required program of risk analysis and
oversight and its current cybersecurity threat analysis indicate is
necessary to identify risks and vulnerabilities that could enable an
intruder or unauthorized user or insider to:
(1) Interfere with the designated contract market's operations or
with fulfillment of its statutory and regulatory responsibilities;
(2) Impair or degrade the reliability, security, or adequate
scalable capacity of the designated contract market's automated
systems;
(3) Add to, delete, modify, exfiltrate, or compromise the integrity
of any data related to the designated contract market's regulated
activities; or
(4) Undertake any other unauthorized action affecting the
designated contract market's regulated activities or the hardware or
software used in connection with those activities.
(l) Internal reporting and review. Both the senior management and
the Board of Directors of a designated contract market shall receive
and review reports setting forth the results of the testing and
assessment required by this section. A designated contract market shall
establish and follow appropriate procedures for the remediation of
issues identified through such review, as provided in paragraph (m) of
this section, and for evaluation of the effectiveness of testing and
assessment protocols.
(m) Remediation. A designated contract market shall identify and
document the vulnerabilities and deficiencies in its systems revealed
by the testing and assessment required by this section. The designated
contract market shall conduct and document an appropriate analysis of
the risks presented by such vulnerabilities and deficiencies, to
determine and document whether to remediate or accept the associated
risk. When the designated contract market determines to remediate a
vulnerability or deficiency, it must remediate in a timely manner given
the nature and magnitude of the associated risk.
(n) Required production of annual total trading volume. (1) As used
in this paragraph, annual total trading volume means the total number
of all contracts traded on or pursuant to the rules of a designated
contract market during a calendar year.
(2) Each designated contract market shall provide to the Commission
for calendar year 2015 and each calendar year thereafter its annual
total trading volume, providing this information for 2015 within 30
calendar days of the effective date of the final version of this rule,
and for 2016 and subsequent years by January 31 of the following
calendar year. For calendar year 2015 and each calendar year
thereafter, the Commission shall provide to each designated contract
market the percentage of the combined annual total trading volume of
all designated contract markets regulated by the Commission which is
constituted by that designated contract market's annual total trading
volume, providing this information for 2015 within 60 calendar days of
the effective date of the final version of this rule, and for 2016 and
subsequent years by February 28 of the following calendar year.
PART 49--SWAP DATA REPOSITORIES
0
6. The authority citation for part 49 continues to read as follows:
Authority: 7 U.S.C. 12a and 24a, as amended by Title VII of the
Wall Street Reform and Consumer Protection Act, Pub. L. No. 111-203,
124 Stat. 1376 (2010), unless otherwise noted.
0
7. In Sec. 49.24, revise paragraphs (b), (c), (d), (i), (j), and
paragraph (k) introductory text and add paragraphs (l), (m), and (n) to
read as follows:
Sec. 49.24 System Safeguards.
* * * * *
(b) A swap data repository's program of risk analysis and oversight
with respect to its operations and automated systems shall address each
of the following categories of risk analysis and oversight:
(1) Enterprise risk management and governance. This category
includes, but is not limited to: Assessment, mitigation, and monitoring
of security and technology risk; security and technology capital
planning and investment; board of directors and management oversight of
technology and security; information technology audit and controls
assessments;
[[Page 64316]]
remediation of deficiencies; and any other elements of enterprise risk
management and governance included in generally accepted best
practices.
(2) Information security. This category includes, but is not
limited to, controls relating to: Access to systems and data (including
least privilege, separation of duties, account monitoring and control);
user and device identification and authentication; security awareness
training; audit log maintenance, monitoring, and analysis; media
protection; personnel security and screening; automated system and
communications protection (including network port control, boundary
defenses, encryption); system and information integrity (including
malware defenses, software integrity monitoring); vulnerability
management; penetration testing; security incident response and
management; and any other elements of information security included in
generally accepted best practices.
(3) Business continuity-disaster recovery planning and resources.
This category includes, but is not limited to: Regular, periodic
testing and review of business continuity-disaster recovery
capabilities, the controls and capabilities described in paragraph (a),
(d), (e), (f), and (k) of this section; and any other elements of
business continuity-disaster recovery planning and resources included
in generally accepted best practices.
(4) Capacity and performance planning. This category includes, but
is not limited to: Controls for monitoring the swap data repository's
systems to ensure adequate scalable capacity (including testing,
monitoring, and analysis of current and projected future capacity and
performance, and of possible capacity degradation due to planned
automated system changes); and any other elements of capacity and
performance planning included in generally accepted best practices.
(5) Systems operations. This category includes, but is not limited
to: System maintenance; configuration management (including baseline
configuration, configuration change and patch management, least
functionality, inventory of authorized and unauthorized devices and
software); event and problem response and management; and any other
elements of system operations included in generally accepted best
practices.
(6) Systems development and quality assurance. This category
includes, but is not limited to: Requirements development; pre-
production and regression testing; change management procedures and
approvals; outsourcing and vendor management; training in secure coding
practices; and any other elements of systems development and quality
assurance included in generally accepted best practices.
(7) Physical security and environmental controls. This category
includes, but is not limited to: Physical access and monitoring; power,
telecommunication, and environmental controls; fire protection; and any
other elements of physical security and environmental controls included
in generally accepted best practices.
(c) In addressing the categories of risk analysis and oversight
required under paragraph (b) of this section, a swap data repository
shall follow generally accepted standards and best practices with
respect to the development, operation, reliability, security, and
capacity of automated systems.
(d) A swap data repository shall maintain a business continuity-
disaster recovery plan and business continuity-disaster recovery
resources, emergency procedures, and backup facilities sufficient to
enable timely recovery and resumption of its operations and resumption
of its ongoing fulfillment of its duties and obligations as a swap data
repository following any disruption of its operations. Such duties and
obligations include, without limitation: The duties set forth in Sec.
49.19, and maintenance of a comprehensive audit trail. The swap data
repository's business continuity-disaster recovery plan and resources
generally should enable resumption of the swap data repository's
operations and resumption of ongoing fulfillment of the swap data
repository's duties and obligations during the next business day
following the disruption. A swap data repository shall update its
business continuity-disaster recovery plan and emergency procedures at
a frequency determined by an appropriate risk analysis, but at a
minimum no less frequently than annually.
* * * * *
(i) As part of a swap data repository's obligation to produce books
and records in accordance with Sec. Sec. 1.31 and 45.2 of this
chapter, and Sec. 49.12, a swap data repository shall provide to the
Commission the following system safeguards-related books and records,
promptly upon the request of any Commission representative:
(1) Current copies of its business continuity-disaster recovery
plans and other emergency procedures;
(2) All assessments of its operational risks or system safeguards-
related controls;
(3) All reports concerning system safeguards testing and assessment
required by this chapter, whether performed by independent contractors
or by employees of the swap data repository; and
(4) All other books and records requested by Commission staff in
connection with Commission oversight of system safeguards pursuant to
the Act or Commission regulations, or in connection with Commission
maintenance of a current profile of the swap data repository's
automated systems.
(5) Nothing in paragraph (i) of this section shall be interpreted
as reducing or limiting in any way a swap data repository's obligation
to comply with Sec. Sec. 1.31 and 45.2 of this chapter, or with Sec.
49.12.
(j) A swap data repository shall conduct regular, periodic,
objective testing and review of its automated systems to ensure that
they are reliable, secure, and have adequate scalable capacity. It
shall also conduct regular, periodic testing and review of its business
continuity-disaster recovery capabilities. Such testing and review
shall include, without limitation, all of the types of testing set
forth in this paragraph.
(1) Definitions. As used in this paragraph (j):
Controls means the safeguards or countermeasures employed by the
swap data repository in order to protect the reliability, security, or
capacity of its automated systems or the confidentiality, integrity,
and availability of its data and information, and in order to enable
the swap data repository to fulfill its statutory and regulatory duties
and responsibilities.
Controls testing means assessment of the swap data repository's
controls to determine whether such controls are implemented correctly,
are operating as intended, and are enabling the swap data repository to
meet the requirements established by this section.
Enterprise technology risk assessment means a written assessment
that includes, but is not limited to, an analysis of threats and
vulnerabilities in the context of mitigating controls. An enterprise
technology risk assessment identifies, estimates, and prioritizes risks
to swap data repository operations or assets, or to market
participants, individuals, or other entities, resulting from impairment
of the confidentiality, integrity, and availability of data and
information or the reliability, security, or capacity of automated
systems.
External penetration testing means attempts to penetrate the swap
data repository's automated systems from outside the systems'
boundaries to identify and exploit vulnerabilities.
[[Page 64317]]
Methods of conducting external penetration testing include, but are not
limited to, methods for circumventing the security features of an
automated system.
Internal penetration testing means attempts to penetrate the swap
data repository's automated systems from inside the systems'
boundaries, to identify and exploit vulnerabilities. Methods of
conducting internal penetration testing include, but are not limited
to, methods for circumventing the security features of an automated
system.
Key controls means those controls that an appropriate risk analysis
determines are either critically important for effective system
safeguards or intended to address risks that evolve or change more
frequently and therefore require more frequent review to ensure their
continuing effectiveness in addressing such risks.
Security incident means a cyber security or physical security event
that actually jeopardizes or has a significant likelihood of
jeopardizing automated system operation, reliability, security, or
capacity, or the availability, confidentiality or integrity of data.
Security incident response plan means a written plan documenting
the swap data repository's policies, controls, procedures, and
resources for identifying, responding to, mitigating, and recovering
from security incidents, and the roles and responsibilities of its
management, staff and independent contractors in responding to security
incidents. A security incident response plan may be a separate document
or a business continuity-disaster recovery plan section or appendix
dedicated to security incident response.
Security incident response plan testing means testing of a swap
data repository's security incident response plan to determine the
plan's effectiveness, identify its potential weaknesses or
deficiencies, enable regular plan updating and improvement, and
maintain organizational preparedness and resiliency with respect to
security incidents. Methods of conducting security incident response
plan testing may include, but are not limited to, checklist completion,
walk-through or table-top exercises, simulations, and comprehensive
exercises.
Vulnerability testing means testing of a swap data repository's
automated systems to determine what information may be discoverable
through a reconnaissance analysis of those systems and what
vulnerabilities may be present on those systems.
(2) Vulnerability testing. A swap data repository shall conduct
vulnerability testing of a scope sufficient to satisfy the requirements
set forth in paragraph (l) of this section.
(i) A swap data repository shall conduct such vulnerability testing
at a frequency determined by an appropriate risk analysis, but no less
frequently than quarterly.
(ii) Such vulnerability testing shall include automated
vulnerability scanning, which shall follow generally accepted best
practices.
(iii) A swap data repository shall conduct vulnerability testing by
engaging independent contractors or by using employees of the swap data
repository who are not responsible for development or operation of the
systems or capabilities being tested.
(3) External penetration testing. A swap data repository shall
conduct external penetration testing of a scope sufficient to satisfy
the requirements set forth in paragraph (l) of this section.
(i) A swap data repository shall conduct such external penetration
testing at a frequency determined by an appropriate risk analysis, but
no less frequently than annually.
(ii) A swap data repository shall engage independent contractors to
conduct the required annual external penetration test. The swap data
repository may conduct other external penetration testing by using
employees of the swap data repository who are not responsible for
development or operation of the systems or capabilities being tested.
(4) Internal penetration testing. A swap data repository shall
conduct internal penetration testing of a scope sufficient to satisfy
the requirements set forth in paragraph (l) of this section.
(i) A swap data repository shall conduct such internal penetration
testing at a frequency determined by an appropriate risk analysis, but
no less frequently than annually.
(ii) A swap data repository shall conduct internal penetration
testing by engaging independent contractors, or by using employees of
the swap data repository who are not responsible for development or
operation of the systems or capabilities being tested.
(5) Controls testing. A swap data repository shall conduct controls
testing of a scope sufficient to satisfy the requirements set forth in
paragraph (l) of this section.
(i) A swap data repository shall conduct controls testing, which
includes testing of each control included in its program of risk
analysis and oversight, at a frequency determined by an appropriate
risk analysis. Such testing may be conducted on a rolling basis. A swap
data repository shall conduct testing of its key controls no less
frequently than every three years. The swap data repository may conduct
testing of its key controls on a rolling basis over the course of three
years or the period determined by such risk analysis, whichever is
shorter.
(ii) A swap data repository shall engage independent contractors to
test and assess the key controls included in its program of risk
analysis and oversight no less frequently than every three years. The
swap data repository may conduct any other controls testing required by
this section by using independent contractors or employees of the swap
data repository who are not responsible for development or operation of
the systems or capabilities being tested.
(6) Security incident response plan testing. A swap data repository
shall conduct security incident response plan testing sufficient to
satisfy the requirements set forth in paragraph (l) of this section.
(i) A swap data repository shall conduct such security incident
response plan testing at a frequency determined by an appropriate risk
analysis, but no less frequently than annually.
(ii) A swap data repository's security incident response plan shall
include, without limitation, the swap data repository's definition and
classification of security incidents, its policies and procedures for
reporting security incidents and for internal and external
communication and information sharing regarding security incidents, and
the hand-off and escalation points in its security incident response
process.
(iii) A swap data repository may coordinate its security incident
response plan testing with other testing required by this section or
with testing of its other business continuity-disaster recovery and
crisis management plans.
(iv) A swap data repository may conduct security incident response
plan testing by engaging independent contractors or by using employees
of the swap data repository.
(7) Enterprise technology risk assessment. A swap data repository
shall conduct enterprise technology risk assessment of a scope
sufficient to satisfy the requirements set forth in paragraph (l) of
this section.
(i) A swap data repository shall conduct an enterprise technology
risk assessment at a frequency determined by an appropriate risk
analysis, but no less frequently than annually. A swap data repository
that has conducted an enterprise technology risk assessment
[[Page 64318]]
that complies with this section may conduct subsequent assessments by
updating the previous assessment.
(ii) A swap data repository may conduct enterprise technology risk
assessments by using independent contractors or employees of the swap
data repository who are not responsible for development or operation of
the systems or capabilities being assessed.
(k) To the extent practicable, a swap data repository shall:
* * * * *
(l) Scope of testing and assessment. The scope for all system
safeguards testing and assessment required by this part shall be broad
enough to include the testing of automated systems and controls that
the swap data repository's required program of risk analysis and
oversight and its current cybersecurity threat analysis indicate is
necessary to identify risks and vulnerabilities that could enable an
intruder or unauthorized user or insider to:
(1) Interfere with the swap data repository's operations or with
fulfillment of its statutory and regulatory responsibilities;
(2) Impair or degrade the reliability, security, or adequate
scalable capacity of the swap data repository's automated systems;
(3) Add to, delete, modify, exfiltrate, or compromise the integrity
of any data related to the swap data repository's regulated activities;
or
(4) Undertake any other unauthorized action affecting the swap data
repository's regulated activities or the hardware or software used in
connection with those activities.
(m) Internal reporting and review. Both the senior management and
the Board of Directors of a swap data repository shall receive and
review reports setting forth the results of the testing and assessment
required by this section. A swap data repository shall establish and
follow appropriate procedures for the remediation of issues identified
through such review, as provided in paragraph (n) of this section, and
for evaluation of the effectiveness of testing and assessment
protocols.
(n) Remediation. A swap data repository shall identify and document
the vulnerabilities and deficiencies in its systems revealed by the
testing and assessment required by this section. The swap data
repository shall conduct and document an appropriate analysis of the
risks presented by such vulnerabilities and deficiencies, to determine
and document whether to remediate or accept the associated risk. When
the swap data repository determines to remediate a vulnerability or
deficiency, it must remediate in a timely manner given the nature and
magnitude of the associated risk.
Issued in Washington, DC, on September 9, 2016, by the
Commission.
Christopher J. Kirkpatrick,
Secretary of the Commission.
Note: The following appendices will not appear in the Code of
Federal Regulations.
Appendices to System Safeguards Testing Requirements--Commission Voting
Summary, Chairman's Statement, and Commissioner's Statement
Appendix 1--Commission Voting Summary
On this matter, Chairman Massad and Commissioners Bowen and
Giancarlo voted in the affirmative. No Commissioner voted in the
negative.
Appendix 2--Statement of Chairman Timothy G. Massad
I strongly support the two rules the Commission has finalized
today.
The risk of cyberattack probably represents the single greatest
threat to the stability and integrity of our markets today.
Instances of cyberattacks are all too familiar both inside and
outside the financial sector. Today, they often are motivated not
just by those with a desire to profit, but by those with a desire
deliberately to disrupt or destabilize orderly operations.
That is why these system safeguard rules are so important. The
rules we have finalized today will apply to the core infrastructure
in our markets--the exchanges, clearinghouses, trading platforms,
and trade repositories. And they will ensure that those private
companies are regularly evaluating cyber risks and testing their
cybersecurity and operational risk defenses. While our rules already
require this generally, the measures we approved today add greater
definition--not by being overly prescriptive, but by setting some
principles-based standards, and requiring specific types of testing,
all rooted in industry best practices.
I've said many times that as regulators, we must not just look
backwards to address the causes of past failures or crises. We also
must look ahead--ahead to the new opportunities and challenges
facing our markets. Financial markets constantly evolve, and we must
ensure our regulatory framework is adapting to these changes.
These new rules are one good example of how we are looking ahead
and addressing these new challenges. They will serve as a strong and
important complement to the many other steps being taken by
regulators and market participants to address cybersecurity. For
example, government agencies and market participants are already
working together to share information about potential threats and
risks--and learn from one another.
I want to thank all those who provided feedback on the proposed
rules the Commission approved last December. We received a number of
thoughtful comments from market participants, most of which
expressed broad support for the proposals. Commenters also
highlighted some areas of concern, and we made adjustments based on
that feedback. For example, we have reduced the frequency of
controls testing and narrowed the instances where independent
contractor testing is required. We have also clarified definitions
of key terms, and made clear that the scope of required testing will
be based on appropriate risk and threat analysis.
I also thank Commission staff for their hard work on these
measures, particularly our staff in the Division of Market Oversight
and Division of Clearing and Risk, as well as the support that is
always provided by staff in the Office of General Counsel, the
Office of Chief Economist and other staff who comment on the rules.
I also thank my fellow Commissioners Bowen and Giancarlo for their
support of and suggestions regarding these final rules.
Appendix 3--Concurring Statement of Commissioner Sharon Y. Bowen
I will be voting yes on both systems safeguards rules. There is
not much more to say than what I said when these rules were proposed
on December 10, 2015.\1\ Cybersecurity is a top concern for American
companies, especially financial firms. These rules are a good step
forward in addressing these concerns.
---------------------------------------------------------------------------
\1\ Concurring Statement of Commissioner Sharon Y. Bowen
Regarding Notice of Proposed Rulemaking on System Safeguards Testing
Requirements (Dec. 10, 2015), available at http://www.cftc.gov/PressRoom/SpeechesTestimony/bowenstatement121615b.
---------------------------------------------------------------------------
As I noted when they were proposed, there are many aspects of
these proposals that I like:
First, they set up a comprehensive testing regime by: (a)
Defining the types of cybersecurity testing essential to fulfilling
system safeguards testing obligations, including vulnerability
testing, penetration testing, controls testing, security incident
response plan testing, and enterprise technology risk assessment;
(b) requiring internal reporting and review of testing results; and
(c) mandating remediation of vulnerabilities and deficiencies.
Further, for certain significant entities, based on trading volume,
it requires heightened measures such as minimum frequency
requirements for conducting certain testing, and specific
requirements for the use of independent contractors.
Second, there is a focus on governance--requiring, for instance,
that firms' Board of Directors receive and review all reports
setting forth the results of all testing. And third, these
rulemakings are largely based on well-regarded, accepted best
practices for cybersecurity, including The National Institute of
Standards and Technology Framework for Improving Critical
[[Page 64319]]
Infrastructure Cybersecurity (``NIST Framework'').\2\
---------------------------------------------------------------------------
\2\ Id. See also NIST Framework, Subcategory PR.IP-10, at 28,
and Category DE.DP, at 31, available at http://www.nist.gov/cyberframework/upload/cybersecurity-framework-021214.pdf.
---------------------------------------------------------------------------
I was also an early proponent of including all registered
entities, including SEFs, in this rule. I am glad to see them
included, and look forward to the staff roundtable to discuss how to
apply heightened standards to the significant SEFs. Thank you and I
look forward to the staff's presentation.
[FR Doc. 2016-22174 Filed 9-16-16; 8:45 am]
BILLING CODE 6351-01-P
Last Updated: September 19, 2016