[ad_1]
[Federal Register Volume 80, Number 246 (Wednesday, December 23, 2015)]
[Proposed Rules]
[Pages 80113-80138]
From the Federal Register Online via the Government Publishing Office [www.gpo.gov]
[FR Doc No: 2015-32144]
[[Page 80113]]
Vol. 80
Wednesday,
No. 246
December 23, 2015
Part IV
Commodity Futures Trading Commission
———————————————————————–
17 CFR Part 39
System Safeguards Testing Requirements for Derivatives Clearing
Organizations; Proposed Rule
Federal Register / Vol. 80 , No. 246 / Wednesday, December 23, 2015 /
Proposed Rules
[[Page 80114]]
———————————————————————–
COMMODITY FUTURES TRADING COMMISSION
17 CFR Part 39
RIN 3038-AE29
System Safeguards Testing Requirements for Derivatives Clearing
Organizations
AGENCY: Commodity Futures Trading Commission.
ACTION: Notice of proposed rulemaking.
———————————————————————–
SUMMARY: The Commodity Futures Trading Commission (“Commission”) is
proposing enhanced requirements for a derivatives clearing
organization’s testing of its system safeguards, as well as additional
amendments to reorder and renumber certain paragraphs within the
regulations and make other minor changes to improve the clarity of the
rule text.
DATES: Comments must be received by February 22, 2016.
ADDRESSES: You may submit comments, identified by RIN 3038-AE29, by any
of the following methods:
CFTC Web site: http://comments.cftc.gov. Follow the
instructions for submitting comments through the Comments Online
process on the Web site.
Mail: Send to Christopher Kirkpatrick, Secretary of the
Commission, Commodity Futures Trading Commission, Three Lafayette
Centre, 1155 21st Street NW., Washington, DC 20581.
Hand Delivery/Courier: Same as Mail, above.
Federal eRulemaking Portal: http://www.regulations.gov.
Follow the instructions for submitting comments.
Please submit your comments using only one method. All comments
must be submitted in English, or if not, accompanied by an English
translation. Comments will be posted as received to http://www.cftc.gov. You should submit only information that you wish to make
available publicly. If you wish the Commission to consider information
that may be exempt from disclosure under the Freedom of Information
Act, a petition for confidential treatment of the exempt information
may be submitted under Sec. 145.9 of the Commission’s regulations (17
CFR 145.9).
The Commission reserves the right, but shall have no obligation, to
review, pre-screen, filter, redact, refuse or remove any or all of your
submission from http://www.cftc.gov that it may deem to be
inappropriate for publication, such as obscene language. All
submissions that have been redacted or removed that contain comments on
the merits of the rulemaking will be retained in the public comment
file and will be considered as required under the Administrative
Procedure Act and other applicable laws, and may be accessible under
the Freedom of Information Act.
FOR FURTHER INFORMATION CONTACT: Eileen A. Donovan, Deputy Director,
202-418-5096, [email protected]; M. Laura Astrada, Associate Director,
202-418-7622, [email protected]; or Eileen Chotiner, Senior Compliance
Analyst, (202) 418-5467, [email protected], in each case, at the
Division of Clearing and Risk, Commodity Futures Trading Commission,
Three Lafayette Centre, 1155 21st Street NW., Washington, DC 20581; or
Julie A. Mohr, Deputy Director, (312) 596-0568, [email protected]; or
Joseph Opron, Special Counsel, (312) 596-0653, [email protected], in each
case, at the Division of Clearing and Risk, Commodity Futures Trading
Commission, 525 West Monroe Street, Chicago, Illinois 60661.
SUPPLEMENTARY INFORMATION:
I. Background
A. System Safeguards Requirements for DCOs
Section 5b(c)(2) of the Commodity Exchange Act (“CEA”) 1 sets
forth core principles with which a derivatives clearing organization
(“DCO”) must comply in order to be registered and to maintain
registration with the Commission. In November 2011, the Commission
adopted regulations 2 to establish standards for compliance with the
core principles, including Core Principle I, which concerns a DCO’s
system safeguards.3 In 2013, the Commission adopted additional
standards for compliance with the core principles for systemically
important DCOs (“SIDCOs”) and DCOs that elect to opt-in to the SIDCO
regulatory requirements (“Subpart C DCOs”).
—————————————————————————
1 7 U.S.C. 7a-1.
2 Derivatives Clearing Organization General Provisions and
Core Principles, 76 FR 69334 (Nov. 8, 2011) (codified at 17 CFR part
39).
3 Core Principle I requires a DCO to: (1) Establish and
maintain a program of risk analysis and oversight to identify and
minimize sources of operational risk; (2) establish and maintain
emergency procedures, backup facilities, and a plan for disaster
recovery that allows for the timely recovery and resumption of the
DCO’s operations and the fulfillment of each of its obligations and
responsibilities; and (3) periodically conduct tests to verify that
the DCO’s backup resources are sufficient.
—————————————————————————
Regulation 39.18 implements Core Principle I and, among other
things, specifies: (1) The requisite elements, standards, and resources
of a DCO’s program of risk analysis and oversight with respect to its
operations and automated systems; (2) the requirements for a DCO’s
business continuity and disaster recovery plan, emergency procedures,
and physical, technological, and personnel resources described therein;
(3) the responsibilities, obligations, and recovery time objective of a
DCO following a disruption of its operations; and (4) other system
safeguards requirements related to reporting, recordkeeping, testing,
and coordination with a DCO’s clearing members and service providers.
As discussed below, the Commission is proposing clarifications and
enhanced requirements for a DCO’s testing of its system safeguards, as
well as additional amendments to reorder and renumber certain
paragraphs and make other minor changes to improve the clarity of the
rule text. The Commission is also proposing corresponding technical
corrections to Sec. 39.34.
B. Escalating and Evolving Cybersecurity Threats
Recent studies have identified a consistent, growing cybersecurity
threat to the financial sector. A survey of 46 global securities
exchanges conducted by the International Organization of Securities
Commissions (“IOSCO”) and the World Federation of Exchanges (“WFE”)
found that as of July 2013, over half of exchanges worldwide had
experienced a cyber attack during the previous year.4 Indeed,
cybersecurity now ranks as the number one concern for nearly half of
financial institutions in the United States.5 Further, the sheer
volume of cyber attacks today is remarkable. The annual Pricewaterhouse
Coopers Global State of Information Security Survey (“PWC Survey”)
for 2015, which included 9,700 participants, found that the total
number of security incidents detected in 2014 increased by 48% over
2013, for a total of 42.8 million incoming attacks, the equivalent of
more than 117,000 attacks per day, every day.6 As the PWC Survey
pointed out, these numbers do not include undetected attacks. Verizon’s
2015 Data Breach Investigations Report noted that during
[[Page 80115]]
2014, the financial services sector experienced an average of 350
malware attacks per week.7
—————————————————————————
4 OICV-IOSCO and WFE, Cyber-crime, securities markets and
systemic risk, Staff Working Paper (SWP2/2013), July 16, 2013
(“IOSCO-WFE Staff Report”), p. 3, available at: https://www.iosco.org/library/pubdocs/pdf/IOSCOPD460.pdf.
5 Depository Trust & Clearing Corporation, Systemic Risk
Barometer Study, Q1 2015, p. 1, available at: http://dtcc.com/~/
media/Files/pdfs/Systemic-Risk-Report-2015-Q1.pdf.
6 Pricewaterhouse Coopers, Managing Cyber Risks in an
Interconnected World: Key Findings from the Global State of
Information Security Survey 2015, Sept. 30, 2014, p. 7, available
at: www.pwc.com/gsiss2015.
7 Verizon, 2015 Data Breach Investigations Report, p. 21,
available at: http://www.verizonenterprise.com/DBIR/2015/.
—————————————————————————
Concerned about these developments, in March 2015, Commission staff
held a Roundtable on Cybersecurity and System Safeguards Testing
(“CFTC Roundtable”) to, among other things, discuss the issue and
identify critical areas of concern.8 Similarly, a June 2015 Market
Risk Advisory Committee (“MRAC”) meeting focused on cybersecurity.
Commissioner Sharon Bowen, the sponsor of MRAC, noted that cyber
attacks on U.S. businesses have been “alarmingly increasing” and
stated that “it’s critical that the financial industry have strong
protections in place.” 9
—————————————————————————
8 See generally CFTC Staff Roundtable on Cybersecurity and
System Safeguards Testing, Transcript, Mar. 18, 2015 (“CFTC
Roundtable”), pp. 11-91, available at: http://www.cftc.gov/ucm/groups/public/@newsroom/documents/file/transcript031815.pdf.
9 See Market Risk Advisory Committee Meeting, Transcript, June
2, 2015, p. 6, available at: http://www.cftc.gov/ucm/groups/public/@aboutcftc/documents/file/mrac_060215_transcript.pdf.
—————————————————————————
Experts have identified a number of important topics surrounding
cybersecurity that financial institutions should take into
consideration. First, the financial sector is facing increasing numbers
of more dangerous cyber adversaries, with expanding and worsening
motivations and goals.10 Until recently, most cyber attacks on
financial sector institutions were conducted by criminals whose aim was
monetary theft or fraud.11 While such attacks continue, recently
there has been a rise in attacks by politically motivated
“hacktivists” or terrorists, and by state-sponsored intruders, aimed
at disruption of their targets’ operations; theft of data or
intellectual property; extortion, cyber espionage, corruption or
destruction of data; and degradation or destruction of automated
systems.12 IOSCO and the WFE note that attacks on securities
exchanges now tend to be disruptive in nature, which “suggests a shift
in motive for cyber-crime in securities markets, away from financial
gain and towards more destabilizing aims.” 13
—————————————————————————
10 CFTC Roundtable, supra note 8, at 22-24.
11 Id. at 18-24, 42-43.
12 Id. at 12, 14-15, 17-24, 42-44, 47.
13 IOSCO-WFE Staff Report, supra note 4, at 3-4.
—————————————————————————
Second, financial institutions face increasing cyber capabilities
from both non-state actors and state-sponsored intruders. For example,
there has been an increase in sophistication on the part of most actors
in the cyber arena, both in terms of technical capability and the
capacity to organize and carry out attacks.14
—————————————————————————
14 Statement of Mr. Michael Daniel, White House Cybersecurity
Coordinator, CFTC Roundtable, supra note 8, at 21-23.
—————————————————————————
Third, the financial sector is experiencing an increase in the
duration of cyber attacks.15 While attacks aimed at monetary theft or
fraud tend to manifest themselves quickly, today’s more sophisticated
attacks may involve cyber adversaries having a presence inside a
target’s automated systems for an extended period of time, while
avoiding detection.16
—————————————————————————
15 Id. at 77, 82-83.
16 IOSCO and the WFE noted in 2013: “The rise of a relatively
new class of cyber-attack is especially troubling. This new class is
referred to as an `Advanced Persistent Threat’ (APT). . . . [APTs]
are usually directed at business and political targets for political
ends. APTs involve stealth to persistently infiltrate a system over
a long period of time, without the system displaying any unusual
symptoms.” IOSCO-WFE Staff Report, supra note 4, at 3.
—————————————————————————
Fourth, financial institutions face a broadening cyber threat
field. They must consider cyber vulnerabilities not only with respect
to desktop computers and their own automated systems, but also with
respect to mobile devices and data in the cloud.17 Further, adequate
risk analysis must address not just the vulnerabilities of the entity’s
automated systems, but also the human vulnerabilities posed by social
engineering 18 or disgruntled employees.19 Notably, today’s cyber
threat environment also includes automated systems that are not
directly internet-facing.20 For example, internet-facing corporate
information technology and non-internet-facing operations technology
can be, and often are, connected for maintenance purposes or in
error.21 Non-internet-facing systems are also vulnerable to insertion
of malware-infected removable media, phishing attacks, and other social
engineering techniques, and to supply-chain risk involving both
hardware and software.22
—————————————————————————
17 CFTC Roundtable, supra note 8, at 22.
18 “In a social engineering attack, an attacker uses human
interaction (social skills) to obtain or compromise information
about an organization or its computer systems. An attacker may seem
unassuming and respectable, possibly claiming to be a new employee,
repairperson, or researcher and even offering credentials to support
that identity. However, by asking questions, he or she may be able
to piece together enough information to infiltrate an organization’s
network. If an attacker is not able to gather enough information
from one source, he or she may contact another source within the
same organization and rely on the information from the first source
to add to his or her credibility.” See U.S. Computer Emergency
Readiness Team, Dep’t of Homeland Sec., Security Tip (ST04-014),
Avoiding Social Engineering and Phishing Attacks, available at:
https://www.us-cert.gov/ncas/tips/ST04-014 (last visited Sept. 14,
2015).
19 CFTC Roundtable, supra note 8, at 14, 79-80.
20 Id. at 60-70.
21 Id. at 73.
22 Id. at 62-66, 77-79.
—————————————————————————
Finally, financial institutions cannot achieve cyber resilience by
addressing threats to themselves alone: They also face threats due to
the increasing interconnectedness of financial services firms.23 As
such, a financial entity’s risk assessments need to consider
cybersecurity across the breadth of the financial sector, from
exchanges and clearing organizations to counterparties and customers,
technology providers, other third party service providers, and the
businesses and products in the entity’s supply chain.24
—————————————————————————
23 Id. at 25-26.
24 Id. at 48-57.
—————————————————————————
C. Need for Cybersecurity Testing
In the current environment, cybersecurity testing is crucial to
efforts by exchanges, clearing organizations, swap data repositories,
and other entities in the financial sector to strengthen cyber
defenses; mitigate operational, reputational, and financial risk; and
maintain cyber resilience and the ability to recover from cyber
attacks. To maintain the effectiveness of cybersecurity controls, such
entities must regularly test their system safeguards in order to find
and fix vulnerabilities before an attacker exploits them.
An entity’s testing should be informed by how its controls and
countermeasures stack up against the techniques, tactics, and
procedures used by its potential attackers.25 Adequate testing needs
to include periodic risk assessments made in light of changing business
conditions, the changing threat landscape, and changes to automated
systems. It also needs to include recurring tests of controls and
automated system components to verify their effectiveness and
operability, as well as continuous monitoring and scanning of system
operation and vulnerabilities. Testing should include a focus on the
entity’s ability to detect, contain, respond to, and recover from cyber
attacks within its systems, not just on its defenses designed to
prevent intrusions.26 This should include detection, containment, and
recovery from compromise of data integrity–perhaps the greatest threat
with respect to financial sector data–in addition to addressing
compromise of data availability or confidentiality, which tend to be
the main focus of many best
[[Page 80116]]
practices.27 Finally, both internal testing by the entity itself and
independent testing by third party service providers are essential
components of an adequate testing regime.28
—————————————————————————
25 Id. at 45-46.
26 Id. at 80-84.
27 Id. at 15-16, 65, 71-74, 82-83.
28 Id. at 89-90, 101-108, 167-168, 172-173, 244-253.
—————————————————————————
Cybersecurity testing is a well-established best practice generally
and for financial sector entities. The Federal Information Security
Management Act (“FISMA”), which is a source of cybersecurity best
practices and also establishes legal requirements for federal
government agencies, calls for “periodic testing and evaluation of the
effectiveness of information security policies, procedures, and
practices, to be performed with a frequency depending on risk, but no
less than annually. . . .” 29 The National Institute of Standards
and Technology (“NIST”) Framework for Improving Critical
Infrastructure Cybersecurity calls for testing of cybersecurity
response and recovery plans and cybersecurity detection processes and
procedures.30 The Financial Industry Regulatory Authority (“FINRA”)
2015 Report on Cybersecurity Practices notes that “[r]isk assessments
serve as foundational tools for firms to understand the cybersecurity
risks they face across the range of the firm’s activities and assets,”
and calls for firms to develop, implement, and test cybersecurity
incident response plans.31 FINRA notes that one common deficiency
with respect to cybersecurity is “failure to conduct adequate periodic
cybersecurity assessments.” 32 The Council on Cybersecurity’s
Critical Security Controls for Effective Cyber Defense (the
“Controls”) call for entities to “[c]ontinuously acquire, assess,
and take action on new information in order to identify
vulnerabilities, remediate, and minimize the window of opportunity for
attackers.” 33 The Controls further state that “[o]rganizations
that do not scan for vulnerabilities and proactively address discovered
flaws face a significant likelihood of having their computer systems
compromised.” 34 The Controls also call for entities to “[t]est the
overall strength of an organization’s defenses (the technology, the
processes, and the people) by simulating the objectives and actions of
an attacker.” 35 The Controls recommend conducting “regular
external and internal penetration tests to identify vulnerabilities and
attack vectors that can be used to exploit enterprise systems
successfully,” from both outside and inside the boundaries of the
organization’s network perimeter,36 and also call for use of
vulnerability scanning and penetration testing in concert.37
—————————————————————————
29 44 U.S.C. 3544(b)(5).
30 NIST, Framework for Improving Critical Infrastructure
Cybersecurity, Feb. 2014, v.1, Subcategory PR.IP-10, p. 28, and
Category DE.DP, p. 31, available at: http://www.nist.gov/cyberframework/upload/cybersecurity-framework-021214.pdf.
31 FINRA, Report on Cybersecurity Practices, Feb. 2015
(“FINRA Report”), pp. 1-2, available at: https://www.finra.org/sites/default/files/p602363%20Report%20on%20Cybersecurity%20Practices_0.pdf.
32 Id. at 8.
33 Council on Cybersecurity, The Critical Security Controls
for Effective Cyber Defense, v. 5.1 (“Council on Cybersecurity”),
p. 28, available at: http://www.counciloncybersecurity.org/bcms-media/Files/Download?id=a52977d7-a0e7-462e-a4c0-a3bd01512144.
34 Id.
35 Id. at 102.
36 Id.
37 Id. at 103.
—————————————————————————
The Federal Financial Institutions Examination Council
(“FFIEC”),38 another important source of cybersecurity best
practices for financial sector entities, summarized the need for
cybersecurity testing in today’s cyber threat environment:
—————————————————————————
38 The FFIEC includes the Board of Governors of the Federal
Reserve System, the Federal Deposit Insurance Corporation, the
Office of the Comptroller of the Currency, the Consumer Financial
Protection Bureau, the National Credit Union Administration, and the
State Liaison Committee of the Conference of State Bank Supervision.
Financial institutions should have a testing plan that
identifies control objectives; schedules tests of the controls used
to meet those objectives; ensures prompt corrective action where
deficiencies are identified; and provides independent assurance for
compliance with security policies. Security tests are necessary to
identify control deficiencies. An effective testing plan identifies
the key controls, then tests those controls at a frequency based on
the risk that the control is not functioning. Security testing
should include independent tests conducted by personnel without
direct responsibility for security administration. Adverse test
results indicate a control is not functioning and cannot be relied
upon. Follow-up can include correction of the specific control, as
well as a search for, and correction of, a root cause. Types of
tests include audits, security assessments, vulnerability scans, and
penetration tests.39
—————————————————————————
39 See FFIEC, E-Banking Booklet: IT Examination Handbook, Aug.
2003, p. 30, available at: http://ithandbook.ffiec.gov/ITBooklets/FFIEC_ITBooklet_E-Banking.pdf.
Some experts further note that cybersecurity testing may become a
requirement for obtaining cyber insurance. Under such an approach,
insurance coverage might be conditioned on cybersecurity testing and
assessment, followed by implementation of appropriate prevention and
detection procedures.40
—————————————————————————
40 See PricewaterhouseCoopers, Insurance 2020 and Beyond:
Reaping the Dividends of Cyber Resilience, 2015, available at:
http://www.pwc.com/gx/en/insurance/publications/assets/reaping-dividends-cyber-resilience.pdf.
—————————————————————————
Cybersecurity testing is also supported internationally. IOSCO has
emphasized the importance of testing to ensure effective controls, in
light of risks posed by the complexity of markets caused by
technological advances.41 According to IOSCO, “regulatory
authorities have also recognized the need for [t]rading [v]enues to
appropriately monitor critical systems and have appropriate control
mechanisms in place.” 42 Similarly, the European Securities and
Markets Authority (“ESMA”) guidelines for automated trading systems
call for trading platforms to test trading systems and system updates
to ensure that systems meet regulatory requirements, that risk
management controls work as intended, and that the systems can function
effectively in stressed market conditions.43 Further, the Principles
for Financial Market Infrastructures published by the Bank for
International Settlements’ Committee on Payments and Market
Infrastructures (“CPMI”) and IOSCO’s Technical Committee (together,
“CPMI-IOSCO”) note that with respect to operational risks, which
include cyber risk, “[a financial market infrastructure]’s
arrangements with participants, operational policies, and operational
procedures should be periodically, and whenever necessary, tested and
reviewed, especially after significant changes occur to the system or a
major incident occurs. . . .” 44 The Commission also notes that
Sec. 39.18(j)(1)(i) currently requires DCOs to conduct regular,
periodic, and objective testing and review of their automated systems
to ensure that these systems are reliable, secure, and have adequate
scalable capacity. Finally, the Commission notes that this requirement
must be satisfied by following, at a
[[Page 80117]]
minimum, generally accepted standards and industry best practices.45
As further explained below, the proposed rules would clarify existing
system safeguards requirements by identifying relevant generally
accepted standards and industry best practices. With few exceptions,
such as requirements for independent contractors to conduct certain
testing, the Commission is not changing the regulatory requirement for
DCOs as it exists today.
—————————————————————————
41 IOSCO Consultation Report, Mechanisms for Trading Venues to
Effectively Manage Electronic Trading Risks and Plans for Business
Continuity, Apr. 2015, p. 3, available at: https://www.iosco.org/library/pubdocs/pdf/IOSCOPD483.pdf.
42 Id. at 9.
43 ESMA, Guidelines: Systems and controls in an automated
trading environment for trading platforms, investment firms and
competent authorities, Feb. 24, 2012, p. 7, available at: http://www.esma.europa.eu/system/files/esma_2012_122_en.pdf.
44 CPMI-IOSCO, Principles for Financial Market
Infrastructures, Apr. 2012, at 96, available at: http://www.iosco.org/library/pubdocs/pdf/IOSCOPD377.pdf. See also CPMI,
Cyber resilience in financial market infrastructures, Nov. 2014,
available at: http://www.bis.org/cpmi/publ/d122.pdf.
45 For a more detailed discussion of current testing
requirements for DCOs, please see the System Safeguards Requirements
for DCOs in section I.A. above and the Consideration of Costs and
Benefits in section IV.C. below.
—————————————————————————
II. Proposed Amendments
A. Enhanced Testing Requirements
As discussed above, Sec. 39.18 requires a DCO to establish and
maintain a program of risk analysis and oversight with respect to its
operations and automated systems. As part of this program, a DCO is
required to conduct regular, periodic, and objective testing and review
of its automated systems to ensure that they are reliable, secure, and
have adequate scalable capacity. DCOs are specifically required, under
Sec. 39.18(d), to follow “generally accepted standards and industry
best practices with respect to the development, operation, reliability,
security, and capacity of automated systems” in addressing the
categories of risk analysis and oversight specified in Sec. 39.18. As
discussed in the Commission’s proposing release for Sec. 39.18, “DCO
compliance with generally accepted standards and best practices with
respect to the development, operation, reliability, security, and
capacity of automated systems can reduce the frequency and severity of
automated system security breaches or functional failures, thereby
augmenting efforts to mitigate systemic risk.” 46 This requirement
was further designed to allow DCOs flexibility in adapting their
programs to current industry best practices, which the Commission
recognized would evolve over time. Similarly, the additional testing
provisions that the Commission is proposing have been constructed to
set forth certain minimum requirements, with the expectation that DCOs’
testing may change as accepted standards and industry best practices
develop over time and are reflected in the DCO’s risk analysis.
—————————————————————————
46 See Risk Management Requirements for Derivatives Clearing
Organizations, 76 FR 3698, 3713 (Jan. 20, 2011).
—————————————————————————
Specifically, the Commission is proposing to strengthen the current
system safeguards regulatory framework by specifying five fundamental
types of systems testing and assessment that are required under Sec.
39.18. The Commission is proposing to require that these types of
testing and assessment be conducted at a frequency determined by an
appropriate risk analysis, but no less frequently than a proposed
minimum, which varies based on the particular type of testing or
assessment. To strengthen the objectivity and reliability of the
testing, assessment, and information available to the Commission in
this regard, the Commission is proposing to require that independent
contractors perform a significant portion of the testing and
assessment. In developing these requirements, the Commission has relied
on various industry standards and best practices for assessment of
information security systems, which are referenced in the following
discussion. The Commission has not proposed a definition of the term
“independent contractor.” Proposed definitions of terms related to
the proposed testing requirements are discussed in the respective
section setting forth each proposed testing requirement.
1. Vulnerability Testing
Identification of cyber and automated system vulnerabilities is a
critical component of a DCO’s ongoing assessment of risks to its
systems. NIST standards call for organizations to scan for automated
system vulnerabilities both on a regular and ongoing basis, and when
new vulnerabilities potentially affecting their systems are identified
and reported.47 NIST adds that organizations should employ
vulnerability scanning tools and techniques that automate parts of the
vulnerability management process.48 NIST also calls for the
organization to remediate vulnerabilities identified by vulnerability
testing, in accordance with its assessments of risk.49 Similarly, the
Controls recommend that organizations “continuously acquire, assess,
and take action on new information in order to identify
vulnerabilities, remediate, and minimize the window of opportunity for
attackers.” 50
—————————————————————————
47 NIST Special Publication 800-53, Security and Privacy
Controls for Federal Information Systems and Organizations, rev. 4
(“NIST SP 800-53”), Control RA-5, available at: http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf.
48 Id.
49 Id.
50 Council on Cybersecurity, supra note 33, at 28.
—————————————————————————
The proposed minimum standards and frequencies for vulnerability
testing are intended to strengthen a DCO’s systems oversight program.
Accordingly, in Sec. 39.18(a) the Commission is proposing to define
“vulnerability testing” as the testing of a DCO’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. This definition is consistent with NIST
standards for such testing.51 For purposes of this definition, the
term “reconnaissance analysis” is used to combine various aspects of
vulnerability testing.52 The proposed definition deliberately refers
broadly to vulnerability testing in order to avoid prescribing use of
any particular technology or tools, because vulnerability assessments
may not always be automated, and technology may change.53
—————————————————————————
51 See NIST SP 800-53, supra note 47, at F-153.
52 See, e.g., NIST Special Publication 800-115, Technical
Guide to Information Security Testing and Assessment, Sept. 2008
(“NIST SP 800-115”), p. 24, available at: http://csrc.nist.gov/publications/nistpubs/800-115/SP800-115.pdf (noting that
“[e]xternal testing often begins with reconnaissance techniques
that search public registration data, Domain Name System (DNS)
server information, newsgroup postings, and other publicly available
information to collect information (e.g., system names, Internet
Protocol [IP] addresses, operating systems, technical points of
contact) that may help the assessor to identify vulnerabilities”).
53 See SANS Institute, Penetration Testing: Assessing Your
Overall Security Before Attackers Do, p. 7, available at: https://www.sans.org/reading-room/whitepapers/analyst/penetration-testing-assessing-security-attackers-34635 (last visited Sept. 30, 2015)
(noting, “A wide variety of tools may be used in penetration
testing. These tools are of two main types; reconnaissance or
vulnerability testing tools and exploitation tools. While
penetration testing is more directly tied to the exploitation tools,
the initial scanning and reconnaissance is often done using less
intrusive tools.”).
—————————————————————————
Proposed Sec. 39.18(e)(2) would also require that vulnerability
testing include automated vulnerability scanning, as well as an
analysis of the test results to identify and prioritize all identified
vulnerabilities that require remediation.54 Moreover, the Commission
recognizes that automated scans may be authenticated (i.e., conducted
using usernames or passwords) or unauthenticated (i.e., conducted
without using usernames or
[[Page 80118]]
passwords). However, the Commission proposes requiring that, where
indicated by appropriate risk analysis, a DCO conduct such scanning on
an authenticated basis.55 Where scanning is conducted on an
unauthenticated basis, a DCO would be required to implement effective
compensating controls.56
—————————————————————————
54 See Security Standards Council, Payment Card Industry Data
Security Standards, Apr. 2015, v. 3.1 (“PCI-DSS”), p. 94,
available at: https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-1.pdf (defining a vulnerability scan as “a combination
of automated or manual tools, techniques, and/or methods run against
external and internal network devices and servers, designed to
expose potential vulnerabilities that could be found and exploited
by malicious individuals”). See also NIST SP 800-115, supra note
52, at 2-2 (noting that testing techniques that include
vulnerability scanning “can identify systems, ports, services, and
potential vulnerabilities, and may be performed manually but are
generally performed using automated tools”).
55 See Securities Standards Council, The PCI Monitor: Weekly
news, updates and insights from PCI SSC, June 25, 2014, available
at: http://training.pcisecuritystandards.org/the-pci-monitor-weekly-news-updates-and-insights-from-pci-ssc2?ecid=ACsprvuuirRbrU3vDlk76s_ngGKJKEYlvaBJzvvUMldZv4KKh6V1guIKOR5VLTNfAqPQ_Gmox3zO&utm_campaign=Monitor&utm_source=hs_email&utm_medium=email&utm_content=13292865&_hsenc=p2ANqtz-_LIkkHURyUmyq1p2OxB39R5nOpRh1XHE_jW6wCC6EEUAow15E7AuExcIGwdYxyh_6YNxVvKorcurk6r90E3d7dG71fbw&_hsmi=13292865#web.
56 See PCI-DSS, supra note 54, app. B at 112 (“Compensating
controls may be considered . . . when an entity cannot meet a
requirement explicitly as stated, due to legitimate technical or
documented business constraints, but has sufficiently mitigated the
risk associated with the requirement through implementation of
other, or compensating, controls.”).
—————————————————————————
Furthermore, the Commission is proposing to require DCOs to conduct
vulnerability testing at a frequency determined by an appropriate risk
analysis, but no less frequently than quarterly.57 The Commission
notes that while “[t]he frequency of testing should be determined by
the institution’s risk assessment,” 58 best practices call for risk
assessments to include consideration of a number of important factors,
including, for example, the frequency and extent of changes in the
organization’s automated systems and operating environment; the
potential impact if risks revealed by testing are not addressed
appropriately; the degree to which the relevant threat environment or
potential attacker profiles and techniques are changing; and the
results of other testing.59 Frequency appropriate to risk analysis
can also vary depending on the type of monitoring involved; for
example, with whether automated monitoring or procedural testing is
being conducted.60 Nonetheless, the Commission notes that the PCI-DSS
standards provide that entities should run internal and external
network vulnerability scans “at least quarterly,” as well as after
any significant network changes, new system component installations,
firewall modifications, or product upgrades.61 Because best practices
call for vulnerability testing at a frequency determined by an
appropriate risk analysis, and call for such testing to be conducted no
less than quarterly, this proposed rule does not impose new
requirements on DCOs. Rather, it is designed to give additional clarity
to DCOs concerning what is currently required under existing
regulations. In light of these best practices and the current level of
cyber threat to the financial sector discussed above, the Commission
believes that this proposed rule is appropriate in today’s
cybersecurity environment. For the same reasons, and because the
Commission understands that DCOs currently conduct vulnerability
testing on at least a quarterly basis and in many cases more
frequently, the Commission also believes that this minimum frequency
requirement for vulnerability testing will impose only de minimis
additional costs, if any, on DCOs.
—————————————————————————
57 See FFIEC, Information Security Booklet, IT Examination
Handbook, July 2006 (“FFIEC Handbook”), p. 82, available at:
http://ithandbook.ffiec.gov/ITBooklets/FFIEC_ITBooklet_InformationSecurity.pdf (noting that “firewall
policies and other policies addressing access control between the
financial institution’s network and other networks should be audited
and verified at least quarterly”).
58 Id.
59 See NIST Special Publication 800-39, Managing Information
Security Risk, Mar. 2011 (“NIST SP 800-39”), pp. 47-48, available
at: http://csrc.nist.gov/publications/nistpubs/800-39/SP800-39-final.pdf; see also FFIEC Handbook, supra note 57, at 82.
60 Id.
61 See Requirement 11.2, PCI-DSS, supra note 54, at 94.
—————————————————————————
In addition, the proposed rule would require DCOs to engage
independent contractors to conduct two of the required quarterly
vulnerability tests each year, while permitting DCOs to conduct other
vulnerability testing using employees who are not responsible for
development or operation of the systems or capabilities being tested.
The Commission believes that important benefits are provided when a
testing program includes both testing by independent contractors and
testing by entity employees not responsible for building or operating
the system being tested. While testing needs to be performed
internally, it also needs to be conducted from the viewpoint of an
outsider, particularly where testing against the possible tactics or
techniques of a particular threat actor is concerned.62 For example,
entity employees can use viewpoints that the outside world would not
have, based on intimate knowledge of the entity.63 Conversely,
independent contractors provide an outsider’s perspective, and may
search for vulnerabilities in a system that entity employees may not
have contemplated during the design or operation of the system
involved.64
—————————————————————————
62 See generally CFTC Roundtable, supra note 8, at 89-90.
63 Id. at 178.
64 Id. at 172-173.
—————————————————————————
The Commission also notes that best practices support having
testing conducted by both independent contractors and entity employees.
Regarding the benefits provided by independent contractor testing, NIST
notes that engaging third parties (e.g., auditors, contractor support
staff) to conduct the assessment offers an independent view and
approach that internal assessors may not be able to provide.
Organizations may also use third parties to provide specific subject
matter expertise that is not available internally.65 FFIEC states
that testing by independent contractors provides credibility to test
results.66 Acknowledging the use of entity employees to conduct
testing, FFIEC calls for such tests to be performed “by individuals
who are also independent of the design, installation, maintenance, and
operation of the tested system.” 67 Similarly, with respect to
system safeguards testing by internal auditors, FFIEC further states
that the auditors should have both independence and authority from the
Board of Directors to access all records and staff necessary for their
audits, and that auditors should not participate in activities that may
compromise or appear to compromise their independence.68 Further, the
data security standards of the Payment Card Industry Security Standards
Council call for conducting both internal and external vulnerability
scans, with external scans performed by an approved vendor.69
—————————————————————————
65 NIST SP 800-115, supra note 52, at 6-6. NIST also notes
that giving outsiders access to an organization’s systems can
introduce additional risk, and recommends proper vetting and
attention to contractual responsibility in this regard.
66 FFIEC Handbook, supra note 57, at 81.
67 Id.
68 FFIEC, Audit Booklet: IT Examination Handbook, Apr. 2012,
p.6, available at: http://ithandbook.ffiec.gov/ITBooklets/FFIEC_ITBooklet_Audit.pdf.
69 See Requirement 11, PCI-DSS, supra note 54, at 94-96.
—————————————————————————
Accordingly, following consideration of the recommendations set
forth in the standards mentioned above, the Commission believes that
requiring two of the four tests to be conducted by independent
contractors is a balanced approach. Other vulnerability tests may be
performed by employees of the DCO who are not responsible for
development or operation of the systems or capabilities being tested.
In light of the best practices and the current level of cyber threat to
the financial sector discussed above, the Commission believes that the
proposed rule provisions regarding vulnerability testing by independent
contractors are
[[Page 80119]]
appropriate in today’s cybersecurity environment.
2. Penetration Testing
Though complementary to vulnerability testing, penetration testing
differs from vulnerability testing in that its purpose is to identify
ways that the vulnerabilities identified above could be exploited.70
In other words, penetration testing attempts to exploit cyber and
automated system vulnerabilities, and subjects the system to real-world
attacks by testing personnel in order to identify both the extent to
which an attacker could compromise the system before the organization
detects and counters the attack, and the effectiveness of the
organization’s response mechanisms.71
—————————————————————————
70 See Security Standards Council, PCI-DSS Information
Supplement: Penetration Testing Guidance, Mar. 2015 (“PCI-DSS
Penetration Testing”), p. 3, available at: https://www.pcisecuritystandards.org/documents/Penetration_Testing_Guidance_March_2015.pdf.
71 See FFIEC Handbook, supra note 57, at 81.
—————————————————————————
NIST defines penetration testing as “[a] test methodology in which
assessors, typically working under specific constraints, attempt to
circumvent or defeat the security features of an information system.”
72 As noted in the FINRA Report, “[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.” 73 As further
explained, external security testing “is conducted from outside the
organization’s security perimeter[, which] offers the ability to view
the environment’s security posture as it appears outside the security
perimeter–usually as seen from the Internet–with the goal of
revealing vulnerabilities that could be exploited by an external
attacker.” 74 Internal penetration testing, on the other hand, is
conducted “from the internal network and [assessors] assume the
identity of a trusted insider or an attacker who has penetrated the
perimeter defenses.” 75 Internal penetration testing can therefore
reveal vulnerabilities that could be exploited, and demonstrates the
potential damage this type of attacker could cause.76
—————————————————————————
72 NIST SP 800-53, supra note 47, app. B at B-16.
73 FINRA Report, supra note 31, at 22.
74 NIST SP 800-115, supra note 52, at 2-4.
75 Id. at 2-5. See also, e.g., SANS, Penetration Testing in
the Financial Services Industry, 2010, p. 17, available at: https://www.sans.org/reading-room/whitepapers/testing/penetration-testing-financial-services-industry-33314 (“Penetration testing is
essential given the context of high operational risk in the
financial services industry.”).
76 See NIST SP 800-115, supra note 52, at 2-5.
—————————————————————————
In addition, generally accepted standards and industry best
practices support annual penetration testing. For example, NIST calls
for at least annual penetration testing of an organization’s network
and systems.77 Moreover, the FFIEC calls for independent penetration
testing of high risk systems at least annually, and for quarterly
testing and verification of the efficacy of firewall and access control
defenses.78 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.79
—————————————————————————
77 Id. at 5-6.
78 FFIEC Handbook, supra note 57, at 82.
79 See Requirements 11.3.1 and 11.3.2, PCI-DSS, supra note 54.
—————————————————————————
The primary benefit of a penetration test is that it identifies the
extent to which a system can be compromised before the attack is
identified and assesses the effectiveness of the response
mechanism.80 Accordingly, the Commission is proposing to require both
external and internal penetration testing. In Sec. 39.18(a), the
Commission proposes to define “external penetration testing” as
attempts to penetrate a DCO’s automated systems or networks from
outside the system and network boundaries to identify and exploit
vulnerabilities (including, but not limited to, methods for
circumventing the security features of an application, system, or
network).81 Proposed Sec. 39.18(e)(3) would require external
penetration testing to be conducted at a frequency determined by an
appropriate risk analysis, but no less frequently than annually.82
The Commission proposes to define “internal penetration testing” in
Sec. 39.18(a) as attempts to penetrate a DCO’s automated systems or
networks from inside the system and network boundaries to identify and
exploit vulnerabilities (including, but not limited to, methods for
circumventing the security features of an application, system, or
network).83 In Sec. 39.18(e)(4), the Commission also proposes to
require that internal penetration testing be conducted at a frequency
determined by an appropriate risk analysis, but no less frequently than
annually.
—————————————————————————
80 FFIEC Handbook, supra note 57, at 81.
81 See NIST SP 800-53, supra note 47, app. B at B-16 (defining
“penetration testing” as “[a] test methodology in which
assessors, typically working under specific constraints, attempt to
circumvent or defeat the security features of an information
system”); see also NIST Special Publication 800-137, Information
Security Continuous Monitoring for Federal Information Systems and
Organizations, Sept. 2011 (“NIST SP 800-137”), app. B, p. B-10,
available at: http://csrc.nist.gov/publications/nistpubs/800-137/SP800-137-Final.pdf.
82 See PCI-DSS Penetration Testing, supra note 70, at 8
(noting that “[p]enetration testing should be performed at least
annually and after any significant change–for example,
infrastructure or application upgrade or modification–or new system
component installations”).
83 Id. at 2.
—————————————————————————
As discussed above, the Commission notes that generally accepted
standards and industry best practices require annual penetration
testing. Moreover, DCOs currently are required to follow generally
accepted standards and industry best practices, which support a minimum
frequency of annually for internal penetration testing, and as
discussed in more detail in the Cost-Benefit Analysis in Section IV.C.
below, DCOs are conducting penetration testing on at least an annual
basis. However, the Commission acknowledges that Securities and
Exchange Commission (“SEC”) Regulation SCI, which is applicable to
DCOs that are registered with the SEC as clearing agencies,84
requires that penetration testing be conducted every three years.85
Nonetheless, given the importance of DCOs to the U.S. financial system,
the Commission believes that annual internal penetration testing is
appropriate in order to sufficiently address risks to a DCO’s systems.
—————————————————————————
84 Of the 15 DCOs currently registered with the Commission,
four also are registered with the SEC as clearing agencies: Chicago
Mercantile Exchange, Inc. (“CME”), ICE Clear Credit LLC, ICE Clear
Europe Limited, and Options Clearing Corporation. However, on August
3, 2015, CME filed with the SEC a written request to withdraw from
registration as a clearing agency. See Securities Exchange Act
Release No. 34-75762 (Aug. 26, 2015), 80 FR 52815 (Sept. 1, 2015).
85 17 CFR 240.1003. The SEC noted in its adopting release that
“SCI entities may, however, determine that based on its [sic] risk
assessment, it is appropriate and/or necessary to conduct such
penetration test reviews more frequently than once every three
years.” Regulation Systems Compliance and Integrity, 79 FR 72252,
72344 (Dec. 5, 2014).
—————————————————————————
In addition, and consistent with generally accepted standards and
industry best practices, proposed Sec. 39.18(e)(3) would require DCOs
to engage independent contractors to perform the required annual
external penetration tests. Independent testing provides for
impartiality, meaning that penetration testers are free from conflicts
of interest with respect to the development, operation, or management
of the system(s) that are the targets of the testing.86 The
Commission believes that the impartiality provided by independent
contractors, including their lack of a stake in the outcome, is an
[[Page 80120]]
important factor in conducting external penetration testing and
enhances the credibility of the test results.87 Proposed Sec.
39.18(e)(4) would, however, permit internal penetration testing to be
conducted by either independent contractors or employees of the DCO who
are not responsible for development or operation of the systems or
capabilities being tested.88
—————————————————————————
86 NIST SP 800-53, supra note 47, app. F-CA at F-62.
87 FFIEC Handbook, supra note 57, at 81 (noting that
“[i]ndependence provides credibility to the test results”).
88 See, e.g., PCI-DSS, supra note 54, at 97.
—————————————————————————
3. Controls Testing
Controls provide reasonable assurance that security management is
effective, and adequate control testing is therefore critical to
ensuring the confidentiality, integrity, and availability of
information and information systems.89 Regular, ongoing testing of
all of an organization’s system safeguards-related controls for these
purposes is a crucial part of a DCO’s risk analysis and oversight
program.90
—————————————————————————
89 See generally U.S. Gov’t Accountability Office, GAO-09-
232G, Federal Information System Controls Audit Manual, Feb. 2009,
available at: http://www.gao.gov/assets/80/77142.pdf.
90 See generally 17 CFR 39.18 and 17 CFR 39.34.
—————————————————————————
Generally accepted standards and industry best practices call for
organizations to conduct regular, ongoing controls testing that over
time includes testing of all their system safeguards-related controls.
For example, NIST calls for organizations to assess “the security
controls in the information system and its environment of operation to
determine the extent to which the controls are implemented correctly,
operating as intended, and producing the desired outcome with respect
to meeting established security requirements.” 91 NIST notes that
the results of such testing can allow organizations to, among other
things, identify potential cybersecurity problems or shortfalls,
identify security-related weaknesses and deficiencies, prioritize risk
mitigation decisions and activities, confirm that weaknesses and
deficiencies have been addressed, and inform related budgetary
decisions and capital investment.92 FFIEC calls for controls testing
because “[c]ontrols should not be assumed to be completely
effective,” and states that a controls testing program “is sound
industry practice and should be based on an assessment of the risk of
non-compliance or circumvention of the institution’s controls.” 93
—————————————————————————
91 NIST SP 800-53, supra note 47, app. F-CA at F-55.
92 NIST Special Publication 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.
93 FFIEC Handbook, supra note 57, at 12.
—————————————————————————
Consistent with industry best practices, the Commission proposes to
define “controls testing” in Sec. 39.18(a) as an assessment of a
DCO’s controls to determine whether such controls are implemented
correctly, are operating as intended, and are enabling the DCO to meet
the system safeguards requirements set forth in Sec. 39.18.94
Furthermore, the Commission proposes to define “controls” as the
safeguards or countermeasures 95 employed by the DCO in order to
protect the reliability, security, or capacity of its automated systems
or the confidentiality, integrity, or availability of its data and
information, in order to enable the DCO to fulfill its statutory and
regulatory responsibilities. Regulation 39.18(a) would also define
“key controls” as 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. In today’s
cybersecurity threat environment, the Commission believes that
effective testing of this subset of the system safeguards controls
maintained by a DCO is particularly important.
—————————————————————————
94 See generally NIST SP 800-53A, supra note 92.
95 NIST SP 800-53, supra note 47, app. B at B-5 (defining
“countermeasures” as “[a]ctions, devices, procedures, techniques,
or other measures that reduce the vulnerability of an information
system. Synonymous with security controls and safeguards”).
—————————————————————————
In addition, the Commission is proposing to require controls
testing in Sec. 39.18(e)(5), which would include testing of each
control included in the DCO’s risk analysis and oversight program, to
be conducted at a frequency indicated by an appropriate risk analysis,
but no less frequently than every two years. The Commission believes
that this would ensure that each such control is tested with sufficient
frequency to confirm the continuing adequacy of the DCO’s system
safeguards. The Commission recognizes, however, that appropriate risk
analysis may well determine that more frequent testing of either
certain key controls or all controls is necessary. The Commission notes
that industry best practices support information security continuous
monitoring (“ISCM”), which is defined as “maintaining ongoing
awareness of information security, vulnerabilities, and threats to
support organizational risk management decisions.” 96 Nonetheless,
recognizing that it is impractical to test every security control at
all times, these standards note that “[t]he frequency of assessments
should be sufficient to assure adequate security commensurate with
risk, as determined by system categorization and ISCM strategy
requirements.” 97 Thus, consistent with industry best practices, the
Commission is proposing minimum frequency for the testing of each
control of no less than every two years.
—————————————————————————
96 NIST SP 800-137, supra note 81, at vi.
97 Id. at 11.
—————————————————————————
The Commission also proposes to permit such testing to be conducted
on a rolling basis over the course of the period determined by
appropriate risk analysis in recognition of the fact that an adequate
system safeguards program for a DCO must necessarily include large
numbers of controls, and therefore it could be impracticable and unduly
burdensome to require testing of all controls in a single test. This
provision is designed to give a DCO flexibility concerning how and when
to test controls during the applicable minimum period, and is intended
to reduce burdens associated with testing every control to the extent
possible while still safeguarding and managing the DCO’s security.98
—————————————————————————
98 Id. at 25-27.
—————————————————————————
The proposed rule would also require testing of key controls to be
conducted by independent contractors. As noted above, the Commission
believes that the impartiality and credibility provided by independent
testing supports the proposed requirement that testing of key controls
be done by independent contractors. However, the Commission is
proposing to give DCOs the discretion to test other controls using
either independent contractors or employees of the DCO who are
independent of the systems being tested.99
—————————————————————————
99 See discussion supra section II.A.1.
—————————————————————————
4. Security Incident Response Plan Testing
The Commission recognizes that adequate cyber resilience requires
organizations to have sufficient capacity to detect, contain,
eliminate, and recover from a cyber intrusion, and believes that
security incident response plans,100 and testing of those plans, are
essential to such capabilities.
—————————————————————————
100 As discussed in more detail below, the Commission proposes
to define “security incident response plan testing” as the testing
of a DCO’s security incident response plan to determine the plan’s
effectiveness, identify potential weaknesses or deficiencies, enable
regular plan updating and improvement, and maintain organizational
preparedness and resiliency with respect to security incidents.
—————————————————————————
[[Page 80121]]
NIST urges organizations to have a security incident response plan
that “establishes procedures to address cyber attacks against an
organization’s information systems. These procedures are designed to
enable security personnel to identify, mitigate, and recover from
malicious computer incidents, such as unauthorized access to a system
or data, denial of service, or unauthorized changes to system hardware,
software, or data (e.g., malicious logic, such as a virus, worm, or
Trojan horse).” 101
—————————————————————————
101 NIST Special Publication 800-34, Contingency Planning
Guide for Federal Information Systems, rev. 1 (“NIST SP 800-34”),
p. 10, available at: http://csrc.nist.gov/publications/nistpubs/800-34-rev1/sp800-34-rev1_errata-Nov11-2010.pdf. Specifically, NIST
recommends that an organization develop, document, and distribute to
the appropriate personnel “[a]n incident response policy that
addresses purpose, scope, roles, responsibilities, management
commitment, coordination among organizational entities, and
compliance,” as well as “[p]rocedures to facilitate the
implementation of the incident response policy and associated
incident response controls.” NIST SP 800-53, supra note 47, at F-
103. See also NIST Special Publication 800-61, Computer Security
Incident Handling Guide, rev. 2 (“NIST SP 800-61”), p. 8,
available at: http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf. Such incident response plan should:
a. Provide the organization with a roadmap for implementing its
incident response capability;
b. Describe the structure and organization of the incident
response capability;
c. Provide a high-level approach for how the incident response
capability fits into the overall organization;
d. Meet the unique requirements of the organization, which
relate to mission, size, structure, and functions;
e. Define reportable incidents;
f. Provide metrics for measuring the incident response
capability within the organization;
g. Define the resources and management support needed to
effectively maintain and mature an incident response capability; and
h. Be reviewed and approved by [appropriate organization-defined
personnel or roles].
Id. at F-109. Finally, copies of the plan should be distributed
to appropriate personnel; reviewed at an appropriate frequency;
updated to address system or organizational changes, or problems
encountered during plan implementation, execution, or testing, with
plan changes communicated to appropriate personnel; and protected
from unauthorized disclosure and modification. Id.
—————————————————————————
In addition, NIST states that organizations should test their
security incident response capabilities, at appropriate frequencies, to
determine their effectiveness, and to document test results.102
—————————————————————————
102 NIST SP 800-53, supra note 47, app. F-IR at F-104.
—————————————————————————
FINRA’s best practices also call for firms to have security
incident response plans. FINRA’s 2015 Report on Cybersecurity Practices
states: “Firms should establish policies and procedures, as well as
roles and responsibilities for escalating and responding to
cybersecurity incidents. Effective practices for incident response
include . . . involvement in industry-wide and firm-specific simulation
exercises as appropriate to the role and scale of a firm’s business.”
103 Similarly, the FFIEC also calls for security incident response
plan testing, stating that “[f]inancial institutions should assess the
adequacy of their preparation by testing incident response guidelines
to ensure that the procedures correspond with business continuity
strategies.” 104 Moreover, the Controls argue that organizations
should protect their information, as well as their reputations, by
developing and implementing a security incident response plan,105 and
“conduct[ing] periodic incident scenario sessions for personnel
associated with the incident handling team, to ensure that they
understand current threats and risks, as well as their responsibilities
in supporting the incident handling teams.” 106
—————————————————————————
103 FINRA Report, supra note 31, at 23.
104 FFIEC, Business Continuity Planning Booklet: IT
Examination Handbook, Feb. 2015 (“FFIEC BCP Booklet”), p. 26,
available at: http://ithandbook.ffiec.gov/ITBooklets/FFIEC_ITBooklet_BusinessContinuityPlanning.pdf.
105 Council on Cybersecurity, supra note 33, at 96.
106 Id. at 97.
—————————————————————————
The Commission believes that industry best practices require the
development, implementation, and testing of a security incident
response plan.107 Proposed Sec. 39.18(e)(6) would require that DCOs
have a security incident response plan that is tested at a frequency
determined by an appropriate risk analysis, but no less frequently than
annually. Because Sec. 39.18 already calls for a DCO’s risk analysis
and oversight program to follow best practices, this requirement should
not impose any additional burdens or costs on DCOs. In addition, the
Commission notes that having such plans regularly tested will help DCOs
address security incidents more quickly and effectively when they
actually happen. Moreover, the Commission notes that annual testing is
consistent with industry best practices and an important part of a
DCO’s business continuity and disaster recovery plan.
—————————————————————————
107 See, e.g., FINRA Report, supra note 31, at 23; and FFIEC
BCP Booklet, supra note 104, at 25 (noting that “[e]very financial
institution should develop an incident response policy that is
properly integrated into the business continuity planning
process”).
—————————————————————————
The proposed rule would define a “security incident” as a
cybersecurity or physical security event that actually or potentially
jeopardizes automated system operation, reliability, security, or
capacity, or the availability, confidentiality, or integrity of
data.108 The Commission further proposes defining a “security
incident response plan” as a written plan documenting the DCO’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. Under the
proposed definition, 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. However,
the Commission proposes requiring the DCO’s security incident response
plan to include the DCO’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.
—————————————————————————
108 NIST defines an “incident” as “[a]n occurrence that
actually or potentially jeopardizes the confidentiality, integrity,
or availability of an information system or the information the
system processes, stores, or transmits, or that constitutes a
violation or imminent threat of violation of security policies,
security procedures, or acceptable use policies.” NIST SP 800-53,
supra note 47, at B-9. NIST further defines a “computer security
incident” as “a violation or imminent threat of violation of
computer security policies, acceptable use policies, or standard
security practices.” NIST SP 800-61, supra note 101, at 6. The
FFIEC notes that a security incident represents “the attempted or
successful unauthorized access, use, modification, or destruction of
information systems or customer data. If unauthorized access occurs,
the financial institution’s computer systems could potentially fail
and confidential information could be compromised.” FFIEC BCP
Booklet, supra note 104, at 25.
—————————————————————————
The Commission proposes to define “security incident response plan
testing” in Sec. 39.18(a) as the testing of a DCO’s security incident
response plan to determine the plan’s effectiveness, identify 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 would not be limited
to, checklist completion, walk-through or table-top exercises,
simulations, and comprehensive exercises.109 Pursuant to
[[Page 80122]]
proposed Sec. 39.18(e)(6), a DCO would also be permitted to coordinate
its security incident response plan testing with other testing required
by proposed Sec. 39.18(e),110 or with the testing of its other
business continuity-disaster recovery and crisis management plans. In
addition, a DCO would be permitted to conduct security incident
response plan testing by engaging independent contractors or by using
employees of the DCO who are not responsible for development or
operation of the systems or capabilities being tested. The Commission
notes that discussion at the CFTC Roundtable included concerns about
performing tests in a production environment, as the tests could have
the unintended consequence of disrupting business as usual and
potentially cause an event.111 Accordingly, the Commission proposes
to give DCOs discretion to decide whether the testing is completed in a
production or non-production environment.
—————————————————————————
109 See NIST SP 800-53, supra note 47, app. F-IR at F-104
(stating that “[i]ncident response testing includes, for example,
the use of checklists, walk-through or tabletop exercises,
simulations (parallel/full interrupt), and comprehensive exercises.
Incident response testing can also include a determination of the
effects on organizational operations (e.g., reduction in mission
capabilities), organizational assets, and individuals due to
incident response”).
110 In addition to the changes proposed herein, the Commission
is proposing to renumber Sec. 39.18(j) as Sec. 39.18(e).
111 CFTC Roundtable, supra note 8, at 87-88, 118, 321-326,
345-346.
—————————————————————————
5. Enterprise Technology Risk Assessment (“ETRA”)
ETRA is an important part of a DCO’s risk assessment program
because it helps the DCO produce a broad determination of its system
safeguards-related risks.112 In a sense, ETRA can be seen as a
strategic approach through which a DCO identifies risks and aligns its
systems goals accordingly. A well-conducted ETRA, and the knowledge and
prioritization of risks that it provides, can also inform and guide the
ongoing testing process and result in more effective cybersecurity risk
management.
—————————————————————————
112 NIST SP 800-39, supra note 59, at 1.
—————————————————————————
The Commission notes that with respect to ETRA, best practices
provide a number of sources for such risk assessment frameworks,113
and a DCO would generally be free to choose the assessment framework it
believes most appropriate to its particular circumstances, provided
that its choice is congruent with best practices and is consistent with
the DCO’s risk profile. For example, FINRA notes that approaches to
integrating threats and vulnerabilities in an overall risk assessment
report often differ, with some organizations following proprietary risk
assessment methodologies and other using vendor products tailored to
their particular needs, and with firms using a variety of cyber
incident and threat intelligence inputs for their risk
assessments.114
—————————————————————————
113 See, e.g., FFIEC Handbook, supra note 57; NIST SP 800-39,
supra note 59.
114 FINRA Report, supra note 31, at 14.
—————————————————————————
The Commission proposes to define “ETRA” in Sec. 39.18(a) as a
written assessment that includes, but is not limited to, an analysis of
threats and vulnerabilities in the context of mitigating controls. An
ETRA identifies, estimates, and prioritizes risks to a DCO’s operations
or assets (which include, for example, mission, functions, image, and
reputation risks), or to market participants, individuals, and other
entities, resulting from impairment of the confidentiality, integrity,
or availability of data and information or the reliability, security,
or capacity of automated systems.115 Proposed Sec. 39.18(e)(7) would
provide DCOs flexibility by permitting the ETRA to be completed by
independent contractors or employees of the DCO not responsible for
development or operation of the systems or capabilities being assessed.
The proposal would, however, require an ETRA to be completed at a
frequency determined by an appropriate risk analysis by the DCO, but no
less frequently than annually.116 As noted in the PCI-DSS standards,
“[p]erforming risk assessments at least annually and upon significant
changes allows the organization to keep up to date with organizational
changes and evolving threats, trends, and technologies.” 117
However, the Commission emphasizes that the proposed requirement to
prepare a written assessment on at least an annual basis is not
intended to substitute for the DCO’s obligation to conduct risk
assessment and monitoring on an ongoing basis; rather, its purpose is
to formalize the risk assessment process and ensure that it is
documented at a minimum frequency. As noted in the FFIEC Handbook:
“Monitoring and updating the security program is an important part of
the ongoing cyclical security process. Financial institutions should
treat security as dynamic with active monitoring; prompt, ongoing risk
assessment; and appropriate updates to controls.” 118
—————————————————————————
115 NIST SP 800-53, supra note 47, app. B at B-19.
116 See, e.g., FINRA Report, supra note 31, at 14 (stating
that firms conducting defined risk assessment processes do so either
annually or on an ongoing basis throughout the year, in either case
culminating in an annual risk assessment report).
117 See, e.g., PCI-DSS, supra note 54, at 100.
118 FFIEC Handbook, supra note 57, at 86.
—————————————————————————
B. Scope of Testing and Assessment
The Commission believes that the scope of a DCO’s testing should be
based on a proper risk analysis that takes into account the DCO’s
particular automated systems and networks and vulnerabilities,
including any recent changes to them, as well as the nature of the
DCO’s possible adversaries and their capabilities as revealed by
current cybersecurity threat analysis.119 The Commission recognizes
that, however, the scope set for particular instances of the various
types of cybersecurity testing can vary appropriately.120 Thus,
proposed Sec. 39.18(e)(8) would give a DCO flexibility in setting the
scope of particular cybersecurity tests, so long as its overall testing
program is sufficient to provide adequate assurance of the overall
effectiveness of its cybersecurity controls with respect to its system
safeguards-related risks. The Commission believes that such flexibility
should reduce costs and burdens associated with the proposed scope
while still effectively measuring the resilience of the DCO system
safeguards.
—————————————————————————
119 CFTC Roundtable, supra note 8, at 98, 101-103, 108-113,
128-130, 140-142, 173-180.
120 Id.
—————————————————————————
Accordingly, the Commission is proposing that the scope of all
testing and assessment required by its system safeguards regulations
for DCOs 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 DCO’s operations or
with fulfillment of its statutory and regulatory responsibilities;
impair or degrade the reliability, security, or capacity of the DCO’s
automated systems; add to, delete, modify, exfiltrate, or compromise
the integrity of any data related to the DCO’s regulated activities; or
undertake any other unauthorized action affecting the DCO’s regulated
activities or the hardware or software used in connection with those
activities. The Commission believes that this proposed scope is broad
enough to address all significant threats to the DCO, while still
providing sufficient guidance regarding the elements of the DCO’s
program.
C. Internal Reporting, Review, and Remediation
Under current Sec. 39.18(j)(3) 121 reports on testing protocols
and results must be communicated to, and reviewed by,
[[Page 80123]]
senior management of the DCO. However, consistent with industry best
practices, in Sec. 39.18(e)(9) the Commission is proposing to expand
this reporting requirement to include communication to, and review by,
the DCO’s board of directors. The Commission notes that active
management with board level involvement “is an essential effective
practice to address cybersecurity threats[, because] [w]ithout that
involvement and commitment, a firm is unlikely to achieve its
cybersecurity goals.” 122 Further, the Commission notes that FINRA
observes that “[b]oards should play a leadership role in overseeing
firms’ cybersecurity efforts,” and states that the board of directors
should understand and approach cybersecurity as an enterprise-wide risk
management issue rather than merely an information technology
issue.123 The Commission also notes that FFIEC states that regular
reports to the board of directors should address the results of the
organization’s risk assessment process and of its security monitoring
and testing, including both internal and external audits and
reviews.124 In addition, FFIEC calls for boards to review
recommendations for changes to the information security program
resulting from testing and assessment, and to review the overall
effectiveness of the program.125
—————————————————————————
121 The Commission is further proposing to renumber Sec.
39.18(j)(3) as Sec. 39.18(e)(9).
122 FINRA Report, supra note 31, at 7.
123 Id.
124 FFIEC Handbook, supra note 57, at 5.
125 Id.
—————————————————————————
Accordingly, proposed Sec. 39.18(e)(10) would also require DCOs to
establish and follow appropriate procedures for the remediation of
issues identified through such review, and for evaluation of the
effectiveness of testing and assessment protocols. The proposed rule
would also add a provision requiring a DCO 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 the DCO to fulfill the requirements of part
39 and meet its statutory and regulatory obligations. The proposed rule
would require such remediation to be timely in light of appropriate
risk analysis with respect to the risks presented.
D. Additional Amendments
In addition to the changes discussed above, the Commission is
proposing to reorder and renumber certain paragraphs in Sec. 39.18 to
make certain technical corrections to improve the clarity of the rule
text.
1. Definitions
The Commission is proposing to amend the introductory text of Sec.
39.18(a) to make clear that the definitions therein are also applicable
to Sec. 39.34, which sets forth additional system safeguards
requirements for SIDCOs and Subpart C DCOs.
The Commission also is proposing to revise the definitions of
“relevant area” and “recovery time objective” to make the language
consistent with that used elsewhere in Sec. 39.18.
Finally, the Commission is proposing to change references to “the
clearing and settlement of existing and new products” to “the
processing, clearing, and settlement of transactions” and a single
reference to “an entity” to “a [DCO].”
2. Program of Risk Analysis and Oversight
Regulation 39.18(b) requires a DCO to have a program of risk
analysis and oversight with respect to its operation and systems that
addresses the following elements, set forth in Sec. 39.18(c): (1)
Information security; (2) business continuity and 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. Specific requirements
concerning business continuity and disaster recovery are addressed in
Sec. 39.18(e), but the regulation does not provide any further
guidance on the other five elements. Therefore, the Commission is
proposing to amend Sec. 39.18(c) (renumbered as Sec. 39.18(b)(2))
126 to provide more detail for each of those other five
elements.127
—————————————————————————
126 The Commission is further proposing to renumber Sec.
39.18(d) as Sec. 39.18(b)(3); renumber Sec. 39.18(e)(2) as Sec.
39.18(b)(4); and delete Sec. 39.18(e)(3) and fold its requirements
into Sec. 39.18(c)(2). The Commission is also proposing conforming
changes to the text of the renumbered provisions.
127 Although the Commission is proposing, in a concurrent
notice of proposed rulemaking, to require that the program of risk
analysis and oversight for designated contract markets (“DCMs”)
include enterprise risk management and governance applicable
specifically to security and technology, at this time the Commission
is not proposing such a requirement for DCOs. The Commission
believes that DCOs face a wider array of risks than DCMs, and
therefore any enterprise risk management requirements for DCOs would
not be limited to the system safeguards context but rather would
need to be addressed in a more comprehensive fashion. The Commission
is considering this issue and may address it in a future rulemaking.
—————————————————————————
3. Business Continuity and Disaster Recovery Plan
Regulation 39.18(e)(1) requires that a DCO maintain a business
continuity and disaster recovery plan, emergency procedures, and
physical, technological, and personnel resources sufficient to enable
the timely recovery and resumption of operations and the fulfillment of
each obligation and responsibility of the DCO following any disruption
of its operations. Regulation 39.18(e)(2) explains that the
“responsibilities and obligations” described in Sec. 39.18(e)(1)
include the daily processing, clearing, and settlement of transactions.
Because these provisions are so closely linked, the Commission is
proposing to combine them into a new Sec. 39.18(c)(1).128
—————————————————————————
128 The Commission is further proposing to renumber Sec.
39.18(e)(3) as Sec. 39.18(c)(2), and Sec. 39.18(k) as Sec.
39.18(c)(3). The Commission is also proposing conforming changes to
the text of the renumbered provisions.
—————————————————————————
4. Location of Resources; Outsourcing
Regulation 39.18(f) allows a DCO to satisfy the resource
requirement in Sec. 39.18(e)(1) (renumbered as Sec. 39.18(c)(1))
using its own employees and property or through written contractual
arrangements with another DCO or other service provider (i.e.,
outsourcing). The Commission is proposing to amend this provision (and
renumber it as Sec. 39.18(d)) to clarify that a DCO is also permitted
to use outsourcing to satisfy Sec. 39.18(b)(2) (renumbered as Sec.
39.18(b)(4)), which requires a DCO to establish and maintain resources
that allow for the fulfillment of each obligation and responsibility of
the DCO in light of the risks identified by the DCO’s program of risk
analysis and oversight.
In addition, the Commission is proposing to amend Sec.
39.18(f)(2)(i) (renumbered as Sec. 39.18(d)(2)), which states that, if
a DCO chooses to use outsourced resources, the DCO retains liability
for any failure to meet the responsibilities specified in Sec.
39.18(e)(1) (renumbered as Sec. 39.18(c)(1)), “although it is free to
seek indemnification from the service provider.” Regulation 39.18
contains no restrictions that would prevent a DCO from seeking
indemnification from its service provider; therefore, the Commission is
proposing to delete this unnecessary language.
5. Recordkeeping
Under current Sec. 39.18(i), a DCO is required to maintain, and
provide to Commission staff upon request, current
[[Page 80124]]
copies of its business continuity plan and other emergency procedures,
its assessments of its operational risks, and records of testing
protocols and results. The Commission is proposing to renumber Sec.
39.18(i) as Sec. 39.18(f), and to amend the language to conform with
the testing requirements proposed herein.
6. Notice of Exceptional Events
Under current Sec. 39.18(g)(1), a DCO is required to promptly
notify Commission staff of any cybersecurity incident that materially
impairs, or creates a significant likelihood of material impairment of,
automated system operation, reliability, security, or capacity. The
Commission is proposing a conforming amendment to Sec. 39.18(g)(1), to
replace the term “cybersecurity incident” with “security incident,”
as the proposed definition of “security incident” would include a
cybersecurity incident.
7. System Safeguards for SIDCOs and Subpart C DCOs
The Commission is proposing to amend Sec. 39.34 to update several
cross-references to various provisions of Sec. 39.18.
III. Request for Comment
The Commission requests comment on all aspects of the proposed
amendments to Sec. Sec. 39.18 and 39.34. With respect to testing, the
Commission is particularly interested in the following:
Are the testing requirements being proposed in Sec. 39.18
consistent with the DCO core principles set forth in the CEA,
particularly the goals of Core Principle I? If so, in what ways? If
not, why not?
Are the proposed testing frequencies sufficient to safeguard DCOs
against cyber attacks? In particular, should the proposed control
testing be done more frequently, or less frequently? In each case,
please provide any data you may have that supports an alternate
frequency for such testing.
Should the Commission define the term “independent contractor”?
If so, how should such term be defined? If not, why not?
What alternatives, if any, would be more effective in reducing
systemic risk, mitigating the growing cybersecurity threats faced by
DCOs, and achieving compliance with the DCO core principles set forth
in the CEA?
The Commission requests that commenters include a detailed
description of any such alternatives and estimates of the costs and
benefits of such alternatives. Can the proposed changes to Sec. 39.18
be effectively implemented and complied with? If not, what changes
could be made to increase the likelihood of effective implementation
and compliance?
IV. Related Matters
A. Regulatory Flexibility Act
The Regulatory Flexibility Act (“RFA”) requires that agencies
consider whether the regulations they propose will have a significant
economic impact on a substantial number of small entities and, if so,
provide a regulatory flexibility analysis respecting the impact.129
The rules proposed by the Commission will impact DCOs. The Commission
has previously established certain definitions of “small entities” to
be used by the Commission in evaluating the impact of its regulations
on small entities in accordance with the RFA.130 The Commission has
previously determined that DCOs are not small entities for the purpose
of the RFA.131 Accordingly, the Chairman, on behalf of the
Commission, hereby certifies pursuant to 5 U.S.C. 605(b) that the
proposed rules will not have a significant economic impact on a
substantial number of small entities.
—————————————————————————
129 5 U.S.C. 601 et seq.
130 See 47 FR 18618, 18618-21 (Apr. 30, 1982).
131 See New Regulatory Framework for Clearing Organizations,
66 FR 45604, 45609 (Aug. 29, 2001).
—————————————————————————
B. Paperwork Reduction Act
The Paperwork Reduction Act of 1995 (“PRA”) 132 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. An agency may not conduct or
sponsor, and a person is not required to respond to, a collection of
information unless it displays a currently valid control number. This
proposed rulemaking contains recordkeeping and reporting requirements
that are collections of information within the meaning of the PRA.
—————————————————————————
132 44 U.S.C. 3501 et seq.
—————————————————————————
The proposed rulemaking contains provisions that would qualify as
collections of information, for which the Commission has already sought
and obtained a control number from the Office of Management and Budget
(“OMB”). The title for this collection of information is “Risk
Management Requirements for Derivatives Clearing Organizations” (OMB
Control Number 3038-0076). If adopted, responses to this collection of
information would be mandatory. As discussed below, the Commission
believes the proposal will not impose any new recordkeeping or
reporting requirements that are not already accounted for in collection
3038-0076.133 Accordingly, the Commission invites public comment on
the accuracy of its estimate that no additional recordkeeping or
information collection requirements or changes to existing collection
requirements would result from the proposal.
—————————————————————————
133 See Risk Management Requirements for Derivatives Clearing
Organizations, OMB Control No. 3038-0076, available at: http://www.reginfo.gov/public/do/PRAOMBHistory?ombControlNumber=3038-0076.
—————————————————————————
The Commission will protect proprietary information according to
the Freedom of Information Act (“FOIA”) and 17 CFR part 145,
“Commission Records and Information.” In addition, section 8(a)(1) of
the CEA strictly prohibits the Commission, unless specifically
authorized by the Act, from making public “data and information that
would separately disclose the business transactions or market positions
of any person and trade secrets or names of customers.” The Commission
is also required to protect certain information contained in a
government system of records according to the Privacy Act of 1974.
1. Clarification of Collection 3038-0076
The Commission notes that DCOs are already subject to system
safeguard-related recordkeeping and reporting requirements. As
discussed above in section II, the Commission is proposing to amend and
renumber current Sec. 39.18(i) as Sec. 39.18(f), to clarify the
system safeguard recordkeeping and reporting requirements for DCOs. The
proposed regulation would require DCOs, in accordance with Sec.
1.31,134 to provide the Commission with the following documents
promptly upon request of Commission staff: (1) Current copies of the
DCO’s business continuity and disaster recovery plan and other
emergency procedures; (2) all assessments of the DCO’s operational
risks or system safeguard-related controls; (3) all required reports
concerning system safeguards testing and assessment, whether conducted
by independent contractors or employees of the DCO; and (4) all other
documents requested by staff of the Division of Clearing and Risk, or
any successor division, in connection with Commission oversight of
system
[[Page 80125]]
safeguards pursuant to the CEA or Commission regulations, or in
connection with Commission maintenance of a current profile of the
DCO’s automated systems. The pertinent recordkeeping and reporting
requirements of proposed Sec. 39.18(f) are contained in the provisions
of current Sec. 39.18(i), which was adopted on November 8, 2011.135
Accordingly, the Commission believes that proposed Sec. 39.18(f) would
not impact the burden estimates currently provided for in collection
3038-0076.
—————————————————————————
134 Regulation 1.31(a)(1) specifically provides that “all
books and records required to be kept by the CEA or by these
regulations 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. The rule further provides that “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).
135 76 FR 69334.
—————————————————————————
2. Information Collection Comments
The Commission invites comment on any aspect of the proposed
information collection requirements discussed above. Pursuant to 44
U.S.C. 3506(c)(2)(B), the Commission will consider public comments on
such proposed requirements in: (1) Evaluating whether the proposed
collection of information is necessary for the proper performance of
the functions of the Commission, including whether the information will
have a practical use; (2) evaluating the accuracy of the Commission’s
estimate of the burden of the proposed collection of information,
including the validity of the methodology and assumptions used; (3)
enhancing the quality, utility, and clarity of the information proposed
to be collected; and (4) minimizing the burden of collection of
information on those who are to respond, including through the use of
appropriate automated, electronic, mechanical, or other technological
information collection techniques.
Copies of the submission from the Commission to OMB are available
from the CFTC Clearance Officer, 1155 21st Street NW., Washington, DC
20581, (202) 418-5160 or from http://RegInfo.gov. Persons desiring to
submit comments on the proposed information collection requirements
should send those comments to: The Office of Information and Regulatory
Affairs, Office of Management and Budget, Room 10235, New Executive
Office Building, Washington, DC 20503, Attention: Desk Officer of the
Commodity Futures Trading Commission; (202) 395-6566 (fax); or
[email protected] (email). Please provide the Commission with
a copy of submitted comments so that all comments can be summarized and
addressed in the final rulemaking, and please refer to the ADDRESSES
section of this rulemaking for instructions on submitting comments to
the Commission. OMB is required to make a decision concerning the
proposed information collection requirements between thirty (30) and
sixty (60) days after publication of the proposal in the Federal
Register. Therefore, a comment to OMB is best assured of receiving full
consideration if OMB (as well as the Commission) receives it within
thirty (30) days of publication of the proposal.
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 actions before promulgating a regulation
under the CEA or issuing certain orders.136 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. The Commission’s cost and benefit considerations in
accordance with section 15(a) are discussed below.
—————————————————————————
136 7 U.S.C. 19(a).
—————————————————————————
As an initial matter, the Commission considers the incremental
costs and benefits of these regulations, that is the costs and benefits
that are above the current system safeguard practices and requirements
under the CEA and the Commission’s regulations for DCOs. Where
reasonably feasible, the Commission has endeavored to estimate
quantifiable costs and benefits. Where quantification is not feasible,
the Commission identifies and describes costs and benefits
qualitatively.137
—————————————————————————
137 For example, to quantify benefits such as enhanced
protections for market participants and the public and financial
integrity of the futures and swaps markets would require
information, data and/or metrics that either do not exist, or to
which the Commission generally does not have access.
—————————————————————————
The Commission requests comment on the costs and benefits
associated with the proposed regulations. As discussed below, the
Commission has identified certain costs and benefits associated with
the proposed regulations and requests comment on all aspects of its
proposed consideration of costs and benefits, including identification
and assessment of any costs and benefits not discussed herein. In
addition, the Commission requests that commenters provide data and any
other information or statistics that the commenters relied on to reach
any conclusions regarding the Commission’s proposed consideration of
costs and benefits, including the series of questions in section 3(f).
2. Background and Baseline for the Proposal
As discussed above, the Commission believes that the current cyber
threats to the financial sector have expanded dramatically over recent
years.138 Accordingly, the current cyber threat environment
highlights the need to consider an updated regulatory framework with
respect to cybersecurity testing for DCOs. Although the Commission
acknowledges that the proposed amendments would likely result in some
additional costs for DCOs, the proposal would also bring several
overarching benefits to the futures and swaps industry. As discussed
more fully below, a comprehensive cybersecurity testing program is
crucial to efforts by DCOs to strengthen cyber defenses, to mitigate
operational, reputational, and financial risk, and to maintain cyber
resilience and ability to recover from cyber attack.139
Significantly, to ensure the effectiveness of cybersecurity controls, a
DCO must test in order to find and fix its vulnerabilities before an
attacker exploits them.140
—————————————————————————
138 See supra section I.B.
139 See also supra section I.C.
140 See supra section II.A.
—————————————————————————
The Commission recognizes that any economic effects, including
costs and benefits, should be compared to a baseline that accounts for
current regulatory requirements. The baseline for this cost and benefit
consideration is the set of requirements under the CEA and the
Commission’s regulations for DCOs. Currently, Sec. 39.18(j)(1)(i)
requires a DCO to conduct regular, periodic, and objective testing and
review of its automated systems to ensure that they are reliable,
secure, and have adequate scalable capacity.141 This requirement,
which forms part of the DCO risk analysis program required under Sec.
39.18(b), must be satisfied by following, at a minimum, “generally
accepted standards and industry best practices.” 142 In addition to
the generally accepted standards and industry best practices discussed
in section II above, this cost and benefit discussion uses information
provided by DCOs in connection with a recent survey of DCO system
safeguard costs and practices conducted by Commission staff (“February
2015 DCR Survey”).143
—————————————————————————
141 17 CFR 39.18(j).
142 See 17 CFR 39.18(d).
143 On February 19, 2015, the Division of Clearing and Risk
requested, pursuant to Sec. 39.19(c)(5)(i), information from each
registered DCO regarding the scope and costs of its current system
safeguard testing. Of the 14 DCOs contacted, 13 responded. ICE Clear
Credit, ICE Clear Europe, Ice Clear US, and the Clearing
Corporation, each subsidiaries of Intercontinental Exchange, Inc.,
provided a single response, indicating that their testing costs are
shared. LCH.Clearnet Ltd, LCH.Clearnet LLC, and LCH.Clearnet SA,
each subsidiaries of LCH.Clearnet Group Ltd., also provided a single
response, indicating that their testing costs are shared.
—————————————————————————
[[Page 80126]]
The Commission notes, however, that in certain instances the cost
estimates provided by the DCOs included estimates at the parent company
level of the DCO. Where parent level estimates were provided, the DCOs
explained that they generally share the same automated systems and
system safeguard programs with other entities within the corporate
structure and were therefore unable to apportion the actual costs to
particular entities. The Commission further notes that some of the DCOs
that supplied cost information are also registered with the Commission
in other capacities (as DCMs and/or swap data repositories). These DCOs
provided cost estimates that cover all of their Commission-regulated
functions because they generally share the same automated systems and
system safeguard programs. Therefore, the Commission has attempted to
account for these distinctions, where appropriate.
The Commission believes that certain entities that would be subject
to the proposal already comply with most of the testing requirements
while others may need some modest enhancements to their system
safeguard program to achieve compliance. In this same regard, the
Commission notes that some DCOs are larger or more complex than others,
and the proposed requirements may impact DCOs differently depending on
their size and the complexity of their systems. Thus, the Commission
expects that the costs and benefits may vary somewhat among DCOs. The
Commission also believes that to the extent the new requirements impose
additional costs, the primary costs will be in the form of more
frequent testing, including some testing that would have to be carried
out by independent contractors on behalf of the DCO. As a result, the
proposed rules may increase operational costs for DCOs by requiring
additional resources. The Commission is sensitive to the economic
effects of the proposed regulations, including costs and benefits.
Accordingly, the Commission seeks comment on the costs and benefits of
the proposed regulations, including where possible, quantitative data.
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 DCO. The
Commission’s proposed regulations are intended to further mitigate the
frequency and severity of system security breaches or functional
failures, and therefore, serve an important, if unquantifiable, public
benefit. Although the benefits of effective regulation are difficult to
value in dollar terms, the Commission believes that they are no less
important to consider given the Commission’s mission to protect market
participants and the public and to promote market integrity.
The discussion of costs and benefits that follows begins with a
summary of the current testing requirements and sources for industry
best practices as well as a summary of each proposed regulation and a
consideration of the corresponding costs and benefits. At the
conclusion of this discussion, the Commission considers the costs and
benefits of the proposed regulations collectively in light of the five
factors set forth in section 15(a) of the CEA.
3. Consideration of Costs and Benefits Related to the Proposed Rules
a. Regulation 39.18(a)–Definitions
(i) Summary of Proposed Regulations
As discussed above in section II, proposed Sec. 39.18(a) would add
to the existing list of definitions, 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.
(ii) Costs and Benefits
The proposed definitions simply provide context to the specific
system safeguard tests and assessments that a DCO would be required to
conduct on an ongoing basis. Accordingly, the costs and benefits of
these terms are attributable to the substantive testing requirements
and, therefore, are discussed in the cost and benefit considerations
related to the rules describing the requirements for each test.
b. Regulation 39.18(e)(2)–Vulnerability Testing
(i) Summary of Proposed Regulations
As discussed above in section II(A)(1), proposed Sec. 39.18(a)
defines “vulnerability testing” as testing of a DCO’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. Regulation 39.18(e)(2) requires such
testing to be of a scope sufficient to satisfy the testing scope
requirements of proposed Sec. 39.18(e)(8). Regulation 39.18(e)(2)(i)
requires a DCO to conduct vulnerability testing at a frequency
determined by an appropriate risk analysis, but at a minimum no less
frequently than quarterly. Among the four vulnerability tests conducted
annually, the proposed regulations would require a DCO to engage
independent contractors to perform two of the required quarterly tests
each year for the DCO, although other vulnerability testing may be
conducted by employees of the DCO who are not responsible for
development or operation of the systems or capabilities being tested.
The vulnerability test would also require automated vulnerability
scanning, which may be authenticated or unauthenticated.
(ii) Costs
The Commission believes that the scope requirement of proposed
Sec. 39.18(e)(2) will not impose new costs on DCOs. Comprehensive
vulnerability testing is an industry best practice,144 and therefore
required to be conducted under current Commission regulations.
Moreover, the Commission believes, based on the representations made by
DCOs to Commission staff in administering the Commission’s examination
program and DCO responses to the February 2015 DCR Survey, that most
DCOs are currently conducting vulnerability testing sufficient to meet
the scope requirements of proposed Sec. 39.18(e)(2). The Commission
also believes that the frequency requirement of proposed Sec.
39.18(e)(2)(i) will not impose new costs on DCOs. The Commission notes
that industry best practices state that vulnerability testing should be
conducted “at least quarterly.” 145 Accordingly, current Sec.
39.18 requires DCOs to conduct vulnerability testing on a quarterly
basis. In addition, the Commission notes that all 13 DCOs responding to
the February 2015 DCR Survey conduct vulnerability testing on a
quarterly basis at a minimum.146
—————————————————————————
144 See, e.g., NIST SP-800-53, supra note 47, at F-153; FFIEC
Handbook, supra note 57, at 10 (“Financial institutions should
assess potential threats and vulnerabilities of their information
systems.”); PCI-DSS, supra note 54, at 94.
145 See supra section II.A.1.; see also supra note 57 and
accompanying text.
146 The frequency of vulnerability testing ranged from 5 to
200 tests per year.
—————————————————————————
Proposed Sec. 39.18(e)(2)(ii) would require a DCO to conduct
vulnerability tests that include automated vulnerability scanning on an
[[Page 80127]]
authenticated basis, or, where not conducted on an authenticated basis,
to implement compensating controls.147 The Commission notes that
industry best practices specifically recommend authenticated
scanning.148 Likewise, current Sec. 39.18 requires DCOs to conduct
authenticated scanning and Commission staff has examined DCOs for
compliance with such requirement. Accordingly, the Commission does not
believe that DCOs will incur additional costs as a result of the
adoption of proposed Sec. 39.18(e)(2)(ii).
—————————————————————————
147 See supra notes 55 and 56 and accompanying text.
148 See, e.g., NIST SP 800-53, supra note 47, at F-154
(“Privileged access authorization to selected system components
facilitates more thorough vulnerability scanning and also protects
the sensitive nature of such scanning.”).
—————————————————————————
Under proposed Sec. 39.18(e)(2)(iii), for at least two of the
required quarterly vulnerability tests each year, vulnerability testing
must be conducted by an independent contractor. However, the remaining
two vulnerability tests may be conducted by a DCO’s employees so long
as those employees are not responsible for development or operation of
the systems or capabilities being tested.149 The Commission notes
that at least 9 of the 13 DCOs responding to the February 2015 DCR
Survey currently conduct at least some of their vulnerability testing
using independent contractors. The Commission does not, however, have
quantification or estimation of the costs associated with proposed
Sec. 39.18(e)(2)(iii). Nonetheless, in qualitative terms, the
Commission recognizes that, compared to the status quo, this proposed
requirement may impose some costs on DCOs equal to the difference
between conducting vulnerability testing in-house and hiring an
independent contractor. In particular, these proposed regulations may
require DCOs to establish and implement internal policies and
procedures that are reasonably designed to address the workflow
associated with the test, which 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 vulnerabilities identified by the independent contractor,
implementation of the measures to address such vulnerabilities, and
verification that these measures are effective and appropriate. The
Commission requests comment on the potential costs of proposed Sec.
39.18(e)(2)(iii) on DCOs, including, where possible, quantitative data.
—————————————————————————
149 See supra section II.A.1.
—————————————————————————
(iii) Benefits
Vulnerability testing identifies, ranks, and reports
vulnerabilities that, if exploited, may result in an intentional or
unintentional compromise of a system.150 The complex analysis and
plan preparation that a DCO undertakes to complete vulnerability
testing, including designing and implementing changes to existing
plans, are likely to contribute to a better ex ante understanding by
the DCO’s management of the challenges the DCO would face in a cyber
threat scenario, and thus better preparation to meet those challenges.
This improved preparation helps reduce the possibility of market
disruptions and financial losses to clearing members and their
customers. Regularly conducting vulnerability tests enables a DCO to
mitigate the impact that a cyber threat to, or a disruption of, a DCO’s
operations would have on customers, clearing members, and, more
broadly, the stability of the U.S. financial markets. Accordingly, the
Commission believes that such testing strengthens DCOs’ systems,
thereby protecting clearing members and their customers from a
disruption in clearing services.
—————————————————————————
150 PCI-DSS Penetration Testing, supra note 70, at 3.
—————————————————————————
The Commission acknowledges, as described above, that some DCOs may
incur additional costs as a result of the new requirement in proposed
Sec. 39.18(e)(2)(iii) that independent contractors complete the
vulnerability testing. Nevertheless, the Commission believes that the
use of independent contractions for vulnerability testing–a practice
that many DCOs report already doing–will strengthen this important
system safeguard, significantly benefitting the DCO, financial markets,
and the public by mitigating systemic risk.
The Commission requests comments on the potential benefits to a DCO
in complying with all aspects of proposed Sec. 39.18(e)(2), and any
benefits that would be realized by members of DCOs and their customers,
as well as other market participants or the financial system more
broadly. The Commission specifically requests comment on alternative
means to address these issues, and the benefits associated with such
alternatives.
c. Regulation 39.18(e)(3)–External Penetration Testing
(i) Summary of Proposed Regulations
As discussed above in section II(A)(2), proposed Sec. 39.18(a)
defines “external penetration testing” as “attempts to penetrate a
[DCO’s] automated systems from outside the systems’ boundaries to
identify and exploit vulnerabilities,” and proposed Sec. 39.18(e)(3)
requires such testing to be of a scope sufficient to satisfy the
testing scope requirements of proposed Sec. 39.18(e)(8). Proposed
Sec. 39.18(e)(3)(i) would require a DCO to conduct external
penetration testing at a frequency determined by an appropriate risk
analysis, but at a minimum no less frequently than annually. The
proposed rule also provides that independent contractors must perform
the required annual external penetration test on behalf of the DCO.
However, other external penetration testing may be performed by
appropriately qualified DCO employees not responsible for development
or operation of the systems or capabilities being tested.
(ii) Costs
The Commission believes that the scope requirement of proposed
Sec. 39.18(e)(3) will not impose new costs on DCOs. Comprehensive
external penetration testing is an industry best practice 151 and,
based on the representations made by DCOs to Commission staff in
administering the Commission’s examination program and DCO responses to
the February 2015 DCR Survey, the Commission believes that most DCOs
are currently conducting external penetration testing sufficient to
meet the scope requirements of proposed Sec. 39.18(e)(3).
—————————————————————————
151 See, e.g., NIST SP 800-53, supra note 47, app. F-CA at F-
62; FFIEC Handbook, supra note 57, at 81; PCI-DSS, supra note 54, at
96-97; see also section II.A.2.
—————————————————————————
In addition, the Commission believes that the frequency requirement
of proposed Sec. 39.18(e)(3)(i) will not impose new costs on DCOs. The
Commission notes that industry best practices specifically state that
external penetration testing should be conducted “at least annually.”
152 Therefore current Commission regulations require annual
penetration testing. Moreover, the Commission notes that at least 11 of
the 13 DCOs responding to the February 2015 DCR Survey conduct, at a
minimum, annual external penetration testing, with two DCOs responding
that they conduct periodic external penetration testing.
—————————————————————————
152 See, e.g., PCI-DSS, supra note 54, at 96-97; see also
section II.A.2.
—————————————————————————
[[Page 80128]]
The Commission believes that the requirement of proposed Sec.
39.18(e)(3)(ii) to use an independent contractor will not impose new
costs on DCOs. Current Sec. 39.18(j)(2) requires external penetration
testing to be conducted by a qualified, independent professional, who
can be employed by the DCO so long as he or she is not responsible for
development or operation of the systems or capabilities being tested.
However, as discussed above,153 the Commission notes that it is
industry best practice for DCOs to employ independent contractors to
conduct their external penetration testing, and therefore it is
currently required under Sec. 39.18. The Commission notes that at
least 11 of the 13 DCOs responding to the February 2015 DCR Survey
already employ independent contractors to conduct their external
penetration testing. The Commission is proposing Sec. 39.18(e)(3)(ii)
to make clear that independent contractors must conduct the required
annual external penetration test.
—————————————————————————
153 See supra section II.A.2.
—————————————————————————
The Commission requests comment on the potential costs of proposed
Sec. 39.18(e)(3) on DCOs, including, where possible, quantitative
data.
(iii) Benefits
External penetration testing benefits DCOs by identifying the
extent to which its systems can be compromised before an attack is
identified.154 Such testing is conducted outside a DCO’s security
perimeter to help reveal vulnerabilities that could be exploited by an
external attacker. Accordingly, the Commission believes that the
external penetration testing strengthens DCOs’ systems, thereby
protecting clearing members and their customers from a disruption in
clearing services, which could potentially disrupt the functioning of
the broader financial markets.
—————————————————————————
154 FFIEC Handbook, supra note 57, at 81; see also supra
section II.A.2.
—————————————————————————
As stated above, industry best practices require DCOs to engage
independent contractors to conduct annual external penetration testing.
Further, to the extent there is a lack of clarity regarding the
applicability of certain industry best practices in light of the
language in current Sec. 39.18(j)(2), proposed Sec. 39.18(e)(3)(ii)
would provide additional clarity. Moreover, the Commission believes
that testing by an independent contractor has particular value with
respect to external penetration testing because the test comes from the
viewpoint of an outsider, which may differ from the views of current
tactics, techniques, and threat vectors of current threat actors held
by DCO employees. The Commission believes that external penetration
testing helps DCOs, which constitute critical infrastructures important
to the national economy, to be adequately protected against the level
of cybersecurity threat now affecting the financial sector.
The Commission requests comments on the potential benefits to a DCO
in complying with all aspects of proposed Sec. 39.18(e)(3), and any
benefits that would be realized by members of DCOs and their customers,
as well as other market participants or the financial system more
broadly. The Commission specifically requests comment on alternative
means to address these issues, and the benefits associated with such
alternatives.
d. Regulation 39.18(e)(4)–Internal Penetration Testing
(i) Summary of Proposed Regulations
As discussed above in section II(A)(2), proposed Sec. 39.18(a)
defines “internal penetration testing” as “attempts to penetrate a
[DCO’s] automated systems from inside the systems’ boundaries to
identify and exploit vulnerabilities.” Proposed Sec. 39.18(e)(4)
requires such testing to be of a scope sufficient to satisfy the
testing scope requirements of proposed Sec. 39.18(e)(8). Proposed
Sec. 39.18(e)(4)(i) requires a DCO to conduct internal penetration
testing at a frequency determined by an appropriate risk analysis, but
no less frequently than annually. The test may be conducted by
independent contractors, or by appropriately qualified DCO employees
not responsible for development or operation of the systems or
capabilities being tested.
(ii) Costs
The Commission believes that the scope requirement of proposed
Sec. 39.18(e)(4) will not impose new costs on DCOs. Comprehensive
internal penetration testing is an industry best practice,155 and is
therefore required under current regulations. In addition, based on the
representations made by DCOs to Commission staff in administering the
Commission’s examination program and responses to the February 2015 DCR
Survey, the Commission believes that most DCOs are currently conducting
internal penetration testing sufficient to meet the scope requirements
of proposed Sec. 39.18(e)(4).
—————————————————————————
155 See, e.g., NIST SP 800-53, supra note 47, at F-62; FFIEC
Handbook, supra note 57, at 81; PCI-DSS, supra note 54, at 96-97;
see also supra section II.A.2.
—————————————————————————
Proposed Sec. 39.18(e)(4)(i) would require a DCO to conduct
internal penetration testing at a frequency determined by an
appropriate risk analysis, but no less frequently than annually. As
discussed above, industry best practices require annual internal
penetration testing, as well as after any significant infrastructure or
application upgrade or modification.” 156 Moreover, the Commission
notes that the February 2015 DCR Survey indicated that most DCOs
conduct internal penetration testing at least annually.
—————————————————————————
156 See, e.g., PCI-DSS, supra note 54, at 96-97; see also
supra section II.A.2.
—————————————————————————
The Commission also believes that proposed Sec. 39.18(e)(4)(ii)
will not impose new costs on DCOs. Proposed Sec. 39.18(e)(4)(ii)
requires DCOs to conduct internal penetration testing by engaging
independent contractors, or by using employees of the DCO who are not
responsible for development or operation of the systems or capabilities
being tested. Regulation 39.18(j)(2) currently requires testing to be
conducted by a qualified, independent professional, who can be employed
by the DCO so long as he or she is not responsible for development or
operation of the systems or capabilities being tested. Accordingly,
proposed Sec. 39.18(e)(4)(ii) would not change current regulatory
requirements.
The Commission requests comment on the potential costs of proposed
Sec. 39.18(e)(4) on DCOs, including, where possible, quantitative
data.
(iii) Benefits
By attempting to penetrate a DCO’s automated systems from inside
the systems’ boundaries, internal penetration tests allow DCOs to
assess system vulnerabilities from attackers that penetrate the DCO’s
perimeter defenses and from trusted insiders, such as former employees
and contractors. In addition to being an industry best practice, the
Commission believes that an 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 DCO’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.”
157
[[Page 80129]]
The Commission also believes that internal penetration testing
strengthens DCOs’ systems, thereby protecting clearing members and
their customers from a disruption in clearing services, which could
potentially disrupt the functioning of the broader financial markets.
—————————————————————————
157 FINRA Report, supra note 31, at 22.
—————————————————————————
The Commission requests comments on the potential benefits to a DCO
in complying with all aspects of proposed Sec. 39.18(e)(4), and any
benefits that would be realized by members of DCOs and their customers,
as well as other market participants or the financial system more
broadly. The Commission specifically requests comment on alternative
means to address these issues, and the benefits associated with such
alternatives.
e. Regulation 39.18(e)(5)–Controls Testing
(i) Summary of Proposed Regulations
As discussed above in section II(A)(3), proposed Sec. 39.18(a)
defines “controls testing” as an assessment of the DCO’s controls to
determine whether such controls are implemented correctly, are
operating as intended, and are enabling the DCO to meet the
requirements of proposed Sec. 39.18, and proposed Sec. 39.18(e)(5)
requires such testing to be of a scope sufficient to satisfy the
testing scope requirements of proposed Sec. 39.18(e)(8). Proposed
Sec. 39.18(e)(5)(i) would require a DCO to 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, but no less frequently than every two years.
Pursuant to proposed Sec. 39.18(e)(5)(ii), a DCO would be required
to engage independent contractors to test and assess its “key
controls,” which are defined in proposed Sec. 39.18(a) as “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.” DCOs may conduct any other non-key controls testing by
using independent contractors or employees of the DCO who are not
responsible for development or operation of the systems or capabilities
being tested.
(ii) Costs
The Commission does not believe that the scope requirement of
proposed Sec. 39.18(e)(5) will impose new costs on DCOs. Comprehensive
controls testing is an industry best practice.158 Accordingly,
current Sec. 39.18 requires DCOs to conduct comprehensive controls
testing. In addition, based on the representations made by DCOs to
Commission staff in administering the Commission’s examination program
and responses to the February 2015 DCR Survey, the Commission believes
that most DCOs are currently conducting controls testing sufficient to
meet the scope requirements of proposed Sec. 39.18(e)(5).
—————————————————————————
158 See, e.g., NIST SP 800-137, supra note 81, at vi; PCI-DSS,
supra note 54, at 13; see also supra section II.A.3.
—————————————————————————
Proposed Sec. 39.18(e)(5)(i) would require control testing to be
conducted at a frequency determined by an appropriate risk analysis,
but no less frequently than every two years. The Commission recognizes,
however, that appropriate risk analysis may well determine that more
frequent testing of either certain key controls or all controls is
necessary. For example, the Commission notes that the February 2015 DCR
Survey indicated that most DCOs conduct controls testing at least
annually.159
—————————————————————————
159 Seven of the responding DCOs conduct controls testing
annually, three DCOs conduct controls testing biannually, two DCOs
conduct controls testing triennially, and one DCO does not conduct
controls testing.
—————————————————————————
Proposed Sec. 39.18(e)(5)(ii) would require DCOs to engage
independent contractors to test and assess its key controls. Regulation
39.18(j)(2) currently requires testing to be conducted by a qualified,
independent professional, who can be employed by the DCO so long as he
or she is not responsible for development or operation of the systems
or capabilities being tested. The Commission notes that at least 11 of
the 13 DCOs responding to the February 2015 DCR Survey already employ
independent contractors to conduct key controls testing.
The Commission does not have quantification or estimation of the
costs associated with proposed Sec. 39.18(e)(5)(i) or proposed Sec.
39.18(e)(5)(ii). Nonetheless, in qualitative terms, the Commission
recognizes that, compared to the status quo, this proposed requirement
may impose some costs on DCOs equal to the difference between
conducting controls testing every two years in-house and hiring an
independent contractor to do so. In addition, with respect to the
frequency requirement in the proposed rule, a DCO would be required to
test each control included in its program of system safeguards-related
risk analysis oversight, at a frequency determined by appropriate risk
analysis, but no less frequently than every two years. The Commission
further recognizes that actual costs may vary as a result of numerous
factors, including the size of the DCO and the complexity of the
automated systems. Moreover, these proposed regulations may require
DCOs to establish and implement internal policies and procedures that
are reasonably designed to address the workflow associated with the
controls test, which may include the communication and cooperation
between the DCO and independent contractor, communication and
cooperation between the DCO’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.
The Commission requests comment on the potential costs of proposed
Sec. 39.18(e)(5) on DCOs, including, where possible, quantitative
data.
(iii) Benefits
Controls testing is essential in determining risk to an
organization’s operations and assets, to individuals, and to other
organizations, and to the Nation resulting from the use of the
organization’s systems.160 In other words, controls testing is vital
because it allows firms to be nimble in preventing, detecting, or
recovering from an attack.161 The Commission believes that the
complex analysis and plan preparation that a DCO undertakes with
respect to controls testing, including designing and implementing
changes to existing plans, likely contributes to a better ex ante
understanding by the DCO’s management of the challenges the DCO would
face in a cyber threat scenario, and thus better preparation to meet
those challenges. This improved preparation would help reduce the
possibility of market disruptions and financial losses to clearing
members and their customers. Moreover, regularly conducting controls
testing enables a DCO to mitigate the impact that a cyber threat to, or
a disruption of, a DCO’s operations would have on customers, clearing
members, and, more broadly, the stability of the U.S. financial
markets. Accordingly, the Commission believes that such testing
strengthens a DCO’s systems, thereby protecting
[[Page 80130]]
clearing members and their customers from a disruption in clearing
services
—————————————————————————
160 See NIST SP 800-53A, supra note 92, at 1; see also supra
section II.A.3.
161 Statement of Mr. Mark Clancy, Chief Executive Officer,
Soltra, CFTC Roundtable, supra note 8.
—————————————————————————
In addition, the Commission acknowledges that, as described above,
some DCOs may incur some additional costs as a result of the need to
conduct testing by an independent contractor. However, the Commission
believes that testing by an independent contractor has particular value
because the test comes from the viewpoint of an outsider, which may
differ from the views of current tactics, techniques, and threat
vectors of current threat actors held by DCO employees. The Commission
also acknowledges that, as described above, some DCOs may incur some
additional costs as a result of the need to accelerate the testing of
some controls in order to comply with the two-year cycle requirement.
Nevertheless, the Commission believes that it is essential for each
control to be tested within the two-year cycle requirement in order to
confirm the continuing adequacy of the DCO’s system safeguards and
maintain market stability. Additionally, the Commission notes that the
proposed rule would permit such testing to be conducted on a rolling
basis over the course of a two year period or period determined by
appropriate risk analysis. The rolling basis provision in the proposed
rule is designed to give a DCO flexibility concerning when controls are
tested during the required minimum frequency period. This flexibility
is intended to reduce burdens associated with testing every control
while still ensuring the needed minimum testing frequency. The
Commission also notes that testing on a rolling basis is consistent
with best practices.
The Commission requests comments on the potential benefits to a DCO
in complying with all aspects of proposed Sec. 39.18(e)(5), and any
benefits that would be realized by members of DCOs and their customers,
as well as other market participants or the financial system more
broadly. The Commission specifically requests comment on alternative
means to address these issues, and the benefits associated with such
alternatives.
f. Regulation 39.18(e)(6)–Security Incident Response Plan Testing
(i) Summary of Proposed Regulations
As discussed above in section II(A)(4), proposed Sec. 39.18(a)
defines security incident response plan testing as testing of a DCO’s
security incident response 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. Methods
of conducting security incident response plan testing would include,
but not be limited to, checklist completion, walk-through or table-top
exercises, simulations, and comprehensive exercises.
Proposed Sec. 39.18(e)(6)(i) would require DCOs to conduct such
testing at a frequency determined by an appropriate risk analysis, but
at a minimum no less frequently than annually. Proposed Sec.
39.18(e)(6)(ii) would require the DCO’s security incident response plan
to include, without limitation, the entity’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. Under proposed Sec. 39.18(e)(6)(iii), the DCO 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. Moreover, proposed Sec.
39.18(e)(6)(iv) would permit the DCO to conduct security incident
response plan testing by engaging independent contractors or by using
its own employees.
(ii) Costs
The Commission believes that proposed Sec. 39.18(e)(6)(i) will not
impose new costs on DCOs. Security incident response plan testing is an
industry best practice and therefore is required to be conducted under
current Commission regulations.162 Moreover, the Commission notes
that industry best practices state that security incident response plan
testing should be conducted annually.163 Accordingly, proposed Sec.
39.18(e)(6)(ii) will not impose new costs on DCOs because current Sec.
39.18 requires DCOs to conduct security incident response plan testing
on an annual basis. Finally, as stated above, Sec. 39.18(e)(6)(iii)
and (iv) do not contain explicit requirements, but rather provide a DCO
with flexibility to: (1) Coordinate its security incident response plan
testing with other testing required by Sec. 39.18 or with testing of
its other business continuity-disaster recovery and crisis management
plans; and (2) consistent with current Sec. 39.18(j)(2), engage
independent contractors or use employees of the DCO who are not
responsible for development or operation of the systems or capabilities
being tested. Accordingly, these provisions will not impose new costs
on DCOs.
—————————————————————————
162 See e.g., NIST SP 800-34, supra note 101, at 11; FINRA
Report, supra note 31, at 23; FFIEC BCP Booklet, supra note 104, at
25; and Council on Cybersecurity, supra note 33, at CSC 18; see also
supra section II.A.4. Similarly, the Commission proposes to
expressly require DCOs to update their business continuity and
disaster recovery plans and other emergency plans at least annually.
The Commission notes that updating such plans and procedures at
least annually is an industry best practice. See NIST SP 800-61,
supra note 101, at 8. Thus, annual updates are required under
current Commission regulations. Therefore, the Commission does not
believe that this proposal would impose new costs on DCOs. The
Commission acknowledges that this proposal could impose additional
burdens or costs on DCOs. The Commission believes, however, that
DCOs must be adequately protected in today’s environment.
163 See, e.g., NIST Special Publication 800-84, Guide to Test,
Training, and Exercise Programs for IT Plans and Capabilities, Sept.
2006, p. ES-2, available at: http://csrc.nist.gov/publications/nistpubs/800-84/SP800-84.pdf; PCI-DSS, supra note 54, at 108; see
also supra section II.A.4.
—————————————————————————
The Commission requests comment on the potential costs of proposed
Sec. 39.18(e)(6) on DCOs, including, where possible, quantitative
data.
(iii) Benefits
Security incident response plans, and adequate testing of such
plans, reduce the damage caused by breaches of a DCO’s network
security. Network security breaches are highly likely to have a
substantial negative impact on a DCO’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 DCO’s reputation and brand. Moreover, the longer a cyber
intrusion continues, the more its impact may be compounded.
As noted above, and consistent with industry best practices, the
Commission believes that annual security incident response testing
increases the ability of a DCO to mitigate the duration and impact in
the event of a security incident.164 Thus, a DCO may be better
positioned to minimize any potential impacts to automated system
operations, reliability, security, or capacity, or the availability,
confidentiality, or integrity of its derivatives data.
—————————————————————————
164 As noted above, the proposed provision that would require
DCOs to update their business continuity and disaster recovery plans
and other emergency plans at least annually reflects what is already
considered an industry best practice. Further, annual updates are
important because once an organization has developed a business
continuity and disaster recovery 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.” NIST SP
800-61, supra note 101, at 8.
—————————————————————————
[[Page 80131]]
The Commission requests comments on the potential benefits to a DCO
in complying with all aspects of proposed Sec. 39.18(e)(6), and any
benefits that would be realized by members of DCOs and their customers,
as well as other market participants or the financial system more
broadly. The Commission specifically requests comment on alternative
means to address these issues, and the benefits associated with such
alternatives.
g. Regulation 39.18(e)(7)–Enterprise Technology Risk Assessment
(i) Summary of Proposed Regulations
Proposed Sec. 39.18(a) defines an “enterprise technology risk
assessment” as a written assessment that includes, but is not limited
to, an analysis of threats and vulnerabilities in the context of
mitigating controls. Proposed Sec. 39.18(a) also provides that an
enterprise technology risk assessment identifies, estimates, and
prioritizes risks to a DCO’s operations or assets, or to market
participants, individuals, or other entities, resulting from impairment
of the confidentiality, integrity, or availability of data and
information or the reliability, security, or capacity of automated
systems. Proposed Sec. 39.18(e)(7) requires such assessment to be of a
scope sufficient to satisfy the requirements of proposed Sec.
39.18(e)(8). Proposed Sec. 39.18(e)(7)(i) requires DCOs to conduct an
enterprise technology risk assessment at a frequency determined by an
appropriate risk analysis, but no less frequently than annually.
Proposed Sec. 39.18(e)(7)(ii) provides that DCOs may use independent
contractors or employees of the DCO not responsible for development or
operation of the systems or capabilities being assessed to conduct an
enterprise technology risk assessment.
(ii) Costs
The Commission does not believe that the scope requirement of
proposed Sec. 39.18(e)(7) will impose new costs on DCOs. Comprehensive
enterprise technology risk assessments are an industry best
practice.165 Accordingly, current Sec. 39.18 requires DCOs to
conduct enterprise technology risk assessments. In addition, based on
the representations made by DCOs to Commission staff in administering
the Commission’s examination program and responses to the February 2015
DCR Survey, the Commission believes that most DCOs are currently
conducting enterprise technology risk assessments sufficient to meet
the scope requirements of proposed Sec. 39.18(e)(7).
—————————————————————————
165 See, e.g., NIST SP 800-39, supra note 59; FFIEC Handbook,
supra note 57, at 86; PCI-DSS, supra note 54, at 100; see also supra
section II.A.5.
—————————————————————————
Proposed Sec. 39.18(e)(7)(i) would require a DCO to conduct an
enterprise technology risk assessment at a frequency determined by an
appropriate risk analysis, but no less frequently than annually. As
discussed above,166 industry best practices require enterprise
technology risk assessments at least annually and upon significant
changes to the environment.167 Thus, current regulations require DCOs
to conduct enterprise technology risk assessments on an annual basis.
Accordingly, the Commission does not believe that proposed Sec.
39.18(e)(7)(i) will impose new costs on DCOs. Moreover, the Commission
notes that responses to the February 2015 DCR Survey indicated that
most DCOs conduct an enterprise technology risk assessment at least
annually.
—————————————————————————
166 See supra section II.A.5.
167 PCI-DSS, supra note 54, at 100.
—————————————————————————
Proposed Sec. 39.18(e)(7)(ii) requires DCOs to conduct enterprise
technology risk assessments by using independent contractors or
employees of the DCO not responsible for development or operation of
the systems or capabilities being assessed. Regulation 39.18(j)(2)
currently requires testing to be conducted by a qualified, independent
professional, who can be employed by the DCO so long as he or she is
not responsible for development or operation of the systems or
capabilities being tested. Accordingly, the Commission does not believe
that DCOs will incur additional costs as a result of the adoption of
proposed Sec. 39.18(e)(7)(ii).
(iii) Benefits
The Commission believes that enterprise technology risk assessments
are essential components of a comprehensive system safeguard program.
Enterprise technology risk assessments can be viewed as a strategic
approach through which a DCO identifies risks and aligns its systems
goals accordingly. The Commission believes that these requirements are
necessary to support a strong risk management framework for DCOs,
thereby helping to protect DCOs, their members, and other market
participants, and helping to mitigate the risk of market disruptions.
The Commission requests comments on the potential benefits to a DCO
in complying with all aspects of proposed Sec. 39.18(e)(7), and any
benefits that would be realized by members of DCOs and their customers,
as well as other market participants or the financial system more
broadly. The Commission specifically requests comment on alternative
means to address these issues, and the benefits associated with such
alternatives.
h. Regulation 39.18(e)(8)–Scope of Testing and Assessment
(i) Summary of Proposed Regulations
As discussed above in section II(B), proposed Sec. 39.18(e)(8)
provides that the scope for all system safeguards testing and
assessment required by proposed Sec. 39.18 must be broad enough to
include all testing of automated systems, networks, and controls
necessary to identify any vulnerability which, if exploited or
accidentally triggered, 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, modify,
exfiltrate, or compromise the integrity of any data related to the
entity’s regulated activities; and (4) undertake any other unauthorized
action affecting the entity’s regulated activities or the hardware or
software used in connection with those activities.
(ii) Costs and Benefits
The Commission believes that the costs and benefits associated with
the scope for testing and assessment are generally attributable to the
substantive testing requirements, and therefore, are discussed above in
the cost and benefit considerations related to the rules describing the
requirements for each test or assessment.
i. Regulation 39.18(e)(9)–Internal Reporting and Review
(i) Summary of Proposed Regulations
As discussed above in section II(C), proposed Sec. 39.18(e)(9)
provides that both the senior management and the board of directors of
the DCO must receive and review reports setting forth the results of
the testing and assessment required by proposed Sec. 39.18. Moreover
the DCO would be required to establish and follow appropriate
procedures for the remediation of issues identified through such
review, as provided in proposed Sec. 39.18(e)(10), and for evaluation
of the effectiveness of testing and assessment protocols.
(ii) Costs
As discussed above, review of system safeguard testing and
assessments by
[[Page 80132]]
senior management and the DCO’s board of directors is an industry best
practice and is therefore required to be conducted under current
Commission regulations.168 Accordingly, the Commission does not
believe that DCOs will incur additional costs as a result of the
adoption of the proposed rules.
—————————————————————————
168 See supra section II.C.
—————————————————————————
Nevertheless, the Commission requests comment on any potential
costs of proposed Sec. 39.18(e)(9) on DCOs, including, where possible,
quantitative data.
(iii) 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 DCO’s board of directors may
have to devote resources to reviewing testing and assessment reports,
active supervision by these individuals promotes responsibility and
accountability by ensuring they receive and review the results of all
system safeguard testing and assessments, thereby affording them the
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, and compliance personnel
of the DCO. Such focus could cause a DCO to internalize and/or more
appropriately allocate certain costs that would otherwise be borne by
clearing members, customers of clearing members, and other relevant
stakeholders. Active supervision by senior management and the board of
directors also promotes a more efficient, effective, and reliable DCO
risk management and operating structure. Consequently, the DCO should
be better positioned to strengthen the integrity, resiliency, and
availability of its automated systems.
The Commission requests comments on the potential benefits to a DCO
in complying with all aspects of proposed Sec. 39.18(e)(9), and any
benefits that would be realized by members of DCOs and their customers,
as well as other market participants or the financial system more
broadly. The Commission specifically requests comment on alternative
means to address these issues, and the benefits associated with such
alternatives.
j. Regulation 39.18(e)(10)–Remediation
(i) Summary of Proposed Regulations
As discussed above in section II(C), proposed Sec. 39.18(e)(10)
requires a DCO to analyze the results of the testing and assessment
required by proposed Sec. 39.18 to identify all vulnerabilities and
deficiencies in its systems. The DCO would also be required to
remediate those vulnerabilities and deficiencies to the extent
necessary to enable the DCO to fulfill its statutory and regulatory
obligations. The remediation would have to be timely in light of
appropriate risk analysis with respect to the risks presented by such
vulnerabilities and deficiencies.
(ii) Costs
The Commission believes that, based on a DCO’s risk analysis, the
DCO generally remediates the vulnerabilities and deficiencies revealed
by testing and assessment in the ordinary course of business to
mitigate harm to the DCO and to satisfy current statutory and
regulatory requirements. As discussed above, remediation of
vulnerabilities and deficiencies revealed by cybersecurity testing is
an industry best practice,169 and DCOs are already required to comply
with this requirement. Accordingly, the Commission does not believe
that DCOs will incur additional costs as a result of the adoption of
the proposed rules.
—————————————————————————
169 See, e.g., FFIEC Handbook, supra note 57, at 5; see also
supra section II.C.
—————————————————————————
The Commission requests comment on any potential costs of proposed
Sec. 39.18(e)(10) on DCOs, including, where possible, quantitative
data.
(iii) Benefits
The Commission believes that effective remediation is a critical
component of a comprehensive and effective system safeguard program. As
discussed above, the Commission believes that the remediation of
vulnerabilities and deficiencies revealed by cybersecurity testing is a
current industry best practice and therefore already required under
current regulations. Moreover, remediation may reduce the frequency and
severity of systems disruptions and breaches for DCOs. In addition,
remediation helps ensure that DCOs dedicate appropriate resources to
timely address system safeguard-related deficiencies and would place an
emphasis on mitigating harm to market participants while promoting
market integrity. Without a timely remediation requirement, the impact
of the vulnerabilities or deficiencies identified by the testing or
assessment could persist and have a detrimental effect on the
derivatives markets generally, as well as market participants. The
Commission also believes that remediation could potentially result in
DCOs reviewing and revising their existing policies and procedures to
ensure that they are sufficiently thorough in the context of the new
regulatory requirements, which would also assist their staffs in
responding appropriately to vulnerabilities or deficiencies identified
by the testing and assessments.
The Commission requests comments on the potential benefits to a DCO
in complying with all aspects of proposed Sec. 39.18(e)(10), and any
benefits that would be realized by members of DCOs and their customers,
as well as other market participants or the financial system more
broadly. The Commission specifically requests comment on alternative
means to address these issues, and the benefits associated with such
alternatives.
4. Section 15(a) Factors
a. Protection of Market Participants and the Public
Automated systems are critical to a DCO’s operations, which provide
essential counterparty credit risk protection to market participants
and the investing public. Proposed Sec. 39.18 is designed to further
enhance DCOs’ risk analysis programs in order to ensure that such
automated systems are reliable, secure, and have an adequate scalable
capacity. Accordingly, the Commission believes that the proposed rules
will further help protect the derivatives markets by promoting more
robust automated systems and therefore fewer disruptions and market-
wide closures, systems compliance issues, and systems intrusions.
Additionally, providing the Commission with reports concerning the
system safeguards testing and assessments required by the proposed
regulations will further facilitate the Commission’s oversight of
derivatives 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 a DCO’s automated systems are
available, reliable, secure, have adequate scalable capacity, and are
effectively overseen.
The costs of this proposed rulemaking would be mitigated by the
countervailing benefits of improved design, more efficient and
effective processes, and enhanced planning that would lead to increased
safety and soundness of DCOs and the reduction of
[[Page 80133]]
systemic risk, which protect market participants and the public from
the adverse consequences that would result from a DCO’s failure or a
disruption in its functioning.
b. Efficiency, Competitiveness and Financial Integrity
The proposed amendments to Sec. 39.18 would help preserve the
efficiency and financial integrity of the derivatives markets by
promoting comprehensive oversight and testing of a DCO’s operations and
automated systems. Specifically, the proposed amendments will further
reduce the probability of a cyber attack that could lead to a
disruption in clearing services which could, in turn, cause disruptions
to the efficient functioning and financial integrity of the derivatives
markets. Preventing cyber attacks could prevent monetary losses to
DCOs, and thereby help protect their financial integrity.
The Commission does not anticipate the proposed amendments to have
a significant impact on the competitiveness of the derivatives markets.
c. Price Discovery
The Commission does not anticipate the proposed amendments to Sec.
39.18 to have a direct effect on the price discovery process. However,
ensuring that DCOs’ automated systems function properly to clear trades
protects the price discovery process to the extent that a prolonged
disruption or suspension in clearing at a DCO may cause potential
market participants to refrain from trading.
d. Sound Risk Management Practices
The proposed amendments to Sec. 39.18 would strengthen and promote
sound risk management practices across DCOs. Specifically, the proposed
amendments would build upon the current system safeguards requirements
by ensuring that tests of DCOs’ key system safeguards are conducted at
minimum intervals and, where appropriate, by independent professionals.
The applicable tests are each recognized by industry best practices as
essential components of a sound risk management program. Moreover, the
benefits of the proposed rules will be shared by market participants
and the investing public as DCOs, by their nature, serve to provide
such parties with counterparty credit risk protection.
In addition, reliably functioning computer systems and networks are
crucial to comprehensive risk management, and being able to request
reports of the system safeguards testing required by the proposed
regulations will assist the Commission in its oversight of DCOs and
will bolster the Commission’s ability to assess systemic risk levels.
e. Other Public Interest Considerations
The Commission notes the public interest in promoting and
protecting public confidence in the safety and security of the
financial markets. DCOs are essential to risk management in the
financial markets, both systemically and on an individual firm level.
Proposed Sec. 39.18, by explicating current requirements and
identifying several additional key tests and assessments, promotes the
ability of DCOs to perform these functions free from disruption due to
both internal and external threats to its systems.
5. Request for Comment
In addition to the requests for comment specified above, the
Commission requests comment on the following:
What are the potential costs and benefits resulting from, or
arising out of, requiring DCOs to comply with the proposed changes to
Sec. 39.18? In considering costs and benefits, commenters are
requested to address the effect of the proposed regulation not only on
a DCO, but also on the DCO’s clearing members, the customers of
clearing members, and the financial system more broadly. The Commission
requests that, where possible, commenters provide quantitative data in
their comments, particularly with respect to estimates of costs and
benefits.
The Commission has identified the baseline as current regulatory
requirements. Is this baseline correct? If not, what should the
baseline be, and how would the alternative baseline change the costs
and benefits associated with the proposed changes to Sec. 39.18?
Do rules impose costs above those required by current system
safeguards rule and identified by the Commission? Specify and provide
data to support.
Do rules provide benefits above those required by current system
safeguards rule and identified by the Commission? Specify and provide
data to support.
Do the costs or impacts of the proposed rules differ depending on
the size of a DCO? Do they differ depending on the complexity of a
DCO’s systems?
List of Subjects in 17 CFR Part 39
Commodity futures, Reporting and recordkeeping requirements, System
safeguards.
For the reasons stated in the preamble, the Commodity Futures
Trading Commission proposes to amend 17 CFR part 39 as follows:
PART 39–DERIVATIVES CLEARING ORGANIZATIONS
0
1. The authority citation for part 39 continues to read as follows:
Authority: 7 U.S.C. 2, 7a-1, and 12a; 12 U.S.C. 5464; 15 U.S.C.
8325.
0
2. Revise Sec. 39.18 to read as follows:
Sec. 39.18 System safeguards.
(a) Definitions. For purposes of this section and Sec. 39.34:
Controls mean the safeguards or countermeasures employed by the
derivatives clearing organization in order to protect the reliability,
security, or capacity of its automated systems or the confidentiality,
integrity, or availability of its data and information, in order to
enable the derivatives clearing organization to fulfill its statutory
and regulatory responsibilities.
Controls testing means assessment of the derivatives clearing
organization’s controls to determine whether such controls are
implemented correctly, are operating as intended, and are enabling the
derivatives clearing organization 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 a derivatives clearing organization’s operations or assets, or to
market participants, individuals, or other entities, resulting from
impairment of the confidentiality, integrity, or availability of data
and information or the reliability, security, or capacity of automated
systems.
External penetration testing means attempts to penetrate a
derivatives clearing organization’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 a
derivatives clearing organization’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.
[[Page 80134]]
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.
Recovery time objective means the time period within which a
derivatives clearing organization should be able to achieve recovery
and resumption of processing, clearing, and settlement of transactions,
after those capabilities become temporarily inoperable for any reason
up to or including a wide-scale disruption.
Relevant area means the metropolitan or other geographic area
within which a derivatives clearing organization has physical
infrastructure or personnel necessary for it to conduct activities
necessary to the processing, clearing, and settlement of transactions.
The term “relevant area” also includes communities economically
integrated with, adjacent to, or within normal commuting distance of
that metropolitan or other geographic area.
Security incident means a cybersecurity or physical security event
that actually or potentially jeopardizes 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 derivatives clearing organization’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
derivatives clearing organization’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 derivatives clearing
organization’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.
Wide-scale disruption means an event that causes a severe
disruption or destruction of transportation, telecommunications, power,
water, or other critical infrastructure components in a relevant area,
or an event that results in an evacuation or unavailability of the
population in a relevant area.
(b) Program of risk analysis and oversight–(1) General. A
derivatives clearing organization shall establish and maintain a
program of risk analysis and oversight with respect to its operations
and automated systems to identify and minimize sources of operational
risk through:
(i) The development of appropriate controls and procedures; and
(ii) The development of automated systems that are reliable,
secure, and have adequate scalable capacity.
(2) Elements of program. A derivatives clearing organization’s
program of risk analysis and oversight with respect to its operations
and automated systems, as described in paragraph (b)(1) of this
section, shall address each of the following elements:
(i) Information security, including, but not limited to, controls
relating to: Access to systems and data (e.g., 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
(e.g., network port control, boundary defenses, encryption); system and
information integrity (e.g., 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;
(ii) Business continuity and disaster recovery planning and
resources, including, but not limited to, the controls and capabilities
described in paragraph (c) of this section; and any other elements of
business continuity and disaster recovery planning and resources
included in generally accepted best practices;
(iii) Capacity and performance planning, including, but not limited
to, controls for monitoring the derivatives clearing organization’s
systems to ensure adequate scalable capacity (e.g., 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;
(iv) Systems operations, including, but not limited to, system
maintenance; configuration management (e.g., 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;
(v) Systems development and quality assurance, including, but 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; and
(vi) Physical security and environmental controls, including, but
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.
(3) Standards for program. In addressing the elements listed under
paragraph (b)(2) of this section, a derivatives clearing organization
shall follow generally accepted standards and industry best practices
with respect to the development, operation, reliability, security, and
capacity of automated systems.
(4) Resources. A derivatives clearing organization shall establish
and maintain resources that allow for the fulfillment of each
obligation and responsibility of the derivatives clearing organization,
including the daily processing, clearing, and settlement of
transactions, in light of any risk to its operations and automated
systems. The derivatives clearing organization shall periodically
verify the adequacy of such resources.
(c) Business continuity and disaster recovery–(1) General. A
derivatives clearing organization shall establish and maintain a
business continuity and disaster recovery plan, emergency procedures,
and physical, technological, and personnel resources sufficient to
enable the timely recovery and resumption of operations and the
[[Page 80135]]
fulfillment of each obligation and responsibility of the derivatives
clearing organization, including, but not limited to, the daily
processing, clearing, and settlement of transactions, following any
disruption of its operations.
(2) Recovery time objective. A derivatives clearing organization’s
business continuity and disaster recovery plan, as described in
paragraph (c)(1) of this section, shall have, and the derivatives
clearing organization shall maintain physical, technological, and
personnel resources sufficient to meet, a recovery time objective of no
later than the next business day following a disruption.
(3) Coordination of plans. A derivatives clearing organization
shall, to the extent practicable:
(i) Coordinate its business continuity and disaster recovery plan
with those of its clearing members, in a manner adequate to enable
effective resumption of daily processing, clearing, and settlement of
transactions following a disruption;
(ii) Initiate and coordinate periodic, synchronized testing of its
business continuity and disaster recovery plan with those of its
clearing members; and
(iii) Ensure that its business continuity and disaster recovery
plan takes into account the plans of its providers of essential
services, including telecommunications, power, and water.
(d) Outsourcing. (1) A derivatives clearing organization shall
maintain the resources required under paragraphs (b)(4) and (c)(1) of
this section either:
(i) Using its own employees as personnel, and property that it
owns, licenses, or leases; or
(ii) Through written contractual arrangements with another
derivatives clearing organization or other service provider.
(2) Retention of responsibility. A derivatives clearing
organization that enters into a contractual outsourcing arrangement
shall retain complete responsibility for any failure to meet the
requirements specified in paragraphs (b) and (c) of this section. The
derivatives clearing organization must employ personnel with the
expertise necessary to enable it to supervise the service provider’s
delivery of the services.
(3) Testing of resources. The testing referred to in paragraph (e)
of this section shall apply to all of the derivatives clearing
organization’s own and outsourced resources, and shall verify that all
such resources will work together effectively. Where testing is
required to be conducted by an independent contractor, the derivatives
clearing organization shall engage a contractor that is independent
from both the derivatives clearing organization and any outside service
provider used to design, develop, or maintain the resources being
tested.
(e) Testing–(1) General. A derivatives clearing organization shall
conduct regular, periodic, and objective testing and review of:
(i) Its automated systems to ensure that they are reliable, secure,
and have adequate scalable capacity; and
(ii) Its business continuity and disaster recovery capabilities,
using testing protocols adequate to ensure that the derivatives
clearing organization’s backup resources are sufficient to meet the
requirements of paragraph (c) of this section.
(2) Vulnerability testing. A derivatives clearing organization
shall conduct vulnerability testing of a scope sufficient to satisfy
the requirements set forth in paragraph (e)(8) of this section.
(i) A derivatives clearing organization 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. Where indicated by appropriate risk analysis,
such scanning shall be conducted on an authenticated basis, e.g., using
log-in credentials. Where scanning is conducted on an unauthenticated
basis, the derivatives clearing organization shall implement effective
compensating controls.
(iii) A derivatives clearing organization shall engage independent
contractors to conduct two of the required quarterly vulnerability
tests each year. A derivatives clearing organization may conduct other
vulnerability testing by using employees of the derivatives clearing
organization who are not responsible for development or operation of
the systems or capabilities being tested.
(3) External penetration testing. A derivatives clearing
organization shall conduct external penetration testing of a scope
sufficient to satisfy the requirements set forth in paragraph (e)(8) of
this section.
(i) A derivatives clearing organization shall conduct such external
penetration testing at a frequency determined by an appropriate risk
analysis, but no less frequently than annually.
(ii) A derivatives clearing organization shall engage independent
contractors to conduct the required annual external penetration test. A
derivatives clearing organization may conduct other external
penetration testing by using employees of the derivatives clearing
organization who are not responsible for development or operation of
the systems or capabilities being tested.
(4) Internal penetration testing. A derivatives clearing
organization shall conduct internal penetration testing of a scope
sufficient to satisfy the requirements set forth in paragraph (e)(8) of
this section.
(i) A derivatives clearing organization shall conduct such internal
penetration testing at a frequency determined by an appropriate risk
analysis, but no less frequently than annually.
(ii) A derivatives clearing organization shall conduct internal
penetration testing by engaging independent contractors, or by using
employees of the derivatives clearing organization who are not
responsible for development or operation of the systems or capabilities
being tested.
(5) Controls testing. A derivatives clearing organization shall
conduct controls testing of a scope sufficient to satisfy the
requirements set forth in paragraph (e)(8) of this section.
(i) A derivatives clearing organization 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, but no less frequently than every two years.
A derivatives clearing organization may conduct such testing on a
rolling basis over the course of the period determined by such risk
analysis.
(ii) A derivatives clearing organization shall engage independent
contractors to test and assess the key controls, as determined by
appropriate risk analysis, included in the derivatives clearing
organization’s program of risk analysis and oversight no less
frequently than every two years. A derivatives clearing organization
may conduct any other controls testing required by this section by
using independent contractors or employees of the derivatives clearing
organization who are not responsible for development or operation of
the systems or capabilities being tested.
(6) Security incident response plan testing. A derivatives clearing
organization shall conduct security incident response plan testing
sufficient to satisfy the requirements set forth in paragraph (e)(8) of
this section.
(i) The derivatives clearing organization shall conduct such
security incident response plan testing at a frequency determined by an
appropriate risk analysis, but no less frequently than annually.
(ii) The derivatives clearing organization’s security incident
response plan shall include, without limitation, the derivatives
clearing organization’s definition and
[[Page 80136]]
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) The derivatives clearing organization 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) The derivatives clearing organization may conduct security
incident response plan testing by engaging independent contractors or
by using employees of the derivatives clearing organization who are not
responsible for development or operation of the systems or capabilities
being tested.
(7) Enterprise technology risk assessment. A derivatives clearing
organization shall conduct enterprise technology risk assessments of a
scope sufficient to satisfy the requirements set forth in paragraph
(e)(8) of this section.
(i) A derivatives clearing organization shall conduct an enterprise
technology risk assessment at a frequency determined by an appropriate
risk analysis, but no less frequently than annually.
(ii) A derivatives clearing organization may conduct enterprise
technology risk assessments by using independent contractors or
employees of the derivatives clearing organization not responsible for
development or operation of the systems or capabilities being assessed.
(8) Scope of testing and assessment. The scope of all testing and
assessment required by this section shall be broad enough to include
testing of all 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:
(i) Interfere with the derivatives clearing organization’s
operations or with fulfillment of its statutory and regulatory
responsibilities;
(ii) Impair or degrade the reliability, security, or capacity of
the derivatives clearing organization’s automated systems;
(iii) Add to, delete, modify, exfiltrate, or compromise the
integrity of any data related to the derivatives clearing
organization’s regulated activities; or
(iv) Undertake any other unauthorized action affecting the
derivatives clearing organization’s regulated activities or the
hardware or software used in connection with those activities.
(9) Internal reporting and review. Both the senior management and
the board of directors of the derivatives clearing organization shall
receive and review reports setting forth the results of the testing and
assessment required by this section. The derivatives clearing
organization shall establish and follow appropriate procedures for the
remediation of issues identified through such review, as provided in
paragraph (e)(10) of this section, and for evaluation of the
effectiveness of testing and assessment protocols.
(10) Remediation. A derivatives clearing organization shall analyze
the results of the testing and assessment required by this section to
identify all vulnerabilities and deficiencies in its systems. The
derivatives clearing organization shall remediate those vulnerabilities
and deficiencies to the extent necessary to enable the derivatives
clearing organization to fulfill the requirements of this chapter and
meet its statutory and regulatory obligations. Such remediation must be
timely in light of appropriate risk analysis with respect to the risks
presented by such vulnerabilities and deficiencies.
(f) Recordkeeping. A derivatives clearing organization shall
maintain, and provide to staff of the Division of Clearing and Risk, or
any successor division, promptly upon request, pursuant to Sec. 1.31
of this chapter:
(1) Current copies of the derivatives clearing organization’s
business continuity and disaster recovery plan and other emergency
procedures. Such plan and procedures shall be updated at a frequency
determined by an appropriate risk analysis, but no less frequently than
annually;
(2) All assessments of the derivatives clearing organization’s
operational risks or system safeguards-related controls;
(3) All reports concerning testing and assessment required by this
section, whether conducted by independent contractors or by employees
of the derivatives clearing organization; and
(4) All other documents requested by staff of the Division of
Clearing and Risk, or any successor division, 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 derivatives clearing organization’s automated
systems.
(5) Nothing in this paragraph (f) of this section shall be
interpreted as reducing or limiting in any way a derivatives clearing
organization’s obligation to comply with Sec. 1.31 of this chapter.
(g) Notice of exceptional events. A derivatives clearing
organization shall notify staff of the Division of Clearing and Risk,
or any successor division, promptly of:
(1) Any hardware or software malfunction, security incident, or
targeted threat that materially impairs, or creates a significant
likelihood of material impairment, of automated system operation,
reliability, security, or capacity; or
(2) Any activation of the derivatives clearing organization’s
business continuity and disaster recovery plan.
(h) Notice of planned changes. A derivatives clearing organization
shall provide staff of the Division of Clearing and Risk, or any
successor division, timely advance notice of all material:
(1) Planned changes to the derivatives clearing organization’s
automated systems that may impact the reliability, security, or
capacity of such systems; and
(2) Planned changes to the derivatives clearing organization’s
program of risk analysis and oversight.
0
3. Revise paragraphs (a), (b)(3), and (c) of Sec. 39.34 to read as
follows:
Sec. 39.34 System safeguards for systemically important derivatives
clearing organizations and subpart C derivatives clearing
organizations.
(a) Notwithstanding Sec. 39.18(c)(2), the business continuity and
disaster recovery plan described in Sec. 39.18(c)(1) for each
systemically important derivatives clearing organization and subpart C
derivatives clearing organization shall have the objective of enabling,
and the physical, technological, and personnel resources described in
Sec. 39.18(c)(1) shall be sufficient to enable, the systemically
important derivatives clearing organization or subpart C derivatives
clearing organization to recover its operations and resume daily
processing, clearing, and settlement no later than two hours following
the disruption, for any disruption including a wide-scale disruption.
(b) * * *
(3) The provisions of Sec. 39.18(d) shall apply to these resource
requirements.
(c) Each systemically important derivatives clearing organization
and subpart C derivatives clearing organization must conduct regular,
periodic tests of its business continuity and disaster recovery plans
and resources and its capacity to achieve the required recovery time
objective in the event of a wide-scale disruption. The
[[Page 80137]]
provisions of Sec. 39.18(e) shall apply to such testing.
* * * * *
Issued in Washington, DC, on December 17, 2015, 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 for Derivatives
Clearing Organizations–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 this proposed rule.
The risk of cyberattacks is perhaps the most important single
issue we face in terms of financial market stability and integrity.
The examples of cyberattacks or significant technological
disruptions from inside and outside the financial sector are all too
frequent and familiar.
Today, the aims of these attacks can go beyond traditional
financial motives. Today, we must be concerned about the possibility
of attacks intended to destroy information and disrupt or
destabilize our markets.
The risk to American businesses and the economy is dramatic. And
the interconnectedness of our financial institutions and markets
means that a failure in one institution can have significant
repercussions throughout the system.
The proposed rule that we are issuing today is an important step
toward enhancing the protections in our markets. It builds on our
core principles–which already require clearinghouses to focus on
system safeguards–by setting standards consistent with best
practices. It requires robust testing of cyber protections, setting
forth the types of testing that must be conducted, the frequency of
testing and whether tests should be conducted by independent
parties. In addition, it enhances standards for incident response
planning and enterprise technology risk assessments.
Our requirements should come as no surprise–clearinghouses
should already be doing extensive testing. Indeed, we hope that
today’s proposal sets a baseline that is already being met.
The proposal also complements what we as a Commission already
do. We focus on these issues in our examinations to determine
whether an institution is following good practices and paying
adequate attention to these risks at the board level and on down.
This rule is largely in line with another system safeguards
proposal that the Commission also approved today, which applies the
same standards to other critical market infrastructure.
Since the 2009 G-20 agreement and the enactment of Dodd-Frank,
clearinghouses have become increasingly important the financial
system. As a result, I believe we must do all we can to ensure their
strength and stability. This proposed rule is a critical component
of this effort.
I thank the staff for their hard work on this proposal. Of
course, we welcome public comment on both our system safeguards
proposals, which will be carefully taken into account before we take
any final action.
Appendix 3–Statement of Commissioner Sharon Y. Bowen
Today, we are considering two rule proposals that address an
issue which is right at the heart of systemic risk in our markets–
cybersecurity. The question that we face is: with a problem as
immense as cybercrime, and the many measures already being employed
to combat it, what would today’s proposed rules accomplish? In
answer to that question, I want to say a few words about our
cybercrime challenge, what is currently being done to address it,
and what I hope these proposed regulations would add to these
efforts.
The problem is clear–our firms are facing an unrelenting
onslaught of attacks from hackers with a number of motives ranging
from petty fraud to international cyberwarfare. We have all heard of
notable and sizable companies that have been the victim of
cybercrime, including: Sony, eBay, JPMorgan, Target, and Staples–
even the U.S. government has fallen victim.
In recent testimony before the House Committee on Financial
Services, Subcommittee on Oversight and Investigations about
cybercrime, the Director of the Center for Cyber and Homeland
Security noted that the “U.S. financial services sector in
particular is in the crosshairs as a primary target.” 1 He cited
one US bank which stated that it faced 30,000 cyber-attacks in one
week–averaging an attack every 34 seconds.2
—————————————————————————
1 Testimony of Frank J. Cilluffo, Director, Center for Cyber
and Homeland Security, Before the U.S. House of Representatives,
Committee on Financial Services, Subcommittee on Oversight and
Investigations, 1 (June 16, 2015) (noting that “the following
figures which were provided to me recently by a major U.S. bank on a
not-for-attribution basis: just last week, they faced 30,000 cyber-
attacks. This amounts to an attack every 34 seconds, each and every
day. And these are just the attacks that the bank actually knows
about, by virtue of a known malicious signature or IP address. As
for the source of the known attacks, approximately 22,000 came from
criminal organizations; and 400 from nation-states.”), available at
https://cchs.gwu.edu/sites/cchs.gwu.edu/files/downloads/A%20Global%20Perspective%20on%20Cyber%20Threats%20-%2015%20June%202015.pdf.
2 Id.
—————————————————————————
Given the magnitude of the problem, it is not at all surprising
that a lot is already being done to address it. The Department of
Homeland Security and others have been working with private firms to
shore up defenses. Regulators have certainly been active. The
Securities and Exchange Commission (SEC), the Federal Deposit
Insurance Corporation (FDIC), the Federal Reserve Board (FRB), the
Federal Housing Finance Agency (FHFA), and our self-regulatory
organization, the National Futures Association (NFA), have issued
cybersecurity guidance. In Europe, the Bank of England (BOE)
introduced the CBEST program to conduct penetration testing on
firms, based on the latest data on cybercrime. We heard a
presentation from the BOE about CBEST at a meeting of the Market
Risk Advisory Committee this year.
I wanted to hear what market participants were doing to address
the challenge of our cybersecurity landscape so I met with several
of our large registrant dealers and asked them about their
cybersecurity efforts. After these discussions, I was both alarmed
by the immensity of the problem and heartened by efforts of these
larger participants to meet that problem head on. They were
employing best practices such as reviewing the practices of their
third party providers, using third parties to audit systems, sharing
information with other market participants, integrating
cybersecurity risk management into their governance structure, and
staying in communication with their regulators.
We have also been vigilant in our efforts to address
cybersecurity. Under our current rule structure, many of our
registrants have system safeguards requirements. They require, among
other things, that the registrants have policies and resources for
risk analysis and oversight with respect to their operations and
automated systems, as well as reporting, recordkeeping, testing, and
coordination with service providers. These requirements clearly
include appropriate cybersecurity measures. We also regularly
examine registrants for their adherence to the system safeguards
requirements, including effective governance, use of resources,
appropriate policies, and vigilant response to attacks.
So if all of this is happening, what would more regulation
accomplish? In other words, what is the “value add” of the rules
being proposed today? The answer is: A great deal. While some firms
are clearly engaging in best practices, we have no guarantee that
all of them are. And as I have said before, in a system as
electronically interconnected as our financial markets, “we’re
collectively only as strong as our weakest link, and so we need a
high baseline level of protection for everyone . . .” 3 We need
to incentivize all firms under our purview to engage in these
effective practices.
—————————————————————————
3 Commissioner Sharon Y. Bowen, Commodity Futures Trading
Commission, “Remarks of CFTC Commissioner Sharon Y. Bowen Before
the 17th Annual OpRisk North America,” March 25, 2015, available at
http://www.cftc.gov/PressRoom/SpeechesTestimony/opabowen-2.
—————————————————————————
We have to do this carefully though because once a regulator
inserts itself into the cybersecurity landscape at a firm–the firm
now has two concerns: Not just fighting the attackers, but managing
its reputation with its regulator. So, if not done carefully, a
regulator’s attempt to bolster cybersecurity at a firm can instead
undermine it by incentivizing the firm to cover up any weaknesses in
its cybersecurity
[[Page 80138]]
infrastructure, instead of addressing them. Further, we must be
careful not to mandate a one-size-fits-all standard because firms
are different. Thus, we must be thoughtful about how to engage on
this issue. We need to encourage best practices, while not hampering
firms’ ability to customize their risk management plan to address
their cybersecurity threats.
I think these rulemakings are a great first step in
accomplishing that balance. 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
Infrastructure Cybersecurity (“NIST Framework”).4
—————————————————————————
4 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.
—————————————————————————
In all, I think the staff has put together two thoughtful
proposals. Clearly, however, this is only a first step since all our
registrants, not just exchanges, SEFs, SDRs and DCOs, need to have
clear cybersecurity measures in place. I am also very eager to hear
what the general public has to say about these proposals. Do they go
far enough to incentivize appropriate cybersecurity measures? Are
they too burdensome for firms that do not pose significant risk to
the system? And given that this is a dynamic field with a constantly
evolving set of threats, what next steps should we take to address
cybercrime? Please send in all your thoughts for our consideration.
[FR Doc. 2015-32144 Filed 12-22-15; 8:45 am]
BILLING CODE 6351-01-P
Last Updated: December 23, 2015
[ad_2]
Source link
