Chesney on Cybersecurity Law,
Policy, and Institutions
v.3.1 (August 2021)
Professor Bobby Chesney
The University of Texas at Austin
@bobbychesney

About this book: This is an interdisciplinary “eCasebook,” designed from the ground up to reflect the
intertwined nature of the legal and policy questions associated with cybersecurity. My aim is to help the
reader understand the nature and functions of the various government and private-sector actors associated
with cybersecurity in the United States, the policy goals they pursue, the issues and challenges they face,
and the legal environment in which all of this takes place. The first part of the book focuses on the “defensive”
perspective (meaning that we will assume an overarching policy goal of minimizing unauthorized access to
or disruption of computer systems). The second part focuses on the “offensive” perspective (meaning that
there are contexts in which unauthorized access or disruption might actually be desirable as a matter of
policy). In short, the book is a guided tour of the broad cybersecurity landscape.
Who should use it? The book is designed to be valuable not just to beginners but also those who may have
experience in one area but would like to see how their corner of the puzzle relates to the larger whole. At
the University of Texas, I use it as the main text in an interdisciplinary course that includes students from our
schools of law, public affairs, computer science, engineering, information, communications, and business.
My aim is for it to work equally well, however, as a free-standing text for those who want to study these topics
independently.
Why did you write this book and why is it free? I wrote this book under the auspices of the interdisciplinary
cybersecurity program at UT’s Robert Strauss Center for International Security and Law, with generous support
from the Hewlett Foundation’s Cyber Initiative.1 We believe that progress in this area has been inhibited to
an unnecessary degree by a lack of mutual understanding among lawyers, engineers, computer scientists,
government officials, and business leaders, and we have set out to develop courses that will help close that
gap. Wanting to ensure the widest possible distribution and impact in light of this goal, and to have the
option to quickly and easily update the text when needed, I opted to make the book freely available online
rather than selling it through a publisher. I hope you’ll find the end result appealing, even if it is much lessformal and polished than would have been the case otherwise. And, if you do, I hope you will further the
mission by recommending the book to others.
Copyright? I’m providing access to this work under the terms of a Creative Commons Attribution 4.0
International (CC BY 4.0) license: https://creativecommons.org/licenses/by/4.0/. You are free to use some or
all of it as you wish (that’s one reason why I’ve posted a .doc version along with the .pdf), so long as you (1)
cite the book as indicated below, (2) give appropriate indications of changes made by you, and (3) link to
the license. Here is the requested citation:
ROBERT M. CHESNEY, CHESNEY ON CYBERSECURITY LAW, POLICY, AND INSTITUTIONS (v.3.1) (2021), available at
https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3547103 (this work is licensed under a
Creative Commons Attribution 4.0 International license
https://creativecommons.org/licenses/by/4.0/).
I make no copyright claim, of course, as to any public-domain works excerpts included in this work, such as
quotations from cases or statutes. Nor is any claim made as to any other materials that I have included in
this work pursuant to a copyright exception or limitation such as fair use.

1 I extend special thanks to Rachael Jensen for her outstanding research and teaching assistance, especially her key role

in adapting earlier versions of these readings into the current format, and to Eli Sugarman of the Hewlett Foundation.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

2

Table of Contents
I. THE DEFENSIVE PERSPECTIVE ...................................................................................... 3
A. Introduction ........................................................................................................... 3
1. Holiday Bear and SolarWinds: A Case Study ................................................ 11
2. Introduction to Key Terms and Concepts ..................................................... 11
B. Imposing Costs on Attackers .............................................................................. 17
3. The Crime Model: Key Institutions and the CFAA ........................................ 17
4. CFAA Case Studies .......................................................................................... 22
5. Other Criminal Statutes ................................................................................... 24
6. Civil Liability under the CFAA .......................................................................... 30
7. What if the Attacker is a Foreign Government? (I) ...................................... 43
8. What if the Attacker is a Foreign Government? (II)...................................... 46
9. What if the Attacker is a Foreign Government (III) ....................................... 57
10. What if the Attacker is a Foreign Government? (IV) .................................. 63
C. Encouraging Potential Victims to Defend Better ............................................ 66
11. The Role of Regulators (I) .............................................................................. 67
12. The Role of Regulators (II).............................................................................. 75
13. Private Lawsuits (I) .......................................................................................... 84
14. Private Lawsuits (II); Insurance & Contract Terms ..................................... 104
15. Facilitating Better Defense through Information-Sharing (I) .................... 114
16. Facilitating Better Defense through Information-Sharing (II) ................... 129
17. How the Government Protects Itself (I)...................................................... 144
18. How the Government Protects Itself (II) ..................................................... 158
19. Improving Cybersecurity for the Nation’s Critical infrastructure ............. 170
D. Organizing to Mitigate Harm ........................................................................... 184
20. Federal Coordination and Significant Cyber Incidents .......................... 185
II. THE OFFENSIVE PERSPECTIVE ................................................................................. 199
21. Lawful-But-Unauthorized-Access: Private Sector Hacking? .................... 200
22. Government Hacking: Law Enforcement ................................................. 209
23. The Insecurity Industry .................................................................................. 217
24. Government Hacking: Espionage.............................................................. 231
25. Government Hacking: Armed Conflict ..................................................... 247
26. Government Hacking: Grey-Zone Competition ....................................... 259

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

3

I. THE DEFENSIVE PERSPECTIVE
For the first part of this book, we will focus on the defensive perspective. That is, we will focus on
the overarching public-policy goals of (i) minimizing unauthorized access, disruption,
manipulation, and damage to computers and (ii) mitigating the harm when such malicious
activity nonetheless occurs.
When it comes to the first of those two core goals, the main idea is simple: we want to increase
the undesirable consequences attackers believe they will risk should they attempt certain actions,
while also making it more difficult for them to succeed. Part B below focuses of the former, and
Part C below focuses on the latter. In both contexts, our goal is to understand the various
institutions, policies, and legal frameworks that define the status quo on these matters; to grasp
the competing interests that are in play; and to wrestle with the question of how we might do
better. Part D then takes up the second major goal noted above: managing the consequences
of successful attacks. Before we dive into all that, however, we will launch into things in Part A with
two introductory readings, to help build a common foundation for all that follows.

A. Introduction
1. Holiday Bear and SolarWinds: A Case Study

Southwest Parkway is a wide and winding road that leads away from Austin towards the Texas Hill
Country. Along its length are neighborhoods, schools, and long stretches of open landscape. It is
not where one might expect to find the epicenter of a major cybersecurity episode. But Southwest
Parkways also is where one can find the unassuming headquarters of SolarWinds, a name that
burst into the headlines in December 2020.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

4

SolarWinds specializes in network-management tools—that is, software that large enterprises use
to monitor and control conditions throughout their information technology environment. Its
products are in widespread use around the world, including a wide array of prominent private
sector entities and government agencies. Among its most successful products is a networkmonitoring system called Orion. Orion is an “on premises” platform, meaning that it does not reside
in the cloud (that is, on remote servers controlled by SolarWinds itself). Rather, customers upload
Orion as a software package installed on their own networks and run from there. And this has
consequences for the process by which Orion periodically is updated. Like any software, Orion
periodically requires updates both for security purposes and to improve performance. Thus, Orion
customers periodically receive and routinely install from SolarWinds software updates, much as all
of us periodically accept vendor-provided updates for the operating system on our phones. In
both contexts, the provider “digitally signs” the update in a way that can be verified technically,
ensuring that the update really is coming from the provider. Trusting that the provider took all
necessary safety precautions, and often lacking the means to conduct an independent security
check in any event, most of us accept these verified updates as a matter of course. This is true for
us as individuals with our phones, and it is true to some extent for many a large organization,
including those using Orion.
Therein lay an extraordinary opportunity for espionage. If a would-be spy could “trojan” an Orion
update—that is, if one could find a way to embed malicious code somewhere within an
otherwise-legitimate update—then customers by the thousands would open their virtual gates
and let that code into their networks. And given the particular function of Orion—spanning across
a user’s IT infrastructure—the resulting backdoors, if employed discretely enough, might then pave
the way for deployment of further malware directly into those now-compromised networks. The
end result could be an intelligence bonanza.
The opportunity would have been tempting for any foreign intelligence service engaged in
collection against the U.S. government. And at least one such service did spot it: Russia’s Foreign
Intelligence Service, better known in English as SVR (Sluzbha Vneshney Razvedki).
SVR has a well-deserved reputation for its ability to conduct espionage through cyber means.
Hackers associated with SVR sometimes are referred to as “Advanced Persistent Threat 29”
(APT29), under the anodyne labeling system frequently used in the information security industry as
a way to track government hackers without having to expressly attribute particular campaigns or
entities to the actual government involved. Others have used the label “Cozy Bear,” following
the more-entertaining naming system popularized by Dmitri Alperovich and the security firm
CrowdStrike. With Crowdstrike’s nomenclature, groups believed to be linked to the Russian
government are named some variation of “Bear.” A group thought to be associated with Russia’s
military intelligence agency (GRU), for example, are known in this system as “Fancy Bear.” And
so, when a possibly-new group of hackers linked to Russia emerges, a new name may follow. And
in this case, when the SolarWinds story began to break in December 2020, the initial framing
offered by Dmitri Alperovich was the seasonally-appropriate “Holiday Bear.”
Since that time, attribution has focused firmly and reliably on SVR, but I will still refer periodically to
Holiday Bear. This will remind us that analysts wrestling with attribution amidst unfolding attacks
often are drawing on forensic and contextual clues that may be specific to specific groups within
larger organizations.
What follows is a detailed account of the complex sequence of operations SVR conducted as
part of the Holiday Bear campaign. As we shall see, exploiting SolarWinds was a central part of
the campaign, but there is far more to the story than that (indeed, the intense media focus on
SolarWinds has had the unfortunate effect of deflecting attention from the shortcomings of other
companies and government agencies).

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

5

Step one: accessing the SolarWinds “build environment”
It is one thing to recognize that SolarWinds customers might not detect a trojaned Orion update,
but quite another to compromise the update system in the first place. The task SVR first faced,
accordingly, was to sort out how it could penetrate without detection the “build environment”
(aka “development environment”) used by SolarWinds engineers to draft and tinker with Orion’s
code. Then SVR would need to find a way to inject malicious code into an Orion “build” without
detection. These were tall orders.
SVR managed both tasks, but we do not (yet) know precisely how. There are plenty of plausible
explanations, however. Perhaps it spearphished an employee’s credentials (that is: tailoring a
fake message for that particular employee and thereby tricking them into opening a malwarelaced file and thereby gaining access to the person’s legitimate login credentials). Perhaps it
simply engaged in password “spraying” until it hit upon something that worked (famously, a
security researcher in 2019 had discovered the password for an unrelated SolarWinds server stored
in a GitHub repository; the password was “password123”). Perhaps SVR hacked its way into the
build environment, taking advantage of vulnerabilities or configuration errors in the software used
by SolarWinds engineers to perform their development work. All of these are common routes to
initial exploitation, and any could have been the culprit here. At any rate, SVR managed it. No
later than early September 2019 (and possibly as early as January 2019), SVR established access
to the build environment.
Step two: injecting malware into an Orion update
SVR’s next step was to test drive its access by inserting some innocuous code into the build
environment, to see if this could be done without detection. In fall 2019, SVR dipped its toes into
the water, inserting a modest batch of innocuous code. It worked; the addition was not detected.
Exhibiting remarkable patience, SVR continued with similar experiments for months before at last
taking advantage of this access to inject actual malware into an Orion build. It took that step in
February 2020.
To accomplish this, SVR used malware now known to us as “SUNSPOT.” SUNSPOT was thoughtfully
designed for its task. Once deployed into the build environment, it determined whether a
particular development tool (Microsoft Visual Studio) was in use by the SolarWinds engineers at
that time. If so, SUNSPOT then checked to see if that tool was being used for an Orion build in
particular. If so, SUNSPOT monitored to determine precisely when the developers used that tool
to access a particular part of the Orion source code, and at that moment SUNSPOT injected a file
with the plausible-sounding name “SolarWinds.Orion.Core.BusinessLayer.dll” into the Orion build.
That .dll file was, in fact, a custom malware package known to us now as “SUNBURST.”
It might help at this point to draw out the analogy to the Trojan Horse. If the eventual distribution
of a corrupted Orion update was the cyber equivalent to that giant wooden horse being brought
within the walls of the city of Troy, then SUNBURST was the equivalent of the small squad of Greek
warriors hiding within the horse, prepared to sneak out and quietly open a side gate in those walls
and thus allows their fellows to pour in undetected. From that perspective, SVR’s success in
loading SUNBURST into the Orion build was equivalent to loading that squad of Greek warriors into
the horse prior to presenting the horse at the city’s gates; it remained to be seen if the Trojans
would take the horse within their walls or if the squad hidden within could manage to open a gate
from the inside without getting caught.
In the event, it unfolded exactly as SVR hoped. SolarWinds did not detect the compromise of their
latest Orion update, and hence proceeded to digitally sign it and roll it out to customers though
the existing, trusted remote-update mechanism. That process began in March 2020 and
continued for a few months. The horse was now within the walls for a vast array of customers. The
spread might have gone further, in fact, but at that point SVR apparently concluded that it had

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

6

achieved sufficient distribution. Rather than risk someone at SolarWinds detecting the compromise
of its build environment and unspooling the entire campaign, SVR at that point did what it could
delete its access to the build environment, covering its tracks as well as it could.
At this point, some 18,000 customers had downloaded the trojaned Orion update. Among them
were several U.S. government agencies, including the Departments of Treasury, State, Commerce,
Energy, and Homeland Security.
Step three: deciding where to take advantage of SUNBURST
In theory, SVR could have blindly exploited all infected systems to the maximum extent possible.
But doing so would have increased the opportunities for detection, with the potential to expose
and thus put an end to the entire campaign. Rather than run such risks, SVR instead chose to
proceed slowly and narrowly, with an emphasis on remaining undetected while carefully
identifying which of the infected customers best fit their specific collection priorities.
In every instance, SUNBURST took no action at all for approximately two weeks once installed on
the customer’s premises. This put some distance between its eventual actions and the upload
process. Then, when it did finally come alive, its first action was to perform a complex series of
checks designed to determine whether various security products were in operation on the system.
Where such products were detected, SUNBURST disabled them if possible, but otherwise simply
shut itself down without taking further action. Only if and when it passed these safety checks
would SUNBURST go on to its next step: communicating with an external command-and-control
(C2) server. In Trojan horse terms, the warriors in the horse had waited two full weeks, and after
making sure no one was watching they moved at last moved to open up a side gate.
To minimize the risk that its communications with a C2 server would not draw attention, SVR
attempted to disguise this malicious traffic. This was made easier by the fact that on-premises
instances of Orion routinely had to communicate with SolarWinds as part of what SolarWinds calls
the “Orion Improvement Program” (much as an iPhone user might click yes when asked if it is ok
for our phone to share information with Apple about how we are using Siri, in order to help Apple
improve the product or better tailor it to our usage patterns). SVR accordingly designed
SUNBURST’s communications with C2 servers so as to appear, on casual inspection, to be part of
that legitimate traffic flow. The ruse appears to have been highly effective. Among other things,
this illustrates that victims typically were not limiting Orion’s external communications in a way that
would limit them to specifically pre-approved (“allow-listed”) domains, or that would at least flag
for attention any communications to a non-pre-approved domain.
Critically, the initial communication did not automatically result in SVR dispatching additional
malware. The first task, instead, was to enable SVR to decide whether to exploit that particular
victim or, instead to cover its tracks by uninstalling SUNBURST from that location. Towards that end,
SUNBURST dispatched location information that SVR in turn used to make a judgment about the
identity of the infected system. In most cases, it appears, the system in question proved not to be
of interest, and SVR uninstalled SUNBURST frequently. But not in all cases. SVR had hit the jackpot
in plenty of instances, and now it was time to move on to the active-exploitation stage.
Step four: injecting the tools needed to act effectively within targeted systems
Notably, SUNBURST did not itself contain the tools needed to engage in lateral movement within
the compromised networks, to conduct data exfiltration, and to engage in other aspects of active
exploitation. It was a slim design, reflecting the premium SVR placed on detection-avoidance at
the initial stage. SUNBURST contained no more than was necessary to reach the point that it could
open a backdoor to a C2 server. Put simply: in order to actively exploit an infected system, SVR
needed to use SUNBURST to inject additional malware.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

7

But how to do so without that fresh injection of malware being detected at the victim’s perimeter
by their network’s antivirus capability? This is a classic problem that hackers have long faced. Of
course, one might try to overcome it by developing sophisticated, never-seen-elsewhere custom
malware that might not be detected by security software that scans for known indicators of
compromise. That’s not a realistic option for many attackers, and even where it is, it remains
tempting to instead make use of “retail” malware that already exists and has a long track record
of reliability and effectiveness. If such commonplace tools can be injected without detection,
even sophisticated entities like SVR will make use of them.
These considerations over time have led to the development of a category of malware tools
known as “droppers” and “loaders.” These are programs that hide within themselves some
otherwise-detectable malware payload. The idea with a dropper is that the attacker might be
able to install the dropper on a targeted system without detection, at which the dropper will
unpack and install the core malware payload. Loaders are similar, but rather than containing the
malware payload within themselves all along, they provide a (more secure) means to download
the payload surreptitiously from an external server. Both have the effect, at any rate, of reducing
detection risk at the stage when a malware payload must transit a system’s perimeter, thus making
it more attractive to rely on retail malware.
That’s the route SVR took with the SUNBURST-infected systems that it targeted for active
exploitation. Specifically, SVR developed what is now called TEARDROP. TEARDROP was a novel
dropper that SVR could load into compromised systems via SUNBURST, with little risk of detection
at victims’ network perimeter. SVR also deployed a novel loader, RAINDROP, for the same
purpose.
In this way, SVR successfully injected the toolkit it needed for active exploitation of its priority
targets, despite the fact that the toolkit it chose to use was, very much, a well-known one: Cobalt
Strike.
Cobalt Strike is a commercial product sold by the Minnesota company HelpSystems as a tool for
use in attack simulations and penetration testing. That is to say, it is meant to be a pro-security
product, emulating what a real attacker might do. The Cobalt Strike BEACON capability, for
example, provides a range of capabilities comparable to what a sophisticated, genuine attacker
might employ. All of which is quite useful from the defense-improvement perspective, when
actually used for testing purposes. But real attackers also find these tools useful. As the firm Intel471
recently wrote, “criminals love” Cobalt Strike, and it has “become a very common second-stage
payload for many malware campaigns….”
SVR apparently loves it too, for rather than using TEARDROP and RAINDROP to inject bespoke (SVRmade) tools at this stage in the operation (as they had done at every prior stage), they instead
went with what amounted to a somewhat-customized version of Cobalt Strike BEACON.
Some have suggested that this was a significant mistake on SVR’s part, since there are techniques
available to detect the presence of BEACON on a network. Yet it does not appear that any of
the targeted entities actually detected BEACON in use before otherwise learning of the
SolarWinds campaign. SVR did take steps to hide what was occurring, after all. To execute a file,
for example, it would temporarily replace a legitimate file with a malicious one, execute that file
(at times doing so by temporarily modifying a legitimate scheduled task so that it would issue the
command to execute the file), and then restore the original. And, in any event, SVR may have
had the notion that using such common tools might actually make it more difficult for investigators
to attribute the operation to it, and by extension make it less likely that the larger campaign would
be undone by exposure of any one instance (relatedly, SVR ensured that each deployed instance
of BEACON varied from the others in terms of file names and other otherwise-matchable details,

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

8

thus reducing the chance that detection by one victim would result in the sharing of indicatorsof-compromise that could be used effectively by other victims).
Step five: swimming upstream to the cloud
At this point, SVR was well-established within victims’ own local (on premises) servers and systems.
And if that was where to find the richest intelligence, the table would have been fully set for
espionage success. But for a growing number of organizations—including government entities—
the on-prem environment is not where one will find most of the information an intelligence
collector would value. Increasingly, organizations rely on cloud services for email and documents.
This is true, for example, for organizations that rely on the Microsoft 365 (“M365”) product suite,
which encompasses, among other things, the Microsoft Office software suite (Outlook for email,
Word for documents, PowerPoint for slides, and Excel for spreadsheets), or that use Microsoft’s
Azure cloud services (just as the same would be true for an organization that instead used the
cloud services of other providers, such as Amazon’s AWS cloud services).
Not surprisingly, this was true for many of the entities SVR had compromised via Orion, especially
with respect to using M365. In those case, accordingly, SVR had more work to do even after
getting BEACON into the on-prem environment. To get the intelligence it actually sought—to
realize the purpose of the whole effort—it next needed to swim upstream from its on-premises
foothold into the M365 cloud environment.
This brings us to an important and underappreciated aspect of the “SolarWinds” story: it is just as
much a Microsoft story. The SolarWinds framing is understandable, of course, given the breadth
of the compromises that resulted from the breach of that one company’s own security. But from
SVR’s perspective, what ultimately mattered was accessing the M365 cloud environment. Orion
was one (very attractive and scalable) pathway to get to the doorstep, but it was not the only
such pathway. Indeed, in a security advisory released on January 8, 2021, CISA revealed that it
was “investigating instances in which [SVR] may have obtained initial access” not via Orion but,
rather, “by Password Guessing…, Password Spraying…, and/or exploiting inappropriately secured
administrative or service credentials…instead of utilizing the compromised SolarWinds Orion
products.” Soon thereafter, the firm Malwarebytes revealed publicly that it too had been
“recently targeted by the same threat actor,” and that it could “confirm the existence of another
intrusion vector that works by abusing applications [other than Orion] with privileged access to
Microsoft Office 365 and Azure environments.”
How did SVR make the leap to the cloud from within customer systems? It appears it used multiple
pathways, one of which is known as the “Golden SAML” approach. This method overcomes the
critical identity authentication process that normally precludes unauthorized users from accessing
cloud-based accounts. More specifically, it is a method that works for systems that use “Active
Directory Federation Services,” or ADFS, to connect users with cloud-based services like M365. The
basic idea with ADFS is that when a user goes to log in to the cloud service, that service directs
the request to a particular server (the ADFS server) to validate the user’s identity. If the ADFS server
approves the credentials, it issues a token to the cloud service that confirms the user’s legitimacy
and enabling access. For obvious reasons, then, the security of the ADFS server itself is critical. In
particular, the private encryption key and signing certificate for that server are critical. Which
brings us to the heart of the Golden SAML approach: if the attacker gains access to the private
key, this in turn leads to the ability to issue tokens, and that then opens the door to accessing the
accounts associated with that ADFS server.
That was one way that SVR began strolling through the 365 accounts of its victims. One of the
other methods later identified by FireEye was similar: the creation within Azure Active Directory
(Azure AD) of entirely new domains approved to function as a trusted third-party “identity
provider”—that is, as a provider of authentication services such as those described above.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

9

Whichever particular pathway was taken, however, the fundamental approach was the same:
leveraging the client’s own credentials so as to circumvent cloud identity-authentication
safeguards from the inside. At this point, it was simply a question of whether anyone would notice
unusual patterns of account access and other account activity. For a long time, no one did.
Step six: don’t get caught
What changed? SVR’s luck ran out. It was extracting material from a variety of private victims,
not just government agencies. One of these, as it happened, was the cybersecurity company
FireEye, and at some point FireEye detected what was happening.
On December 8, 2020, Kevin Mandia published the jaw-dropping news that someone had
penetrated FireEye’s systems and gotten away with their pen-testing tools. The sophistication of
the attack suggested it was the work of a nation-state actor, in Mandia’s opinion, as did the fact
that the attacker also apparently attempted to learn things about FireEye’s government
customers. Five days later, Mandia announced as a follow-up that FireEye had “identified a
global campaign that introduces a compromise into the networks of public and private
organizations through the software supply chain.” In particular, Mandia explained, the campaign
exploited the update mechanism for SolarWinds Orion.” It was a stunning turn of events, with
holiday-wrecking implications for thousands-upon-thousands of SolarWinds customers.
Given the scale and potential impact of the operation, it was clear early on that the episode
constituted a “significant cyber incident”—that is, an incident of sufficiently-serious nature to
warrant formal federal government interagency coordination efforts—under the U.S.
government’s National Cyber Response Plan. In practical terms, this meant that the federal
government would form an interagency “Cyber Unified Coordination Group” (UCG) as the focal
point for cooperation and deconfliction among FBI (as the lead agency for what the government
calls “threat response”), CISA (as the lead agency for “asset response”), and ODNI with NSA
support (as the lead agency for “intelligence support and related activities”). By January 5, the
UCG was ready to go on the record with a (very) limited degree of public attribution, declaring
their collective belief that the attacker was “likely Russian in origin.” This was a far cry from blaming
the Russian government directly, but it was a beginning. Meanwhile, private sector experts were
more explicit about the attribution. Dmitri Alperovitch and David Cross used the label “Holiday
Bear” in an interview on Patrick Gray’s Risky Business show (a weekly must-listen for everyone
interested in cybersecurity) as a way to capture their view that a Russian government actor was
responsible, even it if was not yet clear which precise actor it was.
Eventually, the US government would state in no uncertain terms that it was the SVR, specifically,
that conducted the operation: “Today the United States if formally naming the Russian Foreign
Intelligence Service (SVR), also known as APT 29, Cozy Bear, and The Dukes, as the perpetrator of
the broad-scope cyber espionage campaign that exploited the SolarWinds Orion platform and
other information technology infrastructures. The U.S. Intelligence Community has high confidence
in its assessment of attribution to the SVR.”

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

10

Consider the following questions and prepare to discuss them in class:
•
•
•
•

•
•
•
•

•

Was it wrong, in some normative sense, for SVR to conduct this campaign?
Must the answer to that question be yes to justify efforts to defeat such campaigns?
Must the answer to the first question be yes to justify efforts to impose costs on Russia
for conducting the campaign?
You may have read about other recent high-profile cybersecurity challenges, such as
a ransomware episode targeting Colonial Pipeline which resulted in operational
disruptions with massive practical consequences, particularly on the East Coast.
Should we view that sort of event the same as the Holiday Bear campaign?
When analyzing actions by foreign actors in this space, do practices of US
government agencies matter? What about actions of individual US non-state actors?
Who, if anyone, bears meaningful responsibility for failing to prevent or detect the
Holiday Bear campaign?
Should private companies be liable for damages when their products are exploited?
Be prepared to discuss this with reference to SolarWinds, HelpSystems, and Microsoft.
Consider the performance of the federal agencies at issue in this account. Later in the
book we will learn about how the federal government is organized to defend itself on
such matters, but for now we must still ask: based on what is in the public record, are
these agencies partially at fault?
If you were president, what action if any would you take once you were confident of
SVR’s responsibility for this campaign?

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

11

2. Introduction to Key Terms and Concepts

Our aim in this reading is to build common ground regarding a variety of key concepts and terms
associated with cybersecurity.
A. About those “attackers”
In this book we often will use the word “attacker” as a shorthand referring to a person or
organization that seeks to access, disrupt, manipulate, or damage a system in an unauthorized
way. Attackers come in many shapes and sizes. Some are sophisticated professionals, others are
rank amateurs. Some are state-sponsored, some are part of non-state organizations (and some
of these nonetheless sometimes work on behalf of states), and some are individuals. Some are
crooks. Some are spies. Some are just showing off skills. Some are in it for the laughs. Some do it
to settle personal scores. Some are seeking competitive advantage. Some mean well, hoping to
spur people to increase their defenses by exposing weaknesses in hopes that they’ll be remedied.
Some are malicious, hoping to cause harm (or to use your system to cause harm to others). The
point being, there are many potential attackers out there, with a wide variety of motives and
capacities, some awful and others laudable.
B. Core Goals Associated with the Security of Information
There is a particular organizing principle often used to explain the core goals of information
security (“infosec”): the “CIA Triad.” That’s not a reference to the Central Intelligence Agency.
Rather, the acronym refers to three distinct defensive policy goals: preserving the confidentiality,
integrity, and availability of information.
Confidentiality:
You may sometimes be happy to expose certain information to the world, but often you’ll
want to control access to it. Ensuring the confidentiality of information means just that––

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

12

ensuring that people can access it only in accordance with the terms the owner of the
information sets. We can also refer to this as privacy, though “confidentiality” fits a bit
better and is more commonly used in this setting. Those who gain unauthorized access to
an information system can cause harm, from this point of view, by violating
confidentiality—either by just reading the information or exfiltrating a copy of it out of the
system.
Integrity:
In addition to controlling the confidentiality of information, we also commonly wish to
ensure that information is not altered or destroyed in an unauthorized way. Those who
gain unauthorized access to a system at a level permitting alteration of data are thus in a
position to cause harm to the integrity of the information.
Availability:
Another goal for the security of information systems is to ensure systems work as intended—
that is, that the information remains available for its intended use. An attacker who cannot
pierce the confidentiality of information or harm its integrity might nonetheless be able to
disrupt access to it, causing harm to the availability of the information. And notice, too,
that measures one might take to protect against harms to the confidentiality and integrity
of a might impose undue costs along the availability dimension.
In short, the overarching goal of cybersecurity from the defensive perspective is to prevent (or, at
least, minimize) unauthorized, harmful actions along any of these dimensions.
C. More Key Terms
Vulnerability:
In any system, there are latent weaknesses. Those weaknesses present opportunities that
might be exploited purposefully (or even just accidentally) to cause the system to perform
in a way its owner does not intend. This is endemic to software. The code that comprises
software tends to be complex, sometimes mind-bogglingly so. Vulnerabilities—also known
as “bugs” or “vulns”—are bound to be there. Some are easily spotted, and some require
sheer genius or blind luck to discover. Some are easily remedied (that is, “patched” by a
change to the code in question), but some cannot readily be fixed without disrupting the
functionality of the code.
Note: Just because a vuln has been identified does not mean the creator/supplier of the
software at issue will develop a patch. And even if a patch is developed, it does not follow
that everyone using that software will apply the patch. Many vulns remain useful to
attackers long, long after their existence is discovered and a patch developed.
Exploit:
Just knowing that vuln exists is not enough to provide someone with unauthorized access
to a system––some further step is required to take advantage of the vuln. An “exploit” is a
program or technique that takes advantage of a vuln in order to achieve some
unauthorized effect within the system.
Note: An attacker may not immediately have access to all parts of the system at issue.
“Privilege escalation” refers to additional steps that extend the attacker's unauthorized

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

13

access. An “exploit chain” refers to the combination of programs and techniques that an
attacker assembles to gain access to a system, escalate privileges within it, and then
perhaps to take further actions.
Disclosure:
A person who discovers a vulnerability (or, for that matter, who identifies an exploit
targeting a vulnerability) might choose to disclose the information to some responsible
party, such as the creator of the software that suffers from the vulnerability or to a public
database of known vulns. Some companies actually pay bounties for such information
through “bug bounty programs,” but then again, some companies have unfortunately
suspicious (or worse) reactions to receiving such information out of the blue––especially if
they perceive the situation as an extortion attempt. Meanwhile, not everyone who
discovers a vuln is inclined to disclose it. Some would prefer to sell the information on the
black market, or even keep it for their own eventual use.
A “zero-day vulnerability” is a vulnerability that has not been disclosed. The name reflects
the fact that is has been zero days since disclosure, and thus there is not yet a patch for
the vuln (let alone distribution of a patch). Many assume that this makes zero-day vulns
the most valuable bugs. But, in fact, the value of a vuln depends on many factors,
especially the nature of the access that follows when the vuln is exploited successfully.
There are many, many, many more n-day vulns (i.e., vulns that were disclosed n days ago,
with n simply being a variable reflecting the number of days in a particular, actual
instance), and some have considerable continuing value. Conversely, some zero-days
are not particularly valuable.
Note: The fact that a company receives notification of a bug does not mean the
company will necessarily work to develop a patch for it. Most companies have a primary
mission (selling products or services) where they would prefer to spend their resources.
Investing the time, money, and labor in increasing cybersecurity diverts resources away
from profit-seeking projects. And so, when a company is alerted to a vulnerability in its
system, it will undoubtedly weigh the costs and benefits associated with patching it.
Social Engineering:
Alas, the greatest and most persistent vulnerability is, well, us. “Social engineering” means
tricking people into revealing information or otherwise taking an action that make it
possible for someone to gain unauthorized access to a system. This can be as simple as
tricking someone into sharing a password, or as complicated as developing a highly
customized email designed to get the target to open an attachment that contains
malware.
“Phishing” is the generic term for tricking someone into opening an attachment or clicking
a link that opens the door for malware to access a system. “Spear phishing” is when the
inducement is tailored to the target––for example, an email that appears to be from a
coworker asking you to review an attached document.
Another category of human vulnerability involves “insider threats”—that is, people within
an organization who properly have access to a system but then use that access in an
unauthorized way or cooperate with someone else to enable them to do so. Some insider
threats are themselves malicious, such as an employee stealing trade secrets from his
employer. Others are induced by an outside actor working through an insider––whether
the insider knows it or not. For example, an employee who forwards an email that contains

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

14

links or attachments laced with malware is an insider who poses a threat to his
organization, even though he is unaware. And don’t disregard witting forms of
collaboration resulting from bribery, blackmail, coercion, etc.

Spend some time thinking about the various reasons why someone might want to gain
unauthorized access to a system, and what types of individuals and organizations might act on
those reasons. Be prepared to offer your thoughts during class, as we work collectively to map
out the constellation of motives and actors.

D. Meet the Black Market
When a person or entity wants to gain unauthorized access to, or disrupt, a computer or network,
it certainly helps if that person or entity already has the skill and resources needed to develop tools
to suit that purpose. But not everyone does, and for the most part, they don’t actually need to.
Why not? Because there is a thriving black market for the sale of both stolen information (credit
card numbers, etc.), and the tools needed to steal and disrupt.
Obviously, anonymity is important to participants in cybercrime black markets. Consider the
following excerpt from this January 2017 Wired article from Andy Greenberg, as an introduction
to how these markets and their participants try to remain hidden:
SITES ON THE so-called dark web, or darknet, typically operate under what seems like a
privacy paradox: While anyone who knows a dark web site's address can visit it, no one
can figure out who hosts that site, or where. It hides in plain sight. But changes coming to
the anonymity tools underlying the darknet promise to make a new kind of online privacy
possible. Soon anyone will be able to create their own corner of the internet that's not
just anonymous and untraceable, but entirely undiscoverable without an invite.
Over the coming months, the non-profit Tor Project will upgrade the security and privacy
of the so-called "onion services," or "hidden services," that enable the darknet's
anonymity. … That code is now getting a revamp, set to go live sometime later this year,
designed to both strengthen its encryption and to let administrators easily create fully
secret darknet sites that can only be discovered by those who know a long string of
unguessable characters. …
Most darknet sites today make no secret of their existence, widely publicizing their
".onion" web addresses on the regular web and social media for potential visitors. Any
whistleblower can visit WikiLeaks' anonymous upload system, for instance, by pasting
wlupld3ptjvsgwqw.onion into their Tor browser, and many thousands of drug customers
and dealers knew that the notorious dark web drug market Silk Road could be found at
silkroadvb5piz3r.onion before the FBI took it offline.
But even without knowing a Tor hidden service's address, another trick has allowed
snoops, security firms, hackers, and law enforcement to discover them. Tor's network
comprises volunteers' computers that serve as "nodes," bouncing traffic around the
globe. Anyone can position their computer as a particular sort of node---one of
thousands of "hidden service directories" that route visitors to a certain hidden service.
For that routing system to work, all hidden services have to declare their existence to
those directories. A study released at the hacker conference Defcon last year showed
that more than a hundred of the 3,000 or so hidden service directories were secretly

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

15

crawling every site whose address they learned, in order to scan the dark web for
previously undiscovered sites.
… The next generation of hidden services will use a clever method to protect the secrecy
of those addresses. Instead of declaring their .onion address to hidden service
directories, they'll instead derive a unique cryptographic key from that address, and give
that key to Tor's hidden service directories. Any Tor user looking for a certain hidden
service can perform that same derivation to check the key and route themselves to the
correct darknet site. But the hidden service directory can't derive the .onion address from
the key, preventing snoops from discovering any secret darknet address. "The Tor network
isn’t going to give you any way to learn about an onion address you don’t already
know," says Mathewson.
… That potential to foil law enforcement raises the inevitable question: Will
undiscoverable hidden services become a magnet for the worst parts of the darknet,
including markets for stolen data, hacking tools, or child pornography?

Consider the following questions and prepare to discuss them in class:
• What do the labels “darknet” and “TOR” mean?
• Which policy arguments might favor allowing at least some such hidden services to
exist? Which favor suppressing them?
• How should these interests be reconciled? Should the balance should be the same in
all societies? Why might that be hard in practice?

E. Ransomware
A particularly-important aspect of hacking-related crime revolves around ransomware—that is,
schemes to extort money from a victim by encrypting their data and demanding a payment
(typically bitcoin) in exchange for the key. The problem posed by ransomware has accelerated
in recent years in part thanks to the emergence of a market for ransomware-as-a-service (RaaS),
and convenient online portals enabling would-be-customers to purchase RaaS. Catalin Cimpanu
provided this overview for ZDNet (Nov. 16, 2020):
Ransomware-as-a-Service is a cyber-security term referring to criminal gangs that rent
ransomware to other groups, either via a dedicated portal or via threads on hacking
forums.
RaaS portals work by providing a ready-made ransomware code to other gangs. These
gangs, often called RaaS clients or affiliates, rent the ransomware code, customize it using
options provided by the RaaS, and then deploy in real-world attacks via a method of their
choosing.
These methods vary between RaaS affiliate and can include email spear-phishing attacks,
en-masse indisciriminate email spam campaigns, the use of compromised RDP credentials
to gain access to corporate networks, or the use of vulnerabilities in networking devices to
gain access to internal enterprise networks.
Payments from these incidents, regardless of how the affiliates managed to infect a victim,
go to the RaaS gang, who keeps a small percentage and then forwards the rest to the
affiliate.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

16

RaaS offerings have been around since 2017, and they have been widely adopted as they
allow non-technical criminal gangs to spread ransomware without needing to know how
to code and deal with advanced cryptography concepts.
According to a report published today by Intel 471, there are currently around 25 RaaS
offerings being advertised on the underground hacking scene.
While there are ransomware gangs who operate without renting their "product" to other
groups, the number of RaaS portals available today far exceeds what many security
experts thought could be available and shows the plethora of options that criminal gangs
have at their disposal if they ever choose to dip their toes in the ransomware game.
But not all RaaS offerings provide the same features. Intel 471 says it's been tracking these
services across three different tiers, depending on the RaaS' sophistication, features, and
proven history.
Tier 1 is for the most well-known ransomware operations today. To be classified as a Tier 1
RaaS, these operations had to be around for months, proven the viability of their code
through a large number of attacks, and continued to operate despite public exposure.
This tier includes the likes of REvil, Netwalker, DopplePaymer, Egregor (Maze), and Ryuk.
With the exception of Ryuk, all Tier 1 operators also run dedicated "leak sites" where they
name-and-shame victims as part of their well-oiled extortion cartel.
These gangs also use a wide variety of intrusion vectors, each depending on the type of
affiliates they recruit. They can breach networks by exploiting bugs in networking devices
(by recruiting networking experts), they can drop their ransomware payload on systems
already infected by other malware (by working with other malware cartels), or they can
gain access to company networks via RDP connections (by working with brute-force
botnet operators or sellers or compromised RDP credentials).
Tier 2 is for RaaS portals that have gained a reputation on the hacking underground,
provide access to advanced ransomware strains, but have yet to reach the same number
of affiliates and attacks as Tier 1 operators.
This list includes the likes of Avaddon, Conti, Clop, DarkSide, Mespinoza (Pysa),
RagnarLocker, Ranzy (Ako), SunCrypt, and Thanos — and these are effectively the upand-comers of the ransomware world.
Tier 3 is for newly launched RaaS portals or for RaaS offerings about which there's limited
to no information available. In some cases, it is unclear if any of these are still up and
running or if their authors gave up after trying and failing to get their portals off the ground.
This list currently includes the likes of CVartek.u45, Exorcist, Gothmog, Lolkek, Muchlove,
Nemty, Rush, Wally, Xinof, Zeoticus, and (late arrival) ZagreuS.
All in all, while the underground cybercrime ecosystem is generating profits through
criminal activity, it is still a market, and, just like all markets, it is governed by the same
principles that guide any other market today.
A large number of service providers is the tell-tale sign of a booming economy that is far
from being saturated. Saturating the RaaS market will only happen when criminals create
more RaaS portals than affiliate groups are willing to sign up for or when companies bolster
their security measures, making intrusion harder to carry out, drying up profits for crooks.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

17

B. Imposing Costs on Attackers
In this section we will study an array of tools that the government can use to impose costs on
attackers, starting with the tools of criminal law enforcement and then moving on to civil liability
and beyond that to an array of options that become relevant when the attacker is or might be
associated with a foreign government.

3. The Crime Model: Key Institutions and the CFAA

Learning objectives
•
•
•
•
•
•
•
•
•
•
•
•
•

Be able to distinguish the roles of CCIPS and NSD within DOJ, vis-à-vis cyber crime.
Understand the sorts of fact patterns that might implicate NSD equities (distinguishing the
nature of the victim from the nature of the perpetrator)
Be able to identify and distinguish the FBI and Secret Service roles in investigating cybercrime
(at the federal level), while also noting potential role of state investigative agencies
Identify the organizational home and purpose of NCIJTF
Understand that CFAA is not one crime but many
For 1030(a)(1), understand what it means to say this is a trespass+theft crime, albeit one limited
to specific sorts of protected government information.
For 1030(a)(2), understand what it means to say that this too is a trespass+theft crime, this time
one that applies far more broadly than might appear at first glance (and how this is explained
by the “protected computer” definition)
For 1030(a)(3), understand what it means to say that this is a trespass-only crime, and also how
it is limited in other ways
For 1030(a)(4), understand what it means to say that this is a fraud-facilitation crime, and
especially grasp that the deceptive element need not be part of the computer access itself,
but rather the computer access must be in service of the deception
For 1030(a)(5)(A), understand what it means to say that this is a malicious-damage crime.
For 1030(a)(5)(B), understand what it means to say that this is a reckless-damage crime.
For 1030(a)(5)(C), understand what it means to say that this is a strict-liability for damage/loss
crime (and know the definitional difference between “damage” and “loss”).
Don’t forget: 1030(b) covers “conspiracy” to do all the above, too.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

18

In this unit we are assuming the paramount policy goal is to minimize unauthorized access to (or
disruption of) computers, and we open by examining tools that advance this aim by imposing
costs on attackers. Among the most visible and discussed of these tools is criminal prosecution.
A. Meet the Government’s Investigators
There are a surprising number of government agencies responsible for investigating cybercrime,
and their roles often overlap. As you read the information below, you might want to create a list
or chart that identifies each agency, the relevant department/structure within the agency, and
their basic responsibilities. Throughout the semester, it may be useful to refer back to this list and
update as needed.
Department of Justice

As you read here and here to learn about the Department of Justice's role in investigating and
prosecuting attackers, consider the following questions:
• What is the office at DOJ that has special responsibility for this area, in general?
• Which office at the Justice Department appears to have had lead responsibility in the
APT 10 Group case, and why do you suppose that is?

FBI

As you read here and here to learn about the FBI's role in investigating and prosecuting
attackers, consider the following questions:
• What part of FBI focuses on computer crime, in general?
• Can you specify the various roles FBI plays?

U.S. Secret Service

As you read here about the Secret Service's role in investigating and prosecuting attackers,
consider the following questions:
• What role does the Secret Service play?
• Why is the Secret Service involved in this area?

We are focused for the moment on prosecuting hacking as a crime. But it’s worth pausing to
remind ourselves that “crime” is not always the most relevant label to describe an unauthorized
access scenario, even if it does involve a violation of criminal law.

So stretch your mind a bit, recalling the reference in the readings above to DOJ’s National
Security Division:
• When DOJ decides to prosecute, how might this have implications—perhaps negative
ones—for the missions of other U.S. government agencies or departments?

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

19

B. The Computer Fraud and Abuse Act
There are many federal crimes that might be implicated by the activity we are discussing, but the
most significant one is the Computer Fraud and Abuse Act, or CFAA. The CFAA is codified in Title
18 of the United States Code (the U.S. Code is the compilation of federal statutes organized
topically, and Title 18 is the main place to find federal criminal laws). In particular, it is codified as
18 U.S.C. Section 1030.
For some of you, this will be your first time to really examine a criminal statute. You may be surprised
by how convoluted it seems to be once you begin reading it closely. I assure you: You can handle
it, so long as you take your time parsing the language.
The part we want to focus on here is the first subsection, 1030(a). As you will see, it actually
contains seven separate criminal offenses. I reprint them below, but you can also find the full text
of the statute (including the relevant definitions) here. Read them through one time, slowly, and
then proceed to the questions below.
Section 1030(a) imposes felony liability on whomever:
(1)

having knowingly accessed a computer without authorization or exceeding
authorized access, and by means of such conduct having obtained information
that has been determined by the United States Government pursuant to an
Executive order or statute to require protection against unauthorized disclosure for
reasons of national defense or foreign relations, or any restricted data, as defined
in paragraph y. of section 11 of the Atomic Energy Act of 1954, with reason to
believe that such information so obtained could be used to the injury of the
United States, or to the advantage of any foreign nation willfully communicates,
delivers, transmits, or causes to be communicated, delivered, or transmitted, or
attempts to communicate, deliver, transmit or cause to be communicated,
delivered, or transmitted the same to any person not entitled to receive it, or
willfully retains the same and fails to deliver it to the officer or employee of the
United States entitled to receive it;

(2)

intentionally accesses a computer without authorization or exceeds authorized
access, and thereby obtains—
(A) information contained in a financial record of a financial institution, or
of a card issuer as defined in section 1602(n) of title 15, or contained in a
file of a consumer reporting agency on a consumer, as such terms are
defined in the Fair Credit Reporting Act (15 U.S.C. 1681 et seq.);
(B) information from any department or agency of the United States; or
(C) information from any protected computer;

(3)

intentionally, without authorization to access any nonpublic computer of
a department or agency of the United States, accesses such a computer of
that department or agency that is exclusively for the use of the Government of the
United States or, in the case of a computer not exclusively for such use, is used by
or for the Government of the United States and such conduct affects that use by
or for the Government of the United States;

(4)

knowingly and with intent to defraud, accesses a protected computer without
authorization, or exceeds authorized access, and by means of such conduct
furthers the intended fraud and obtains anything of value, unless the object of the

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

20

fraud and the thing obtained consists only of the use of the computer and
the value of such use is not more than $5,000 in any 1-year period;
(5)
(A) knowingly causes the transmission of a program, information, code, or
command, and as a result of such conduct, intentionally
causes damage without authorization, to a protected computer;
(B) intentionally accesses a protected computer without authorization,
and as a result of such conduct, recklessly causes damage; or
(C) intentionally accesses a protected computer without authorization,
and as a result of such conduct, causes damage and loss.
(6)

knowingly and with intent to defraud traffics (as defined in section 1029) in any
password or similar information through which a computer may be accessed
without authorization, if—
(A) such trafficking affects interstate or foreign commerce; or
(B) such computer is used by or for the Government of the United States;

(7)

with intent to extort from any person any money or other thing of value, transmits
in interstate or foreign commerce any communication containing any—
(A) threat to cause damage to a protected computer;
(B) threat to obtain information from a protected computer without
authorization or in excess of authorization or to impair the confidentiality of
information obtained from a protected computer without authorization or
by exceeding authorized access; or
(C) demand or request for money or other thing of value in relation
to damage to a protected computer, where such damage was caused to
facilitate the extortion. . . .

Also note that the statute contains several definitions in 1030(e), too many to list here. Here are
the highlights:
(1)

the term “computer” means an electronic, magnetic, optical, electrochemical, or
other high speed data processing device performing logical, arithmetic, or storage
functions, and includes any data storage facility or communications facility directly
related to or operating in conjunction with such device, but such term does not
include an automated typewriter or typesetter, a portable hand held calculator,
or other similar device;

(2)

the term “protected computer” means a computer—
(A) exclusively for the use of a financial institution or the
United States Government, or, in the case of a computer not exclusively for
such
use,
used
by
or
for
a financial
institution or
the
United States Government
and
the
conduct
constituting
the offense affects that use by or for the financial institution or the
Government; or
(B) which is used in or affecting interstate or foreign commerce or
communication,
including
a computer
located
outside
the

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

21

United States that is used in a manner that affects interstate or foreign
commerce or communication of the United States;
…
(6)

the term “exceeds authorized access” means to access a computer with
authorization and to use such access to obtain or alter information in
the computer that the accesser is not entitled so to obtain or alter;

…
(8)

the term “damage” means any impairment to the integrity or availability of data,
a program, a system, or information;

…
(11)

the term “loss” means any reasonable cost to any victim, including the cost of
responding to an offense, conducting a damage assessment, and restoring the
data, program, system, or information to its condition prior to the offense, and any
revenue lost, cost incurred, or other consequential damages incurred because of
interruption of service; and

(12)

the term “person” means any individual, firm, corporation, educational
institution, financial institution, governmental entity, or legal or other entity.

To help you make sense of the statute, consider the following:
• Make a list, chart, flash cards, or something else that helps you break down the key
elements for each of these separate crimes. Start by giving each one a label, in your
own words, that fairly describes the unique aspect of that particular provision. Then list
the elements necessary for an offense, including the necessary actions, the required
mental state, and any other conditions mentioned.
• Do any of the provisions seem problematic to you? Be prepared to explain why.
• Which provisions seem must relevant to a classic “hacking” scenario in which someone
uses an exploit to gain unauthorized access to someone else’s computer, and
thereafter exfiltrates data from it?
• Is the CFAA only concerned with such hacking scenarios?

Notice that the CFAA goes on, in subsection 1030(b), to criminalize conspiracies and attempts to
commit the offenses listed in 1030(a).

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

22

4. CFAA Case Studies and Interpretations

Learning Objectives:
1. Understand whether and how the CFAA applies in the case of unintentional—but
reckless—impact on others (the Morris case)
2. Understand the controversy regarding the CFAA-based prosecution of Aaron Swartz
3. Grasp the difference between a system owner (a) choosing to give someone access to
certain information and (b) specifying rules for what that person can do with that
information. Can you see why the system owner might feel that the former depends on
the latter?
4. Know the CFAA definition for exceeding authorized access.
5. Understand why point 3 above raises a tricky question regarding the precise meaning of
that definition, such that we might interpret “exceeding access” either broadly or
narrowly.
6. Understand how the Supreme Court has addressed this issue in Van Buren
As we read through various cases where individuals were charged with violating the CFAA, bear
in mind that the statute has been amended several times throughout the years. For some of these
cases, the charged offenses will differ slightly from the modern ones. As you read, consider
whether it would be easier or harder to charge the same individual with a CFAA violation today,
and whether any other offenses might apply to the same conduct.
A. United States v. Morris
The first big CFAA prosecution involved the ground-breaking—and largely accidental—“Morris
Worm.”

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

23

Read about the underlying events here, and then read the court opinion affirming his
conviction––United States v. Morris, 928 F.2d 504 (2d Cir. 1991).
• Do you agree that Morris violated the CFAA––either today or as it was written then?
• What were the best legal arguments for and against prosecuting Morris?
• Does the prosecution make normative sense to you? In other words, does it make
sense to prosecute people like Morris?

B. United States v. Swartz
The controversy surrounding the Morris case was nothing compared to that generated by the later
prosecution of Aaron Swartz.

Read this article about the Swartz prosecution, and consider the same questions from the
Morris case.
• Do you agree that Swartz violated the CFAA––either today or as it was written then?
• What were the best legal arguments for and against prosecuting Swartz?
• Does the prosecution make normative sense to you? In other words, does it make
sense to prosecute people like Swartz?

C. United States v. Van Buren
The Supreme Court recently issued its first opinion construing the CFAA: United States v. Van Buren.
Read the opinion here, focusing on pages 3-16 and 17-20. Take special note of footnote 8, on
p.13.

Be prepared to:
• Identify the precise portion of the CFAA in dispute, the competing proposed
interpretations, and the best arguments for and against each proposal
• Explain which interpretation the Court adopted, including especially the idea that a
“gate” is “up or down” in a way that defines the scope of an authorized users access
to a computer
• Can you explain footnote 8?
• Defend your view on whether the Court got it right or wrong

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

24

5. Other Criminal Statutes

Learning Objectives
•
•
•

•
•
•

Understand that Wire Fraud is a common charge both because the elements are relatively
broad (use of telecoms to further some fraudulent scheme) and the penalties are
comparatively serious
Appreciate the degree of leverage over defendants that follows from the fact that
prosecutors can charge multiple counts of the same type of crime, if there are multiple
instances (which there almost certainly will be in the wire fraud context)
The Anthony Clark prosecution illustrates that it can be a bit trick to sort out who is being
victimized in a fraud scenario (it wasn’t the buyers who paid him, nor Microsoft (Xbox), but
rather the gaming company (on the theory that their system was duped into issuing things of
value to him).
Understand why cases involving attackers located overseas present a layer of complexity
insofar as it may be difficult to arrange an arrest.
Understand why the lack of an extradition treaty does not mean the U.S. government
cannot go into a particular location to physically seize a person.
Understand the competing equities (other than the interests of law enforcement, that is) that
arise when there is a proposal to arrest someone who is a foreign national, and how this has
implications for how a well-designed government decisionmaking process should go about
ensuring that all such competing equities are given due consideration.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity
•
•
•

•
•
•
•
•

25

Be able to explain how the Track2 case illustrates these complexities, including especially the
risk of unanticipated collateral consequences (Sergey Mikhailov)
Understand that each state has its own computer crime laws, mostly similar to the federal
ones we’ve studied but sometimes distinct in interesting ways.
Appreciate how Section 33.02 of the Texas Penal Code, for example, is akin to CFAA Section
1030(a)(2), except that it requires *no* exfiltration of data (and thus is a type of “trespassonly” provision) and uses an “effective consent” standard that is separately defined (in
Section 33.01(12)) in a way that expressly makes the owner/operator’s intentions in granting
conditional access part of the statutory standard (in contrast to the indeterminacy on this
point for “exceeds authorized access” that has given rise to the federal Van Buren case).
Understand that international law is not the law of a foreign state, but rather a species of law
that in theory is common to all states (or at least to the states that are party to a particular
treaty)
There can be rules of international law that constitute criminal law (there are law-of-war rules
like this, notably), but you do not normally see that with ordinary crime situations—and there
are no such rules as to computer crimes.
Instead, what you often get are treaties in which states agree to pass ordinary domestic
criminal laws on a given subject, and to cooperate with each other’s criminal investigations.
The Budapest Convention is like that.
Understand that Russia and China declined to join it, and ponder why.
Understand that Russia, China, and other authoritarian states are pushing a new treaty that
has been criticized on the ground that it will give cover to countries to criminalize unwelcome
online speech.

A. Other Relevant Criminal Laws
The CFAA isn’t the only tool in the toolbox for federal prosecutors dealing with cybercrime. There
are some statutes of more-general applicability that often fit well with hacking scenarios, and
there also are some highly-tailored statutes to consider.
The most-relevant of the generally-applicable criminal laws, in this respect, is the “wire fraud”
statute––18 U.S.C. 1343:
Whoever, having devised or intending to devise any scheme or artifice to defraud,
or for obtaining money or property by means of false or fraudulent pretenses,
representations, or promises, transmits or causes to be transmitted by means of
wire,
radio,
or
television
communication
in
interstate
or foreign
commerce, any writings, signs, signals, pictures, or sounds for the purpose of
executing such scheme or artifice, shall be fined under this title or imprisoned not
more than 20 years, or both. …

Consider the following questions:
• How does the wire fraud statute differ from the CFAA?
• Why might a prosecutor find this statute handy?
To get a further sense of what a wire fraud prosecution linked to hacking might look like, check
out this article about an unusual wire fraud prosecution. Goooooooooooooooal!
Apart from “wire fraud,” there are several other, more-specific fraud statutes. While I do not intend
for you to learn the particulars with them (unlike the CFAA and Wire Fraud), I do want you to be
familiar with the general idea behind them. So skim the following information on identify fraud,

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

26

identity theft, and access device fraud. Don’t invest too much time in this section; just do enough
to be able to articulate what these laws forbid in general, and ponder how this could be useful in
a cybersecurity scenario.
The “identity fraud” statute, 18 USC 1028, is complex. It lists a variety of identity fraud scenarios (see
(1)-(8) below), and allows the government to prosecute such activity when certain conditions are
met. First, skim the list of fraud scenarios:
(1)

knowingly
and
without
lawful
authority produces an identification
document, authentication feature, or a false identification document;

(2)

knowingly transfers an identification document, authentication feature, or a
false identification document knowing that such document or feature was stolen
or produced without lawful authority;

(3)

knowingly possesses with intent to use unlawfully or transfer unlawfully five or
more identification documents (other than those issued lawfully for the use of the
possessor), authentication features, or false identification documents;

(4)

knowingly possesses an identification document (other than one issued lawfully for
the use of the possessor), authentication feature, or a false identification
document, with the intent such document or feature be used to defraud the
United States;

(5)

knowingly produces, transfers,
or
possesses
a document-making
implement or authentication feature with the intent such document-making
implement or authentication feature will be used in the production of a false
identification
document or
another document-making
implement or authentication feature which will be so used;

(6)

knowingly possesses an identification document or authentication feature that is
or appears to be an identification document or authentication feature of the
United States or a sponsoring entity of an event designated as a special event of
national significance which is stolen or produced without lawful authority knowing
that such document or feature was stolen or produced without such authority;

(7)

knowingly transfers, possesses, or uses, without lawful authority, a means of
identification of another person with the intent to commit, or to aid or abet, or in
connection with, any unlawful activity that constitutes a violation of Federal law,
or that constitutes a felony under any applicable State or local law; or

(8)

knowingly traffics in false or actual authentication features for use
false identification documents, document-making implements, or means
identification;

in
of

As noted, those scenarios can be prosecuted federally when certain conditions are met. To wit:
(1)

the identification
document, authentication
feature, or
false identification
document is or appears to be issued by or under the authority of the
United States or a sponsoring entity of an event designated as a special event of
national significance or the document-making implement is designed or suited for
making
such
an
identification
document, authentication
feature, or
false identification document;

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

(2)

the offense is an offense under subsection (a)(4) of this section; or

(3)

either—

27

(A) the production, transfer, possession, or use prohibited by this section is
in or affects interstate or foreign commerce, including the transfer of a
document by electronic means; or
(B) the means of identification, identification document, false identification
document, or document-making implement is transported in the mail in the
course of the production, transfer, possession, or use prohibited by this
section.
Meanwhile, identity theft, 18 USC 1028A, allows the government to prosecute an individual who:
during and in relation to any felony violation enumerated in subsection (c) [more
on this below], knowingly transfers, possesses, or uses, without lawful authority,
a means of identification of another person . . .
Subsection (c) lists several offenses contained in other statutes, including theft and embezzlement;
"false personification of citizenship"; "false statements in connection with the acquisition of a
firearm"; fraud; mail, bank, and wire fraud; several immigration-related offenses; "obtaining
customer information by false pretenses"; and "false statements relating to" Social Security
programs.
Next we have “access device” fraud. What a confusing term of art that is. Let’s define it first.
According to the relevant statute, this means:
any card, plate, code, account number, electronic serial number, mobile
identification
number,
personal
identification
number,
or
other
telecommunications service, equipment, or instrument identifier, or other means of
account access that can be used, alone or in conjunction with another access
device, to obtain money, goods, services, or any other thing of value, or that can
be used to initiate a transfer of funds (other than a transfer originated solely by
paper instrument)
So, what sorts of charges can be brought? 18 USC 1029 allows the government to prosecute an
individual who, in affecting interstate commerce:
(1)

knowingly and with intent to defraud produces, uses, or traffics in one or more
counterfeit access devices;

(2)

knowingly and with intent to defraud traffics in or uses one or more unauthorized
access devices during any one-year period, and by such conduct obtains
anything of value aggregating $1,000 or more during that period;

(3)

knowingly and with intent to defraud possesses fifteen or more devices which are
counterfeit or unauthorized access devices;

(4)

knowingly, and with intent to defraud, produces, traffics in, has control or custody
of, or possesses device-making equipment;

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

28

(5)

knowingly and with intent to defraud effects transactions, with 1 or more access
devices issued to another person or persons, to receive payment or any other thing
of value during any 1-year period the aggregate value of which is equal to or
greater than $1,000;

(6)

without the authorization of the issuer of the access device, knowingly and with
intent to defraud solicits a person for the purpose of—
(A)

offering an access device; or

(B)

selling information regarding or an application to obtain an access device;

(7)

knowingly and with intent to defraud uses, produces, traffics in, has control or
custody of, or possesses a telecommunications instrument that has been modified
or altered to obtain unauthorized use of telecommunications services;

(8)

knowingly and with intent to defraud uses, produces, traffics in, has control or
custody of, or possesses a scanning receiver;

(9)

knowingly uses, produces, traffics in, has control or custody of, or possesses
hardware or software, knowing it has been configured to insert or modify
telecommunication identifying information associated with or contained in a
telecommunications instrument so that such instrument may be used to obtain
telecommunications service without authorization; or

(10)

without the authorization of the credit card system member or its agent, knowingly
and with intent to defraud causes or arranges for another person to present to the
member or its agent, for payment, 1 or more evidences or records of transactions
made by an access device;

For a fascinating case showing how a variety of these statutes might be used in combination, we
will discuss the prosecution of Roman Zeleznev (aka “Track2”).

Read about Track2 here and consider the following questions:
• This case turned out well for the government; do you think it indicates that similar
success is possible in most such cases? Read this and this for a glimpse of some
unusual complications.
• What made this case harder than normal? What factors explain how DOJ prevailed
anyway? Does this show DOJ can generally prevail in similar cases?

Note: There are other criminal laws that are important in this space, though we will not explore
them in the interest of moving along to other topics. For the record, however, I’ll still proceed to
name a few of them: 18 USC 641 (theft of government property); 18 USC 2511 (unauthorized
interception of communications); 18 USC 2701 (unauthorized accessing of stored
communications); and 18 USC 793–798 (various provisions relating to espionage and protection of
defense information). There also is 17 USC 1201–1205, aka the Digital Millennium Copyright Act
(“DMCA”).

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

29

B. State Criminal Laws
States have statutes analogous to the CFAA. For an overview of the relevant Texas statute,
including observations on how it differs from CFAA in certain respects, read this article.

Be prepared to articulate whether / how the Texas statute differs from the CFAA.

C. International Cybercrime Enforcement
The United States is party to the “Budapest Convention on Cybercrime”––an international treaty
promoting cooperation between nations in combating cybercrime.

Skim its provisions to get a rough sense of what it is trying to accomplish.
• What do the parties to this treaty actually promise to do that seems genuinely
significant?
• Why do you suppose Russia, China, and Iran are not parties to this treaty?

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

30

6. Civil Liability under the CFAA

Learning objectives
1. Be able to explain the pros and cons of modulating (calibrating) “civil liability” as a tool to
advance a government’s policy goals for a given industry or problem set such as
cybersecurity.
2. Understand that such modulation can involve both (a) expanding or shrinking the grounds for
suing and (b) expanding or shrinking the procedural and evidentiary obstacles to actually
prevailing in court once you have a ground to sue.
3. Appreciate that the CFAA (section 1030(g)) reflects a purposeful expansion of the grounds to
sue in the computer crime context, but of course there were (and still are) various pre-existing
general-purpose grounds to sue people who cause harm intentionally, recklessly, or
negligently (and many of these “old school” torts apply pretty well in the context of hacking)
4. Understand that 1030(g) only allows suit against the attacker (and note the “belt and
suspenders” line confirming this extra-clearly as to software/hardware makers who plainly were
rather worried about negligence suits, even though 1030(g) on its face does not authorize
such suits).
5. Understand the four “gateways to litigation land” included in CFAA Section 1030(g), and note
that the first gateway (involving aggregate costs of $5000) doesn’t count unless the costs
involved “economic damage.”
6. Be able to explain the holding in the Facebook case.
7. Be able to explain the holding in the LinkedIn case.
8. Be able to describe how the Facebook and LinkedIn decisions can be distinguished (a hint:
can you analogize one of them to a situation in which a guy wants to run a website showing
the day’s local gas prices, and gathers his information simply by driving around looking at
what the signs say?)
9. Once you grasp that distinction, can you form a view on whether the CFAA really should
apply differently in those two scenarios?

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

31

A. The CFAA’s Civil Liability Provision
It turns out the CFAA is not just a criminal statute, but also a civil liability statute––that is, it also
creates a “private right of action” enabling suits for money damages in certain circumstances.
Here's the basic provision making it possible to sue someone who breaches the CFAA, 18 U.S.C.
1030(g):
(g)

Any person who suffers damage or loss by reason of a violation of this section may
maintain a civil action against the violator to obtain compensatory damages and
injunctive relief or other equitable relief. A civil action for a violation of this section
may be brought only if the conduct involves 1 of the factors set forth in
subclauses (I), (II), (III), (IV), or (V) of subsection (c)(4)(A)(i). Damages for a violation
involving only conduct described in subsection (c)(4)(A)(i)(I) are limited to
economic damages. No action may be brought under this subsection unless such
action is begun within 2 years of the date of the act complained of or the date of
the discovery of the damage. No action may be brought under this subsection for
the negligent design or manufacture of computer hardware, computer software,
or firmware.

That’s not the most straightforward provision, given the complicated cross-reference in the second
sentence. It would have been clearer if the drafters had simply said in the text itself that the right
to sue for a CFAA violation exists only where the violation involved one of the following five
situations:
(I)

loss to 1 or more persons during any 1-year period … aggregating at least $5,000 in
value;

(II)

the modification or impairment, or potential modification or impairment, of the
medical examination, diagnosis, treatment, or care of 1 or more individuals;

(III)

physical injury to any person;

(IV)

a threat to public health or safety;

(V)

damage affecting a computer used by or for an entity of the United States
Government in furtherance of the administration of justice, national defense, or
national security;

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

•
•
•

•

32

What do you suppose is the purpose of having any such limits?
Do you have an opinion on whether these conditions are too narrow or too broad?
Notice that 1030(g) includes a caveat to the effect that a situation covered by scenario
(I) above only counts if the damages involved are “economic damages.” That is a wellestablished concept in tort law, reflecting the idea that there is a distinction between
harms that are readily-quantifiable in dollar terms (such as lost wages or bills for services
that a victim incurred in response to an incident) and those that are more subjective
(such as pain-and-suffering). Why insist on this limitation in the CFAA context?
Notice the last sentence of 1030(g).
o Whom does this protect?
o Would such entities likely be subject to 1030(g) liability absent this sentence?
o Does this sentence preclude lawsuits based on theories other than the
CFAA?
o What sees to be the point of this provision?

B. Case Study: Facebook’s Effort to Shut Down Power Ventures
In 2016, the Ninth Circuit Court of Appeals issued a ruling in Facebook v. Vachani, a CFAA case in
which Facebook sought to stop Vachani’s company (“Power Ventures”) from continuing to
access data from the accounts of Facebook users who willingly shared their login credentials with
Power Ventures. What follows below is an excerpt from the analysis of that decision from Professor
Orin Kerr (from a contemporaneous post to the blog the Volokh Conspiracy):
I think this decision is wrong, and that it has big implications going forward. Here’s a
rundown of the case and why it matters. I’ll conclude with a thought about a possible way
to read the case more narrowly, as well as why I’m not convinced that narrow reading is
correct.
I. The Facts
Steve Vachani is the chief executive and founder of Power Ventures, which had a website
at Power.com. (I’ll refer to Vachani and Power Ventures collectively as “Power.”) Power
had a service that let users aggregate their contacts on different social media sites.
Power’s software allowed Facebook users to authorize Power to go into their Facebook
accounts and gather information for them for use at Power’s website. Power users also
authorized the software to send Facebook messages to other Facebook users for them.
Facebook didn’t appreciate this, and it sent a “cease and desist” letter to Power telling
the company to stop. The cease-and-desist letter told Power that it was violating
Facebook’s terms of use and warned Power that it may have violated federal and state
law. Facebook also blocked Power’s IP addresses. Power just changed IP addresses and
continued operating.
Facebook then sued, claiming that Power’s conduct violated the CFAA, a somewhat
similar California unauthorized access statute and the CAN-SPAM Act. Just to keep things
simple, I’ll focus this post only on the claims brought under the CFAA.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

33

II. The New Decision
In the new decision, the court holds that Power violated the CFAA when it continued to
access Facebook’s computers with users’ permission after receiving the cease-and-desist
letter. Oddly, Judge Susan P. Graber’s explanation for why Power violated the CFAA
focuses almost exclusively on Power’s state of mind rather than what Power did. The CFAA
prohibits intentionally accessing a computer without authorization. Instead of explaining
what counts as access “without authorization,” Judge Graber focuses mostly on whether
Power had a culpable state of mind with respect to whether it was doing something
unwanted.
Here’s the key analysis:
Initially, Power users arguably gave Power permission to use Facebook’s computers to
disseminate messages. Power reasonably could have thought that consent from
Facebook users to share the promotion was permission for Power to access Facebook’s
computers. [FN: Because, initially, Power users gave Power permission to use Facebook’s
computers to disseminate messages, we need not decide whether websites such as
Facebook are presumptively open to all comers, unless and until permission is revoked
expressly.] . . . Power users took action akin to allowing a friend to use a computer or to log
on to an e-mail account. Because Power had at least arguable permission to access
Facebook’s computers, it did not initially access Facebook’s computers “without
authorization” within the meaning of the CFAA.
But Facebook expressly rescinded that permission when Facebook issued its written cease
and desist letter to Power on December 1, 2008. Facebook’s cease and desist letter
informed Power that it had violated Facebook’s terms of use and demanded that Power
stop soliciting Facebook users’ information, using Facebook content, or otherwise
interacting with Facebook through automated scripts. Facebook then imposed IP blocks
in an effort to prevent Power’s continued access.
The record shows unequivocally that Power knew that it no longer had authorization to
access Facebook’s computers, but continued to do so anyway. In requests for admission
propounded during the course of this litigation, Power admitted that, after receiving notice
that its use of or access to Facebook was forbidden by Facebook, it “took, copied, or
made use of data from the Facebook website without Facebook’s permission to do so.”
(Emphasis added; capitalization omitted.)
. . . In sum, as it admitted, Power deliberately disregarded the cease and desist letter and
accessed Facebook’s computers without authorization to do so. It circumvented IP barriers
that further demonstrated that Facebook had rescinded permission for Power to access
Facebook’s computers. [FN: Simply bypassing an IP address, without more, would not
constitute unauthorized use. Because a blocked user does not receive notice that he has
been blocked, he may never realize that the block was imposed and that authorization
was revoked. Or, even if he does discover the block, he could conclude that it was
triggered by misconduct by someone else who shares the same IP address, such as the
user’s roommate or co-worker.] We therefore hold that, after receiving written notification

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

34

from Facebook on December 1, 2008, Power accessed Facebook’s computers “without
authorization” within the meaning of the CFAA and is liable under that statute.
As I read the court’s opinion, the main issue is state of mind. Did you know that the
computer owner didn’t want you to visit the website? At first, Power didn’t know
Facebook’s view. But after the cease-and-desist letter, Power knew Facebook’s position.
As a result, it was a federal crime to use Facebook after having received Facebook’s letter
telling it to stay away. If I’m reading the opinion correctly, it appears that every contact
with the computer that its owner doesn’t want is “without authorization.” The main question
becomes mens rea: The visit becomes a federal crime when the visitor knows that the
computer owner doesn’t want it.
III. The Thin (Nonexistent?) Line Between Terms of Use and Cease-and-Desist Letters
At this point you may be thinking: Hey, wait, didn’t the en banc 9th Circuit rule in Nosal I
that using a computer in violation of its terms of use is not a CFAA violation? If intentionally
using a computer in violation of the terms of use is legal authorized access, as the en banc
9th Circuit held in Nosal I, why is intentionally using a computer after receiving a ceaseand-desist letter criminal access “without authorization”? In one case, the user goes to the
website and sees the terms; in the other, the website owner contacts the user and shows
the terms to them. But it’s the same thing, right?
Judge Graber offers two explanations for the difference. First:
[A]lthough Nosal I makes clear that violation of the terms of use of a website cannot itself
constitute access without authorization, this case does not involve non-compliance with
terms and conditions of service. Facebook and Power had no direct relationship, and it
does not appear that Power was subject to any contractual terms that it could have
breached.
I don’t follow this.
First, I don’t understand why it matters whether there is an existing contractual relationship.
Maybe that’s relevant to whether we are in the illegal “access without authorization” box
or the equally illegal “exceeds authorized access” box, which Judge Graber elsewhere
notes is a possible difference between this case and Nosal I. But I don’t see how it could
be the difference between illegal “access without authorization” and legal authorized
access.
Second, both terms of use and cease-and-desist letters are just written statements about
what the computer owner wants you to do with the computer. If Facebook’s terms say,
“no social media aggregators such as Power.com are permitted to visit,” it’s hard for me
to distinguish between that and a letter to Power saying “we do not permit social media
aggregators such as you and therefore you cannot visit.”
If you have to really come up with a difference, I suppose terms of use imply a conditional
that cease-and-desist letters don’t. Terms of use requires the visitor to see that his act is
prohibited and therefore unwanted. There can be uncertainty about whether that
condition is met. But that’s solely a matter of state of mind rather than the act. It goes to

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

35

whether the act is intentional, which is a separate element of the crime. I don’t understand
how one can be criminal “access without authorization” and the other is legal authorized
access.
Judge Graber also offers this distinction between terms of use and cease-and-desist letters:
Finally, Nosal I [on terms of use] was most concerned with transforming “otherwise
innocuous behavior into federal crimes simply because a computer is involved.” Id. at 860.
It aimed to prevent criminal liability for computer users who might be unaware that they
were committing a crime. But, in this case, Facebook clearly notified Power of the
revocation of access, and Power intentionally refused to comply. Nosal I’s concerns about
overreaching or an absence of culpable intent simply do not apply here. This case is closer
to Nosal II, wherein liability attached after permission to access computers was expressly
revoked, but then the defendant deliberately circumvented the rescission of authorization.
This makes no sense to me. Again, Graber appears to have a misplaced emphasis on state
of mind. She is focused on whether people had “culpable intent,” and letting those
“unaware” escape liability while those who acted “deliberately” are punished. But that
can’t explain why you can intentionally violate terms of use but you can’t intentionally
ignore cease-and-desist letters. The state-of-mind question is about a different element of
the CFAA — whether the unauthorized access was “intentional,” not whether the act was
an unauthorized access in the first place. The difference in the legal treatment of the two
acts has to rest on the difference between the acts themselves, not the differences
between possible states of mind about those acts.
IV. The Physical World Analogy
Finally, Judge Graber offers a physical-world analogy that I suspect may really explain the
decision.
Suppose that a person wants to borrow a friend’s jewelry that is held in a safe deposit box
at a bank. The friend gives permission for the person to access the safe deposit box and
lends him a key. Upon receiving the key, though, the person decides to visit the bank while
carrying a shotgun. The bank ejects the person from its premises and bans his reentry. The
gun-toting jewelry borrower could not then reenter the bank, claiming that access to the
safe deposit box gave him authority to stride about the bank’s property while armed. In
other words, to access the safe deposit box, the person needs permission both from his
friend (who controls access to the safe) and from the bank (which controls access to its
premises). Similarly, for Power to continue its campaign using Facebook’s computers, it
needed authorization both from individual Facebook users (who controlled their data and
personal pages) and from Facebook (which stored this data on its physical servers).
I explained my problem with this kind of analogy in my recent article “Norms of Computer
Trespass.” As I see it, the problem is that the trespass norms of private spaces like homes or
commercial stores can’t be blindly applied to a public website. Trespass is always normsdependent, and each kind of space has its own set of norms. In the case of a bank, we
recognize that the bank is a private business that only permits visitors that it wants to enter.
The trespass norm is that staying when the bank wants you out is a trespass.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

36

Public websites are different, I think. The web is a publishing platform, and everyone is
inherently authorized to visit a public website. True, Power did more than just visit the public
face of the website. Power also accessed the individual accounts of users acting as their
agents. But as I see it, that’s not enough to constitute a computer trespass because it’s
within the permission of the user and acting as the user’s agent. The only non-public access
was to the virtual space the user controlled, so I think the user’s permission should be
enough.
This doesn’t mean that what Power did is necessarily a good thing. Maybe there should
be other causes of action against Power for its conduct. But as I see it, the CFAA shouldn’t
be one of them based on these facts. Facebook also could suspend the accounts of its
users who authorized Power, or it could take technical steps to stop Power’s entry inside
Facebook’s network. But I don’t think it should have been allowed to rely on the CFAA to
keep Power away with a letter.
V. A Narrower Reading?
This is an important case. This was a civil dispute, but the CFAA is also criminal statute. If
read broadly, the case seems to say that if you want to make it a crime for someone to
visit your website, you just need to give them notice that you don’t want them to visit. I
gather that as long as you phrase the notice as a command to cease and desist, rather
than as just general terms of use, it becomes legally binding.
One question is whether you can read the decision more narrowly to apply only to
accessing an account rather than visiting a website. Here’s the uncertainty: Is the decision
saying broadly that you can’t visit the public face of a website after the computer owner
said “no,” or is the decision saying more narrowly that you can’t access an individual
account with the user’s permission after the computer owner said “no”? I would still
disagree with the narrower reading, but it would be a lot less objectionable than the
broader one.
Reading over the opinion, though, I don’t see a lot of reason to think the court had the
narrower interpretation in mind. Consider these clues. First, Footnote 1 states:
Because, initially, Power users gave Power permission to use Facebook’s computers to
disseminate messages, we need not decide whether websites such as Facebook are
presumptively open to all comers, unless and until permission is revoked expressly.
The court then cites a law review article “asserting that websites are the cyber-equivalent
of an open public square in the physical world.” By not deciding that question, the court
appears not to be hinging its analysis on a distinction between visiting the public part of a
website and accessing a private account that happens to be accessible over the web.
The effect of a cease-and-desist letter appears to be the same in both cases.
Second, when the court explains the difference between terms of use on a website and a
cease-and-desist letter, it doesn’t just say that the difference is that terms of use often
applies to the public that uses the website while the cease-and-desist letter here was for
conduct that required account access. That would have been a ready distinction to
make, but the court didn’t make it.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

37

Third, the court says that by sending the cease-and-desist letter, “Facebook explicitly
revoked authorization for any access[.]” (emphasis in original). It doesn’t say that the
authorization was revoked for the account access but not for visiting material accessible
to the public on its computers (content such as this, for example, which anyone can
access). Again, that suggests the broader reading rather than the narrower reading.
VI. What Next?
Given the wafer-thin distinction between this case and the en banc decision in Nosal I, will
the 9th Circuit grant a petition for rehearing en banc? I hope so. As always, stay tuned.

•
•
•
•

Since that time, the Supreme Court decided Van Buren, as you know. Which way
does Van Buren cut?
Can you explain the Court’s argument for why Power Ventures violated the CFAA?
Can you distinguish and state the various critiques offered by Professor Kerr?
Who has it right?

Note: The Supreme Court refused to review the Ninth Circuit’s ruling, thus ending the case.
C. Case Study: LinkedIn’s Effort to Shut Down HiQ
Read the following excerpt from the 2019 decision of the Ninth Circuit Court of Appeals in
LinkedIn v. HiQ:
May LinkedIn, the professional networking website, prevent a competitor, hiQ, from
collecting and using information that LinkedIn users have shared on their public profiles,
available for viewing by anyone with a web browser? HiQ, a data analytics company,
obtained a preliminary injunction forbidding LinkedIn from denying hiQ access to publicly
available LinkedIn member profiles. At this preliminary injunction stage, we do not resolve
the companies’ legal dispute definitively, nor do we address all the claims and defenses
they have pleaded in the district court. Instead, we focus on whether hiQ has raised
serious questions on the merits of the factual and legal issues presented to us, as well as
on the other requisites for preliminary relief.
Founded in 2002, LinkedIn is a professional networking website with over 500 million
members. Members post resumes and job listings and build professional "connections"
with other members. LinkedIn specifically disclaims ownership of the information users
post to their personal profiles: according to LinkedIn’s User Agreement, members own the
content and information they submit or post to LinkedIn and grant LinkedIn only a nonexclusive license to "use, copy, modify, distribute, publish, and process" that information.
LinkedIn allows its members to choose among various privacy settings. Members can
specify which portions of their profile are visible to the general public (that is, to both
LinkedIn members and nonmembers), and which portions are visible only to direct
connections, to the member’s "network" (consisting of LinkedIn members within three
degrees of connectivity), or to all LinkedIn members. This case deals only with profiles
made visible to the general public.
Direct connections (or first-degree connections) are people to whom a LinkedIn member
is connected by virtue of having invited them to connect and had the invitation

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

38

accepted, or of having accepted their invitation to connect. Second-degree
connections are people connected to a member’s first-degree connections. Thirddegree connections are people connected to a member’s second-degree connections.
A LinkedIn member’s network consists of the member’s first-degree, second-degree, and
third-degree connections, as well as fellow members of the same LinkedIn Groups
(groups of members in the same industry or with similar interests that any member can
request to join).
LinkedIn also offers all members—whatever their profile privacy settings—a "Do Not
Broadcast" option with respect to every change they make to their profiles. If a LinkedIn
member selects this option, her connections will not be notified when she updates her
profile information, although the updated information will still appear on her profile page
(and thus be visible to anyone permitted to view her profile under her general privacy
setting). More than 50 million LinkedIn members have, at some point, elected to employ
the "Do Not Broadcast" feature, and approximately 20 percent of all active users who
updated their profiles between July 2016 and July 2017—whatever their privacy setting—
employed the "Do Not Broadcast" setting.
LinkedIn has taken steps to protect the data on its website from what it perceives as
misuse or misappropriation. The instructions in LinkedIn’s "robots.txt" file—a text file used
by website owners to communicate with search engine crawlers and other web robots—
prohibit access to LinkedIn servers via automated bots, except that certain entities, like
the Google search engine, have express permission from LinkedIn for bot access.
LinkedIn also employs several technological systems to detect suspicious activity and
restrict automated scraping. For example, LinkedIn’s Quicksand system detects nonhuman activity indicative of scraping; its Sentinel system throttles (slows or limits) or even
blocks activity from suspicious IP addresses; and its Org Block system generates a list of
known "bad" IP addresses serving as large-scale scrapers. In total, LinkedIn blocks
approximately 95 million automated attempts to scrape data every day, and has
restricted over 11 million accounts suspected of violating its User Agreement, including
through scraping.
Section 8.2 of the LinkedIn User Agreement to which hiQ agreed states that users agree
not to "[s]crape or copy profiles and information of others through any means (including
crawlers, browser plugins and add-ons, and any other technology or manual work),"
"[c]opy or use the information, content or data on LinkedIn in connection with a
competitive service (as determined by LinkedIn)," "[u]se manual or automated software,
devices, scripts robots, other means or processes to access, ‘scrape,’ ‘crawl’ or ‘spider’
the Services or any related data or information," or "[u]se bots or other automated
methods to access the Services." HiQ is no longer bound by the User Agreement, as
LinkedIn has terminated hiQ’s user status.
HiQ is a data analytics company founded in 2012. Using automated bots, it scrapes
information that LinkedIn users have included on public LinkedIn profiles, including name,
job title, work history, and skills. It then uses that information, along with a proprietary
predictive algorithm, to yield "people analytics," which it sells to business clients.
HiQ offers two such analytics. The first, Keeper, purports to identify employees at the
greatest risk of being recruited away. According to hiQ, the product enables employers
to offer career development opportunities, retention bonuses, or other perks to retain
valuable employees. The second, Skill Mapper, summarizes employees’ skills in the
aggregate. Among other things, the tool is supposed to help employers identify skill gaps
in their workforces so that they can offer internal training in those areas, promoting
internal mobility and reducing the expense of external recruitment.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

39

HiQ regularly organizes "Elevate" conferences, during which participants discuss hiQ’s
business model and share best practices in the people analytics field. LinkedIn
representatives participated in Elevate conferences beginning in October 2015. At least
ten LinkedIn representatives attended the conferences. LinkedIn employees have also
spoken at Elevate conferences. In 2016, a LinkedIn employee was awarded the Elevate
"Impact Award." LinkedIn employees thus had an opportunity to learn about hiQ’s
products, including "that [one of] hiQ’s product[s] used data from a variety of sources—
internal and external—to predict employee attrition" and that hiQ "collected skills data
from public professional profiles in order to provide hiQ’s customers information about
their employees’ skill sets."
In recent years, LinkedIn has explored ways to capitalize on the vast amounts of data
contained in LinkedIn profiles by marketing new products. In June 2017, LinkedIn’s Chief
Executive Officer ("CEO"), Jeff Weiner, appearing on CBS, explained that LinkedIn hoped
to "leverage all this extraordinary data we’ve been able to collect by virtue of having
500 million people join the site." Weiner mentioned as possibilities providing employers
with data-driven insights about what skills they will need to grow and where they can find
employees with those skills. Since then, LinkedIn has announced a new product, Talent
Insights, which analyzes LinkedIn data to provide companies with such data-driven
information.
In May 2017, LinkedIn sent hiQ a cease-and-desist letter, asserting that hiQ was in
violation of LinkedIn’s User Agreement and demanding that hiQ stop accessing and
copying data from LinkedIn’s server. The letter stated that if hiQ accessed LinkedIn’s
data in the future, it would be violating state and federal law, including the Computer
Fraud and Abuse Act ("CFAA"), the Digital Millennium Copyright Act ("DMCA"), California
Penal Code § 502(c), and the California common law of trespass. The letter further stated
that LinkedIn had "implemented technical measures to prevent hiQ from accessing, and
assisting others to access, LinkedIn’s site, through systems that detect, monitor, and block
scraping activity."
HiQ’s response was to demand that LinkedIn recognize hiQ’s right to access LinkedIn’s
public pages and to threaten to seek an injunction if LinkedIn refused. A week later, hiQ
filed suit, seeking injunctive relief based on California law and a declaratory judgment
that LinkedIn could not lawfully invoke the CFAA, the DMCA, California Penal Code §
502(c), or the common law of trespass against it. HiQ also filed a request for a temporary
restraining order, which the parties subsequently agreed to convert into a motion for a
preliminary injunction.
The district court granted hiQ’s motion. It ordered LinkedIn to withdraw its cease-anddesist letter, to remove any existing technical barriers to hiQ’s access to public profiles,
and to refrain from putting in place any legal or technical measures with the effect of
blocking hiQ’s access to public profiles. LinkedIn timely appealed.
… The pivotal CFAA question here is whether once hiQ received LinkedIn’s cease-anddesist letter, any further scraping and use of LinkedIn’s data was "without authorization"
within the meaning of the CFAA and thus a violation of the statute. 18 U.S.C. § 1030(a)(2).
If so, hiQ could have no legal right of access to LinkedIn’s data and so could not
succeed on any of its state law claims, including the tortious interference with contract
claim we have held otherwise sufficient for preliminary injunction purposes.
We have held in another context that the phrase " ‘without authorization’ is a nontechnical term that, given its plain and ordinary meaning, means accessing a protected

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

40

computer without permission." Nosal II , 844 F.3d at 1028. Nosal II involved an employee
accessing without permission an employer’s private computer for which access
permissions in the form of user accounts were required. Id. at 1028–29. Nosal II did not
address whether access can be "without authorization" under the CFAA where, as here,
prior authorization is not generally required, but a particular person—or bot—is refused
access. HiQ’s position is that Nosal II is consistent with the conclusion that where access is
open to the general public, the CFAA "without authorization" concept is inapplicable. At
the very least, we conclude, hiQ has raised a serious question as to this issue.
First, the wording of the statute, forbidding "access[ ] ... without authorization," 18 U.S.C. §
1030(a)(2), suggests a baseline in which access is not generally available and so
permission is ordinarily required. "Authorization" is an affirmative notion, indicating that
access is restricted to those specially recognized or admitted. See, e.g. , Black’s Law
Dictionary (10th ed. 2014) (defining "authorization" as "[o]fficial permission to do
something; sanction or warrant"). Where the default is free access without authorization,
in ordinary parlance one would characterize selective denial of access as a ban, not as
a lack of "authorization." Cf. Blankenhorn v. City of Orange , 485 F.3d 463, 472 (9th Cir.
2007) (characterizing the exclusion of the plaintiff in particular from a shopping mall as
"bann[ing]").
Second, even if this interpretation is debatable, the legislative history of the statute
confirms our understanding. "If [a] statute’s terms are ambiguous, we may use ...
legislative history[ ] and the statute’s overall purpose to illuminate Congress’s intent."
Jonah R. v. Carmona , 446 F.3d 1000, 1005 (9th Cir. 2006).
The CFAA was enacted to prevent intentional intrusion onto someone else’s computer—
specifically, computer hacking. See United States v. Nosal (Nosal I) , 676 F.3d 854, 858 (9th
Cir. 2012) (citing S. Rep. No. 99-432, at 9 (1986) (Conf. Rep.)).
The 1984 House Report on the CFAA explicitly analogized the conduct prohibited by
section 1030 to forced entry: "It is noteworthy that section 1030 deals with an
‘unauthorized access’ concept of computer fraud rather than the mere use of a
computer. Thus, the conduct prohibited is analogous to that of ‘breaking and entering’
....’ " H.R. Rep. No. 98-894, at 20 (1984); see also id. at 10 (describing the problem of "
‘hackers’ who have been able to access (trespass into) both private and public
computer systems"). Senator Jeremiah Denton similarly characterized the CFAA as a
statute designed to prevent unlawful intrusion into otherwise inaccessible computers,
observing that "[t]he bill makes it clear that unauthorized access to a Government
computer is a trespass offense, as surely as if the offender had entered a restricted
Government compound without proper authorization." 132 Cong. Rec. 27639 (1986)
(emphasis added). And when considering amendments to the CFAA two years later, the
House again linked computer intrusion to breaking and entering. See H.R. Rep. No. 99612, at 5–6 (1986) (describing "the expanding group of electronic trespassers," who
trespass "just as much as if they broke a window and crawled into a home while the
occupants were away").
In recognizing that the CFAA is best understood as an anti-intrusion statute and not as a
"misappropriation statute," Nosal I , 676 F.3d at 857–58, we rejected the contract-based
interpretation of the CFAA’s "without authorization" provision adopted by some of our
sister circuits. Compare Facebook, Inc. v. Power Ventures, Inc. , 844 F.3d 1058, 1067 (9th
Cir. 2016), cert. denied , ––– U.S. ––––, 138 S. Ct. 313, 199 L.Ed.2d 206 (2017) ("[A] violation
of the terms of use of a website—without more—cannot establish liability under the
CFAA."); Nosal I , 676 F.3d at 862 ("We remain unpersuaded by the decisions of our sister

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

41

circuits that interpret the CFAA broadly to cover violations of corporate computer use
restrictions or violations of a duty of loyalty."), with EF Cultural Travel BV v. Explorica, Inc. ,
274 F.3d 577, 583–84 (1st Cir. 2001) (holding that violations of a confidentiality agreement
or other contractual restraints could give rise to a claim for unauthorized access under
the CFAA); United States v. Rodriguez , 628 F.3d 1258, 1263 (11th Cir. 2010) (holding that a
defendant "exceeds authorized access" when violating policies governing authorized
use of databases).
We therefore look to whether the conduct at issue is analogous to "breaking and
entering." H.R. Rep. No. 98-894, at 20. Significantly, the version of the CFAA initially
enacted in 1984 was limited to a narrow range of computers—namely, those containing
national security information or financial data and those operated by or on behalf of the
government. See Counterfeit Access Device and Computer Fraud and Abuse Act of
1984, Pub. L. No. 98-473, § 2102, 98 Stat. 2190, 2190–91. None of the computers to which
the CFAA initially applied were accessible to the general public; affirmative authorization
of some kind was presumptively required.
When section 1030(a)(2)(c) was added in 1996 to extend the prohibition on unauthorized
access to any "protected computer," the Senate Judiciary Committee explained that
the amendment was designed to "to increase protection for the privacy and
confidentiality of computer information." S. Rep. No. 104-357, at 7 (emphasis added). The
legislative history of section 1030 thus makes clear that the prohibition on unauthorized
access is properly understood to apply only to private information—information
delineated as private through use of a permission requirement of some sort. As one
prominent commentator has put it, "an authentication requirement, such as a password
gate, is needed to create the necessary barrier that divides open spaces from closed
spaces on the Web." Orin S. Kerr, Norms of Computer Trespass , 116 Colum. L. Rev. 1143,
1161 (2016). Moreover, elsewhere in the statute, password fraud is cited as a means by
which a computer may be accessed without authorization, see 18 U.S.C. § 1030(a)(6),
bolstering the idea that authorization is only required for password-protected sites or sites
that otherwise prevent the general public from viewing the information.
We therefore conclude that hiQ has raised a serious question as to whether the
reference to access "without authorization" limits the scope of the statutory coverage to
computer information for which authorization or access permission, such as password
authentication, is generally required. Put differently, the CFAA contemplates the
existence of three kinds of computer information: (1) information for which access is
open to the general public and permission is not required, (2) information for which
authorization is required and has been given, and (3) information for which authorization
is required but has not been given (or, in the case of the prohibition on exceeding
authorized access, has not been given for the part of the system accessed). Public
LinkedIn profiles, available to anyone with an Internet connection, fall into the first
category. With regard to such information, the "breaking and entering" analogue
invoked so frequently during congressional consideration has no application, and the
concept of "without authorization" is inapt.
Neither of the cases LinkedIn principally relies upon is to the contrary. LinkedIn first cites
Nosal II , 844 F.3d 1024 (9th Cir. 2016). As we have already stated, Nosal II held that a
former employee who used current employees’ login credentials to access company
computers and collect confidential information had acted " ‘without authorization’ in
violation of the CFAA." Nosal II , 844 F.3d at 1038. The computer information the
defendant accessed in Nosal II was thus plainly one which no one could access without
authorization.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

42

So too with regard to the system at issue in Power Ventures , 844 F.3d 1058 (9th Cir. 2016),
the other precedent upon which LinkedIn relies. In that case, Facebook sued Power
Ventures, a social networking website that aggregated social networking information
from multiple platforms, for accessing Facebook users’ data and using that data to send
mass messages as part of a promotional campaign. Id. at 1062–63. After Facebook sent
a cease-and-desist letter, Power Ventures continued to circumvent IP barriers and gain
access to password-protected Facebook member profiles. Id. at 1063. We held that after
receiving an individualized cease-and-desist letter, Power Ventures had accessed
Facebook computers "without authorization" and was therefore liable under the CFAA.
Id. at 1067–68. But we specifically recognized that "Facebook has tried to limit and
control access to its website" as to the purposes for which Power Ventures sought to use
it. Id. at 1063. Indeed, Facebook requires its users to register with a unique username and
password, and Power Ventures required that Facebook users provide their Facebook
username and password to access their Facebook data on Power Ventures’ platform.
Facebook, Inc. v. Power Ventures, Inc. , 844 F. Supp. 2d 1025, 1028 (N.D. Cal. 2012). While
Power Ventures was gathering user data that was protected by Facebook’s username
and password authentication system, the data hiQ was scraping was available to
anyone with a web browser.
In sum, Nosal II and Power Ventures control situations in which authorization generally is
required and has either never been given or has been revoked. As Power Ventures
indicated, the two cases do not control the situation present here, in which information is
"presumptively open to all comers." Power Ventures , 844 F.3d at 1067 n.2.
… For all these reasons, it appears that the CFAA’s prohibition on accessing a computer
"without authorization" is violated when a person circumvents a computer’s generally
applicable rules regarding access permissions, such as username and password
requirements, to gain access to a computer. It is likely that when a computer network
generally permits public access to its data, a user’s accessing that publicly available
data will not constitute access without authorization under the CFAA. The data hiQ seeks
to access is not owned by LinkedIn and has not been demarcated by LinkedIn as private
using such an authorization system. …
Less than two weeks after the Supreme Court’s decision in Van Buren, the Court granted
LinkedIn’s request for review of the Ninth Circuit’s ruling, immediately vacating the Ninth Circuit’s
ruling and remanding the case back to the Ninth Circuit for reconsideration in light of Van Buren.

•

Does Van Buren require a different outcome?

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

43

7. What if the Attacker is a Foreign Government? (I)

Learning objectives
1. Be able to describe (and distinguish among) the various categories of state behavior in the
cyber domain
2. Appreciate the point of having the ability to apply those distinctions: the idea is no more and
no less than to help ensure clear-eyed decisionmaking when responding to a situation that
appears to involve an adversarial cyber action from a foreign government.
3. Bear in mind that a given scenario might implicate more than one such category.
4. Understand the problem of indeterminacy: given missing facts, or incorrect beliefs, it may be
very hard in practice to apply these categories accurately.
5. Understand the problem of multiplicity: a given scenario might actually (or seemingly)
involve more than one possible purpose
6. Understand that everything can change over time: at any given moment you are looking at
a snapshot, but the facts might have been different before and might change again later.
This suggests the need to continuously reassess.
7. Understand that the “what is it” question is different from (though it might be informed by)
the “who done it” question.
8. Understand that the “who done it” question typically is called “attribution” (which we’ll study
in class 8).
9. Ponder the complications where the foreign attacker is a seemingly-private actor with ties to
the government.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

44

Up until now, we have proceeded from the assumption that instances of unauthorized access
involved run-of-the-mill criminal or tortious activity conducted by private individuals or
organizations. But sometimes the perpetrator is acting on behalf of a foreign government.
Governments hack for many different (and sometimes overlapping) reasons, and we need to
introduce these possibilities before turning to the questions that arise when we consider how the
U.S. government attempts to impose costs on foreign governments in these situations.
The primary purposes behind government hacking, in no particular order, include:
o

Law Enforcement: A government may engage in hacking to advance its own law
enforcement interests. This could involve hacking to investigate or gather evidence on a
crime that has already been committed, or perhaps executing a kind of sting operation.

o

Crime: Some regimes are desperate for cash. Private persons are not the only ones who
might hack for financial gain.

o

Information Collection: Most states are in the business of stealing secrets in order to inform
decision-making or to advance other goals, though states vary widely in their capacity to
actually do this effectively. It is an ancient art, one that always has involved both technical
and non-technical means. As more and more information and communications have
gone digital, hacking has become ever more central to intelligence collection. Often we
call this “spying” or “espionage,” terms that call to mind images of civilian agencies
stealing secrets for the benefit of a government (or, in the practice of some states—though
not the United States—for the benefit of state-controlled or state-favored private
enterprises). But civilian agencies are not the only ones that engage in surreptitious
information collection. When conducted by the military, we sometimes refer to this activity
as intelligence, surveillance, and reconnaissance (“ISR”). ISR has connotations of informing
tactical, operational, or even strategic military planning. Whatever the label, though, the
bottom line is that hacking is an increasingly-necessary aspect of stealing secrets.

o

Covert Action: As our review of the CFAA underscored, the general label of “hacking”
encompasses more than just unauthorized access to steal information; sometimes the
access is sought in order to alter or destroy data or to cause harm to a system controlled
or impacted by that data. When a government pursues that approach, a question arises
regarding how to categorize the activity. Sometimes such activity will be part of an armed
conflict, and we will say more about that in just a moment. For now, what matters is that
not every such hack occurs in the context of armed conflict; indeed, most do not. And
yet they are not instances of espionage, either. So what are they? Well, if the government
involved is trying to keep its role secret, then the best answer usually will be “covert action.”
There are some complicated nuances here, at least within the U.S. legal system, when the
government entity involved is a military entity––but we will save that for later in the course.
Covert action can encompass a wide-range of cyber operations, from information
operations (propaganda, disinformation, etc.) to efforts to create damaging physical
effects (sabotage).

o

Armed Conflict: Though journalists and others routinely refer to "cyber attacks” and
“cyberwar” when talking about hostile foreign cyber activities targeting U.S. systems, the
fact is that these actions rarely actually concern genuine armed conflict involving the
United States. But they certainly could, and sometimes they really do. And so the threshold
question you must ask is: Is there already a relevant state of armed conflict, or could this
action on its own engender one? If not, then it is better not to talk in terms of war and
combat; covert action may be the better label.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

45

o

Preparation of the Battlefield: This is military jargon for the idea that it is at times useful or
even necessary for the armed forces to take certain actions in advance of potential
hostilities—sometimes far in advance—in order to be in a better position to carry out
certain operations later (that is, if and when an armed conflict actually begins). In the
physical world, for example, special operators might enter enemy territory prior to a
conflict in order to determine optimal routes, preposition supplies, and so forth. So too,
then, with cyber operations. In order to be able to take an action involving a targeted
system later, it may be wise or even necessary to establish access to that system now. Of
course, in that case, it’s best to remain undetected, lest that “preparation of the
battlefield” go to waste. But what if one actually wants to be detected? That leads us to
the distinct concept of a “hold-at-risk” strategy.

o

Hold-at-Risk: This perhaps unfamiliar phrase is a shorthand for a simple idea. It refers to
the idea that one might want to demonstrate to a rival or prospective opponent—in a
very credible way—that one has the capacity to cause damage to something that they
value. That is, the idea is to prove that you are holding something they value “at risk,” and
that the other side had best not forget this when interacting with you in other settings.
Simply put, a “hold-at-risk” strategy is an effort to improve your deterrence posture in
relation to an opponent, thus impacting their calculations and actions in a way that is
favorable to you. In this sense, it is akin to a “show of force” in which a government puts
equipment or personnel, quite visibly, in geographic position to carry out certain
operations (e.g., positioning an aircraft carrier nearby). In the cyber context, penetrating
a system that contains valuable data or controls a valuable system—and allowing the
other side to detect that you have done this—is a way of signaling that you truly do have
the means to harm that data or system (and perhaps others as well).

o

The Indeterminacy and Multiplicity Problems: Here’s the most important point of them all:
In many instances, it is not easy for a defender to tell which of these aims might explain
why someone has hacked into a particular system. To be sure, it can become clear
enough once the hacker begins making use of that access in order to do certain things.
But because all of the aforementioned motivations for state-sponsored hacking begin with
social engineering or malware in order to gain unauthorized access to a system, a
defender who has detected such an intrusion may be left with little basis for predicting
what the intruder intends. Sometimes the context will help, of course, and eventually time
will tell. In rare instances, moreover, external sources of information might shed useful light
too. But in the meantime, the defender is left to make the best guess possible in the
circumstances. Note, too, that the intruder might have in mind one purpose at one time,
and may switch to a different purpose later.

Bearing the above in mind, perform the following exercise:
• Pick a foreign power with whom the United States has particularly bad relations.
Imagine you are in a position of authority and trust in that government, and imagine a
concrete example of an American target that you might like to have your government
penetrate for each of the purposes mentioned above.
• Be able to explain what your country gets from each scenario, as well as the offsetting
risks that might give you pause.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

46

8. What if the Attacker is a Foreign Government? (II)

Learning objectives
1. Develop a view on whether our pantheon of malicious cyber activity categories fits only for
foreign governments, or if instead it also works for activity attributed to foreign non-state
actors (groups or individuals)
2. Develop a view on whether “terrorism” is a distinct-enough category to warrant separate
inclusion in the pantheon
3. Understand the various dimensions along which the United States could be described as
unusually-vulnerable to malicious cyber activity, relative to the vulnerability of other states
4. Be able to articulate how the relative (asymmetric) vulnerability of the United States should
impact American calculations relating to deterrence in general, and the concept of
escalation dominance in particular
5. Speaking of escalation dominance: be able to define it, and relate it to the real-world
example of the U.S. response to Iranian DDoS attacks on US banks.
6. Be able to distinguish among defense, deterrence, and disruption as distinct strategies for
advancing the overall goal of minimizing the incidence and impact of hostile cyber
activities.
7. Also be able to explain how both defense and disruption strategies have a dynamic
relationship with deterrence.
8. Understand the distinction between “within-domain” and “cross-domain.”
9. Be able to explain what “escalation risk” means and how this can play a key role in the
process of determining how a government will respond to a hostile foreign cyber action.
10. Appreciate that responses do not have to be “within-domain,” and that there may be costs
or benefits to responding in a cross-domain fashion (though those costs and benefits may be
impacted by calibrating the intensity and nature of the response).
11. Understand the distinction between “attribution” and the set of
information/evidence/intelligence that supports that attribution.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

47

12. Appreciate that both attribution, and the underlying support for the attribution, can be kept
entirely private, made wholly public, or something in between.
13. Consider why a government might calibrate things along those dimensions, and why it might
matter which foreign government is at issue.
14. Understand that attribution can itself be a cost-imposition mechanisms (“name-andshame”), but also recognize that countries vary in the degree to which this will have an
impact.
A. A Framework for Thinking about Threat Reduction
Conversations about the threat foreign governments may pose to networks in the United States
(including not just threats associated with formal parts of those governments, like their militaries
and intelligence services, but also private persons/organizations that may act on behalf of those
governments) often are framed in terms of “deterrence,” “escalation risk,” and other familiar
concepts from the international relations and security literatures. And rightly so. Before exploring
those concepts in detail, however, it might help to spend a moment considering, at a high level
of generality, how such concepts fit into a larger picture.
Let’s say you are the President of the United States, and you and your advisors are formulating a
strategy in response to your belief that a foreign government—let’s say Iran—might take an action
you view as a serious threat to U.S. interests. That action could involve the use of an existing
capability in some unwelcome way––a use of military force, an intervention in the oil market, etc.
Or it might involve an attempt to acquire some new capability that would make the foreign state
a greater threat in the future––a nuclear bomb, for example. The point is, your overarching goal
is to minimize the net danger.
To achieve that overarching goal, there are at least three subsidiary strategies you might consider
(they are not mutually exclusive):

Disruption

Deterrence

Defense

Prevent the other state
from becoming
capable of taking the
undesirable action.
Or, if it has capability
already, destroy (or at
least degrade) it.

Convince them not to
take the undesirable
action by maximizing
their expected costs
and minimizing their
expected benefits.

Minimize the harm you
would suffer if the
undesirable action
occurs by maximizing
relevant defenses and
establishing resiliency.

Note that the disruption, deterrence, and defense strategies can relate to one another. For
example, if you build strong defenses and your adversary knows this, this may cause an increase
in their expected costs of the action (for they may conclude they must put more of their own
resources into the effort) or a decrease in their expected benefits (for they may have to revise
their odds of success). Either way, their cost-benefit assessment will be less appealing, and the
degree of deterrent persuasion increased.
B. Notes on the U.S. Defensive Posture in Cyberspace: America the Vulnerable?
Read this article about how extensive “digitalization” of the United States results in strategic
vulnerabilities that, in turn, cast a shadow over U.S. policymaking and operational decision-making
in response to adversary actions in cyberspace.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

48

As you read, consider the following:
• What are the six vulnerabilities described, and precisely why it should matter to U.S.
policymakers pondering their options in response to hostile foreign cyber activity?
• What larger lessons do you draw?
C. Key Terms Relating to Deterrence
The following set of readings are designed to introduce you to some of the terminology related to
deterrence.

Skim this article in order to develop an understanding of these terms:
• Deterrence
• Cross-domain deterrence
• Within-domain deterrence
• Escalation
• Escalation risk
• Escalation dominance
Next, read the following excerpts from this article by Shaun Waterman for Cyberscoop:
When the Obama administration was weighing a response to distributed denial-ofservice attacks against U.S. banks in 2012, officials vetoed any retaliation because they
were worried that the country’s digital infrastructure wouldn’t be able to deal with
counterattacks, according to former Director of National Intelligence James Clapper.
The DDoS attacks, which slammed dozens of U.S. banks with increasing force, were
traced back to Iran by U.S. intelligence, Clapper recently told the ICF CyberSci
Symposium in Fairfax, Virginia. The attacks, launched from networks of compromised
servers around the world, struck 46 major banks and other financial institutions —
including Bank of America, Capital One, JPMorgan Chase, PNC Bank, New York Stock
Exchange and Nasdaq. Hundreds of thousands of customers were unable to access their
bank accounts online and the victim companies spent tens of millions of dollars to
mitigate the attacks.
“We’d all built up quite a head of steam, [thinking] ‘By God, we’re not going to let the
Iranians get away with this! We’re going to do something!'” Clapper said, describing a
2012 National Security Council meeting where intelligence officials laid out options for
retaliatory cyber measures against Iranian hackers believed responsible.
“We had teed up a bunch of options for cyberattack against the very same players who
had participated in these denial of service attacks [against the banks],” he said. “The
initial instinct was: Let’s attack back.”
According to Clapper, then-Secretary of the Treasury Tim Geithner ultimately put a stop
to the attack after expressing concern over the banks’ ability to withstand a counterretaliation. Additionally, the U.S. also chose not to formally raise the issue with Iran
through diplomatic channels, but instead enlisted allies across the world to help
dismantle the global infrastructure used to launch the attacks.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

49

Clapper added that the conclusion he drew was that no matter how accurate your
attribution, cyberattacks were always going to rely on robust online fortifications.
“The big take away for me, is that unless you are very confident in your cyberdefenses,
it’s almost pointless to talk about cyberattacks. The very essence of offense is, you have
to have a good defense,” he said. “And what complicates it further is, we in the U.S., we
have an inclination to be very precise, very limited, very surgical, legalistic. You cannot
be assured that the adversary is going to be similarly precise and surgical and legalistic.
So if you attack them, you have a anticipate a probably much … greater retaliation as a
result.”
Sam Visner, an ICF executive and former senior NSA official, told CyberScoop the
questions the decision raised made sense to him.
From Visner’s perspective, the question is “Would Iran’s counteraction also be in
proportion, or would it have sought to demonstrate the capacity to damage and/or
destabilize the international monetary system? Would Iran have seen itself as a
stakeholder in the stability of that system, or as an insurgent?”
It was the prospect of just such an all-out assault by Iranian hackers, rather than any
doubt about the attribution, that stayed the hand of the U.S., Clapper said.
“We had the Iranians cold,” he added, “The forensics were quite precise, quite good
and also quite fun.”
Clapper’s remarks are a reference to the detailed profiles that U.S. agencies were able
to build of the alleged attackers, many elements of which were made public when the
Justice Department indicted seven of them last year. One hacker, for instance, was
allegedly given credit towards his compulsory military service obligations for his work on
the huge botnet that launched the assault — at that time among the largest DDoS
attacks ever seen.
Clapper did not elaborate on his comments any further after his speech when
approached by reporters. The Department of the Treasury declined to comment through
a spokesman. Representatives of Warburg Pincus, where Geithner now works, did not
respond to a request for comment.
Clapper said the incident was one of two in Obama’s tenure where the administration
weighed, but ultimately decided against online retaliation. The other incident was the
North Korean attack on Sony Pictures Entertainment in 2014.
“Again, we had excellent attribution with the North Koreans,” he said, adding that there
was a different “complicating issue” in this case. “Was it okay to go through some other
country’s infrastructure when you’re doing essentially a cyber act of war against your
adversary?” he asked.
North Korea, which has very limited connectivity to the outside world, relies on China for
its internet access.
When intelligence officials raised this option, Clapper said, “The lawyers went nuts, so we
didn’t do anything on the cyber front. We ended up sanctioning a bunch of North
Korean generals.”

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

50

Clapper added he believed that, at least in the first term of the Obama administration,
officials had made the mistake of separating cyber out from other instruments of national
power; both for the U.S. and its adversaries.
“In the end,” he concluded, “cyber’s a tool, not an end in and of itself… [Our
adversaries] do it to achieve an outcome, not because cyber’s cool.”

Consider the following questions:
• Should the government always make public that it has taken an action in response to
another state’s hacking? Can deterrence work without public claims of that kind?
• In answering those questions, give thought to the different possible “audiences” for
such actions. Obviously, one would be the foreign government to which the U.S. is
responding. But who else might be watching?
On “attribution” in the cyberspace context, we’ll read to excerpts. First, consider the following
excerpt from this Lily Hay Newman article in Wired:
AFTER MONTHS OF news about Russian meddling in this year's US presidential election
you're probably sick of speculation and ready for answers: What exactly did Russia do
and why? It sounds simple enough, but a fundamental concept in cybersecurity and
digital forensics is the fact that it is sometimes extremely difficult after a cyberattack to
definitively name a perpetrator. Hackers have a lot of technical tools at their disposal to
cover their tracks. And even when analysts figure out which computer a hacker used,
going from there to who used it is very difficult. This is known as the attribution problem.
TL;DR: The attribution problem is the idea that identifying the source of a cyber attack or
cyber crime is often complicated and difficult because there is no physical act to
observe and attackers can use digital tools to extensively cover their tracks.
The quandary has gained visibility in recent years as more nation-state hacking makes
attribution a geopolitical issue. And this amplifies the problem significantly by
necessitating public disclosures. In the US, when the intelligence community is in
agreement about an attribution and is ready for the presidential administration to share it
publicly, citizens want proof or an explanation of how the attribution was reached. But
releasing information about technical and physical intelligence capabilities and
initiatives can undermine current and future operations. As a result, even when
intelligence agencies can make a determination with a high degree of confidence, they
face a second attribution problem in the court of public opinion.
The idea that attribution is not possible really doesn’t carry any weight in the technically
informed community anymore.
"Obviously there are cases where we cannot come to a clear conclusion in digital
forensics. It’s always a question of what evidence did you get," says Thomas Rid, a
cybersecurity-focused professor in the department of War Studies at King’s College
London and author of the 2014 paper Attributing Cyber Attacks. "But there is still this
'attribution is impossible' knee jerk reaction that occasionally pops up, which really
doesn’t make much sense. The idea that attribution is not possible really doesn’t carry
any weight in the technically informed community anymore."

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

51

When the Obama administration placed blame for the 2014 Sony Pictures hack on North
Korea, for example, much of the security community agreed with the consensus, but
there was also some prominent skepticism. Part of this was because Obama did not
disclose that the US had the direct ability to spy on North Korean internet activity before
and during the attack on Sony. These details were later reported by the New York Times.
But inconsistent access to full evidence can make it difficult for individuals and civilian
security firms to vet government attributions.
In 2016, President-elect Trump has leaned on the attribution problem to dismiss consensus
about Russia's political hacking during the presidential campaign. Speaking to FOX News
on Dec. 11, Trump said, "Once they hack, if you don't catch them in the act you're not
going to catch them. [Intelligence agencies] have no idea if it's Russia or China or
somebody. It could be somebody sitting in a bed some place. ... I don't really think it is
[the Russians], but who knows? I don't know either. They don't know and I don't know."
President-elect Trump has made many similar statements referencing the difficulty of
tracing well-executed cyber attacks. But this frames the attribution problem at an
inaccurate extreme, suggesting that it is absolutely never possible to determine the
source of a cyber attack unless analysts observe it as it is happening. (Trump's statements
are also inaccurate given that digital forensic analysts, particularly the civilian firm
CrowdStrike, did catch Russian actors "in the act.") "What I can say is in my experience
being in an intelligence agency, if the CIA came to me and had a high confidence level
with supporting evidence—to dismiss that is definitely alarming," says David Kennedy,
CEO of the security firm TrustedSec, who formerly worked at the NSA and with the Marine
Corps’ signal intelligence unit. "No supporting evidence has been released to the public,
but would assume it has to Obama, intelligence officers, and Trump."
In a broad sense, the attribution problem applies to any type of investigation, not just a
digital one. There isn't always iron-clad direct proof of who committed a crime and it can
be difficult or even impossible to discern a culprit from the evidence and information
available. Nonetheless, it is possible to codify a justice system that identifies suspects and
then decides whether they are innocent or guilty of crimes based on available
evidence. Absent perfect information, a justice system will certainly make inaccurate
determinations at times, but if the overall rate of success is satisfactory the framework
can function.
Though cyber attacks and digital attribution are in their infancy compared with that of
physical crimes, systems for cyber attribution are slowly developing in the same way. And
since attribution deals in degrees of certainty, not absolutes, people are still evolving their
standard for what rate of success and confidence level is enough. "Attribution is
extremely difficult and requires intelligence sources that are reliable and accurate,"
Kennedy says. "The intelligence community typically monitors specific groups and activity
in order to have high confidence. It's not a perfect system, but the US is one of the best."
For now, the intelligence community consensus about the Russian attribution is not firm
enough for some, who still have doubts about whether the US can reasonably base
retaliation against Russia on it. The attribution problem is exactly that—a problem. But it is
not an irreconcilable barrier. "You can identify hackers even if you do not catch them in
the act," Rid says. "Digital forensics as a profession is exactly there to solve that problem
and it can be solved. Sometimes it can’t, but often it can."

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

52

Next, read this excerpt from this piece by David Sanger and Martin Fackler in the New York
Times:

The trail that led American officials to blame North Korea for the destructive cyberattack
on Sony Pictures Entertainment in November winds back to 2010, when the National
Security Agency scrambled to break into the computer systems of a country considered
one of the most impenetrable targets on earth.
Spurred by growing concern about North Korea’s maturing capabilities, the American
spy agency drilled into the Chinese networks that connect North Korea to the outside
world, picked through connections in Malaysia favored by North Korean hackers and
penetrated directly into the North with the help of South Korea and other American
allies, according to former United States and foreign officials, computer experts later
briefed on the operations and a newly disclosed N.S.A. document.
A classified security agency program expanded into an ambitious effort, officials said, to
place malware that could track the internal workings of many of the computers and
networks used by the North’s hackers, a force that South Korea’s military recently said
numbers roughly 6,000 people. Most are commanded by the country’s main intelligence
service, called the Reconnaissance General Bureau, and Bureau 121, its secretive
hacking unit, with a large outpost in China.
The evidence gathered by the “early warning radar” of software painstakingly hidden to
monitor North Korea’s activities proved critical in persuading President Obama to accuse
the government of Kim Jong-un of ordering the Sony attack, according to the officials
and experts, who spoke on the condition of anonymity about the classified N.S.A.
operation.
Mr. Obama’s decision to accuse North Korea of ordering the largest destructive attack
against an American target — and to promise retaliation, which has begun in the form of
new economic sanctions — was highly unusual: The United States had never explicitly
charged another government with mounting a cyberattack on American targets.
Mr. Obama is cautious in drawing stark conclusions from intelligence, aides say. But in this
case “he had no doubt,” according to one senior American military official.
“Attributing where attacks come from is incredibly difficult and slow,” said James A.
Lewis, a cyberwarfare expert at the Center for Strategic and International Studies in
Washington. “The speed and certainty with which the United States made its
determinations about North Korea told you that something was different here — that
they had some kind of inside view.”
For about a decade, the United States has implanted “beacons,” which can map a
computer network, along with surveillance software and occasionally even destructive
malware in the computer systems of foreign adversaries. The government spends billions
of dollars on the technology, which was crucial to the American and Israeli attacks on
Iran’s nuclear program, and documents previously disclosed by Edward J. Snowden, the
former security agency contractor, demonstrated how widely they have been deployed
against China.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

53

But fearing the exposure of its methods in a country that remains a black hole for
intelligence gathering, American officials have declined to talk publicly about the role
the technology played in Washington’s assessment that the North Korean government
had ordered the attack on Sony.
The extensive American penetration of the North Korean system also raises questions
about why the United States was not able to alert Sony as the attacks took shape last fall,
even though the North had warned, as early as June, that the release of the movie “The
Interview,” a crude comedy about a C.I.A. plot to assassinate the North’s leader, would
be “an act of war.”
Dinner in Pyongyang
The N.S.A.’s success in getting into North Korea’s systems in recent years should have
allowed the agency to see the first “spear phishing” attacks on Sony — the use of emails
that put malicious code into a computer system if an unknowing user clicks on a link —
when the attacks began in early September, according to two American officials.
But those attacks did not look unusual. Only in retrospect did investigators determine that
the North had stolen the “credentials” of a Sony systems administrator, which allowed the
hackers to roam freely inside Sony’s systems.
In recent weeks, investigators have concluded that the hackers spent more than two
months, from mid-September to mid-November, mapping Sony’s computer systems,
identifying critical files and planning how to destroy computers and servers.
“They were incredibly careful, and patient,” said one person briefed on the investigation.
But he added that even with their view into the North’s activities, American intelligence
agencies “couldn’t really understand the severity” of the destruction that was coming
when the attacks began Nov. 24.
In fact, when, Gen. James R. Clapper Jr., the director of national intelligence, had an
impromptu dinner in early November with his North Korean counterpart during a secret
mission to Pyongyang to secure the release of two imprisoned Americans, he made no
mention of Sony or the North’s growing hacking campaigns, officials say.
In a recent speech at Fordham University in New York, Mr. Clapper acknowledged that
the commander of the Reconnaissance General Bureau, Kim Yong-chol, with whom he
traded barbs over the 12-course dinner, was “later responsible for overseeing the attack
against Sony.” (General Clapper praised the food; his hosts later presented him with a bill
for his share of the meal.)
Asked about General Clapper’s knowledge of the Sony attacks from the North when he
attended the dinner, Brian P. Hale, a spokesman for the director of national intelligence,
said that the director did not know he would meet his intelligence counterpart and that
the purpose of his trip to North Korea “was solely to secure the release of the two
detained U.S. citizens.”
“Because of the sensitivities surrounding the effort” to win the Americans’ release, Mr.
Hale said, “the D.N.I. was focused on the task and did not want to derail any progress by
discussing other matters.” But he said General Clapper was acutely aware of the North’s
growing capabilities.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

54

Jang Sae-yul, a former North Korean army programmer who defected in 2007, speaking
in an interview in Seoul, said: “They have built up formidable hacking skills. They have
spent almost 30 years getting ready, learning how to do this and this alone, how to target
specific countries.”
Still, the sophistication of the Sony hack was such that many experts say they are
skeptical that North Korea was the culprit, or the lone culprit. They have suggested it was
an insider, a disgruntled Sony ex-employee or an outside group cleverly mimicking North
Korean hackers. Many remain unconvinced by the efforts of the F.B.I. director, James B.
Comey, to answer critics by disclosing some of the American evidence.
Mr. Comey told the same Fordham conference that the North Koreans got “sloppy” in
hiding their tracks, and that hackers periodically “connected directly and we could see
them.”
“And we could see that the I.P. addresses that were being used to post and to send the
emails were coming from I.P.s that were exclusively used by the North Koreans,” he said.
Some of those addresses appear to be in China, experts say.
The skeptics say, however, that it would not be that difficult for hackers who wanted to
appear to be North Korean to fake their whereabouts. Mr. Comey said there was other
evidence he could not discuss. So did Adm. Michael S. Rogers, the N.S.A. director, who
told the Fordham conference that after reviewing the classified data he had “high
confidence” the North had ordered the action.
A Growing Capability
North Korea built its first computer with vacuum tubes in 1965, with engineers trained in
France. For a brief time, it appeared ahead of South Korea and of China, which not only
caught up but also came to build major elements of their economic success on their
hardware and software.
Defectors say that the Internet was first viewed by North Korea’s leadership as a threat,
something that could taint its citizens with outside ideas.
But Kim Heung-kwang, a defector who said in an interview that he helped train many of
the North’s first cyberspies, recalled that in the early 1990s a group of North Korean
computer experts came back from China with a “very strange new idea”: Use the
Internet to steal secrets and attack the government’s enemies. “The Chinese are already
doing it,” he quoted one of the experts as saying.
Defectors report that the North Korean military was interested. So was the ruling Workers’
Party, which in 1994 sent 15 North Koreans to a military academy in Beijing to learn about
hacking. When they returned, they formed the core of the External Information
Intelligence Office, which hacked into websites, penetrated fire walls and stole
information abroad. Because the North had so few connections to the outside world, the
hackers did much of their work in China and Japan.
According to Mr. Kim, the military began training computer “warriors” in earnest in 1996
and two years later opened Bureau 121, now the primary cyberattack unit. Members
were dispatched for two years of training in China and Russia. Mr. Jang said they were
envied, in part because of their freedom to travel.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

55

“They used to come back with exotic foreign clothes and expensive electronics like rice
cookers and cameras,” he said. His friends told him that Bureau 121 was divided into
different groups, each targeting a specific country or region, especially the United
States, South Korea and the North’s one ally, China.
“They spend those two years not attacking, but just learning about their target country’s
Internet,” said Mr. Jang, 46, who was a first lieutenant in a different army unit that wrote
software for war game simulations.
Mr. Jang said that as time went on, the North began diverting high school students with
the best math skills into a handful of top universities, including a military school
specializing in computer-based warfare called Mirim University, which he attended as a
young army officer.
Others were deployed to an “attack base” in the northeastern Chinese city of Shenyang,
where there are many North Korean-run hotels and restaurants. Unlike the North’s nuclear
and ballistic missile programs, the cyberforces can be used to harass South Korea and
the United States without risking a devastating response.
“Cyberwarfare is simply the modern chapter in North Korea’s long history of asymmetrical
warfare,” said a security research report in August by Hewlett-Packard.
An Attack in Seoul
When the Americans first gained access to the North Korean networks and computers in
2010, their surveillance focused on the North’s nuclear program and its leadership, as well
as efforts to detect attacks aimed at United States military forces in South Korea, said one
former American official. (The German magazine Der Spiegel published an N.S.A.
document on Saturday that provides some details of South Korea’s help in spying on the
North.) Then a highly destructive attack in 2013 on South Korean banks and media
companies suggested that North Korea was becoming a greater threat, and the focus
shifted.
“The big target was the hackers,” the official said.
That attack knocked out almost 50,000 computers and servers in South Korea for several
days at five banks and television broadcasters.
The hackers were patient, spending nine months probing the South Korean systems. But
they also made the mistake seen in the Sony hack, at one point revealing what South
Korean analysts believe to have been their true I.P. addresses. Lim Jong-in, dean of the
Graduate School of Information Security at Korea University, said those addresses were
traced back to Shenyang, and fell within a spectrum of I.P. addresses linked to North
Korean companies.
The attack was studied by American intelligence agencies. But after the North issued its
warnings about Sony’s movie last June, American officials appear to have made no
reference to the risk in their discussions with Sony executives. Even when the spearphishing attacks began in September — against Sony and other targets — “it didn’t set
off alarm bells,” according to one person involved in the investigation.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

56

The result is that American officials began to focus on North Korea only after the
destructive attacks began in November, when pictures of skulls and gruesome images of
Sony executives appeared on the screens of company employees. (That propaganda
move by the hackers may have worked to Sony’s benefit: Some employees unplugged
their computers immediately, saving some data from destruction.)
It did not take long for American officials to conclude that the source of the attack was
North Korea, officials say. “Figuring out how to respond was a lot harder,” one White
House official said.

Consider these questions:
• Why do some claim attribution is especially difficult in the cyberspace context, and
why would that be different than, say, nuclear weapons?
• What impact does such difficulty mean as to decision-making in particular cases?
• Should the government always make public that it has taken an action in response to
another state’s hacking? Can deterrence work without public claims of that kind?
• In answering those questions, give thought to the different possible “audiences” for
such actions. Obviously, one would be the foreign government to which the U.S. is
responding. But who else might be watching?

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

57

9. What if the Attacker is a Foreign Government (III)

Learning Objectives
•
•
•
•

•
•

Know that, prior to 2014, US policy did not allow for the indictment of foreign government
agents for hacking activities; understand that this changed as to particular scenarios
(commercial espionage, election interference)
Appreciate that intelligence collection on such foreign activities is not, itself, a costimposition tool (though it can lead to the use of such tools).
Appreciate that diplomacy in the form of a complaint (without the threat or imposition of a
cost or prospect of a benefit) can still be viewed as a soft form of cost imposition, though
only some foreign governments will find this significant.
Understand that prosecution can be a cost-imposition tool in and of itself, but also can be a
high-credibility variant of the name-and-shame tool and further might be a useful tool for an
entirely-distinct cost-imposition strategy: creation of “international norms” of proper state
behavior in the cyber domain.
Understand that a “norm” is not the same as a rule of international “law,” and may or may
not have real constraining impact.
Appreciate how the United States and allies have worked to create international agreement
as to certain norms (including by issuing joint statements and through the UN “Group of
Government Experts” process), but with limited success given divergent national interests
involving some states (particularly Russia, China, and authoritarian states).

A. The Toolkit
A government interested in imposing costs on a foreign entity can draw, in theory, on a broad
toolkit. Options include:

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

58

1. Diplomatic complaint: using formal diplomatic channels to express displeasure, with or
without suggesting possible consequences and with or without making a specific
demand.
2. “Name and shame” for violating “norms”: going public with an attribution blaming the
foreign government for an action that violated some particular norm of international
behavior (or, if there’s a claim of actual illegality, asserting so)
3. Prosecution: pursuing criminal charges against the specific foreign persons associated
with the action in question. Sometimes this becomes a vehicle for naming-and-shaming,
notably, and also a way to put weight behind claims about where the normative and
legal lines should be drawn.
4. Civil suits: foreign governments generally enjoy immunity from civil litigation in US courts,
but suits nonetheless are attempted with frequency against both foreign government
entities and individuals.
5. Economic sanctions: one of the most commonly used tools in the American foreignpolicy toolkit are economic sanctions. Note that sanctions have more bite when other
countries follow suit (either on an ad hoc cooperative basis, or pursuant to collective
action from the United Nations)
6. Withholding other benefits: a government also can impose costs internationally by
retracting or withholding various benefits, such as loans, immigration opportunities, and
any number of other things.
7. Providing benefits to the other government’s adversaries: this can take the form of arms
sales, diplomatic support, etc.

Be prepared to discuss the pros and cons of using each of these levers.

Let’s take a closer look at some of these tools, starting with prosecution.
B. Prosecution
Consider the following account from Associate Deputy Attorney General Sujit Raman from a
speech delivered in May 2019:
For many years, we have targeted and successfully disrupted transnational criminal
syndicates engaged in cybercrime, as well as the digital infrastructure those actors
employ. More recently, we began publicly charging foreign state actors whose malicious
cyber activity broke U.S. law. It is fair to ask why we devote significant resources to
prosecuting state actors whom we may never bring to the United States to face
justice. And it is fair to ask why we shifted from an approach that relied mainly on
intelligence collection and diplomacy to one that includes a law enforcement
response. As I will explain, prosecutions of state-sponsored malicious cyber activity serve
an important purpose, even if we cannot guarantee that we will be able to produce in
court every individual involved.
Since the indictment of Chinese PLA officers in 2014, the Department of Justice has
remained focused on state-sponsored criminal activity that targets U.S. companies. We
are also now focused on activity that targets the U.S. political process. In the past two
years, the Department brought more national security cyber cases against criminals acting
on behalf of our major adversaries than in the previous five years.
There are several reasons for the increasing prosecutions. The main one is that we are
following the threat, just as we did in responding to the threat of terrorism. As I’ve

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

59

explained, nation states are engaged in activity that victimizes individuals and companies
in the United States, violates U.S. law, and departs from international norms of responsible
state behavior—norms that benefit all nations. Our criminal cases reflect our adversaries’
efforts to harm our companies and our nation.
Second, the increasing number of national security cyber cases reinforces the lesson that
our adversaries’ conduct lies outside the norms of responsible behavior. The actions we
highlight in indictments are not legitimate state-craft. They are crimes without justification
in international relations. I will say more about that in a moment.
Third, our cases reflect our increasingly sophisticated ability to attribute this criminal
conduct to the individuals and states involved. This ability is closely related to my second
point, because it shows the commitment of our law enforcement and intelligence
agencies to work closely together, while protecting intelligence sources and
methods. These partnerships, which were forged in the counterterrorism context, serve to
solidify the consensus that a law enforcement response to malign nation-state cyber
activity makes sense.
In bringing these cases, we are guided by six basic principles.
First, the Department has a duty to enforce our laws and protect our people. We cannot
refuse to act when foreign state actors violate our criminal laws, transgress established
norms, and victimize our citizens. That is especially true when such crimes often represent
severe violations of the victim’s privacy rights, and can have lasting, damaging
impact. The Department has an obligation to work toward a future where our citizens can
live and conduct their business with confidence in the integrity of their information and
institutions.
Second, attribution is the key to deterrence. “Without attribution, there will be no
consequences . . . and thus, no deterrence.”[14] Attribution through the criminal justice
system escalates the stakes for state-sponsored activity in a way that a press release or a
public statement alone would not. We have on occasion obtained custody of foreign
criminal defendants. Our indictments limit their travel. And the prospect of criminal
indictment can help deter some cyber actors from engaging in such conduct in the first
place. This can make it more difficult for states to recruit the manpower and resources for
cyber-attacks, and raise the cost of engaging in malicious cyber activity.
Third, attribution through the criminal justice system is a powerful way to expose state
conduct that violates norms of responsible behavior. It complicates our adversaries’
attempts to feign ignorance of illegal acts they thought could be taken in secret, or to
hide behind public denials. Our cases are governed by well-known policies relating to the
conduct of all federal prosecutors. An indictment is brought by a grand jury, under
established procedures; charges are brought only when the facts and law justify it. The
allegations in our indictments are thorough and detailed, and we can prove them in a
courtroom, using admissible evidence, at proof beyond any reasonable doubt. For all
these reasons, criminal indictments are among the most powerful statements we can
make as a government.
Fourth, unsealed indictments promote transparency. There will always be cases in which
our ability to expose malicious cyber activity is limited by our obligation to protect
intelligence sources and methods or sensitive ongoing investigations. But where we are
able to do so, we strive to expose such schemes to the American people and the
international community. Attribution through detailed indictments educates the public

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

60

about our adversaries’ efforts and methods to spread disinformation, steal commercial
technology, and target computer networks.
Fifth, although our goal is to hold accountable in court those we charge with trade theft
or cyber crimes, our investigations can provide critical support for the use of civil,
diplomatic, economic, and military tools. Some thoughtful critics have criticized the
Department’s so-called “name and shame” strategy on the theory that our indictments
have failed to stanch the activity. But you can’t separate our indictments from the
broader array of tools our government now uses to counter malign cyber activity. These
include freezing assets or prohibiting transactions, or adding companies to the
Department of Commerce Entity List. As the National Security Advisor has confirmed, it
also includes “undertaking offensive cyber operations”[15] aimed at defending our
national interests. Our tools also include other authorities that can block criminals’ assets,
restrict their access to the banking system, and prohibit them from freely engaging in
trade. We developed this approach to address terrorism and terrorist financing. We are
applying it to the cyber threat, as well.
Finally, by using public law to emphasize the need to protect private U.S. victims against
nation-state actors, we help develop the framework of public-private cooperation that is
critical to cybersecurity. The Department tries to show through our actions how we can
help companies respond to nation-state threats they cannot face alone, in a way that
respects their status as victims. The Department has developed strong relationships with
the private sector based on our aggressive pursuit of criminal nation-state conduct,
ranging from cyber theft to information operations using third-party social media platforms.
No one seriously suggests that we can prosecute our way out of this problem. But to dismiss
the role that federal law enforcement plays in the government’s shared fight against
cyber-enabled threats is to unfairly discount—and diminish—our nation’s powerful
commitment to the rule of law, both within our borders and without.
C. Economic Sanctions
Economic sanctions are a vast and important topic, the breadth of which is well beyond the
scope of our course. Nonetheless, this section conveys what you should understand at a minimum.
When we talk of “sanctions” in this setting, we are referring to the ability of the U.S. government
either to freeze the U.S.-based assets of a foreign person, organization, or government, or to
declare some or all transactions with the sanctioned party unlawful––meaning no purchases,
sales, trade, donations, services, exchanges, etc.
Congress at times has passed laws that directly impose sanctions, but it is much more common
these days for Congress to delegate to the President the authority to impose sanctions based on
certain criteria Congress sets. For example, Congress recently enacted the Countering America’s
Adversaries Through Sanctions Act (CAATSA, pronounced “Cats-uh” or “Cots-uh”), which among
other things calls for sanctions in response to interference with U.S. elections. And definitely be
aware of the International Emergency Economic Powers Act (IEEPA, pronounced “Eye-EEP-uh”),
which since the 1970s has served as a broad delegation of authority for the president to sanction
foreign entities so long as the president has publicly declared the existence of a “national
emergency” relating to a foreign affairs matter and the sanctions are related to that situation.
Note: Don’t be misled by the seeming gravity of declaring a national emergency; the public over
time has proven to be largely uninterested when such declarations occur, and thus it has proven
relatively easy to declare them when deemed useful.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

61

By and large, presidential authority to issue sanctions under these and similar statutes ends up
being delegated, through an executive order, to the Treasury Department. The body within
Treasury that manages sanctions is the Office of Foreign Assets Control (“OFAC”). Periodically,
OFAC will announce new entities or individuals to be sanctioned under one or more of the
currently active sanction regimes.
What makes people comply with sanctions? Criminal penalties for violating them, derived from
the statutes that created the sanction rules in the first place. Can you sanction someone for their
violation of other sanctions? Yes, that’s called “secondary sanctions.” This is a hot topic vis-à-vis
foreign companies that want to do business with foreign entities (such as certain Iranian entities)
that are themselves the subject of sanctions.
Unilateral sanctions (that is, those imposed only by the United States) can have an impact, but
multilateral sanctions of course can have a greater impact. To get other states to follow suit, the
U.S. government can try diplomatic persuasion. To actually compel other governments to follow
suit? That requires a U.N. Security Council Resolution, which is no easy thing to obtain given the
constellation of competing national interests the Council represents (and the fact that China,
Russia, the UK, France, and the United States all have permanent authority to veto UNSC action).

Consider the utility of sanctions vis-à-vis: Russia, China, Iran, and North Korea
• Are sanctions equally useful in each case? Why or why not?

D. Russia
Read this New York Times account from December 2016, which focuses on Russian election
interference in 2016, and this one on possible responses. Note that in July 2018, a federal grand
jury did issue an indictment (no need to read it, but it is here if you wish to) of various Russian
officers, in an early example of the prosecution tool being put to use (at least nominally; no Russian
officer was or is in actual US custody):

As you read, consider the following questions:
• How did hacking in this context relate to a larger “information operation”? What
lessons does this episode suggest about vulnerability to spear-phishing?
• How do you assess the response of (i) the FBI in particular and (ii) the U.S. government
more generally?
• What insights did you gather regarding the entities that conduct such activities for the
Russian government? How would you characterize what Russia did here? (Crime?
Espionage? Covert action? Some combination, or something else?)
• What would you have done differently had you been president?
• And, finally, is any of this actually beyond the pale, in the sense that you would not
want to see the United States doing the same thing (and do you see how that is a
different question from asking whether the United States should do what it can to stop
such actions from succeeding against it)?

Read this Washington Post story regarding another Russia incident. Again, there was an
indictment (no need to read it, but it is here if you wish to). Do read the latest developments in
that case.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

How do you assess the effectiveness of the U.S. government response in this instance? Can
the same model reliably be applied elsewhere?

Electronic copy available at: https://ssrn.com/abstract=3547103

62

Chesney on Cybersecurity

63

10. What if the Attacker is a Foreign Government? (IV)

Learning objectives
1. Appreciate that the power to impose sanctions that have real bite is not evenly distributed
around the world; the US has loads of it (understand why), the EU has a lot of it, and China
increasingly has a lot of it too.
2. Appreciate that it is one thing to declare a sanction, but another to have the ability to enforce
it such that relevant people/entities will obey.
3. Understand that the US legal framework for sanctions is rooted in this divide: the president
controls foreign relations, yes, but only Congress can pass statutes that give rise to criminal
sanctions or civil liabilities that actually require compliance.
4. Understand what IEEPA is and how it works, including especially how it can be used in a
calibrated, step-by-step way that enables the President to send varied levels of threat signals.
5. Understand that statutes like CAATSA demonstrate that Congress at times still wants to have a
more-direct voice in deciding when and how sanctions should be used.
6. Understand the costs of using the sanctions mechanism, including impacts on your own
economy, risks of retaliation (escalation risk) both within domain and cross domain, risks of
incentivizing restructuring that may leave you with less sanctions leverage (as well as other lost
advantages, such as possible access to an adversary’s supply chain) going forward.
7. Appreciate how this last point relates to the idea of a “great decoupling” between the United
States and China, as both sides increasingly focus not only on supply chain security exposure
(espionage risk) but also on supply-chain sanctions exposure.
8. Appreciate that sanctions work better with more countries involved.
9. Know the options for seeking such cooperation (cooperative persuasion, coercive persuasion,
UN Security Council Resolution), but understand why these options might not work.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

64

10. Understand additional cost-imposition tools available in the foreign-attacker setting, including:
military force, within-domain cyber responses, withholding of benefits (from immigration
benefits to financial aid, etc.), PNG’ing personnel or closing facilities, and more.
11. Always bear in mind that the utility of each of these options (in terms of what they will mean
to the adversary) and the credibility of using them (in terms of how realistic it is for you to
actually employ them, including having the will to do so) will vary greatly over time,
circumstance, and adversary.
12. Be able to identify a broad range of cost-imposition options that were available to the
Obama Administration in 2016, assessing the pros and cons of using each.
13. Understand which options the administration actually used, and why (including why there
were escalation dominance concerns).
14. Be able to explain the difference of view between the United States and China regarding
“commercial espionage” and why this matters.
15. Appreciate that the question of whether to treat commercial espionage as normativelyillegitimate is distinct from the question of whether to defend against it; one defends against
“traditional” espionage vigorously even if one accepts that such activity is legitimate in a
normative sense.
16. Understand which cost-imposition measures the United States imposed in relation to China in
early 2013, in 2014, and then in the run-up to the “Obama-Xi agreement” (pay particular
attention to the calibrated use of IEEPA)
17. Be able to explain why Chinese commercial espionage for a time seemed to decrease, but
only for a time as it turned out.
In this reading, we continue by looking at the specific issue of Chinese-sponsored hacking.
Read this Christian Science Monitor piece examining Chinese-government sponsored hacking
against U.S. targets (public and private) in recent years.

Consider the following questions:
• How does Chinese-government sponsored hacking differ from the Russian activities
descried above, and what follows from this as a matter of policy?
• Should it be off-limits to hack businesses in hopes of providing competitive
advantages for your own nation’s companies (and does it really matter if the
companies in question, on either end, are formally owned in part or in whole by the
state)?
• Should the United States have done more to respond to these hacks?

The Obama administration surprised many observers when it brought criminal charges against a
group of PLA hackers (United States v. Dong (W.D. Pa.). You can skim the indictment here, but
the main thing is to actually read this story and this story about the case.
Analysis of the impact of this effort has been conflicted. Compare this account and this account.

•
•

What lessons if any do you draw from this? Is prosecution an effective approach?
Scalable?
Does news of this recent arrest –possibly linked to the famous OPM hack—change
your view?

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

65

Prosecution is not the only tool available, of course. Read this Executive Order from President
Obama, which in April 2015 established a system for sanctioning the beneficiaries of cyberespionage used for commercial advantage. Read more here and here, too.

What are the pros and cons of this approach?

Eventually, the U.S. and Chinese government struck a deal, of sorts.

Read this recent account, and consider the following questions:
• What was the deal, and has it helped?
• What lessons do you draw?

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

66

C. Encouraging Potential Victims to Defend Better
Minimizing unauthorized (and excessive) access is not just a function of imposing painful
consequences on intruders. It is also a function of making it harder for them to succeed when
they do make an attempt—i.e., it is a function of improving defense, too.
Recall how we distinguished disruption, deterrence, and defense in the readings above.
Improving defense will, at the margins, prevent some intrusions in the direct sense that some
attacks that might otherwise have succeeded will now fail. Moreover, even for attackers who are
able and willing to overcome the improved defense, the improvement increases the attacker’s
costs, thereby making the effort marginally less attractive (by reducing prospective return on
investment) and perhaps even causing the attacker to reduce the scope of their activities due to
resulting resource constraints. Sometimes this is called “deterrence by denial.” Incentivizing
potential victims (whether they are private or public entities or individuals) to improve their
defenses on a systemic basis thus can serve important goals of cybersecurity policy.
Of course, most potential victims already have at least some incentive to develop and improve
defenses, even absent any form of external intervention to encourage them further. Some have
trade secrets to protect. Most desire to keep at least some things private. Some need to keep
customers happy. And so forth. As a result, we can safely assume there will be some defensive
activity even if no external forces intervene to encourage such steps. It’s rather like the situation
of a building owner. Most building owners would take at least some steps to make the building
safe even if there were no building codes, insurers, or plaintiff’s lawyers with which to contend.
We might call this the “natural level” of investment in defense.
Is the natural level good enough? In the building-safety context, society has answered that
question with a resounding no. Governments, insurers, and litigators intervene in all sorts of ways
to spur further safety measures in that setting. And the same is true with respect to various other
contexts, such as pollution and public health. In these and other settings, we see extensive
interventions in the name of promoting safety or well-being (whether all such interventions are
genuinely motivated by such noble goals, and whether they are warranted in light of offsetting
costs, are entirely different questions, of course).
So too with cybersecurity policy. Just like the building-safety context, there are an array of
additional incentives that have been (or could be) brought to bear to incentivize greater
investment in safeguards in the cybersecurity context. Indeed, many of the levers are the same.
In both settings we find regulators who might dictate rules and standards, litigants who might sue,
insurers who might set and enforce coverage conditions, and contract counterparties who might
insist on certain actions as a condition of the deal.
These external incentive structures are not the only levers promoting improved defense on a
systematic basis, however. Another involves efforts to promote sharing of information that might
assist the cause of improved defense. And another tool is “pruning”—that is, legislation that
repeals or carves out exceptions to existing laws that may be useful for other purposes, but that
has the collateral impact of discouraging desirable defensive measures.
In the pages that follow in this subsection, we will survey each of these levers before concluding
with a look at how the U.S. government organizes to promote better defense of (1) its own systems
and (2) the systems associated with “critical infrastructure” owned by the private sector.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

67

11. The Role of Regulators (I)

Learning Objectives
•
•
•
•
•
•
•
•
•
•
•

Understand the role that “externalities” analysis plays in the decision not to leave privatesector cybersecurity decisions entirely to the market (be able to state the analogy to
situations such as building safety, health codes, and car safety).
Be able to describe the array of strategies (tools) governments might try to use if and when
they want to alter the incentive structures relating to investment in safety measures.
Understand the role that regulatory agencies might play.
Understand the two core prohibitions in Section 5 of the FTC Act, and how each of them
might separately be the basis for an enforcement action relating to poor cybersecurity
Be able to explain why it is easier to explain the FTC’s role in this area when it acts under its
“deception” authority than under its “unfair competition” authority, but be able to make the
latter case.
Be able to explain how it is that the FTC can be said to have produced cybersecurity-related
rules even without issuing cybersecurity-specific regulations (hint: think of the cumulative
impact of their enforcement actions).
Form an opinion on the propriety of treating poor cybersecurity as an instance of unfair
competition.
Be able to explain why Section 5(n) applies only to the “unfair” prong and how it functions
almost like a definition of “unfair.”
Be able to list the conditions specified in Section 5(n).
Form a view on whether the meaning of “unfair” should vary depending on the resources
and sophistication of the actor in question.
Understand (from the Wyndham and LabMD cases) whether the courts agree that the FTC
can develop the specific meaning of unfairness in this setting via enforcement actions
instead of via rule-making.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity
•
•
•
•

68

Appreciate that the Wyndham decision was the first to affirm that the unfairness prong could
be used as the basis to proceed against a company for poor cybersecurity practices without
having to show an element of deception.
Understand that Wyndham was an easy case given the egregiousness of its omissions.
Appreciate that when the FTC brings an enforcement action within itself, the outcome it can
achieve is limited to directives to do/not do certain things (that is, to injunctive-style relief)
rather than money damages.
Understand that many enforcement actions end in a settlement (called a Consent Decree),
and that the FTC can sue in federal court later if it believes the defendant is violating the
terms.

In theory, one way to promote better defense on a systematic basis is to create legally-binding
rules or standards that oblige potential victims to take certain steps towards that end. Who might
do that? In the first instance, of course, we should look to legislatures (both state and federal). In
our separation-of-powers system, after all, that is the part of government meant to make laws.
That said, anyone with even glancing familiarity with federal and state government over the past
century will understand that a vast amount of rulemaking—for better or worse—stems not directly
from legislation but rather from regulations promulgated by “administrative agencies.”
A. About Federal Administrative Agencies
The federal government contains a large number of administrative agencies. Each has some
particular field of subject-matter responsibility (the scope of which is defined by statute in most
cases). Each typically performs many functions, but we are especially concerned with two core
capacities.
First, rulemaking. An agency might have authority to promulgate legally-binding regulations (that
is, to engage in “rulemaking”) in furtherance of some goal specified by Congress. For example,
Congress has given the Environmental Protection Agency authority to promulgate regulations to
further the goals of the Clean Air Act in certain ways. There are a host of complex procedural
rules associated with agency rulemaking, but for now it is enough to know that this has been a
common mode of creating law since the 20th century.
Second, enforcement. Congress sometimes authorizes an agency to initiate and pursue
“enforcement” proceedings. The idea is that the agency may be tasked with investigating
possible rule violations (whether a rule stated directly in a statute enacted by Congress, or a rule
promulgated by an agency pursuant to authority delegated by Congress) and then initiating civil
proceedings to enforce alleged violations. In some cases, the enforcement action might take
the form of an ordinary civil suit, with the agency suing the alleged violator in federal court. But
sometimes Congress empowers the agency also or instead to adjudicate the enforcement
process internally (at least as an initial matter), with a litigation process involving an administrative
law judge within the agency itself. Either way, the general idea is to secure a determination that
someone violated a rule, producing a costly fine/damages, an order obliging (enjoining) the
violator to take or cease some particular action(s), or both.
Like other forms of litigation, agency enforcement proceedings routinely result in settlements in
which the alleged violator agrees to take or cease certain actions, with the possibility of more
severe consequences later on if the party breaches that obligation.
Note that other parties in an industry may take note of the initiation and resolution of enforcement
actions. Enforcement actions thus can cast a shadow—sometimes a very long shadow—
impacting how other players decide to act.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

69

Bearing that in mind, can you make an argument that “enforcement” authority is itself a
second form of rule-making authority?

B. There Is Not (Yet) An “EPA” For Cybersecurity
I mentioned the EPA above. It was created during the Nixon Administration at a time of mounting
concern about the harmful effects of pollution. Over time, Congress has granted various
rulemaking and enforcement authorities to the EPA in furtherance of this general mission. One
might argue that mounting concern about inadequate cybersecurity warrants creation of a
similar dedicated agency. It is important to grasp, however, that Congress so far has not taken
that step. As we will see later in this unit, there is an important agency within the Department of
Homeland Security known now (though not originally) as the Cybersecurity and Infrastructure
Security Agency (CISA), but its role does not (yet) include rulemaking and enforcement authority
encompassing the private sector.
All that said: just as nature abhors a physical vacuum, so too government bureaucracies seem to
abhor perceived regulatory vacuums. There are existing administrative agencies with broad
jurisdiction that have, in various ways, taken up at least some aspects of the cybersecurity
regulatory challenge—sometimes because Congress has directed them expressly to do so, and
sometimes because they have noted that their existing jurisdiction arguably encompasses certain
aspects of cybersecurity and they have acted accordingly.
Your goal in light of all that: understand how certain pre-existing agencies have managed to
participate in cybersecurity promotion. We’ll start with the one you hear about the most in this
space: the FTC.
C. The Federal Trade Commission (“FTC”) and The FTC Act
For a very brief introduction to the FTC, read this.

Based only on this overview, would you expect the FTC to have a role in setting or enforcing
standards for cybersecurity? Why or why not?

One of the statutes the FTC is empowered to enforce is the Federal Trade Commission Act (“FTC
Act”). The FTC has not engaged in any rulemaking relating to cybersecurity under this statute.
Instead, it has focused on enforcement actions, based on the claim that some situations involving
poor cybersecurity violated a rule set forth in the FTC Act itself. In fact, it has initiated more than
60 enforcement actions along these lines, and has touted the resulting body of cases as
functioning, collectively, as a form of guidance to the private sector. In a moment I’ll ask you to
consider whether this level of enforcement, without tailored rulemaking, is desirable. But first you
need to know just what they’ve been enforcing and how they’ve been doing it.
Goal #1: Understand what exactly the FTC Act prohibits. The answer is found in 15 U.S.C. 45(a)(1).
(1)

Unfair methods of competition in or affecting commerce, and unfair or deceptive
acts or practices in or affecting commerce, are hereby declared unlawful.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

70

There’s an opening clause about unfair competition, and a second clause that refers alternatively
both to “unfair” practices and “deceptive” practices that impact interstate commerce.

Consider the following questions:
• Can you explain how unfairness is different from deception?
• Does either concept seem relevant to a situation in which some entity has poor
cybersecurity?
• In terms of clarity (and thus understanding on the part of those who must comply),
how does this compare to the various subparts of the CFAA?

Goal #2: Understand how 15 U.S.C. 45(n) limits one (but not both) of those two prohibitions.
(n)

Standard of proof; public policy considerations
The Commission shall have no authority under this section or section 57a of this title
to declare unlawful an act or practice on the grounds that such act or practice is
unfair unless the act or practice causes or is likely to cause substantial injury to
consumers which is not reasonably avoidable by consumers themselves and not
outweighed by countervailing benefits to consumers or to competition. In
determining whether an act or practice is unfair, the Commission may consider
established public policies as evidence to be considered with all other evidence.
Such public policy considerations may not serve as a primary basis for such
determination.

Notice that this applies only where the enforcement action by the FTC takes place under
the “unfair” prong. Can you see how this section functions almost like a definition of “unfair,”
and if so can you summarize the various elements of the definition in the form of a list?

Goal #3: Understand whether there are significant limits with respect to who has to care about
the FTC Act. Read 15 U.S.C. 45(a)(2).
(2)

The Commission is hereby empowered and directed to prevent persons,
partnerships, or corporations, except banks, savings and loan institutions described
in section 57a(f)(3) of this title, Federal credit unions described in section 57a(f)(4)
of this title, common carriers subject to the Acts to regulate commerce, air carriers
and foreign air carriers subject to part A of subtitle VII of title 49, and persons,
partnerships, or corporations insofar as they are subject to the Packers and
Stockyards Act, 1921, as amended [7 U.S.C. 181 et seq.], except as provided in
section 406(b) of said Act [7 U.S.C. 227(b)], from using unfair methods of
competition in or affecting commerce and unfair or deceptive acts or practices in
or affecting commerce.

Does subsection 45(a)(2) encompass everyone?

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

71

Goal #4: Understand how the FTC goes about enforcing the FTC Act. It has two available options.
Read 45(b) and 45(m).
(b)

Proceeding by Commission; modifying and setting aside orders
Whenever the Commission shall have reason to believe that any such person,
partnership, or corporation has been or is using any unfair method of competition
or unfair or deceptive act or practice in or affecting commerce, and if it shall
appear to the Commission that a proceeding by it in respect thereof would be to
the interest of the public, it shall issue and serve upon such person, partnership, or
corporation a complaint stating its charges in that respect and containing a notice
of a hearing upon a day and at a place therein fixed at least thirty days after the
service of said complaint. The person, partnership, or corporation so complained
of shall have the right to appear at the place and time so fixed and show cause
why an order should not be entered by the Commission requiring such person,
partnership, or corporation to cease and desist from the violation of the law so
charged in said complaint. Any person, partnership, or corporation may make
application, and upon good cause shown may be allowed by the Commission to
intervene and appear in said proceeding by counsel or in person. The testimony in
any such proceeding shall be reduced to writing and filed in the office of the
Commission. If upon such hearing the Commission shall be of the opinion that the
method of competition or the act or practice in question is prohibited by this
subchapter, it shall make a report in writing in which it shall state its findings as to
the facts and shall issue and cause to be served on such person, partnership, or
corporation an order requiring such person, partnership, or corporation to cease
and desist from using such method of competition or such act or practice. Until the
expiration of the time allowed for filing a petition for review, if no such petition has
been duly filed within such time, or, if a petition for review has been filed within such
time then until the record in the proceeding has been filed in a court of appeals of
the United States, as hereinafter provided, the Commission may at any time, upon
such notice and in such manner as it shall deem proper, modify or set aside, in
whole or in part, any report or any order made or issued by it under this section.
After the expiration of the time allowed for filing a petition for review, if no such
petition has been duly filed within such time, the Commission may at any time, after
notice and opportunity for hearing, reopen and alter, modify, or set aside, in whole
or in part any report or order made or issued by it under this section, whenever in
the opinion of the Commission conditions of fact or of law have so changed as to
require such action or if the public interest shall so require, except that (1) the said
person, partnership, or corporation may, within sixty days after service upon him or
it of said report or order entered after such a reopening, obtain a review thereof in
the appropriate court of appeals of the United States, in the manner provided in
subsection (c) of this section; and (2) in the case of an order, the Commission shall
reopen any such order to consider whether such order (including any affirmative
relief provision contained in such order) should be altered, modified, or set aside,
in whole or in part, if the person, partnership, or corporation involved files a request
with the Commission which makes a satisfactory showing that changed conditions
of law or fact require such order to be altered, modified, or set aside, in whole or
in part. The Commission shall determine whether to alter, modify, or set aside any
order of the Commission in response to a request made by a person, partnership,
or corporation under paragraph [1] (2) not later than 120 days after the date of the
filing of such request.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity
(m)

72

Civil actions for recovery of penalties for knowing violations of rules and cease and
desist orders respecting unfair or deceptive acts or practices; jurisdiction;
maximum amount of penalties; continuing violations; de novo determinations;
compromise or settlement procedure
(1)
(A) The Commission may commence a civil action to recover a civil
penalty in a district court of the United States against any person,
partnership, or corporation which violates any rule under this
subchapter respecting unfair or deceptive acts or practices (other
than an interpretive rule or a rule violation of which the Commission
has provided is not an unfair or deceptive act or practice in
violation of subsection (a)(1)) with actual knowledge or knowledge
fairly implied on the basis of objective circumstances that such act
is unfair or deceptive and is prohibited by such rule. In such action,
such person, partnership, or corporation shall be liable for a civil
penalty of not more than $10,000 for each violation.
(B) If the Commission determines in a proceeding under subsection
(b) that any act or practice is unfair or deceptive, and issues a final
cease and desist order, other than a consent order, with respect to
such act or practice, then the Commission may commence a civil
action to obtain a civil penalty in a district court of the United States
against any person, partnership, or corporation which engages in
such act or practice—
(1) after such cease and desist order becomes final
(whether or not such person, partnership, or corporation was
subject to such cease and desist order), and
(2) with actual knowledge that such act or practice is unfair
or deceptive and is unlawful under subsection (a)(1) of this
section.
In such action, such person, partnership, or corporation shall be
liable for a civil penalty of not more than $10,000 for each violation.
(C) In the case of a violation through continuing failure to comply
with a rule or with subsection (a)(1), each day of continuance of
such failure shall be treated as a separate violation, for purposes of
subparagraphs (A) and (B). In determining the amount of such a
civil penalty, the court shall take into account the degree of
culpability, any history of prior such conduct, ability to pay, effect
on ability to continue to do business, and such other matters as
justice may require.
(2) If the cease and desist order establishing that the act or practice is unfair or
deceptive was not issued against the defendant in a civil penalty action under
paragraph (1)(B) the issues of fact in such action against such defendant shall be
tried de novo. Upon request of any party to such an action against such
defendant, the court shall also review the determination of law made by the
Commission in the proceeding under subsection (b) that the act or practice which

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

73

was the subject of such proceeding constituted an unfair or deceptive act or
practice in violation of subsection (a).
(3) The Commission may compromise or settle any action for a civil penalty if such
compromise or settlement is accompanied by a public statement of its reasons
and is approved by the court.

Can you explain the difference between the two procedures in terms of who decides whether
the FTC’s allegation is correct? In terms of what remedies appear to be available if the FTC
wins?

D. Case Study #1: Uber
Read this complaint filed by the FTC.

Consider the following questions:
• Which enforcement path did the FTC use in this case?
• In what way(s) did Uber allegedly violate Section 45(a)?
• Assuming all the allegations to be true, would you agree with the FTC that this violates
the statute?

Eventually Uber settled with the FTC, but then in April 2018, the FTC announced it had reopened
the case due to Uber’s failure to disclose that, during the pendency of the case at the earlier
stage, Uber had experienced another data breach. This led to a revised settlement agreement.

Scan the document to get a sense of the commitments FTC extracted from Uber.
• What are those commitments, and was this a good outcome?

The FTC was not the only problem Uber faced in connection with these events. A number of state
Attorneys General decided to team up and sue Uber together, based on various state databreach liability laws we will examine in the next class. For now, it is enough to note that Uber faced
this massive and well-resourced lawsuit at the same time that it faced the FTC’s renewed
enforcement action.

Consider how the pendency of parallel litigation might matter. Oh, by the way, Uber and the
states have just announced (9/26/18) that they are settling for $148 million.

E. Case Study #2: Wyndham Hotels
Here’s an example of the FTC suing in federal court. Read this note summarizing the litigation
involving Wyndham Hotels.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

74

Consider the following questions:
• What was Wyndham’s argument about the propriety of suing them under the
“unfairness” prong of Section 45(a)(1)?
o How did the court rule on that point, and do you agree?
• What was Wyndham’s second argument, concerning “fair notice”?
o How did the court rule on that one, and do you agree?

Note: Wyndham and the FTC settled later, with Wyndham agreeing to take on a variety of
security-focused practices (as well as annual audits) for the next 20 years.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

75

12. The Role of Regulators (II)
Learning objectives
•

•
•
•
•
•
•
•
•
•
•
•

Understand that the Eleventh Circuit in LabMD did not object to the common-law
enforcement methods of the FTC, but did object to the FTC’s attempt to impose remedies
that were not very specific in the obligations they entailed.
Understand that the same agency (the FTC) enforces both the FTC Act (Section 5) and the
GLB Act (Safeguards Rule)
Be able to describe the category of entities subject to the GLB Act
Be able to describe what the Safeguards Rule actually requires (written information security
policy, actual risk assessments, and adequate safeguard)
Understand the arguments for and against having such indeterminate standards
Be prepared to defend your view on whether the FTC’s Safeguards Rule enforcement action
against TaxSlayer was fair
Know what a credential-stuffing attack is, why these often work, and some steps to defend
against them
Understand that other federal regulators (SEC, FCC, FDA, etc.) frequently have authorities
similar to the GLB Act, to be enforced against particular sectors
Appreciate that both U.S. states and foreign governments also have various regulatory
agencies who may have jurisdiction in a given case
Be able to explain the pros and cons of having multiple relevant regulators with overlapping
jurisdiction
Give thought to the optimal way to act via such agencies if you believe more pressure
should be placed on companies to invest more/smarter in defense
Understand California’s new “security of connected devices” law as a direct regulation of
IOT manufacturers who sell their products in California, and be able to explain what exactly it
requires/forbids

A. Case Study #3: LabMD
This was a remarkable case in many respects. I won’t summarize it here, but rather will ask you to
read this short overview from Prof. Dan Solove.

•

Can you summarize how the outcome in LabMD compares to Wyndham?

B. The FTC and the Gramm-Leach-Bliley Act
As it happens, the FTC also has authority to enforce other statutes, and in some cases to
promulgate regulations relating to them. One such statute is the Gramm-Leach-Bliley Act (the
“GLB Act”), which, among other things, concerns the protection of customer data by financial
institutions.
The FTC has promulgated a set of regulations on that issue, known collectively as the “Safeguards
Rule” (found in 16 Code of Federal Regulations Part 314). Here is an overview of the rule written
by the FTC (if you want to see the actual text of the Rule, it is here):
Many companies collect personal information from their customers, including names, addresses,
and phone numbers; bank and credit card account numbers; income and credit histories; and
Social Security numbers. The Gramm-Leach-Bliley (GLB) Act requires companies defined under

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

76

the law as “financial institutions” to ensure the security and confidentiality of this type of
information. As part of its implementation of the GLB Act, the Federal Trade Commission (FTC)
issued the Safeguards Rule, which requires financial institutions under FTC jurisdiction to have
measures in place to keep customer information secure. …
The definition of “financial institution” includes many businesses that may not normally describe
themselves that way. In fact, the Rule applies to all businesses, regardless of size, that are
“significantly engaged” in providing financial products or services. This includes, for example,
check-cashing businesses, payday lenders, mortgage brokers, nonbank lenders, personal
property or real estate appraisers, professional tax preparers, and courier services. The
Safeguards Rule also applies to companies like credit reporting agencies and ATM operators that
receive information about the customers of other financial institutions. …
The Safeguards Rule requires companies to develop a written information security plan that
describes their program to protect customer information. The plan must be appropriate to the
company’s size and complexity, the nature and scope of its activities, and the sensitivity of the
customer information it handles. As part of its plan, each company must:
•

designate one or more employees to coordinate its information security program;

•

identify and assess the risks to customer information in each relevant area of the company’s
operation, and evaluate the effectiveness of the current safeguards for controlling these risks;

•

design and implement a safeguards program, and regularly monitor and test it;

•

select service providers that can maintain appropriate safeguards, make sure your contract
requires them to maintain safeguards, and oversee their handling of customer information;
and

•

evaluate and adjust the program in light of relevant circumstances, including changes in the
firm’s business or operations, or the results of security testing and monitoring.

The requirements are designed to be flexible. Companies should implement safeguards
appropriate to their own circumstances. …
The Safeguards Rule requires companies to assess and address the risks to customer
information in all areas of their operation, including three areas that are particularly important to
information security: Employee Management and Training; Information Systems; and Detecting
and Managing System Failures. One of the early steps companies should take is to determine
what information they are collecting and storing, and whether they have a business need to do
so. You can reduce the risks to customer information if you know what you have and keep only
what you need.
Depending on the nature of their business operations, firms should consider implementing the
following practices:
…
•

Limiting access to customer information to employees who have a business reason to see it.
For example, give employees who respond to customer inquiries access to customer files,
but only to the extent they need it to do their jobs.

•

Controlling access to sensitive information by requiring employees to use “strong” passwords
that must be changed on a regular basis. (Tough-to-crack passwords require the use of at
least six characters, upper- and lower-case letters, and a combination of letters, numbers,
and symbols.)

•

Using password-activated screen savers to lock employee computers after a period of
inactivity.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

77

•

Developing policies for appropriate use and protection of laptops, PDAs, cell phones, or other
mobile devices. For example, make sure employees store these devices in a secure place
when not in use. Also, consider that customer information in encrypted files will be better
protected in case of theft of such a device.

•

Training employees to take basic steps to maintain the security, confidentiality, and integrity
of customer information, including:

o

Locking rooms and file cabinets where records are kept;

o

Not sharing or openly posting employee passwords in work areas;

o

Encrypting sensitive customer information when it is transmitted electronically via public
networks;

o

Referring calls or other requests for customer information to designated individuals who have
been trained in how your company safeguards personal data; and

o

Reporting suspicious attempts to obtain customer information to designated personnel.

•

Regularly reminding all employees of your company’s policy — and the legal requirement —
to keep customer information secure and confidential. For example, consider posting
reminders about their responsibility for security in areas where customer information is
stored, like file rooms.

•

Developing policies for employees who telecommute. For example, consider whether or how
employees should be allowed to keep or access customer data at home. Also, require
employees who use personal computers to store or access customer data to use protections
against viruses, spyware, and other unauthorized intrusions.

•

Imposing disciplinary measures for security policy violations.

•

Preventing terminated employees from accessing customer information by immediately
deactivating their passwords and user names and taking other appropriate measures.
Information Systems. Information systems include network and software design, and
information processing, storage, transmission, retrieval, and disposal. Here are some
suggestions on maintaining security throughout the life cycle of customer information, from
data entry to data disposal:

•

Know where sensitive customer information is stored and store it securely. Make sure only
authorized employees have access. For example:

•

o

Ensure that storage areas are protected against destruction or damage from physical
hazards, like fire or floods.

o

Store records in a room or cabinet that is locked when unattended.

o

When customer information is stored on a server or other computer, ensure that the
computer is accessible only with a “strong” password and is kept in a physicallysecure area.

o

Where possible, avoid storing sensitive customer data on a computer with an Internet
connection.

o

Maintain secure backup records and keep archived data secure by storing it off-line
and in a physically-secure area.

o

Maintain a careful inventory of your company’s computers and any other equipment
on which customer information may be stored.

Take steps to ensure the secure transmission of customer information. For example:
o

When you transmit credit card information or other sensitive financial data, use a
Secure Sockets Layer (SSL) or other secure connection, so that the information is
protected in transit.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

•

78

o

If you collect information online directly from customers, make secure transmission
automatic. Caution customers against transmitting sensitive data, like account
numbers, via email or in response to an unsolicited email or pop-up message.

o

If you must transmit sensitive data by email over the Internet, be sure to encrypt the
data.

Dispose of customer information in a secure way and, where applicable, consistent with the
FTC’s Disposal Rule. For example:
o

Consider designating or hiring a records retention manager to supervise the disposal
of records containing customer information. If you hire an outside disposal company,
conduct due diligence beforehand by checking references or requiring that the
company be certified by a recognized industry group.

o

Burn, pulverize, or shred papers containing customer information so that the
information cannot be read or reconstructed.

o

Destroy or erase data when disposing of computers, disks, CDs, magnetic tapes,
hard drives, laptops, PDAs, cell phones, or any other electronic media or hardware
containing customer information.
Detecting and Managing System Failures. Effective security management requires
your company to deter, detect, and defend against security breaches. That means
taking reasonable steps to prevent attacks, quickly diagnosing a security incident,
and having a plan in place for responding effectively. Consider implementing the
following procedures:

•

Monitoring the websites of your software vendors and reading relevant industry publications
for news about emerging threats and available defenses.

•

Maintaining up-to-date and appropriate programs and controls to prevent unauthorized
access to customer information. Be sure to:

•

•

o

check with software vendors regularly to get and install patches that resolve software
vulnerabilities;

o

use anti-virus and anti-spyware software that updates automatically;

o

maintain up-to-date firewalls, particularly if you use a broadband Internet connection
or allow employees to connect to your network from home or other off-site locations;

o

regularly ensure that ports not used for your business are closed; and

o

promptly pass along information and instructions to employees regarding any new
security risks or possible breaches.

Using appropriate oversight or audit procedures to detect the improper disclosure or theft of
customer information. It’s wise to:
o

keep logs of activity on your network and monitor them for signs of unauthorized
access to customer information;

o

use an up-to-date intrusion detection system to alert you of attacks;

o

monitor both in- and out-bound transfers of information for indications of a
compromise, such as unexpectedly large amounts of data being transmitted from
your system to an unknown user; and

o

insert a dummy account into each of your customer lists and monitor the account to
detect any unauthorized contacts or charges.

Taking steps to preserve the security, confidentiality, and integrity of customer information in
the event of a breach. If a breach occurs:

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

•

79

o

take immediate action to secure any information that has or may have been
compromised. For example, if a computer connected to the Internet is compromised,
disconnect the computer from the Internet;

o

preserve and review files or programs that may reveal how the breach occurred; and

o

if feasible and appropriate, bring in security professionals to help assess the breach
as soon as possible.

Considering notifying consumers, law enforcement, and/or businesses in the event of a
security breach. For example:
o

notify consumers if their personal information is subject to a breach that poses a
significant risk of identity theft or related harm;

o

notify law enforcement if the breach may involve criminal activity or there is evidence
that the breach has resulted in identity theft or related harm;

o

notify the credit bureaus and other businesses that may be affected by the breach.
…; and

o

check to see if breach notification is required under applicable state law.

Who does this govern, and (at a general level) what does it require them to do?

C. Case study: In the Matter of Taxslayer
For a recent illustration of the Safeguards Rule in action, read pp.3-5 of this action the FTC filed
against TaxSlayer:
The Federal Trade Commission, having reason to believe that TaxSlayer, LLC, a limited
liability company, (“TaxSlayer” or “Respondent”), has violated the provisions of the Federal
Trade Commission Act, 15 U.S.C. § 45(a); the Privacy of Consumer Financial Information Rule
(“Privacy Rule”), 16 C.F.R. Part 313, recodified at 12 C.F.R. § 1016 (“Reg. P”), and issued
pursuant to Sections 501-504 of the Gramm-Leach-Bliley Act (“GLB Act”), 15 U.S.C. §§ 68016803; and the Standards for Safeguarding Customer Information Rule (“Safeguards Rule”), 16
C.F.R. Part 314, issued pursuant to Sections 501(b) and 505(b)(2) of the GLB Act, 15 U.S.C. §§
6801(b), 6805(b)(2); and it appearing to the Commission that this proceeding is in the public
interest, alleges:
1. Respondent is a Georgia limited liability corporation with its principal office at 3003
TaxSlayer Drive, Evans, Georgia 30809.
2. The acts and practices of Respondent alleged in this complaint have been in or affecting
commerce, as “commerce” is defined in Section 4 of the Federal Trade Commission Act.
RESPONDENT’S BUSINESS PRACTICES
3. Respondent advertises, offers for sale, sells, and distributes products and services to
consumers, including TaxSlayer Online, a tax return preparation and electronic filing
software and service.
4. Respondent is a business that began more than 50 years ago as a tax return preparation
firm. It developed tax return preparation software for its internal use in the 1980s. In the
1990s, it developed a browser-based software service that it advertises, offers for sale,
sells, and distributes to assist consumers in preparing and electronically filing federal and

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity
state income tax returns. Over the years, Respondent added other tax return preparation
products, including a mobile app. This Complaint refers to the browser-based software
service and mobile app as “TaxSlayer Online.”
5. In 2016, more than 950,000 individuals filed tax returns with TaxSlayer Online.
6. Respondent typically charges consumers fees for the use of TaxSlayer Online.
7. TaxSlayer Online users create an account by entering a username and password (“login
credentials”) on an account creation page.
8. They then input a host of personal information in order to create a tax return, including
but not limited to: name, Social Security number (“SSN”), telephone number, physical
address, income, employment status, marital status, identity of dependents, financial
assets, financial activities, receipt of government benefits, home ownership, indebtedness,
health insurance, retirement information, charitable donations, tax payments, tax refunds,
bank account numbers, and payment card numbers. Respondent also collects IP
addresses and persistent identifiers associated with the particular device from which the
tax return is prepared and/or filed.
9. TaxSlayer Online uses this personal information to prepare tax returns on behalf of
customers. Once a tax return is prepared, a customer can file the return electronically
through TaxSlayer Online with the Internal Revenue Service (“IRS”) and state
departments of revenue. If a customer is entitled to a refund, Respondent offers the
option of transferring the refund directly into a customer’s bank account. Customers may
also elect to receive their tax refunds on a prepaid debit card.
RESPONDENT’S GRAMM-LEACH-BLILEY ACT (“GLB ACT”) VIOLATIONS
10. Respondent is a financial institution subject to the GLB Act, as that term is defined by
Section 509(3)(A) of the GLB Act, 15 U.S.C. § 6809(3)(A), because among other things,
Respondent provides tax planning and tax preparation services, 16 C.F.R.
§ 313.3(k)(2)(viii); 12 C.F.R. § 1016.3(l)(3)(ii)(H); 12 C.F.R. § 225.28(b)(6)(vi) (“Reg.
Y”), and data processing, 12 C.F.R. § 225.28(b)(14). Respondent collects nonpublic
personal information, as defined by 16 C.F.R. § 313.3(n) and 12 C.F.R. § 1016.3(p)(1)(3). Because Respondent is a financial institution that collects nonpublic personal
information, it is subject to the requirements of the GLB Privacy Rule, 16 C.F.R. Part
313, Reg. P., 12 C.F.R. Part 1016, and the Safeguards Rule, 16 C.F.R. Part 314.
…
Safeguards Rule
14. The Safeguards Rule, which implements Section 501(b) of the GLB Act,
15 U.S.C. § 6801(b), was promulgated by the Commission on May 23, 2002, and became
effective on May 23, 2003. The Rule requires financial institutions to protect the
security, confidentiality, and integrity of customer information by developing,
implementing, and maintaining a comprehensive information security program that is
written in one or more readily accessible parts, and that contains administrative,
technical, and physical safeguards that are appropriate to the financial institution’s size
and complexity, the nature and scope of its activities, and the sensitivity of the customer
information at issue, including:

Electronic copy available at: https://ssrn.com/abstract=3547103

80

Chesney on Cybersecurity

a. Designating one or more employees to coordinate the information security program;
b. Identifying reasonably foreseeable internal and external risks to the security,
confidentiality, and integrity of customer information, and assessing the sufficiency
of any safeguards in place to control those risks;
c. Designing and implementing information safeguards to control the risks identified
through risk assessment, and regularly testing or otherwise monitoring the
effectiveness of the safeguards’ key controls, systems, and procedures;
d. Overseeing service providers, and requiring them by contract to protect the security
and confidentiality of customer information; and
e. Evaluating and adjusting the information security program in light of the results of
testing and monitoring, changes to the business operation, and other relevant
circumstances.
15. Respondent violated the Safeguards Rule. For example:
a. Respondent failed to have a written information security program until November
2015.
b. Respondent failed to conduct a risk assessment, which would have identified
reasonably foreseeable internal and external risks to the security, confidentiality, and
integrity of customer information, including risks associated with inadequate
authentication.
c. Respondent failed to implement information safeguards to control the risks to
customer information from inadequate authentication. For example:
i. Respondent did not require consumers to choose strong passwords when setting
up their accounts, which is a standard practice for accounts containing sensitive
personal information. Respondent’s only requirement for passwords was that
they be eight to sixteen characters in length. This created a risk that attackers
could guess commonly-used passwords, or use dictionary attacks, to access
TaxSlayer Online accounts.
ii. Respondent failed to implement adequate risk-based authentication measures
sufficient to mitigate the risk of list validation attacks when such attacks became
reasonably foreseeable. List validation attacks occur when remote attackers use
lists of stolen login credentials to attempt to access accounts across a number of
popular Internet sites, knowing that consumers often reuse user name and
passwords combinations.
iii. Respondent failed to inform TaxSlayer Online users when a material change was
made to the mailing address, password, or security question associated with their
accounts. Respondent also failed to inform TaxSlayer Online users when a
material change is made to the bank account routing number or the payment
method for a refund (e.g., from bank account to a pre-paid debit card) associated
with their accounts.
iv. Respondent failed to require customers to validate their email addresses at
account creation, in order to verify accuracy and communicate with customers
regarding security-related issues.
v. Respondent failed to use readily-available tools to prevent devices or IP addresses

Electronic copy available at: https://ssrn.com/abstract=3547103

81

Chesney on Cybersecurity

82

from attempting to access an unlimited number of TaxSlayer Online accounts in
rapid succession through a list validation attack.
16. Respondent became subject to a list validation attack that began on October 10, 2015, and
ended on December 21, 2015. On that day, Respondent implemented multi-factor
authentication, requiring users to first submit their username and password, and then to
authenticate their device by, for example, entering a code that Respondent sent to the
user’s email or mobile phone.
17. As part of this list validation attack, the remote attackers were able to gain full access to
8,882 existing TaxSlayer Online accounts. In an unknown number of instances, the
attackers engaged in tax identity theft by altering the bank routing and refund methods, efiling
fraudulent tax returns, and diverting the fabricated tax refunds to themselves.
Customers were not notified when these alterations occurred. Respondent was not aware
of this list validation attack until a TaxSlayer Online user called on January 11, 2016 to
report suspicious activity on her account.
18. Consumers who are the victims of tax identity theft spend significant time resolving this
problem. Victims spend time calling the IRS and state tax authorities to report the tax
identity theft. Victims then have to obtain PIN numbers from the IRS and file their taxes
on paper using those PIN numbers. They then have to wait months to receive their tax
refunds. To protect themselves and their dependents from future identity theft, victims
freeze or place holds on their credit, and they spend additional time monitoring their
credit histories and financial accounts. These victims also suffer out-of-pocket financial
losses….

D. A Quick Look at Other Federal Regulators
There are other federal regulators involved in cybersecurity, besides the FTC. We will not go into
anything like the same level of detail with them, but you should have at least a glancing familiarity
with the idea that just about every regulator, these days, takes an interest in the cybersecurity
practices of the entities within its reach. Consider, for example, the Securities & Exchange
Commission (“SEC”):
SEC: Morgan Stanley Failed to Safeguard Customer Data
FOR IMMEDIATE RELEASE
2016-112
Washington D.C., June 8, 2016 —
The Securities and Exchange Commission today announced that Morgan Stanley Smith Barney
LLC has agreed to pay a $1 million penalty to settle charges related to its failures to protect
customer information, some of which was hacked and offered for sale online.
The SEC issued an order finding that Morgan Stanley failed to adopt written policies and
procedures reasonably designed to protect customer data. As a result of these failures, from 2011
to 2014, a then-employee impermissibly accessed and transferred the data regarding
approximately 730,000 accounts to his personal server, which was ultimately hacked by third
parties.
“Given the dangers and impact of cyber breaches, data security is a critically important aspect
of investor protection. We expect SEC registrants of all sizes to have policies and procedures that

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

83

are reasonably designed to protect customer information,” said Andrew Ceresney, Director of the
SEC Enforcement Division.
According to the SEC’s order instituting a settled administrative proceeding:
The federal securities laws require registered broker-dealers and investment advisers to adopt
written policies and procedures reasonably designed to protect customer records and
information.
Morgan Stanley’s policies and procedures were not reasonable, however, for two internal web
applications or “portals” that allowed its employees to access customers’ confidential account
information.
For these portals, Morgan Stanley did not have effective authorization modules for more than 10
years to restrict employees’ access to customer data based on each employee’s legitimate
business need.
Morgan Stanley also did not audit or test the relevant authorization modules, nor did it monitor or
analyze employees’ access to and use of the portals.
Consequently, then-employee Galen J. Marsh downloaded and transferred confidential data to
his personal server at home between 2011 and 2014.
A likely third-party hack of Marsh’s personal server resulted in portions of the confidential data
being posted on the Internet with offers to sell larger quantities.
The SEC’s order finds that Morgan Stanley violated Rule 30(a) of Regulation S-P, also known as the
“Safeguards Rule.” Morgan Stanley agreed to settle the charges without admitting or denying
the findings. In a separate order, Marsh agreed to an industry and penny stock bar with the right
to apply for reentry after five years. He was criminally convicted for his actions last year and
received 36 months of probation and a $600,000 restitution order.
The SEC’s investigation was conducted by William Martin and Simona Suh of the Enforcement
Division’s Market Abuse Unit and supervised by Joseph G. Sansone, Co-Chief of the unit. The SEC
appreciates the assistance of the New York Field Office of the Federal Bureau of Investigation and
the U.S. Attorney’s Office for the Southern District of New York.
E. But wait, there’s more …
Just as federal regulatory agencies have paid increasing attention to cybersecurity matters, so
too with state-legal agencies (including, in many cases, state Attorney General offices, as those
offices at the state level often have an FTC-like consumer-protection function).
And then there are the regulatory agencies of other countries (and, in the case of the European
Union, supra-national regulators). We will not explore these topics here, but you should be
aware that these other regulators may have a significant impact.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

84

13. Private Lawsuits (I)

Learning objectives
•

•
•
•
•
•
•
•

Appreciate how the prospect of civil liability for damages relates to the incentives of
private sector entities with respect to their cybersecurity investments, and how the
ability of governments to modify those prospects can be used as a tool to impact
those incentives.
Be able to identify an array of entities or individuals who might fairly be described as
the “victims” in the situation in which a hacker succeeds in extracting information
from a company.
Know factors that help explain why victims don’t often bring civil suits against the
attacker in that situation.
Be able to explain why the most-likely subject for such a suit is the company that
suffered the breach.
Understand the factors that make it difficult to sue software vendors based on the
vulns in their products.
Form a view on whether the law should be tweaked to make vendors more
amenable to suit.
Understand why settlements occur even when the defendant does not believe they
should be liable.
Understand why class action status can be a powerful driver of settlement.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

85

A. The Big Picture: Who Are the Injured Parties Who Might Become Plaintiffs?
Consider the following depiction of the chain of actors involved in a common type of
cybersecurity incident:

Vendor
(makes
software)

Company (uses
Vendor’s
software; has
customer credit
card data)

Hacker accesses
Company’s database by:
(1) social engineering
tricking Company’s
employee into sharing
credentials, or
(2) exploiting a
vulnerability in
Vendor’s software.

Shareholders
lose value as
stock dips
Customers fear
credit card fraud
& identity theft.

Credit card
companies issue
new cards.

Looking at the chart above, consider the following questions:
• Who would you characterize as a victim?
• One might expect that if anyone is to be sued for damages, it would be the hacker.
That rarely occurs, however. Why might that be?

Usually the vendor is not sued either. That’s to be expected if the hacker breached the
company’s security via social engineering; that’s a failure on the part of the employee(s) and
perhaps the company, but not the vendor. But what if the breach was the result of a vulnerability
in the vendor’s software? Read the following excerpt from this Lawfare article by Jane Chong:

The rapid evolution of software technology and the surge in the total number of
computer users actually led early commentators to warn of software vendors’ increasing
exposure to lawsuits —and the “catastrophic" consequences to ensue. But history has
gone the other way. Operating within a “legislative void,” the courts have consistently
construed software licenses in a manner that allows software vendors to disclaim almost
all liability for software defects. Bruce Schneier, perhaps the most prominent decrier of
the current no-liability regime for software vendors, puts it simply: “there are no real
consequences for having bad security.” The result is a marketplace crammed with
shoddy code.
As users, we tolerate defective software because defective software works most of the
time. And we get it much faster and with a great many features. Partly in response to
consumer appetite, timely release and incremental patching have become key features
of the industry’s “fix-it-later” culture. Software companies look for bugs late in the
development process and knowingly package and ship buggy software with
impunity. Meanwhile end users are slow in acknowledging vulnerabilities, use patches
too infrequently, and fail to timely deploy published updates.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

86

Some experts fear that nothing short of a digital Pearl Harbor—a large-scale attack that
exploits critical security holes in our industrial control systems—will create the momentum
needed to trigger government regulation of and private investment in quality code.
If that ends up being the case, it won’t be for lack of theorizing. Suboptimal code has
been recognized as a problem for decades. Certainly, there are defenders of the status
quo who argue that holding software providers liable for their code would raise
costs and stifle innovation. But legal academics have spent thirty years disagreeing with
that proposition and dreaming up liability schemes designed to force software vendors
to shoulder some of the costs long borne entirely by users.
… The most common analogy is the car. And there are legitimate parallels between the
vehicle safety crisis of the 1960s and today’s software security conundrum. Then, state
and federal courts were reluctant to apply tort law even where automobile-accident
victims claimed their injuries resulted from the failure of manufacturers to exercise
reasonable care in the design of their motor vehicles. Over the next thirty years, however,
the courts did an about-face: they imposed on automobile manufacturers a duty to use
reasonable care in designing products to avoid subjecting passengers to an
unreasonable risk of injury in the event of a collision; applied a rule of strict liability to
vehicles found to be defective and unreasonably dangerous; and held automobile
manufacturers accountable for preventing and reducing the severity of accidents.
Yet to insist that software defects and automobile defects should be governed by
substantively similar legal regimes is to ignore the fact that “software” is a category
comprising everything from video games to aircraft navigation systems, and that the
type and severity of harms arising from software vulnerabilities in those products range
dramatically. By contrast, automobile defects more invariably risk bodily injury and
property damage. To dismiss these distinctions is to contribute to an increasingly
contrived dichotomy, between those who see the uniqueness of software as an
argument for exempting software programs from traditional liability rules altogether, and
those who stress that software is nothing special to claim that the road to software
vendor liability lies in traditional contract or tort remedies.
…Software license agreements are typically crammed with boilerplate language freeing
the software provider from virtually all forms of liability while binding the commercial user
to severe use restrictions. Unhappy with that? Too bad. Anyone who has ever installed
software after “consenting” to the terms of the accompanying clickwrap, shrinkwrap or
browsewrap understands that the disgruntled user has exactly two choices when it
comes to mass market license agreements: take it or leave it.
Software providers typically shunt all the risks associated with their products onto users
through these license agreements, which the courts have generally treated as
enforceable contracts. Think of contracts as a form of private law-making—the parties
agree to impose on themselves obligations not otherwise dictated by the law. Frustrated
theorists have looked outside of the contract realm for ways to hold software providers
accountable for the harms that users sustain as a result of insecure code. Consumer
protection laws would seem to offer one narrow avenue for redress. Alternatively, users
have filed suit for compensation on tort grounds, alleging negligence on the part of the
software provider or product defect. Recognizing the continuing failure of contract law
to provide software users meaningful remedies for harms caused by insecure code, as
well as the challenges associated with bringing a successful tort claim under the current
law, Professors Michael Rustad and Thomas Koenig have gone so far as to propose

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

87

enacting a statute to establish an entirely new category of tort—“the tort of negligent
enablement of cybercrime.”
Software license agreements have become such a bad joke for software users that it’s
hard to believe that once upon a time, it looked like users might be able to leverage
contract principles to their advantage. Specifically, commentators speculated that the
contract-making principles embodied in the Uniform Commercial Code (UCC)—a set of
model laws adopted at least partially by all the states—could be used to “pierc[e] the
vendor's boilerplate” and create a legal framework that would equally benefit vendors
and users, licensors and licensees.
As one believer declared back in 1988, “[B]ecause fairness and reasonableness are
fundamental in the Code, application of the UCC would benefit parties unfamiliar with its
provisions.” Another commentator predicted as early as 1985: “The courts have
adequate means to protect software vendees from unconscionable contract provisions
and the UCC makes requirements for effective disclaimers of warranty clear, so that the
UCC will adequately protect software vendees and will not serve as a vehicle for
manufacturers to limit their liability."
Unfortunately, the UCC has served as just that: a liability-limitation vehicle. As one critic
put it almost two decades ago, treating software licenses as sales governed by the
UCC “creates a legal fiction which—contrary to the general intent of the UCC—places
the purchaser at a severe disadvantage vis-à-vis the vendor.” This is because the UCC is
built on freedom-to-contract principles that assume roughly equal bargaining power
between the buyer and the seller. Since roughly the mid-1990s, the courts have
accepted that operating assumption and allowed software providers to contract away
responsibility for the deficiencies of their products.
Judicial adherence to upholding the terms of the standard software license agreement
has prompted Douglas Phillips, general counsel of Promontory Interfinancial Network, to
dub it the “legislative license.” In other words, thanks to a long line of court decisions, "the
law of the software license has come largely to be defined by each software license
itself."
UCC freedom-to-contract principles serve as the pretext by which courts are able to
uphold the liability disclaimers and limitations on remedies found in all commercial
software licensing agreements. But this is not the end of the story. Other factors help
explain why, in one high-profile case after another, software users alleging defects and
security breaches get their cases thrown out of court. These factors are important insofar
as they offer insight into how the courts understand code—and suggest that the grounds
on which courts construe the rules of contract law in favor of software providers
would similarly forestall user attempts to impose liability on providers through existing
consumer protection laws or through claims sounding in tort. Indeed, software liability is
unlikely to get off the ground without the help of legislation or regulation specifically
designed to impose certain duties on software providers.
At least three factors other than the disclaimers and limitations crammed into the
standard license agreement prevent users from seeking compensation when they are
harmed by defective software. To start, much software is free. This is a problem under
contract law because courts will not hold software providers liable for harms brought
about for products or services for which users did not offer some form of payment—or
what lawyers call “consideration.” This is the basic rule underlying Bruce Schneier’s

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

88

observation that “[f]ree software wouldn't fall under a liability regime because the writer
and the user have no business relationship; they are not seller and buyer.” Schneier is
correct—as long as we’re talking about a private ordering regime. A different legal
framework, however, might make for a different rule. For example, providers of free
software generate revenue not by extracting money from the users, but rather by
extracting data that they are then able to monetize. A statute that creates a duty for
software providers to institute safeguards to secure this data or restrict its use might allow
users to bring suit in the event of a security breach under tort theories of negligence or
misrepresentation.
But in the absence of such a statute, the fact that much software and many Internet
services are free will remain a sticking point for users seeking compensation for securityrelated injuries. Last year the social networking service LinkedIn was hit with a high-profile
class action suit after hackers breached the company server and posted 6.5 million
hashes corresponding to LinkedIn accounts on a forum. Sixty percent of these hashes
were later cracked. The plaintiffs alleged that LinkedIn had failed to utilize industry
standard protocols and technology to protect its customers' personally identifiable
information, in violation of its own User Agreement and Privacy Policy. A federal court in
California threw out the case this spring in part on the grounds that the policy was the
same for users of the free and premium versions of the service. Specifically, the court
found that the complaint “fails to sufficiently allege that Plaintiffs actually provided
consideration for the security services which they claim were not provided.”
The fact that popular Web applications are often free has also proven problematic for
users attempting to state a claim for harms stemming from a security breach under
existing consumer protection laws. In 2011, in lawsuits filed against Facebook and against
Apple for their policies of sharing user data with third parties, two more federal court
judges in California ruled that consumer protection laws did not extend to the users of
free services. In his order dismissing the Facebook case, Chief Judge James Ware of
the U.S. District Court for the Northern District of California wrote, “[A] plaintiff who is
a consumer of certain services (i.e., who “paid fees” for those services) may state a claim
under certain California consumer protection statutes when a company, in violation of its
own policies, discloses personal information about its consumers to the public . . . . Here,
by contrast, Plaintiffs do not allege that they paid fees for Defendant's services.”
Here is a second reason software providers tend to prevail under a private-ordering
regime, and remain immune even when users bring suit under various tort theories: the
courts are resistant to finding an implied warranty of merchantability with respect to
security for software products and services that they know cannot be made vulnerabilityfree. That is, courts tend to treat certain user security expectations as inherently
unreasonable. For example, in 2011, several banks sued the payment transaction
company that had been holding their customers’ data when it suffered a massive
security breach. A Texas federal court rejected the suit, reasoning, “To the extent that the
Financial Institution Plaintiffs argue that [the company’s] statements and conduct
amounted to a guarantee of absolute data security, reliance on that statement would
be unreasonable as a matter of law.” In rejecting the plaintiffs’ claim, the court relied on
the logic of yet another court decision, which declared that “in today's known world of
sophisticated hackers, data theft, software glitches, and computer viruses, a jury could
not reasonably find an implied merchant commitment against every intrusion under any
circumstances whatsoever.”
Note that this line of reasoning once got traction in the automobile context. Evans v.
General Motors Corp. was a Seventh Circuit case in which the plaintiff alleged that

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

89

General Motors had been negligent in designing its 1961 Chevrolet station wagon
without the perimeter frame rails that were being used in many other cars to protect
occupants during a side-impact collision. The Evans court rejected the claim on the
grounds that "[a] manufacturer is not under a duty to make his automobile accidentproof or foolproof.” As one commentator pointed out, the court exaggerated the
plaintiff’s claim to immunize the manufacturer from liability.
Two years later, the Eighth Circuit rejected this formulation of the claims in the landmark
case Larsen v. General Motors Corp., in which the plaintiff alleged negligent design
based on the displacement of the steering shaft in the Chevrolet Corvair. Specifically,
the Larsen court rejected General Motors’ attempt to frame the issue as one contingent
on determining whether it had the duty to produce a crash-proof car, relying instead on
the idea that it was possible for General Motors to have designed a vehicle that would
minimize the effect of accidents.
Similar standards based on industry best practices could be used to impose liability in the
software context, if courts conceived of software as a product that could be designed
to minimize, though not eliminate, security vulnerabilities. But the judiciary’s lack of
technical expertise and the inherent complexity of software have long prevented the
courts from making this leap. In a case dating back to 1986, a federal bankruptcy court
declined to enforce the implied warranty of merchantability where a DOS-based
computer that represented itself as being Apple-compatible failed to run Apple
software. Noting that Apple sells thousands of software programs, the court declared,
“We simply cannot determine the extent of the incompatibility and on that failure of
proof we conclude that there has been no breach of an implied warranty of
merchantability.” The fact that software users have been unsuccessful in asserting
breach of implied warranty bodes badly, in turn, for their ability to bring what amounts to
the “conceptually indistinguishable” tort claim for negligence against the software
maker.
A third factor suggests that courts will continue construing software license agreements—
and, as it turns out, tort actions—in favor of software providers: the idea that hackers, not
providers, are singularly responsible for security breaches. Last year, a California federal
court rejected the claim that Sony had misrepresented the quality of its network security
where Sony's privacy policy had stated that its security was not perfect, and moreover
also rejected plaintiffs' claims of unfair business practices, since Sony did not benefit
financially from the third-party data breach.
The court’s rejection of the unfair business practice claim is noteworthy in that it suggests
a narrow view of what constitutes financial benefit. That is, the court reasons that
software providers gain nothing when malicious actors bring about security breaches,
thereby declining to take an expansive view of the gains that software vendors (unjustly)
reap by engaging in easy, shoddy software development and shipping practices that in
turn contribute to security vulnerabilities and security breaches.
This cramped focus on the role of the hacker in executing the exploit and the refusal to
consider the role of the software maker in creating an environment susceptible to exploit
similarly present a challenge for any attempt to bring basic tort claims. Negligence is
grounds for a civil lawsuit where the plaintiff is able to establish that the defendant owed
a duty, breached that duty, caused harm as a result and should pay damages to make
Humpty Dumpty whole again. Establishing the causation element in that chain is difficult,
if not impossible, so long as courts choose to fixate on the hacker, not the environmentcreator, when assessing who brought about the injury in question.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

90

In sum, it is significant that buttressing the courts’ interpretation of software license
agreements are ideas that similarly pose problems for holding software providers liable
under consumer protection statutes or under tort theories. But the idea that, in the
absence of special legislation or regulation, tort could be a viable avenue for pursuing
liability for software providers runs up against a much bigger threshold problem. That is
the economic loss doctrine. Broadly speaking, the doctrine restricts tort liability to cases
involving bodily injury or damage to other property. This is a special problem for tort
claims related to software vulnerabilities, since most security breaches give rise to purely
economic losses or data compromises.
Thanks to the economic loss rule, courts have long been spared the uncomfortable task
of actually declaring that software vendors have no duty to institute reasonable
measures to develop and maintain secure software. For example, back in 2000, the gas
and oil company Hou-Tex, Inc. alleged that a software program company had
breached both its duty to inform its customer about a bug in the software and its duty to
fix the problem. But the Texas state court held that the economic loss rule precluded
Hou-Tex's negligence claims against the software company. In a 2010 case, a New York
federal judge made no mention of a potential duty, and instead simply
dismissed plaintiffs’ claims of negligence, strict liability and gross negligence for damages
stemming from defects in the contracted-for software, as barred by New York's
economic loss doctrine.
The economic loss doctrine has public policy roots. As the Supreme Court explained in
its landmark 1986 decision East River Steamship Corp. v. Transamerica Delaval, Inc., tort
law is the appropriate vehicle for addressing unexpectedly dangerous and defective
products, since in the case of unexpected personal injury or property damage, the
manufacturer is best positioned to bear the cost of and to price the product to spread
the loss. Pure financial loss, however, is properly the domain of contract law, particularly
the law of warranty, because the rule prompts the parties to set the terms of the
bargain. Where the consumer agrees to pay less, the manufacturer can restrict its liability
by disclaiming warranties or limiting remedies.
In short, the economic loss doctrine is premised on the idea that, as declared by the East
River Steamship court, “a commercial situation generally does not involve large
disparities in bargaining power . . . [thus] we see no reason to intrude into the parties'
allocation of the risk.” In other words, the rule does not account for the asymmetric
bargaining power between software vendors and end-users—which is pretty vast.
And so after very briefly touring some of the problems with the current private-ordering
regime, and having learned (in part) why tort law won’t work either, we return, full circle,
to the inadequacies of contract law and the UCC in allocating liability between software
vendors and users.
The failure of software users to prevail under contract, tort, or consumer protection
schemes when it comes to getting compensated for bad code suggests that in the
absence of specific legislation or regulation—for example, restricting software vendors’
ability to rely on blanket disclaimers—software users will have little success in holding
vendors accountable for vulnerabilities.
To put it simply, the laws on the books must change—or the quality of our software will
not.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

91

Noted computer security expert Daniel Geer thinks you should bear the costs of the
insecure code you use. It’s nothing personal. He acknowledges that holding the end user
responsible for being the “unwitting accomplice to constant crime” is far from a perfect
cybersecurity strategy. But he concludes that for the time being, it is the least “worst”
option:
If you say that it is the responsibility of Internet Service Providers (ISPs) — that “clean
pipes” argument— then you are flatly giving up on not having your traffic inspected at a
fine level of detail. If you say that it is the software manufacturer’s responsibility, we will
soon need the digital equivalent of the Food and Drug Administration to set standards for
efficacy and safety. If you say that it is the government’s responsibility, then the mythical
Information Superhighway Driver’s License must soon follow. To my mind, personal
responsibility for Internet safety is the worst choice, except for all the others.
Geer’s concern is well-founded: imposing security responsibilities on entities other than
the end-user will no doubt abrogate some of the freedom and functionality that end
users currently enjoy as consumers. This is true both with respect to software and Internet
access specifically and with respect to computer information systems more generally.
But Geer’s conclusions are unnecessarily stark, in part because they assume that security
is a pie that cannot be intelligently shared—a conclusion that, it should be noted, we
would never be inclined to accept in our offline lives. Our physical security may
ultimately be our burden to bear, but we expect fast food chains not to poison us, local
police to do their rounds and our neighbors to call 9-1-1 if they see suspicious activity.
Some invisible web of law, professional obligations and communal norms collude at all
times to keep us alive and our property in our possession.
Would vesting ISPs with circumscribed security responsibilities—such as responding to or
recording highly unusual traffic patterns that suggest an ongoing DDoS attack—require
end-users to “flatly” relinquish data privacy? Many ISPs already implement limited
security mechanisms, and carefully designed private-public data-sharing restrictions
could go a long way toward addressing concerns about improper use of subscriber
information.
Similarly, holding software providers accountable for their code need not entail exposing
software providers to lawsuits for any and all vulnerabilities found in their products.
Liability critics battle a straw man when they make arguments like this one, from
computer security authority Roger Grimes: “If all software is imperfect and carries security
bugs, that means that all software vendors—from one-person shops to global
conglomerate corporations—would be liable for unintentional mistakes.”
Liability is a weapon far more nuanced than its critics believe. Geer and Grimes see
liability as a big red button—a kind of nuclear option, to be avoided at all costs.
Meanwhile proponents understand liability as a complex machine ideally outfitted with a
number of smart levers.
Consider: software’s functions range from trivial to critical; security standards can be
imposed at the development or testing stage, in the form of responsible patching
practices or through obligations for timely disclosure of vulnerabilities or breaches; the
code itself might be open-source or proprietary or in any case free. An effective liability
regime is one that takes these many factors into account when it comes to designing
rules, creating duties or imposing standards.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

92

For starters, it would make no sense to hold all software providers to the same duty of
care and the same liability for breach of that duty, irrespective of the software’s
intended use and associated harms. As Bruce Schneier observed back in 2005, “Not all
software needs to be built under the overview of a licensed software engineer . . . [but]
commercial aircraft flight control software clearly requires certification of the responsible
engineer.” All software embedded in life-critical systems or critical infrastructure should
be consistently made subject to more rigorous standards than standard commercial
software, and the manufacturers should be held liable either for harms caused by
products that deviate from those standards, or for flaws that are not timely remediated.
Imposing this kind of liability will require restricting the disclaimers of warranty and
limitations on remedies found in standard software license agreements. As far as
recommendations go, this is a familiar rerun. In a 2007 report, the House of Lords Science
and Technology Committee recommended that the European Union institute “a
comprehensive framework of vendor liability and consumer protection,” one that
imposes liability on software and hardware manufacturers “notwithstanding end user
licensing agreements, in circumstances where negligence can be demonstrated.”
The tricky part, of course, is putting into place a system through which negligence can
be reliably demonstrated. As a general principle, insofar as security can be understood
as a process, rather than an end, negligence should be assessed based on failure to
adhere to certain security standards rather than based on absolutes like the number of
vulnerabilities in the software itself. Indeed, numbers might reveal more about the
software’s popularity than its inherent insecurity. Any particular vulnerability might not
prove a software program unacceptably defective—but an examination of the general
processes and precautions through which the software was produced just might.
Laws merely establishing modest duties on the part of software makers—and subjecting
them either to private suit or government fine in the event of harms resulting from
breach—could help push the industry to develop and implement best practices. These
practices could in turn constitute an affirmative defense against negligence claims. Best
practices might range from periodic independent security audits to participation in what
David Rice, Apple’s global director of security, describes as a ratings system for software
security, an analogue to the National Highway Traffic Safety Administration’s rating
system for automobile safety.
Already existing legislation that penalizes companies for failing to safeguard sensitive user
information offers a useful model for imposing narrowly circumscribed security duties on
software providers. For example, in 2006, the Indiana legislature enacted a statute that
requires that the owner of any database containing personal electronic data disclose
a security breach to potentially affected consumers but does not require any other
affirmative act. The terms of the statute are decidedly narrow—it provides the state
attorney general enforcement powers but affords the affected customer no private right
of action against the database owner and imposes no duty to compensate affected
individuals for inconvenience or potential credit-related harms in the wake of the
breach.
There are other factors to consider in calibrating a liability system. Liability exposure
should be to some extent contingent, for example, on the availability of the source
code. It is difficult to imagine, for instance, a good argument for holding the contributors
to an open source software project liable for their code. Whether or not you believe that
the process by which open source software evolves actually constitutes its own security
mechanism, a la Linus's Law ("given enough eyeballs, all bugs are shallow”), the fact is

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

93

that open-source software offers users both the cake and the recipe. Users are free to
examine the recipe and alter it at will. By offering users access to the source code, open
source software makes users responsible for the source code—and unable to recover for
harms.
Imposing liability on open-source software is not only an incoherent proposition, but it
also has problematic First Amendment implications. Code is, after all, more than a good
or service. It is also a language and a medium. And clumsily-imposed liability rules could
place significant and unacceptable burdens on software speech and application-level
innovation.
In her book on the relationship between internet architecture and innovation, Barbara
van Schewick gives us some sense of why we should be wary of creating stifling liability
laws with her description of the nexus between software applications and sheer human
potential:
The importance of innovation in applications goes beyond its role in fostering economic
growth. The Internet, as a general-purpose technology . . . creates value by enabling
users to do the things they want or need to do. Applications are the tools that let users
realize this value. For example, the Internet’s political, social or cultural potential—its
potential to improve democratic discourse, to facilitate political organization and action,
or to provide a decentralized environment for social and cultural interaction in which
anyone can participate—is tightly linked to applications that help individuals, groups or
organizations do more things or do them more efficiently, and not just in economic
contexts but also in social, cultural or political contexts.
All of this applies, of course, to proprietary applications, but the liability calculus for
closed-source software should come out a little different. When it comes to proprietary
applications, the security of the code does not lie with users but remains instead entirely
within the control of a commercial entity. The fact that much proprietary software is
“free” should not foreclose liability: a narrowly tailored liability rule might provide that
where users are “paying” for a software product or service with their data, a data
breach that causes damages could be grounds for government-imposed fines or, to the
extent it causes individuals to sustain harm, private damages.
This is by no means a comprehensive overview of all possible approaches to constructing
a software liability regime. It is rather a glimpse of a few of the many levers we can push
and pull to turn security from an afterthought into a priority for software makers. Such a
change will come with costs, imposed on software makers and redistributed to us, the
users. But we must keep in mind that whatever we pay in preventive costs today are low
compared with what we could pay in remedial security costs tomorrow.
As a matter of routine, we accept inconveniences, costs and risk redistribution in other
areas of our lives. Drugs are required to undergo clinical testing, food is inspected and
occasionally “administratively detained,” and vaccines are taxed to compensate the
small fraction of recipients who will suffer an adverse reaction. Restrained measures to
police software, too, can be understood as part of a commonsense tradeoff between
what is cheap and functional and what is safe and secure.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

94

Make a list of the obstacles to suing software providers.
• Consider the policies that might be served by each obstacle. Would you change
any of them?

This leaves the option of suing the company that actually suffered the breach, on the theory that
it was not just a victim but also a harm-inflictor in its own right given that it did not have better
defenses. Our goal now is to understand the major form of liability that companies in this situation
might face.
B. Tort Liability (Liability For Lack of Due Care)
In our legal system, we use the word “tort” to refer to situations in which the law authorizes suits for
damages based on harmful actions/omissions. Some torts are “common law” causes of action,
meaning that the courts have recognized a right to sue in a particular situation even without a
statute calling for recognition of that tort. This is the traditional and most familiar kind of tort.
Examples include negligence and battery. But legislatures can create torts by statute, too, if they
wish.
There are many kinds of torts. One batch, called “intentional torts,” involves purposefully harmful
conduct. That’s not our concern here, for we are assuming that companies do not intend to be
breached. So that leaves us with unintentional harms. In that situation, the tort system can take
either of two approaches. First, it can make someone strictly liable for all harms they cause.
Second, it can make them liable only for harms that result from lack of adequate care—what we
commonly call “negligence.” The strict-liability approach is relatively rare, and usually confined
to ultra-hazardous activities. For companies that may have inadequate information security, the
important question is negligence.
As all law students learn during their first year, negligence makes a defendant liable in damages
where four conditions are met: (1) the defendant owed a duty of care, (2) the defendant
breached that duty, (3) the plaintiff suffered a legally recognizable harm, and (4) the breach was
the proximate (reasonably foreseeable) cause of that harm.

Pause now to consider how, in the scenario above, the company’s customers might have a
negligence claim against (a) the company or (b) the vendor.

Plaintiffs have an uphill battle in bringing negligence claims against companies that suffer a data
breach, because each of the elements of a traditional negligence action are difficult to show in
the cybersecurity context. For example, even if a court assumes that a business has a duty to
protect its customers’ data, plaintiffs must show the business’s cybersecurity practices were so
substandard that it actually breached that duty of care––and this requires comparing those
practices to some standard of what “reasonable” cybersecurity practices look like.
Next, plaintiffs must show that they suffered some harm as a result of the breach. But how? For
plaintiffs whose data has been exposed, it can be difficult to identify the amount of harm they
actually suffered unless that data has been used against them. But even for plaintiffs who can
show they suffered identity theft or some other harm, how can they prove it was the result of this
particular breach, and not some other breach of their data?

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

95

The Supreme Court recently denied certiorari in two cases that would have addressed the
problems plaintiffs face in obtaining class certification in class-action suits. Here is what Joseph
Marks at the Washington Post had to say about it in December 2018:
Two class-action lawsuits that could come before the Supreme Court this term seek to
determine just how bad a cybersecurity lapse must be before customers can sue.
In both cases, federal appeals court judges formally approved lawsuits by thousands of
consumers who want to collectively sue major companies for cybersecurity failures — even
though the customers couldn’t prove they’d suffered any direct financial harm from the
companies’ digital negligence.
The companies are asking the high court to overturn the lower court decisions allowing the
lawsuits. They argue that customers must suffer some concrete financial or physical harm
before they can demand compensation for a data breach or for hackable vulnerabilities
discovered in their products.
Flexible tech solutions can prepare your business for nearly any challenge, but first you
need a game plan.
Consumers, however, contend that setting such strict standards would give negligent
companies a pass for not sufficiently protecting their products and data.
If the Supreme Court rules on either case, it could fundamentally reshape the responsibility
the private sector has over the security of Internet-connected products that could
endanger consumers' privacy or even their lives in the case of things like cars and medical
devices.
If the court sets a high bar for consumers to sue, it could prompt companies to play fast
and loose with their data. If that standard is too low, however, it may deter companies
from sharing information about newfound computer bugs or investing in new technologies
out of fear they’ll be on the hook for legal damages.
“You’ve potentially jacked way up the monetary costs from a vulnerability that’s disclosed
down the road,” Megan L. Brown, an attorney with Wiley Rein who deals in complex
litigation and technology, told me. “That may affect a company’s risk calculation and
make them not do some things.”
The first class action suit was sparked after a viral 2015 Wired article describing how two
security researchers hacked through the entertainment system in a Jeep Cherokee to kill
the brakes — all while the Wired reporter was driving the vehicle at 70 mph through
downtown St. Louis.
After the article, Chrysler mailed 1.4 million vehicle owners a USB stick with software to fix
the vulnerability, and there’s no evidence malicious hackers ever exploited it. Jeep owners
point to the hack, however, as evidence that their vehicles are “excessively vulnerable”
and say they should get some money back, according to Chrysler’s petition to the high
court.
The issue is particularly complicated because cybersecurity experts warn there’s no way
to ensure any system is 100 percent digitally secure.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

96

Even major digital consumer products such as Microsoft’s Office suite or Apple’s iPhone
aren’t invulnerable. Security researchers find hackable vulnerabilities in those products
every week. The most mature and cyber-sensitive companies, however, usually manage
to find and patch the most dangerous vulnerabilities before malicious hackers exploit
them.
If the Jeep plaintiffs are successful, “it opens the door to litigation of all stripes and flavors
over any consumer product that connects to the Internet,” Chrysler attorney Thomas H.
Dupree Jr. told me. “Any product, hypothetically, can be hacked and any plaintiff can
hire a lawyer who says, ‘In my opinion the product has inadequate cybersecurity even
though it hasn’t been breached.’ ”
In the second case, the online retailer Zappos did suffer a malicious breach of a database
containing customers’ information, including names, contact information and possibly
credit card data. The company says, however, that there’s no evidence the hackers used
that data to impersonate customers or to make phony credit card charges.
The customers dispute that characterization, however, and say hackers used their
information to hack other accounts.
The Zappos and Jeep cases are being litigated at the U.S. District Court level while the
lower courts wait to learn whether the Supreme Court will hear the cases. Neither case has
moved substantially past the questions of whether the plaintiffs have standing to sue and
who should be included in the plaintiffs' class.
The high court held a conference on the Zappos case this month and is scheduled to meet
on the Jeep case Jan. 4. The court probably will decide whether to grant hearings in the
cases in January.
Meanwhile, industry groups are worried about the potential implications. Trade
associations like the U.S. Chamber of Commerce, the National Association of
Manufacturers and CTI, the wireless association, have filed friend-of-the-court briefs
supporting the companies.
They have reason to be concerned if the high court does take the cases. Lawsuits where
there’s much clearer harm from a data breach have resulted in multimillion-dollar
settlements. Target, for example, paid $18.5 million to settle cases brought by state
attorneys general over its 2013 breach of credit and debit card information for at least 40
million customers and personal information about many more. The retailer is trying to
conclude a $10 million settlement on a consumer class action stemming from that breach.
In other cases, assessing whether hack victims have suffered harm can be far more
difficult.
The U.S. Court of Appeals for the D.C. Circuit, for example, is mulling a case filed by federal
employee unions over the 2015 Office of Personnel Management data breach. Most
cyber experts believe that breach was launched by Chinese government hackers who
want to use the data for blackmail or other espionage.
That means it’s unlikely the data stolen from more than 21 million current and former
federal employees and their families will be used for identity theft or to make phony credit
card charges. The stolen data, however, included extremely personal background check

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

97

information, including lengthy questionnaires about finances, housing, family relationships
and drug and alcohol use.
An appeals court judge said during a Nov. 2 hearing that the government faced an “uphill
battle” arguing the plaintiffs didn’t have grounds to sue in that case, as reported by
GovExec.
The harm caused by that kind of hack is far different from the nebulous damage caused
by a breach involving only information such as names and addresses, Joe Hall, chief
technologist at the Center for Democracy and Technology think tank, told me.
“Trivial harm should not be something that keeps us from building wonderful things,” Hall
said. “But we really need to find a way to articulate harms that are not economic but really
affect people’s ability to trust each other or to participate in the world.”
So, what happened next? The Supreme Court has declined to hear either case, leaving the Court
of Appeals rulings in place.
Next, consider the following case study, arising out of the infamous data breach at the credit
agency Equifax. Credit-reporting agencies like Equifax are a particularly appealing target, in light
of the vast volume and sensitive nature of the information they collect. As you might imagine,
news of the breach made headlines, and many lawsuits followed. Eventually, a group of plaintiffs
joined to seek “class action” status—that is, to represent and seek recovery not just on their own
behalf but also on behalf of every other similarly-situated person. Here is an account of that suit,
from Anne Bucher:
Equifax Inc. has been hit with a class action lawsuit filed on behalf of individuals in all 50
states and the District of Columbia over the massive Equifax data breach that was
announced in September.
A massive cybersecurity incident reportedly exposed the sensitive personal identification
and financial information of more than 145 million people—nearly half of the U.S
population.
“This case concerns the largest data breach involving personal and financial information
in American history,” the Equifax class action lawsuit says. “Equifax, one of the three credit
reporting companies used by thousands of businesses to assess the credit worthiness of
customers and prospective customers, failed spectacularly in protecting that data.”
As a result, sensitive consumer information such as names, birth dates, Social Security
numbers, drivers’ license numbers, address history and other financial information was
allegedly accessed by unauthorized parties from May through June.
The Equifax class action lawsuit claims the damage caused by the Equifax data breach
was compounded by the credit reporting agency’s “egregious cybersecurity failures
before, during, and after the breach,” including: failing to employ an available security
patch, not recognizing the data breach for more than three months, failing to implement
security measures after the data breach, and failing to timely inform the public about the
massive data breach.
The plaintiffs also challenge Equifax’s response to the data breach, including the confusing
emails it sent to consumers about whether their information was compromised, and
creating a credit monitoring service with a confusing message about whether users would

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

98

be bound by an arbitration clause, and sending consumers a wrong link to have their
credit frozen.
… This new 323-page Equifax class action lawsuit seeks to consolidate dozens of data
breach lawsuits that are currently pending throughout the country. At least 150 data
breach lawsuits have been filed nationwide against Equifax so far.
The plaintiffs include individuals from all 50 states and the District of Columbia who allege
they have experienced fraud after their sensitive personal information was compromised
in the data breach.
The Equifax class action lawsuit asserts claims for violation of the Fair Credit Reporting Act,
negligence, negligence per se, bailment, unjust enrichment, and violation of state
consumer protection and/or privacy laws. The plaintiffs are seeking monetary damages,
declaratory and injunctive relief, and other remedies allowed under the applicable laws.
The plaintiffs in this case sought “class action” status—that is, they sought approval from the court
to assert not just their own claims but those of all other similarly-situated persons.

Consider the pros and cons of class-action status from the point of view of the defendant, the
plaintiff, and the plaintiff’s attorneys (bearing in mind that the plaintiff’s attorneys most likely
are being compensated on a “contingent fee” basis—meaning that they will receive a
percentage of the eventual recovery, if any).

It can be hard to prove what the duty of care is, let alone that a breach of it occurred. Read this
CNN account of the Equifax hack:
How did it happen? Much is still unknown. But it came down to a flaw in a tool designed
to build web applications, the company said in a press release this week. And Equifax
admitted it was aware of the security flaw a full two months before the company says
hackers first gained accessed to its data.
Some of the information hackers had access to includes names, Social Security numbers,
birth dates, addresses and some driver's license numbers.
The tool is called Apache Struts, and it's used by many large businesses and government
organizations. Equifax used it to support its online dispute portal
-where Equifax (EFX) customers go to log issues with their credit reports. The flaw allowed
hackers to take control of a website.
A cybersecurity arm of the U.S. Department of Homeland Security, US-CERT, "identified and
disclosed" the Apache Struts flaw in March, Equifax said in a statement.
And the company's security department "was aware of this vulnerability at that time, and
took efforts to identify and to patch any vulnerable systems."
Yet, according to the company, hackers exploited the flaw months later.
Equifax has said it discovered the data breach on July 29. On Friday, it said it waited until
it "observed additional suspicious activity" a day later to take the affected web application
offline.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

99

And on August 2 Equifax contacted Mandiant, a professional cybersecurity firm, to help
the company assess what data had been compromised.
With help from Mandiant, Equifax was able to determine a series of breaches had
occurred from May 13 through July 30, the company said.
Patching software at big corporations with many machines does take time. They must first
identify the vulnerability, then implement and test the patch to make sure it doesn't break
anything before making it public.
However, security experts say Equifax should have moved faster.
"There's really no excuse whether it's a difficult patch or not, for an organization of that size
with that kind of magnitude of data," said Jon Hendren, director of strategy at security firm
UpGuard. "When you're a big organization like that, it's a systemic failure of process and
the blame goes straight to the top."
Equifax has also been widely criticized for waiting more than a month to alert its customers
and shareholders about the hack.
On Friday, the company announced its chief information officer and chief security officer
are "retiring."

Consider the following questions:
• Assume that is all accurate. Do you feel Equifax breached a duty of care?
• What, exactly, is the duty?
• If you think Equifax breached its duty, what specifically would you say it should have
done? Can you explain how your understanding of Equifax’s duty is different from
saying that Equifax is simply strictly liable for any breach that might occur?
• What do you suppose Equifax would argue in response?

Proving the existence of a duty of care, and a breach, can be difficult. But even if proven, that’s
not enough. The plaintiff also must prove that the breach was the proximate cause of damage.
This can be a huge challenge in the context of data breaches.
The Electronic Frontier Foundation offers the following perspective (original here):
This summer 143 million Americans had their most sensitive information breached,
including their name, addresses, social security numbers (SSNs), and date of birth. The
breach occurred at Equifax, one of the three major credit reporting agencies that
conducts the credit checks relied on by many industries, including landlords, car lenders,
phone and cable service providers, and banks that offer credits cards, checking
accounts and mortgages. Misuse of this information can be financially devastating.
Worse still, if a criminal uses stolen information to commit fraud, it can lead to the arrest
and even prosecution of an innocent data breach victim.
Given the scope and seriousness of the risk that the Equifax breach poses to innocent
people, and the anxiety that these breaches cause, you might assume that legal
remedies would be readily available to compensate those affected. You’d be wrong.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

100

While there are already several lawsuits filed against Equifax, the pathway for those
cases to provide real help to victims is far from clear. That’s because even as the number
and severity of data breaches increases, the law remains too narrowly focused on
people who have suffered financial losses directly traceable to a breach.
The law consistently fails to recognize other sorts of harms to victims. In some cases this
arises in the context of threshold “standing” to sue, a legal requirement that requires
proof of harm (lawyers call it “injury in fact”) to even get into the door in federal courts. In
other cases the problem arises within the claim itself, where “harm” is a legal element
that must be proven for a plaintiff to win the case. Regardless of how the issue of “harm”
comes up, judges are too often failing to ensure that data breach victims have legal
remedies.
The consequences of this failure are two-fold. First, there’s the direct problem that the
courthouse door is closed to hundreds of millions of people who face real risk and the
accompanying reasonable fears about the misuse of their information. Second, but
perhaps even more important, the lack of legal accountability means that the
companies that hold our sensitive data continue to have insufficient incentives to take
the steps necessary to protect us against the next breach.
Effective computer security is hard, and no system will be free of bugs and errors.
But in the Equifax hack, as in so many others, the breach resulted from a known security
vulnerability. A patch to fix the vulnerability had been available for two months, but
Equifax failed to implement it even though the vulnerability was being actively exploited.
This wasn’t the first time that Equifax has failed to take computer security seriously.
Even if increasing liability only accomplished an increased incentive to patch known
security problems, that alone would protect millions of people.
While there are exceptions, too often courts dismiss data breach lawsuits based on a
cramped view of what constitutes “harm.” These courts mistakenly require actual or
imminent loss of money due to the misuse of information that is directly traceable to a
single security breach.
Yet outside of data breach cases, courts routinely handle cases where damages aren’t
just a current loss of money or property. The law has long recognized harms such as the
infliction of emotional distress, assault, damage to reputation and future business
dealings.1Victims of medical malpractice and toxic exposures can receive current
compensation for potential for future pain and suffering. As two law professors, EFF
Advisory Board member Daniel J. Solove and Danielle Keats Citron, noted in comparing
data breach cases to the recent claims of emotional distress brought by Terry Bollea
(Hulk Hogan) against Gawker: “Why does the embarrassment over a sex video amount
to $115 million worth of harm but the anxiety over the loss of personal data (such as a
Social Security number and financial information) amount to no harm?” “Why does the
embarrassment over a sex video amount to $115 million worth of harm but the anxiety
over the loss of personal data (such as a Social Security number and financial
information) amount to no harm?”
For harms that can be difficult to quantify, some specific laws (e.g. copyright,
wiretapping) provide for “statutory damages,” which sets an amount per infraction.2

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

101

The recent decision dismissing the cases arising from the 2014-2015 Office of Personnel
Management (OPM) hack is a good example of these “data breach blinders.” The court
required that the plaintiffs—mostly government employees—demonstrate that they
faced a certain, impending, and substantial risk that the stolen information would be
misused against them, and that they be able to trace any harm they alleged to the
actual breach. The fact that the data sufficient to impersonate was stolen, and stolen
due to negligence of OPM, was not sufficient. The court then disappointingly found that
the fact that the Chinese government—as opposed to ordinary criminals—are suspected
of having stolen the information counted against the plaintiffs in demonstrating likely
misuse.
The ruling is especially troubling because we know that it can take years before the
harms of a breach are realized. Criminals often trade our information back and forth
before acting on it; indeed there are entire online forums devoted to this exchange.
Stolen credentials can be used to set up a separate persona that incurs debts, commits
crimes, and more for quite a long time before the victim is aware of it. And it can be
difficult if not impossible to trace a problem with credit or criminal activity misuse back to
any particular breach.
How are you to prove that the bad data that torpedoed your mortgage application
came from the breaches at Equifax as opposed to the OPM, Target, Anthem, or Yahoo
breaches, just to name a few?
When data is being declared the ‘oil of the digital era’ and millions in venture capital
funding await those who can exploit it, it's time to reevaluate how to think of data
breaches and misuse, and how we restore access to the courts for those impacted by
them.
When data is being declared the ‘oil of the digital era,’ it's time to reevaluate how to
think of data breaches and misuse.
Simply shrugging shoulders, as the OPM judge did, is not sufficient. Courts need to start
applying what they already know in awarding emotional distress damages, reputational
damages, and prospective business advantage damages to data breach cases, along
with the recognition of current harm due to future risks, as in medical malpractice and
pollution cases. If the fear caused by an assault can be actionable, so should the fear
caused by the loss of enough personal data for a criminal to take out a mortgage in your
name. These lessons can and should be brought to bear to help data breach victims get
into the courthouse door and all the way to the end of the case.
If the political will is there, legislatures, both federal and state, can step up and create
incentives for greater security and a much steeper downside for companies that fail to
take the necessary steps to protect our data.
The standing problem requires innovation in crafting claims, but even the Supreme Court
in the recent Spokeo decision recognized that intangible harms can still be harms under
the Constitution and Congress can make that intention even more clear with proper
legislative language. Alternately, as in copyright or wiretapping cases where the
damages are hard to quantify, Congress can use techniques like statutory damages to
ensure that those harmed receive compensation. Making such remedies clearly
available in data misuse and breach cases is worthy of careful consideration. So far, the
federal bills being floated in response to the Equifax breach and earlier breaches do not

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

102

remove these obstacles to victims bringing legal claims and ensure a private right of
action.
Similarly, outside of the shadow of federal standing requirements, state legislatures can
consider models of specific state law protections like California’s Lemon Law, formally
known as the Song-Beverly Consumer Warranty Act. The Lemon Law provides specific
extra remedies for those purchasing a new car that needs significant repairs. States
should be able to recognize that data breach situations are special and may similarly
require special remedies. Things to consider are giving victims easier (and free) ways to
clean up their credit rather than just the standard insufficient credit monitoring schemes.
By looking at various options, Congress and state legislatures could spur a race to the top
on computer security and create real consequences for those who choose to linger on
the bottom.
Of course, shoring up our legal remedies isn’t the only avenue for incentivizing
companies to protect our data better. Government agencies like the Federal Trade
Commission and state attorneys general have a role to play, as does public pressure and
media attention.
One thing is for sure: as long as the consequences for neglecting to protect user data
are weak, data breaches like the Equifax breach will continue to occur. Worse, it will
become increasingly difficult for victims to demonstrate which breach caused their
credit rate to drop, their job prospects to dim, or their hopes for a mortgage to be
dashed. It’s long past time for us to rethink the approach to harm in data breach cases.

•

Do you agree?

So, what ultimately happened in the Equifax case, anyway? See here:
Equifax’s massive data breach in 2017 compromised 146.6 million Social Security numbers, along
with other personal information. As a result, the consumer credit reporting agency
faced numerous lawsuits, including a class-action lawsuit that reached a settlement of at least
$650 million on Monday.
According to the terms of the settlement, which still requires court approval, Equifax has to put
at least $380.5 million into a restitution fund for consumers harmed by the breach. The creditmonitoring agency has agreed to put up an additional $125 million if consumers’ out-of-pocket
losses exceed $380.5 million. The settlement also includes money Equifax will spend on free credit
monitoring for those affected by the breach.
The roughly 147 million people whose data was breached are eligible for five potential benefits:
•
•

They can be compensated for up to 20 hours at $25 per hour for time they spent
dealing with identity theft or other related measures. Ten of these hours can be “selfcertified.”
They are also eligible to be reimbursed for up to $20,000 as a result of losses “fairly
traceable” to the breach. This can include a credit file being frozen or unfrozen,
buying credit monitoring services, out-of-pocket losses due to identity theft of fraud,

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

•

•
•

103

and a quarter of money paid to Equifax for credit monitoring or ID theft protection
subscriptions a year before the breach.
As a result of the settlement, class members can obtain four years of three-bureau
credit monitoring and ID protection through Experian — worth $1,200. Plus, they can
get another six years of one-bureau credit monitoring through Equifax, valued at
$720.
Consumers who have existing credit-card monitoring can be paid $125.
The settlement also provides “ID restoration” services for seven years, for those who
were victims of identity theft. These consumers will be assigned an “identity theft
restoration specialist” who will provide them with step-by-step assistance.

… Back in January 2019, a judge had denied a request from Equifax to dismiss the classaction lawsuit. The New York Times notes that the settlement assumes that just 7 million will
sign up for free creditor monitoring. According to the settlement itself, if all 147 million
people whose data was breached sign up for monitoring, then Equifax would have to pay
a whopping $2 billion. Consumers have six months to claim their benefits.

Consider the following questions:
• Why did the company settle?
• Is this a good outcome from the point of view of the larger public interest(s) at stake?

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

104

14. Private Lawsuits (II); Insurance & Contract Terms

Learning Objectives
•

•
•
•

•
•
•
•

•
•
•
•

•

Understand how a statute can make it easier to sue for negligence by imposing “statutory
damages” and how this is one example of how a government can tweak, intentionally, the
incentives environment
Be able to explain why the possible role of China in both the Equifax and Anthem stories
complicates the question of their liability
Contract breach claims may overlap with, but are not coextensive with, deception claims
(ala the FTC Act); be able to explain why
Understand that liability for inadequate “breach notification” is a particularly-common
scenario, and that anticipation of such liability is itself a factor encouraging greater investment
in breach prevention
Appreciate that there is not yet a uniform standard for breach notification, and that states
vary in terms of what they require
Be able to describe the timing requirement of the Texas breach notification law, including the
factors that allow flexibility
Note that the shareholders of publicly-traded companies can bring “shareholder” suits
Be able to explain why insurance companies are in a great position to promote improved
cybersecurity on a wide scale, though also why such companies have had trouble fulfilling this
role.
Be able to explain the two distinct roles that the insurance industry can play: “proxy regulator”
and “wise counselor sharing important information”
Understand reasons why the insurance industry has not (yet) optimized its ability to drive
insureds towards improved cybersecurity more effectively
Understand that governments are in position to regulate insurers, and hence might be in
position to drive insurers to approach this issue differently than they do
Appreciate that any contract party, in theory, can insist on certain cybersecurity practices as
a condition of the contract, but also that few entities are in a position to have a systemic
impact in this way
Understand why the government is in such a position, and be able to describe how the
Kaspersky example illustrates what can be done with that position

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

105

A. Statutory Interventions to Clarify Liability
Note that legislatures can intervene to clarify or modify the scope of tort-style liability if they wish,
making it harder or easier to sue. California, for example, recently did exactly that. Section 11 of
the California Consumer Privacy Act of 2018 (codified at Cal. Civil Code Section 1798.150)
provides that certain companies doing business in California are subject to civil suit for injunctive
relief or damages in the amount of the plaintiff’s actual damages or else “statutory damages”
(that is, a pre-set penalty determined by the statute) in the range of $100-$750 per consumer per
incident, whichever turns out to be higher, if “nonencrypted or nonredacted personal information
. . . is subject to an unauthorized access and exfiltration, theft, or disclosure as a result of the
business’s violation of the duty to implement and maintain reasonable security procedures and
practices appropriate to the nature of the information….”

Consider these questions:
• How does this statutory standard compare to common-law negligence?
• In light of how the statute describes the category of information subject to the statute’s
protection, what advice would you give to a company that has personal information
to protect?
B. Contract Liability (For Failing to Live Up to Security-Related Promises)
In some settings, the company that suffered a breach will have made security-related
representations in a contract of some kind. A professional-services firm, for example, might include
such representations in the “engagement letter” that serves as the contract between the firm and
its clients (sophisticated clients increasingly will insist upon this). In other settings, there may be
terms-of-service that govern a customer’s or user’s relationship to a company (particularly, but not
only, where customers or users interact with the company via an app). These too may contain
security-related representations. These and other examples create the possibility of a breach-ofcontract lawsuit in the event of a data breach where the breach arguably shows that the
company failed to live up to its promises.
Of course, companies make some representations in settings that do not count as part of a
contract with a customer or user. For example, a company may make statements in
advertisements or on their websites, including statements about care they take to protect
customer and user data.

Consider how this illustrates the difference between a breach of contract claim and an FTC
enforcement action based on deceptive advertising.

C. Case Study: Anthem
In February 2015, the health insurance company Anthem announced that its security had been
breached and that a massive amount of personally identifiable information about patients had
been exposed. This led to massive litigation, based on a variety of claims, including breach-ofcontract claims. Anthem tried to have these claims dismissed but was only partially successful.
On one hand, it did succeed in having the breach-of-contract claims dismissed, on the ground
that the promises it made regarding customer privacy on its website’s “privacy statement” and in
certain mailings to customers were not actually part of a contract with customers. On the other

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

106

hand, the court refused to dismiss a separate cause of action, under California-state law, for
deceptive advertising.
Having failed to get the whole case dismissed, Anthem eventually settled. Read about it below
(drawing from this):
Health insurer Anthem Inc. will pay $115 million to end class action litigation over a 2015
data breach that exposed information of nearly 80 million individuals.
According to court documents, Class Members are expected to receive two years of
credit monitoring as well as money for any expenses due to the data breach under the
deal.
Settlement documents indicate that $15 million will be reserved for any out-of-pocket
expenses paid by Class Members due to the breach. Anthem will also pay $38 million in
attorneys’ fees.
“By settling now, the class is able to take advantage of remedies that, as a practical
matter, will be unavailable or worth substantially less by the time this case could be
litigated to a final judgment,” noted the court document supporting the plaintiffs’ motion
for preliminary approval of the class action settlement. “Our expert on identity theft and
fraud protection has explained that credit monitoring services are most critical in the first
five years after the Anthem data breach, and the two years of free credit monitoring
provided by Anthem have recently expired. Similarly, changes to Anthem’s data security
practices will be most effective the sooner they are implemented.”
Anthem is the country’s second largest health insurer and in 2015 it was hit with a massive
data breach. The Anthem class action lawsuit alleged that Anthem failed to properly
encrypt its data even after being warned by federal agencies about the risk of keeping
highly valuable information unprotected.
Under the terms of the settlement, Anthem must secure its information and make specific
upgrades to its data security systems.
… The class action had been converted to multidistrict litigation; however, a federal
court judge trimmed claims against Anthem affiliates, including Blue Cross entities, after
determining they had no connection to the plaintiffs’ claims.
Anthem lost the bid to completely dismiss the case and a judge ordered the U.S.
government to produce documents related to a 2013 audit of Anthem’s security systems
earlier this year.

Consider the following questions:
•
•

What did the plaintiffs receive? What did the plaintiff’s attorneys receive?
How do you feel about this result?

By this point, you surely are asking yourself: Didn’t the regulators also get in on the Anthem action?
Of course they did (just like they also got in on the Equifax action).

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

107

Because Anthem was in the insurance business, a California state insurance regulatory agency
conducted an investigation. It took a considerably more-sympathetic view of the matter,
emphasizing state-actor responsibility for the breach and suggesting that there was little chance
Anthem could have long withstood the persistent efforts of a nation state to capture this data.

Is this inconsistent with the civil litigation result? If so, is that a policy problem, and what might
be done about it?

As for the FTC, it did not get involved. But because Anthem was involved in health matters,
another federal agency did: the Department of Health and Human Services (“HHS”). For a quick
glance at HHS’s role in this space, read the following excerpt (from this):
If you’re already following HIPAA compliance-related news, you’re probably already
familiar with the “Wall of Shame.” If you’re just getting started, read on. The HIPAA
Breach Notification Rule requires Covered Entities and Business Associates
to report HIPAA cyber security breaches of protected health information (PHI) to the U. S.
Department of Health and Human Services (HHS).
Breach means the acquisition, access, use or disclosure of protected health information
in a manner not permitted under the HIPAA Privacy Rule, which compromises the security
or privacy of the protected health information. HHS then investigates the breaches and
the outcome can range from minor corrective actions to big monetary fines.
But that’s not all. Under the HITECH Act passed in 2009, the Secretary of HHS must post a
list of breaches of unsecured protected health information affecting 500 or more
individuals. These breaches are posted online at the HHS’ website for the world to see.
This list is known in HIPAA circles as the “Wall of Shame.” The website allows the download
of the list into Microsoft Excel and includes information such as the name of the covered
entity responsible for the breach, when it was reported, the number of individuals
affected by the breach and brief summaries of the breach cases that OCR has
investigated and closed.
Breach reporting began September 23, 2009. As of July 19, 2019 there were 247 breaches
to date in 2019. Each breach representing the unauthorized disclosure of the PHI of at
least 500 individuals. At the conclusion of an investigation, a breach summary is made
available to the public via the OCRs Breach Reporting Portal. The following is an example
of a breach summary from AccDoc Solutions, outlining their 2018 hacking incident
exposing their servers:
“A business associate (BA), AccuDoc Solutions, Inc., discovered on September 29, 2018,
that an unauthorized user had gained access to a web server which contained the
electronic protected health information (ePHI) for seven of its covered entity (CE) clients,
affecting 2,652,537 individuals. While no data was exfiltrated, the ePHI that was
potentially exposed included demographic information, account balances, and
insurance policy information. In response to the breach, the BA terminated the
unauthorized user’s access and improved technical safeguards. The CEs provided
breach notification to affected individuals and the media. The BA provided breach
notification to HHS on behalf of six out of seven CE clients. One CE notified HHS on its
own. OCR obtained assurances that the BA implemented the corrective actions listed.”

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

108

D. Liability for Inadequate Disclosure of a Data Breach
The possibility of being sued for inadequate care, failing to live up to a promise, or deceptive
advertising all loom large when a company learns that it has been breached and that customer
or user data has been exposed. And that in turn creates an incentive for the company leadership
to proceed very carefully—and thus very slowly—in letting anyone know that the breach has
occurred. But there is a powerful consideration pushing in the exact opposite direction: all states
have laws compelling companies to disclose such breaches, and to do so rapidly.

Can you summarize the competing public-policy interests implicated by such laws, and how
you assess the balance between them?

Needless to say, we are not going to look at all the different state-breach-disclosure laws. Instead,
we’ll look at Texas law as an example. From the Texas Business & Commerce Code:
Sec. 521.053. NOTIFICATION REQUIRED FOLLOWING BREACH OF SECURITY OF
COMPUTERIZED DATA
…
(b) A person who conducts business in this state and owns or licenses
computerized data that includes sensitive personal information shall disclose any breach
of system security, after discovering or receiving notification of the breach, to any
individual whose sensitive personal information was, or is reasonably believed to have
been, acquired by an unauthorized person. The disclosure shall be made without
unreasonable delay and in each case not later than the 60th day after the date on
which the person determines that the breach occurred, except as provided by
Subsection (d) or as necessary to determine the scope of the breach and restore the
reasonable integrity of the data system.
(b-1) If the individual whose sensitive personal information was or is reasonably
believed to have been acquired by an unauthorized person is a resident of a state that
requires a person described by Subsection (b) to provide notice of a breach of system
security, the notice of the breach of system security required under Subsection (b) may
be provided under that state's law or under Subsection (b).
(c) Any person who maintains computerized data that includes sensitive
personal information not owned by the person shall notify the owner or license holder of
the information of any breach of system security immediately after discovering the
breach, if the sensitive personal information was, or is reasonably believed to have been,
acquired by an unauthorized person.
(d) A person may delay providing notice as required by Subsection (b) or (c) at
the request of a law enforcement agency that determines that the notification will
impede a criminal investigation. The notification shall be made as soon as the law
enforcement agency determines that the notification will not compromise the
investigation.
(e) A person may give notice as required by Subsection (b) or (c) by providing:
(1) written notice at the last known address of the individual;

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

109

(2) electronic notice, if the notice is provided in accordance with 15
U.S.C. Section 7001; or
(3) notice as provided by Subsection (f).
(f) If the person required to give notice under Subsection (b) or (c)
demonstrates that the cost of providing notice would exceed $250,000, the number of
affected persons exceeds 500,000, or the person does not have sufficient contact
information, the notice may be given by:
(1) electronic mail, if the person has electronic mail addresses for the
affected persons;
(2) conspicuous posting of the notice on the person's website; or
(3) notice published in or broadcast on major statewide media.
(g) Notwithstanding Subsection (e), a person who maintains the person's own
notification procedures as part of an information security policy for the treatment of
sensitive personal information that complies with the timing requirements for notice under
this section complies with this section if the person notifies affected persons in
accordance with that policy.
(h) If a person is required by this section to notify at one time more than 10,000
persons of a breach of system security, the person shall also notify each consumer
reporting agency, as defined by 15 U.S.C. Section 1681a, that maintains files on
consumers on a nationwide basis, of the timing, distribution, and content of the notices.
The person shall provide the notice required by this subsection without unreasonable
delay.
(i) A person who is required to disclose or provide notification of a breach of
system security under this section shall notify the attorney general of that breach not later
than the 60th day after the date on which the person determines that the breach
occurred if the breach involves at least 250 residents of this state. The notification under
this subsection must include:
(1) a detailed description of the nature and circumstances of the
breach or the use of sensitive personal information acquired as a result of the breach;
(2) the number of residents of this state affected by the breach at the
time of notification;
(3) the measures taken by the person regarding the breach;
(4) any measures the person intends to take regarding the breach after
the notification under this subsection; and
(5) information regarding whether law enforcement is engaged in
investigating the breach.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

110

Consider these questions:
• How certain must the entity be that a breach occurred?
• Precisely how quickly must the disclosure be made as a default matter?
• How does Section 521.053(d) potentially change that timeline?

The Texas Attorney General is responsible for filing civil suits to enforce Section 521.053, but note
that a Section 521.053 violation may also constitute a deceptive act for purposes of a private civil
suit under the Texas Deceptive Trade Practices Act.
As you might imagine, the patchwork quilt of disclosure laws around the various states (as well as
some cities) has led some to argue for Congress to impose a uniform national approach.

•

What are the pros and cons of one national standard?

Don’t forget: Some companies will be subject to foreign jurisdictions as well, and these may be
more demanding than American disclosure requirements. The European Union’s much discussed
“General Data Protection Regulation” (“GDPR”) is a particularly significant example you should
be aware of (though we are not studying its particular requirements in this class).
E. Shareholder Derivative Actions
Recall that in our generic scenario above, we noted the possibility that Company B has
shareholders who might sue it, assuming share prices dropped once the breach became public.
Such “shareholder derivative actions” arise frequently with publicly traded companies when those
companies experience any sort of significant reversal that might be attributed to bad decisionmaking by the company’s officers or board of directors.
F. Insurance
In any context in which entities and individuals can anticipate suffering a loss—whether the loss
be from damage to possessions or a person, or from at least some forms of legal liability—there is
a strong incentive to protect against the anticipated loss by purchasing an insurance policy.
Because insurers usually (though definitely not always) are at liberty to determine which sorts of
risks they will insure against, and subject to which conditions, the insurance industry in general is in
a powerful position to nudge or even compel certain behaviors (just think of the incentives for safe
driving that car insurance does or might generate). And thus, insurance has an important role to
play in relation to the general challenge of encouraging potential victims to engage in better
defense.
For a handy and accessible (and brief) introduction to the emerging cybersecurity insurance
market, read this excerpt from this CEIP report, “Addressing the Private Sector Cybersecurity
Predicament: The Indispensable Role of Insurance” (Nov. 2018), by Ariel Levite, Scott Kannry, and
Wyatt Hoffman:
The private sector is struggling to contend with the growing scope, scale, and complexity of
cyber risks to corporations’ finances, reputation, and even property. These risks cut across
multiple areas of business operations and permeate relationships with suppliers, customers, and
third parties. Most governments are by now aware that cyber threats can severely damage and
disrupt their economies and infrastructure, and many invest significant effort and resources to

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

111

confront this danger. Yet virtually all face serious bandwidth limitations in addressing cyber
threats to private entities. Concerns over potential escalation or blowback if they pursue or
retaliate against foreign hackers, including potential states or proxies, further dampen
governments’ enthusiasm for defending the private sector. Furthermore, those governments that
seek to address private sector cyber vulnerabilities face serious pushback against onerous
regulations and reservations about creating a moral hazard if they assume responsibility for
protecting the private sector. These reasons and others have made a governmental solution to
this worsening private sector predicament unsatisfactory—a situation that is unlikely to
fundamentally change for the foreseeable future.
Faced with this sobering reality, the more resourceful and sophisticated private sector entities
are scaling up their own efforts to address cyber threats. In addition to a range of security
measures, many have turned increasingly to the risk challenging mechanism offered by cyber
insurance policies. Yet the cyber insurance coverage presently available provides only a limited,
uncertain, and ad hoc solution. The insurance industry harbors far greater potential to address
the cybersecurity challenge. Historically, insurance has played a crucial role in understanding,
managing, and mitigating the risks arising from emerging domains of human activity, particularly
in the context of evolving technologies. This holds true for cyberspace, where insurance has the
potential to assume a more fundamental role in reshaping the risk landscape. While this
potential has largely gone unexplored, its historical track record in other domains suggests that
the insurance industry could perform six core cyber risk mitigation functions: (1) engineering risks,
(2) channeling corporate risk, (3) managing systemic risks, (4) harnessing collective security
insights, (5) shaping broader risk trends, and (6) harmonizing risk-related standards and practices
internationally.
The current state of cyber insurance remains far from the ideal role envisioned here. This paper
analyzes the range of barriers that stand in the way of a properly functioning cyber insurance
market—including practical, technical, operational, and strategic challenges, within and
outside the insurance industry—and explores a series of individual and complementary efforts by
the insurance industry, governments, vendors of information and communications technologies
(ICTs), and other key stakeholders in the private sector toward realizing the full potential of
insurance to reshape the risk environment. Cyber insurance will ultimately be indispensable in a
broader solution to the escalating cyber risk challenge. Harnessing its full potential will be
imperative not only for managing corporate cyber risks, but for preventing potential systemic
cyber incidents of growing concern for governments and the private sector alike.

•
•

Some say that insurance companies are the key to systematically improving
cybersecurity defenses. How so?
What obstacles appear to lie in the way of that ambition?

G. Contract Terms
When an insurer insists upon certain cybersecurity-related measures as a condition of coverage,
that is an example of using contact leverage. But insurers are by no means the only ones who
might choose to use that leverage for this purpose. In fact, private sector actors increasingly often
insist upon certain steps as a contract condition, particularly in contexts involving professional
services (e.g., with law firms) or supply chains. While flowing from disaggregated individual selfinterest rather than top-down government policy, this phenomenon has considerable potential to
generate systematic improvements in the overall level of cybersecurity preparedness.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

112

That said, there are times when the government itself can use contract leverage toward this same
end—that is, not just to protect itself (we’ll see that later, when we reach the subunit on
government efforts to improve its own defenses) but also to have a larger pro-defense effect.
Here’s an example from 2018 involving an attempt by the government to leverage contracting
power to keep certain private entities from using the antivirus products and other services of
Kaspersky Lab (a Russia-based AV vendor that once had a substantial share of the US market, and
still has a large global presence):
The government is seeking to eliminate all traces of cybersecurity firm Kaspersky Labs
from federal systems, issuing a new interim rule in the June 15 Federal Register to extend
the governmentwide ban to contractors.
The rule, issued by the General Services Administration, the Department of Defense and
the National Aeronautics and Space Administration, amends the Federal Acquisition
Regulation to require that all contracts and solicitations finalized after July 16, 2018,
include language prohibiting the presence of Kaspersky hardware, software and
products.
The rule applies not just to federal contracts but also smaller "micro" purchases and the
purchase of commercial off the shelf items, which are often exempt from many
contracting regulations. The notice states that the interim rule was issued without prior
opportunity for public comment due to "urgent and compelling reasons."
"While the law does not specifically address acquisitions of commercial items, including
COTS items, there is an unacceptable level of risk for the Government in buying
hardware, software, or services developed or provided in whole or in part by Kaspersky
Lab," the notice reads. "This level of risk is not alleviated by the fact that the item being
acquired has been sold or offered for sale to the general public…nor by the small size of
the purchase."
The Department of Homeland Security and Congress both took steps last year to ban
federal agencies from using of Kaspersky software and products. But it has always
been less clear to what extent those restrictions might apply to contractors, and whether
such prohibitions would extend only to government-supporting systems or throughout
contractors' entire networks.
The new rule not only prohibits contractors from using Kaspersky products and services in
federal systems, but they must also report discovery of such products and services
discovered during the performance of contract work. The ban extends down to
subcontractors.
Shortly after DHS issued its ban, Michael Duffy, branch chief for the DHS Office of
Cybersecurity, told reporters that when it came to contractors, the department was
referring to Circular A-130 guidance and indicated that it would be left up to individual
agencies to manage their own risk in the contracting space.
"What we've tried to do is have agencies determine the risk themselves, versus us driving
all that action," Duffy said.
However, Secretary of Homeland Security Kirstjen Nielsen told Congress in May that
subsequent investigation revealed many contractors were not even aware they had
Kaspersky software embedded on their systems. Nielsen said her department was

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

113

exploring ways to allow for the suspension of contracts from vendors who relied on the
company's code or products.
"It has to be that we can pause and turn off contracts the moment we have a concern,"
Nielsen said. "If someone's been hacked, if someone is vulnerable or someone is using
software that we know will put us at risk."
The move is the latest blow to Kaspersky Labs, after a pair of lawsuits challenging the
government ban were dismissed in U.S. court and the European Union passed a
motion calling for a similar ban throughout its institutions, saying the company's products
are "confirmed as malicious."
For its part, the company and its founder Eugene Kaspersky have consistently denied any
involvement or assistance with Russian espionage. In an attempt to allay concerns about
customer data flowing to Russian servers, the company has started a transparency
initiative and announced it was opening up a new data center in Switzerland.
Kaspersky Labs is suspected of wittingly or unwittingly facilitating Russian espionage, but
thus far virtually all the evidence demonstrating that threat -- such as the theft of
classified files from an National Security Agency contractor's home computer -- have
come from media reports. The federal government has declined to confirm or deny
those reports. In court filings, government lawyers and DHS officials have claimed
the potential threat alone posed by Kaspersky Labs software and hardware is enough to
justify the ban on national security grounds.
That has led other cybersecurity vendors, such as Dragos CEO Robert M. Lee and
Rendition Infosec founder Jake Williams, to call on the government to release more
information about its case against the company. Earlier this week, former CIA Director
Michael Hayden told CyberScoop that he hopes the government has "a case rather
than a concern" against Kaspersky, because otherwise the move could lead to
retaliation against U.S. products and companies.

Can you identify limits to the utility of this approach, based on this example? What are the
pros and cons?

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

114

15. Facilitating Better Defense through Information Sharing (I)

Learning Objectives
•
•
•
•

•

•
•
•
•

•
•
•
•
•

Understand that information sharing is a critical consideration for many security challenges,
with the relevant information ranging from highly-technical data that may be critical for
defense in specific instances to highly-generic intelligence about threat actor intentions
Be able to distinguish “cyber threat intelligence” and “indicators of compromise”
Be able to explain why private actors might be reluctant to share information with each other,
why government entities might be reluctant to do the same, and why the same also might be
true as between the public and private sectors
Understand the “proprietary model” of information sharing: there is a vast universe of private
companies that sell products and services relating to cybersecurity (we’ll call them vendors),
and understand that information-sharing (from the vendor to the client) often is an essential
element of those relationships
Bearing this in mind, be able to explain why a vendor ever would “go public” with an
announcement revealing important cyber threat intelligence (hint: consider factors including
efforts to convince customers of the threat and of the skills of the vendor, but also ponder how
it would look if society writ large suffered significant harms as a result of some exploit that was
known to a specific vendor but not shared with others).
Understand what Virus Total does, and appreciate that it is providing an important informationpooling service for the public without a government having to create or compel such a
capability
Appreciate why private companies that could compete with each other in terms of having
unique access to threat intelligence would instead share that information with each other,
competing on other grounds instead
Understand how Cyber Command’s disclosure of Russian government malware, via VT,
constitutes both (i) promotion of defense via information-sharing and (ii) affirmative disruption
of adversary capabilities
Appreciate that in any defense-oriented disclosure setting, the first step generally is to disclose
privately to the relevant vendor (in order that they might mitigate the problem before it
becomes public). Public disclosure is a second step, carried out either to force the vendor to
act or, if the vendor has now acted, to spread awareness of a threat (and, hopefully, the
mitigation for that threat).
Understand how Project Zero and Zero Day Initiative differ from VT, and from each other
Be able to articulate the difference between Project Zero and the “insecurity industry,” and
the arguments for and against the latter
Be able to explain the utility of MITRE’s “ATT&CK” typology
Be able to explain the utility of MITRE’s “Common Vulnerabilities and Exposures” (CVE)
database
Be able to explain the utility of “ISACs,” “ISAOs,” and the Cyber Threat Alliance

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

115

Consider for a moment the idea of “public health” policy—that is, the important set of goals
associated with minimizing and mitigating disease and injury on a systematic basis. As with
cybersecurity, a wide variety of both public and private actors seek to promote public health.
And as with cybersecurity, those actors employ many different tools. Some of these tools are
familiar to us from the cybersecurity setting, in fact; regulations, for example, play a key role in
promoting public health. And so, we might take the comparison a bit further, using the familiar
public-health model as a way to appreciate another parallel with cybersecurity policy: facilitation
of information-sharing as a means to promote safety.
Some amount of information-sharing will occur without external interventions by public or privatesector actors, of course. But the “natural” level of such sharing may be suboptimal (too limited,
too slow, too confusing, too inaccurate, etc.) for any number of reasons. And if that is the case,
then there is an argument for someone to take steps to improve things from that baseline level. In
the public-health setting, we find governmental and international entities like the Centers for
Disease Control and the World Health Organization which do this sort of thing, as well as an array
of private sector actors (including both non-profit and for-profit entities). In various ways, these
actors develop, curate, and disseminate a wide array of useful information, ranging from highly
technical information to “best practices” and procedures.
So too with cybersecurity. That is, an important part of cybersecurity policy is the facilitation of
information-sharing intended to facilitate and promote defense. Our goal in the next two classes
is to become better acquainted with some of the key information-sharing actors and activities,
and then to examine an important piece of legislation that attempts to prune away legal
disincentives to information sharing.
A. What Information Might We Want to Share?
There are many possibilities. Let’s start with the sharing of “threat intelligence.” Note that this is a
term of convenience (the meaning of which can vary from audience to audience) rather than a
term of art (with a well-settled meaning and scope). That caveat aside, what is the general idea?
For starters, threat intelligence includes “Indicators of Compromise” (aka “IOCs”). This is a
shorthand for the idea that there are technical signatures and other objective indicia that might
be useful as a basis for detecting unauthorized activity in a system. This could be, for example, a
signature element of an exploit, the fact that a system has a particularly important vuln, the URL
of a known botnet command-and-control server, and so forth; the common idea is that the
information is something one can search for in a scalable way, and that it is correlated with
malicious activity.
For at least some people, threat intelligence has a broader scope than just IOCs. That is, the
phrase might also encompass all sorts of additional, useful information, some of it technical (for
example, details about a newly discovered vulnerability or newly circulated patch) and some of
it otherwise (for example, information about the capabilities, motives, intentions, or characteristic
tactics, techniques, and procedures of potentially hostile entities or individuals).

Be prepared to identify and distinguish these categories, and to explain why sharing
information of each kind can be helpful for improving defense.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

116

Threat intelligence is not the only relevant category of information we might hope to spread as a
means to boost cybersecurity on a widespread basis. We might also want to spread knowledge
of what we might call “effective practices” or “best practices.”
The idea here is straightforward: we want as many individuals and organizations as possible to at
least be aware of optimal policies, practices, techniques, or procedures, just as we do in the
public-health setting (just think of the efforts made to encourage people to wash their hands,
cover their sneezes, get flu shots, quit smoking, etc.). Sometimes we go further, of course, actually
compelling adoption of such practices (just think of the FTC’s current attempt to revise the G-L-B
Act Safeguards Rule in order to require, among other things, the use of multi-factor authentication
in some circumstances). But here we are talking about the less intrusive step of simply increasing
the chance that someone will adopt such measures voluntarily.
This raises a question: If a practice is desirable, why not always go with mandatory rules rather
than merely helpful advisories? First, sometimes the case for mandating use of a particular
measure just isn’t clear, as when the measure entails offsetting costs that might in some cases
outweigh the benefits. In such circumstances, promoting awareness of the measure helps
individuals and organizations make their own judgment about that cost-benefit tradeoff.
Second, even if the measure might be worthy of a mandate, there may be any number of reasons
why it is not currently possible to get Congress or a relevant agency to take that particular step.
Merely sharing information about the measure normally will not require anything like the same
degree of political will. Indeed, as we will see below, it may not require government intervention
at all.

Be able to explain how mandatory rules and informational advisories relate to each other,
and why the former is generally more difficult to employ than the latter.
B. Why is Information-Sharing Difficult, in Theory?
Information-sharing can be conducted on a government-to-government, government-to-private,
private-to-government, and private-to-private basis. Each dynamic presents its own challenges,
giving rise to the possibility that we might not get sufficient sharing, on a systematic basis, without
interventions.

Consider these questions:
• Why might one government entity be reluctant to share information with another?
• Why might the government be reluctant to share with the private sector?
• Why might the private sector be reluctant to share with the government?
• Why might one private sector entity resist sharing with another?
• Do your answers depend on which type of information is at issue?

C. Key Information-Sharing Institutions
Let’s now have a look at some of the institutions and systems involved in promoting informationsharing relating to cybersecurity. What follows below is not meant to be comprehensive, by any
stretch. That said, this selective survey will give you a feel for some of the key systems and
institutional players, while underscoring that much of the work under this heading is carried out
through the private sector.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

117

Security Vendors:
We will start by observing that there is a large and dynamic “security vendor” community
consisting of an array of for-profit businesses that provide various cybersecurity-related products
and services. Of course, one must pay to get the benefits of these products and services in most
circumstances, so most of the security benefits that vendors provide do not properly qualify for
discussion under the heading of information-sharing. But vendors frequently do provide certain
security-related information on a free and open basis, as when companies publish special
“reports” identifying newly discovered malware campaigns.

Can you explain why a for-profit enterprise would publish such a report?

VirusTotal:
VirusTotal is a company founded in Spain in 2004, later acquired by Google, and now operated
by Chronicle (a fellow subsidiary of Google’s parent entity, Alphabet). The basic idea is simple:
VirusTotal aggregates the capabilities of a large number of antivirus and URL/domain blacklisting
companies, and provides a user-friendly way to check files against the sum of their capabilities.
The value proposition for users is obvious enough, but what’s in it for all those companies? Well,
they get to see the results too, and thus can improve their own individual capabilities. It would
not work if all those companies still competed (as they used to) primarily on the basis of having
exclusive, propriety databases of threat indicators, but these days the bigger companies mostly
embrace a model of open sharing of such information while competing based on other
considerations. That’s a big win for the public at large, and VirusTotal is a notable mechanism for
transmitting the resulting benefits in a user-friendly way.

Can you describe how this shift is analogous to public health and pharmaceuticals?
For a more detailed explanation of what one can do with VirusTotal, and how the communitygood model of information-sharing about threat indicators can be used as an instrument of
statecraft, read the following excerpt from a 2018 article at Motherboard:
This week, US Cyber Command (CYBERCOM), a part of the military tasked with
hacking and
cybersecurity
focused
missions,
started
publicly
releasing
unclassified samples of adversaries’ malware it has discovered. CYBERCOM says the move
is to improve information sharing among the cybersecurity community, but in some ways
it could be seen as a signal to those who hack US systems: we may release your tools to
the wider world. “This is intended to be an enduring and ongoing information sharing effort,
and it is not focused on any particular adversary,” Joseph R. Holstead, acting director of
public affairs at CYBERCOM told Motherboard in an email.
On Friday, CYBERCOM uploaded multiple files to VirusTotal, a Chronicle-owned search
engine and repository for malware. Once uploaded, VirusTotal users can download the
malware, see which anti-virus or cybersecurity products likely detect it, and see links to
other pieces of malicious code. One of the two samples CYBERCOM distributed on Friday
is marked as coming from APT28, a Russian government-linked hacking group…also known
as … Fancy Bear. …CYBERCOM announced its new initiative on Monday, and uploaded
its first two samples on the same day.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

118

What do you make of CYBERCOM’s decision to burn Russian tools via VirusTotal?
Project Zero:
Project Zero is part of Google. Here is a recent account, again from Motherboard:
Ever since Project Zero was announced in 2014, these hackers have taken apart software
used by millions of people—and predominantly written by other company’s engineers—
with a mission to “make zero-day hard.” …
In five years, Project Zero researchers have helped find and fix more than 1,500
vulnerabilities in some of the world’s most popular software, according Project Zero’s own
tally. In Apple products, Beer and his colleagues have found more than 300 bugs; in
Microsoft’s products they found more than 500; in Adobe's Flash, they found more than
200. Project Zero has also found critical issues in CloudFlare, several antivirus apps,
and chat apps such as WhatsApp and FaceTime. A Project Zero researcher was also part
of the group who found the infamous Spectre and Meltdown flaws in Intel chips.
These numbers show Project Zero has had a massive impact on the security of devices,
operating systems, and applications used by millions of people every day.
For Google, these disclosures give the internet giant good publicity by showing how much
the company cares for the security of not just its users—but everyone else too. In
assembling one of the most elite hacking teams on the planet, Google is messaging to its
customers that it takes security very seriously. Along the way, Google has given itself an
excuse to probe its competitors products and software, doubtlessly learning from others'
security mistakes. Project Zero has been able to poke holes in the bulletproof mystique of
the iPhone's security, which is widely believed to be the hardest consumer device to hack.
In doing so, Google is able to insert itself into conversations it might not otherwise be a part
of.
Regardless of Project Zero's true mission, there’s no doubt that the team has had a
profound influence on the cybersecurity industry in the last five years.
“Without this level of technical detail in the public eye, defenders don't stand a chance.”
For one, Project Zero has normalized something that years ago was more controversial: a
strict 90-day deadline for companies that receive its bug reports to patch the
vulnerabilities. If they don't patch in that time frame, Google drops the bugs itself.
Microsoft, in particular, was not a fan of this policy at the beginning. Today, most
companies that interact with Project Zero respect that 90-day deadline as an industry
standard, a tidal change in the always controversial debate on the so-called “responsible
disclosure”—the idea that security researchers who find vulnerabilities should first disclose
them to the affected company, so that it can fix them before the bugs are exploited by
hackers. According to its own tally, around 95 percent of bugs reported by Project Zero
get patched within that deadline.
“People looked at the way the wind was blowing and then decided that—maybe just
maybe— instead of creating a fuss, creating a fix within 90 days was just easier,” said Chris
Evans, Project Zero’s original team leader.
But perhaps no accolade is more significant than how much people on the other side of
Project Zero’s fence, whom Evans would call the “insecurity industry,” hate the Google

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

119

hackers. This “insecurity industry” is made of companies like Azimuth Security and NSO
Group, government contractors whose job is to find bugs and write exploits. But, instead
of reporting the vulnerabilities to the companies who own the software, these companies
sell them to governments who turn them into tools to hack and surveil targets.
“Fuck those guys,” said a researcher who works for a company that does offensive security,
referring to Project Zero. “They don’t make the world safer.”
The researcher, who spoke on condition of anonymity because they are not allowed to
talk to the press, said that zero-day vulnerabilities are sometimes used to go after terrorists
or dangerous criminals. So when Project Zero kills those bugs, it may be killing tools used by
intelligence agencies to go after the bad guys, according to the researcher.

Consider these questions:
• Can you explain how this activity differs from VirusTotal?
• What are the pros and cons of this model?

Also check out Zero-Day Initiative here:
The Zero Day Initiative (ZDI) was created to encourage the reporting of 0-day
vulnerabilities privately to the affected vendors by financially rewarding researchers. At
the time, there was a perception by some in the information security industry that those
who find vulnerabilities are malicious hackers looking to do harm. Some still feel that way.
While skilled, malicious attackers do exist, they remain a small minority of the total
number of people who actually discover new flaws in software.
Incorporating the global community of independent researchers also augments our
internal research organizations with the additional zero-day research and exploit
intelligence. This approach coalesced with the formation of the ZDI, launched on July 25,
2005. The main goals of the ZDI are to:
… Encourage the responsible reporting of zero-day vulnerabilities through financial
incentives.
…
Today, the ZDI represents the world’s largest vendor-agnostic bug bounty program. Our
approach to the acquisition of vulnerability information is different than other programs.
No technical details concerning the vulnerability are sent out publicly until the vendor
has released a patch.
We do not resell or redistribute the vulnerabilities that are acquired through the ZDI.
Submitting through the ZDI program also relieves you from the burden of tracking the bug
with the vendor. We make every effort to work with vendors to ensure they understand
the technical details and severity of a reported security flaw, which leaves researchers
free to go find other bugs. We will let you know where things stand with all of your own
current cases with regards to vendor disclosure. In no cases will an acquired vulnerability
be "kept quiet" because a product vendor does not wish to address it.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

120

Interested researchers provide us with exclusive information about previously un-patched
vulnerabilities they have discovered. The ZDI then collects background information in
order to validate the identity of the researcher strictly for ethical and financial oversight.
Our internal researchers and analysts validate the issue in our security labs and make a
monetary offer to the researcher. If the researcher accepts the offer, a payment will be
promptly made. As a researcher discovers and provides additional vulnerability research,
bonuses and rewards can increase through a loyalty program similar to a frequent flier
program.
After an agreement has been reached for the acquisition of a researcher's bug report,
protection filters for Trend Micro customers are developed and deployed.
Simultaneously, the ZDI notifies the affected vendor so that they can develop a
vulnerability patch. The ZDI discloses any and all acquired vulnerabilities to product
vendors in accordance with our disclosure policy. This disclosure policy ensures that both
researchers and product vendors understand how ZDI handles vulnerability information.
This policy further reassures researchers that in no case will any of their discoveries be
"swept under the rug". It also reassures product vendors that there is a professional and
standard set of guidelines they can expect to be utilized throughout the disclosure
process.
Once a patch is ready from the affected vendor, the ZDI works collaboratively with the
vendor to notify the public of the vulnerability through a joint advisory that provides full
credit to the originating researcher, unless the researcher chooses to remain anonymous.
Before public disclosure of the vulnerability, we may choose to share technical details of
the vulnerability with other security vendors so they too may prepare an appropriate
security response for their customers. This practice allows us to facilitating the protection
of a customer base larger than our own.
In order to maintain the secrecy of a researcher's vulnerability discovery until a product
vendor can develop a patch, Trend Micro customers are only given a generic
description of the filter provided, not the vulnerability itself. Once details are made public
in coordination with the product vendor, an updated description is made public so our
customers can identify the appropriate filters that were protecting them. In other words,
while our customers will be protected from the vulnerability in advance, they will not be
able to discern the vulnerability itself.
…
This policy outlines how the Zero Day Initiative (ZDI) handles responsible vulnerability
disclosure to product vendors, Trend Micro customers, security vendors and the general
public. ZDI will responsibly and promptly notify the appropriate product vendor of a
security flaw with their product(s) or service(s). The first attempt at contact will be through
any appropriate contacts or formal mechanisms listed on the vendor Web site, or by
sending an e-mail to security@, support@, info@, and secure@company.com with the
pertinent information about the vulnerability. Simultaneous to the vendor notification,
protection filters may be distributed to Trend Micro customers through approved
channels.
If a vendor fails to acknowledge ZDI initial notification within five business days, ZDI will
attempt a second formal contact by a direct telephone call to a representative for that
vendor. If a vendor fails to respond after an additional five business days following the
second notification, ZDI may rely on an intermediary to try to establish contact with the

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

121

vendor. If ZDI exhausts all reasonable means in order to contact a vendor, then ZDI may
issue a public advisory disclosing its findings fifteen business days after the initial contact.
If a vendor response is received within the timeframe outlined above, ZDI will allow the
vendor 4-months (120 days) to address the vulnerability with a security patch or other
corrective measure as appropriate. At the end of the deadline, if a vendor is not
responsive or unable to provide a reasonable statement as to why the vulnerability is not
fixed, the ZDI will publish a limited advisory including mitigation in an effort to enable the
defensive community to protect the user. We believe that by taking these actions, the
vendor will understand the responsibility they have to their customers and will react
appropriately. Extensions to the 120-day disclosure timeline will not be granted.
If a product vendor is unable to, or chooses not to, patch a particular security flaw, ZDI
will offer to work with that vendor to publicly disclose the flaw with some effective
workarounds. In no cases will an acquired vulnerability be “kept quiet” because a
product vendor does not wish to address it. To maintain transparency into our process,
we plan on publishing a summary of the communication we've had with the vendor
regarding the issue. We hope that this level of insight into our process will allow the
community to better understand some of the difficulties vendors have when remediating
high-impact bugs. ZDI will make every effort to work with vendors to ensure they
understand the technical details and severity of a reported security flaw.
ZDI will formally and publicly release its security advisories on our Web site. Only advisories
listed on the website should be considered official ZDI advisories.

•

How does ZDI differ from the other programs we’ve examined?

The MITRE ATT&CK Matrix:
Now for something different. The MITRE Corporation is a large non-profit research enterprise that
houses a variety of federally funded research and development centers (FFRDCs). Put simply: it’s
a research institute that carries out government-funded projects. Among many other things, MITRE
has an array of cybersecurity-related programs. One of these—known as the ATT&CK Matrix—has
gained a remarkable following in recent years, and increasingly is used as a common touchstone
for understanding—and having a common way to talk about—the full spectrum of activities in
which a malicious actor might engage. Read this excerpt from this account:
MITRE started ATT&CK in 2013 to document common tactics, techniques, and procedures
(TTPs) that advanced persistent threats use against Windows enterprise networks. ATT&CK
was created out of a need to document adversary behaviors for use within a MITRE
research project called FMX. FMX’s objective was to investigate use of endpoint telemetry
data and analytics to improve post-compromise detection of adversaries operating
within enterprise networks. Much of that work is documented here: Finding Threats with
ATT&CK-based Analytics and the Cyber Analytics Repository.
Based on our research, we decided we needed a framework to address four main issues:
1. Adversary behaviors. Focusing on adversary tactics and techniques allowed
us to develop analytics to detect possible adversary behaviors. Typical

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

122

indicators such as domains, IP addresses, file hashes, registry keys, etc. were
easily changed by adversaries and were only useful for point in time
detection — they didn’t represent how adversaries interact with systems, only
that they likely interacted at some time.
2. Lifecycle models that didn’t fit. Existing adversary lifecycle and Cyber Kill
Chain concepts were too high-level to relate behaviors to defenses — the
level of abstraction wasn’t useful to map TTPs to new types of sensors.
3. Applicability to real environments. TTPs need to be based on observed
incidents to show the work is applicable to real environments.
4. Common taxonomy. TTPs need to be comparable across different types of
adversary groups using the same terminology.
We strongly believe that offense is the best driver for defense. An organization’s ability to
detect and stop an intrusion improves greatly by maintaining strong offense and defense
teams that work together. Within FMX, ATT&CK was the framework used to build adversary
emulation scenarios. The emulation team used these scenarios to inject real-world inspired
activity into the network. Then the team used the tests to verify that the sensors and
analytics were working to detect adversarial behavior within a production network. The
approach resulted in a rapid improvement in detection capability, and, most importantly,
in a measured and repeatable way.
ATT&CK became the go-to tool both for the adversary emulation team to plan events
and for the detection team to verify their progress. This was such a useful process for
MITRE’s research program that we felt it should be released to benefit the entire
community, so MITRE released ATT&CK to the public in May 2015. ATT&CK has since
expanded significantly to incorporate techniques used against macOS and Linux,
behaviors used by adversaries against mobile devices, and adversary strategies for
planning and conducting operations pre-exploit.

What is ATT&CK?
ATT&CK is largely a knowledge base of adversarial techniques — a breakdown and
classification of offensively oriented actions that can be used against particular platforms,
such as Windows. Unlike prior work in this area, the focus isn’t on the tools and malware
that adversaries use but on how they interact with systems during an operation.
ATT&CK organizes these techniques into a set of tactics to help explain to provide context
for the technique. Each technique includes information that’s relevant to both a red team
or penetration tester for understanding the nature of how a technique works and also to a
defender for understanding the context surrounding events or artifacts generated by a
technique in use.
Tactics represent the “why” of an ATT&CK technique. The tactic is the adversary’s tactical
objective for performing an action. Tactics serve as useful contextual categories for
individual techniques and cover standard, higher-level notations for things adversaries do

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

123

during an operation, such as persist, discover information, move laterally, execute files,
and exfiltrate data.
Techniques represent “how” an adversary achieves a tactical objective by performing an
action. For example, an adversary may dump credentials to gain access to useful
credentials within a network that can be used later for lateral movement. Techniques may
also represent “what” an adversary gains by performing an action. This is a useful
distinction for the Discovery tactic as the techniques highlight what type of information an
adversary is after with a particular action. There may be many ways, or techniques, to
achieve tactical objectives, so there are multiple techniques in each tactic category.

The ATT&CK™ Matrix
The relationship between tactics and techniques can be visualized in the ATT&CK Matrix.
For example, under the tactic Persistence (this is the adversary’s goal — to persist in the
target environment), there are a series of techniques including AppInit DLLs, New
Serviceand Scheduled Task. Each of these is a single technique that adversaries may use
to achieve the goal of persistence.

The ATT&CK Matrix is probably the most widely recognizable aspect of ATT&CK because
it’s commonly used to show things like defensive coverage of an environment, detection
capabilities in security products, and results of an incident or red team engagement.

Cyber Threat Intelligence
Another important aspect of ATT&CK is how it integrates cyber threat intelligence (CTI).
Unlike previous ways of digesting CTI that were used primarily for indicators, ATT&CK
documents adversary group behavior profiles, such as APT29, based on publicly available
reporting to show which groups use what techniques.
Usually, individual reports are used to document one particular incident or group, but this
makes it difficult to compare what happened across incidents or groups and come to a
conclusion on what types of defenses were most effective. With ATT&CK, analysts can

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

124

look across groups of activity by focusing on the technique itself. When deciding how to
focus defensive resources, analysts might want to start with techniques that have the
highest group usage.
Examples of how particular adversaries use techniques are documented in its ATT&CK
page, which represents that group’s procedure for using the technique. The procedure is
a particular instance of use and can be very useful for understanding exactly how the
technique is used and for replication of an incident with adversary emulation and for
specifics on how to detect that instance in use.

Where ATT&CK is Today
ATT&CK has expanded quite significantly over the past five years, from Windows to other
platforms and technologies. It’s in use by many different government organizations and
industry sectors, including financial, healthcare, retail, and technology. The public
adoption and use has led to significant contributions back to ATT&CK to keep it up-todate and useful for the community. We want to continue this trend, so MITRE has big
plans to keep growing ATT&CK to ensure its future as a valuable public resource.

Consider these questions:
• After perusing the site, can you sum up the role that the ATT&CK Matrix plays?
• Does this properly count as part of the information-sharing ecosystem?

Cyber Threat Alliance:
CTA shows us another model, one that might be described as a hybrid between the full
community-good model of VirusTotal and the proprietary model associated with private sector
security vendors. Here is how CTA sums up its origin and core function:
We were founded in 2014 through an informal agreement to share intelligence among
Fortinet, McAfee, Palo Alto Networks, and Symantec. They called this arrangement the
Cyber Threat Alliance, but CTA had no dedicated staff nor any legal paperwork. In 2015,
the companies developed a white paper on the Cryptowall Crimeware. The paper
garnered a lot of attention and showed the value of collaboration among the
cybersecurity community.
At this point, the companies realized that they were involved in something bigger. In order
to increase the impact across the ecosystem, CTA needed to scale. To achieve this, the
Founding Members decided to establish CTA as an independent organization and relaunch it in February 2017 at RSA. The revamped CTA now has dedicated staff, resources,
and a technology platform for sharing advanced threat data. As a result, CTA members
can all share timely, actionable, contextualized, and campaign-based intelligence that
can be used to improve their products and services to better protect their customers, more
systematically thwart adversaries, and improve the security of the digital ecosystem.
CTA has been growing rapidly and earning a positive reputation. To understand it better, consider
this account, from CTA itself, of the unusual role it can play:

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

125

On May 23, 2018, Cisco’s Talos Intelligence Group publicly exposed a new malware threat
they dubbed VPNFilter. VPNFilter is a sophisticated modular malware system targeting
networking equipment all over the world. This malware allowed for theft of website
credentials, collection of data, injection of malicious content into network traffic as it
passes through an infected device, and destruction of the infected device.
Earlier in May, VPNFilter had begun a large-scale infection of devices in Ukraine and
eventually targeted at least 500,000 network devices worldwide. This happened to be right
around the time of the one-year anniversary of NotPetya, the Ukrainian Constitution Day,
and the European Soccer Championship. The threat of a destructive attack timed with
any of these events forced Talos’ hand and pushed them to release all of the information
they currently had on the malware to the public, in coordination with law enforcement.
This is pretty typical for many cybersecurity companies. They are researching a threat and
eventually decide to expose it. However, Talos did something special that has the
potential to improve our cybersecurity over the long run. They informed fellow members in
the Cyber Threat Alliance of the threat of VPNFilter before they released it publicly. Why
would one company provide their competitors with advance notice of such a significant
malware release?
Talos realized that VPNFilter had the potential to be a massive problem for internet users
across the globe. If the destructive module of the malware was activated, it could cut off
internet access for millions of people. They also recognized that they needed assistance
in addressing the problem and informing the public of the risk. The devices that VPNFilter
targeted are on the perimeter of most organizations’ networks and difficult to defend,
typically do not have a host-based protection system, have hundreds of publicly known
vulnerabilities, and are difficult for organizations to patch. To quickly handle this threat, CTA
members would need to amplify Talos’ alert and spread mitigation information as quickly
as possible.
Talos leveraged CTA’s Algorithm & Intelligence (A&I) Committee to provide CTA members
with VPNFilter cyber threat indicators and defensive measures, including VPNFilter samples
and analytic findings. They also provided a briefing to members to answer questions and
engage on how to mitigate the threat. CTA members were then able to quickly perform
their own analysis to verify and validate Talos’ work and use that to develop protections
for their cybersecurity products.
When Talos released their blog at 9:00 am eastern time on May 23, CTA members already
had protections in place, defending and protecting their customers as quickly as possible.
This allowed our members to avoid the usual scramble and delay of trying to obtain new
malware samples, performing analysis, and developing protections when another
company publishes a significant report. CTA members, such as Fortinet, Symantec, Sophos,
Palo Alto Networks, McAfee, Juniper, and Rapid7, published their own findings and analysis
over the next few hours and days, amplifying the messaging. These blogs were collected
by CTA and published in a single location for the public to find information on VPNFilter.
CTA members continued to discuss and share information on VPNFilter within A&I meetings.
This included updates on victim telemetry, additional affected infrastructure, and new
insights on malicious modules. Talos provided public updates on VPNFilter on June
6 and September 27, and the malware samples and analysis were shared with CTA
members in advance. As before, CTA members provided additional analysis and
amplification of the warnings of VPNFilter to assist with mitigation.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

126

Impact and Assessment
Was this successful? As of the publication of this blog post, the destructive module of
VPNFilter was never employed. So that’s a good thing. Based on our collective visibility it
appears that VPNFilter activity has been severely degraded since the release of
information in May and operational coordination actions with law enforcement,
intelligence organizations, and CTA and its members. Talos has seen no signs of the actor
trying to reconnect with the devices that still have the Stage 1 malware, and most C2
channels for the malware have been mitigated. While it is highly unlikely that the highly
capable actor behind VPNFilter has stopped their activities, it does appear that they were
forced to abandon the VPNFilter framework due to these coordinated actions.
One of the other effects of Talos’ early sharing and CTA’s response has been an increased
willingness of CTA members to share information on significant malicious cyber activity with
each other before the release of details publicly. These disruption activities seek to prevent
actors from succeeding in their goals and increase the costs of their malicious cyber
activities. By coordinating ahead of release on significant issues, CTA members leverage
their data, analysis, and cybersecurity products to expose the activity, prevent additional
harm, and mitigate any of the activity’s effects as early as possible. In the months since
VPNFilter, Symantec (Thrip, Leafminer), Fortinet (Emotet), Sophos (SamSam), and Palo Alto
Networks (Gorgon Group, KONNI, and DOGCALL) have all provided CTA members with
early access to malicious cyber activity analysis and samples. In fact, this early release
momentum continues today with Symantec’s release of information and analysis on a new
threat actor they call Gallmaker. CTA encourages our members to continue this type of
sharing moving forward.
The members of CTA seek to work together in good faith to share cyber threat intelligence
to disrupt malicious actors and protect their customers. We share cyber threat indicators
and defensive measures for the purposes of improving defenses against advanced cyber
adversaries across member organizations and their customers, to advance the
cybersecurity of critical information technology infrastructure, and to increase the security,
availability, integrity, and efficiency of information systems. We recognize that not every
cybersecurity provider has the same visibility into the threat, and the only way we can
expand our knowledge base is to share with one another and then act for the greater
good. We are all stronger when we work together. As we move forward, the early sharing
demonstrated through VPNFilter provides just a glimpse of the potential impact that CTA
can have to improve the overall security of the internet.

Can you articulate the value proposition CTA is describing in this story?

ISACs and ISAOs
CTA is not the only, or the first, model for cross-company collaborations involving cybersecurity
information-sharing. “ISACs” and “ISAOs” are similar. The following account (from an ISAO known
as the Advanced Cyber Security Center (ACSC)) provides a handy introduction:
When it comes to sharing cybersecurity information, it can get complicated fast.
Organizations have to navigate a tight workforce, conflicting laws and regulations, and
prioritize protections within their organizations -- often on penny-pinching budgets. Public
entities like the Federal Bureau of Investigation (FBI) and the Department of Homeland
Security (DHS) strive for better engagement with corporations to improve collaboration

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

127

and communication but concerns over sharing sensitive information or giving competitors
insight into business operations limit collaboration.
In 2015, the White House addressed those hurdles with Executive Order 13691: Promoting
Private Sector Cybersecurity Information Sharing. … EO 13691 was designed to help fill the
need for security information sharing beyond federal agencies and to “encourage the
voluntary formation of [information sharing organizations], to establish mechanisms to
continually improve the capabilities and functions of these organizations, and to better
allow these organizations to partner with the Federal Government on a voluntary basis.”
Although the executive order provided a basis for DHS to support broadening the
ecosystem, these “voluntary” sharing organizations added a layer of complexity that
confused even the cybersecurity community. Information Sharing and Analysis Centers
(ISACs) and Information Sharing and Analysis Organizations (ISAOs) established by the
executive order differ in role and benefits but both are critically important to successful
collaboration. Below, we provide a short summary of how these types of information
sharing organizations operate. …
ISACs: Sector-Specific Collaboration
To address the need for better sharing of information about cyber risks and
preparedness, Presidential Decision Directive 63, signed in 1998, encouraged critical
infrastructure sectors to establish information sharing organizations. The directive
established clear responsibilities at the government level for building collaborations with
organizations to “serve as the mechanism for gathering, analyzing, appropriately sanitizing
and disseminating private sector information” to industry and the government. Therefore,
the ISACs aligned specifically with each individually designated critical infrastructure
sector. ISACs provide real-time threat and attack intelligence sharing, training and curated
reporting to their members, who may pay an annual fee depending on the market sector.
Information sharing through ISACs is usually protected by legal agreements that protect
against non-disclosure and attribution back to the reporting organization, providing some
protection for their members against inappropriate disclosure. In addition, the advent of
automated sharing platforms hosted by some ISACs can allow for consistent collaboration
between member organizations and some may be able to respond and share actionable
threat intelligence more quickly than the government. Many have also grown to reach
well beyond the US, building international membership opportunities.
ISAOs: Effective-Practice Sharing Networks
While ISACs covered the emerging information sharing needs of critical infrastructure
initially, the rapidly evolving cybersecurity landscape necessitated the need for Executive
Order 13691 encouraging ISAO development. … [T]o encourage innovative information
sharing…, “ISAOs may be organized on the basis of sector, sub-sector, region, or any other
affinity, including in response to particular emerging threats or vulnerabilities.” These new
information sharing organizations were also envisioned to be sector-agnostic, allowing for
membership to “be drawn from the public or private sectors, or consist of a combination
of public and private sector organizations.” Like ISACs, information sharing through ISAOs
may be protected by legal agreements that protect against non-disclosure and
attribution back to the reporting organization.
…. ISAOs have evolved to focus beyond threat sharing and towards effective-practice
sharing within a more geography-centric local community….

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

128

Task: Do some searching to see if you can identify at least three distinct ISACs or ISAOs. Come
to class prepared to name them, describe their particular areas of focus, and share anything
you could glean about the nature of their activities
• How, if at all, is the ISAC/ISAO model different from CTA?
• Can you articulate why some people are reluctant to see NSA involved in defenseoriented activity?
• What is the best response to such concerns?

At this point, you may have noticed that we have not yet turned our attention to some key
government institutions that play a direct role in promotion of information-sharing. We’ve saved
that for last on purpose, for the role played by DHS’s Cybersecurity & Infrastructure Security
Agency (CISA) goes hand-in-hand with a key statute that will require careful parsing. We’ll do all
of that below, in the next reading.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

129

16. Facilitating Better Defense through Information-Sharing (II)

Learning Objectives
•

•

•
•

•

•

Understand that DHS CISA has functions (in its Cybersecurity Division) that include promotion
of public-private information sharing, both in the form of narrative alerts/bulletins and
especially in the form of the Automated Indicator Sharing (AIS) system for real-time distribution
(and upload) of threat intelligence
Understand that NSA now has a “Cybersecurity Directorate” focused on promoting defense
not only of certain U.S. government systems but also those of private companies in the Defense
Industrial Base—and that the Directorate sometimes advances that mission by sharing cyber
threat intelligence (including public sharing that might include attributions of state
responsibility)
Homework: Playing the role of a staffer providing a memo, describe the array of options the
government has if it wants to disrupt the ability of a foreign adversary to make use of an exploit
With respect to the goal of promoting federal sharing of information with the private sector
(and state/local government), understand that the 2015 Act focused on solving the problem
of federal officials who might not be sure that such sharing was part of their organization’s
affirmative responsibilities—and be able to identify where and how the Act remedies that
problem.
Understand why the Act does not attempt to compel private sector entities to receive such
information, and why the Act in fact makes clear such entities cannot be held liable for
declining the opportunity.
With respect to the goal of promoting private-sector sharing of information with the federal
government, understand how the 2015 Act tries to prune away various disincentives including
lost intellectual-property protections, waiver of privileges, exposure to FOIA, and incurring civil
liability.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity
•

•
•

•

•
•

130

Understand that these aspects of the Act incurred substantial opposition from privacy
advocates, and be able to describe how the Act tries to ameliorate those concerns by limiting
the ways in which the federal government can use the information provided by the private
sector under the Act (in particular, be able to answer whether and when such information
can be used by law enforcement).
Understand why the Act does not attempt to compel private sector entities to provide such
information, and be able to discuss whether you think that should be changed.
Appreciate that the Act is not limited to information-sharing provisions, despite its title; be able
to describe how private-sector concerns about the impact of the Computer Fraud and Abuse
Act in self-defense settings led the Act’s authors to include additional provisions unrelated to
information sharing.
Be able to describe what the Act has to say about the defensive use of “monitoring” activities
occurring within one’s own system, and whether the CFAA otherwise would have been
violated by such activities.
Be able to describe how the Act defines “defensive measures,” and how this differs from the
“monitoring” scenario.
Be able to explain how the Act’s blessing of “defensive measures” relates to the scope of the
CFAA. In particular, be able to state and defend a view regarding whether the Act would
encompass scenarios including (i) beacons, (ii) backdoors, and (iii) destructive malware, and
whether the Act should be understood as making a meaningful change to the scope of
potential liability an entity would face under the CFAA for such measures.

In this class, we conclude our survey of key information-sharing actors, and then turn our attention
to an important 2015 statute designed to improve information-sharing by pruning away various
disincentives.
A. More Information-Sharing Institutions
The Cybersecurity Division at DHS’s Cybersecurity and Infrastructure Security Agency (CISA):
In addition to encouraging formation of ISACs and ISAOs, the federal government has taken
certain institutional-design steps in order to promote information sharing. Specifically, it has
charged a particular agency with this mission: the Cybersecurity and Infrastructure Security
Agency (CISA, pronounced “sis-uh”).
CISA is a component of the Department of Homeland Security (DHS). Previously known by the
much less evocative moniker, the “National Protection and Programs Directorate” (NPPD), CISA
has been growing rapidly both in stature and capability, and the recent name change was an
important symbolic marker of that success. CISA today encompasses several distinct functional
divisions, including not only its Cybersecurity Division but also its Infrastructure Security Division, the
National Risk Management Center, and the Emergency Communications Division. Our primary
concern is with the Cybersecurity Division.
What exactly does the Cybersecurity Division do? It has a number of distinct responsibilities. Some
of these are focused on improving the security of the federal government’s own systems. We will
read about that more soon enough. Others involve cybersecurity services CISA can provide on a
voluntary basis to state and local government entities and to certain private-sector entities,
services that range from risk-assessment and capacity-building to penetration testing and
assistance with incident response. We will table all of that for now, too, in order to stay focused
on the topic of information-sharing and CISA’s role in that setting.
As we noted earlier in this reading, there are several dimensions to information-sharing as an area
of cybersecurity policy. Ideally, there would be an efficient flow of useful information from the

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

131

federal government to the private sector, from the private sector to the government, and among
various private sector entities. A variety of obstacles historically have impeded these flows,
however, and thus a core challenge for CISA has been to develop useful mechanisms for
overcoming those obstacles as much as possible.
How to do that? CISA in recent years operationalized these functions primarily through its 24/7
watch-and-operations center known until recently as National Cybersecurity and
Communications Integration Center (NCCIC, pronounced “N-kick”). Since its establishment in
2009, NCCIC has served as a hub for information exchange, among other things. Those functions
continue today, though recent reshufflings of internal organizational labels suggest that it may be
best to eschew a focus on that precise label and to concentrate instead on simply understanding
the functions CISA performs in this area.
One notable example is the Automated Indicator Sharing (AIS) Program. AIS is a free service
consisting of a bi-directional information-exchange platform that facilitates real-time, automated
sharing of threat indicators between CISA and voluntarily-participating private-sector entities. The
basic idea is that a participating private-sector entity which identifies a threat indicator can
upload signatures to CISA at machine speed via AIS, and CISA can in turn use AIS to share those
signatures to all other participants in addition to using them for its own defensive purposes (note
how this is akin to, say, VirusTotal). CISA can originate the dissemination as well.
Separately, CISA promotes a distinct form of information-sharing by producing (and distributing
the old fashioned way) a variety of bulletins and technical advisories. Here’s a current list of them,
from CISA:
Subscriptions are available to all users for the following products:
•

Current Activity entries provide up-to-date information about high-impact types of
security activity affecting the community at large.

•

Alerts provide timely information about current security issues, vulnerabilities, and
exploits.

•

Bulletins provide weekly summaries of new vulnerabilities. Patch information is
provided when available.

•

Tips provide advice about common security issues for the general public.

•

Analysis Reports provide in-depth analysis on a new or evolving cyber threat.

•

Industrial Control Systems Alerts provide timely notification to critical infrastructure
owners and operators concerning threats or activity with the potential to impact
critical infrastructure computing networks.

•

Industrial Control Systems Advisories provide timely information about current
industrial control systems (ICS) security issues, vulnerabilities, and exploits

As we will soon explore in more detail, CISA also plays an especially important informationsharing role in the special context of private sector entities that constitute “critical infrastructure.”
We explore that topic separately below. For now, we will move on to close out our review of key
information-sharing actors by looking briefly to the National Security Agency (NSA).
NSA’s New Cybersecurity Directorate:
NSA is, of course, most famous for its role as the nation’s lead agency for collection and analysis
of “signals intelligence” (SIGINT). In practical terms, this means that NSA is in the business of
espionage targeting electronic communications, stored data, and so forth. At first blush, then, it

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

132

would seem we should not be talking about NSA at all, until Unit II of this course. But NSA also has
important protective functions related to cybersecurity. Who better to understand attackers’
capabilities, after all, than our own premier electronic espionage agency? While this protective
mission is largely a matter of protecting the government’s own systems (again, a topic we will
address in an upcoming class rather than here), there is an aspect of this protective mission that
also concerns private-sector entities with strategic significance and the broader public. That’s
why we are talking about it briefly here.
The organizational home for this function, within NSA, has undergone various name and
organizational-chart revisions in recent years. For a long period, it was embodied by the
“Information Assurance Directorate,” or IAD. After a complicated period of recent change, NSA
has recently reorganized again, and now we find this function in the newly christened
Cybersecurity Directorate. The general idea appears to be to maximize the effect of defensive
efforts—particularly with an eye towards preventing significant intellectual-property theft by other
states—by collocating a range of NSA capabilities (including collection capabilities, presumably)
and creating a mission-oriented team environment for them.
The head of CD, Anne Neuberger, has explained:
[O]ne of her directorate’s new goals is to provide more actionable threat intelligence at
the unclassified level so that partners, customers and private sector firms can actually reap
benefits in real-time. The NSA, she said, will strive to declassify and share threat intelligence
faster. . . .
The Cybersecurity Directorate’s early mission is to “prevent and eradicate threats” to
national security and weapons systems and the defense industrial base, which face
increasingly complex cyber threats from China, Russia, Iran and North Korea. . . .
One of the ways the Cybersecurity Directorate aims to do that is by producing “better
threat alerts with more context,” Neuberger said. The directorate released such
an advisory on Oct. 7, detailing to the public how multiple nation-state actors “have
weaponized” certain virtual private network vulnerabilities. The advisory included a list of
affected systems and recommended patches and other strategies to harden systems
against intrusion.

Can you relate this to the note above regarding USCYBERCOM’s contributions to VirusTotal?

Having described a variety of private and public actors who do important things to promote
information-sharing, we should now turn our attention to an issue that has greatly complicated
that project over time: How, if at all, should Congress intervene to support such efforts via
legislation intended to “prune” away disincentives to information-sharing?
B. What Do We Mean by “Pruning”?
In some situations, an entity might be willing (perhaps even eager) to pursue some particular
security measure, yet may be deterred from doing so by the potential applicability of a legal
constraint (criminal, civil liability, regulatory pressure, etc.). And that might be a good thing; the
legal constraint presumably serves some otherwise-desirable purpose, after all, and the resulting
benefits associated with that purpose might well outweigh the opportunity cost associated with
discouraging uptake of the security measure in question. But then again, the balance also might
cut the opposite way. If so, some “pruning”—that is, changes to the law so that it no longer will
discourage the measure—might be in order.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

133

After many years of debate, Congress in 2015 enacted a law designed to do just this in relation
to the circulation of cybersecurity-relevant information. The rest of this reading examines that
legislation.
C. The Cybersecurity Information Sharing Act of 2015
In 2015, Congress passed and President Obama signed into law the “Cybersecurity Information
Sharing Act of 2015.” Since that law has the same acronym as the newly renamed DHS agency
described above, one must now be careful and clear when referring to “CISA.” Here, I’ll refer to
it simply as the Act or the 2015 Act, in hopes of keeping things simple.
The full text of the 2015 Act can be found here, but for our purposes you should focus only on the
sections quoted in the text below and the questions that follow for each.
Definitions:
As an initial matter, read these two definitions from the statute. First, Section 102(6) defines “cyber
threat indicator” to mean information used to “describe or identify":
(A)

malicious reconnaissance, including anomalous patterns of communications that
appear to be transmitted for the purpose of gathering technical information
related to a cybersecurity threat or security vulnerability;

(B)

a method of defeating a security control or exploitation of a security vulnerability;

(C)

a security vulnerability, including anomalous activity that appears to indicate the
existence of a security vulnerability;

(D)

a method of causing a user with legitimate access to an information system or
information that is stored on, processed by, or transiting an information system to
unwittingly enable the defeat of a security control or exploitation of a security
vulnerability;

(E)

malicious cyber command and control;

(F)

the actual or potential harm caused by an incident, including a description of the
information exfiltrated as a result of a particular cybersecurity threat;

(G)

any other attribute of a cybersecurity threat, if disclosure of such attribute is not
otherwise prohibited by law; or

(H)

any combination thereof.

Second, Section 102(7) defines the term “defensive measure” as follows:
an action, device, procedure, signature, technique, or other measure applied to an
information system or information that is stored on, processed by, or transiting an
information system that detects, prevents, or mitigates a known or suspected cybersecurity
threat or security vulnerability … [but] does not include a measure that destroys, renders
unusable, provides unauthorized access to, or substantially harms an information system
or information stored on, processed by, or transiting such information system not owned by

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

134

…the private entity operating the measure … or …another entity or Federal entity that is
authorized to provide consent and has provided consent to that private entity for
operation of such measure.
Now we will turn to the key substantive provisions in the statute. As you will see, I’ve reordered
and grouped them in a way designed to highlight the distinct things Congress was trying to
accomplish.
Two Major Goals:
It helps to think of the 2015 Act as pursuing two overarching goals. First, it sought to increase the
flow of information between the government and the private sector (in both directions). Second,
it sought to increase the likelihood that private sector entities would feel free to use certain
defensive measures. Alas, the drafters did not organize the 2015 Act in a way that maps easily
onto that two-prong framework. Accordingly, I’ve excerpted the relevant sections of the Act,
below, in an order that should be easier for you to follow (as compared to the mind-numbing
effect of reading the sections in their original order).
Goal #1: Facilitate the Flow of Information between Government and the Private Sector
A major goal of the Act was to make it easier for the government to share certain information with
the private sector, and vice-versa. Section 103 addresses the former scenario, and Section 105
addresses the latter.
a. Section 103 (When the Federal Government Shares with Others)
(a)

[T]he Director of National Intelligence, the Secretary of Homeland Security, the
Secretary of Defense, and the Attorney General . . . shall jointly develop and issue
procedures to facilitate and promote
(1)

the timely sharing of classified cyber threat indicators [see definition below]
and defensive measures [see definition below] in the possession of the
Federal Government with representatives of relevant Federal entities and
non-Federal entities that have appropriate security clearances;

(2)

the timely sharing with relevant Federal entities and non-Federal entities of
cyber threat indicators, defensive measures, and information relating to
cybersecurity threats or authorized uses under this title, in the possession of
the Federal Government that may be declassified and shared at an
unclassified level;

(3)

the timely sharing with relevant Federal entities and non-Federal entities, or
the public if appropriate, of unclassified, including controlled unclassified,
cyber threat indicators and defensive measures in the possession of the
Federal Government;

(4)

the timely sharing with Federal entities and non-Federal entities, if
appropriate, of information relating to cybersecurity threats or authorized
uses under this title, in the possession of the Federal Government about
cybersecurity threats to such entities to prevent or mitigate adverse effects
from such cybersecurity threats; and

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity
(5)

135

the periodic sharing, through publication and targeted outreach, of
cybersecurity best practices that are developed based on ongoing
analyses of cyber threat indicators, defensive measures, and information
relating to cybersecurity threats or authorized uses under this title, in the
possession of the Federal Government, with attention to accessibility and
implementation challenges faced by small business concerns.

Be able to explain how the five subparts of Section 103 accomplish different things (note how
this exercise is similar to parsing the CFAA).
• What specific information-sharing obstacle do these subparts appear designed to
address? That is to say: In what sense might this be described as a “pruning”?
• Note that Section 103 does not compel private-sector entities to receive whatever
information the government is willing to provide. Why not take that further step?

Of course, the voluntariness of the system won’t seem authentic if entities could be sued,
somehow, for failing to participate.

Can you come up with an argument a plaintiff might make, along those lines?

To head off that prospect, Congress included the following language in Section 108:
(f)

Information Sharing Relationships.––Nothing in this title shall be construed–– . . . to
require the use of the capability and process within the Department of Homeland
Security developed under section 105(c).

(ii)

No Liability for Non-Participation.––Nothing in this title shall be construed to subject
any entity to liability for choosing not to engage in the voluntary activities
authorized in this title.

(k)

Federal Preemption.–– . . . This title supersedes any statute or other provision of law
of a State or political subdivision of a State that restricts or otherwise expressly
regulates an activity authorized under this title.

What work do these provisions do?

b. Section 105 (When Others Share with the Federal Government)
Section 105 is a very long and complicated provision. I’m going to quote from it selectively and
with extensive paraphrasing, to keep this readable and focused.
First, there are two subsections (105(a) and (c)) that combine to require the federal government
to take an important institutional step to facilitate the process of receiving information from others.
Specifically, these subsections require the government to rapidly develop a process for receiving
cyber-threat indicators and defensive measures provided by the private sector, with an emphasis
on speed, automation, and distribution within the federal government once received. So far so
good. But note that there was much anxiety, in some quarters, about this idea while the bill was

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

136

pending. Some felt it opened the door to a privacy problem, with the government potentially
obtaining personally identifiable information about customers, employees, and so forth.
Accordingly, a separate subsection—105(b)—requires that the process be developed in a way
that addresses such privacy and civil-liberties interests.
Note that you have seen the eventual result of Section 105, above, in the form of CISA’s programs
for information sharing. But there’s more, so let’s return to the details of the statute.
Congress anticipated that private sector entities might be reluctant to work with the government
in the form of information-sharing partnerships, but it did not go so far as to mandate such
cooperation. What it tried, instead, was to encourage private sector entities to participate in the
system by pruning away potential disincentives. Specifically, Section 105(d) provides a host of
protections, including but not limited to these three:
(1)

The provision of cyber threat indicators and defensive measures to the Federal
Government under this title shall not constitute a waiver of any applicable privilege
or protection provided by law, including trade secret protection.

(2)

[A] cyber threat indicator or defensive measure provided by a non-Federal entity
to the Federal Government under this title shall be considered the commercial,
financial, and proprietary information of such non-Federal entity when so
designated by the originating non-Federal entity or a third party acting in
accordance with the written authorization of the originating non-Federal entity.

(3)

[This one exempts the information shared by a private entity from disclosure by the
government when the government receives freedom-of-information requests].

Do you think this is adequate to encourage participation? If not, what else would you be
willing to try?

A separate policy challenge that emerged during the drafting of the 2015 Act concerned the
possibility that the government might obtain information from the private sector for cybersecurity
purposes, yet end up using the information for other purposes.

Is that a bad thing? Be able to advance at least one argument against this, and one in favor
of it.

At any rate, Congress decided to address this issue. It did so in a complicated way, however.
Subsection 105(d)(5) states that the information provided to the government through this
mechanism may only be used for:
(i)

a cybersecurity purpose;

(iii)

the purpose of responding to, or otherwise preventing or mitigating, a specific
threat of death, a specific threat of serious bodily harm, or a specific threat of
serious economic harm . . .;

(iv)

the purpose of responding to, investigating, prosecuting, or otherwise preventing
or mitigating a serious threat to a minor, including sexual exploitation and threats
to physical safety; or

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

(v)

137

the purpose of preventing, investigating, disrupting, or prosecuting [certain
offenses involving fraud, identity theft, espionage, censorship, and protection of
trade secrets].

Is that an adequate solution (assuming a solution was needed)?

That was not the only concern Congress tried to address in subsection 105(d)(5), though. Consider
this language:
Except as provided [below], cyber threat indicators and defensive measures provided to
the Federal Government under this title shall not be used by any Federal, State, tribal, or
local government to regulate, including an enforcement action, the lawful activities of
any [private-sector entity, except that such information can be used to inform regulatory
efforts intended to support prevention/mitigation of cybersecurity threats]

Think back to our unit on regulators.
• What sort of fears might a private-sector entity have that this language tries to
address?
• Does the language really address those concerns?

Next we will look at Section 104(c), titled “Authorization for Sharing or Receiving Cyber Threat
Indicators or Defensive Measures”:
(1)

In general.––Except as provided in paragraph (2) and notwithstanding any other
provision of law, a non-Federal entity may, for a cybersecurity purpose and
consistent with the protection of classified information, share with, or receive from,
any other non-Federal entity or the Federal Government a cyber threat indicator
or defensive measure.

This is followed (out of sequence) by 106(b), which provides:
No cause of action shall lie or be maintained in any court against any private entity, and
such action shall be promptly dismissed, for the sharing or receipt of a cyber threat indicator
or defensive measure under section 104(c) if . . . such sharing or receipt is conducted in
accordance with this title

Consider these questions:
• What legal obstacle does all this seem designed to prune?
• Does it succeed?

Goal #2: Remove Obstacles to Desirable Private-Sector Defensive Actions
Another major goal of the Act was to prune away the liability risks (real or perceived) that
Congress concluded might be deterring private-sector entities from engaging in certain desirable

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

138

activities (activities that are useful for defense in their own right, and that might generate
important information to be shared more broadly). Most of the relevant provisions, for purposes
of this goal, are found in Sections 104 and 106.
a. Making it Clear That Entities Can Monitor Their Own Systems
First, read Section 104(a):
Notwithstanding any other provision of law, a private entity may, for cybersecurity
purposes, monitor—
(A)

an information system of such private entity;

(B)

an information system of another non-Federal entity, upon the authorization and
written consent of such other entity;

(C)

an information system of a Federal entity, upon the authorization and written
consent of an authorized representative of the Federal entity; and

(D)

information that is stored on, processed by, or transiting an information system
monitored by the private entity under this paragraph.

Absent this provision, would such activity be illegal?

Now read Section 106(a):
No cause of action shall lie or be maintained in any court against any private entity, and
such action shall be promptly dismissed, for the monitoring of an information system and
information under section 104(a) that is conducted in accordance with this title.

Consider these questions:
• Are 104(a) and 106(a) duplicative?
• Note the language in 106(a) about “shall be promptly dismissed.” Is that unnecessary
given the prior clause stating that there shall be no cause of action?

b. Making it Clear Entities Can Do Other “Defensive” Things
Next up, consider Section 104(b), titled “Authorization for Operation of Defensive Measures.” [Tip:
go back and re-read the statutory definition of “defensive measures,” above, before reading
104(b)]
(1)

In general.––Notwithstanding any other provision of law, a private entity may, for
cybersecurity purposes, operate a defensive measure that is applied to—
(A)

an information system of such private entity in order to protect the rights or
property of the private entity;

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity
(B)

an information system of another non-Federal entity upon written consent
of such entity for operation of such defensive measure to protect the rights
or property of such entity; and
an information system of a Federal entity upon written consent of an
authorized representative of such Federal entity for operation of such
defensive measure to protect the rights or property of the Federal
Government.

(C)

(2)

139

Construction.––Nothing in this subsection shall be construed––
(A)

to authorize the use of a defensive measure other than as provided in this
subsection; or

(B)

to limit otherwise lawful activity.

Consider these questions:
• What activities would 104(b) encompass beyond the “monitoring” authorized by
104(a) and 106(a)?
• Imagine that a company creates a trap: a file meant to be attractive to an intruder,
but includes within it malware that will, when opened, attempt to:
o (a) communicate with the company to reveal its location,
o (b) same as (a) but also create a backdoor through which the company can
then access the system where the file is found, or
o (c) delete all data on the system where it currently resides.
• Would any of those options be permissible under 104(b)?

c. More Pruning
Let’s conclude with a look at two further pruning provisions.
Section 106(c) adds:
Nothing in this title shall be construed . . . to create . . . (A) a duty to share a cyber threat
indicator or defensive measure; or . . . a duty to warn or act based on the receipt of a
cyber threat indicator or defensive measure

What liabilities does this guard against, and is it necessary?

And then we have Section 104(e):
[I]t shall not be considered a violation of any provision of antitrust laws for 2 or more private
entities to exchange or provide a cyber threat indicator or defensive measure, or
assistance relating to the prevention, investigation, or mitigation of a cybersecurity threat,
for cybersecurity purposes under this title.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

140

Why might that have seemed necessary?

D. Epilogue
The 2015 Act has now been on the books for a while, and we are beginning to learn how it is
working in practice. This 2018 story sounded a negative note, suggesting that relatively few
companies had signed up to participate in CISA’s AIS system:
More than two years after Congress passed a landmark bill incentivizing companies to
share with the government how and when malicious hackers are trying to penetrate their
computer networks, only six companies and other non-federal entities are sharing that
data, according to figures provided to Nextgov.
That’s compared with about 190 such entities and about 60 federal departments and
agencies that are receiving cyber threat data from Homeland Security’s automated
indicator sharing program, a Homeland Security official told Nextgov.
That low figure for private-sector participation is an additional blow to the program, which
has struggled to provide companies and government agencies with the sort of actionable
cyber intelligence that was promised by the Cybersecurity Act of 2015.
“CISA clearly hasn’t lived up to the full potential that I and many of my colleagues had
hoped and wanted it to,” said Rep. Jim Langevin, D-R.I., co-founder of the Congressional
Cybersecurity Caucus and a strong supporter of the bill when it passed.
CISA stands for the Cybersecurity Information Sharing Act, a major component of the
Cybersecurity Act of 2015, which is often used as shorthand for the full bill.
Langevin had hoped that CISA would inspire several thousand companies or more to
share threat information by this time, he said. He’d hoped that far more would be receiving
the data—at least all of the Fortune 5,000.
But, more than two years later, only six non-federal organizations have followed through
on sharing their own data.
If more companies don’t begin sharing cyber threat information, he said, the government
should consider mandating cyber information sharing, through regulation or legislation—a
shift that’s unlikely to be popular with the regulation-averse Trump administration.
“We need to get realistic about the fact that public-private partnerships haven’t yet borne
the kind of fruit that we want,” Langevin said. “Public-private partnerships are preferable
but, at some point, good intentions will only get us so far.”
Sen. Ron Wyden, D-Ore., who opposed CISA over privacy concerns, also urged turning to
mandates rather than voluntary partnerships with business.
“The immunity this misguided law gave to America’s most powerful corporations appears
to be far less useful for cybersecurity than its congressional proponents claimed,” Wyden
said. “Instead of weakening privacy protections for Americans’ personal information, it
would have been more productive for Congress to mandate strong encryption and other
common sense cybersecurity best practices.”

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

141

Rep. Dutch Ruppersberger, D-Md., a co-sponsor of CISA, is trying to schedule a briefing
with the House Appropriations Committee to discuss how Homeland Security can boost
private-sector participation in the program, a spokeswoman told Nextgov.
“Obviously, we think six non-federal entities is unacceptable, and we know the
department isn’t happy with that number, either,” the spokeswoman said.
During the briefing, Ruppersberger wants Homeland Security officials to “outline their
game plan on how to bring this number up and provide better context regarding these six
companies,” the spokeswoman said.
Ultimately, she said, “we need the private sector to step up and contribute more, but we
have to make it easier, quicker and more fulfilling for them, too.”
The low figure for active participation in Homeland Security’s indicator sharing program
comes after an earlier inspector general report dinged the department for flooding
recipients with information but not giving them enough context to figure out what was
important.
In one case, a federal agency received 11,447 cyber threat indicators from Homeland
Security in 2016 and only two or three of them were actually useful, the inspector general
said.
Rep. Bennie Thompson, D-Miss., ranking member on the Homeland Security Committee,
urged Homeland Security to “improve the timeliness and quality” of the information it
shares to bolster private-sector participation. He also said the private sector “needs to step
up” and warned that “information sharing is not a one-way street.”
Information Sharing for Collective Defense
CISA, which failed to pass in two successive Congresses before finally becoming law in
2015, promised liability protections to companies if they shared cyber threat indicators with
the government and with each other.
The law didn’t protect companies from being sued if they were breached by hackers, but
it barred customers from suing the company merely for sharing their information with the
government.
The idea was that the government would organize and prioritize all that threat information
from companies, combine it with the government’s own store of threat data, collected by
intelligence services and Homeland Security, and share the result back out with anyone
who was interested, bolstering the nation’s collective cyber defense.
The information would all come at machine speed using special protocols too, so there
would be no fiddling with phone calls and emails.
After years of haggling between security researchers, companies and privacy advocates,
it was considered the most significant cyber legislation affecting the private sector to ever
pass Congress.
What’s the Business Case?

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

142

The problem, former Homeland Security officials say, comes down to incentives.
CISA gave companies legal protection to share cyber threat information with the
government but it didn’t make a business case for why it was in their interest to do so, said
Phil Reitinger, who led Homeland Security’s cyber division under President Barack Obama.
“It’s easy to be a free rider in this this space and just consume the data other people
produce,” said Reitinger. “The information security professionals get it, but there’s more
work to be done convincing businesses that they’ve got a social responsibility to do this
and, overall, it’s in their economic best interest.”
Reitinger noted that the number of companies sharing threat information may be larger
than it appears because some companies may be sharing information with public-private
partnerships, known as information sharing and analysis centers, which are sharing it, in
turn, with Homeland Security.
Bruce McConnell, another top Homeland Security cyber official under Obama, also
pointed to the free rider problem. He noted, however, some companies have improved
sharing cyber threat information with each other in recent years, often leaving
government out of the loop.
One model he cited was the Cyber Threat Alliance, a coalition of tech and security
companies that share threat indicators, which was launched in 2017.
“Until companies realize we’re all in this together, the program will remain anemic,”
McConnell said of the Homeland Security sharing program.
Always a Long Road
To be clear, cyber analysts and CISA’s sponsors never believed the legislation would be a
panacea for cyber threats.
When CISA was on the Senate floor, one of its co-sponsors, Senate Intelligence Chairman
Richard Burr, R-N.C., stressed that the bill “does not prevent cyberattacks” and
acknowledged that no Senate bill could.
Burr praised the bill, though, for providing “a pathway to minimizing the amount of data
that is lost.”
Burr’s co-sponsor, Sen. Dianne Feinstein, D-Calif., who was then the Intelligence
Committee’s ranking member, lauded the bill for receiving support from over 40 business
groups and the U.S. Chamber of Commerce. She also described it as a “first-step bill,”
though, that would “not bring an end to successful cyberattacks or thefts.”
Judged by those modest goals, Reitinger, the former homeland security official, said CISA
should not be deemed a failure.
Even if most companies are only receiving rather than sending cyber threat data, that still
has the capability to make them significantly more secure, he said.
“In any sort of system like this, you’re likely to get an order of magnitude more recipients
than donors,” he said. “I’m very happy with having almost 200 entities receiving data right
now. But do I want more people contributing? For sure I do.”

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

•
•

143

Why might that be? Give thought both to lingering obstacles and to the potential
implications of the various other sharing systems we examined in the prior reading.
It has been several years since that snapshot. Do a bit of digging to see if you can
determine how things are going today.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

144

17. How the Government Protects Itself (I)

Learning objectives
•

•
•
•

•

•
•
•

Be able to explain the difference between the “technical story” of a breach and the
“organizational story” of that breach, and be able to relate that distinction to the OPM
breach.
With reference to a breach scenario, be able to explain the difference between the
“infection,” “detection,” “mitigation,” and “response” stages.
Understand how the OPM story illustrates the impact of organizational priorities and limited
budgets on the commitment of an organization to cybersecurity.
Appreciate that in the event a breach is discovered, it often is important to take no action
that might tip off the attacker…and thus technical steps to remove the attacker might have
to be delayed, and so too breach notification
Notice that it is much easier for the government itself to delay breach notification (not
accountable for complying with breach notification laws the way a private entity must),
though (by way of review) recall the grounds for a private entity also to delay notification (law
enforcement request, reasonable need for mitigation purposes; appreciate the utility of
having a third party advise you in writing of this)
Understand how the project of “long term mitigation” might call for changes relating to the
“organizational story” as much or as to the “technical story”
Appreciate why the US government did not attempt to treat the OPM breach as normatively
wrongful, and how this in turn limited the options for a larger US government response
Be able to explain why neither the FTC nor insurers have a significant role in pressuring
government agencies that have shoddy cybersecurity

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity
•
•

•
•

•

•

•

•
•

145

Be able to explain why the prospect of civil suit means less to a government agency head
than to the head of a private organization
Understand how “sovereign immunity” precludes such suits absent specific statutes waiving
that protection, but also how problems still can arise thanks to the potentially-speculative
nature of damages and the possibility that the particular statute in question might impose
onerous requirements (such as the Privacy Act’s requirement that the Court find that the
government acted “intentionally or willfully”
Know the obstacles encountered by the plaintiffs in the OPM litigation
Understand that the Supreme Court has not yet held that there is a constitutional “data
privacy” right as such, though of course there is a Fourth Amendment right against
unreasonable searches and seizures that encompasses government access to things as to
which one has a reasonable expectation of privacy
Be able to distinguish among: standard-setting (including everything from broad and vague
standards to highly-targeted mandates); monitoring/oversight/auditing in relation to those
standards; and actual cybersecurity “operations” (ranging from ad hoc help with incident
response to day-to-day security services).
Be able to explain why it is so much easier for Congress to subject federal agencies to
standard-setting, oversight, and operational intervention from another federal agency, in
contrast to the headaches that would arise if Congress tried to do the same to the private
sector (and consider whether, in light of topics we’ve already studied, Congress has
nonetheless succeeded in imposing at least some such interventions on the private sector)
Know which agencies have been given some form of standard-setting authority over other
federal agencies; which have a monitoring/oversight/audit role; and which perform
operational security functions.
Conversely, be able to describe the functions assigned to DHS CISA and OMB.
Be able to describe how the 2017 Executive Order regarding affirmative reporting of
“accepted risk” helps to create good incentives to invest smartly in cybersecurity measures
(and give thought to whether a well-considered report of this kind actually can function as a
defense for the agency if things later go wrong).

In recent classes we have surveyed the set of tools that can be used to incentivize private sector
entities to adopt stronger security measures. But what about the government’s own security
practices? How might we get the government to defend itself better?
As with private sector entities, government entities do have internal incentives to maintain the
security and functionality of their systems. No entity wants just anyone to be able to monitor its
internal deliberations, for example, and plenty of entities have more particular reasons to preserve
confidentiality, integrity, and accessibility (the SEC does not want people to access private
information and thus enable market manipulation, for example, just as NSA does not want
adversaries to be able to learn its techniques and capabilities). Yet we have ample reason to
believe that, if left to their own devices, many if not most government entities would not or could
not invest as much in security as they probably should. And so we need tools to compel
government entities, just like private entities, to do more.
Our main goal in this class is to understand which tools might be relevant to this task. Before we
dive in, though, a note is in order regarding the object of our analysis.
The “government” is not a single entity, but rather a vast array of distinct agencies and enterprises
(and that’s true even if we concern ourselves only with the federal government, while ignoring
state, county, city, tribal, and other levels of non-federal government). Most of these entities,
moreover, will own and operate any number of networks, databases, and endpoints; will have
their own budgetary, personnel, management, and leadership issues; and so forth. Thus, even if

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

146

we limit our focus to the U.S. government, the number of distinct security challenges for “the
government” is bewildering.
A. Case Study: The 2015 OPM Hack
Before we dig into the various tools that might be used to push government entities to devote
more effort to their own cybersecurity, it would be good to get a better grip on the problem we
are trying to solve. Toward that end, let’s start with a case study of a breach involving a
government agency: the 2015 episode in which hackers (widely thought to be acting for China’s
Ministry of State Security) penetrated security at the federal government’s Office of Personnel
Management and thereby acquired a vast trove of security-clearance background-check files.
As you read about the OPM hack, bear the following in mind: Determining “how” a breach
happened is a complicated matter. At one level, one can answer with a “technical story”—that
is, an explanation focused on which vulnerabilities (technical or otherwise) were exploited to gain
initial access; which tactics or methods were then used to escalate privilege, move laterally, mask
presence, etc.; which implants were installed; and how data was eventually exfiltrated, altered,
or disrupted. But note that one also might answer, instead or in addition, with an “organizational
story”—that is, an account that highlights features of the organization that helped produce the
circumstances that in turn made the technical story possible. The idea is that every organization’s
security structure is, ultimately, a function of the organization’s past choices on a number of
dimensions (including how much budget to commit to security, which personnel to hire, what
management structure to employ, what training to provide, what policy or legal constraints to
follow, what reward (and punishment) structure to apply, and so forth) as well as employee
personal dynamics and organizational culture. Both stories—the technical and the
organizational—deserve attention in any case study of a particular attack.
Now, on to our case study. Please read the following excerpts from this article from Wired, which
provides a handy overview of what occurred:
The routine nature of OPM’s business made the revelations of April 15, 2015, as perplexing as
they were disturbing. On that morning, a security engineer named Brendan Saulsbury set out
to decrypt a portion of the Secure Sockets Layer (SSL) traffic that flows across the agency’s
digital network. Hackers have become adept at using SSL encryption to cloak their exploits,
much as online vendors use it to shield credit card numbers in transit. Since the previous
December, OPM’s cybersecurity staff had been peeling back SSL’s camouflage to get a
clearer view of the data sloshing in and out of the agency’s systems.
Soon after his shift started, Saulsbury noticed that his decryption efforts had exposed an odd
bit of outbound traffic: a beacon-like signal pinging to a site called opmsecurity.org. But the
agency owned no such domain. The OPM-related name suggested it had been created to
deceive. When Saulsbury and his colleagues used a security program called Cylance V to dig
a little deeper, they located the signal’s source: a file called mcutil.dll, a standard component
of software sold by security giant McAfee. But that didn’t make sense; OPM doesn’t use
McAfee products. Saulsbury and the other engineers soon realized that mcutil.dll was hiding
a piece of malware designed to give a hacker access to the agency’s servers.
. . . [E]arly that morning, a team of engineers from the US Computer Emergency Readiness
Team [US-CERT], the Department of Homeland Security unit that handles digital calamities,
marched into OPM’s headquarters. The engineers set up a command post in a windowless
storage room in the subbasement, just down the hall from where Saulsbury had discovered
the hack less than 24 hours earlier. Since they couldn’t trust OPM’s compromised network, the

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

147

visitors improvised their own by lugging in workstations and servers that they could seal behind
a customized firewall.
. . . One of the US-CERT team’s first moves was to analyze the malware that Saulsbury had
found attached to mcutil.dll. The program turned out to be one they knew well: a variant of
PlugX, a remote-access tool commonly deployed by Chinese-speaking hacking units. The tool
has also shown up on computers used by foes of China’s government, including activists in
Hong Kong and Tibet. The malware’s code is always slightly tweaked between attacks so
firewalls can’t recognize it.
. . . The hunt turned up not just malware but also the first inklings of the breach’s severity. A
technician from the security software company Cylance, who was supporting the effort,
spotted encrypted .rar files that the attackers had neglected to delete. He knew that .rar files
are used to store compressed data and are often employed by hackers to shrink files for
efficient exfiltration. In an email to Cylance CEO Stuart McClure on Sunday, April 19, the
technician was blunt in his assessment of OPM’s situation: “They are fucked btw,” he wrote.
By Tuesday the 21st, having churned through a string of nearly sleepless days and nights, the
investigators felt satisfied that they’d done their due diligence. . . . The PlugX variant they were
seeking to annihilate was present on fewer than 10 OPM machines; unfortunately, some of
those machines were pivotal to the entire network. “The big one was what we call the
jumpbox,” Mejeur says. “That’s the administrative server that’s used to log in to all the other
servers. And it’s got malware on it. That is an ‘Oh feces’ moment.”
By controlling the jumpbox, the attackers had gained access to every nook and cranny of
OPM’s digital terrain. The investigators wondered whether the APT had pulled off that
impressive feat with the aid of the system blueprints stolen in the breach discovered in March
2014. If that were the case, then the hackers had devoted months to laying the groundwork
for this attack.
At first, the investigators left each piece of malware in place, electing only to throttle its ability
to send outbound traffic; if the attackers tried to download any data, they would find
themselves confined to dial-up speeds. But on April 21, Mejeur and the US-CERT team began
to discuss whether it was time to boot the attackers, who would thus learn that they’d been
caught. “If I miss one remote-access tool, they’ll come back in through that variant, they’ll
reestablish access, and then they’ll go dormant for six months to a year at least,” says a USCERT incident responder who participated in the OPM investigation and who agreed to speak
on the condition he remain anonymous. “And then a year later, they’ve now put malware in
a lot of different places, and you don’t know what’s happening because you think you
already mitigated the threat.”
The debate continued until the evening of Friday, April 24, when an opportunity presented
itself: As part of a grid modernization program in Washington, OPM’s building was scheduled
to have its power cut for several hours. The team decided that, even though it would mostly
be just a psychological triumph, they would dump the malware just minutes before the
blackout. If the attackers were monitoring the network, they wouldn’t realize their access had
been cut until everything finished booting up at least 12 hours later.
By the time power was restored on the 25th, the hackers no longer had the means to roam
OPM’s network—or at least that’s what everyone hoped. The investigators could finally turn
toward piecing together what the attackers had hauled away.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

148

. . . As the investigators laboriously sifted through interview transcripts and network logs, they
created a rough timeline of the attack. The earliest incursion they could identify had been
made with an OPM credential issued to a contractor from KeyPoint Government Solutions.
There was no way to know how the hackers had obtained that credential, but the investigators
knew that KeyPoint had announced a breach of its own in December 2014. There was a good
chance that the hackers had first targeted KeyPoint in order to harvest the single credential
necessary to compromise OPM.
Once established on the agency’s network, they used trial and error to find the credentials
necessary to seed the jumpbox with their PlugX variant. Then, during the long Fourth of July
weekend in 2014, when staffing was sure to be light, the hackers began to run a series of
commands meant to prepare data for exfiltration. Bundles of records were copied, moved
onto drives from which they could be snatched, and chopped up into .zip or .rar files to avoid
causing suspicious traffic spikes. The records that the attackers targeted were some of the
most sensitive imaginable.
The hackers had first pillaged a massive trove of background-check data. As part of its human
resources mission, OPM processes over 2 million background investigations per year, involving
everyone from contractors to federal judges. OPM’s digital archives contain roughly 18 million
copies of Standard Form 86, a 127-page questionnaire for federal security clearance that
includes probing questions about an applicant’s personal finances, past substance abuse,
and psychiatric care. The agency also warehouses the data that is gathered on applicants
for some of the government’s most secretive jobs. That data can include everything from lie
detector results to notes about whether an applicant engages in risky sexual behavior.
The hackers next delved into the complete personnel files of 4.2 million employees, past and
present. Then, just weeks before OPM booted them out, they grabbed approximately 5.6
million digital images of government employee fingerprints.
. . . The Congressional hearings that take place in the wake of national calamities often have
a vicious edge, and the one looking into the OPM hack was no exception. The agency’s
director, Katherine Archuleta, turned in a clumsy performance before the House Oversight
Committee: She failed to offer a clear idea of how many people had been affected by the
attack, and she seemed to duck personal responsibility by repeatedly mentioning how difficult
it is to secure OPM’s aging “legacy systems.” The committee’s members reacted with
predictable scorn.
. . . Damning details about OPM’s porous security emerged at the hearing. The agency’s own
assistant inspector general for audits testified about what he characterized as a “long history
of systemic failures to properly manage its IT infrastructure.”
The tone of the hearings struck some observers as overly brutal. The OPM brain trust received
no credit for implementing the SSL decryption program that had led to the attack’s discovery,
nor for acting fast to quell the threat.
...
Archuleta resigned under pressure, and her CIO, Donna Seymour, opted for retirement days
before she was to endure another round of grilling by the House committee. The two
executives’ departures struck fear into their peers across the federal bureaucracy.
And here are some additional details, summarizing criticism of OPM’s information-security
practices that were identified in a 2014 audit:

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

149

Unqualified InfoSec Personnel
The OPM’s infosec system was managed by Designated Security Officers (DSO) that weren’t
certified IT security professionals and were performing DSO duties in addition to their full-time
jobs. Despite updating to new IT security and privacy policies, the DSOs just weren’t qualified
to implement those policies …infosec personnel didn’t report to the Chief Information Security
Officer (CISO) and they didn’t employ experienced infosec professionals to manage their
security.
. . . Vulnerability Scanning? . . . [A]uditors were unable to obtain tangible evidence that
vulnerability scans were routinely conducted on all of OPM’s servers in 2014.
No Insight, No Inventory
The report also found that OPM doesn’t maintain an accurate centralized inventory of all of
their servers, databases or network devices that reside within the network. Without insight into
this basic data, it’s pretty hard to ensure OPM data is secured.
Untimely Patch Management
Although the OCIO applies operating system patches on all devices within OPM’s network
weekly, and uses a third-party patching software management program to update the
software, they still found, via scans, that numerous servers were not patched on a timely basis.
. . . Poorly Configured SIEM
Although the OPM owns a security information and event management (SIEM) tool that can
detect, analyze and correlate security incidents over time, it wasn’t configured to receive
data from 20 percent of major OPM information systems.
The report also stated that OPM systems were over-reporting log and event data, resulting in
too much data for their security analysts to review. Plus, there was a high volume of falsepositives that created a backlog and delay in identifying real incidents.
No PIV Authentication
While over 95 percent of OPM workstations require PIV (Personal Identity Verification)
authentication to access the OPM network, none of the agency’s 47 major apps require PIV
authentication. PIV is a type of government-issued smart card.
No Two-Factor Authentication
According to the NYTimes.com, in an interview, OPM’s Chief Information Officer (CIO) Donna
Seymour said that installing two-factor authentication (multi-factor authentication) in the
government’s ‘antiquated environment’ was difficult and very time-consuming.
. . . Ultimately, the security report found that OPM had not undergone an adequate security
controls test in more than eight years - which is more than enough time for new vulnerabilities
to pop up and for breaches to go unnoticed. Don’t wait that long to take a look at your own
company’s security controls in order to avoid a preventable breach.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

150

Consider the following questions:
Focus first on the technical story:
• How did the intruders gain access to OPM’s system in the first place?
• How were they able to move laterally and extract data without detection?
Now focus on the organizational story:
• Can you identify (or at least imagine) a set of factors that help explain why OPM did
not have better security?
• For each factor you identified, what exactly would a “fix” look like?
• What factors might make it hard in practice to adopt each such fix?
As long as we have this case study cued up, let’s use it for a quick review:
• Can you categorize what China apparently did here, using the typology of
government actions we reviewed earlier in the course?
• In light of that categorization, and drawing on our prior discussions of US-China
relations, how should the U.S. government have responded to the OPM hack? Think
of three specific potential actions, and list pros and cons for each.

B. Tools to Generate Better Government Security
Plainly, the government’s own cybersecurity efforts sometimes fall short. And so the question
arises: What tools can we bring to bear to get the government to try harder?
That’s the same question we have been exploring throughout Unit I.B., with reference to privatesector entities as the victims. We therefore might start by considering whether the tools used to
push the private sector to do better might also help the government to push itself to do better.
1. Tools that Work Poorly in this Setting
As we saw previously, one way to encourage defensive improvements is to increase the extent to
which entities perceive that they are exposed to the risk of enforcement actions by regulators
such as the FTC. Another is leverage from insurance companies. Neither really work where it is
the government itself we are trying to impact.

Can you explain why that might be?

Government entities do face the possibility of suits brought by private plaintiffs, at least in theory.
But such suits have a bad track record.
The first problem is “sovereign immunity.” Unlike a private entity, federal and state government
entities cannot be hauled into their own courts involuntarily; as sovereigns, they can only be sued
if they have consented.
Does that ever happen? Yes, in fact waiver of sovereign immunity via statute is common. Both
federal and state laws are full of examples of statutes expressly waiving immunity as to certain
types of claims. The question for us is: Do any of them apply in a setting where the government
entity had poor cybersecurity? There are some that might, but in practice they’ve not yet proven
to have much bite in the cybersecurity setting.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

151

The most well-known statute of this kind at the federal level is the Federal Tort Claims Act. It waives
immunity where a person suffers personal injury, property damage, or death as a result of wrongful
or negligent conduct by a government official. Most states (including Texas) have something
similar on the books. It is difficult to use these laws to sue successfully for damages relating to a
data breach, however, in light of the injury requirement.
A second option is the federal Privacy Act, which attempts to protect the confidentiality of
personally identifiable information held by the U.S. government. In relevant part, 5 U.S.C.
552a(e)(10) states that the government must:
establish appropriate administrative, technical, and physical safeguards to insure the
security and confidentiality of records and to protect against any anticipated threats or
hazards to their security or integrity which could result in substantial harm, embarrassment,
inconvenience, or unfairness to any individual on whom information is maintained . . . .
The Privacy Act is a key part of the plaintiffs’ claims in currently pending litigation known as In re:
U.S. Office of Personnel Management Data Security Breach Litigation, which is a would-be classaction stemming from the OPM breach. The plaintiffs argue that OPM’s poor security measures
violate the Privacy Act (among other things). Here, too, the question of damages looms large.
The Supreme Court in 2012’s FAA v. Cooper had held, after all, that “emotional damages” are not
cognizable under the Privacy Act. And with the OPM hack attributed widely to China as an act
of espionage rather than an effort to raise money via identity theft, it was not surprising when the
trial court initially dismissed the lawsuit on the ground that the claims of damage were speculative,
and thus that the plaintiffs lacked standing:
Rejecting plaintiffs’ argument that they faced a heightened risk of identity theft due to the
breaches, the court held that the facts alleged failed to plausibly support the conclusion
that this risk of future injury was either substantial or clearly impending. The district court
ultimately concluded that only those plaintiffs who specifically identified out-of-pocket
losses stemming from the actual misuse of their data had suffered an injury in fact sufficient
for standing purposes. But even those plaintiffs lacked standing, the district court
concluded, because they failed to allege facts demonstrating that the misuse of their
information was traceable to the OPM breaches in particular.
But then, in the summer of 2019, a divided D.C. Circuit Court of Appeals partially reversed this
determination. The majority explained:
[T]he district court should not have relied even in part on its own surmise that the Chinese
government perpetrated these attacks. Absent any factual allegations regarding the
identity of the cyberattackers, the district court was not free to conduct its own extrarecord research and then draw inferences from that research in OPM’s and KeyPoint’s
favor.
. . . Beyond that, although a cyberattack on a government system might well be motivated
by a purpose other than identity theft, given the type of information stolen in the OPM
breaches and Arnold Plaintiffs’ allegations regarding the subsequent misuse of that
information, it is just as plausible to infer that identity theft is at least one of the hackers’
goals, even if those hackers are indeed affiliated with a foreign government. Our
dissenting colleague takes a different tack, suggesting that because this case involves
government databases, “espionage is an ‘obvious alternative explanation’” for the
attacks. . . . We disagree as to just how obvious an explanation this is based on the facts
alleged in the complaint. Furthermore, given that espionage and identity theft are not
mutually exclusive, the likely existence of an espionage-related motive hardly renders

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

152

implausible Arnold Plaintiffs’ claim that they face a substantial future risk of identity theft
and financial fraud as a result of the breaches.
. . . Because Arnold Plaintiffs adequately allege a substantial risk of future identity theft,
any expenses they have reasonably incurred to mitigate that risk likewise qualify as injury
in fact.

Are you persuaded? Why, or why not?

Another major hurdle that all plaintiffs under the Privacy Act must confront if they hope to recover
money damages is the statute’s peculiar mens rea requirement for that scenario. Simply put, the
statute provides that damages may be awarded for violations of the aforementioned duty
(among other reasons), but only where “the court determines that the agency acted in a manner
which was intentional or willful … ” and the plaintiff suffered damages as a result. 5 U.S.C.
552a(g)(4). Note that there is no such mens rea requirement if the plaintiff instead is seeking only
injunctive relief (that is, a court order directing an agency to do, or not do, some specific thing).
See id. at 552a(g)(2-3).

Would you characterize OPM as having intentionally or willfully failed to meet its Privacy Act
obligations?

Intriguingly, some of the plaintiffs in the OPM litigation argued that OPM’s poor effort to protect
their information violated not just the Privacy Act but also the Constitution itself. Specifically, they
argued that there is an (unwritten) constitutional right to “informational privacy” that can be
derived from the Due Process Clause of the Fifth Amendment (the text of which prohibits the
deprivation of life, liberty or property without due process of law), and that this asserted right
perhaps could be read to impose an obligation of reasonable efforts to protect personally
identifiable information once in the government’s hands.
Is there such a right in the first place? The Supreme Court has largely dodged the question. In its
2009 NASA v. Nelson decision, the majority assumed without deciding that some such a right might
exist, citing two earlier cases that it depicted as having made a similar move (Justices Scalia and
Thomas dissented, calling for clear recognition that no such right has as yet been made part of
the Constitution, however desirable such a right might be as a matter of policy). But some circuit
courts, such as the Ninth Circuit, have been willing to go further, and in the same D.C. Circuit
decision in the OPM case discussed above, the majority was willing to assume, at least for now,
that such a claim exists.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

153

Consider these questions:
• As a normative matter, what are the best arguments for and against permitting
persons to sue for damages in circumstances like the OPM breach?
• If such a right should exist, should it take the form of a statute or of a constitutional
right?
• Let’s assume the government can be sued in these cases. Do you think that
anticipation of liability risk for the government as a whole will impact agency decisionmaking in a manner similar to the way that litigation risk may impact the decisionmaking of private entities? Put yourself in the position of an agency head making
budget plans. What are your incentives, exactly?

2. Tools that Work Well in this Setting
a) Direct mandates to do or not do certain things
Whereas regulatory enforcement, insurance leverage, and liability risk all work better for
influencing the private sector than for influencing the government itself, the reverse is true with
respect to another tool: direct mandates to do (or not do) certain things.

Why would it be easier for the government to impose direct mandates on itself, as compared
to imposing them on the private sector?

Our task now is to understand the way that the federal government, over time, has developed a
complex system for imposing security mandates on itself.
Let’s start (somewhat arbitrarily) in 1996, during the Clinton administration. A statute passed that
year tasked the Secretary of Commerce with establishing information-security standards that most
of the rest of the government would henceforth have to follow (the obligation would not extend
to defense and intelligence agencies, however; they remained free to develop and enforce their
own rules in this respect). The statute specified that the Secretary should base his or her directives
on the standards and guidelines developed by the Commerce Department’s National Institute of
Standards and Technology (better known as “NIST”), which is a deeply respected technical
organization.
Fast-forward six years, to the early years of the George W. Bush administration. In 2002, at a time
before the Department of Homeland Security existed, Congress passed the Federal Information
Systems Management Act of 2002 (“FISMA,” pronounced “fiz-muh”). FISMA did three significant
things, for our purposes. First, it took the standard-setting role away from Commerce and gave it
to the White House’s Office of Management and Budget (OMB) (though in fulfilling that role OMB
still would remain reliant on the guidance provided by NIST, which remained part of the
Commerce Department). Second, FISMA charged OMB with a critical further task: to monitor, on
at least an annual basis, whether other agencies actually complied with its standards. And third,
FISMA called for creation of an “information security incident center” that would both provide
expert advice (including in the face of an unfolding emergency) and function as a threatintelligence hub (collecting and analyzing information). This eventually resulted in creation of USCERT, which you read about previously in relation to the Equifax and OPM case studies.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

154

Six years later, with DHS now in existence, President Bush issued National Security Presidential
Directive 54/Homeland Security Presidential Directive 23. That 2008 Directive called for DHS to
play the lead role in protecting federal networks (other than military and intelligence systems).
This meant something much more concrete and direct than simply generating rules for other
agencies to follow and then monitoring to see whether they complied. The order made US-CERT
part of DHS (in particular, part of the directorate that eventually became CISA), and directed DHS
to act through US-CERT to monitor and protect all “external access points” associated with federal
government systems, and to provide intrusion detection, incident analysis, and other capabilities.
That is to say, the order called upon DHS to take on operational responsibility for certain security
functions on behalf of all other non-military, non-intelligence agencies. DHS responded to that
assignment by, among other things, developing and deploying an intrusion-detection system that
came to be known as “Einstein.” Here is a DHS account of Einstein versions 2 and 3 from a few
years ago:
DHS is deploying, as part of its EINSTEIN 2 activities, signature-based sensors capable of
inspecting Internet traffic entering Federal systems for unauthorized accesses and malicious
content. The EINSTEIN 2 capability enables analysis of network flow information to identify
potential malicious activity while conducting automatic full packet inspection of traffic
entering or exiting U.S. Government networks for malicious activity using signature-based
intrusion detection technology. . . . EINSTEIN 2 is capable of alerting US-CERT in real time to the
presence of malicious or potentially harmful activity in federal network traffic and provides
correlation and visualization of the derived data. [Meanwhile, DHS is developing a new
system], called EINSTEIN 3, [that] will draw on commercial technology and specialized
government technology to conduct real-time full packet inspection and threat-based
decision-making on network traffic entering or leaving these Executive Branch networks. . . .
The EINSTEIN 3 system will also support enhanced information sharing by US-CERT with Federal
Departments and Agencies by giving DHS the ability to automate alerting of detected
network intrusion attempts and, when deemed necessary by DHS, to send alerts that do not
contain the content of communications to the National Security Agency (NSA) so that DHS
efforts may be supported by NSA exercising its lawfully authorized missions. . . . DHS will be able
to adapt threat signatures determined by NSA in the course of its foreign intelligence and DoD
information assurance missions for use in the EINSTEIN 3 system in support of DHS’s federal
system security mission. Information sharing on cyber intrusions will be conducted in
accordance with the laws and oversight for activities related to homeland security,
intelligence, and defense in order to protect the privacy and rights of U.S. citizens.

Can you sum up what the Einstein system actually does, and for whom?

With DHS thus emerging as the lead agency for most aspects of the federal government’s own
cybersecurity, a question arose regarding whether it still made sense for OMB to have the oversight
role assigned to it by the 2002 FISMA (that is, the role of ensuring that other agencies were
complying with OMB’s NIST-based standards). In 2010, the Obama administration concluded that
the answer was no, and notwithstanding FISMA, proceeded to direct OMB to delegate its
oversight role to DHS. Then, in 2014, Congress ratified that division of labor in “FISMA 2014.”
So far so good. But note that, up to this point, the ability of DHS to compel other agencies to take
particular steps in the name of cybersecurity was limited to articulation of standards and
monitoring for compliance. Apart from the implicit name-and-shame element that came with
the filing of periodic reports from that compliance-monitoring process (an element that didn’t
seem to move the needle much in the case of OPM, it is worth noting), it was not clear what
negative consequences if any an uncooperative or non-responsive agency faced if it more-or-

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

155

less just ignored DHS. Which helps us understand why, in 2014 and again in 2015, Congress granted
certain additional authorities to DHS. Specifically, DHS gained authority to issue mandatory
directives addressing cybersecurity issues for all federal information systems (other than those
associated with the military and the Intelligence Community).
This authority comes in two varieties. First, CISA can issue “binding operational directives” (“BODs”)
in order to compel implementation of cybersecurity policies. This authority is codified at 44 U.S.C.
3553(b)(2), and has been in place since FISMA 2014. Second, thanks to a statute Congress
enacted in late 2015 (section 229 of the “Federal Cybersecurity Enhancement Act of 2015”), CISA
also can issue “emergency directives” (“EDs”) to compel agencies to take particular steps in
response to specific security threats. This authority is codified at 44 U.S.C. 3553(h).
The full list of BODs and EDs that have been issued is found at https://cyber.dhs.gov/directives/. As
of October 2020, there had been nine BODs and four EDs:
Binding Operational Directives
• BOD 20-01 - Develop and Publish a Vulnerability Disclosure Policy
• BOD 19-02 - Vulnerability Remediation Requirements for Internet-Accessible Systems
• BOD 18-02 - Securing High Value Assets
• BOD 18-01 - Enhance Email and Web Security
• BOD 17-01 - Removal of Kaspersky-branded Products
• BOD 16-03 - 2016 Agency Cybersecurity Reporting Requirements
• BOD 16-02 - Threat to Network Infrastructure Devices
• BOD 16-01 - Securing High Value Assets (Revoked)
• BOD 15-01 - Critical Vulnerability Mitigation (Revoked)
Emergency Directives
• ED 21-04 - Mitigate Windows Print Spooler Service Vulnerability
• ED 21-03 - Mitigate Pulse Connect Secure Product Vulnerabilities
• ED 21-02 - Mitigate Microsoft Exchange On-Premises Product Vulnerabilities
• ED 21-01 - Mitigate SolarWinds Orion Code Compromise
• ED 20-04 - Mitigate Netlogon Elevation of Privilege Vulnerability from 8/20 Patch Tuesday
• ED 20-03 - Mitigate Windows DNS Server Vulnerability from July 2020 Patch Tuesday
• ED 20-02 - Mitigate Windows Vulnerabilities from January 2020 Patch Tuesday
• ED 19-01 - Mitigate DNS Infrastructure Tampering

•
•
•
•
•
•

Come to class prepared to describe a problem that gave rise to a BOD, and what
the BOD directed federal agencies to do in response to that problem.
Do the same with respect to one of the EDs.
Can you explain why CISA uses the BOD authority in some contexts and the ED
authority in others?
Notice BOD 17-01. Does it strike you as different in kind from the other BODs?
Congress later codified the prohibition on Kaspersky products, highlighting that similar
effects can be achieved directly by statute. Why have BOD/ED authority, given that
option?
Should Congress extend CISA’s authority to issue BODs and EDs so that it can issue
orders not just to government agencies, but also at least some private-sector
entities? Be prepared to state the pros and cons, and consider separately the
practical obstacles to adopting such a policy.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

156

b) Provision of special services
There are other things CISA does to help level-up security for other government entities. For
example, CISA sometimes provides agencies with the sort of security-enhancing services that
one normally would hire a private information-security company to provide. The following chart
provides a rough overview of the sort of services CISA can provide (resources permitting):
1. Continuous Diagnostics and Mitigation
2. Enhanced Cybersecurity Services (Domain Name System sinkholing; email filtering)
3. Hunt and Incident Response Team support (remote assistance; advisory deployment;
remote deployment; on-site deployment)
4. Advanced Malware Analysis Center
5. Distribution to the public of threat intelligence and other useful information (ex: the FY2019
RVA findings mapped to ATT&CK)
6. Vulnerability Scanning
7. Web App Scanning
8. Phishing Campaign Assessment
9. Remote Penetration Testing
10. Risk & Vulnerability Assessment
11. Cyber Resilience Review
12. External Dependencies Management Assessment
13. Cyber Infrastructure Survey
14. Cyber Security Evaluation Tool
15. Validated Architecture Design Review
At this point, we are ready to connect this topic directly to the case study on Holiday Bear and
SolarWinds with which this book began. As you will recall, SVR managed to place SUNBURST on
a variety of federal agency systems via SolarWinds Orion, deploy Cobalt Strike BEACON on those
compromised systems, swim upstream into M365 cloud environments, and ultimately to exfiltrate
emails and other information. Having just read about CISA’s role in boosting federal agency
cybersecurity, you might be wondering whether there was some way CISA could or should have
detected these activities. The short answer is no, because at that time each separate agency
was responsible in the first instance for its own security, and CISA had only limited ability—
requiring the approval of those agencies’ leaders—to monitor for threats within those systems.
Fortunately, a statute passed in 2020 extended new authority to CISA on this very topic,
authorizing CISA to engage in threat-hunting on federal civilian executive branch systems
without always having to secure the advance permission of agency leaders. While certainly not
a silver bullet for the Holiday Bear scenario, this will help.
Finally, before leaving the topic of centralized security services, a quick note about the current
status of US-CERT is in order. You may recall from our initial introduction to CISA that the functions
of NCCIC remain in place even as internal organizational realignments call into question the
continuing relevance of that specific name. Well, suffice to say that much the same can be
said about US-CERT: the functions of US-CERT remain as before, and the name itself is still in use in
certain respects, but it is no longer clear that the old label is the best way to capture how CISA
itself refers to these functions. For those of us on the outside, therefore, the same advice obtains:
concentrate on learning the functionality, and be mindful that different people may be using
different organizational labels to refer to the personnel executing those functions.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

157

c) Risk management obligations
In May 2017, when President Trump issued Executive Order 13,800 (May 11, 2017), “Strengthening
the Cybersecurity of Federal Networks and Critical Infrastructure.” For now, we are concerned
only with Section 1 of that order. In relevant part, it states:
(c) Risk Management
(i)

Agency heads will be held accountable by the President for implementing
risk management measures commensurate with the risk and magnitude of
the harm that would result from unauthorized access, use, disclosure,
disruption, modification, or destruction of IT and data. They will also be held
accountable by the President for ensuring that cybersecurity risk
management processes are aligned with strategic, operational, and
budgetary planning processes.

(ii)

Effective immediately, each agency head shall use The Framework for
Improving Critical Infrastructure Cybersecurity (the Framework) developed
by the National Institute of Standards and Technology, or any successor
document, to manage the agency’s cybersecurity risk. Each agency head
shall provide a risk management report to the Secretary of Homeland
Security and the Director of the Office of Management and Budget (OMB)
within 90 days of the date of this order. The risk management report shall:
(A) document the risk mitigation and acceptance choices made by each
agency head as of the date of this order, including:
(1) the strategic, operational, and budgetary considerations that
informed those choices; and
(2) any accepted risk, including from unmitigated vulnerabilities;
and
(B) describe the agency’s action plan to implement the Framework.

(iii)

The Secretary of Homeland Security and the Director of OMB…shall jointly
assess each agency’s risk management report to determine whether the
risk mitigation and acceptance choices set forth in the reports are
appropriate and sufficient to manage the cybersecurity risk to the
executive branch enterprise in the aggregate (the determination).

In what precise way does this approach increase pressure on agencies?

In our next reading, we will examine the most recent White House intervention in the general
space of government self-regulation, which to some extent is responsive to the Holiday Bear
debacle.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

158

18. How the Government Protects Itself (II)

Learning Objectives
•
•

•

•

•
•
•

•
•

Be able to describe the key features of President Biden’s May 2021 Executive Order
Be able to explain the difference among blue space, red space, and gray space (including
how to categorize a situation in which an adversary is using a server without the
owner/operator’s awareness)
Understand the difference among these blue space scenarios: the DoDIN, foreign
government system’s where the US military operates by invitation of the host government, and
Defense Support of Civil Authorities
With respect to defense of the DoDIN, be able to describe why we have “Cyber Protection
Teams” (as part of JFHQ-DODIN) in addition to personnel attached directly to the particularly
DoD entities whose systems they defend
Be able to explain how JFHQ-DODIN has a role analogous to that of CISA in terms of
coordination, standard-setting, oversight/auditing, and issuance of directives
Understand the policy rationales supporting the use of Cyber Protection Teams in “hunt
forward” missions
Understand why both state/local/tribal governments in the United States, as well as other
federal government entities, might at time wish to draw on U.S. military defensive capabilities,
and how the Stafford Act and the Economy Act enable this
Appreciate why the “Posse Comitatus Act” is irrelevant to such support
Understand what a “national security system” is, and how NSA plays a role analogous to that
of CISA in terms of coordination, standard-setting, etc. for such systems

A. The May 2021 Biden Cybersecurity Executive Order
President Biden issued an important executive order on cybersecurity in May 2021, one that
touches on many topics but that includes some elements further spurring the government’s efforts
to protect itself. Here are key excerpts from an overview I wrote with Trey Herr of the Atlantic
Council for Lawfare:
Yesterday evening, the Biden administration released its much-anticipated “Executive
Order on Improving the Nation’s Cybersecurity.”
It is tempting to yawn; every
administration in recent memory has done something of this kind, after all, and not always

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

159

to significant effect. But this executive order deserves your attention. It contains concrete
measures tailored to respond to lessons learned from recent crises, especially the
SolarWinds and Microsoft Exchange compromises.
Is there more work to do? Obviously, yes. But to a significant extent that’s a job for
Congress. The question at the moment is whether the Biden administration with this
executive order has made good use of the limited tools that it controls directly. As we
explain below, the answer is largely yes.
…
2. Cybersecurity is a sprawling problem. Which specific parts of that problem does the EO
aim to address?
The EO does not aim to address the entirety of the cybersecurity landscape. Instead, it
focuses on a handful of important aspects of that larger challenge, with a clear (and
expected) emphasis on those that were central to the SolarWinds/Sunburst and Microsoft
Exchange messes. Here’s a shorthand overview of which parts of the order cover which
general topics:
Stages in the Cybersecurity Cycle and Corresponding Contributions From the EO
Preventing intrusion
Section 3 (cloud services; multi-factor authentication)
Section 4 (software supply chain standards; “Internet of Things” (IoT) transparency)
Minimizing impact of intrusion (pre-detection)
Section 3 (data encryption; zero trust environment)
Detecting and responding to intrusion
Section 2 (notification requirements; enabled/required vendor cooperation)
Section 3 (additional information sharing)
Section 6 (uniform incident response playbook)
Section 7 (endpoint detection and response; centralized threat-hunting)
Section 8 (logging requirements)
Learning (and disseminating) lessons from intrusion
Section 5 (Cyber Safety Review Board)
That’s the big picture. But remember: The EO largely is focused on the federal
government’s own cybersecurity posture. This makes sense, given the limits on what the
president can accomplish unilaterally and given the role that SolarWinds/Sunburst—an
intrusion that made its way deep into government and private-sector systems—played in
giving rise to this effort.
3. Let’s get to the specifics. What exactly is in the operative sections of the EO?
The operative parts of the EO are Sections 2-9. Here’s what you need to know about each.
Section 2: Ensuring that private entities supplying IT/OT services to federal agencies can
and will share threat information with CISA, the FBI, etc.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

160

Section 2 takes on an aspect of the information-sharing problem that was highlighted—
not in a good way—by the SolarWinds/Sunburst mess. Many federal information systems
are run or supported by a private-sector service provider. These arrangements are
sometimes based on contracts that are written in ways that fail to require the private
vendor to share threat and incident information with other federal agencies, like CISA or
the FBI. Some such contracts may even prohibit such sharing. At any rate, the experience
with SolarWinds/Sunburst demonstrates that such contract complications really do
interfere with the ability of CISA and the FBI to obtain quick cooperation from outside
vendors.
If contracts are the problem, then the procurement power is the solution. And that’s what
Section 2 is all about. It puts into motion a two-month process to review the contracting
rules known as the Federal Acquisition Regulation (FAR) and the Defense Federal
Acquisition Regulation Supplement (DFARS) with an eye toward a host of changes meant
to address the aforementioned issue. The disclosure rules cover software products as well
as, critically, any “support system for a software product or service.” This covers a potential
reporting gap for core technology systems like identity management (the kinds of systems
repeatedly abused in the SolarWinds/Sunburst crisis).
Eventually, FAR and DFARS will oblige service providers to do what boils down to three
things. First, they’ll have to collect and preserve a broad array of information (including
information relating to “event prevention,” not just incident response). Second, they’ll
have to share such information with the government when the information relates to an
incident (or potential incident) that is relevant to the contract in question. And they’ll have
to cooperate with the federal entities involved in addressing or investigating incidents or
potential incidents.
Another part of Section 2 sets in motion a separate change to FAR that eventually will result
in a requirement that such providers also must affirmatively and “promptly” report
cybersecurity incidents involving a product or service provided to the government (or the
support systems for such services/products). This, too, clearly reflects concerns brought to
light by recent experience.
While incident data takes the starring role here, notice that the administration appears
interested in more than that. There is language as well about information necessary for the
government “to respond to cyber threats, incidents, and risks.” This implies a much broader
potential range of data, and it may implicate companies that sell this kind of threat
intelligence and cybersecurity data directly to the federal government. It’s unclear if the
new rule will come with waivers to permit that kind of sale or if it will be covered under
these new disclosure guidelines. There is a wild card in Section (3) (e), moreover, with an
open-ended direction to DHS and the Office of Management and Budget (OMB) to
ensure service providers share this data “to the greatest extent possible.” Much of the
practical impact of this section will come out in the implementation for these rules, so stay
tuned.
Section 3: Getting the government’s own house in order (aka Cloud, More Cloud, and Don’t
Trust Anybody)
It’s official: Cloud is in. While policies to encourage and support cloud adoption have been
spreading across federal information technology over the past decade, the governance
of cloud security has remained relatively immature. “Section 3. Modernizing Federal
Government Cybersecurity” takes direct aim at this problem, charging CISA to develop
secure cloud adoption practices and guidelines, offer cloud incident responses to the

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

161

.gov, and set policy on how agencies should work with partners like CISA and the FBI in
responding to cloud incidents. Per the executive order, OMB also will play an important
role, drafting a federal cloud security strategy with associated guidance for agencies. The
challenge for CISA (and OMB) is that the timeline to develop these complex policies is
tight, 90 days or less in each case.
Section 3 also includes a small but significant set of actions to modernize FedRAMP (the
federal government’s main security authorization program for cloud services). The
language reads almost like language taken right from the Cloud Service Provider
playbook, with emphasis on more-automated, more-rapid and less-duplicative reviews of
new cloud services. The devil is in the details (the word “automation” is plenty fungible),
but the inclusion of the entire cycle of FedRAMP (including continuous monitoring) pushes
the scope of these prospective changes out a long way, into the full life cycle of cloud
services. Most expansive is the possibility of mapping other security certifications and
compliance frameworks to FedRAMP in order to speed cloud service providers’
authorization. That opens up significant opportunities for industry-led compliance
frameworks, targeting, for example, only software as a service (SaaS) in order to supplant
slower moving FedRAMP processes.
Alongside the cloud lovefest is the “zero trust architecture” concept. Zero trust is a loose
collection of technology concepts and security design philosophies rooted in the
assumption that a breach is inevitable and that, accordingly, there should be strict limits
on access and authorization within a network. On this model, every device and every
interaction is presumptively suspicious and should be scrutinized accordingly, and access
should be strictly limited against a set of conditions and “roles” (for example, CEO, system
administrator, and guest). The practical effect of zero trust is to require new processes to
set and enforce rules for nearly everything that takes place—from opening files on a share
drive to signing up a new mobile phone for Wi-Fi. The EO emphasizes zero trust as a means
of ensuring more robust defenses even where supply chains are compromised or
organizations breached. Implementing this kind of design philosophy is tough and time
intensive. There is no one-stop-shop to “buy” zero trust right now as it is as much about
changing culture as the type of technology users have. Whether a set of 60-day sprints
can successfully kickstart that transformation remains to be seen.
A final note on Section 3: It also sets a 180-day deadline for all Federal Civilian Executive
Branch (FCEB) entities to adopt multi-factor authentication and data encryption
practices, and they will owe progress reports to CISA (and help from CISA) along the way.
Section 4: Getting serious about software supply chain security
If you came for the software security, grab your popcorn because “Section. 4 Enhancing
Software Supply Chain Security” does not disappoint. It takes an unusually specific
technical view in places, and runs nearly to the end of the alphabet for sub-section
headings. It boils down to four broad areas:
Software supply chain security guidance from the National Institute of Standards and
Technology (informed by a heavy emphasis on the security of the development
environment and integrity/vulnerability checking), with eventual OMB enforcement to
ensure that agencies insist on compliance.
Inclusion of a Software Bill of Materials (SBOM) requirement in that guidance (and a
directive to the Department of Commerce (NTIA this time) to produce minimum
specifications for SBOMs).

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

162

A definition of (and trailing set of actions based on) the concept of “critical software,”
including enforcement by OMB, along with support and guidance from DHS and NIST.
Encouragement of IoT security and labeling.
The core software supply chain security guidance is in the hands of NIST, which is a popular
recurring character throughout the section. This is tricky territory for NIST, the Marylandbased boffins whose remit most generally tracks toward developing best practices and
extensive consensus building around voluntary guidelines and special publications.
Software supply chain security has been a challenge for policymakers in part because of
the gap between software development in standards and development in practice.
Placing most to all of the software supply chain security responsibility on a standards and
technology research body may prove challenging.
Software development gets a lot of attention in this section, but the focus is largely in line
with ensuring integrity of code at the root of the software supply chain. There are also
several requirements for vendors to attest to the development and security standards
required of them, including a limited public disclosure. Injecting this kind of information
about vendor security posture into the market is a good thing and a useful signal for
potential customers of these companies outside the federal space. And SBOM is here at
last; look for more in the form of a minimum viable specification from Commerce in the
next 60 days.
All of these supply chain guidelines and practices will be applied to vendors of “critical
software,” a term the EO introduces but will need DHS, the Office of the Director of National
Intelligence, and others to precisely define. Agencies will similarly have new restrictions
and guidance on how they operate “critical software,” but it is unclear how this will
interact with existing programs like the DHS/NIST High Value Asset (HVA) program.
Tucked into the later stages of Section 4 are a sequence of actions on IoT supply chain
security addressing baseline security and development practices of vendors with input
from NIST and a labeling program supported by the Federal Trade Commission. This
includes a big role for NIST to identify and ingest all existing cybersecurity and secure
software development labeling schemes and best practices and, in the case of software,
possibly produce a “tiered software security rating system.” The prospect for movement
on cybersecurity labeling for IoT is exciting, answering several calls for such a program in
the United States and matching up with policies in the United Kingdom, Singapore and
elsewhere. It may yet prove necessary for Congress to act in this space, however, before
there is widespread uptake of such transparency measures.
Section 5: An NTSB for significant cyber incidents
Another much-anticipated idea breathed to life by the EO is the Cyber Safety Review
Board. The board will be an interagency group convened by DHS and featuring
representatives from the Defense Department, the Justice Department, CISA, the National
Security Agency (NSA) and the FBI, as well as appointees from the private sector (tailored
to the circumstances of the particular incident under review). The idea is to review
“significant cyber incidents” (which might involve breach of federal systems but also might
encompass certain private-sector incidents), in order to extract lessons learned and then
disseminate those lessons appropriately.
The model is inspired by the National
Transportation Safety Board, which reviews major transportation accidents like airplane
crashes and whose detailed investigative write-ups help inform risk assessments, vendor
evaluations and operational practices.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

163

The EO specifies a specific first job for the Cyber Safety Review Board: extracting lessons
learned from SolarWinds/Sunburst. Of course, the EO itself shows that this learning process
is already well in motion. That said, the EO also makes clear that the board in this first trot
around the track also should use the occasion to identify lessons learned about itself,
enabling the board process to work better in the future.
Sections 6, 7, and 8: Getting the federal cyber house in order, part II
Sections 6, 7 and 8 return to the theme of compelling federal agencies to improve their
cybersecurity posture.
The sequence starts with “Section 6. Standardizing the Federal Government’s Playbook for
Responding to Cybersecurity Vulnerabilities and Incidents,” addressing the fact that the
endless array of FCEB agencies apparently have an endless variety of incident response
playbooks.
No doubt the variation at least partially reflects tailoring to local
circumstances. But the net result of the variety is to make it more difficult for CISA, as the
centralized defensive lead, to ensure compliance effectively. So, Section 6 charges CISA
to develop a standard incident response playbook (in consultation with a host of other
agencies and organizations). It also tasks CISA to review and update the document
annually with the NSA and clarifies CISA’s authority to review agency response plans to
ensure conformity. In this way, Section 6 contributes to the ongoing process of moving CISA
further out front as the central cybersecurity organization for FCEB agencies.
This is as good a time as any to recall that, in the words of one former House staffer, CISA
is “overworked, understaffed and in one sense fighting half-blindfolded.” Increased
authority is good, in other words, but it needs to be matched by increased resources. The
next two years will be critical for CISA as Jen Easterly takes command and a prospective
infusion of budget paired with a surge in hiring may reshape the agency for good.
On to “Section 7. Improving Detection of Cybersecurity Vulnerabilities and Incidents on
Federal Government Networks,” which responds to issues that have loomed large in the
SolarWinds/Sunburst postmortems: the lack of strong (and consistent) endpoint detectionand-response (EDR) capabilities across many FCEB entities, and limits that existed (until
recently at least) on the ability of CISA to conduct threat-hunting across the systems of
those entities (with or without their permission). Section 7 directs all agencies to launch
initiatives to improve their EDR capabilities on a tight timeline, as well as other initiatives to
enhance CISA’s centralized threat-hunting capabilities. Relatedly, Section 7 also obliges
agencies to enter into agreements to provide CISA access to object-level data in support
of CISA’s Continuous Diagnostics and Mitigation Program.
Threat-hunting aficionados will recall that Congress actually granted CISA expanded (and
clarified) centralized threat-hunting authority in Section 1705 of the fiscal 2021 National
Defense Authorization Act. In a sign of the importance of that fresh authority, the EO calls
for CISA to produce a report in 90 days explaining how they are putting this authority to
work and also requires additional reporting every quarter describing its ongoing use.
Prediction: These reports will confirm that CISA is trying to make the most of Section 1705
but will need more resources to make full use of it.
Next up is “Section 8. Improving the Federal Government’s Investigative and Remediation
Capabilities.” Section 8 is very much a low-hanging fruit sort of provision, as it zeroes in on
the lack of network logs in many FCEB systems. As emphasized by some of the most
pointed criticism of vendors in the aftermath of SolarWinds/Sunburst, the amount (and
nature) of data recorded to network logs, and how that data is retained and accessed,

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

164

can have a major influence on the speed and success of cyber incident response. DHS
accordingly is charged with developing standard practices on logging, while OMB has
responsibility to enforce those practices across civilian agencies.
Notably, some of the SolarWinds/Sunburst postmortems have suggested that FCEB logging
issues sometimes result from financial constraints that led agencies to contract for vendor
services at price levels that did not include robust logging. Perhaps in response to this, the
EO specifically directs OMB to work with agency leaders to ensure they have the resources
needed to meet the new logging requirements.
Section 9: Don’t forget about national security systems!
At this point it should be clear that most of the EO focuses on the .gov—that is, the civilian
agencies and the characters you know and love, like the Internal Revenue Service, the
Environmnetal Protection Agency, the Department of State and more. But the Department
of Defense and the intelligence community like the cloud and computing too, thank you
very much. So, what about them?
Scattered requirements in the main body of the EO, and especially in “Section 9. National
Security Systems,” ensure that there are processes for the secretary of defense to
incorporate all of the standards and guidelines developed in the order for national security
systems where applicable and appropriate. National security systems (and the .mil
environment more broadly) thus are not the focus of this EO, but they do receive some
limited attention (with an emphasis on synchronizing with civilian agencies’ security
controls and data-collection practices).
4. 8,000+ Words Later, Where Are We?
If you wanted a document that deals with critical infrastructure or taking the fight to
foreign ransomware franchises, this EO is not for you. And that should come as no surprise.
Despite the timing of the Colonial Pipeline incident last week, the EO is the culmination of
an intensive period of work by the Biden cyber team sparked by the double-punch of
SolarWinds/Sunburst and Microsoft Exchange vulnerabilities. The watchword that follows
from those episodes is software security, with a heavy focus on federal incident response,
investigation and remediation.
That’s the center of gravity of the new EO. It is not revolutionary, but that shouldn’t be the
measure of success. The important question is whether it responds smartly to the important
lessons learned from painful recent experience, and it does seem to do that. FCEB entities
will be forced to take a variety of important steps (perhaps most notably, basic things like
the new encryption and multi-factor authentication mandates). CISA will be pushed a bit
further toward center stage, as the central cybersecurity organ of the .gov. Along the way,
the EO covers a lot of ground on secure software development and more risk-aware
treatment of “critical software” alongside new policies on cloud security and attempts to
shift the .gov environment to a new model of trust. There’s even an IoT securitytransparency nudge.
Plenty of questions and challenges remain, which is to be expected. For example, the EO
does not wrestle with “org chart” challenges, such as the role in all of this for the Federal
Acquisition Security Council or the federal chief information security officer, who go
unmentioned. Nor does it grapple directly with the future role of the national cyber
director (NCD), which soon will be filled by the esteemed Chris Inglis. It remains to be seen
how (if at all) the new programs and reporting lines—many of which include reporting to,

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

165

or decisions from, the assistant to the president for national security affairs—will change at
that point (while the NCD is not mentioned in the main body of the EO, there is an option
to allow that “portions of this order may be modified to enable the NCD to fully execute
its duties and responsibilities”). That may influence the timelines of some of these activities
as well.
Bottom line: The EO goes far toward picking the low-hanging fruit (and some not-so-lowhanging fruit) highlighted by recent challenges. In terms of systematic improvements for
the nation’s cybersecurity, attention should now shift to Congress. The EO’s prescriptive
elements may be a useful model for how Congress might take steps to bolster security in
at least some critical infrastructure subsectors, for example. And only Congress can
provide the increased resources that ultimately are needed to realize the full impact of
these new policies.

•

Which parts of the EO strike you as most important in terms of improving federal
civilian cybersecurity?

B. Cybersecurity for the Military
We have noted at several points that the roles played by OMB and DHS/CISA do not apply to
systems belonging to the military or to the Intelligence Community. Our task now, accordingly, is
to understand at least a bit about how those critical parts of the federal government go about
defending themselves.
The efforts of the Department of Defense (“DoD”) to defend itself can be broken down into two
categories: First, direct defense of its own networks and other systems that might constitute “blue
space.” Second, indirect efforts to boost the defense of private-sector actors that play an
important role in relation to national defense.
1. Securing the DoDIN
Not surprisingly, DoD is not subject to the OMB/CISA system of cybersecurity oversight that we
discussed in the last reading. Instead, DoD itself shoulders the responsibility for ensuring that its
own vast web of information systems and communication networks are defended appropriately.
That vast web is known, collectively, as the Department of Defense Information Network, or
“DoDIN” (pronounced “doh-din”). One commentator memorably described DoDIN as “really not
a single network, but a quasi-feudal patchwork of often incompatible local networks. It’s the Holy
Roman Empire of cyberspace.”
How does DoD organize to ensure the DoDIN is defended appropriately?
Start with the fact that the constituent elements of the DoDIN each belong to some constituent
element within DoD: a combatant command (for example, Central Command (CENTCOM)), a
service branch (for example, the Navy), a combat-support agency (for example, the Defense
Information Support Agency), and so forth. As Joint Publication 13-2 explains, each such entity is
authorized and has some capacity of its own “to take . . . defensive actions . . . and to restore the
system to a secure configuration.” Not all threats can be dealt with sufficiently by such “local”
resources, however, and in any event, many threats are not confined to a single entity’s systems.
This, plus the general need for higher levels of planning, coordination, and oversight, eventually

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

166

gave rise to the creation of a headquarters element focused on DoDIN defense: “JFHQ-DoDIN,”
which stands for Joint Forces Headquarters-DoDIN.
JFHQ-DoDIN is a “subordinate headquarters” within U.S. CYBERCOM (an organization we have
discussed some already, and will discuss more once we reach Unit II). It can assign “cyber
protection teams” as needed to assist in defense of the DoDIN, and it also can take charge or
coordinate as needed where multiple elements of the system are involved, or where there may
be spillover effects of other kinds.
In addition to this operational function, JFHQ-DoDIN also has an oversight/management function
analogous to that performed by OMB/CISA. On that dimension, JFHQ-DoDIN oversees the
owner/operators of the many component parts of the DoDIN as they engage in prospective riskassessment; aggregates and assesses the results from those efforts; and issues directives for
change where needed.
2. Beyond the DoDIN: Defending “Blue Space”
DoD uses the phrase “blue space” to describe cyber operational environments in which DoD is a
known and authorized presence. This includes, obviously, the DoDIN itself. But there are contexts
in which DoD may become a known and authorized defender. Collectively, the combination of
the DoDIN with these others constitute “blue space” environments.
“Blue space” is in contrast to operations that might occur on an adversary’s system (“red space,”
which includes any system the adversary has the ability to control to the exclusion of others), and
operations that might occur on the systems of third parties (“gray space,” which includes any
system not constituting blue space or red space).

•

Can you think of reasons why these distinctions matter?

Of course, the idea of DoD being asked to defend non-DoDIN systems raises a question about
when and how such requests occur. In contexts involving partner nations overseas, it typically is
as a government-to-government agreement. CYBERCOM personnel, for example, have assisted
countries including Montenegro, Ukraine, and North Macedonia via “hunt forward” missions
intended to identify malware targeting critical systems there. Consider this November 2019
account, from Shannon Vavra at CyberScoop:
U.S. European Command and U.S. Cyber Command are deploying an undisclosed
number of defensive cyber-operators to Montenegro in order to gain insights into
cyberthreats from adversaries before both the U.S. and Montenegrin elections next year.
It’s the second time in as many years the Department of Defense is going through the
effort as part of a partnership that’s uniquely poised to provide insights on possible Russian
election interference.
Montenegro and the U.S. both have been targeted by the Russian government-linked
hacking outfit APT28, or Fancy Bear. If Cyber Command uncovers similar activity again in
Montenegro, those insights could inform decisions on how to safeguard the U.S.
“Montenegro is among the first in Europe to face unconventional attacks on its
democracy and freedom of choice,” Montenegrin Defense Minister Predrag Boskovic
said in a statement. “It is precisely in the face of new challenges with the United States that

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

167

we seek a way, using their resources, to protect democracy in the Western Balkans from
those who would keep this part of Europe in conflicts, setbacks, and economic decline.”
In 2016 and 2017 Montenegro’s government agencies and media outlets were targeted
by several different cyberattacks that Montenegro has tied to APT28, one of the same
groups behind the 2016 Democratic National Committee breach.
When CyberScoop asked Cyber Command to detail lessons learned from last year and
what instructions American service members will be assigned while in Montenegro this
year, U.S. officials said only that they would be countering malicious actors on critical
networks. The U.S. service members are specifically focused on finding new and unknown
malware that could pose a threat to the U.S. or to Montenegro.
U.S. Secretary of State Mike Pompeo said last month the U.S. has been able to protect
against the latest Russian malware as a direct result of insights gathered from last year’s
collaboration. Russian hackers previously targeted Montenegro with spearphishing attacks
that could, for instance, yield technical data for its American allies.
“We’ve been able to develop a patch against the latest Russian malware that now
protects millions of devices worldwide,” Pompeo said during a trip to Montenegro’s
capital, Podgorica.
When the U.S. deployment ended last fall, Montenegro suggested resuming the
partnership, a Cyber Command spokesperson told CyberScoop. The Pentagon effort is
scheduled to end by the end of this year, they added.
The “hunt” continues…
These kinds of missions, known as “Hunt Forward” operations, are relatively new for Cyber
Command. Last year, along with Montenegro, Cyber Command also deployed
personnel to Ukraine and North Macedonia to collect insights into adversarial cyberthreats
in preparation for the 2018 midterm elections.
A Hunt Forward mission, which typically sends anywhere between five and 30 U.S. service
members to hunt for malware at a time, is broadly defined as an intelligence-gathering
one and a protection one.
“The team’s operations are part of efforts to persistently engage adversaries in
cyberspace, working to protect critical infrastructure alongside valued partners and
allies,” the Cyber Command spokesperson told CyberScoop, adding that they “also
generate insights into adversarial cyber threats to the upcoming U.S. and Montenegrin
elections in 2020.”
Montenegro also has been working to bolster its own efforts in other ways. It announced
last year it would be joining the North Atlantic Treaty Organization’s cyberdefense
center in Estonia, for example, which aims to boost information sharing among member
nations.
The announcement comes weeks after Russian President Vladimir Putin joked about the
prospect of interfering U.S. elections in 2020, saying “I’ll tell you a secret: Yes, we’ll definitely
do it. Just don’t tell anyone.”
This news also comes amid warnings from the U.S. intelligence officials that multiple
adversaries are seeking to interfere in the 2020 U.S. presidential election. While last year the

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

168

National Security Agency and Cyber Command jointly ran a task force to counter Russian
efforts to interfere in U.S. elections, that so-called Russian Small Group has since been
expanded to include fend off threats from Russia, China, Iran, and North Korea.
Aside from Montenegro, it is unclear what other countries Cyber Command may be
partnering with moving forward to run Hunt Forward missions. The Montenegro mission is
the only Hunt Forward operation ongoing right now. Earlier this year Cyber Command told
reporters it had ongoing deployments abroad with multiple allies, which it declined to
name. These have each ended at this time.
Almost exactly a year later, Julian Barnes at the New York Times had this assessment of morerecent “hunt forward” activities:
The United States Cyber Command expanded its overseas operations aimed at finding
foreign hacking groups before the election on Tuesday, an effort to identify not only
Russian tactics but also those of China and Iran, military officials said.
In addition to new operations in Europe to pursue Russian hackers, Cyber Command sent
teams to the Middle East and Asia over the past two years to help find Iranian, Chinese
and North Korean hacking teams and identify the tools they were using to break into
computer networks.
… Officials would identify only regions and not the countries they had operated in before
the 2020 election. But Cyber Command officials said those efforts uncovered malware
being used by adversarial hacking teams. Other government agencies used that
information to help state and local officials shore up their election system defenses and to
notify the public about threats.

•
•

Can you list the benefits that “hunt forward” activities yield for the United States?
What are the pros and cons of having the U.S. military perform this function, and are
there realistic alternatives?

When the context for non-DoDIN blue-space operations instead is domestic, things of course are
more complicated given the robust traditions, legal constraints, and political sensitivities that
combine to limit the role that the U.S. military normally can play in domestic life. That said, there
are contexts in which DoD personnel or equipment are used to assist civil authorities during an
exigency, particularly where the military has unique capabilities. DoD refers to this category of
activity, in general, as “Defense Support of Civil Authorities” (DSCA). It is the sort of thing that
comes up without much controversy during hurricanes or other natural disasters, but it can and
does extend to other contexts. These days, one such context is cyberspace.
The following passage, from a recent Government Accountability Office report, provides an
easy introduction to two statutory authorities that might result in CYBERCOM providing support to
civil authorities:
Under the Robert T. Stafford Disaster Relief and Emergency Assistance Act (the Stafford Act),
when state capabilities and resources are overwhelmed and the President of the United States
declares an emergency or disaster, the governor of an affected state can request assistance
from the federal government for major disasters or emergencies. The Stafford Act aims to
provide a means of assistance by the federal government to state and local governments in

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

169

responding to a presidentially declared major disaster or emergency. A governor’s request for
the President to declare a major disaster or emergency is required to be based on a finding
that the situation is of such severity and magnitude that effective response is beyond the
capabilities of the state and the affected local governments and that federal assistance is
necessary.
Additionally, under the Economy Act, a federal agency may request the support of another
federal agency, including DOD, without a presidential declaration of a major disaster or an
emergency. This act permits one federal agency to request goods and services from another
federal agency provided that, among other things, the service is available and cannot be
obtained more cheaply or conveniently by contract.

Consider these questions:
•
•

Can you explain why it is easier to rely on the Economy Act than the Stafford Act?
Can you explain how each might be the vehicle allowing CYBERCOM to extend its
defensive capabilities to the benefit of CISA, a state, or another entity?

•
Note: Any conversation on this topic inevitably comes around to some version of the question:
Doesn’t the Posse Comitatus Act (PCA) bar the military from having any involvement in domestic
affairs? That is a common, but incorrect, understanding of the PCA. It provides:
Whoever, except in cases and under circumstances expressly authorized by the Constitution
or Act of Congress, willfully uses any part of the Army or the Air Force as a posse comitatus or
otherwise to execute the laws shall be fined under this title or imprisoned not more than two
years, or both.

Can you explain why, in light of that language, CYBERCOM at least sometimes can provide
support to CISA, etc.? Try to identify two distinct reasons.

C. Cybersecurity for the Intelligence Community
What about protection of the information systems that carry the nation’s classified information
and other aspects of the intelligence enterprise, apart from the DoDIN? A key term-of-art for such
systems is “National Security Systems.” As noted above, the OMB/CISA role does not apply to such
systems, but they are not the exclusive province of the military either. Who defends them?
The answer is complicated, for various agencies within the Intelligence Community have their own
in-house capabilities with respect to the defensive aspects of cybersecurity. For our purposes, the
main thing to understand is that the NSA plays the most significant operational role in protecting
these networks.
Related to this is the Committee on National Security Systems. CSSS is an interagency body with
representation from 21 separate government agencies, tasked with setting national policy—and
issuing corresponding guidance and procedures—with respect to protection of National Security
Systems. NSA’s Director is the designated “National Manager” for this function, as one might
expect. Note that CSSS can and does issue directives with which agencies must comply, much
as CISA can for civilian systems and JFHQ-DoDIN can for military systems.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

170

19. Improving Cybersecurity for the Nation’s Critical infrastructure

Learning Objectives:
•
•
•
•
•
•
•

•
•

•
•
•
•
•
•

Appreciate why it is difficult to write a precise definition of “critical infrastructure”
Be able to state the statutory definition found in 42 USC 5195c(e), and to explain whether and
how some of its key terms are indeterminate
Understand how that indeterminacy leaves it to the executive branch to develop moreprecise descriptions of which entities are “in” and which are “out”
Know that PPD-21 adopted a 16-sector model of CI, and that it remains in force today
Understand that for most of those categories, there inevitably will be close-calls on the margins
Know that election systems were added to the list (as a sub-sector) only after the 2016 election,
and be able to explain why this step was controversial
Be able to explain why private-sector ownership of most CI gives rise to substantial difficulties
insofar as one might want to impose strict regulations on such entities (or even have NSA or
some other government entity play an operational role in defending the systems of such
entities)
Appreciate that CISA does not have general regulatory authority over CI entities vis-à-vis
cybersecurity; ponder whether it should
Understand that some CI sectors already are subject to the regulatory authority of some
sector-specific agency, including authority relating to cybersecurity (for example, think of the
FTC and Financial Services)
Be able to identify a few security-related consequences that do follow from a CI designation
(including the idea of having “priority” for certain government actions)
Understand that all CI entities are encouraged (but not required) to adopt the NIST
Cybersecurity Framework
Be able to give a general description of what the Framework is and why it might add value
for an entity
Be able to describe the various ideas that Michael Daniel summed up in his 2013 report on the
fruits of an interagency process that brainstormed concepts for improving CI cybersecurity
Understand why one might want there to be a subcategory of CI limited to the most-important
entities, and how this relates to the idea of “Section 9” entities
Be able to explain what consequences currently attach for an entity added to the Section 9
list, but also what other consequences might also apply one day (and be able to explain why
one might create the Section 9 list before adding those additional consequences)

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity
•

•
•

171

With respect to encouraging the Defense Industrial Base to defend itself better, be able to
explain the change introduced by the “Cybersecurity Maturity Model Certification”
(“CMMC”) system
Understand the importance of the “who is paying” question lurking beneath the surface of the
CMMC, and be able to explain how it appears this question will be answered
Ponder whether the same payment model would work in other “critical infrastructure”
contexts apart from the Defense Industrial Base

Most breaches involving systems owned or operated by the private sector do not implicate the
national interest in an acute way (though the cumulative effect of such breaches is a different
story). But when the system in question constitutes part of the nation’s “critical infrastructure,” then
by definition the stakes are higher. Our task: understanding which contexts “count” in this
particular way; which officers or institutions get to decide when such a context is present; and
what follows from such a determination.
A. What Counts?
Let’s begin by exploring the scope of the concept “critical infrastructure” (that is, “CI”). That
formerly obscure label is now commonplace. But what does it really mean?
At a high level of generality, “CI” captures that idea that our daily lives and the economy depend
to no small extent on certain particularly important systems, services, and structures. As DHS has
put it:
[C]ritical infrastructure provides the essential services that underpin American society and
serve as the backbone of our nation’s economy, security, and health. We know it as the
power we use in our homes, the water we drink, the transportation that moves us, the stores
we shop in, and the communication systems we rely on to stay in touch with friends and
family.

Consider these questions:
• Are the generalized examples mentioned in that second sentence all equally
“critical”? If not, rank them from most vital to least as you see it.
• What policy implications follow from the idea that some CI is more critical than others?

Now let’s get more specific. A federal statute (42 U.S.C. 5195c(e)) defines “critical infrastructure”
to mean:
[S]ystems and assets, whether physical or virtual, so vital to the United States that the
incapacity or destruction of such systems and assets would have a debilitating impact on
security, national economic security, national public health or safety, or any combination
of those matters.
In 2013, moreover, President Obama via Presidential Policy Directive 21 (“PPD-21”) split the general
category of CI into 16 distinct “sectors.” Here is the list as set forth on CISA’s page on this topic
(note how the list includes language identifying a “sector-specific agency” to be the lead
government agency for purposes of working with companies in that sector on security matters):
1. Chemical Sector

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

172

The Department of Homeland Security is designated as the Sector-Specific Agency for the
Chemical Sector.
2. Commercial Facilities Sector
The Department of Homeland Security is designated as the Sector-Specific Agency for the
Commercial Facilities Sector, which includes a diverse range of sites that draw large
crowds of people for shopping, business, entertainment, or lodging.
3. Communications Sector
The Communications Sector is an integral component of the U.S. economy, underlying the
operations of all businesses, public safety organizations, and government. The Department
of Homeland Security is the Sector-Specific Agency for the Communications Sector.
4. Critical Manufacturing Sector
The Department of Homeland Security is designated as the Sector-Specific Agency for the
Critical Manufacturing Sector.
5. Dams Sector
The Department of Homeland Security is designated as the Sector-Specific Agency for the
Dams Sector. The Dams Sector comprises dam projects, navigation locks, levees, hurricane
barriers, mine tailings impoundments, and other similar water retention and/or control
facilities.
6. Defense Industrial Base Sector
The U.S. Department of Defense is the Sector-Specific Agency for the Defense Industrial
Base Sector. The Defense Industrial Base Sector enables research, development, design,
production, delivery, and maintenance of military weapons systems, subsystems, and
components or parts to meet U.S. military requirements.
7. Emergency Services Sector
The Department of Homeland Security is designated as the Sector-Specific Agency for the
Emergency Services Sector. The sector provides a wide range of prevention,
preparedness, response, and recovery services during both day-to-day operations and
incident response.
8. Energy Sector
The U.S. energy infrastructure fuels the economy of the 21st century. The Department of
Energy is the Sector-Specific Agency for the Energy Sector.
9. Financial Services Sector
The Department of the Treasury is designated as the Sector-Specific Agency for the
Financial Services Sector.
10. Food and Agriculture Sector
The Department of Agriculture and the Department of Health and Human Services are
designated as the co-Sector-Specific Agencies for the Food and Agriculture Sector.
11. Government Facilities Sector
The Department of Homeland Security and the General Services Administration are
designated as the Co-Sector-Specific Agencies for the Government Facilities Sector.
12, Healthcare and Public Health Sector

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

173

The Department of Health and Human Services is designated as the Sector-Specific
Agency for the Healthcare and Public Health Sector.
13. Information Technology Sector
The Department of Homeland Security is designated as the Sector-Specific Agency for the
Information Technology Sector.
14. Nuclear Reactors, Materials, and Waste Sector
The Department of Homeland Security is designated as the Sector-Specific Agency for the
Nuclear Reactors, Materials, and Waste Sector.
15. Transportation Systems Sector
The Department of Homeland Security and the Department of Transportation are
designated as the Co-Sector-Specific Agencies for the Transportation Systems Sector.
16. Water and Wastewater Systems Sector
The Environmental Protection Agency is designated as the Sector-Specific Agency for the
Water and Wastewater Systems Sector.

Would you add anything to this list? What do you think does not belong?

PPD-21 also directed the Secretary of Homeland Security to update this list periodically. Normally,
such moves draw little attention. But just prior to the inauguration of President Trump in January
2017, DHS Secretary Jeh Johnson added election systems to the CI list for the first time (adding this
as a subsector in the “government facilities” category, alongside existing subsectors for
“education facilities” and “national monuments and icons”). Secretary Johnson explained:
I have determined that election infrastructure in this country should be designated as a
subsector of the existing Government Facilities critical infrastructure sector. Given the vital
role elections play in this country, it is clear that certain systems and assets of election
infrastructure meet the definition of critical infrastructure, in fact and in law. . . .
By “election infrastructure,” we mean storage facilities, polling places, and centralized
vote tabulations locations used to support the election process, and information and
communications technology to include voter registration databases, voting machines,
and other systems to manage the election process and report and display results on behalf
of state and local governments.
Prior to reaching this determination, my staff and I consulted many state and local election
officials; I am aware that many of them are opposed to this designation. It is important to
stress what this designation does and does not mean. This designation does not mean a
federal takeover, regulation, oversight or intrusion concerning elections in this country. This
designation does nothing to change the role state and local governments have in
administering and running elections.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

174

Consider these questions:
• Are you surprised that election infrastructure was not already covered?
• Why do you suppose it was not covered before, and for that matter, why do you
suppose some “state and local election officials” were “opposed to this designation”?
• The statement lists various things that will not happen as a result of the designation.
Does the scope of that list give you pause regarding the utility of making this
designation in the first place?

Let’s use a mini-case study to give you a richer feel for the breadth of the CI definition. Recall that
North Korea several years ago engaged in a massive hack of Sony Pictures Entertainment to
punish Sony for producing the comedy “The Interview.” Was that an attack on America’s critical
infrastructure, at least insofar as DHS CISA is concerned? To answer questions like that, you have
to be familiar with the “sector-specific plans” produced by DHS for each of the 16 CI sectors listed
above. If you read the sector-specific plan for the “Commercial Facilities” sector, you will find that
it includes a variety of more specific “sub-sectors,” including the following:
Entertainment and Media Subsector . . .
The subsector includes media production facilities (e.g., television and motion pictures),
print media companies (e.g., newspapers, magazines, and books), and broadcast
companies (e.g., television and radio stations). These outlets reach the general population
on a continuous basis and have a significant effect on the economy.
•

Should Sony Pictures Entertainment qualify? Make the case for or against, bearing in
mind the statutory definition of CI quoted earlier.

B. The Consequences of a CI Designation
What follows from a CI designation? Not as much as you might expect. One can imagine a world
in which this designation carries with it robust authorities for one or more government agencies
(CISA being the most likely candidate) to issue regulations compelling or forbidding certain things
relating to both cybersecurity and the physical aspects of security. As we have seen, after all,
CISA has exactly that sort of authority with respect to cybersecurity for U.S. government entities
(other than the military and intelligence agencies). And while it may seem unrealistic as a political
matter to grant any regulator such broad authority over the entirety of the private sector, it is not
hard to imagine treating CI-designated entities differently on this dimension.
For the most part, however, that is not how it works. A CI designation as such carries with it no
such general regulatory authority. Certain sectors may happen to be subject to regulation
(including cybersecurity-related regulation) already thanks to other statutes, but no further
authority follows from a CI designation.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

175

Consider these questions:
• Can you explain how the financial sector is an example of the point made in that last
sentence? Think back to the GLB Act and the Safeguards Rule.
• What are the best arguments for and against giving CISA broad authority to regulate
all CI-designated entities for cybersecurity (and physical security) purposes?
• Is there a good argument for giving such authority to each “sector-specific agency,”
even if not vesting all of it in CISA alone?
• Should CISA be given such authority as to all entities, period?
• Review: For an owner/operator of CI, what other incentive structures impact their
cybersecurity risk management decisions?
Since there is no general authority to regulate CI-designated entities, the question arises as to what
practical consequences follow from the designation. To answer, let’s take a close look at excerpts
from this Congressional Research Service report on the consequences of the decision to extend
CI status to election infrastructure. The report highlights three “notable consequences” from the
designation.
First:
It raised the priority for DHS to provide security assistance to election jurisdictions that
request it and for other executive branch actions, such as economic sanctions that the
Department of the Treasury can impose against foreign actors who attack elements of U.S.
CI, including tampering with elections.

Consider these questions:
• Does this mean that such assistance would not be provided otherwise?
• Does this mean that sanctions would not be imposed otherwise?
• Is there real value on this dimension?

We will further explore the question of services CISA might provide, below. For now, let’s
continue to note what the CRS report had to say about the consequences of a CI designation
for election systems. As the second example, the report explained that the designation
brings the subsector under a 2015 United Nations nonbinding consensus report (A/70/174)
stating that nations should not conduct or support cyber-activity that intentionally
damages or impairs the operation of CI in providing services to the public. It also states
that nations should take steps to protect their own CI from cyberattacks and to assist other
nations in protecting their CI and responding to cyberattacks on it. The report was the work
of a group of governmental experts from 20 nations, including Russia and the United States.

Consider these questions:
• Do you recognize this reference to the “Group of Government Experts” process that
we studied previously?
• Does this point have any practical significance? Be prepared to argue it both ways.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

176

Third, the report explained that the designation also
provided DHS the authority to establish formal coordination mechanisms for CI sectors and
subsectors and to use existing entities to support the security of the subsector. Those
mechanisms are used to enhance information sharing within the subsector and to
facilitate collaboration within and across subsectors and sectors.

Can you relate this to our prior study of information-sharing mechanisms, including ISACs?

Now, back to the aforementioned topic of services that CISA might provide to private sector
entities, and thus especially to CI-designated entities. Just what services might this include?
The list has grown significantly, in terms both of numbers and significance, in recent years. CISA
has produced a detailed catalog here, but our purposes the following chart—which we already
viewed previously in connection with services CISA can provide to other federal civilian
agencies—will suffice:
1. Continuous Diagnostics and Mitigation
2. Enhanced Cybersecurity Services (Domain Name System sinkholing; email filtering)
3. Hunt and Incident Response Team support (remote assistance; advisory deployment;
remote deployment; on-site deployment)
4. Advanced Malware Analysis Center
5. Distribution to the public of threat intelligence and other useful information (ex: the FY2019
RVA findings mapped to ATT&CK)
6. Vulnerability Scanning
7. Web App Scanning
8. Phishing Campaign Assessment
9. Remote Penetration Testing
10. Risk & Vulnerability Assessment
11. Cyber Resilience Review
12. External Dependencies Management Assessment
13. Cyber Infrastructure Survey
14. Cyber Security Evaluation Tool
15. Validated Architecture Design Review
Note: CISA has limited resources, and cannot possibly provide these services to all private CI
entities, or even to most of them.

•

Should Congress enact a tax-credit system designed to incentivize private CI entities
to seek more such services from private-sector security companies?

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

177

C. The NIST Cybersecurity Framework
Staying with the theme of information-sharing and voluntary improvements to security for
privately-owned CI entities, let’s turn now to a discussion of the “NIST Cybersecurity Framework.”
To understand its role, we need to go back to the 2013. On the same day that President Obama
issued PPD-21, he also issued Executive Order 13636. EO 13636 mostly focused on encouraging
voluntary information-sharing by CI owner/operators (it was, in that sense, a precursor to CISA
2015). But EO 13636 also sought to encourage better defense of CI entities via this measure:
Sec. 7. Baseline Framework to Reduce Cyber Risk to Critical Infrastructure.
(a) The Secretary of Commerce shall direct the Director of the National Institute of
Standards and Technology (the "Director") to lead the development of a framework to
reduce cyber risks to critical infrastructure (the "Cybersecurity Framework"). The
Cybersecurity Framework shall include a set of standards, methodologies, procedures,
and processes that align policy, business, and technological approaches to address cyber
risks. The Cybersecurity Framework shall incorporate voluntary consensus standards and
industry best practices to the fullest extent possible. . . .
(b) The Cybersecurity Framework shall provide a prioritized, flexible, repeatable,
performance-based, and cost-effective approach, including information security
measures and controls, to help owners and operators of critical infrastructure identify,
assess, and manage cyber risk. The Cybersecurity Framework shall focus on identifying
cross-sector security standards and guidelines applicable to critical infrastructure. The
Cybersecurity Framework will also identify areas for improvement that should be
addressed through future collaboration with particular sectors and standards-developing
organizations. To enable technical innovation and account for organizational differences,
the Cybersecurity Framework will provide guidance that is technology neutral and that
enables critical infrastructure sectors to benefit from a competitive market for products
and services that meet the standards, methodologies, procedures, and processes
developed to address cyber risks. The Cybersecurity Framework shall include guidance for
measuring the performance of an entity in implementing the Cybersecurity Framework.
Pursuant to that directive (and consistent with a similar directive from Congress that followed in
the Cybersecurity Enhancement Act of 2014), NIST published the first version of the Cybersecurity
Framework in February 2014, and then published an updated version in April 2018. The following
language (from the original 2014 version) explains what the Framework does—and does not—
aspire to do:
The Framework uses risk management processes to enable organizations to inform and
prioritize decisions regarding cybersecurity. It supports recurring risk assessments and
validation of business drivers to help organizations select target states for cybersecurity
activities that reflect desired outcomes. Thus, the Framework gives organizations the ability
to dynamically select and direct improvement in cybersecurity risk management. . . . The
Framework provides a common language for understanding, managing, and expressing
cybersecurity risk both internally and externally. It can be used to help identify and prioritize
actions for reducing cybersecurity risk, and it is a tool for aligning policy, business, and
technological approaches to managing that risk. . . . The Core is not a checklist of actions
to perform.”

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

178

Consider these questions:
• How is this similar to MITRE ATT&CK Matrix, and how is it different?
• Does EO 13636 purport to make private sector critical infrastructure owners legally
obligated to adopt and adhere to the Cybersecurity Framework?
• Should it do so?
• Is it feasible to create such an obligation via Executive Order, as opposed to
legislation?
• Does the existence of the Framework nonetheless cast a legal shadow of sorts, one
that might at least create incentives for CI owners? As you ponder that question, think
about how CISA 2015 anticipated and addressed parallel concerns.

An interagency study set to work brainstorming ideas for how to encourage voluntary adoption
of the NIST Framework. As summarized later in 2013 by Michael Daniel (President Obama’s
Cybersecurity Coordinator), the resulting ideas included:
•

•

•

•

•

Cybersecurity Insurance — Agencies suggested that the insurance industry be engaged
when developing the standards, procedures, and other measures that comprise the
Framework and the Program. The goal of this collaboration would be to build
underwriting practices that promote the adoption of cyber risk-reducing measures and
risk-based pricing and foster a competitive cyber insurance market. The Commerce
Department’s National Institute of Standards and Technology is taking steps to engage
the insurance industry in further discussion on the Framework. This process should
continue as the Framework is developed and the Voluntary Program is created.
Grants — Agencies suggested leveraging federal grant programs. Agencies suggest
incentivizing the adoption of the Framework and participation in the Voluntary Program
as a condition or as one of the weighted criteria for federal critical infrastructure grants.
Over the next six months, agencies will develop such criteria for consideration.
Process Preference — Agencies offered suggestions on a range of government programs
in which participating in the Voluntary Program could be a consideration in expediting
existing government service delivery. For example, the government sometimes provides
technical assistance to critical infrastructure. Outside of incident response situations, the
government could use Framework adoption and participation in the Voluntary Program
as secondary criteria for prioritizing who receives that technical assistance. The primary
criteria for technical assistance would always remain the criticality of the infrastructure,
but for non-emergency situations, technical assistance could be seen as an additional
benefit that could help to drive adoption. Agencies currently have the authority to act in
these areas without further legislation. As we work with the private sector over the next six
months to develop the Voluntary Program, we will simultaneously identify and examine
specific programs where this approach could be helpful
Liability Limitation — Agencies pointed to a range of areas where more information is
necessary to determine if legislation to reduce liability on Program participants may
appropriately encourage a broader range of critical infrastructure companies to
implement the Framework. These areas include reduced tort liability, limited indemnity,
higher burdens of proof, or the creation of a Federal legal privilege that preempts State
disclosure requirements. As the Framework is developed, agencies will continue to
gather information about the specific areas identified in the reports related to liability
limitation.
Streamline Regulations — Agencies will continue to ensure that the Framework and the
Voluntary Program interact in an effective manner with existing regulatory structures. As
the Framework and Voluntary Program are developed, agencies will recommend other
areas that could help make compliance easier, for example: eliminating overlaps

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

179

among existing laws and regulation, enabling equivalent adoption across regulatory
structures, and reducing audit burdens.
Public Recognition — Agencies suggested further exploration on whether optional public
recognition for participants in the Program and their vendors would be an effective
means to incentivize participation. DHS will work with the critical infrastructure community
to consider areas for optional public recognition as they work together to develop the
Voluntary Program.
Rate Recovery for Price Regulated Industries — Agencies recommended further dialogue
with federal, state, and local regulators and sector specific agencies on whether the
regulatory agencies that set utility rates should consider allowing utilities recovery for
cybersecurity investments related to complying with the Framework and participation in
the Program.
Cybersecurity Research — Once the Framework is complete, agencies recommended
identifying areas where commercial solutions are available to implement the Framework
and gaps where those solutions do not yet exist. The government can then emphasize
research and development to meet the most pressing cybersecurity challenges where
commercial solutions are not currently available.

•

•

•

•

Be prepared to review the pros and cons of these ideas.

Along those same lines, consider Section 8(e) of EO 13636:
[T]he Secretary of Defense and the Administrator of General Services . . . shall make
recommendations to the President . . . on the feasibility, security benefits, and relative
merits of incorporating security standards into acquisition planning and contract
administration.
•

Can you identify any CI sectors that appear particularly ripe for this approach?

D. Section 9 Entities (“Critical Infrastructure at Greatest Risk”)
Up to this point, we have treated all CI equally, even as we defined the category broadly. But of
course, CI entities are not all equally significant to the nation; nuclear power plants have more
strategic significance than shopping malls, for example. EO 13636 recognized this, carving out a
subcategory of particularly important CI that we will refer to as “Section 9 entities” (so named for
Section 9 of EO 13636, which establishes the category and which we will examine below). Our
goals are to understand the test for qualifying as a Section 9 entity, what consequences follow
from that designation, and what the arguments for and against taking a more proscriptive
approach might be.
First, let’s look at the test for qualifying as a Section 9 entity:
Sec. 9. Identification of Critical Infrastructure at Greatest Risk.
(a) . . . the Secretary shall use a risk-based approach to identify critical infrastructure where
a cybersecurity incident could reasonably result in catastrophic regional or national
effects on public health or safety, economic security, or national security.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

180

Applying that test, should the following entities qualify (and if you need more information,
what information might that be)?
• nuclear power plant
• hospital that is one of three in a town with 75,000 residents
• shopping mall
• single voting machine

Next, let’s have a look at the consequences that follow from receiving this designation. For that,
we need to look at EO 13636 Section 10:
(a)

Agencies with responsibility for regulating the security of critical infrastructure shall
engage in a consultative process with DHS, OMB, and the National Security Staff to
review the preliminary [NIST] Cybersecurity Framework and determine if current
cybersecurity regulatory requirements are sufficient given current and projected
risks. In making such determination, these agencies shall consider the identification
of critical infrastructure required under section 9 of this order. . . .

(b)

If current regulatory requirements are deemed to be insufficient, . . . agencies
identified in subsection (a) of this section shall propose prioritized, risk-based,
efficient, and coordinated actions . . . to mitigate cyber risk.

(c)

. . . agencies identified in subsection (a) of this section shall, in consultation with
owners and operators of critical infrastructure, report to OMB on any critical
infrastructure subject to ineffective, conflicting, or excessively burdensome
cybersecurity requirements. This report shall describe efforts made by agencies,
and make recommendations for further actions, to minimize or eliminate such
requirements.

…
(e)

Independent regulatory agencies with responsibility for regulating the security of
critical infrastructure are encouraged to engage in a consultative process with the
Secretary, relevant Sector-Specific Agencies, and other affected parties to
consider prioritized actions to mitigate cyber risks for critical infrastructure consistent
with their authorities.

Consider these questions:
• Can you sum up the function of each of these subsections?
• Can you think of further steps that could have been taken vis-à-vis Section 9 entities,
without needing legislation?

It may be tempting to dismiss the combination of Sections 9 and 10 as having little bite. And
perhaps that characterization is accurate. But note that it was thought significant enough, at the
time, to warrant certain limitations. First, Section 9 itself expressly prohibits this status to
“commercial information technology products” and “consumer information technology services.”

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

•

181

What sort of businesses might fall within those categories? Why exempt them?

Separately, Section 9(c) provides that (1) any entity designated as a Section 9 entity shall receive
notice of the designation as well as of “the basis for the determination,” and (2) DHS must establish
a process for which the owner/operators of such entities may then seek reconsideration.

•

Why?

That was 2013. What has happened since then? Most recently, in May 2017, President Trump
issued Executive Order 13800, Section 2 of which addresses cybersecurity in the CI context. We’ll
look first at Section 2(b), which is focused on Section 9 entities. In relevant part it provides:
The Secretary of Homeland Security, in coordination with the Secretary of Defense, the
Attorney General, the Director of National Intelligence, the Director of the Federal Bureau
of Investigation, the heads of appropriate sector-specific agencies, . . . and all other
appropriate agency heads, as identified by the Secretary of Homeland Security, shall:

•

(i)

identify authorities and capabilities that agencies could employ to support the
cybersecurity efforts of . . . section 9 entities . . .;

(ii)

engage section 9 entities and solicit input as appropriate to evaluate whether and
how the authorities and capabilities identified pursuant to subsection (b)(i) of this
section might be employed to support cybersecurity risk management efforts and
any obstacles to doing so;

(iii)

provide a report to the President . . . that includes . . . findings and
recommendations for better supporting the cybersecurity risk management efforts
of section 9 entities [based on the above inquiries].

How would you characterize this intervention?

Next, look at Section 2(c), which is not limited to Section 9 entities, but is limited to CI entities that
are owned by a publicly-traded company:
The Secretary of Homeland Security . . . shall provide a report to the President . . . that
examines the sufficiency of existing Federal policies and practices to promote appropriate
market transparency of cybersecurity risk management practices by critical infrastructure
entities, with a focus on publicly traded critical infrastructure entities.

•

Can you explain how such an approach might drive improvements to security?

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

182

E. Case Study: Using Contract Leverage to Drive Change in the Defense Industrial Base
There is one critical infrastructure sector where the government has adopted a novel approach
in an effort to drive systematic improvements in private-sector cybersecurity practices: the
Defense Industrial Base (the “DIB”).
As CISA explains here, the DIB is:
… the worldwide industrial complex that enables research and development, as well as
design, production, delivery, and maintenance of military weapons systems, subsystems,
and components or parts, to meet U.S. military requirements. The Defense Industrial Base
partnership consists of Department of Defense components, more than 100,000 Defense
Industrial Base companies and their subcontractors who perform under contract to the
Department of Defense, companies providing incidental materials and services to the
Department of Defense, and government-owned/contractor-operated and
government-owned/government-operated facilities.
DIB companies routinely deal with classified information, of course, and towards that end typically
have access to government-defended networks designed for that purpose, such as SPIRNet (the
Secret Internet Protocol Router Network). But DIB companies also handle a large amount of
“controlled unclassified information” (“CUI”), meaning information that is not actually classified
but nonetheless should not be made public according to legal or policy directives. The
government has a strong interest in encouraging DIB companies to optimize the security of systems
that handle CUI.
How best to accomplish this? The DIB, by definition, depends extensively on securing government
contracts. Accordingly, this CI sector is particularly amenable to incentives or mandates that the
government might choose to build into those contracts.
The idea of using that leverage to push DIB companies to enhance their cybersecurity efforts is
not novel. DIB contracts are governed by a complex set of regulations that comprise the military’s
standard “acquisition” process: the Defense Federal Acquisition Regulation Supplement (or simply
“DFARS”). In 2016, a rule was added to DFARS requiring would-be contractors to certify that they
had implemented the aforementioned NIST Cybersecurity Framework model of cyber risk
management. The new rule also required these companies to query their own supply chains,
moreover, to find out whether they complied with the NIST framework (and if not, why not). Finally,
the rule also required contractors to give DoD notice within 72 hours in the event of a cyber
incident.
So far so good. But there was a problem: the new DFARS rule did not include a mechanism for
actually vetting these representations before the contract was let, and only limited resources were
available for post-agreement auditing (to be performed by the Defense Contract Management
Agency (DCMA)). In short, the model depended primarily on trust.
Perhaps not surprisingly, this proved ineffective, and DoD eventually began exploring a more
aggressive approach. This led to adoption of what is known as the “Cybersecurity Maturity Model
Certification” (“CMMC”) process.
The idea behind the CMMC is to establish a sliding-scale set of cybersecurity obligations that a
would-be DIB contactor must meet (with the scale demanding more from the entity in
accordance with the sensitivity of the data the entity will have), and to require each such business
to secure a third-party certification of compliance in order to be eligible to receive a contract.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

183

Who will provide those third-party certifications of compliance? That remains to be seen, but the
general idea is to rely on a private sector market for such services rather than tasking an arm of
the Defense Department with doing the work. Towards this end, DOD has contracted with a
newly-created private entity—the “CMMC Accreditation Body”—designed to control the process
of vetting and, well, certifying would-be “CMMC Third Party Assessor Organizations” (C3PAOs).
What does certification cost at the various maturity levels, and who will pick up that bill? It’s too
soon to say how much certifications might cost, but we do know this: DIB companies will be
allowed to include these costs as part of their contract bid, if they wish. Note, too, that the
certifications are meant to be good for three-year periods.

•
•
•
•

The certification process presents a scalability issue. Can you explain how so?
Is it optimal to leave certifications to the private sector?
Are you concerned about the costs involved, both in absolute terms and relative to
the likely value-added from this process?
Could some version of this model be used with other CI sectors?

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

Electronic copy available at: https://ssrn.com/abstract=3547103

184

Chesney on Cybersecurity

185

D. Organizing to Mitigate Harm
Our final defense-oriented topic concerns the process by which the federal government
orchestrates its response when significant cyber incidents occur.

20. Federal Coordination and Significant Cyber Incidents

Learning Objectives
•

•

•

•

Appreciate that there does not have to be a standing set of rules regarding the process for
developing a coordinated interagency response for the federal government (things can be
handled on an ad hoc basis, after all); be able to articulate the advantages of predetermining such questions, however
Needed, or not, President Policy Directive 41 (PPD-41, from 2016) established such a standing
process (the public record does not yet reveal whether the Trump administration has
preserved this framework, though we do know that the administration abolished the Special
Advisor to the President position previously described as the White House “cybersecurity czar”)
Understand that the point of the “Significant Cyber Incident” concept is to guide the decision
on whether a particular incident warrants activation of the federal government’s interagency
system for response coordination under PPD-41
Appreciate that the definition is quite vague (probably by design, since there’s something to
be said for leaving it to the personnel involved to exercising their own judgment on this
question, and since it would be hard to articulate a more-precise test anyway)

From a certain point of view, almost any cybersecurity incident could be said to be a matter of
federal government interest. Many will involve a possible violation of the Computer Fraud and
Abuse Act, after all, so at least federal law enforcement agencies would have a stake in the
situation. And the sum total of the harms that flow from such incidents certainly rises to a level
that warrants a serious and well-considered policy response from the federal government. Only

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

186

a small percentage of these incidents will warrant, on their own, a coordinated federal
interagency response.
This reading focuses on those relatively-rare but important situations. What processes has the
federal government developed over time to regularize interagency (and, for that matter, publicprivate) coordination? And how does this relate to the question of how the federal government
might coordinate across agencies on common questions of policy relating to cybersecurity?
Note that there is no requirement that there be any such formal coordinating mechanisms. In
many policy contexts, coordination in response to particular events occurs in an ad hoc way,
often (though not always) working through general-purpose executive branch procedures (such
as those associated with the National Security Council). Sometimes, however, recurring
experience with coordination needs relating to a particular topic results in adoption of “standing”
committee structures and related procedures. The recurring issue of terrorism spawned such a
response, for example, and as we will see below this is true to some extent with cybersecurity too.
A. Is PPD-41 Still With Us?
The public record regarding the Trump Administration’s approach to interagency coordination
of cybersecurity matters remained unclear over the years. We do know, however, that the
administration eliminated the White House “cybersecurity coordinator” position. Consider this
report from May 2018, from Brian Barrett at Wired:
A LITTLE OVER a month ago, the White House forced out Tom Bossert, its cybersecurity
czar. A week later, cybersecurity coordinator Rob Joyce said he would depart as well.
And now, rather than replace either, the Trump administration will do without anyone at
the helm of its cybersecurity policy. It couldn’t have picked a worse time.
The news that the newly appointed national security adviser John Bolton has decided to
phase out the cybersecurity coordinator role was first reported by Politico. In place of a
single point person in charge of guiding and shaping US cyber policy, the task will now
fall instead to two National Security Council senior directors. The NSC did not respond to
a request for comment.
“At a minimum, this decision and the way that it’s being communicated send the wrong
signal,” says J. Michael Daniel, who served as cybersecurity coordinator under President
Barack Obama and currently heads up the Cyber Threat Alliance nonprofit. “Certainly I
think that our adversaries could interpret that as a signal that this administration doesn’t
take the issue as seriously, regardless of if that’s actually their intent.”
In fairness, there’s nothing sacred about the cybercoordinator role, specifically. It didn’t
exist before the Obama administration, and other corners of the NSC get along fine with
a similar leadership structure to what Bolton has imposed. But the nature of cyberthreats,
and the broad responsibilities Bossert and Joyce took on, seem particularly in need of
centralized command.
“I think it’s probably fair that there’s more policy work to be done right now on cyber
than in certain other areas, because it is in a formative stage,” says Joshua Geltzer,
former senior director for counterterrorism at the NSC and executive director of
Georgetown Law School’s Institute for Constitutional Advocacy and Protection. “You’re
at a point where you’re seeing new sorts of cyberthreats materialize.”

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

187

While US intelligence agencies are responsible for responding to those threats
specifically, the cyberczar role has been in charge of organizing the political responses
to those incidents, such as the March sanctions imposed against Russia for its destructive
NotPetya ransomware and other online malfeasance. The position has also
spearheaded cybersecurity policy, hardening both federal networks and infrastructure
against attacks. It’s a lot of hats—and easier for one person to keep track of them all.
“There’s a reason why you wanted to have a focal point for cybersecurity policy in one
position. I think that’s a very valuable thing to have,” says Daniel.
Political leaders have expressed their concerns over the move as well. “It’s frankly
mindboggling that the Trump Administration has eliminated the top White House official
responsible for a whole-of-government cyber strategy, at a time when the cyber threat
to our nation is greater than ever,” says senator Mark Warner (D - Virginia), the ranking
member of the Senate Intelligence Committee, in a statement.
Indeed, there's been a demonstrable uptick in cyberattacks. In a Congressional briefing
in February, the heads of the NSA, CIA, FBI, and ODNI all testified that Russia would
continue its attempts to interfere in US democracy. North Korea unleashed WannaCry
ransomware on the world a year ago, and has been continually emboldened online.
And with the US withdrawal from the Iran nuclear deal, cybersecurity experts warn that
the country could once again target its sophisticated cyberattacks at the US.
“If anything, our enemies are only going to do more, not less,” says Daniel.
To face those challenges—as well as those from independent criminal actors—without a
coherent cybersecurity policy in place invites unease.
“Big picture, it certainly seems to send a strange message as to how this White House is
prioritizing something most of us think the government needs to prioritize more, when it
comes to cyberpolicy,” says Geltzer.
The true impact of the move may not become apparent for some time. In response,
House Democrats Tuesday introduced a bill that would create a National Office for
Cyberspace, with a director confirmed by the Senate. It's unclear what chance it might
have of passing. And for now, either way, fewer capable people will be focused on bigpicture cybersecurity issues at the highest level of government than there were before.
It's hard to see how that makes for an improvement.
It was not clear whether other aspects of the Obama administration’s approach to coordination
also were significantly altered, and in particular whether the Trump administration altered the
basic model created by President Obama’s Presidential Decision Directive 41 (PPD-41, “United
States Cyber Incident Coordination”), from 2016. Indeed, for this reason among others,
Congress eventually felt obliged to intervene by creating a major new position within the
Executive Branch (based on the recommendation of the Congressionally-chartered Cyber
Solarium Commission): the National Cyber Director.
Here is my overview of the NCD position, written for Lawfare just prior to enactment of the
statute establishing the position in December 2020 (section 1752 of the National Defense
Authorization Act for Fiscal Year 2021, to be precise):
1. What are the problems that warrant creation of the national cyber director position?
The Cyber Solarium Commission identified an array of problems that creation of an NCD
might address. I’ve distilled them into the following four areas of concern:

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

188

The National Cyber Strategy
The federal government has produced national cyber strategy documents in the past
(see the current National Cyber Strategy from 2018, and note too the 2016 Cybersecurity
National Action Plan, the 2009 Cyberspace Policy Review and the 2008 Comprehensive
National Cybersecurity Initiative). The commission observed that the process for
producing and updating such a strategy is not well institutionalized, however; no
particular official or office has lead responsibility for performing this function on a
recurring basis.
The commission also observed that we lack a process for monitoring whether the policies
and budgets of relevant federal agencies align with the current National Cyber Strategy.
Thus, if federal agencies work at cross-purposes or fail to make needed budget
commitments, it is not obvious who in the federal government has ultimate responsibility
for spotting such problems and wrangling recalcitrant entities back into line. The Trump
administration exacerbated this problem in 2018 when it eliminated a White House staff
position that came closest to fulfilling that role. More on that in the very next point.
Presidential Advising
The commission also emphasized the desirability of having a clearly identified adviser to
the president dedicated to cybersecurity matters (as well as to related issues at the
intersection of technology and national security, such as 5G or internet governance). Of
course, there had been such an adviser at one point, in the form of the special assistant
to the president position known as the cybersecurity coordinator. In 2018, however,
National Security Adviser John Bolton eliminated that position. Bolton asserted at the time
that there was no need for such a dedicated position because responsibility for the topic
was diffused throughout the NSC apparatus. This sparked criticism, to put it mildly.
Interagency Coordination
The demise of the cybersecurity coordinator position in 2018 also took away the most
natural official to manage interagency coordination as to both cybersecurity policy
formation and, especially, incident response. Even when the cybersecurity coordinator
position was in place, however, some argued that the position lacked the stature,
statutory authority and staff support to carry out those functions as effectively as one
might wish.
Speaking at Home and Abroad With a Single Voice
The commission also noted the desirability of having a single officer empowered to serve
as the nation’s authoritative voice (apart from the president, of course) in
communications with external audiences (both domestic and foreign) regarding the
collective position of the executive branch on cybersecurity topics.
2. Which authorities would NDAA Section 1752 confer on the NCD?
The version of the NCD envisioned by Section 1752 addresses each of the areas
emphasized by the commission but in some key respects is less ambitious than what the
commission had in mind.
Stature

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

189

One area in which Section 1752 certainly makes good on the commission’s vision has to
do with the stature of the office. In contrast to the old cybersecurity coordinator position,
the NCD would be a Senate-confirmed official (nominated by the president, of course,
and subject to removal at the president’s discretion). And the NCD would, by statute,
become a principal of the National Security Council. The NCD’s pay scale would be set
with reference to Level II of the Executive Schedule (comparable to officials such as the
CIA director and various departmental secretaries). The Office of the NCD, moreover,
would be authorized to have a staff of up to 75 persons and would be situated within the
Executive Office of the President. In short, the NCD and the Office of the NCD would
resemble the structure of the Office of the United States Trade Representative, albeit with
a smaller scale.
Presidential Advising
Turning to the authorities conferred on the NCD, Section 1752 starts in a complex vein. It
makes the NCD “the principal advisor to the President on cybersecurity strategy and
policy,” but with strings attached. Instead of leaving it in those general terms, the
provision describes this as a role specifically “relating to the coordination of” certain
cybersecurity topics (emphasis added).
Which topics? Some are exactly what you would expect, such as “information security
and data privacy.” Others are a bit more interesting, though, because they directly
implicate the equities of other agencies. For example, the list includes “efforts to
understand” malicious cyber activity and to “deter” such activity, as well as “diplomatic
and other efforts to develop norms and international consensus around responsible state
behavior in cyberspace.” These are core concerns of the National Security Agency, the
CIA, U.S. Cyber Command and the State Department; hence, the decision to identify the
NCD as the president’s principal adviser on those topics would be a recipe for turf wars
(ones the NCD would be poorly positioned to win) if not for the qualifying language I
highlighted above, accentuating that the NCD’s particular function is to advise the
president regarding coordination, not to act as the principal adviser about those realms
of activity as such.
Formation of National Strategy and Policy
Section 1752 falls short of the commission’s vision for an NCD with lead authority over the
process of updating the National Cyber Strategy and forming national policy positions
relating to cybersecurity. Under Section 1752(c)(1)(B), the NCD’s role is limited to the
ability to “offer advice and consultation” to, well, everyone in the federal government
with equities relating to cybersecurity. The language doesn’t require anyone else to listen
to that advice, let alone to follow it. Nor does it describe the NCD as the statutorily
required instigator of, or shepherd for, such processes. Which is not to say that the NCD
will not have significant influence in such matters; it’s just that such influence will have to
be earned through persuasion, rather than demanded as-of-right.
Implementation of National Strategy and Policy
The commission’s hopes for a strong NCD fare somewhat better when it comes to a
separate function relating to national strategy and policies: conducting centralized
oversight to ensure that agencies operate in alignment with those strategies and policies
once they are in place. In fact, the opening lines of Section 1752(c)(1)(C) seem rather
strong on this point, describing the NCD as lead agency for “coordination of

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

190

implementation” of national strategies and policies. But, once again, the devil is in the
details. That same subsection goes on to specify exactly what the NCD’s leadership role
entails, and it arguably isn’t much.
Four of the particular authorities listed here boil down to this: The NCD can observe and
advise, but cannot force other agencies to change their policy, resource and personnel
practices. More specifically, these four authorities provide that the NCD may:
•
•
•
•

Monitor the effectiveness of implementation efforts (including their “costeffectiveness”).
Give advice to agency/department heads regarding personnel, budget,
organization, etc.
Review agency budgets for consistency with national policies/strategies and give
advice to the agency heads on where they may be falling short.
Assess the “integration and interoperability” of various Federal cyber centers advise
the President on needed changes.

At this point, it is worth noting that Section 1752 does deal something of a wild card to
the NCD. Subsection 1752(e)(3) rather casually mentions that the NCD shall have power
to “promulgate such rules and regulations as may be necessary to carry out the
functions, powers, and duties vested in the Director.” A bold NCD might seek to leverage
this power to articulate and entrench broad interpretations of the aforementioned
authorities.
Pruning Federal Policies, Guidelines and Regulations
Section 1752(c)(1)(C)(v) directs the NCD to “coordinate” with the attorney general, the
federal chief information officer, the director of the Office of Management and Budget,
the director of national intelligence, and the director of the Cybersecurity & Infrastructure
Agency (CISA) in order to “streamlin[e] … Federal policies and guidelines” and
“regulations relating to cybersecurity.” The bill does not specify the precise purpose of
such “streamlining” efforts, but it does refer in part to existing federal law concerning the
information security practices of federal agencies. For most government agencies, CISA
already performs the role of key overseer of their information security practices. Agencies
operating “national security systems” are separate from that authority, however. Hence,
one possible justification for assigning a coordinating role to the NCD in this area is to
ensure there is an official empowered to think about all government systems in the
round, as it were. At any rate, the key thing is to appreciate that this is just a coordination
role, not one that empowers the NCD to compel agencies to take particular actions.
Interagency Coordination for Incident Response: Developing Plans, Executing Plans
The commission’s vision for the NCD fares well when it comes to interagency
coordination for incident response. The idea of an integrated response, to be clear, is not
the novelty here (see the “Cyber Unified Coordination Group” system adopted in PPD-41
in 2016). The novelty, rather, is in the allocation of such authority to a statutorily
empowered office and then the spelling out of various specific steps that the office must
carry out as part of that mission. Section 1752(c)(1)(D) accomplishes this by directing the
NCD to:
•

Establish (in coordination with relevant agencies) “operational plans, processes, and
playbooks” governing incident response (including, intriguingly, a specific directive to
ensure that “defensive” plans and capabilities are integrated with “offensive” plans

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

•
•
•

191

and capabilities—which sounds to me like a requirement to ensure that plans
account for U.S. Cyber Command’s potential role).
Ensure that those plans are “exercised[.]”
Ensure all of it is updated as needed.
Ensure that the plans involve proper coordination with the private sector.

What about implementation of those plans? The same section describes the NCD as
having responsibility for “ensuring implementation” of them, but it does not elaborate on
the point. On the other hand, the very next subsection (1752(c)(1)(E)) appears to address
the topic in a way that puts the NCD in a potentially powerful position.
Specifically, Section 1752(c)(1)(E) provides for the NCD to lead in “preparing the
response by the Federal Government” to qualifying cyber incidents, and it further states
that the NCD should develop (in coordination with the national security adviser and
heads of relevant agencies) “operational priorities, requirements, and plans” (emphasis
added by me). Further, Subsection (E) specifies that the NCD must ensure agencies
execute those plans properly.
No doubt there will be frictions in practice as future NCDs test the boundaries of this role
in the context of particular cases.
Which cyber incidents rise to the level that trigger such an NCD-led interagency
response?
This part of Section 1752 is especially intriguing.
The status quo, under PPD-41, uses the label “significant cyber incidents” to describe the
subset of cyber incidents that warrant formal interagency coordination (in contrast to
run-of-the-mill incidents as to which one or more federal entities might have a role, but
for which a coordinated interagency response is not necessary). And PPD-41 explains
that incidents qualify for that label when they are “likely to result in demonstrable harm to
the national security interests, foreign relations, or economy of the United States or to the
public confidence, civil liberties, or public health and safety of the American people.”
That is a sensible, but indeterminate, definition.
NDAA Section 1752 makes changes. First, it replaces “significant cyber incidents” with a
nearly identical—but longer—label (that is, “cyber attack or cyber campaign of
significant consequence”). Second, and more important, it defines that category more
broadly (though still quite loosely). According to 1752(g)(2), an incident(s) qualifies if its
“purpose or effects” is to:
(A) Significantly disrupt the confidentiality, integrity, or availability of any federal
information system.
(B) Harm or otherwise significantly compromise the functioning of any computer
supporting any entity that is part of a critical infrastructure sector (notice that this is not
limited to the “Section 9 entities” subcategory but rather reaches the full spectrum of
critical infrastructure entities, and that it does not matter whether the computer in
question is important to the entity).
(C) Otherwise significantly compromise the ability of a critical infrastructure entity to
provide services.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

192

(D) Steal “significant” funds or economic resources, trade secrets, personal identifiers, or
financial information, when done for private financial gain or for
commercial/competitive advantage.
(E) Otherwise constitute a “significant threat to the national security, foreign policy, or
economic health or financial stability of the United States.”
There’s a lot going on there, and plainly much of that is of indeterminate scope. That
said, it seems to me much broader than the “significant cyber incident” category under
PPD-41. It covers any hack of a federal computer, it covers a potentially vast number of
run-of-the-mill identity theft and economically motivated crime situations, and it covers
interference with computers belonging to critical infrastructure entities where the
computer might not be very important (and where, for that matter, the entity itself might
not be that important; remember, this is not limited to Section 9 entities). None of which is
necessarily a bad thing, mind you; it is better to be overinclusive than underinclusive in
this space.
Annual Reports and Other Communication/Representation Functions
Apart from a final, general charge to perform such other functions as the president may
direct, the only other significant duty conferred on the NCD is to report annually to
Congress on the cybersecurity threat environment and related matters, and to report to
the president, the national security adviser and Congress regarding the state of U.S.
cybersecurity.
3. What issues and questions remain?
The NDAA’s version of the NCD is not all that the commission had in mind. But it will do
much good and should be enacted.
The demise of the cybersecurity coordinator position in 2018 demonstrated that the
president cannot always be trusted to perceive the importance of this topic (well, that
might not have been the only clue, but it underscored the point in a particularly relevant
way). Even when that position existed, however, it did not have the institutional clout,
statutory authorities and staff support that the NCD would have. Passage of Section 1752
would address all of that to a very helpful degree, and with authorities that go some way
toward addressing the problem areas the commission perceived.
True, Section 1752 does not do everything the commission hoped it would. As noted
above, the NCD would not own the National Cyber Strategy process (and other national
policy and strategy processes) to the same degree the commission envisioned. And
note, too, that despite language in 1752(c)(2)(A) confirming that the NCD may be
included in preparing for and participating in “domestic and international summits and
other international meetings at which cybersecurity is a major topic,” the legislation
would not make the NCD the executive branch’s default voice, or an independent
voice, in such matters (indeed, a separate section specifies that any such participation
by the NCD “shall” be “in coordination with the Secretary of State”). But it’s more than
half a loaf, and much better than no loaf.
One point of sensitivity that I have not mentioned yet is whether the various directives to
the NCD to serve as a point of contact coordinating with the private sector (including
especially, it would seem, critical infrastructure entities) raises an important question
about deconfliction with the role of the director of CISA. Building relations with the

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

193

private sector, and especially the owners/operators of critical infrastructure entities, is a
central purpose for CISA and a key part of the director’s job. It is not hard to imagine
how an NCD might encroach significantly on that territory if great care is not taken in
developing a modus vivendi between these offices.
A final note, picking up a point I made above: It will be especially interesting to see what
an NCD will be able to make of the aforementioned authority to act as the president’s
principal adviser on the coordination of “efforts to understand and deter malicious cyber
activity.” Such efforts entail some of the nation’s most sensitive intelligence collection
capabilities as well as the increasingly important category of operations undertaken by
U.S. Cyber Command under its “defend forward” concept. If the NCD and the
CYBERCOM commander have a strong relationship, I suppose this might work.
To the future NCD team: Good luck!
There is now a National Cyber Director: Chris Inglis, a widely-respected, longtime-NSA official. But
Director Inglis is not the only major figure within the Executive Office of the President with a key
role in shaping the interagency aspects of cybersecurity matters for the Biden administration.
Before Director Inglis was in position, the Biden administration decided to create a new position
in the National Security Council structure, one focused expressly on this area: the Deputy
National Security Advisor for Cyber and Emerging Technology. Biden appointed another wellregarded NSA veteran—Anne Neuberger—to this position. It is likely that Inglis and Neuberger will
work very well together, given there past experience with one another. Whether the coexistence of these institutional innovations will work as well in the future, with other personnel,
remains to be seen.
B. Coordination/Deconfliction Challenges in an Interagency Setting
Bearing in mind the multiplicity of federal departments and agencies that have authorities and
capabilities that might be relevant in the context of a cybersecurity incident, an important
question arises: Should there be a formal process for coordinating (and, when needed,
deconflicting) the efforts of those departments and agencies—that is, a process that is
established in advance and might even be the subject of training and practice so that it can
run as smoothly as possible in the event of an emergency? Or, instead, is it best to leave such
matters to be worked out on an ad hoc basis as circumstances may dictate?

•

•
•

Can you think of problems that might arise if no formal coordination/deconfliction
process exists? Consider that question both from the point of view of various federal
agencies as well as from the perspective of the private sector (especially the
perspective of a private sector victim)
Identify the pros and cons of establishing a coordination process in advance.
Be sure to consider what the alternative to this would be.

PPD-41 reflects a judgment that ex ante establishment of coordination mechanisms is a good
idea. That framework to some extent is woven into the National Cyber Incident Response Plan
(a DHS document intended to distill the legal and policy frameworks applicable to a national
cyber incident in order to provide a clear common understanding and basis for training). Our
task, accordingly, is to explore the key moving parts so that you can be conversant in this model.
First, note that a key element of interagency coordination involves deconfliction with respect to
those agencies that have similar capabilities and responsibilities relating to a particular function

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

194

that will tend to be part of the government’s response to a cyber incident. Simply put, it might
help if a particular agency is designated in advance as the “lead agency” for each such
function.
PPD-41 does this by identifying three “lines of effort” for federal agencies, and naming a particular
entity as “lead agency” for each. Consider first the three lines of effort:
In responding to any cyber incident, Federal agencies shall undertake three concurrent
lines of effort: threat response; asset response; and intelligence support and related
activities. . . .
A. Threat response activities include conducting appropriate law enforcement and
national security investigative activity at the affected entity’s site; collecting evidence
and gathering intelligence; providing attribution; linking related incidents; identifying
additional affected entities; identifying threat pursuit and disruption opportunities;
developing and executing courses of action to mitigate the immediate threat; and
facilitating information sharing and operational coordination with asset response.
B. Asset response activities include furnishing technical assistance to affected entities to
protect their assets, mitigate vulnerabilities, and reduce impacts of cyber incidents;
identifying other entities that may be at risk and assessing their risk to the same or similar
vulnerabilities; assessing potential risks to the sector or region, including potential
cascading effects, and developing courses of action to mitigate these risks; facilitating
information sharing and operational coordination with threat response; and providing
guidance on how best to utilize Federal resources and capabilities in a timely, effective
manner to speed recovery. . . .
C. Intelligence support and related activities facilitate the building of situational threat
awareness and sharing of related intelligence; the integrated analysis of threat trends
and events; the identification of knowledge gaps; and the ability to degrade or
mitigate adversary threat capabilities.

•
•

Is each line of effort limited to actions that are responsive to an ongoing or completed
incident, or are some proactive? If the latter, which ones?
Notice the very last clause quoted above (“and the ability to degrade”). Can you
think of some examples that would fall under this heading? And does this complicate
the issue of lead-agency responsibility for that category?

Next, consider PPD-41’s selection of lead-agency designations:
[T]he following agencies shall serve as Federal lead agencies for the specified line of effort:
1. In view of the fact that significant cyber incidents will often involve at least the
possibility of a nation-state actor or have some other national security nexus, the
Department of Justice, acting through the Federal Bureau of Investigation and the
National Cyber Investigative Joint Task Force, shall be the Federal lead agency for
threat response activities.
2. The Department of Homeland Security, acting through [CISA], shall be the Federal lead
agency for asset response activities.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

195

3. The Office of the Director of National Intelligence, through the Cyber Threat
Intelligence Integration Center, shall be the Federal lead agency for intelligence
support and related activities.
Designation of lead agencies helps, but it does not exhaust the range of possibilities for
coordination. What about coordination among the lead agencies? What about coordination
between the government and the private sector? What about other government agencies that
might have a key role to play?
To address such questions, PPD-41 borrows the concept of a “Unified Coordination Group”
(“UCG”) from other emergency-response settings. The idea behind a UCG is to establish a
committee structure that will be inert most of the time, but that can be called into being as
needed with predetermined membership and responsibilities.
PPD-41 provides that a “Cyber Unified Coordination Group … shall serve as the primary method
for coordinating between and among Federal agencies in response to a significant cyber incident
as well as for integrating private sector partners into incident response efforts, as appropriate.”
The UCG shall act to ensure inclusion of all relevant agencies in the response effort, coordinate
the planning and execution of both response and recovery tasks, coordinate international and
cross-sector outreach, facilitate information-sharing, and coordinate communications with
impacted parties as well as the public. If the incident has physical effects, moreover, the UCG is
to combine its efforts with the relevant lead agency or interagency group managing those
consequences.
Who has a seat at the table with a Cyber UCG? PPD-41 specifies that the group should include
each of the lead agencies for threat response (FBI), asset response (DHS-CISA), and intelligence
support (ODNI), along with any relevant sector-specific agency insofar as the incident concerns
a critical infrastructure sector. The UCG also may include other federal agencies, agencies at the
state/local/tribal levels, NGOs, international partners, and private-sector entities.
Note that, because some of these roles are predetermined and others foreseeable, it is possible
to conduct training exercises to simulate UCG functions. Indeed, this is perhaps the greatest
advantage of having the UCG model as the default framework for incident-response
coordination. CISA convenes such exercises periodically under the name “Cyber Storm,” and
includes a growing array of private-sector participants in them. See here for after-action reports
generated by past Cyber Storm exercises, if you wish to explore this in more detail (unfortunately,
the reports from the 2018 and 2020 exercises are not yet available to the public).
Given that many incidents will present close calls as to whether a UCG ought to be convened,
who decides that question? PPD-41 provides:
A Cyber UCG shall be formed at the direction of the NSC Principals Committee, Deputies
Committee, or the CRG, or when two or more Federal agencies that generally participate
in the CRG, including relevant SSAs, request its formation. A Cyber UCG shall also be
formed when a significant cyber incident affects critical infrastructure owners and
operators identified by the Secretary of Homeland Security as owning or operating critical
infrastructure for which a cyber incident could reasonably result in catastrophic regional
or national effects on public health or safety, economic security, or national security.
Note the phrase “significant cyber incident,” which I emphasized with bold font above. This is a
term of art under PPD-41 and the National Cyber Incident Response Plan, designed to distinguish
between run-of-the-mill incidents (where there is no need for federal coordination, though one

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

196

or more federal agencies (such as the FBI) might still be involved) and those important enough
to warrant interagency coordination.
What, then, makes an incident “significant” in this sense? Here’s what PPD-41 has to say:
A. Cyber incident. An event occurring on or conducted through a computer network
that actually or imminently jeopardizes the integrity, confidentiality, or availability of
computers, information or communications systems or networks, physical or virtual
infrastructure controlled by computers or information systems, or information resident
thereon. For purposes of this directive, a cyber incident may include a vulnerability in
an information system, system security procedures, internal controls, or implementation
that could be exploited by a threat source.
B. Significant cyber incident. A cyber incident that is (or group of related cyber incidents
that together are) likely to result in demonstrable harm to the national security interests,
foreign relations, or economy of the United States or to the public confidence, civil
liberties, or public health and safety of the American people.
The National Cyber Incident Response Plan supplements that definition with this schema

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

197

What is (are) the key element(s) in the PPD-41 definition?
Does the NCIRP schema actually help clarify things?
Is definitional precision actually important here, or might vagueness be useful?

•
•
•

PPD-41 includes an important caveat:
The Cyber UCG is intended to result in unity of effort and not to alter agency authorities or
leadership, oversight, or command responsibilities. Unless mutually agreed upon between
agency heads or their designees, and consistent with applicable legal authorities such as
the Economy Act of 1932 (31 U.S.C. 1535), Federal departments and agencies will maintain
operational control over their respective agency assets.

Can you anticipate problems that might arise under this heading?
For a recent example of a Cyber Unified Coordination Group being convened to address a
significant cyber incident, consider the March 2021 announcement concerning vulnerabilities
discovered in connection with Microsoft Exchange (vulnerabilities that were exploited on a
massive, reckless scale by hackers acting for China). As the White House press secretary
explained:
Last week the National Security Council (NSC) established a Unified Coordination Group
(UCG), a task force composed of representatives from the FBI, CISA, and ODNI, with
support from the NSA, to drive a whole-of-government response to the Microsoft Exchange
vulnerabilities. On Monday, the NSC convened a UCG leadership meeting, which included
private sector members for the first time, coordinating our respective response efforts. We
invited the private sector partners based on their specific insights to this incident, an
approach the NSC will take going forward as appropriate. The UCG discussed the
remaining number of unpatched systems, malicious exploitation, and ways to partner
together on incident response, including the methodology partners could use for tracking
the incident, going forward.
A final note: PPD-41 also calls for the existence of a separate interagency coordinating body:
the Cyber Response Group (“CRG”). As set forth in part II.A. of the Annex to PPD-41, CRG’s duties
are to:
i.

Coordinate the development and implementation of the Federal Government’s
policies, strategies, and procedures for responding to significant cyber incidents;

ii.

Receive regular updates from the Federal cybersecurity centers and agencies on
significant cyber incidents and measures being taken to resolve or respond to
those incidents;

iii.

Resolve issues elevated to it by subordinate bodies [more on this below] . . .;

iv.

Collaborate with the Counterterrorism Security Group and Domestic Resilience
Group when a cross-disciplinary response to a significant cyber incident is required;

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

198

v.

Identify and consider options for responding to significant cyber incidents, and
make recommendations to the Deputies Committee, where higher-level guidance
is required . . .; and

vi.

Consider the policy implications for public messaging in response to significant
cyber incidents, and coordinate a communications strategy, as necessary,
regarding a significant cyber incident.

Who has a seat this table? Any agency can be invited to participate, but as a general matter
the CRG should include:
senior representatives from the Departments of State, the Treasury, Defense (DOD), Justice
(DOJ), Commerce, Energy, Homeland Security (DHS) and its National Protection and
Programs Directorate, and the United States Secret Service, the Joint Chiefs of Staff, Office
of the Director of National Intelligence, the Federal Bureau of Investigation, the National
Cyber Investigative Joint Task Force, the Central Intelligence Agency, and the National
Security Agency.
CRG meetings are chaired by the “Special Assistant to the President and Cybersecurity
Coordinator . . . or an equivalent successor,” and they “shall convene on a regular basis and as
needed.”

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

199

II. THE OFFENSIVE PERSPECTIVE
We’ve been defense-focused up to this point, in the specific sense of surveying the institutions,
laws, and policies intended to deter, punish, and mitigate the consequences of unauthorized
access. For better or worse, however, limiting unauthorized access is not always the ultimate
policy goal. In the U.S. system, some institutions, laws, and policies promote (or at least tolerate)
offense—that is, efforts to penetrate or interfere with a system without its owner’s authorization (or,
perhaps, awareness). For the sake of convenience, we might call this lawful-but-unauthorized
access (meaning lawful from a U.S. perspective; needless to say, such activity may well violate
the laws of other countries when they occur overseas).
You will note immediately, I hope, that the very idea that this category exists appears at first blush
to be in considerable tension with the policy goals advanced by, well, pretty much everything we
studied in Unit I. Why, then, should there even be such a category? We will explore that question
across several contexts.
To a substantial extent, lawful-but-unauthorized access frameworks rest on the seeminglycounterintuitive claim that they can, in the right circumstances, promote security. We see this, for
example, in the “hackback” scenario, in which some advocate empowering the private sector
to respond to an attack with self-help measures that will have effects outside their own networks
(that is, effects on the attacker’s network or, more likely, effects on intermediary networks from
which an attack has been staged). And we see this as well with the portion of U.S. Cyber
Command’s mission that entails out-of-network operations in “gray space” and “red space”
conducted with the intent to identify, disrupt, or prevent adversary efforts to hack U.S. or allied
systems. It is in this sense that Unit I opened with a note regarding the affirmative use of
unauthorized access methods to promote “defense.”
But the case for lawful-but-unauthorized access does not have to rest entirely on that defensiveminded ground. In some cases, in fact, lawful-but-unauthorized access frameworks are intended
to serve goals that are simply distinct from cybersecurity. We see this with law enforcement
investigations intended to solve (or prevent) crimes of all sorts; with collection of foreign
intelligence (that is, espionage) on a vast array of topics; with promotion of U.S. foreign policy
goals via covert action; and with military operations both within and outside the context of armed
conflict.
Our aim in this unit is to survey each of those scenarios, with an emphasis on the key institutions,
policy conflicts, and legal frameworks.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

200

21. Lawful-But-Unauthorized Access: Private Sector Self-Defense?

Learning objectives
•
•

•
•
•
•
•

•

Be able to explain the uncertainty associated with words and phrases like “hackback” and
“active defense”
Understand that the policy problem undergirding the “hackback” debate has to do with the
relative difficulty of securing rapid and effective government help in the context of a cyber
attack (relative, that is, to the speed and efficacy of government help when a physical-space
robbery or other such harm occurs); be able to account for why this difference exists
Be able to identify an array of responses a private-sector victim might wish to pursue, either in
real time or even ex ante, in response to an attack
Understand which of these measures are permissible under the CFAA, which clearly are not,
and which ones have an unclear status
Understand what CISA 2015 did and did not make clear
Be able to articulate the arguments for and against amending the law further to reduce the
disincentives for hacking back in various ways
Understand that the AC/DC Act has not yet passed Congress, and may never pass Congress,
yet still provides a useful case study as to the difficulty of pruning the legal constraints in this
area
Be able to distinguish “attributional measures” from more-aggressive forms of active defense

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity
•
•

201

Appreciate why attackers might route their operations through compromised third-party
servers, and why this greatly complicates the policy and the legal aspects of hackback
Appreciate that pruning CFAA criminal liability without likewise pruning its civil liability
provisions might result in insufficient change to the incentives the private sector faces (though
that turns in large part on whether the fact pattern in question implicates impacts on third
parties rather than just the attacker).

Are there circumstances in which we want someone in the private sector to be able to access
another’s system without their permission? We just completed a long unit focused on how the
United States discourages that sort of thing—including by imposing criminal and civil liability under
the CFAA—so the idea of instead tolerating or even encouraging it at first blush seems jarring. The
issue proves to be complicated, however, when we ask this question in the specific context of a
hacking victim hoping to respond in self-defense (i.e., “hackback”).
In recent years there has been considerable debate regarding both the extent to which certain
defensive measures are permissible in light of the CFAA (as well as CISA 2015’s “defensive
measures” provision), and whether and how it might be desirable to prune back the CFAA in order
to remove disincentives for potential or actual hacking victims to protect themselves in new (or at
least newly legal) ways.
A. Defining Terms
Before we proceed, we should note that there is some disagreement regarding the proper
meaning of the term “hackback.” Some use it to refer to any defensive measure adopted by a
potential victim where the measure will have a downstream effect inside an adversary’s system.
On that view, even a simple beacon would count. Others would reserve the term for more
aggressive forms of self-defense, limiting it to measures that have a disruptive effect on the
adversary’s system or that provide the victim (or whomever is assisting the victim, for the victim
may turn to an outside security vendor for help) with ongoing unauthorized access to some part
of that system. Those who take this narrower view sometimes distinguish between “hackback”
and “active defense,” with the latter referring to less-aggressive measures (like beacons) that are
not disruptive and that do not provide ongoing access. On the other hand, you sometimes will
see the phrase “active defense” used more broadly to span across this entire category. The
important point, at any rate, is that you should make sure to make clear how you are using these
labels, and likewise that you understand how others use them.
For the sake of convenience, I will use “hackback” as a catch-all phrase meant to encompass
the entire category of self-defense measures that might have an effect within the attacker’s own
system.
Now we can proceed. Let’s first identify the competing policy considerations at work in the
hackback debate, and then move on to consider the challenges that arise once one decides to
prune the CFAA in hopes of encouraging at least some forms of hackback.
B. Understanding the Competing Policy Considerations
Let’s use a hypothetical scenario in order to bring to light the competing policy considerations
that drive the debate over hackback.
Assume an OPM-like scenario involving a private-sector business which we will call Cuckoo’s
Eggnog Company (or simply “Cuckoo”). You are Cliff, the CEO.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

202

Cuckoo’s Chief Information Security Officer (“CISO”) has just notified you of an unfolding incident:
“Bad news, Cliff. Somebody’s inside our network. Looks like they phished the creds of
someone on my team, and they’ve been logging in remotely at night with admin privileges.
We’re still sorting out what they’ve been up to, but so far know that they’ve been scouting our
files, and clearly took an interest in our secret formulas for next year’s new products. Anyway,
looks like our uninvited guest copied some key files, including that database we created
regarding customer preferences. He or she got it all stored in a particular spot under an
innocuous name, and compressed with an eye towards a quiet, gradual exfiltration. And,
well, looks like they went ahead and extracted it this morning. But it’s not all bad news. We’re
pretty sure we have the IP address of the server they sent those files to. And…well, you
know…we’ve got some smart folks on our team. I think we could try some…creative things to
get our stuff back. If you want to.”
By this time, your general counsel has joined the meeting. He has a nervous look on his face.
“What exactly do you have in mind?” he asks the CISO.
“Well, for starters I’d like to do some scanning, see if maybe this server they’re using has some
known vulns we might be able to use.”
“Use for what, exactly?”
“That’s up to y’all. But, strictly hypothetically speaking, maybe I could delete their copy of our
data and files.”
You perk up. “You can do that?”
Encouraged by your interest, the CISO leans in. “Oh yeah, for sure. Or I could leave it all there,
but stick in an extra file, something with a tempting title but a little surprise. They’ll eventually open
it, and when they do it’ll phone home, giving me an IP address that would help us know if they
moved these files somewhere else.”
You are definitely tempted. Before you can answer, though, she continues: “But you know what
would be even better? Let’s hit these jerks with some ransomware. Or maybe just delete
everything on their system!”
Your CISO is smiling now, but your general counsel is not.
“Whoa, slow down! I think we should call the cops, and leave this to the pros.”
The CISO rolls her eyes. “Oh right, yes, that will be super helpful. Give me a break. You don’t
know who to call, and even if you did it would be too late by the time they tried to do anything.
Let me fix this while we still can, Cliff. I can do it right now.”

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

•
•
•
•
•
•
•

203

Make a list of the distinct actions the CISO has suggested.
For each one, what exact benefits might it provide? Think in terms of both the
company and society.
Is it likely that government action could produce that same benefit?
If you were to seek government help, whom would you call?
Now identify potential negative consequences, apart from legal liability.
Does the balance of pros and cons (again setting aside legality) favor taking any of
these steps?
Now assess the legality of each of these steps under the CFAA (bearing in mind, too,
the “defensive measures” provision in CISA 2015).

For a real-life example of someone hacking back, consider the story of Tobias Frömel, a German
citizen who suffered a ransomware attack but then managed to access the attacker’s
command-and-control server and extract from it the information he needed to generate
decryption keys needed by nearly 3,000 other victims. As Lawrence Abrams at Bleeping Computer
reported, Frömel reached out to potential victims with this message:

hey guys,
good news for you all, bad news for me cause i paid already... maybe someone can give
me a tip for my hard work ^^
my wallet: 1JrwK1hpNXHVebByLD2te4E2KzxyMnvhb

i hacked back this criminal and get the whole database with keys, here it is:
https://pastebin.com/N8ahWBni

decryption software:
https://mega.nz/#!O9Jg3QYZ!5Gj8VrBXl4ebp_MaPDPE7JpzqdUaeUa5m9kL5fEmkVs

manual:
upload to nas:
"chmod +x decrypt"
"sudo ./decrypt YOURDECRYPTIONKEY"

and yeah, i know it was not legal from me too but he used already hacked servers with
several webshells on it... and im not the bad guy here :D

but its really sad, i lost 670 € to this criminal :'(

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

204

cheers
battleck aka tobias frömel

Note that the manual on computer crimes published by DOJ CCIPS (which is not legally binding,
but is a convenient expression of DOJ policy) includes an express admonition discouraging victims
of a hack from responding in kind:
Do Not Hack into or Damage the Source Computer
Although it may be tempting to do so (especially if the attack is ongoing), the company should
not take any offensive measures on its own, such as “hacking back” into the attacker’s
computer—even if such measures could in theory be characterized as “defensive.” Doing so
may be illegal, regardless of the motive. Further, as most attacks are launched from
compromised systems of unwitting third parties, “hacking back” can damage the system of
another innocent party. If appropriate, however, the company’s system administrator can
contact the system administrator from the attacking computer to request assistance in
stopping the attack or in determining its true point of origin.

•

Does this change your analysis above?

C. Changing the Law to Encourage Hackback?
Some members of Congress (led by Rep. Tom Graves of Georgia) have proposed legislation
designed to encourage certain hackback measures, though no such bill has yet become law.
The best example is the proposal known as the “Active Cyber Defense Certainty Act”—that is, the
“AC/DC Act.” Let’s have a close look at its key provisions, which appear in the text below, in order
to appreciate the difficulties involved in amending federal law to create more space for such selfdefense measures. Just remember: this bill has not yet become a law; this is just an exercise to
help us grapple with the practical challenges.
The AC/DC Act, if passed, would have created more legal space for hackback in two distinct
ways. First, it would have clarified the legality of using what the bill calls “attributional
technologies.” Second, it would have provided legal protection for a separate category of
activity it calls “active cyber defense measures.” Let’s explore those in order.
1. “Attributional Technology”
Section 3 of the bill aimed to clarify the legality of using beacons, among other “attributional
technologies.” To achieve that end, it would have amended the CFAA to include this language:
Exception For The Use Of Attributional Technology.—
(1)

[Section 1030(a)] shall not apply with respect to the use of attributional technology
in regard to a defender who uses a program, code, or command for attributional
purposes that beacons or returns locational or attributional data in response to a
cyber intrusion in order to identify the source of an intrusion; if—
(A)

the program, code, or command originated on the computer of the
defender but is copied or removed by an unauthorized user; and

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

(B)

•
•

205

the program, code, or command does not result in the destruction of data
or result in an impairment of the essential operating functionality of the
attacker’s computer system, or intentionally create a backdoor enabling
intrusive access into the attacker’s computer system.

Review: Did CISA 2015 already address this?
What are the pros and cons of the proposed AC/DC Act approach?

Note that Section 3 provided a definition of “attributional data”:
The term ‘attributional data’ means any digital information such as log files, text strings,
time stamps, malware samples, identifiers such as user names and Internet Protocol
addresses and metadata or other digital artifacts gathered through forensic analysis.”

•

Is that definition too narrow, too broad, or just right?

Of course, hacking back can involve more than just beacons and the like. What about more
aggressive measures?
2. “Active Cyber Defense Measures”
Section 4 of the bill addressed a category of activity labeled “active cyber defense measures”
(ACDMs). ACDMs were defined to include, as a default matter, any measure that is:

•
•

(I)

undertaken by, or at the direction of, a defender; and

(II)

consist[s] of accessing without authorization the computer of the attacker … to
gather information in order to—
(aa)

establish attribution of criminal activity to share with law enforcement and
other United States Government agencies responsible for cybersecurity;

(bb)

disrupt continued unauthorized activity against the defender’s own
network; or

(cc)

monitor the behavior of an attacker to assist in developing future intrusion
prevention or cyber defense techniques; but

Focus first on subsection (aa): How (if at all) is this different than Section 3’s
“attributional technology” concept, which we just examined?
Now focus on subsections (bb) and (cc): What are the pros and cons of providing
legal protection for activities of that kind?

If you found the scenarios described in (bb) or (cc) to be too broad, you might be comforted to
know that the bill actually went on to articulate a long list of limitations on which otherwise-

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

206

qualifying activities would be eligible for ACDM status. I list each of those seven limitations below,
pausing after each one to pose questions. An otherwise-eligible measure could not qualify for
ACDM status after all if it:
(I)

•
•
•

intentionally destroys or renders inoperable information that does not belong to
the victim that is stored on another person or entity’s computer;

Does this foreclose deletion of files copied from the victim’s system?
What about files copied from the system of some other victim?
What if the victim/defender in good faith believes a file is a copy of its own data and
hence deletes it, but this turns to be mistaken?

(II)

recklessly causes physical injury or financial loss . . .;

Is this a proper limitation? Why not limit the statute to intentional harms? Or expand it to
include negligent harms?

(III)

•

Go back to our hypothetical example involving Cuckoo’s Eggnog Company, and
imagine you are the general counsel. Consider whether you can clearly define the
terms “threat,” “public health,” and “public safety,” and then consider how the
answer to that question might impact your analysis of subsection (III) and the advice
you accordingly might give to Cliff.

(IV)

•
•

intentionally exceeds the level of activity required to perform reconnaissance on
an intermediary computer to allow for attribution of the origin of the persistent
cyber intrusion;

What do you suppose is meant by “intermediary computer”?
How will the victim/defender know that the system in question is an “intermediary”?

(V)

•

creates a threat to the public health or safety;

intentionally results in intrusive or remote access into an intermediary’s computer;

Is this exception consistent with the bill’s effort to permit beacons or even more
aggressive forms of active defense?

(VI)

intentionally results in the persistent disruption to a person or entity’s internet
connectivity resulting in damages . . .; or

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

•
•
•

Why have an exception for this scenario?
How do we know when disruption becomes “persistent”?
At what point does slowing performance count as “disruption”?
(VII)

•

207

impacts any computer … regarding access to national security information, …
regarding government computers, or … regarding a computer system used by or
for a Government entity for the furtherance of the administration of justice, national
defense, or national security;

Why have this exception?

Now that we have a handle on what sorts of activities would count under Section 4 as ACDMs
(if, indeed, it is possible to have a handle on that), the question becomes: What legal
consequences would have followed for ACDMs if the AC/DC Act had become law? The
answer is that Section 4 of the Act would have created an affirmative defense to criminal liability
under the CFAA—though not also to civil liability—for qualifying ACDMs:
(1) GENERALLY.—It is a defense to a criminal prosecution under this section that the
conduct constituting the offense was an active cyber defense measure.
(2) INAPPLICABILITY TO CIVIL ACTION.—The defense against prosecution created by this
section does not prevent a United States person or entity who is targeted by an active
defense measure from seeking a civil remedy, including compensatory damages or
injunctive relief pursuant to subsection (g).

•
•
•

Why remove criminal, but not civil, liability?
Does this defeat the purpose of the bill?
What is the effect of making ACDM status an “affirmative defense” to CFAA liability,
as opposed to stating in the statute that the CFAA’s scope does not extend to the
ACDM scenario?

Another wrinkle: Even if the hackback in question otherwise would qualify as an ACDM, the
AC/DC Act would not have been available in all scenarios. For better or worse, in fact, the bill
specified that ACDMs could be used only where the entity doing the hacking back is “a victim of
a persistent unauthorized intrusion of the individual entity’s computer.”

•
•

Was it wise to limit Act in this way?
How many instances must there be, and of what duration, in order to count as
“persistent”?

There’s one final caveat. In order to get the benefit of the ACDM defense, a qualifying “defender”
also would have to follow a special notification regime. Section 5 specified that a

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

208

defender who uses an active cyber defense measure under the preceding section must
notify the FBI National Cyber Investigative Joint Task Force and receive a response from
the FBI acknowledging receipt of the notification prior to using the measure. . . .
Notification must include the type of cyber breach that the person or entity was a victim
of, the intended target of the active cyber defense measure, the steps the defender plans
to take to preserve evidence of the attacker’s criminal cyber intrusion, as well as the steps
they plan to prevent damage to intermediary computers not under the ownership of the
attacker and other information requested by the FBI to assist with oversight.

•
•
•
•
•

What is the point of requiring such notification?
Does the prospect of a resulting delay before action can occur defeat the purpose of
creating a pathway for private use of ACDMs?
What sort of burdens does this place on FBI’s NCIJTF?
Does this notification regime create any risk of unintended consequences, from the
point of view of a foreign government who is aware of the notification system and then
detects a U.S.-based, private-sector actor using ACDMs against it?
All things considered: Should Congress pass a statute along the lines of the AC/DC
Act?

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

209

21. Government Hacking: Law Enforcement

Learning Objectives
•

•
•

•

•

•
•

•

Appreciate that “government hacking” is not some stand-alone activity that occurs
independent of a given agency’s mission; agencies seek such capabilities for the same reason
they seek any other capability—to execute their mission, whatever that mission may be
Be able to describe the array of government interests where hacking plainly has become an
important part of the toolkit (law enforcement, espionage, warfighting, covert action, etc.)
Understand that criminal law investigation routinely entails privacy invasion even in the
physical realm, and that we have developed a complex body of constitutional, statutory, and
other legal rules—and corresponding institutions (especially courts)—to simultaneously enable
but also constrain such actions
Understand that the topic of law enforcement hacking is *not* concerned with rogue
investigators using hacking in violation of those frameworks, but rather regular investigations
that are carried on under the authority of those frameworks and where there proves to be a
practical need to try hacking in order to overcome a technical obstacle to accessing the
information the government is lawfully-authorized to get (exactly as the government might use
lock-picking, or a ram to force open a door, to overcome the practical obstacle of a locked
door in the course of executing a warrant)
Know how the rise of encryption for communications gave FBI its original motivation to develop
an ability to hack: unable to decipher encrypted communications in transit, FBI physically
installed keylogging malware on a target’s desktop so as to be able to get his key
Understand that FBI switched later to phishing-style distribution in order more efficiently deliver
such malware
Ponder whether you are comfortable relying on the generally-applicable legal regimes that
protect privacy from criminal investigation, or if instead you feel that online-investigative
methods such as these present special challenges warranting a further set of constraints
Understand the difference between whether we should limit or otherwise regulate the ability
of law enforcement entities to hack as a way to execute a warrant or other lawfully-authorized
process for seeking evidence of a crime, and whether there should be a statute that in some

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

•
•
•

•
•

210

way limits how far the makers of communication systems and devices can go when it comes
to engineering those systems or devices to be secure
Understand that the “Going Dark” issue concerns the latter
Be able to state arguments in favor of, and against, legislation of that kind, and form your own
view on the matter
Understand that, in the Apple vs FBI dispute, FBI was seeking a court order to compel Apple to
assist it in executing a search warrant; it was not a situation involving a request for legislation
from Congress
Know that a growing number of US-based communications-related companies are moving
towards default end-to-end encryption
Be able to explain how this trend relates to the policy dispute surrounding law enforcement
purchases of services/capabilities from the insecurity industry

Up to this point we have been considering the potential desirability and legality of allowing
private-sector entities to hack in certain circumstances. But what about the government itself?
A. What Policy Goals Might Government Hacking Serve?
Let’s begin by identifying some of the overarching policy goals that might be advanced by
allowing certain government agencies latitude to hack. Here is a non-exhaustive list of possibilities:
1.
2.
3.
4.
5.

Law Enforcement:
Espionage:
Armed Conflict:
“Gray zone” Competition:
Nonconsensual Defense:

hack to gather evidence of crime
hack to steal foreign-intelligence information
hack in direct relation to an armed conflict
hack to cause effects on foreign adversaries short of war
hack to patch or defend others involuntarily

In each case listed above, the general idea is that in some circumstances it might be efficient for
the government to pursue certain policy goals via hacking (as opposed to having to rely on the
various other methods otherwise available to the government).

Can you imagine a hypothetical example, for each category, in which hacking might be
the most efficient way for the government to proceed?
Knowing that hacking might sometimes be convenient for the pursuit of important policy goals
only starts the analysis, of course. Government hacking might entail offsetting costs, too.

For each of your hypothetical examples, can you identify at least one cost or risk that use of
a hacking approach (in contrast to some other approach) might entail?
Insofar as the costs or risks seem to outweigh the benefits of government hacking in at least some
of these circumstances, the question then becomes whether we can reduce those costs and risks
to a tolerable level by adopting various rules and procedures intended to facilitate government
hacking while safeguarding against anticipated harms. Bear that in mind through the remainder
of the readings, as we survey the circumstances in which U.S. government institutions currently
have (or might one day have) authority to hack.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

211

We will proceed in the same order as the list above, beginning with government hacking to gather
evidence of crime.
B. Law-Enforcement Hacking
In the abstract, criminal investigation can be understood as a sometimes-complex process of
gathering information and then applying some combination of expertise, reason, and analytic
technique to gain insight from it. In today’s world, that information-gathering function often entails
seeking access to data that is “at rest” (running the gamut from a business’s records to
communications that are stored on some server or device) or that is “in motion” at the time of
acquisition (think, for example, of wiretapping to gain access to the content of an email).
The government’s legitimate criminal law investigative interests are in tension, of course, with the
privacy interests of the persons and entities whose data and communications might be at issue.
Not surprisingly, the United States has developed a fairly elaborate legal framework to mediate
that tension.
1. A Thumbnail Sketch of the Legal Framework for Criminal Investigations; or, Why Hack?
The Fourth Amendment to the Constitution of the United States is a foundational part of that
framework. It has two key parts. First, it requires that all government actions constituting a
“search” be “reasonable.” In practical terms, that means in most cases the government first must
obtain a “warrant” from a judge before conducting a “search.” Second, the Fourth Amendment
also specifies that judges may not issue a warrant unless the government has provided a sworn
statement that is sufficient to establish “probable cause” that the search will yield evidence of (or
fruits from) a crime, and that “particularly” describes the “place to be searched” and the “things
to be seized.”
But not every search must be supported by a warrant to be count as reasonable. The Supreme
Court over time has recognized various exceptions and other limits to the reach of that rule. Most
notable for our purposes, the Supreme Court in the 1970s adopted the “third-party doctrine.”
Under that rule, a person has no reasonable expectation of privacy in information that is in the
custody of a third party (such as your bank or your phone company), and thus the Fourth
Amendment has no application should the government ask such a third party to turn over that
information to it.
This rule has been controversial from the start for obvious reasons, and in 2018, the Supreme Court
caused a commotion in Carpenter v. United States by declining to apply the third-party doctrine
to a circumstance in which the government obtained from a telecommunications company an
entire month’s worth of cell-site location data that showed a suspect’s movements in a particularly
comprehensive way. For the time being, however, the third-party doctrine remains the rule for
most investigation scenarios (indeed, the Supreme Court in Carpenter itself went out of its way to
suggest that traditional investigative scenarios remain subject to this rule).
Against the backdrop of this limitation on the relevance of the Fourth Amendment, Congress over
time has enacted a variety of statutes that both limit and facilitate government requests to third
parties for production of information (including electronic information at rest and in motion). It is
beyond the scope of this course to explore those rules in detail, but for present purposes it is
enough to know that criminal investigators routinely seek production of information from third
parties via instruments that require less of an evidentiary showing than does a warrant and that
do not always require ex ante judicial involving, including “grand jury subpoenas” and orders
issued by courts under the 1986 Stored Communications Act. What’s more, Congress even
imposed requirements intended to help overcome potential technical obstacles that might arise
in such cases. For example, the Communications Assistance to Law Enforcement Act (CALEA)

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

212

requires telecommunication companies to “ensure” that their systems are “capable of”
compliance with court-ordered wiretaps and the like. And the Wiretap Act further provides that:
An order authorizing the interception of a . . . communication under this chapter shall,
upon request of the applicant, direct that a provider of wire or electronic communication
service, landlord, custodian or other person shall furnish the applicant forthwith all
information, facilities, and technical assistance necessary to accomplish the interception
unobtrusively and with a minimum of interference with the services that such service
provider, landlord, custodian, or person is according the person whose communications
are to be intercepted. (emphasis added).
In light of all this, it might seem that the government would have little occasion to engage in
hacking. Why sneak in the back door, after all, if the front door is held open for you by the force
of law? The first and foremost answer is that the front door is not always open as a practical
matter, even if it is open as a legal matter.

How might that be the case? Without looking ahead to the readings that follow, can you
identify any scenarios that might fit this description?
2. Lawful Hacking
To understand how FBI eventually came to consider hacking as an option to overcome
practical impediments to the execution of lawful investigative authorities, some historical
context is in order.
In the 1990s, FBI developed a “traffic sniffer” tool intended to be used in support of lawfully
authorized surveillance. The tool—unwisely named “Carnivore”—provided a capacity to filter
packets transiting the network of an Internet Service Provider, flagging those that were to or from
a lawfully-approved target for surveillance. All of this would occur in cooperation with the ISP, so
it was not an example of FBI hacking. Rather, it was an example of the FBI developing a capacity
to accomplish something in circumstances in which the ISPs themselves either could not or would
not develop that same capacity (ISPs, notably, do not count as telecommunication companies
for purposes of CALEA).
When the public became aware of Carnivore, it proved exceptionally controversial. Some
objected to the possibility that it might result in collection of much more than the target’s
communications, while others advanced more sweeping objections. Eventually, though, the issue
would become moot. As Kim Zetter explains in this article from Wired, the increasing ubiquity of
encryption began making it impossible (or at least much harder) for FBI to derive readable plaintext from the packets that might be flagged via Carnivore or similar technologies.
How to overcome that obstacle? Some of the options entailed obvious downsides, not to mention
posed massive political obstacles. One might try to ban encryption altogether, for example, or to
compel providers of encrypted communications services to maintain a capacity to decrypt upon
court order. But another option was to shift focus away from intercepting communications in
transit (at which point encryption was an issue), and instead work to gain surreptitious access to
the sender or receiver’s computer and thus see the pre-encryption or post-decryption messages
in plain text after all. This was a much taller order and less scalable solution, to be sure, but it
proved tempting enough to try.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

213

Zetter’s article highlights a 1999 investigation of an organized crime figure as “the first criminal
suspect known to be targeted by a government keystroke logger”—i.e., malware that would
create a record of all the typing that occurs on a computer. The stakes were high in that case,
for the agents involved had to break into the suspect’s home (twice!) in order to install the logger.
They obtained a warrant, however, and managed the trick. And soon break-ins would no longer
be needed, as FBI developed malware that could be delivered remotely. The age of “lawful
hacking” was underway, eventually expanding to encompass a variety of investigative capacities
beyond keylogging.

Consider the following questions:
• Is it correct to call this “lawful” hacking? Why or why not?
• Can you articulate how the ubiquity of encryption drives law enforcement interest in
hacking?
• Can you relate this law enforcement interest back to the topic of our last class: the
insecurity industry?

3. Watering Holes and Network Investigative Techniques
Notice that our examples, up to this point, involved known suspects. What happens when the
crime is apparent, but the suspect is not? Consider the issues that arose in United States v.
Henderson, a decision by the United States Court of Appeals for the Ninth Circuit upholding the
legality of a law-enforcement hacking tactic used in connection with a child pornography
investigation:
In 2014, the Federal Bureau of Investigation (“FBI”) began investigating the internet website
upf45jv3bziuctml.onion, “Playpen,” which was used to send and to receive child
pornography. Playpen operated on an anonymous network known as “The Onion Router”
or “Tor”. To use Tor, the user must download and install the network software on his
computer. Tor then allows the user to visit any website without revealing the IP address,
geographic location, or other identifying information of the user’s computer by using a
network of relay computers. Tor also allows users to access “hidden services,” which are
websites that are accessible only through the Tor network and are not accessible publicly.
A hidden-service website hosted on the Tor network does not reveal its location; a Tor user
can access the hidden-service website without knowing the location of its server and
without its knowing the user’s location. Playpen operated as a hidden-service website and
required users to log in with a username and password to access its discussion forums,
private messaging services, and images of child pornography.
After determining that Playpen was hosted on servers located in Lenoir, North Carolina,
the FBI obtained and executed a valid search warrant in the Western District of North
Carolina in January 2015, and seized the Playpen servers. The FBI removed the servers to
its facility in Newington, Virginia. Because Tor conceals its users’ locations and IP addresses,
additional investigation was required to identify Playpen users. The FBI then operated the
Playpen website from a government-controlled server in Newington in the Eastern District
of Virginia, from which it obtained a valid court order authorizing it to intercept electronic
communications sent and received by the site’s administrators and users.
The FBI later obtained a warrant from a United States magistrate judge in the Eastern
District of Virginia … authorizing searches for thirty days using what is known as a Network
Investigative Technique (“NIT”). Specifically, such “NIT warrant” authorized the search of

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

214

all “activating” computers—that is, those of any website visitor, wherever located, who
logged into Playpen with a username and password. The NIT technology is computer code
consisting of a set of instructions. When a person logged into the Playpen site, the NIT
caused instructions to be sent to his computer, which in turn caused the computer to
respond to the government-controlled server with seven pieces of identifying information,
including its IP address. The NIT mechanism allowed the FBI, while controlling the website
from within the Eastern District of Virginia, to discover identifying information about
activating computers, even though Playpen operated on the Tor network.
On March 1, 2015, a person logged into Playpen under the username “askjeff.” The NIT
instructions were sent to askjeff’s computer, which revealed its IP address through its
response to the government-controlled server. The computer response also revealed that
askjeff had been actively logged into Playpen for more than thirty-two hours since
September 2014 and had accessed child pornography.
The FBI traced the IP address to an internet service provider (“ISP”), Comcast Corporation,
which was served with an administrative subpoena requesting information about the user
assigned to the IP address. The IP address turned out to be associated with a computer at
the San Mateo, California, home of Bryan Henderson’s grandmother, with whom
Henderson lived. A local federal magistrate judge in the Northern District of California
issued a warrant to search the home, where the FBI then discovered thousands of images
and hundreds of videos depicting child pornography on Henderson’s computer and hard
drives. [Henderson was convicted, and later appealed the trial court’s denial of his motion
to suppress the NIT-derived evidence.]
. . . Henderson challenges only the warrant issued by the Eastern District of Virginia on
February 20, 2015, authorizing the use of the NIT. . . . Henderson argues that . . . the NIT
warrant was issued in violation of Federal Rule of Criminal Procedure 41(b), which
authorizes magistrate judges to issue warrants subject to certain requirements. . . .
Henderson urges that no provision within Rule 41(b) authorizes a magistrate judge to issue
the NIT warrant to search computers located outside of her district. In general, Rule 41(b)
permits “a magistrate judge with authority in the district . . . to issue a warrant to search for
and seize a person or property located within the district.”
. . . The government concedes that a “search” occurred when the NIT was deployed to
users’ computers and returned their identifying information. As two of our sister circuits have
before us, we agree. . . . However, the government counters that the NIT warrant was
nonetheless authorized under Rule 41(b)(4)’s specific provision for tracking devices, which
permits “a magistrate judge with authority in the district . . . to issue a warrant to install
within the district a tracking device . . . to track the movement of a person or property
located within the district, outside the district, or both.”
Rule 41 defines a “tracking device” as “an electronic or mechanical device which permits
the tracking of the movement of a person or object.” The government contends that
Henderson’s computer made a “virtual trip” to the government server in the Eastern District
of Virginia when he logged into the Playpen website. According to the government, his
computer then “brought” the NIT instructions, along with the usual Playpen website
content, back with it from the government server to his computer’s physical location in
California. The NIT instructions then caused identifying location information to be
transmitted back to the government, just like a beeper or other tracking device would.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

215

We are not persuaded by the government’s assertions. The NIT instructions did not actually
“track the movement of a person or property,” as required by the tracking-device
provision. Rather, the NIT mechanism was simply a set of computer instructions that forced
activating computers, regardless of their location, to send certain information to the
government-controlled server in Virginia. Users’ computers did not physically travel to
Virginia, and the information they relayed did not reveal the physical location of any
person or property, unlike a beeper attached to a vehicle. The “seized information (mainly
the IP address) assisted the FBI in identifying a user, [but] it provided no information as to
the computer’s or user’s precise and contemporary physical location.”
...
Interestingly, Rule 41(b) was amended on December 1, 2016—after the issuance of the NIT
warrant here—to authorize magistrate judges to issue warrants to search computers
located outside their district if “the district where the media or information is located has
been concealed through technological means.” As our sister circuits have recognized,
such amendment plainly seems to “authorize[] warrants such as the NIT warrant here.” . . .
The fact that Rule 41 was amended to authorize specifically these sorts of warrants further
supports the notion that Rule 41(b) did not previously do so.
. . . But does a warrant issued in violation of Rule 41(b) compel suppression of evidence?
Not necessarily. Only certain Rule 41 violations justify suppression. The suppression of
evidence is “a judicially created remedy designed to safeguard Fourth Amendment rights
generally through its deterrent effect, rather than a personal constitutional right of the
party aggrieved.” . . . [The Ninth Circuit went on to conclude that the suppression was not
warranted here because the officers relying on the warrant did so out of good-faith belief
in its validity, and because there was no forward-looking deterrence justification for
suppression given the intervening amendment to Rule 41 noted above.]

Consider the following questions:
• How would you explain, in plain terms, what the FBI did here under the label “NIT”?
• If a private person did the same thing, would it violate the CFAA?
• Can you identify any plausible alternative way for the FBI to identify the persons
accessing Playpen other than the NIT approach they used?
• Can you identify any undesirable policy consequences to allowing the FBI to use this
method? Don’t forget: they did get a warrant.
• Change the facts: What legal consequence(s) if FBI had not obtained a warrant?
• Does it matter to your analysis that Playpen preexisted? What if FBI created it from
scratch, as a “watering hole” tactic?
• Revisit the topic of vulnerability disclosure, which arose with the last reading. Does our
foray into NITs and lawful hacking change your views on that topic?

4. Hacking to Get Data-at-Rest (and the Going-Dark Connection)
Note: The NIT language is often used as a shorthand for lawful hacking scenarios, but not all law
enforcement hacking is network-focused. Sometimes, for example, the idea is to overcome the
security of an encrypted device in order to access data-at-rest (or, as in the mafia case
mentioned earlier, to install the equivalent of a keylogger in order to catch outbound and inbound
traffic pre- and post-encryption). The “Apple v. FBI” controversy looms very large under that

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

216

heading. As you probably are aware, that controversy is closely associated with a larger policy
debate sometimes called the “Going Dark” debate.
The idea with that label is that law-enforcement agencies are losing the practical ability to end
up with readable plain-text even when they have warrants or other lawful bases for accessing
data in motion or at rest, because of the combination of two trends: (1) the growing ubiquity of
encryption as the default for the varied communications platforms people use these days, and
(2) circumstances in which the company that created the relevant communication platform or
device does not have—and is not willing or perhaps even able to create—a workaround. Thus, a
series of federal law-enforcement officials have argued that Congress should enact a new and
broader CALEA-style statute, this time focused on requiring companies to have and preserve the
ability to decrypt traffic or otherwise assist law enforcement in executing warrants in this situation.
Opponents argue that there is naught that can or should be done about this, asserting that the
net gain for security overall outweighs lost investigative benefits, and that law enforcement in the
meantime may be enjoying a “golden age” of investigative benefits in relation to non-content
metadata that remains available.
A proper dive into the Going Dark debate is beyond the scope of our course, but if you want to
spend more time on your own studying these issues, consider reading the “Don’t Panic” report
issued by the Berkman Center at Harvard and this essay from Susan Hennessey for Brookings, and
listening to this special episode of Pat Gray’s Risky Business podcast (part of a special series
sponsored by the Hewlett Foundation) in which Pat interviews former FBI General Counsel Jim
Baker on the subject.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

217

23. The Insecurity Industry

Learning Objectives
•

•
•

•

•
•
•

•
•

Be able to describe both the similarities and the differences among: (1) the security industry
(security researchers, white-hat hackers, etc.), (2) the insecurity industry, and (3) black-hat
hackers (hint: all use their skills to identify vulns, create exploits, etc.)
Understand what a “bug-bounty” program is and why that model is desirable from the
defensive perspective
Appreciate that there is a threshold question, for every society, regarding whether it will
legalize hacking for certain institutions (law enforcement, military, spies, etc.), and that this
necessarily gives rise to the question of how those institutions will acquire the capabilities
needed to perform that function
Understand that there does not have to be a private industry to supply such capabilities; they
can be developed exclusively by government entities if that’s how that society prefers to
proceed
Be able to describe the advantages of having an “insecurity industry” to perform this role, as
well as the disadvantages
Understand how the Apple/FBI dispute relates to this topic
Appreciate the utility of having a formalized interagency process for determining when
government knowledge of a vuln/exploit should be disclosed to a vendor and when, instead,
it should be kept for government use
In light of that, understand the basics of how the US government has done this via the “VEP”
Know that VEP determinations are not one-time decisions, but rather require recurring
assessment; be able to describe how this might impact the decision at any given moment in
time

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity
•

•

•

•
•

•

•

218

Understand that vendors themselves naturally may look at the question differently, and
understand the complexities that arise if they attempt to sue an insecurity-industry entity (as
illustrated by the FaceBook/WhatsApp suit against NSO Group)
Be able to explain the difference among: (1) objecting to the idea that a government agency
is authorized to hack under certain conditions; (2) objecting to the idea that such an agency
can turn to a private company to purchase the know-how to do this; and (3) fearing that in
some instances such private companies will sell their wares to a government buyer that might
put them to abusive use
Understand the notional array of regulatory options for minimizing the risk associated with that
third element; consider options that involve (a) outright prohibitions on certain sales, (b) presale requirements of licensing, transparency, or other processes, and (c) post-sale
requirements of auditing, reporting, or even liability
Appreciate that one might have different rules for domestic and overseas sales
Understand the role of the Wassenaar Arrangement, and the nature of the recent dispute
relating to rules that would limit exports (pay particular attention to the question of why this
rules would interfere, potentially, with the penetration-testing industry)
Know that the United States does not formally regulate the “insecurity industry” as such,
meaning that there are no special rules for just that industry (except for situations covered by
export-control law)
Understand the problems illustrated by Project Raven, and how questions related to “human
capital” differ from regulating the sale of software/code

Let’s turn now to a related topic involving “legitimate” private-sector hacking: the policy and legal
questions associated with what some describe pejoratively as the “insecurity industry.”
A. The Insecurity Industry, Government Clients, and the Vulnerabilities Equities Process Issue
In this course, we have spoken often of white-hat security researchers, corporate ventures like
Project Zero, bug-bounty programs, and other elements of the security-enhancing ecosystem.
These players differ in whether and how they seek to be paid for their efforts, but they have in
common a general commitment to increasing information security for all by using their knowledge
of vulnerabilities, exploits, and tactics in a way that’s intended to cause the owner or creator of
relevant systems to patch or take other remedial action. We also have spoken of actors who use
the same knowledge for nefarious purposes, either employing it directly on their own or cashing
in on the black market by selling products and services without regard for how they might be put
to use.
Between these poles, we find the insecurity industry. The key to understanding the insecurity
industry is to grasp that, for better or worse, most domestic legal systems permit certain entities
(usually limited to government agencies, such as law enforcement organizations) to engage in
unauthorized access under at least some conditions. That being the case, those entities either
must develop their own capacities to execute such operations or else purchase that capacity
from others. And that’s where the insecurity industry steps in: these entities supply products and
services to those legitimate users. Or that’s how it is supposed to work, at any rate.
Unquestionably, it does sometimes work that way. A famous example occurred several years ago,
when the FBI had warrants to search the contents of iPhones belonging to Syed Farook and
Tashfeen Malik, the perpetrators of a horrific terrorist attack in San Bernadino in December 2015.
The FBI did not have their passwords, however, and could not run a brute-force password-guessing
program without running afoul of iPhone security features that would progressively slow down the
time between guesses or even wipe the data from the phone after a certain number of incorrect
guesses. The FBI turned to Apple for help, and Apple cooperated with the FBI up to a point. But,
critically, it refused a request to develop a bespoke iOS update that would have negated the

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

219

security features. The FBI then took Apple to a court of law, and Apple in turn took the FBI to the
court of public opinion. Intense controversy followed, until the FBI announced that an unidentified
third-party somehow had managed to solve the access challenge. Here’s how Ellen Nakashima
described this turn of events for the Washington Post:
The FBI cracked a San Bernardino terrorist’s phone with the help of professional hackers
who discovered and brought to the bureau at least one previously unknown software flaw,
according to people familiar with the matter. The new information was then used to create
a piece of hardware that helped the FBI to crack the iPhone’s four-digit personal
identification number without triggering a security feature that would have erased all the
data, the individuals said. The researchers, who typically keep a low profile, specialize in
hunting for vulnerabilities in software and then in some cases selling them to the U.S.
government. They were paid a one-time flat fee for the solution.
The public later learned that the FBI paid approximately $900,000 for the capability it acquired in
that one instance. The Nakashima article goes on to explain:
FBI Director James B. Comey has said that the solution works only on iPhone 5Cs running
the iOS 9 operating system — what he calls a “narrow slice” of phones.
Apple said last week that it would not sue the government to gain access to the solution.
Still, many security and privacy experts have been calling on the government to disclose
the vulnerability data to Apple so that the firm can patch it.
If the government shares data on the flaws with Apple, “they’re going to fix it and then
we’re back where we started from,” Comey said last week in a discussion at Ohio’s Kenyon
College. Nonetheless, he said Monday in Miami, “we’re considering whether to make that
disclosure or not.”
The White House has established a process [the “Vulnerabilities Equities Policy and
Process,” or “VEP”] in which federal officials weigh whether to disclose any security
vulnerabilities they find. . . . The policy calls for a flaw to be submitted to the process for
consideration if it is “newly discovered and not publicly known.” “When we discover these
vulnerabilities, there’s a very strong bias towards disclosure,” White House cybersecurity
coordinator Michael Daniel said in an October 2014 interview. . . . “That’s for a good
reason. If you had to pick the economy and the government that is most dependent on
a digital infrastructure, that would be the United States.” But, he added, “we do have an
intelligence and national security mission that we have to carry out. That is a factor that
we weigh in making our decisions.”
The decision-makers, which include senior officials from the Justice Department, FBI,
National Security Agency, CIA, State Department and Department of Homeland Security,
consider how widely used the software in question is. They also look at the utility of the flaw
that has been discovered. Can it be used to track members of a terrorist group, to prevent
a cyberattack, to identify a nuclear weapons proliferator? Is there another way to obtain
the information?
In the case of the phone used by the San Bernardino terrorist, “you could make the
justification on both national security and on law enforcement grounds because of the
potential use by terrorists and other national security concerns,” said a senior
administration official, speaking on the condition of anonymity because of the matter’s
sensitivity.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

220

A decision also can be made to disclose the flaw — just not right away. An agency might
say it needs the vulnerability for only a few months. “A decision to withhold a vulnerability
is not a forever decision,” Daniel said in the earlier interview. “We require periodic reviews.
So if the conditions change, if what was originally a true [undiscovered flaw] suddenly
becomes identified, we can make the decision to disclose it at that point.”
Note: If you wish, you can read more about the “Vulnerabilities Equities Policy & Process” here,
though you do not need to so for purposes of this class.

Consider the following:
• Can you explain the relationship between the growing ubiquity of encryption both on
devices themselves and on communications-in-transit, and the idea that the
government is motivated to devote more resources to acquiring hacking capabilities?
• Be prepared to attack or defend the idea of the “Vulnerabilities Equities Policies and
Process,” in accordance with your own view of the matter.
• Be prepared to make policy arguments for and against allowing the government to
buy hacking capabilities from outsiders in the specific context in which a law
enforcement agency has obtained a warrant authorizing the search.
• Does your answer apply the same way as to all countries and their varied legal systems,
or is it a U.S.-specific answer?
• Does your answer change if the government does not have a warrant?
o What if the situation is a foreign-intelligence investigation rather than a criminal
investigation?
o What if the government’s intent is to use the capability only against foreign
targets outside the United States?
• If such sales are made unlawful, what impact would that have on the related debate
over whether the law should empower courts under certain conditions to order
hardware and software vendors like Apple to cooperate with the government in
developing solutions to circumvent user-privacy features?

B. Policy Challenge: Insecurity Industry Sales that Facilitate Abuse
If every insecurity-industry vendor sold only to the FBI in contexts involving warrants, this topic would
be much less interesting. In reality, though, there are companies around the globe selling such
goods and services to a wide variety of government buyers, with some of their aims laudable and
others not so at all. To understand this better, we have an excerpt from an article that Joseph
Cox and Lorenzo Franceschi-Bicchierai wrote for Motherboard in 2018:
At first glance, Azimuth Security looks like any other bustling startup. Photos tweeted by the
firm’s co-founder show a staffer zipping in front of glass-walled conference rooms on a
hoverboard and employees in T-shirts playing with a stylish chess set over a beer. But this
small Australian company plays a crucial role in the continuous battle for spies and cops
to hack into phones around the world. . . .
The story of this little-known company provides a rare peek inside the secretive exploit
trade, which is populated with military contractors, individual researchers, and boutique
high-end hacking shops like Azimuth. While the trade is commonly painted as a wild west
full of mercenaries who sell hacking tools to whoever can afford them, over a dozen wellplaced sources described an overlooked section of the industry that focuses on supplying
to a select group of democratic governments, rather than authoritarian regimes. . . . Three
sources familiar with the company said Azimuth—through its partner firm—provides exploits

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

221

to members of the so-called Five Eyes, a global intelligence sharing group made up of the
United States, United Kingdom, Canada, Australia, and New Zealand. . . . Azimuth’s
exploits are used in terrorism cases, and potentially other types of crime such as kidnapping
or child pornography as well. . . .
A plethora of companies now focus solely on offering exploits and other hacking tools to
intelligence and law enforcement agencies around the world, typically with customer
support and additional products to extract information from target devices. Think of it as
a hacking-tools-as-a-service. . . . Many of these firms have controversial client lists,
including countries with abysmal human rights records such as Sudan, Ethiopia, and Russia.

Consider the following:
• What distinction does this passage draw in terms of the potential purchasers of these
“hacking tools”?
• Should that distinction matter with reference to the legality of such sales?
• If you think purchaser identity should be used in determining the legality of such sales,
what statutory language would suffice to implement the distinction?
• The passage also highlights various investigative purposes the purchaser might have in
mind. Should that variable be used to determine legality?
• If so, what statutory language would suffice to implement the distinction?
• To what extent is it reasonable to expect a seller to determine, accurately, who will be
the ultimate user of the capabilities it sells and the purposes to which the capabilities
will be put?
It is clear that, on some occasions, vendors have sold hacking tools to an entity that has, in turn,
used them to facilitate some undesirable end, such as surveilling political opponents (or worse).
What liability, if any, should attach to the vendor in such cases?
Consider the suit Facebook/WhatsApp recently filed against the Israeli firm NSO Group. Here are
excerpts from a handy summary by Andy Greenberg at Wired:
WhatsApp published a statement accusing NSO of targeting 1,400 of its users, including at
least 100 members of "civil society" such as journalists and human-rights defenders, with
malicious voice calls designed to infect targeted phones with malware and steal
messages despite WhatsApp's end-to-end encryption. Those numbers would represent a
new scale for NSO, whose malware has already been linked to attacks against activists
ranging from the now-imprisoned United Arab Emirates dissident Ahmed Mansoor to
Mexican activists opposing a soda tax.
WhatsApp paired its statement with a lawsuit in a Ninth Circuit court, accusing NSO of
violating the Computer Fraud and Abuse Act. . . . To make that charge stick, WhatsApp
will have to show that NSO obtained illegal access to WhatsApp's own systems. Given that
NSO's targets were WhatsApp users rather than, say, WhatsApp's servers, they'll have to
find an argument that they, as the plaintiff, were the victim. . . .
WhatsApp's most obvious unauthorized access argument relates to its terms of service,
which prohibit reverse-engineering WhatsApp's code, harming its users, or sending
malware via WhatsApp. The company might argue that by agreeing to those terms of
service and then violating them, NSO's use of WhatsApp was unauthorized all along. The
complaint appears to lay the groundwork for that case: It points out that NSO Group staff
"created various WhatsApp accounts and agreed to the WhatsApp Terms."

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

222

But that terms-of-service argument will be an uphill battle . . . the Ninth Circuit in particular
has set a clear precedent that terms-of-service violations alone don't constitute
unauthorized access. . . . WhatsApp's lawsuit doesn't make any mention of prior notice to
NSO to stop abusing its services or hacking its users. . . .
Another, trickier strategy for WhatsApp may be to claim that the malicious data NSO sent
via WhatsApp servers was itself a kind of unauthorized access. The WhatsApp complaint
accuses NSO of initiating malicious calls that hid their attack code in fake settings data,
and in doing so bypassed "technical restrictions" on what sort of data WhatsApp's servers
were designed to pass on to phones. This may be the crux of WhatsApp's CFAA claim: that
WhatsApp's own access restrictions were "hacked" with this technique, just as if someone
had bypassed a more obvious access restriction like one that demanded a username and
password. . . .
"We dispute today’s allegations and will vigorously fight them," said NSO in a statement.
"The sole purpose of NSO is to provide technology to licensed government intelligence
and law enforcement agencies to help them fight terrorism and serious crime. Our
technology is not designed or licensed for use against human rights activists and
journalists."

Consider the following questions:
• Can you explain how the first theory of CFAA liability in this case relates to the
Facebook v. Power Ventures case?
• If Facebook/WhatsApp prevail on this theory, does this have implications for the
insecurity industry more generally?
o For example, would this call into question the legality of the capability the FBI
apparently purchased in order to access the San Bernadino iPhones?
• Can you explain the second theory of CFAA liability in this case?
o If it prevails, would it cast a significant shadow over other insecurity-industry
practices?
C. Using Export-Control Laws and Institutions to Limit Risky International Sales
In addition to the question of what is and should be legal in any given country’s domestic legal
system, there is a distinct set of questions concerning whether and how the domestic and
international legal systems that regulate international trade—particularly trade in armaments and
other security-sensitive capabilities—apply to the insecurity industry. This has been a hot topic in
recent years in light of periodic stories of firms in one country providing capabilities to foreign
governments which then put them to abusive ends.
A prominent example involves the Italian firm “Hacking Team,” which in 2015 was itself subject to
a massive doxing episode that revealed to the public that the company sold its surveillanceenabling malware kits to a variety of regimes including Azerbaijan, Bahrain, Egypt, Ethiopia,
Kazakhstan, Morocco, Nigeria, Oman, Saudi Arabia, and Sudan, but also the DEA, the FBI, and
DoD in the United States. This added fuel to the fire of an ongoing effort to update international
arms-trade rules to encompass such transactions. Andy Greenberg at Wired summed up the
situation at the time:
That issue of whether hacking tools are defined as weapons in the terms of arms control
agreements couldn't be more timely: An arms control pact called the Wassenaar

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

223

Arrangement has been hotly debated in recent weeks over its measures that would
control the international export of intrusion software. . . . The Wassenaar Arrangement has
been criticized by the hacker community as limiting security research and preventing the
sharing of penetration testing tools. But Privacy International's Eric King argues that the
practices of Hacking Team demonstrate why the pact is necessary, along with what he
describes as "carve-outs" to protect security research. "What’s clear is that these
companies can’t be left to their own devices," says King. "Some form of regulation is
needed to prevent these companies from selling to human rights abusers. That’s a hard
policy question, and one tool won’t be a silver bullet. But regulation and export controls
should be part of the policy response."

Consider the following questions:
• Should export-control rules encompass vulns, malware, or both?
• Why would “White Hat” security researchers object?

What happened next? Garret Hink explained here for Lawfare in 2018:
The United States successfully negotiated research-use exceptions to export controls on
surveillance tools at the December 2017 meeting of the Wassenaar Arrangement, a club
of advanced economies that coordinates export controls. These export controls—
requirements that organizations selling or sending technologies with potential military
applications abroad obtain a license from the Commerce Department—affect key swaths
of the cybersecurity industry. Although countries implement export controls at the national
level, the United States and 40 other countries have agreed to coordinate their controlled
items at the Wassenaar Arrangement, an international framework for creating a voluntary
export control regime. At this year’s meeting, the U.S. aimed to correct what the
cybersecurity industry portrays as overly-broad controls on intrusive surveillance software—
controls that security experts say “criminalized” essential tools for stopping malware. After
years of debate over the proper scope of export controls on surveillance products, the U.S.
has finally made a beachhead on getting long-sought-after exemptions for security
research and information sharing. In this post, I describe the original Wassenaar export
controls, summarize the 2017 revisions, and forecast what we should expect to see next.
Background
The Arab Spring revealed how repressive regimes use Western commercially developed
software surveillance tools to spy on dissidents and human rights activists. Human rights
organizations sued a French company for giving to the Libyan government equipment
that activists say enabled torture of dissidents. Privacy International and other civil-society
groups pressured the British government to use existing legal mechanisms restrict repressive
regimes’ access to network intrusion software that employed enabled governments to
intercept email, instant messaging and webcam data. (Citizen Lab’s research explores this
topic extensively.) In 2013, the British and French governments negotiated the addition of
two types of dual-use technology—“intrusion software” and “IP network communications
surveillance systems”—to the lists of dual-use technologies that the Wassenaar
Arrangement governs
The Wassenaar Arrangement is an export control framework—not an international
regulatory agency or treaty organization, but rather, a group of countries that meet
regularly and agree to control certain technologies. An export control is a requirement
that a company wishing to sell a product abroad get a government license to export the
item; it is not a ban on that item’s export. Wassenaar has no way to make its controls legally

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

224

binding on its members, who regulate controlled items through their domestic export
control regimes. The arrangement’s 41 members include the U.S., near-all the European
Union (Cyprus is the lone outlier), Russia, Turkey, Argentina and South Africa. Its goal is to
prevent “destabilising accumulations” of conventional arms and dual-use goods and
technologies—items with both civilian and military applications.
The Intrusion Software Controls
The “intrusion software” control took on the difficult task of regulating surveillance software
based on computer code functionality. Wassenaar defined intrusion software as “software
specially designed or modified to avoid detection by monitoring tools, or to defeat
protective countermeasures” and that either extracted data from a computer or network
device or modified the “standard execution path” of a program to allow “the execution
of externally provided instructions.”
But rather than control intrusion software itself, the arrangement put export controls on
software, systems or equipment that interacted with intrusion software. The provision would
cover the software toolkits that companies sell to law enforcement and intelligence
agencies to carry out intrusive surveillance—see for example Hacking Team’s
notorious RCS package. It also controlled any type of technology involved in the
development of intrusion software. “Technology” in the control’s context meant essentially
any program, code or software tool that was connected to intrusion software. In
one interpretation of the WA’s controls, “intrusion software” meant code that took
advantage of an exploit. By controlling software that used software vulnerabilities to carry
out surveillance, the WA control targeted a limited subset of items that related to software
exploits.
When the United States tried to implement the intrusion software controls, Symantec,
FireEye, independent security researchers and the EFF raised serious concerns about their
effect
on
security
software
and
research.
First,
the
Commerce
Department’s implementation through the Commerce Department’s Bureau of Industry
and Security (BIS) expanded its scope to cover a broad range of cybersecurity items.
Mailyn Fidler detailed for Lawfare how the controls ratcheted up efforts to control trade in
software that used zero-day vulnerabilities. BIS said the controls would require export
licenses for commercially available penetration testing products and that potentially any
exploit sent abroad or even to a national of a foreign country would require a license.
BIS published an extensive FAQ that attempted to clarify how the controls affected
security research involving exploits. The EFF criticized the FAQ for creating more confusion
than clarity on the controls’ scope. In addition, the Commerce Department revoked
exemptions for commercially available software products that would have applied to
many of the newly controlled security products. It also failed to provide license exceptions
for security research. The security industry identified all of these actions as harmful to
business and research activities.
But the cybersecurity industry also had problems with the substance of the Wassenaar
language itself. Symantec, FireEye and other security software vendors said the intrusion
software definition was too broad and it encompassed legitimate products like endpoint
security systems and other tools that “hook” into a system to modify its code. They said
further that the controls would also make it much more difficult for security research and
vulnerability information sharing. The control on “technology for the development” of
intrusion software would have covered many essential tools for the security research
community such as exploit proofs-of-concept and automated vulnerability generators.
In response to a deluge of comments opposing the rule, the Commerce Department
withdrew the proposal. After escalating criticism and a dressing down from the House

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

225

oversight committee, the Commerce Department convened with its interagency partners
to revise the U.S. approach. In March 2016, Commerce Secretary Penny Pritzker said in
a letter that the United States would attempt to remove the intrusion software controls at
that year’s Wassenaar meetings. In December 2016, the U.S. negotiating team (with
added technical experts from the cybersecurity community) failed to convince the other
40 Wassenaar members to agree on narrower language. Bipartisan groups of lawmakers
in the House and Senate urged the Trump administration to continue the push to alter the
Wassenaar language at the 2017 meeting.
2017 Revisions to the Wassenaar Controls
At the December 2017 Wassenaar meeting, the members agreed on a set of changes to
the intrusion software controls. It received limited media coverage. The revised control
list included several additions and alterations that Katie Moussouris, a security professional
and technical adviser to the U.S. Wassenaar delegation, hailed as fixes for the problems
the cyber industry had complained about. The changes are:
● Replacing language that controlled software “specially designed” to operate or
communicate with intrusion software with the terms “software specially designed for
command and control” of intrusion software.
● Adding an exception for software that carries out updates authorized by the
owner or operator of the system.
● Adding exemptions for controls on technology either involved in the
development of intrusion software or the development of software that operates, controls
or delivers intrusion software. These exemptions said the controls do not apply for
vulnerability disclosure or cyber incident response activities. The list defines vulnerability
disclosure and cyber incident response as processes for sharing information about
vulnerabilities and cyber incidents but does not explain how these exemptions apply to
specific categories of items.
● Adding a clarifying note saying that the above-described exemptions “do not
diminish national authorities’ rights to ascertain compliance” with existing controls.
The alterations appear to address the some of the concerns associated with the
Wassenaar language, notably the concerns from the security research community about
vulnerability information sharing. But it is not yet clear how the new language mitigates
concerns about the broad definition of intrusion software that may encompass legitimate
security tools not used for “vulnerability disclosure” or “cyber incident response.” Rob
Joyce, White House cybersecurity coordinator, has praised the changes, as has Rep. Jim
Langevin, a leading congressional voice on this issue.
What Comes Next?
The path forward is not clear. The Commerce Department could use the new language
to craft a new proposed rule, to be followed by yet another public comment period. It
would have to decide whether to add more exceptions and how to define how the new
exemptions apply. Alternatively, Commerce could delay implementing the revised list and
wait for the next meeting’s negotiations. In that scenario, Commerce could push for the
U.S. delegation to demand more substantial changes to Wassenaar’s definition of intrusion
software. But the human rights and internet freedom communities united with industry to
oppose the 2015 proposed rule, and it is not clear whether the new changes will satisfy
their concerns.
The Wassenaar changes could cause confusion for other countries as well. The EU has had
intrusion software on its export control list since 2015. But as revelations that European
companies sold surveillance toolkits to Middle Eastern dictators continued, the EU has

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

226

sought to revamp its dual-use export control legislation in the interest of human rights.
Separately, Israel (which is not a Wassenaar member but has a domestic law that adopts
all Wassenaar controls automatically) attempted to more rigorously define intrusion
software in early 2016. Doron Hindin detailed this effort for Lawfare. But a few months later,
Israel shifted its policy on export controls, substantially reducing the scope and strength of
the license requirements. It is unclear how the newest Wassenaar shift will play into both
the EU export control reform initiative and the liberalized Israeli approach.

Is the problem solved? What further steps would you take?
D. What about the International Trade in Personnel?
Recent events in the United States have underscored that the question of exporting hacking
capability is not just a question of the trade in malware and vulns. It’s also a trade in services—
especially the services of trained personnel. Consider the following piece I wrote for Lawfare in
February 2019:
It’s been known since 2012 that a Baltimore-based company called Cyber Point had a
contract with the United Arab Emirates (UAE) to assist its newly-established signals
intelligence agency (then called the National Electronic Security Authority) with “advice
on cyberdefense and policy,” as Ellen Nakashima reported at the time for the Washington
Post. Later, there were suggestions that Cyber Point might be involved in helping the UAE
service acquire malware that the UAE used to support surveillance activities that included
monitoring of political opponents. And now, Reuters has a remarkable piece from Chris
Bing and Joel Schactman, published last week, that goes deeper and raises important
questions about the role of U.S. citizens in working for foreign intelligence agencies.
The Reuters report explains that Cyber Point hired a group of ex-NSA employees to work in
the UAE in support of the UAE signals intelligence service, under the name of “Project
Raven.” Later, the Project Raven team was transferred in some fashion from the Cyber
Point contract to a contract with the UAE-based firm DarkMatter. Along the way, the
Americans came to appreciate that their efforts at times did indeed include surveillance
of political opponents of UAE authorities, and further that the UAE service at times targeted
Americans despite assurances that this would not occur (or at least that the operations
Project Raven in particular conducted or supported would not be directed at Americans).
They probably should not have been surprised by any of that. But be that as it may, the
story understandably has excited concern that the United States lacks a sufficient policyand-law framework to regulate situations of this kind.
What policy concerns, precisely, does this story illustrate? It’s important to be clear on that
question before asking whether the U.S. has an adequate legal architecture for addressing
scenarios like Project Raven.
I see at least four distinct areas of concern implicated by the Project Raven story, each
implicating existing or potential legal architectures in different ways:
1.
2.
3.
4.

Whether Americans in general should ever serve in a foreign intelligence agency;
Whether former intelligence community employees in particular should not do this;
Whether the United States adequately protects classified information;
Whether the United States adequately protect the privacy of Americans from foreign
surveillance.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

227

Let’s take those in sequence.
1. Whether Americans in general should ever serve in a foreign intelligence agency
The question here does not concern serving secretly as an asset for foreign governments,
which U.S. law obviously should (and does) discourage. Instead, the question is whether it
is inherently bad for U.S. persons (American citizens and lawful permanent residents) to
have overt work relationships with foreign intelligence agencies. Some might argue that
all such service is inherently unfriendly to the U.S. government at least at some level, with
some contexts plainly much more so than others. Might some form of ban, with exceptions,
therefore be desirable? And if so, does the U.S. not already have something like this?
The case for having some form of ban begins with the idea that there is inherent tension
between owing a duty of loyalty to the United States and providing services to a foreign
government in direct relation to that government’s pursuit of its own security and foreign
policy goals, which in some cases may be inimical to the security and foreign policy goals
of the United States. There is also the possibility that the actions of U.S. persons abroad,
even when working under the direction and control of a foreign government, could be
held against the United States, fairly or not. On the flip side, there are of course
circumstances in which interests align enough to make such service with a foreign
intelligence agency beneficial for the United States. The balance of equities, then, is highly
context-dependent.
This suggests that the optimal legal framework would be one that allows such service only
where there has been some degree of vetting on the front end, and some degree of
ongoing monitoring on the back end—that is, a licensing model, as opposed to a flat ban.
As it turns out, the U.S. already has a version of this. But as the Project Raven story itself
illustrates, the current system seems incomplete.
The existing licensing model was created primarily to address military-relevant materials
and services. Under the Arms Export Control Act, the executive branch is authorized to
prohibit the unlicensed export of “defense articles” and “defense services.” The meaning
of those broad categories is explicated at great length and detail through the
International Traffic in Arms Regulations (ITAR) and the U.S. Munitions List (USML). Things that
fall within them cannot be exported without a license from the State Department’s Director
of Defense Trade Controls (DDTC). DDTC can—and does—impose conditions on the
licenses it grants, including, where appropriate, limitations designed to prevent U.S.provided articles and services from being used by foreign recipients in ways that violate
human rights or that otherwise harm U.S. interests.
Does this apply to things or services provided to foreign intelligence services? The question
is a tricky one, at least on paper, for the regulations are dense and their references to
intelligence activities are sparse (and not tailored to clearly address grey zone activities in
the cyber domain). That said, the Project Raven/Cyber Point episode itself makes clear
that DDTC does view at least some such activity as coming within the licensing system;
Cyber Point applied for and received a license, after all.
The more important questions—the ones the Project Raven story raises in relation to this
particular policy concern—are whether the licensing system is sufficiently probing on the
front end when the license is being granted, and whether there is adequate back-end
monitoring for compliance with license conditions. The nuances in the Project Raven story,
so far can be gleaned from the Reuters account, are tricky on both points.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

228

Reuters writes that Project Raven transitioned out from under Cyber Point (and its license)
at some point, moving to UAE-based DarkMatter. Conduct subsequent to that shift
probably cannot be laid at Cyber Point’s door, and thus would not violate the Cyber Point
license. On that view, one cannot fault the front-end screening by DDTC, unless it turns out
that the Project Raven activities violated the license terms all along. On the other hand,
that same logic compels the conclusion that the U.S. persons who remained working for
the UAE at that point no longer had the benefit of a DDTC license, yet they continued
providing “defense services” to the UAE. This suggest a possible enforcement gap in the
licensing scheme, though perhaps time will yield an enforcement gap now that the story
has become public.
At any rate, one potentially-attractive policy response to the whole episode would be to
increase the resources devoted to both front-end screening and in-progress monitoring for
DDTC licenses. And perhaps the statute could be amended to support that in-progress
monitoring by imposing increased requirements for periodic compliance-reporting.
Before moving on, it’s worth noting how things might look if the country decided licensing
was not the right way to go and, instead, wanted to move to a flat ban. That idea has a
close parallel in the context of foreign military service. In that setting, American criminal
law has long made it a crime to enlist or otherwise enter into the service of a foreign military
(unless that foreign military is at war with a state against which the U.S. too is at war), and
separately it has also long been a crime to take a foreign government’s commission to
serve in war against a party with which the United States is at peace. To be sure, there are
ample historical examples of the government looking the other way; enforcement has not
been anything like uniform or rigid over time. But still, there it is.
Should the U.S. treat foreign intelligence service the same way as foreign military service,
with a flat ban? This would certainly help minimize Project Raven scenarios in which U.S.
persons end up contributing to undesirable foreign intelligence activities. But perhaps it
would overcorrect to too great an extent, for it also would preclude U.S. persons from
contributing to desirable activities, such as the sort of counterterrorism functions that the
Project Raven personnel originally thought would be their focus. A well-tailored and wellresourced licensing system seems to me to be the better alternative.
2. Whether former intelligence community employees in particular should not do this
Even if Americans in general should have the option of foreign intelligence service, subject
to proper licensing, one might argue that former intelligence community employees are a
special case for whom no such license should be granted.
The case for a flat-ban for former intelligence community employees might go something
like this: First, as the Project Raven story suggests, the fact that an American working for a
foreign service once was an intelligence community employee considerably enhances
the extent to which the actions of the foreign entity may come to reflect back on the
United States, even if unfairly so. Second, much like the analogous scenario in which bans
or at least delays are imposed before former public officials can engage in lobbying
related to their former jobs, the U.S. should worry about both the appearance of
impropriety (which undermines public regard for the entity in question, and thus inhibits
that entity’s ability to pursue its mission) and the possibility that people in public service
might be influenced in their decisions by future employment prospects. Third, officials might
worry (as noted below) about the opportunities for compromise of U.S. personnel that are
created by working with a foreign intelligence service. (Indeed, it is not hard to see how
the UAE service could have taken advantage of the growing murkiness of the Project

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

229

Raven activities so as to create leverage over at least some of those former NSA
employees).
The case against such a flat ban, in contrast, builds from the premise developed above:
there are some circumstances in which it is in the U.S. national interest to improve the
efficacy of foreign intelligence services by allowing Americans to work with them. If that’s
the case, it stands to reason that the persons most able to provide that boost, in at least
some cases, will be former intelligence community employees. On that view, the licensing
system to must function well enough to police against undue risk of the kinds just noted in
the preceding paragraph.
3. Whether the U.S. adequately protects classified information
The preceding discussion draws attention to a related, but distinct, concern: Does the
Project Raven scenario highlight an undue risk that classified information involving cyber
capabilities will leak to a foreign service as a result of former intelligence community
personnel serving with a foreign agency?
Yes and no. The good news is that the U.S. doesn’t lack for relevant criminal laws in this
area. Though there always is risk that a former employee will choose to violate those laws
or be compromised into doing so, there’s not much cause for trying to expand or
strengthen the legal guardrails when it comes to obvious concerns such as exposure of
specific tools like custom malware, access to staging servers, specialized physical
equipment, etc. And the Project Raven story does not suggest otherwise.
But on the other hand, there also is great value in the sheer practical knowledge—the
tactics, techniques and procedures (TTPs)—for which the foreign agency is hiring these
former intelligence community personnel in the first place. Whether and when that knowhow is itself classified information can be tricky, to say the least. Knowledge concerning a
specific software vulnerability—of a zero day—might readily count, but TTPs involving best
practices for detection avoidance and lateral movement within a system might present a
murkier case. And the less clear things are, the more likely it is the former employee will
simply use the TTP in the new job, with the new employer and new colleagues gaining that
know-how along the way even if the U.S. person never intended to “train” them in any
formal sense.
It seems to me the TTP-sharing issue is intractable to a certain extent. If one takes a
sweeping approach to classifying know-how and then ensuring intelligence community
employees understand there will be a strict approach to enforcement, this runs the risk of
effectively prohibiting those employees from going on to do related work
for anyone outside the government, not just foreign intelligence agencies. This in turn
would make the already-serious challenge of recruiting talented hackers and defenders
much more so.
4. Whether U.S. law adequately protects the privacy of Americans from surveillance by
Americans working for a foreign government
Perhaps the most striking element of the Project Raven story is the reference to UAE
surveillance of Americans. My read of the story was that the Americans were not
themselves engaging in this activity. If that’s right, then all that’s at issue is the fact that
foreign intelligence services spied on U.S. citizens—an important thing to know, but not
something that warrants some innovation in the U.S. legal architecture). But what if that’s
not right? That is, what if some of the Americans associated with Project Raven were
engaged in surveillance of their fellow citizens, on behalf of a foreign government?

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

230

The short and complete answer is that they would be in serious legal jeopardy, for neither
their license (which surely excludes such activity anyway) nor the cloak of UAE domestic
law would do anything to make such activity legal from the perspective of U.S. law. Various
U.S. laws—the Wiretap Act, for example, and the Computer Fraud and Abuse Act—might
come into play.
Indeed, the Reuters report notes that the FBI has taken a keen interest in Project Raven
participants. Perhaps this is one of the reasons why? Time will tell. For now, it is enough to
say that this is not an area where the legal framework seems lacking.

Does the United States need new laws?

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

231

24. Government Hacking: Espionage

Learning objectives
•

•
•
•
•

•
•
•

Be able to explain why the prospect hacking by U.S. law enforcement agencies might be
more controversial, within the United States, than hacking by U.S. intelligence agencies (hint:
consider the differences between typical crime investigation scenarios and typical foreignintelligence collection scenarios)
Understand the roles of CIA and NSA in collecting foreign intelligence, and why hacking might
be a means through which they perform that function
Know that multiple statutes require reporting to Congress of “significant intelligence activities”
Know that CIA is forbidden, by statute, from domestic security and police functions
Know that “PPD-28” articulated the US policy against using its espionage capacities to assist
American companies, and that it articulated an “exclusive” list of purposes for which NSA can
engage in “bulk” collection
Understand how the utility of a vuln for espionage purposes relates to the VEP
Understand that there are not, currently, any international law rules specifically designed to
impose substantive limits on when hacking can be used
Understand that the question of whether such international laws (or at least international
“norms”) is less a matter of concerns about espionage as it is a concern about other modes
of government behavior that might involve actual disruption of the function of the penetrated
system (such as armed conflict, covert action, or holding-at-risk)

We turn our attention now to espionage conducted by government agencies in order to collect
“foreign intelligence” (i.e., intelligence concerning the capabilities, intentions, and actions of
foreign states, organizations, or individuals). Espionage can, of course, be conducted using nontechnical means such as recruitment of human intelligence sources (“HUMINT”). But the use of
technical means to capture “signals” (“SIGINT”) has long been a staple of espionage as well, and
in today’s world of computers, smartphones, and other digital communication systems those
means increasingly require hacking.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

232

Our task now is to become familiar with the most important U.S. government agencies that hack
for espionage purposes; to understand the legal and policy architectures associated with them;
and to ponder whether any reforms to those architectures might be warranted.
A. Which U.S. Government Institutions Perform this Function?
In the American system, the federal agencies associated with intelligence activities typically are
referred to collectively as the “Intelligence Community,” or simply the “IC” (pronounced eye-see).
Currently, the label encompasses eighteen such entities (the number increased in early 2021
thanks to the creation of the U.S. Space Force as a distinct military service branch; USSF at the
same time announced that it will collect its collection and analysis capabilities under the heading
of the “U.S. Space Force Intelligence, Surveillance and Reconnaissance Enterprise” (ISRE)). Half
of these—nine of them of them--are part of the Defense Department. Together they constitute
the “Defense Intelligence Enterprise,” with civilian oversight at the Defense Department routing
through the Under Secretary of Defense for Intelligence and Security.
Among these DoD intelligence agencies, most notably for our purposes, is the National Security
Agency (“NSA”). We introduced NSA previously, in our defensive-minded unit, when describing
its critical role defending the federal government’s “national security systems” and its recent focus
on providing indirect support to private sector cybersecurity (especially that of the Defense
Industrial Base). NSA’s role is not just defensive, however; it is the nation’s lead agency for
collection and analysis of SIGINT (both for military intelligence purposes and in support of the
general foreign-intelligence collection goals of the federal government as a whole, or what we
will call “national intelligence”). Hacking thus is central to NSA’s mission. NSA and its eight military
intelligence brethren fall within the budget, policy, and personnel domain of the Secretary of
Defense (exercised, on a day-to-day basis, through the Under Secretary of Defense for
Intelligence).
As for the other nine agencies that comprise the IC: seven of them also are part of a larger federal
department (specifically: the Departments of Justice, State, Treasury, Energy, and Homeland
Security). The remaining two— the Office of the Director of National Intelligence (“ODNI”) and the
Central Intelligence Agency (“CIA”)—are free-standing agencies. ODNI was created in 2004 with
the goal of providing a degree of IC-wide coordination and services, based on the
recommendations of the 9/11 Commission. Thus the Director of National Intelligence (“DNI”) to a
limited extent functions as the head of the IC. The DNI’s control over IC institutions apart from
ODNI itself is quite limited, however, both formally and functionally. Indeed, if one wants to
describe the real, practical distribution of authority over the IC, it probably is most accurate to say
that the DNI, the Director of the CIA, and the Secretary of Defense (or the Under Secretary of
Defense for Intelligence) form an informal triumvirate of most-powerful officials, no one of whom
has anything close to complete control over the others. As for the CIA, it is charged with the full
spectrum of intelligence functions, including collection, analysis, and even the conduct of “covert
action.” It is most famous, of course, for its work with human assets, but both its collection and
covert-action missions may entail hacking.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

•
•
•

233

Which scenario do you suppose is more likely to require resort to hacking: engaging in
espionage or investigating crime?
Which do you suppose is more likely to occur within the United States (whether hacking
is involved or not): the use of espionage by the U.S. government, or investigation of
crime?
Bearing in mind your answer to those questions, can you explain whether policy
concerns are more likely to arise for the United States with respect to law enforcement
hacking or instead with respect to hacking by the government’s spy agencies?

B. What Legal Framework Regulates Espionage?
Over the past five decades, the United States has developed a complex domestic legal
framework relating to espionage activities. Though it does not include provisions that are specific
to espionage conducted via hacking, its general provision applies in that context the same as
with any other espionage methods.
1. Hacking to conduct surveillance against US persons or within the United States
From a U.S. policy perspective, the most sensitive espionage-via-hacking scenarios naturally would
be those that target U.S. persons or that in some meaningful sense take place within the United
States (regardless of whether the activity would involve hacking or any other method). It therefore
is no surprise that the legal architecture places significant constraints on such activity.
It was not always so. Prior to the mid-1970s, various federal agencies periodically engaged in
electronic surveillance within the United States in order to gather intelligence about both foreign
and domestic security concerns, without statutory authorization and without court oversight or
other involvement. When those activities came to public light in the early 1970s, it caused an
uproar. Along with a contemporaneous Supreme Court decision holding that wiretapping for
domestic intelligence purposes still required a court-issued warrant under the Constitution’s Fourth
Amendment—known as the “Keith Case”—this set the stage for major reforms. First, the executive
branch effectively abandoned the idea of conducting electronic surveillance for purely-domestic
intelligence purposes. Henceforth, electronic surveillance either would be a matter of criminal
law enforcement investigation or for purposes of collecting information on foreign-intelligence
topics. And as to the latter, Congress in 1978 crafted the Foreign Intelligence Surveillance Court
(“FISC”) system as a means to ensure case-specific approval by a federal judge over all such
surveillance activity.
A full study of that topic is well-beyond the scope of this book (please see my other eCasebook,
Chesney on the Law of the Intelligence Community, if you are interested in that topic). For now, it
suffices to say that any effort on the part of any federal agency to engage in foreign-intelligence
collection via hacking directed at a U.S. person as the target, or otherwise taking place within the
United States, almost certainly would be governed by this framework and thus would require
working through the Justice Department to file an application seeking permission from the FISC.
And though there are many complex and important questions regarding the adequacy of the
FISC review process, the critical point for our purposes is that those questions are much the same
regardless of whether the government agency plans to using hacking or other methods to
effectuate whatever surveillance the FISC might approve. In that sense, the domestic use of
hacking to collect foreign-intelligence information is precisely analogous to the law enforcement
use of hacking we discussed in the previous reading.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

234

That last observation may remind you that, in our law enforcement reading, we quickly pivoted
to the question of whether there should be laws to help ensure that when the government does
engage in legally-authorized hacking it will be more likely to be able to do so effectively. That is,
we quickly pivoted to the “Going Dark” debate. Notably, under that heading we have seen
repeated assertions by law enforcement officials (such as a succession of FBI Directors) pressing
the argument that some legislative steps eventually may be needed to limit the security measures
that the private sector has been deploying, particularly in relation to encryption. What we have
not seen, in contrast, is comparable statements by the heads of government agencies focused
exclusively on foreign-intelligence collection, such as CIA and NSA.
•

Can you think of any reasons why this might be?
2. Hacking to conduct surveillance against non-U.S. persons outside the United States

By design, the FISC system created in 1978 does not apply when the government uses electronic
surveillance to collect foreign intelligence from non-US persons outside the United States. The
question therefore arises: does any other legal framework address that scenario, whether hacking
will be used or not?
We might call this scenario the “core” foreign-intelligence scenario, since the overseas collection
of foreign intelligence is the paradigm of espionage and the bulk of what we expect agencies
like NSA and CIA to do. And there is, in fact, some law that speaks to this situation. In particular,
Congress has enacted transparency/oversight rules designed to ensure that Congress has at least
some understanding of what such agencies are doing in this core scenario.
According to 50 U.S.C. 3092, both the DNI and the head of specific intelligence agencies (such
as the Director of the NSA or the Director of the CIA) have a standing and constant obligation to
keep the congressional intelligence committees (the Senate Select Committee on Intelligence,
and the House Permanent Select Committee on Intelligence) “fully and currently informed of all
intelligence activities” carried out by or on behalf of the United States, including not just ongoing
activities but also “significant anticipated” activities as well as “significant intelligence failure[s].”
The same officials also must provide to those committees “any information or material
concerning” such activities, upon request. Separately, 50 USC 3091 imposes the same obligation
directly on the President, with the additional caveat that “any illegal intelligence activity” must
be “reported promptly” to those committees.

•
•
•
•
•
•

Can you explain how the mere existence of a requirement to report to Congress on
collection activities might have a beneficial effect in terms of deterring bad ideas for
specific collection efforts?
Can you think of any costs to having such reporting requirements (and do you need
to know more about the granularity of that reporting before you can answer that
question)?
Do you think it is a problem that FISC approval is not required for collection efforts that
target non-US persons outside the United States?
Can you articulate the pros and cons of adopting such a rule?
Is there any reason to adopt hacking-specific rules that differ from the generallyapplicable rules associated with the core foreign-intelligence collection scenario?
Does it matter to your analysis whether other countries (whether ally or adversary)
similarly constrain their own espionage activities?

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

235

3. PPD-28 and the Response to the Snowden Revelations
We should pause here to note that the executive branch can impose rules on itself, even when
Congress has not seen fit to do so. Indeed, amidst the controversies unleashed by the Snowden
revelations that began in the summer of 2013, President Obama in Presidential Policy Directive
28 (“PPD-28”) articulated several such constraints for SIGINT collection, and they remain on the
books at this time. They include:
Section 1(b) – The United States shall not collect signals intelligence for the purpose of
suppressing or burdening criticism or dissent, or for disadvantaging persons based on their
ethnicity, race, gender, sexual orientation, or religion. Signals intelligence shall be
collected exclusively where there is a foreign intelligence or counterintelligence purpose
to support national and departmental missions and not for any other purposes.
Section 1(c) - The collection of foreign private commercial information or trade secrets is
authorized only to protect the national security of the United States or its partners and
allies. It is not an authorized foreign intelligence or counterintelligence purpose to collect
such information to afford a competitive advantage [FN: “Certain economic purposes,
such as identifying trade or sanctions violations or government influence or direction, shall
not constitute competitive advantage.”] to U.S. companies and U.S. business sectors
commercially.

Consider the following questions:
• Is anything in Section 1(b) a serious constraint on what the United States otherwise
might genuinely be inclined to do?
• What about Section 1(c), bearing in mind the explanatory footnote?
• Should any of this be changed?
• Do you think any other country that engages in serious SIGINT collection against the
United States actually follows comparable rules?

PPD-28 goes on in Section 2 to discuss a new limit on the use of “bulk collection” of signals
intelligence. Such collection need not involve hacking, but it might. For example, NSA in theory
might have the capability to surreptitiously access the network of a foreign Internet Service
Provider, and from that perch collect all traffic crossing that network, relying on post-collection
querying of the bulk results in order to separate the wheat from the chaff. At any rate, Section 2
of PPD-28 articulates limits on such approaches, whether made possible by hacking or not:
Locating new or emerging threats and other vital national security information is difficult,
as such information is often hidden within the large and complex system of modern global
communications. The United States must consequently collect signals intelligence in
bulk in certain circumstances in order to identify these threats. Routine communications
and communications of national security interest increasingly transit the same networks,
however, and the collection of signals intelligence in bulk may consequently result in the
collection of information about persons whose activities are not of foreign intelligence or
counterintelligence value. The United States will therefore impose new limits on its use of
signals intelligence collected in bulk. These limits are intended to protect the privacy and
civil liberties of all persons, whatever their nationality and regardless of where they might
reside.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

236

In particular, when the United States collects nonpublicly available signals intelligence in
bulk, it shall use that data only for the purposes of detecting and countering:
(1) espionage and other threats and activities directed by foreign powers or their
intelligence services against the United States and its interests;
(2) threats to the United States and its interests from terrorism;
(3) threats to the United States and its interests from the development, possession,
proliferation, or use of weapons of mass destruction;
(4) cybersecurity threats;
(5) threats to U.S. or allied Armed Forces or other U.S or allied personnel; and
(6) transnational criminal threats, including illicit finance and sanctions evasion
related to the other purposes named in this section.
In no event may signals intelligence collected in bulk be used for the purpose of
suppressing or burdening criticism or dissent; disadvantaging persons based on their
ethnicity, race, gender, sexual orientation, or religion; affording a competitive advantage
to U.S. companies and U.S. business sectors commercially; or achieving any purpose other
than those identified in this section.

Consider the following questions:
• Given the six approved categories, is there anything significant left out?
• If so, is that a good thing or a bad thing?
• Do you suppose any other country that engages in SIGINT collection against the United
States similarly constrains its use of a bulk-collection methods?

C. The Vulnerabilities Equities Process
Not surprisingly, both NSA and CIA are in the business of developing their own hacking
capabilities. And though much hay can be made from already-public vulnerabilities (thanks to
the ubiquity of unpatched systems out there), zero-day vulns of course can be especially
important given the sophistication of some of these agencies’ targets. The agencies,
accordingly, do attempt to discover such vulns, and at least some of the time they put them to
work rather than disclose them to the relevant companies for patching purposes. As we have
noted previously in this book, however, there are competing national interests, particularly in the
case of vulns that impact systems in widespread (or at least sensitive) use by Americans. For that
reason, we will return now (and in considerably more detail) to the topic of the Vulnerabilities
Equities Process.
This 2016 report from Ari Schwartz and Rob Knacke, for Harvard’s Belfer Center, provides a useful
history of the VEP:
The genesis and contours of the existing VEP are reflected in a series of documents
obtained and made public in 2015 and 2016. A basic overview of the origins of the VEP is
set forth in a document entitled “Vulnerability Equities Process Highlights” (“Highlights
Paper”). We can trace the origins of the VEP to a January 2008 directive, signed by
President George W. Bush. This directive, known as National Security Policy Directive 54
(NSPD 54), established a US-government-wide effort called the Comprehensive National
Cybersecurity Initiative (“CNCI”). One component of the CNCI required the Departments

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

237

of State, Defense, Homeland Security, and Justice, as well as the Director of National
Intelligence, to develop “a joint plan for the coordination and application of offensive
capabilities to defend US information systems.”
This joint plan noted, among other things, that the discovery of vulnerabilities “may
present competing equities for [government] offensive and defensive mission interests”
and recommended that “actions taken in response to knowledge of a specific
vulnerability must be coordinated to ensure the needs of each of these ‘equities’ are
addressed.” The plan recommended the development of a “Vulnerabilities Equities
Process.”
A working group, led by the Office of the Director of National Intelligence, developed
the VEP during 2008 and 2009 in response to the Joint Plan’s recommendation. It
consisted of members from the National Security Council, Central Intelligence Agency,
Defense Intelligence Agency, Justice Department, Federal Bureau of Investigation
(“FBI”), Department of Defense, Department of State, Department of Energy, and
Department of Homeland Security. This working group ultimately produced a document
entitled “Commercial and Government Information Technology and Industrial Control
Product or System Vulnerability Equities Policy and Process” (“VEP Document”), which
lays out the process that the government apparently continues to follow today. The VEP
Document is dated February 16, 2010.
The VEP Document demonstrates that the government established a process to
determine whether vulnerabilities discovered or purchased by the government or its
contractors should be retained for government use or revealed to the appropriate
vendor for patching.
Under the process as outlined by the VEP Document, the VEP is intended to “establish[]
policy and responsibilities for disseminating information about vulnerabilities discovered
by the United States Government (USG) or its contractors, or disclosed to the USG by the
private sector or foreign allies in Government Off-The-Shelf (GOTS), Commercial Off-TheShelf (COTS) or other commercial information technology or industrial control products or
systems (to include both hardware and software).” More specifically, the paper “defines
a process to ensure that dissemination decisions regarding the existence of a
vulnerability are made quickly, in full consultation with all concerned government
organizations, and in the best interest of government missions of cybersecurity,
information assurance, intelligence, counterintelligence, law enforcement, military
operations, and critical infrastructure protection.” The policy “applies to all components,
civilian and military personnel, and contractors of the United States Government . . . .”
The VEP Document goes on to give directions for appropriate classified treatment for
“vulnerabilities discovered by the USG or by non-USG entities under contracts with the
USG, or disclosed to the USG by the private sector prior to entry into this process” and
then directs further that “USG entities shall introduce any such vulnerability discovered
into the following Vulnerabilities Equities Process (VEP).” The VEP Document clarifies
further that a vulnerability should be put through the VEP if it is “both newly discovered
and not publicly known.” The VEP Document exempts from the VEP any vulnerability
discovered before its effective date (February 16, 2010). It also exempts from the process

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

238

any vulnerability discovered during the course of open and unclassified federallysponsored research.
The VEP Document establishes the Information Assurance Directorate of the NSA as the
Executive Secretariat of the VEP. It also establishes an interagency Equities Review Board
(“ERB”) for making decisions on whether to retain or disclose a vulnerability. The
composition of the ERB remains classified, however.
Under the process, the agency that comes into possession of a vulnerability that is newly
discovered and not publicly known is required to notify the Executive Secretary, which
then disseminates the vulnerability to all relevant agency Points of Contact (“POCs”),
who “are responsible for ensuring that applicable cybersecurity, cyber defense,
information assurance, intelligence, counterintelligence, law enforcement, or other
offensive cyber operations equities of their organization are appropriately represented in
the process.” Each such agency then is responsible for designating one or more Subject
Matter Experts (“SMEs”) to participate in a discussion convened by the Executive
Secretary to arrive at a consensus on whether the vulnerability should be retained by the
government or disclosed for patching. Ultimately, the ERB is charged with making the
decision on whether to disclose or retain a discovered vulnerability, and the ERB acts by
majority vote. An affected agency is entitled to appeal the ERB’s decision, although the
appeals process itself remains redacted.
The VEP Document provides guidance for implementation of ERB decisions. The
guidance on implementation of a decision not to disclose a vulnerability continues to be
classified. For implementation of decisions to disseminate information on vulnerabilities,
the guidance requires the ERB to establish “guidelines for disseminating that information,
including mitigation strategies, to the cyber security centers that are primarily responsible
for defending or coordinating the defense of networks and systems, as well as offensive
entities.” The VEP Document also provides for an annual oversight mechanism involving
the production of an annual report by the Executive Secretariat, although the identity of
the overseer of the process remains classified.
Although the VEP was established in 2010, its existence was revealed publicly only after
questions were raised about the government’s use of zero day vulnerabilities for
intelligence and offensive purposes, including the government’s practice of purchasing
zero day vulnerabilities, following the leaks of classified information by Edward Snowden
in 2013.
The report issued by the President’s Review Group on Intelligence and Communication
Technologies (“President’s Review Group”) in December 2013 did not mention an existing
VEP, but did contain recommendations about how the government should manage
vulnerability equities. Specifically, Recommendation 30 of the President’s Review Group
report stated:
We recommend that the National Security Council staff should manage an interagency
process to review on a regular basis the activities of the government regarding attacks
that exploit a previously unknown vulnerability in a computer application or system.
These are often called ‘Zero Day’ attacks because developers have had zero days to

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

239

address and patch the vulnerability. US policy should generally move to ensure that Zero
Days are quickly blocked, so that the underlying vulnerabilities are patched on
government and other networks. In rare instances, US policy may briefly authorize using a
Zero Day for high priority intelligence collection, following senior, interagency review
involving all appropriate departments.
The Obama Administration released information about the VEP only after Bloomberg
News alleged in April 2014 that the NSA had known about the then-recently revealed
Heartbleed vulnerability, and exploited Heartbleed for its own purposes instead of
disclosing the vulnerability to be patched. In response to that allegation, which the NSA
vigorously denied, the White House acknowledged that the government sometimes relies
on zero day vulnerabilities for intelligence and other, related purposes, rather than
disclosing such vulnerabilities and allowing them to be patched. However, the White
House also asserted that it had reviewed the recommendations of the President’s Review
Group and had determined, as of January 2014, that the government’s policy should be
that there is a “bias” toward disclosure to vendors for patching rather than retention by
the government. The exception to this government “bias” toward disclosure is if there is a
“clear national security or law enforcement need. . . .”The Administration described
these decisions as the implementation of a “reinvigorated” process for balancing the
equities surrounding zero day vulnerabilities.
Responding to the Heartbleed allegation against the NSA, White House Cybersecurity
Coordinator Michael Daniel authored a White House blogpost in late April 2014 that
further outlined the Obama Administration’s policy regarding zero day vulnerabilities.
Echoing the White House’s statement in early April 2014, Daniel stated that “[t]his spring,
we re-invigorated our efforts to implement existing policy with respect to disclosing
vulnerabilities—so that everyone can have confidence in the integrity of the process that
we use to make these decisions.” Addressing allegations that the government hoards
zero day vulnerabilities, Daniel asserted that “[b]uilding up a huge stockpile of
undisclosed vulnerabilities while leaving the Internet vulnerable and the American
people unprotected would not be in our national security interest.” Nonetheless, while
asserting that disclosure of zero day vulnerabilities is in the national interest “in the
majority of cases,” he categorically rejected the suggestion that the government should
“completely forego this tool as a way to conduct intelligence collection, and better
protect our country in the long-run.”
Daniel explained that the government has a “disciplined, rigorous, and high-level
decision-making process for vulnerability disclosure” that is inter-agency in nature, and
that explores all the pros and cons of disclosure. He emphasized that “there are no hard
and fast rules” governing the process, but outlined the following factors, lightly edited for
clarity, that the ERB considers before deciding whether to disclose a zero day
vulnerability:
• The extent of the vulnerable system’s use in the Internet infrastructure;
• The risks posed and the harm that could be done if the vulnerability is left unpatched;

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

240

• Whether the Administration would know if another government or organization was
exploiting the vulnerability;
• Whether the vulnerability is needed to obtain intelligence (i.e., how badly does the US
government need the information, and are there alternative means of obtaining it);
• How likely it is that others will discover the vulnerability;
• Whether the government can use the vulnerability for a short period of time before
disclosing it; and
• Whether the vulnerability can be patched or otherwise mitigated.
Daniel concluded by asserting that the government “weigh[s] these considerations
through a deliberate process that is biased toward responsibly disclosing the vulnerability
. . . .” He also emphasized the need for sufficient transparency in the process to “instill
some confidence that your government is acting responsibly in the handling of this
important issue.”
The disclosures by the White House in response to the Heartbleed allegations made clear
that the government has a VEP, but provided no additional information on the VEP itself,
or when it was developed. In response to these disclosures, the Electronic Frontier
Foundation (EFF) filed a Freedom of Information Act request for documents related to the
VEP described in the Daniel Blog Post, and then a lawsuit to compel the disclosure of
those documents. The result of that suit was the release of a series of documents, the
most significant of which are the Highlights Paper and the VEP Document.
In the period between the filing of the EFF suit and the release of the Highlights Paper
and the VEP Document, there were several additional statements by government
officials that shed further light on the VEP and its implementation. In a speech delivered
in November 2014, Admiral Michael Rogers, the head of the NSA, discussed the
government’s vulnerability disclosure policies, and stated that “by orders of magnitude,
the greatest number of vulnerabilities we find, we share.”
While the Obama Administration deserves credit for re-invigorating the process and for
demonstrating a clear bias toward disclosure, the fact that the process fell into disuse
from when it went into effect in 2010 until the Intelligence Review Group made its
recommendations in 2014 is troubling. In an interview given to WIRED Magazine, Daniel
asserted that the “default-disclosure policy was established in 2010” but that “it ‘had not
been implemented to the full degree that it should have been,’ hence the government’s
use of the term ‘reinvigorated’ to describe this new phase.” In particular, the “relevant
agencies . . . ‘had not been doing sufficient interagency communications and ensuring
that everybody had the right level of visibility across the entire government’ about
vulnerabilities that were discovered.” Daniel asserted that “although ‘they probably were
disclosing the vulnerability’ by default, they ‘may not have been communicating that to
all the relevant agencies as regular as they should have been.’” Agencies “might have
been communicating ‘at the subject-matter expert level,’ but the communication may
not have been happening as consistently, in as coordinated a fashion or within the
timelines that the policy dictated.”

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

241

Thus, from the public statements made after the issuance of the Daniel Blog Post, it can
be concluded that the VEP has at least once in its short history fallen out of use. While the
process appears now to be functioning well, should the issue once again fade from
attention, the policy in its current form gives few guarantees that adherence to it will not
lapse.
In November 2017, the Trump Administration published a 14-page overview of its revisions to the
VEP (available here if you wish to peruse it). As described by Ellen Nakashima in the Washington
Post:
The White House on Wednesday made public for the first time the rules by which the
government decides to disclose or keep secret software flaws that can be turned into
cyberweapons — whether by U.S. agencies hacking for foreign intelligence, moneyhungry criminals or foreign spies seeking to penetrate American computers.
The move to publish an unclassified charter responds to years of criticism that the process
was unnecessarily opaque, fueling suspicion that it cloaked a stockpile of software flaws
that the National Security Agency was hoarding to go after foreign targets but that put
Americans' cybersecurity at risk.
"This is a really big improvement and an outstanding process," said White House
cybersecurity coordinator Rob Joyce, who spoke at an Aspen Institute event and issued
a blog post on the charter.
By making it public, he said, "we hope to demonstrate to the American people that the
federal government is carefully weighing the risks and benefits" of disclosure vs. retention.
The rules are part of the "Vulnerabilities Equities Process," which the Obama
administration revamped in 2014 as a multiagency forum to debate whether and when
to inform companies such as Microsoft and Juniper that the government has discovered
or bought a software flaw that, if weaponized, could affect the security of their product.
The Trump administration has mostly not altered the rules under which the government
reaches a decision but is disclosing its process. Under the VEP, an "equities review board"
of at least a dozen national security and civilian agencies will meet monthly — or more
often, if a need arises — to discuss newly discovered vulnerabilities. Besides the NSA, the
CIA and the FBI, the list includes the Treasury, Commerce and State departments, and
the Office of Management and Budget.
The priority is on disclosure, the policy states, to protect core Internet systems, the U.S.
economy and critical infrastructure, unless there is "a demonstrable, overriding interest" in
using the flaw for intelligence or law enforcement purposes.
The government has long said that it discloses the vast majority — more than 90 percent
— of the vulnerabilities it discovers or buys in products from defense contractors or other
sellers. In recent years, that has amounted to more than 100 a year, according to people
familiar with the process.
But because the process was classified, the National Security Council, which runs the
discussion, was never able to reveal any numbers. Now, Joyce said, the number of flaws
disclosed and the number retained will be made public in an annual report. A classified
version will be sent to Congress, he said.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

242

"This represents a good step forward in transparency and shows the government getting
more comfortable and more mature with this process," said Michael Daniel, who, as
Joyce's predecessor, oversaw the revamped process. Daniel issued the first blog post on
the VEP in April 2014 in large part to push back against the misperception that the
Heartbleed bug, which sparked fears of a massive security hole in the Internet, had been
kept secret by the NSA.
The debate raged anew this year when it became public that the malicious code at the
heart of the WannaCry virus that hit computer systems globally was developed by the
NSA. The Washington Post reported in May that officials at the agency had years earlier
discussed whether the flaw at the base of the tool, EternalBlue, was so dangerous that it
should be revealed to Microsoft.
[NSA officials worried about the day its potent hacking tool would get loose. Then it did.]
Instead, the agency retained it. In August 2016, a mysterious group calling itself the
Shadow Brokers put online a set of "exploits," or tools, that included EternalBlue. That
eventually led the NSA to alert Microsoft, which issued a patch in March. But not enough
people and companies used the patch — especially in Russia, India, Iran, Brazil and
other countries in Eastern Europe and Asia where computers were infected by
WannaCry or other viruses based on the flaw.
Another major breach occurred in March, when the anti-secrecy group WikiLeaks
dumped online a trove of CIA hacking tools.
"A lot of companies whose software was affected were confused," recalled Ari Schwartz,
coordinator of the Coalition for Cybersecurity Policy and Law, which includes such firms
as Microsoft, Symantec, Intel and Palo Alto Networks. "They were taken aback that
nobody from the CIA had come to them and told them. They found out about it from the
press."
Joyce noted that at times the government has alerted a company to a flaw only to be
told, "That's great, but we're telling customers that they need to buy this shiny nextgeneration [device], and so they have no intention of patching their own equipment,"
he said. There have also been companies who, when informed of a flaw, said: "That's not
a flaw. That's a feature."
All the government can do at that point, he said, is put out a Department of Homeland
Security warning about the software flaws.
Tech companies generally reacted favorably to Wednesday's move. "Getting the VEP
right is critical to fostering trust and cooperation between the tech sector and the
government," said Heather West, senior policy manager at Mozilla, which makes the
widely used browser Firefox. "This accomplishes a lot of things we were asking for in terms
of reform."
Former critics of the process also applauded the transparency. "I'm very happy to see
that they make clear that the presumption lies in favor of disclosure," said Michelle
Richardson, a security expert at the Center for Democracy & Technology.

Sean Lyngaas, writing at FCW (Federal Computer Week) in November 2015, reported the
following:
The National Security Agency last year disclosed to the private sector about 91 percent
of previously unknown software vulnerabilities the agency discovered, according to NSA
Director Adm. Michael Rogers.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

243

"There shouldn’t be any doubt in anyone's mind that the direction clearly to us within the
U.S. government structure is a preference to disclose vulnerabilities because a secure
Internet is in the best interests of our nation and the broader world around us," said
Rogers, who also heads U.S. Cyber Command. He spoke Nov. 7 at the Reagan National
Defense Forum in Simi Valley, Calif.
The topic of "zero-day" vulnerabilities, or those unknown to the broader IT security
community, has been a hot one, with evidence suggesting the NSA has hoarded such
software flaws to exploit them in covert activities.
When asked what makes some zero-days worth keeping, Rogers said the decision to
withhold a vulnerability is based on the intelligence insight it generates. Among the other
considerations in an inter-agency process for disclosing the vulnerabilities, he said,
are: "What’s the price of not sharing this vulnerability? How broadly is it deployed?
What’s the economic impact?" The zero-day disclosure process was once internal to the
NSA but is now overseen by the National Security Council, according to an NSA
statement.
The statement said that "historically," the NSA has released more than 91 percent of the
vulnerabilities it has discovered. The other 9 percent were either already fixed by vendors
or kept "for national security reasons," the statement added.
"Disclosing a vulnerability can mean that we forego an opportunity to: collect crucial
foreign intelligence that could thwart a terrorist attack; stop the theft of our nation’s
intellectual property; [or] discover even more dangerous vulnerabilities that are being
used to exploit our networks," the NSA statement said.
Chaouki Bekrar, founder of Zerodium, a startup that rewards researchers for discovering
zero-days, noted that some vulnerabilities are more critical than others. "The NSA didn’t
say the criticality of [zero days] reported vs unreported," he tweeted. "Reporting nonexploitable [zero days] is a cheap way to improve your reports stats."
Rogers was joined at the Reagan National Defense Forum by, among others, Rep. Adam
Schiff (D-Calif.), the House Permanent Select Committee on Intelligence's ranking
minority member.
Schiff used the aftermath of the hack of Sony Pictures Entertainment, which U.S. officials
attributed to North Korea, to explain why he thought the United States lacked a credible
deterrent in cyberspace. In the wake of the hack, North Korea’s frail Internet
infrastructure experienced an outage, leading some to speculate that the United States
had retaliated in kind. The lack of clarity on whether Washington was responsible for the
outage was problematic for the congressman.
"If it was a response, it wouldn't be a very effective one," he said, "because part of
having a deterrent capability is they got to know when they’re suffering the
repercussions."

Consider this story, from Andy Greenberg at Wired (May 7, 2019), describing an instance in
which NSA-developed malware did fall into the hands of adversaries:
THE NOTION OF a so-called zero-day vulnerability in software is supposed to mean, by
definition, that it's secret. The term refers to a hackable flaw in code that the software's
maker doesn't know about but that a hacker does—in some cases offering that hacker a

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

244

powerful, stealthy skeleton key into the hearts of millions of computers. But according to
new findings from security firm Symantec, one extraordinarily powerful flaw in Microsoft
software at one point remained "secret" to Microsoft while at least three active hacker
groups knew about it. And both before and after that secret became public in early
2017, it took a long, strange trip through the hands of intelligence agencies around the
world, enabling years of espionage and, eventually, mayhem.
On Monday, Symantec revealed that it had traced how a hacker group it calls
Buckeye—also known as APT3 or Gothic Panda and widely believed to be a contractor
of the Chinese Ministry of Security Services—used NSA hacking tools apparently
intercepted from the networks of NSA targets and repurposed those tools to use against
other victims, including US allies. Most notably, Symantec says, the Chinese group's
hacking had planted an NSA backdoor on the network of its victims using a zero-day
vulnerability in Microsoft's Server Message Block (SMB) software, also seemingly learned
by studying the NSA's hacking tools.
That newly revealed hijacking of the NSA's intrusion techniques doesn't just dredge up
longstanding questions about how and when the NSA should secretly exploit software
vulnerabilities to use for spying rather than help software companies to fix them. It also
adds another chapter to the strange story of this particular zero-day's journey: Created
by the NSA, intercepted by China, later stolen and leaked by another mysterious hacker
group known as the Shadow Brokers, and ultimately used by North Korea and Russia in
two of the most damaging and costly cyberattacks in history.
"Based on what we know historically, it’s extremely unusual to have a zero-day be utilized
like this by multiple groups, some of them unbeknownst to each other, for years," says Eric
Chien, a Symantec security analyst. "I can’t think of another case where something like
this has ever happened."
With the addition of Symantec's findings, here's what we now know about the timeline of
that zero-day's path.
Born at the NSA
The SMB vulnerability—labelled as CVE-2017-0143 and CVE-2017-0144 in two slightly
different forms—appears to have first been discovered by the NSA sometime before
2016, though the NSA has never publicly admitted to having used it; it wouldn't be tied to
the agency until it leaked in 2017, revealing its integration in NSA tools called EternalBlue,
EternalRomance, and EternalSynergy.
The SMB zero-day no doubt represented a kind of precious specimen for the agency's
spies: Microsoft's SMB feature allows the sharing of files between PCs. But the agency's
researchers found that it could be tricked into confusing harmless data with executable
commands that an attacker injected via SMB into a computer's memory. That made it a
rare entry point that the NSA's hackers could use to run their own code on practically any
Windows machine with no interaction from the target user, and one that offered access
to the computer's kernel, the deepest part of its operating system. "It’s exactly the kind of
vulnerability someone would want," Chien says. "The target doesn’t have to open a

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

245

document or visit a website. You have a machine on the internet, and I can get you with
it. I immediately have the highest privileges available to me."
Or, as Matthew Hickey, founder of security firm Hacker House, at one point described it,
"It’s internet God mode."
Adopted by China
Symantec found that by March 2016, the SMB zero-day had been obtained by the
Chinese BuckEye group, which was using it in a broad spying campaign. The BuckEye
hackers seemed to have built their own hacking tool from the SMB vulnerability, and just
as unexpectedly were using it on victim computers to install the same backdoor tool,
called DoublePulsar, that the NSA had installed on its targets' machines. That suggests
that the hackers hadn't merely chanced upon the same vulnerability in their research—
what the security world calls a bug collision.; they seemed to have somehow obtained
parts of the NSA's toolkit.
Symantec's researchers say they still don’t know how the BuckEye hackers got the NSA’s
hacking secrets. But Symantec's Chien says their theory is that the tools were found in
victim networks, reverse-engineered, and repurposed. "It doesn't look like they had the
exploit executables,” says Jake Williams, a former NSA hacker and now founder of
security firm Rendition Infosec, who reviewed Symantec's findings. "But it's possible they
were able to steal them [when they were] being thrown at targets by monitoring network
communications."
Symantec says it detected BuckEye’s hackers in five different intrusions, stretching from
March 2016 to August 2017, all using the combination of the SMB exploit and the NSA's
DoublePulsar backdoor. Those intrusions, all seemingly bent on espionage, hit
telecommunications companies as well as research and educational organizations in
Hong Kong, the Philippines, Vietnam, Belgium, and Luxembourg.
Leaked and Weaponized
Starting a year after those stealthy intrusions began, however, the NSA's zero-day was
hijacked in a far more public fashion. In April 2017, a still-mysterious group calling itself the
Shadow Brokers dumped the NSA's EternalBlue, EternalRomance, EternalSynergy, and
DoublePulsar tools into public view, part of a series of leaks from the group that had
started the previous summer with a failed attempt to auction the stolen tools to the
highest bidder. It's still entirely unclear how the NSA's crown jewels ended up in the
Shadow Brokers' hands, though theories include a rogue NSA insider selling the tools and
hackers chancing upon an NSA "staging server," a machine used as a kind of remote
outpost from which to launch operations.
EternalBlue and EternalRomance were integrated into a pair of nation-state cyberattacks
that hit the vast numbers of still-unpatched computers across the globe, with
catastrophic consequences.
Anticipating that leak, Microsoft had pushed out an emergency SMB patch after a
warning from the NSA. Nonetheless, over the next two months, the now-public

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

246

EternalBlue and EternalRomance were integrated into a pair of nation-state
cyberattacks that hit the vast numbers of still-unpatched computers across the globe,
with catastrophic consequences.
First, the North Korean–coded WannaCry worm tore through the internet, combining
EternalBlue with a ransomware payload that encrypted hundreds of thousands of
computers, from police departments in India and universities in China to the National
Health Service in the United Kingdom. The next month, Russian military intelligence
hackers combined EternalBlue and EternalRomance with the open source hacking tool
Mimikatz to create an even larger digital debacle. That second worm was targeted at
Russia's enemies in Ukraine and wiped an estimated 10 percent of the country's
computers. But it quickly spread beyond Ukraine's borders, paralyzing companies such as
Maersk, a European subsidiary of FedEx, the US pharmaceutical Merck, and many others,
costing a record-breaking $10 billion in damage.
Despite the NSA's decision to help Microsoft patch its SMB flaw before those attacks, the
agency has already faced plenty of criticism for having kept its zero-day secret for as
long as it did. But with Symantec's latest revelations, the knowledge of yet another
hacker campaign that had somehow obtained that zero-day and was using it for global
spying will no doubt spark those criticisms again. It may lead to a reexamination of the
White House's so-called Vulnerabilities Equities Process, a system of determining which
flaws that US agencies discover should be patched and which ones should be used for
operations. "No matter how you play it, the fact that someone else besides the Shadow
Brokers had these exploits is extremely concerning and raises serious questions about our
vulnerability equities process," Williams says.
But others counter that the reuse of hacking tools by adversaries should be part of the
expected cost of using them in the first place. And as Symantec's BuckEye research
shows, that cost may be entirely hidden: The reuse of a zero-day by an adversary can
remain as secret as its initial use for years afterward—more than three years, in this case.
"When you utilize a vulnerability, it has a chance to be discovered," Chien says. “That can
happen, and we saw it happen here. But we didn’t know it had happened for quite
some time.”

•
•

What lesson do you take from this?
Should the United States alter its VEP policy?

Given the totality of what you have just read:
•
•
•

Should the U.S. government adopt, via legislation or executive order, any additional
rules intended to limit or regulate the use of hacking for espionage purposes?
Should the U.S. government support efforts to craft international law constraints
specifically designed to limit the use of hacking for espionage purposes?
How about promoting a limiting “norm” of some kind?

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

247

25. Government Hacking: Armed Conflict

Learning objectives
•
•

•
•
•

Know what “USCYBERCOM” is, and be able to describe the differences among Cyber
Protection Teams, Combat Mission Teams, and National Mission Teams
Understand the issues highlighted by the Task Force Ares experience, including in particular (1)
the balance between the interest in collecting intelligence and the interest in
disrupting/destroying adversary capabilities and (2) the diplomatic and other issues that arise
when an adversary’s capabilities are sustained via infrastructure located in the territory of a
third country
Understand the international legal framework relating to military cyber operations
Be able to explain what the “dual hat” is, why it came to exist in the first place, what was
expected to happen to it eventually, why some no longer want that to happen, and how
Congress intervened to ensure it would not happen until certain conditions are met
Understand how the Obama administration addressed the problem of unintended negative
consequences from operations impacting third countries, and what we know of the Trump
administration’s change to that process

In addition to hacking for purposes of criminal investigations and espionage, the U.S. government
also might wish to engage in hacking for a variety of other reasons including:
•
•

as part of an armed conflict; or
as a means to engage in competition with foreign actors below the threshold of armed
conflict (including both acknowledged and deniable actions).

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

248

We will conclude the course in this reading and the next by surveying the legal and policy issues
associated with U.S. government activity (and that of other governments) in these contexts,
starting with armed conflict.
A. Cyberspace operations in the context of armed conflict
Both regular armed forces and non-state armed groups increasingly depend on computers and
communication networks for a growing array of functions. It follows inevitably that military
organizations will seek to establish the ability to penetrate adversary systems. This certainly is true
for the armed forces of the United States.
To some extent, military hacking is a topic that falls within the scope of the espionage discussion
in the previous reading. Military organizations often perform intelligence collection, after all, both
in connection with armed conflict (as a form of combat support) and otherwise (as part of the
process of understanding the capabilities and intentions of potential adversaries). But not all
hacking carried out by military entities fits that bill. Military hacking also might occur in order to
achieve what we might call an “operational effect.” For example, a military organization might
hack a system in order to manipulate information stored there, to disrupt or destroy its functionality,
or to hold it “at risk” of such an effect.
This brings us to a critical point: military organizations conduct cyberspace operations in
connection with armed conflicts, yes, but not only in connection with armed conflicts. Knowing
that a particular cyberspace operation was conducted by a military organization thus is not
enough, on its own, to tell us whether we are dealing with a circumstance involving armed conflict
(or to put things in more colloquial terms, it is not enough to tell us whether we are dealing with a
circumstance involving war).
For the moment, we will focus on military hacking in circumstances that do constitute armed
conflict. We will save until the next subsection the critical and recurring set of issues that arise when
states use hacking (using military organizations or otherwise) to cause operational effects in the
cyber domain below that threshold.
B. The role of CYBERCOM
We have discussed US Cyber Command previously in connection with our study of how the U.S.
government defends its own networks (recall that JFHQ-DoDIN, the entity with overall responsibility
for defending the DoDIN, is a component of CYBERCOM), and also our study of the larger
defensive ecosystem and the way it can interact with international relations (for CYBERCOM at
times will take public-protecting actions such as providing IOCs to VirusTotal, especially (though
apparently not only) when accompanied by a name-and-shame attribution to a foreign
government). But CYBERCOM’s mission is by no means limited to defense. Bear that in mind as
you read this thumbnail sketch of CYBERCOM’s origins.
As Fred Kaplan explains in his book Dark Territory: The Secret History of Cyber War (available here
if you are interested in going deeper), the military’s effort to organize for cyber operations traces
back to the late 1990s. As the Department began to appreciate how vulnerable its own networks
were, it established a new office (the “Joint Task Force—Computer Network Defense,” or just “JTFCND”) to coordinate defensive efforts. Kaplan writes that the

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

249

“initial plan was to give [JTF-CND] an offensive role as well, a mandate to develop options
for attacking an adversary’s network…. [But the organizer] knew that the services wouldn’t
grant such powers to a small bureau with no command authority. … [Eventually, in] 2000,
JTF-CND became JTF-CNO, the O standing for “Operations,” and those operations
included not just Computer Network Defense but also, explicitly, Computer Network
Attack…. [JTF-CNO] was placed under the purview of U.S. Space Command…it was an
odd place to be, but SpaceCom was the only unit that wanted the mission…[and] in any
case, it was a command, invested with war-planning and war-fighting powers. [But key
leaders] felt that the cyber missions—especially those dealing with cyber offense—should
ultimately be brought to the Fort Meade headquarters of the NSA.” (pp. 121-22)
It took many years, but that is what happened in the end. In the summer of 2009, Secretary of
Defense Gates directed the creation of a new command—United States Cyber Command
(CYBERCOM)—focused on both defensive and offensive functions. In order to ensure its rapid
maturation, moreover, the new command would be collocated with NSA at Ft. Meade, and NSA’s
Director would be “dual-hatted” as the CYBERCOM commander as well. This would enable NSA
to incubate CYBERCOM in terms of personnel, knowledge, technical capabilities, and so forth.
Less obviously, it also would ensure a process for deconfliction of priorities should the interests of
CYBERCOM in causing an operational effect in cyberspace come into conflict with the interests
of NSA in collecting intelligence.
So, what exactly is CYBERCOM’s role? The Defense Department’s 2015 Cyber Strategy document
provides a handy explanation:
In 2012, DoD began to build a [Cyber Mission Force (“CMF”)] to carry out DoD’s cyber missions.
Once fully operational, the CMF will include nearly 6,200 military, civilian, and contractor
support personnel from across the military departments and defense components…. The
Cyber Mission Force will be comprised of cyber operators organized into 133 teams, primarily
aligned as follows:
Cyber Protection Forces will augment traditional defensive measures and defend priority DoD
networks and systems against priority threats;
National Mission Forces and their associated support teams will defend the United States and
its interests against cyberattacks of significant consequence; and
Combat Mission Forces and their associated support teams will support combatant
commands by generating integrated cyberspace effects in support of operational plans and
contingency operations.
Combatant commands integrate Combat Mission Forces and Cyber Protection Teams into
plans and operations and employ them in cyberspace, while the National Mission Force
operates under the Commander of USCYBERCOM. Outside of this construct, teams can also
be used to support other missions as required by the Department.
Put simply, CYBERCOM has three core missions: defend DODIN (that’s the job of the Cyber
Protection Forces, operating under the purview of JFHQ-DoDIN); provide operational capabilities
to military forces engaged in combat (that’s the job of the Combat Mission Forces, who will be

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

250

operating in practice under the purview of regional combatant commanders); and in special
circumstances defend the nation more generally (that’s the job of the National Mission Forces).

•
•

Can you identify circumstances that you feel would justify deployment of the National
Mission Forces?
Is that question harder or easier than asking the same thing about a physical-domain
threat to the United States, such as a ballistic missile or a military aircraft entering U.S.
airspace?

Now, a quick primer on what a “combatant command” is and how CYBERCOM fits into that
picture: The traditional organizational structure of the Armed Forces of the United States involved
a sharp division into a series of separate “service branches”: the Army, Navy, Air Force, and
Marines (and the Coast Guard as well, though its precise status is complicated). The several
branches not only recruited, trained, and equipped their own forces, but in the past they also
planned and commanded their own operations (often, though not always, in coordination with
one another). Today, they continue to recruit, train, and equip separately, but they no longer
plan and command operations independently. We now have a “joint forces” model for purposes
of actual operations. Under this model, assets generated by each branch come under the
operational control of a single, unified command structure. More specifically, we now have a
globe-spanning series of geographically-defined “combatant commands,” such as Central
Command (CENTCOM, which encompasses the Middle East through to Afghanistan) and IndoPacific Command (INDOPACOM).
So far so good, but it gets more complicated. In addition to these geographically defined
commands, we also have several additional commands that have no geographic boundaries
but instead are defined by the particular functions they perform or support. CYBERCOM is such a
command. Special Operations Command (SOCOM) is another. These functional commands are
like the geographic ones in that their subordinate units and personnel are mostly generated by
the various service branches, but then brought together under a “joint” command structure for
operational purposes. In CYBERCOM’s case, that means that Army, Navy, Air Force, and Marine
units and personnel make up the various Cyber Mission Forces.

•

You likely have heard of the creation of Space Force as a new service branch in the
U.S. military. Should we create “Cyber Force,” such that the task of recruiting, training,
and equipping cyber mission teams falls to an independent branch rather than Army,
Navy, Air Force, and Marines?

C. CYBERCOM’s role during armed conflict: Joint Task Force-Ares as a case study
Let’s start with a word of caution about terminology. People often use phrases like cyber war and
cyber attack without meaning to claim that an actual circumstance of war exists or that a
particular action amounts to an attack in a war-related sense. Such terms are just convenient
shorthands in such cases. Unfortunately, such language can sometimes lead to confusion. Always

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

251

be clear about your own use of these terms, and be alert to how others might be using (or
misusing) them.

•

Do a search to find recent news articles that use the words “cyberwar” or “cyber
attack.” Do any of the examples seem misplaced?

Having said that, let us assume for the moment that we do have a circumstance of armed conflict,
such as the conflict in Iraq and Syria involving the Islamic State. What are the critical policy and
legal issues that arise when CYBERCOM conducts operations for effect in that setting?
To answer that, let’s use the experience of Joint Task Force-Ares as a case study. JTF-Ares is the
name of the CYBERCOM mission to engage the Islamic State in the cyber domain, for purposes of
both intelligence-gathering and achieving operational effects (either stand-alone operational
effects such as shutting down a website operated by IS, or effects intended to support kinetic
operations in the field). In 2016, the public began to catch glimpses of internal U.S. government
debates associated with these activities, glimpses that highlighted a variety of recurring issues
raised by this scenario. The following text is excerpted from a post I wrote for Lawfare in 2017,
marshaling the public reports that existed up to that point and using them to highlight the issues:
1. July 2016 – Reports of DOD frustration over pace of anti-ISIS cyber operations
In July 2016, the Washington Post (Ellen Nakashima & Missy Ryan) reported on
CYBERCOM’s efforts to disrupt the Islamic State’s online activities (internal
communications, external propaganda, financing, etc.), emphasizing the view of DOD
leadership that CYBERCOM was underperforming:
“An unprecedented Pentagon cyber-offensive against the Islamic State has gotten off to
a slow start, officials said, frustrating Pentagon leaders and threatening to undermine
efforts to counter the militant group’s sophisticated use of technology for recruiting,
operations and propaganda. … But defense officials said the command is still working to
put the right staff in place and has not yet developed a full suite of malware and other
tools tailored to attack an adversary dramatically different from the nation-states
Cybercom was created to fight. … Although officials declined to detail current
operations, they said that cyberattacks occurring under the new task force might, for
instance, disrupt a payment system, identify a communications platform used by Islamic
State members and knock it out, or bring down Dabiq, the Islamic State’s online magazine.
…”
The report is an excellent snapshot of several distinct challenges the military use of
computer network operations can pose.
One such challenge is operational capacity. The story suggests that CYBERCOM simply did
not have the right personnel and the right exploits on hand for this particular mission, at
least at the start. That’s a problem that can be fixed, and the report details the steps DOD
began taking in 2016 to do just that.
Another challenge is the need to have an effective process for deconfliction between
intelligence-collection and operational-effect equities. As the article summarized the
issue:

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

252

“Whenever the military undertakes a cyber-operation to disrupt a network, the intelligence
community may risk losing an opportunity to monitor communications on that network. So
military cybersecurity officials have worked to better coordinate their target selection and
operations with intelligence officials.”
This is not a novel tension, in the abstract. For as long as there has been signals intelligence,
there have been tensions of this kind. When one side has access to the other’s
communications, there will always be tension between the temptation to exploit that
access for operational effect (with the opportunity cost of risking loss of that access going
forward as the enemy realizes it has been monitored) and the temptation to instead
exploit it for indirect intelligence advantage (with the opportunity cost of forgoing direct
operational advantage in at least some cases). World War II provides famous
examples. And so one might fairly ask: is there anything really different about computer
network operations, warranting special attention to the topic in this setting?
Perhaps. In this domain there is much more overlap between the means of collection and
the means of carrying out a disruptive operations. Indeed, those means often will be the
exact same: a particular exploit providing access to an enemy device, network, etc. It
seems to me that this ensures that the tension between collection and operational equities
will arise with greater frequency, and less room for workarounds, than in more familiar
settings.
Having mentioned both the operational capacity concern and the competing-equities
concern, now is a good time to emphasize the significance of the status-quo for NSA and
CYBERCOM: the dual-hatted commander. Whereas more familiar, traditional scenarios
involving tension between collection and operational equities usually involve distinct
underlying institutions and commanders, the status quo with respect to computer network
operations has always (well, the past seven years) involved the dual-hatting of NSA’s
director and CYBERCOM’s commander.
This model in theory ensures that neither institution has a home-field advantage, and
maximizes the chance that the key decisionmaker (yes, there can be important decisions
both below and above the dual-hat, but the dual-hat is obviously in the key position) fully
buys into and fully grasps the importance of each institution’s mission.
Of course, it is possible that the dual-hat might tilt one direction to an unfair or undesirable
degree. And it is possible that some might perceive such a tilt even when there isn’t one.
As 2016 wore on, questions of this kind began to appear in public, and by September the
media was reporting that DNI Clapper and SecDef Carter both were in favor of splitting
up the dual-hat. It was not the first time this topic had come up, to be sure; President
Obama had considered ordering a split in 2013 (during the aftermath of the Snowden
controversy), but had not taken that step at least in part out of concern about
CYBERCOM’s independent operational capacity. Now the idea appeared to have
momentum.
A report from Ellen Nakashima in the Washington Post that same month suggested that this
momentum was in part a product of CYBERCOM’s operational maturation, but also in
significant part driven by the perception that Admiral Rogers, the current dual-hat, favored
collection equities to an undue extent:
“Whether or not it’s true, the perception with Secretary Carter and [top aides] has become
that the intelligence agency has been winning out at the expense of [cyber] war efforts,”
said one senior military official….

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

253

(See also this report by the New York Times, stating that frustration along these same lines
contributed to the effort to get President Obama to remove Admiral Rogers in late 2016.)
The Washington Post report also highlighted concerns that splitting NSA and CYBERCOM
at the leadership level might actually weaken rather than empower CYBERCOM, as NSA
inevitably would become free to withhold from CYBERCOM at least some exploits or other
forms of access so that sources would not be lost:
“Cyber Command’s mission, their primary focus, is to degrade or destroy,” the former
official said. “NSA’s is exploit [to gather intelligence] only. So without having one person as
the leader for both, the bureaucratic walls will go up and you’ll find NSA not cooperating
with Cyber Command to give them the information they’ll need to be successful.”
2. December 2016 – Congress puts on the brakes
Against this backdrop, Congress intervened in late 2016 to slow down the Obama
administration’s move to split the dual-hat. Section 1642 of the NDAA FY’17, enacted in
late December, provides that NSA and CYBERCOM must continue to share a dual-hatted
director/commander unless and until the Secretary of Defense and the Chairman of the
Joint Chiefs of Staff jointly certify to certain Congressional committees (SASC & HASC; SSCI
& HPSCI; and the Appropriations Committees) that separation will not pose
“unacceptable” risks to CYBERCOM’s effectiveness, and that the following six conditions
are met:
“(i) Robust operational infrastructure has been deployed that is sufficient to meet the
unique cyber mission needs of the United States Cyber Command and the National
Security Agency, respectively.
(ii) Robust command and control systems and processes have been established for
planning, deconflicting, and executing military cyber operations.
(iii) The tools and weapons used in cyber operations are sufficient for achieving required
effects.
(iv) Capabilities have been established to enable intelligence collection and operational
preparation of the environment for cyber operations.
(v) Capabilities have been established to train cyber operations personnel, test cyber
capabilities, and rehearse cyber missions.
(vi) The cyber mission force has achieved full operational capability. Section 1642(b)(2)(C)
(emphasis added).
President Obama’s signing statement criticized Congress for imposing this requirement, but
did not include a claim that it was unconstitutional. It remains the law at this time.
3. Early 2017 – Complications in the War Against the Islamic State
While lawmakers and policymakers wrestled with the pros and cons of splitting NSA and
CYBERCOM, computer network operations against the Islamic State continued to
accelerate.
Along the way, however, new problems emerged.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

254

As Ellen Nakashima of the Washington Post reported in May 2017, CYBERCOM by late 2016
had encountered a new set of challenges in its enhanced effort to shut down ISIS sites and
platforms: third-country effects.
“A secret global operation by the Pentagon late last year to sabotage the Islamic State’s
online videos and propaganda sparked fierce debate inside the government over
whether it was necessary to notify countries that are home to computer hosting services
used by the extremist group, including U.S. allies in Europe. … Cybercom developed the
campaign under pressure from then-Defense Secretary Ashton B. Carter, who wanted the
command to raise its game against the Islamic State. But when the CIA, State Department
and FBI got wind of the plan to conduct operations inside the borders of other countries
without telling them, officials at the agencies immediately became concerned that the
campaign could undermine cooperation with those countries on law enforcement,
intelligence and counterterrorism. The issue took the Obama National Security Council
weeks to address…”
This article highlights a third significant challenge associated with computer network
operations: attacking the enemy’s online presence often requires, or at least risks, some
degree of impact on servers located in other countries. Third-country impact involves both
legal and policy challenges, and as the quote above illustrates it also brings into play
otherwise-unrelated equities of other agencies. Thus, the competing-equities tension is not
just a clash between collection and operational equities, but in some cases many others
as well. The dual-hat command structure is primarily an answer only to the former, not the
latter.
Meanwhile, a sobering reality about the utility of cyberattacks on Islamic State
communications began to become clear: the effects often did not last. This was the thrust
of an important piece by David Sanger and Eric Schmitt in the New York Times in June
2017:
“[S]ince they began training their arsenal of cyberweapons on …internet use by the Islamic
State, the results have been a consistent disappointment, American officials say. … [It] has
become clear that recruitment efforts and communications hubs reappear almost as
quickly as they are torn down. … “In general, there was some sense of disappointment in
the overall ability for cyberoperations to land a major blow against ISIS," or the Islamic
State, said Joshua Geltzer, who was the senior director for counterterrorism at the National
Security Council until March. "This is just much harder in practice than people think..."
This suggested that the military equities that some felt had been undervalued by Admiral
Rogers in the past were less weighty than proponents had assumed. Nonetheless,
momentum towards separation—and concern that the dual-hat unduly favors collection
equities—continues.
In mid-July, reports emerged that the Pentagon had submitted to the Trump administration
a plan for effectuating the split, with some of the accompanying commentary continuing
to advance the argument that NSA holds CYBERCOM back to an improper extent:
“The goal, [unnamed U.S. officials] said, is to give U.S. Cyber Command more autonomy,
freeing it from any constraints that stem from working alongside the NSA, which is
responsible for monitoring and collecting telephone, internet and other intelligence data
from around the world — a responsibility that can sometimes clash with military operations
against enemy forces.”

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

255

This account raises a number of questions for you to consider:
•
•
•

•
•

Can you list the variables that may have constrained CYBERCOM in conducting
operations for effect against the Islamic State?
What are the pros and cons of ending the dual-hat arrangement?
Military operations that produce damage in the physical world often are followed by
enemy efforts to repair that damage and restore functionality. Is there reason to think
such remediation efforts are, on the whole, easier in cyberspace?
Can you explain the diplomatic challenge associated with the risk of third-party
effects?
What steps, if any, would you recommend embracing in order to address that
challenge?

The account above refers to interagency battles over potential CYBERCOM operations, with CIA,
State, and Justice objecting at certain points. This might cause you to wonder: What put those
organizations in a position even to know about those plans, let alone to object effectively at the
White House level? The answer has to do with an Obama administration policy directive that
reportedly required interagency vetting of this sort for military cyber operations expected to have
effects outside of areas of active hostilities. Notably, Trump administration officials have
announced that this requirement has been revoked (in the form of National Security Presidential
Memorandum 13, the precise details of which are not yet public). Some have argued, since then,
that there remains a strong element of interagency vetting in these cases. But let’s assume that
there is at least a reduction in the extent of that vetting:

•

What are the pros and cons of weakening the interagency vetting requirement?

The third-party effect issue also raises a profoundly-sensitive set of international law issues. How
so? Here’s a thumbnail sketch. First, Article 2(4) of the U.N. Charter prohibits the “use of force” in
international affairs, absent special conditions including (i) a specific type of approval by the U.N.
Security Council or (ii) the existence of an armed attack to which this action is a necessary and
proportionate response.

If the U.S. government were to shut down an Islamic State propaganda site run from a server
in Germany, without seeking consent from the German government:
•
•
•
•

Would that constitute a “use of force” implicating Article 2(4)?
Would the U.S. government likely be able to get a U.N. Security Council resolution
authorizing the action?
If this could be done, would timing nonetheless be an issue?
The United States might argue that it and its coalition partners are responding to an
armed attack from the Islamic State. Assume that this is a plausible argument to
explain the use of force against the Islamic State in Iraq and Syria. Is it obvious that the
same would be true as to an activity taking effect in Germany?

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

256

If a cyber-domain activity does not constitute a “use of force” regulated by the U.N. Charter, it
might nonetheless constitute an “internationally-wrongful act” in the sense of being a prohibited
“intervention” in the internal affairs of a sovereign state. This is a hot topic in international law,
currently. To understand why, consider this excerpt from a much-noted articulation of the British
view of these questions, from then Attorney General Jeremy Wright in May 2018:
“In certain circumstances, cyber operations which do not meet the threshold of the use of
force but are undertaken by one state against the territory of another state without that
state’s consent will be considered a breach of international law.
The international law prohibition on intervention in the internal affairs of other states is of
particular importance in modern times when technology has an increasing role to play in
every facet of our lives, including political campaigns and the conduct of elections. As set
out by the International Court of Justice in its judgment in the Nicaragua case, the purpose
of this principle is to ensure that all states remain free from external, coercive intervention
in the matters of government which are at the heart of a state’s sovereignty, such as the
freedom to choose its own political, social, economic and cultural system.
The precise boundaries of this principle are the subject of ongoing debate between states,
and not just in the context of cyber space. But the practical application of the principle in
this context would be the use by a hostile state of cyber operations to manipulate the
electoral system to alter the results of an election in another state, intervention in the
fundamental operation of Parliament, or in the stability of our financial system. Such acts
must surely be a breach of the prohibition on intervention in the domestic affairs of states.
Furthermore, a breach of this principle of non-intervention provides victim states with the
ability to take action in response that would otherwise be considered unlawful, but which
is permissible if it is aimed at returning relations between the hostile state and the victim
state to one of lawfulness, and bringing an end to the prior unlawful act. Such action is
permissible under the international law doctrine of countermeasures. Put simply, if a hostile
state breaches international law as a result of its coercive actions against the target state’s
sovereign freedoms, then the victim state can take action to compel that hostile state to
stop.
Consistent with the de-escalatory nature of international law, there are clear restrictions
on the actions that a victim state can take under the doctrine of countermeasures. A
countermeasure can only be taken in response to a prior internationally wrongful act
committed by a state, and must only be directed towards that state. This means that the
victim state must be confident in its attribution of that act to a hostile state before it takes
action in response. In cyberspace of course, attribution presents particular challenges, to
which I will come in a few moments. Countermeasures cannot involve the use of force,
and they must be both necessary and proportionate to the purpose of inducing the hostile
state to comply with its obligations under international law.
These restrictions under the doctrine of countermeasures are generally accepted across
the international law community. The one area where the UK departs from the excellent
work of the International Law Commission on this issue is where the UK is responding to
covert cyber intrusion with countermeasures.
In such circumstances, we would not agree that we are always legally obliged to give
prior notification to the hostile state before taking countermeasures against it. The
covertness and secrecy of the countermeasures must of course be considered necessary
and proportionate to the original illegality, but we say it could not be right for international

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

257

law to require a countermeasure to expose highly sensitive capabilities in defending the
country in the cyber arena, as in any other arena.
In addition, it is also worth stating that, as a matter of law, there is no requirement in the
doctrine of countermeasures for a response to be symmetrical to the underlying unlawful
act. What matters is necessity and proportionality, which means that the UK could respond
to a cyber intrusion through non-cyber means, and vice versa.
Through the principle of non-intervention, it is clear that the international community has
set a boundary at which interference in another state’s sovereign freedoms is considered
internationally wrongful and as such, in breach of international law, giving rise to the right
to take action which may otherwise be unlawful in response. As I have already mentioned,
the precise parameters of this principle remain the subject of ongoing debate in the
international law community, but a further contested area amongst those engaged in the
application of international law to cyber space is the regulation of activities that fall below
the threshold of a prohibited intervention, but nonetheless may be perceived as affecting
the territorial sovereignty of another state without that state’s prior consent.
Some have sought to argue for the existence of a cyber specific rule of a “violation of
territorial sovereignty” in relation to interference in the computer networks of another state
without its consent.
Sovereignty is of course fundamental to the international rules-based system. But I am not
persuaded that we can currently extrapolate from that general principle a specific rule or
additional prohibition for cyber activity beyond that of a prohibited intervention. The UK
Government’s position is therefore that there is no such rule as a matter of current
international law.”
It is widely thought that this understanding of the legal status of sovereignty reflects the U.S. position
as well. Here is language from a speech by Brian Egan, then the Legal Adviser of the State
Department, in 2016:
“In certain circumstances, one State’s non-consensual cyber operation in another State’s
territory could violate international law, even if it falls below the threshold of a use of force.
This is a challenging area of the law that raises difficult questions. The very design of the
Internet may lead to some encroachment on other sovereign jurisdictions. Precisely when
a non-consensual cyber operation violates the sovereignty of another State is a question
lawyers within the U.S. government continue to study carefully, and it is one that ultimately
will be resolved through the practice and opinio juris of States.
Relatedly, consider the challenges we face in clarifying the international law prohibition
on unlawful intervention. As articulated by the International Court of Justice (ICJ) in its
judgment on the merits in the Nicaragua Case, this rule of customary international law
forbids States from engaging in coercive action that bears on a matter that each State is
entitled, by the principle of State sovereignty, to decide freely, such as the choice of a
political, economic, social, and cultural system. This is generally viewed as a relatively
narrow rule of customary international law, but States’ cyber activities could run afoul of
this prohibition. For example, a cyber operation by a State that interferes with another
country’s ability to hold an election or that manipulates another country’s election results
would be a clear violation of the rule of non-intervention. For increased transparency,
States need to do more work to clarify how the international law on non-intervention
applies to States’ activities in cyberspace.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

•

258

Can you explain how the varying national interests and circumstances of the United
States, Russia, and China might cause them to take different positions on these issues?

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

259

26. Government Hacking: Grey-Zone Competition

Learning objectives
•
•
•
•
•
•
•

Understand the uncertainties associated with the idea of a “grey zone” category
Understand the arguments for and against conducting cyber operations that are meant to
have a disruptive impact outside the context of armed conflict
Form a view on which types of government agency(ies) should have responsibility for such
activity, if it is to be conducted at all
Be able to describe the way that the US government has allocated authority in this area
Be familiar with the Stuxnet/Olympic Games episode and lessons learned from it
Understand the scope of activities attributed to Sandworm, and lessons learned from them
Appreciate the international law questions associated with grey zone cyber activity

A. Defining the parameters of this category
The prior reading illustrated how cyber domain operations during armed conflict raise interesting
legal and policy questions. Yet they are not quite as interesting, perhaps, as the ones raised by
operations carried out in the cyber domain that have disruptive or destructive effects but that are
not carried out in connection with armed conflict.
Let’s begin with an effort to be precise about the category of activity that is at issue here. We are
not talking about cyber activities primarily intended to support espionage. Rather, we are
focused on activities that are primarily intended to cause effects. Those effects might concern
computer systems themselves, altering or disrupting their function as an end in itself, or they might
conducted as a means to cause physical-world effects. In either case, the key point is that a

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

260

variety of policy and legal questions arise when such activities occur outside the context of armed
conflict.
Let’s begin by noting that there is a question regarding whether and how to apply a single label
to this category of activity. Recognizing that a growing number of states appear to find such
activity to be an appealing way to advance their national interests, some would apply the
concept of “grey zone competition” here. That evocative label reflects the idea that states
sometimes compete with one another in aggressively-adversarial ways that are difficult for
outsiders to observe clearly, and thus are “grey” both in terms of transparency and in terms of the
spectrum of intensity that runs from peaceful relations to war. Not all such activity occurs within
the cyber domain, of course, but the cyber domain is well-suited to grey zone competition given
the difficulties of attribution and collapsing of geographic distance that it entails.
Bearing all that in mind, and noting that there are few if any alternative conceptual shorthands
available, it is understandable, perhaps even inevitable, that grey zone competition is used in this
context. But do not lose sight of the fact that this is not a formal legal category along the lines of
“armed conflict,” and that people may vary widely in what comes to mind when they hear or see
this label.

•
•
•
•
•
•
•

Do you find the “grey zone” label helpful? Why or why not?
Is there a better alternative?
Can you articulate how this category differs from the category “espionage”?
Can you think of reasons why a government might want to conduct a “grey zone”
cyber operation impacting computer systems in another country?
Can you think of reasons why a government nonetheless should not engage in this sort
of activity?
Can you think of real world examples possibly conducted by the United States?
Can you think of real world examples possibly conducted against the United States?

B. Whose job should this be?
In a moment we will look at some of the legal considerations raised by grey zone cyber activity.
Before we do that, however, let’s consider whether such activity should be the particular province
of any specific type of government entity.
The practical capability to perform such operations might be found within an array of government
organizations. A country’s military might have the means. So too one or more of its intelligence
agencies. So too with its law enforcement agencies. In short, practical capacity does not in all
cases dictate the allocation of responsibility for conducting such operations.
Is there something inherent in the nature of such operations, however, that suggests that they
should usually be performed by a particular type of government entity?
Because this category by definition exists below the level of armed conflict, it is not obvious that
the role should fall to military entities. On the other hand, militaries do routinely have a key role in
non-armed-conflict situations (hostage rescue, peacekeeping, disaster response, etc.), so this
consideration also does not rule them out of the picture.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

261

Meanwhile, the possibility that such activities will be conducted in a manner intended to obscure
the responsible government’s role does point conceptually towards the familiar category of
“covert action” (that is, operations intended to cause practical effects where the sponsoring role
of the government is not meant to be apparent or acknowledged), which ordinarily is the
province of an intelligence agency. This common feature of grey zone cyber activity thus appears
at first glance to favor allocation of responsibility to such an agency. That said, it is not the case
that covert action must be performed only by intelligence agencies. In the US system, for
example, the default rule is that covert action should be performed by the CIA. The president
can assign responsibility elsewhere in particular cases, however, and in any event the statutory
definition of “covert action” expressly excludes situations that qualify as traditional “military
activities.” So, again, the picture is a muddy one.

Assume your government wants to have a grey zone cyber capacity, and you have complete
freedom to assign that function to one or more existing government entities.
•
•
•
•

Would you assign this exclusively to just one of them? Why or why not?
What factors would matter most to you in making this decision?
Which type of entity would you most likely ask to play the leading role, and why?
If money was no object, would you consider creating a brand-new, stand-alone
agency for this purpose? Why or why not?

C. How the United States currently distributes responsibility for this function
For the U.S. government, the ability to perform cyber operations for disruptive or destructive effect
outside the context of armed conflict is lodged both with USCYBERCOM and the CIA.
The CIA, as noted, is America’s lead agency for covert action in general, and there is nothing that
precludes a given covert action program from including a cyber component. And as we shall
see in the case study on Stuxnet below, there is ample reason in the public record to believe that
CIA at times has been directed to execute a covert action program that includes cyber domain
operations of this kind.
Meanwhile, Congress has taken a number of steps to ensure that USCYBERCOM has clear statutory
authority to engage in at least some forms of grey zone activity too—including operational steps
distinct from the blue-space defensive missions we have discussed previously. Until recently, there
had been considerable uncertainty regarding whether CYBERCOM has affirmative authority
under U.S. law to take on this particular role. To some extent, this reflected tension with the CIA’s
lead responsibility for conducting covert action and the related consideration, noted above, that
traditional military activities are formally excluded from the covert action category. To resolve
that tension in a way that would empower USCYBERCOM, Congress has passed a series of statutes
that collectively establish that USCYBERCOM can conduct such operations and that they do not
count as covert action under US law even if there are deniable elements to the operation. Here
are the key passages, now codified as 10 USC 394:
(a) IN GENERAL.-The Secretary of Defense shall … when appropriately authorized to do so,
conduct, military cyber activities or operations in cyberspace, including clandestine

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

262

military activities or operations in cyberspace, to defend the United States and its allies,
including in response to malicious cyber activity carried out against the United States or a
United States person by a foreign power.
(b) AFFIRMATION OF AUTHORITY.-Congress affirms that the activities or operations referred
to in subsection (a), when appropriately authorized, include the conduct of military
activities or operations in cyberspace short of hostilities … including for the purpose of
preparation of the environment, information operations, force protection, and deterrence
of hostilities, or counterterrorism operations involving the Armed Forces of the United States.
(c) CLANDESTINE ACTIVITIES OR OPERATIONS.-A clandestine military activity or operation in
cyberspace shall be considered a traditional military activity for the purposes of [the
statutory definition of “covert action”]

•

Is this two-track arrangement (CIA and USCYBERCOM) optimal?

In Section 1642 of the NDAA Fiscal Year ’19, moreover, Congress added the following statement
of authority:
(a) AUTHORITY TO DISRUPT, DEFEAT, AND DETER CYBER ATTACKS.—
(1) IN GENERAL.—In the event that the National Command Authority determines that the
Russian Federation, People’s Republic of China, Democratic People’s Republic of Korea,
or Islamic Republic of Iran is conducting an active, systematic, and ongoing campaign of
attacks against the Government or people of the United States in cyberspace, including
attempting to influence American elections and democratic political processes, the
National Command Authority may authorize the Secretary of Defense, acting through the
Commander of the United States Cyber Command, to take appropriate and proportional
action in foreign cyberspace to disrupt, defeat, and deter such attacks under the authority
and policy of the Secretary of Defense to conduct cyber operations and information
operations as traditional military activities.

•
•

Can you break this statute down into “elements” that must be satisfied?
What is the consequence if one or more of these elements is not satisfied?

D. Case study: Stuxnet and Olympic Games
Perhaps the most famous example of a grey-zone cyber operation apparently conducted in part
by the United States involved an ambitious covert action program intended to disrupt centrifuges
at the Iranian nuclear enrichment facility in Natanz. David Sanger of the New York Times played
a key role in the early public reporting on these dramatic events. Here are excerpts from one of
the key articles he wrote, from the summer of 2012:

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

263

From his first months in office, President Obama secretly ordered increasingly
sophisticated attacks on the computer systems that run Iran’s main nuclear enrichment
facilities, significantly expanding America’s first sustained use of cyberweapons,
according to participants in the program.
Mr. Obama decided to accelerate the attacks — begun in the Bush administration and
code-named Olympic Games — even after an element of the program accidentally
became public in the summer of 2010 because of a programming error that allowed it to
escape Iran’s Natanz plant and sent it around the world on the Internet. Computer
security experts who began studying the worm, which had been developed by the
United States and Israel, gave it a name: Stuxnet.
At a tense meeting in the White House Situation Room within days of the worm’s
“escape,” Mr. Obama, Vice President Joseph R. Biden Jr. and the director of the Central
Intelligence Agency at the time, Leon E. Panetta, considered whether America’s most
ambitious attempt to slow the progress of Iran’s nuclear efforts had been fatally
compromised.
“Should we shut this thing down?” Mr. Obama asked, according to members of the
president’s national security team who were in the room.
Told it was unclear how much the Iranians knew about the code, and offered evidence
that it was still causing havoc, Mr. Obama decided that the cyberattacks should
proceed. In the following weeks, the Natanz plant was hit by a newer version of the
computer worm, and then another after that. The last of that series of attacks, a few
weeks after Stuxnet was detected around the world, temporarily took out nearly 1,000 of
the 5,000 centrifuges Iran had spinning at the time to purify uranium.
This account of the American and Israeli effort to undermine the Iranian nuclear program
is based on interviews over the past 18 months with current and former American,
European and Israeli officials involved in the program, as well as a range of outside
experts. None would allow their names to be used because the effort remains highly
classified, and parts of it continue to this day.
These officials gave differing assessments of how successful the sabotage program was in
slowing Iran’s progress toward developing the ability to build nuclear weapons. Internal
Obama administration estimates say the effort was set back by 18 months to two years,
but some experts inside and outside the government are more skeptical, noting that
Iran’s enrichment levels have steadily recovered, giving the country enough fuel today
for five or more weapons, with additional enrichment.
… Iran initially denied that its enrichment facilities had been hit by Stuxnet, then said it
had found the worm and contained it. Last year, the nation announced that it had
begun its own military cyberunit, and Brig. Gen. Gholamreza Jalali, the head of Iran’s
Passive Defense Organization, said that the Iranian military was prepared “to fight our
enemies” in “cyberspace and Internet warfare.” But there has been scant evidence that
it has begun to strike back.
…It appears to be the first time the United States has repeatedly used cyberweapons to
cripple another country’s infrastructure, achieving, with computer code, what until then
could be accomplished only by bombing a country or sending in agents to plant
explosives. The code itself is 50 times as big as the typical computer worm, Carey

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

264

Nachenberg, a vice president of Symantec, one of the many groups that have dissected
the code, said at a symposium at Stanford University in April. Those forensic investigations
into the inner workings of the code, while picking apart how it worked, came to no
conclusions about who was responsible.
A similar process is now under way to figure out the origins of another cyberweapon
called Flame that was recently discovered to have attacked the computers of Iranian
officials, sweeping up information from those machines. But the computer code appears
to be at least five years old, and American officials say that it was not part of Olympic
Games. They have declined to say whether the United States was responsible for the
Flame attack.
Mr. Obama, according to participants in the many Situation Room meetings on Olympic
Games, was acutely aware that with every attack he was pushing the United States into
new territory, much as his predecessors had with the first use of atomic weapons in the
1940s, of intercontinental missiles in the 1950s and of drones in the past decade. He
repeatedly expressed concerns that any American acknowledgment that it was using
cyberweapons — even under the most careful and limited circumstances — could
enable other countries, terrorists or hackers to justify their own attacks.
“We discussed the irony, more than once,” one of his aides said. Another said that the
administration was resistant to developing a “grand theory for a weapon whose
possibilities they were still discovering.” Yet Mr. Obama concluded that when it came to
stopping Iran, the United States had no other choice.
If Olympic Games failed, he told aides, there would be no time for sanctions and
diplomacy with Iran to work. Israel could carry out a conventional military attack,
prompting a conflict that could spread throughout the region.
A Bush Initiative
The impetus for Olympic Games dates from 2006, when President George W. Bush saw
few good options in dealing with Iran. At the time, America’s European allies were
divided about the cost that imposing sanctions on Iran would have on their own
economies. Having falsely accused Saddam Hussein of reconstituting his nuclear
program in Iraq, Mr. Bush had little credibility in publicly discussing another nation’s
nuclear ambitions. The Iranians seemed to sense his vulnerability, and, frustrated by
negotiations, they resumed enriching uranium at an underground site at Natanz, one
whose existence had been exposed just three years before.
Iran’s president, Mahmoud Ahmadinejad, took reporters on a tour of the plant and
described grand ambitions to install upward of 50,000 centrifuges. For a country with only
one nuclear power reactor — whose fuel comes from Russia — to say that it needed fuel
for its civilian nuclear program seemed dubious to Bush administration officials. They
feared that the fuel could be used in another way besides providing power: to create a
stockpile that could later be enriched to bomb-grade material if the Iranians made a
political decision to do so.
Hawks in the Bush administration like Vice President Dick Cheney urged Mr. Bush to
consider a military strike against the Iranian nuclear facilities before they could produce
fuel suitable for a weapon. Several times, the administration reviewed military options

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

265

and concluded that they would only further inflame a region already at war, and would
have uncertain results.
For years the C.I.A. had introduced faulty parts and designs into Iran’s systems — even
tinkering with imported power supplies so that they would blow up — but the sabotage
had had relatively little effect. General James E. Cartwright, who had established a small
cyberoperation inside the United States Strategic Command, which is responsible for
many of America’s nuclear forces, joined intelligence officials in presenting a radical
new idea to Mr. Bush and his national security team. It involved a far more sophisticated
cyberweapon than the United States had designed before.
The goal was to gain access to the Natanz plant’s industrial computer controls. That
required leaping the electronic moat that cut the Natanz plant off from the Internet —
called the air gap, because it physically separates the facility from the outside world. The
computer code would invade the specialized computers that command the centrifuges.
The first stage in the effort was to develop a bit of computer code called a beacon that
could be inserted into the computers, which were made by the German company
Siemens and an Iranian manufacturer, to map their operations. The idea was to draw the
equivalent of an electrical blueprint of the Natanz plant, to understand how the
computers control the giant silvery centrifuges that spin at tremendous speeds. The
connections were complex, and unless every circuit was understood, efforts to seize
control of the centrifuges could fail.
Eventually the beacon would have to “phone home” — literally send a message back to
the headquarters of the National Security Agency that would describe the structure and
daily rhythms of the enrichment plant. Expectations for the plan were low; one
participant said the goal was simply to “throw a little sand in the gears” and buy some
time. Mr. Bush was skeptical, but lacking other options, he authorized the effort.
Breakthrough, Aided by Israel
It took months for the beacons to do their work and report home, complete with maps of
the electronic directories of the controllers and what amounted to blueprints of how they
were connected to the centrifuges deep underground.
Then the N.S.A. and a secret Israeli unit respected by American intelligence officials for its
cyberskills set to work developing the enormously complex computer worm that would
become the attacker from within.
The unusually tight collaboration with Israel was driven by two imperatives. Israel’s Unit
8200, a part of its military, had technical expertise that rivaled the N.S.A.’s, and the Israelis
had deep intelligence about operations at Natanz that would be vital to making the
cyberattack a success. But American officials had another interest, to dissuade the
Israelis from carrying out their own pre-emptive strike against the Iranian nuclear facilities.
To do that, the Israelis would have to be convinced that the new line of attack was
working. The only way to convince them, several officials said in interviews, was to have
them deeply involved in every aspect of the program.
Soon the two countries had developed a complex worm that the Americans called “the
bug.” But the bug needed to be tested. So, under enormous secrecy, the United States
began building replicas of Iran’s P-1 centrifuges, an aging, unreliable design that Iran

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

266

purchased from Abdul Qadeer Khan, the Pakistani nuclear chief who had begun selling
fuel-making technology on the black market. Fortunately for the United States, it already
owned some P-1s, thanks to the Libyan dictator, Col. Muammar el-Qaddafi.
When Colonel Qaddafi gave up his nuclear weapons program in 2003, he turned over
the centrifuges he had bought from the Pakistani nuclear ring, and they were placed in
storage at a weapons laboratory in Tennessee. The military and intelligence officials
overseeing Olympic Games borrowed some for what they termed “destructive testing,”
essentially building a virtual replica of Natanz, but spreading the test over several of the
Energy Department’s national laboratories to keep even the most trusted nuclear
workers from figuring out what was afoot.
Those first small-scale tests were surprisingly successful: the bug invaded the computers,
lurking for days or weeks, before sending instructions to speed them up or slow them
down so suddenly that their delicate parts, spinning at supersonic speeds, selfdestructed. After several false starts, it worked. One day, toward the end of Mr. Bush’s
term, the rubble of a centrifuge was spread out on the conference table in the Situation
Room, proof of the potential power of a cyberweapon. The worm was declared ready to
test against the real target: Iran’s underground enrichment plant.
“Previous cyberattacks had effects limited to other computers,” Michael V. Hayden, the
former chief of the C.I.A., said, declining to describe what he knew of these attacks
when he was in office. “This is the first attack of a major nature in which a cyberattack
was used to effect physical destruction,” rather than just slow another computer, or hack
into it to steal data.
“Somebody crossed the Rubicon,” he said.
Getting the worm into Natanz, however, was no easy trick. The United States and Israel
would have to rely on engineers, maintenance workers and others — both spies and
unwitting accomplices — with physical access to the plant. “That was our holy grail,” one
of the architects of the plan said. “It turns out there is always an idiot around who doesn’t
think much about the thumb drive in their hand.”
In fact, thumb drives turned out to be critical in spreading the first variants of the
computer worm; later, more sophisticated methods were developed to deliver the
malicious code.
The first attacks were small, and when the centrifuges began spinning out of control in
2008, the Iranians were mystified about the cause, according to intercepts that the
United States later picked up. “The thinking was that the Iranians would blame bad parts,
or bad engineering, or just incompetence,” one of the architects of the early attack said.
The Iranians were confused partly because no two attacks were exactly alike. Moreover,
the code would lurk inside the plant for weeks, recording normal operations; when it
attacked, it sent signals to the Natanz control room indicating that everything downstairs
was operating normally. “This may have been the most brilliant part of the code,” one
American official said.
Later, word circulated through the International Atomic Energy Agency, the Viennabased nuclear watchdog, that the Iranians had grown so distrustful of their own

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

267

instruments that they had assigned people to sit in the plant and radio back what they
saw.
“The intent was that the failures should make them feel they were stupid, which is what
happened,” the participant in the attacks said. When a few centrifuges failed, the
Iranians would close down whole “stands” that linked 164 machines, looking for signs of
sabotage in all of them. “They overreacted,” one official said. “We soon discovered they
fired people.”
Imagery recovered by nuclear inspectors from cameras at Natanz — which the nuclear
agency uses to keep track of what happens between visits — showed the results. There
was some evidence of wreckage, but it was clear that the Iranians had also carted
away centrifuges that had previously appeared to be working well.
But by the time Mr. Bush left office, no wholesale destruction had been accomplished.
Meeting with Mr. Obama in the White House days before his inauguration, Mr. Bush urged
him to preserve two classified programs, Olympic Games and the drone program in
Pakistan. Mr. Obama took Mr. Bush’s advice.
The Stuxnet Surprise
Mr. Obama came to office with an interest in cyberissues, but he had discussed them
during the campaign mostly in terms of threats to personal privacy and the risks to
infrastructure like the electrical grid and the air traffic control system. He commissioned a
major study on how to improve America’s defenses and announced it with great fanfare
in the East Room.
What he did not say then was that he was also learning the arts of cyberwar. The
architects of Olympic Games would meet him in the Situation Room, often with what
they called the “horse blanket,” a giant foldout schematic diagram of Iran’s nuclear
production facilities. Mr. Obama authorized the attacks to continue, and every few
weeks — certainly after a major attack — he would get updates and authorize the next
step. Sometimes it was a strike riskier and bolder than what had been tried previously.
“From his first days in office, he was deep into every step in slowing the Iranian program
— the diplomacy, the sanctions, every major decision,” a senior administration official
said. “And it’s safe to say that whatever other activity might have been under way was
no exception to that rule.”
But the good luck did not last. In the summer of 2010, shortly after a new variant of the
worm had been sent into Natanz, it became clear that the worm, which was never
supposed to leave the Natanz machines, had broken free, like a zoo animal that found
the keys to the cage. It fell to Mr. Panetta and two other crucial players in Olympic
Games — General Cartwright, the vice chairman of the Joint Chiefs of Staff, and Michael
J. Morell, the deputy director of the C.I.A. — to break the news to Mr. Obama and Mr.
Biden.
An error in the code, they said, had led it to spread to an engineer’s computer when it
was hooked up to the centrifuges. When the engineer left Natanz and connected the
computer to the Internet, the American- and Israeli-made bug failed to recognize that its
environment had changed. It began replicating itself all around the world. Suddenly, the

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

268

code was exposed, though its intent would not be clear, at least to ordinary computer
users.
“We think there was a modification done by the Israelis,” one of the briefers told the
president, “and we don’t know if we were part of that activity.”
Mr. Obama, according to officials in the room, asked a series of questions, fearful that
the code could do damage outside the plant. The answers came back in hedged terms.
Mr. Biden fumed. “It’s got to be the Israelis,” he said. “They went too far.”
In fact, both the Israelis and the Americans had been aiming for a particular part of the
centrifuge plant, a critical area whose loss, they had concluded, would set the Iranians
back considerably. It is unclear who introduced the programming error.
The question facing Mr. Obama was whether the rest of Olympic Games was in
jeopardy, now that a variant of the bug was replicating itself “in the wild,” where
computer security experts can dissect it and figure out its purpose.
“I don’t think we have enough information,” Mr. Obama told the group that day,
according to the officials. But in the meantime, he ordered that the cyberattacks
continue. They were his best hope of disrupting the Iranian nuclear program unless
economic sanctions began to bite harder and reduced Iran’s oil revenues.
Within a week, another version of the bug brought down just under 1,000 centrifuges.
Olympic Games was still on.
A Weapon’s Uncertain Future
American cyberattacks are not limited to Iran, but the focus of attention, as one
administration official put it, “has been overwhelmingly on one country.” There is no
reason to believe that will remain the case for long. Some officials question why the same
techniques have not been used more aggressively against North Korea. Others see
chances to disrupt Chinese military plans, forces in Syria on the way to suppress the
uprising there, and Qaeda operations around the world. “We’ve considered a lot more
attacks than we have gone ahead with,” one former intelligence official said.
Mr. Obama has repeatedly told his aides that there are risks to using — and particularly
to overusing — the weapon. In fact, no country’s infrastructure is more dependent on
computer systems, and thus more vulnerable to attack, than that of the United States. It is
only a matter of time, most experts believe, before it becomes the target of the same
kind of weapon that the Americans have used, secretly, against Iran.

•
•
•

Be able to state the pros and cons of conducting this operation.
Does this story impact your views regarding whether the US government ever should
engage in such activities?
Do you think awareness of this operation meaningfully changed what other nations
are willing to do in the cyber domain?

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

269

E. Case study: Sandworm
The past decade has seen no small amount of grey zone cyber activity of the destructive sort.
Many of the most dramatic and damaging examples have been attributed to a group associated
with Russian military intelligence (aka G.R.U.) known dubbed “Sandworm” by security researchers
in light of the recurrence of Dune references in their code. Consider this October 2020 Wired
article from Andy Greenberg (whose terrific book Sandworm is an extraordinary tale of GRU’s
activities):
NEARLY HALF A decade ago, the Russian hackers known as Sandworm hit Western Ukraine
with the first-ever cyberattack to cause a blackout, an unprecedented act of cyberwar
that turned off the lights for a quarter million Ukrainians. They were just getting started. From
there Sandworm embarked on a years-long spree of wantonly destructive attacks:
another blackout attack on the Ukrainian capital of Kyiv in 2016, the release of the
NotPetya worm in 2017 that spread globally from Ukraine to cause $10 billion in damage,
and a cyberattack that temporarily destroyed the IT backend of the 2018 Winter
Olympics in South Korea, among others.
Yet in spite of crossing every red line the cybersecurity world has tried to draw to protect
civilian critical infrastructure from catastrophic hacking, Sandworm's members had never
been charged or even officially named in connection with those attacks. Until now.
On Monday, the Department of Justice unsealed charges including computer fraud and
conspiracy against six of the hackers who allegedly make up Sandworm, a group also
known in the security industry by the names Telebots, Voodoo Bear, and Hades,
and confirmed earlier this year to work in Unit 74455 of Russia's GRU military intelligence
agency based in a building known as the Tower in the Moscow suburb of Khimki. The
indictment names all six Russian men, who are in their late twenties to early thirties: Yuriy
Sergeyevich Andrienko, Sergey Vladimirovich Detistov, Pavel Valeryevich Frolov, Artem
Valeryevich Ochichenko, and Petr Nikolayevich Pliskin, as well as Anatoliy Sergeyevich
Kovalev, who was previously indicted two years ago for his allegedly role into hacking US
States' Boards of Election in 2016.
“No country has weaponized its cyber capabilities as maliciously or irresponsibly as Russia,
wantonly causing unprecedented damage to pursue small tactical advantages and to
satisfy fits of spite,” assistant attorney general John Demers said in a statement.
"They continue to do disruptive and destructive attacks against anyone they perceive to
be an adversary to Russia or to have slighted Russia in some way," added a senior Justice
Department official who asked not to be identified, in a call with WIRED. "This is probably
one of the most dangerous and aggressive groups of hackers that’s out there."
The charges represent not only the first criminal charges against Sandworm for its most
destructive attacks, but the first time that most of the charged hackers have been publicly
identified as members of the hacker group. Two other GRU hackers believed to be part of
Sandworm—Aleksey Aleksandrovich Potemkin and Aleksandr Vladimirovich Osadchuk—
were previously named in the separate, 2018 indictment of 12 GRU hackers for hacking

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

270

that interfered in the 2016 US election. Kovalev, who in the new indictment is accused of
helping to hack the 2017 campaign of French president Emmanuel Macron, was also
named in those 2018 charges.
The new indictment also represents the first official acknowledgement from the US
government that Sandworm was responsible for a cyberattack on the 2018 Winter
Olympics, in which a piece of malware known as Olympic Destroyer took down much of
the IT infrastructure of the Games just as the opening ceremony was beginning in
Pyeongchang, South Korea. Olympic Destroyer contained layers of "false flags," spoofed
clues in its code designed to trick investigators into blaming North Korea or China. And
according to the new indictment, Sandworm also tried to breach two Olympic partner
organizations responsible for timekeeping in the Olympics, not just the Wifi, Olympics app,
ticketing, and displays that were ultimately disrupted—perhaps an attempt to corrupt the
Olympics sporting events' actual results, too.
In the more than two years that followed, no government in the world officially seemed
willing to blame the cyberattack on Russia, even as private intelligence firms like FireEye
found strong evidence of Sandworm's involvement, and US intelligence leaked their
findings of Russia's culpability to The Washington Post. (The European Union did finally
name "Olympic Destroyer" as one of the known names for Sandworm in sanctions against
the group in July, but without explicitly saying that the sanctions were in response to the
Olympics attack.)
That long silence led to warnings from the cybersecurity community that Russia would no
doubt attempt to attack the 2020 Olympics in Tokyo, too. And separately from the
Sandworm indictment, those warnings were proven true today when the UK's National
Cybersecurity Center revealed that it had tracked, in a joint operation with US intelligence
agencies, reconnaissance activities by Russian hackers seeking to disrupt the 2020
Olympics as predicted—though the games were ultimately delayed due to Covid-19—
targeting the games' organizers, logistics partners, and sponsors.
The Justice Department's new indictment against the hackers includes a long history of
other GRU hacking around the world: The hackers allegedly targeted the Organization for
the Prohibition of Chemical Weapons in the Netherlands and the United Kingdom’s
Defense Science and Technology Laboratory while those two organizations were
investigating the Novichok poisoning of GRU defector Sergei Skripal and his daughter, an
attack not previously linked to Sandworm despite known GRU involvement. The indictment
also lays out new details of Sandworm's targeting of the nation of Georgia in 2019, which
included an attempt to compromise the Georgian parliament in addition to a previously
known campaign of web defacements across the country's internet, affecting 15,000 sites.
Perhaps most significantly, the criminal charges mark the first global law enforcement
response targeting Sandworm's hackers for their release of the NotPetya malware that
ravaged networks across the world. To initially install its data-destroying, self-spreading
code on its victims' machines, Sandworm hijacked the update mechanism of MEDoc, a
common piece of Ukrainian accounting software. But beyond infecting hundreds of
Ukrainian companies and government agencies, NotPetya also spread far beyond
Ukraine's borders, inflicting $10 billion in damage to companies including Merck, FedEx,

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

271

Maersk, Mondelez, as well as paralyzing updates to medical record systems in hospitals
across the US and causing serious collateral damage to Russian firms, too.
The indictment accuses Andrienko, Detistov, Frolov, and Pliskin specifically of developing
different components of the NotPetya malware. It goes so far as to state that Andrienko
and Pliskin "celebrated" after the malware was deployed.
Despite US and EU sanctions against Russia for NotPetya, no hackers were criminally
charged with the global cyberattack, or even named as individually responsible for it, until
now. That apparent inaction led many in the cybersecurity world to marvel for years at
Western governments' failure to hold Sandworm accountable. “NotPetya tested the red
lines of the West, and the result of the test was that there are no red lines yet,” Johns
Hopkins professor of strategic studies Thomas Rid told WIRED in 2018. “The lack of any
proper response is almost an invitation to escalate more.”
Now, however belatedly, that accountability has arrived for Sandworm's hackers. But as
with so many indictments of foreign, state-sponsored hackers, the defendants will likely
never see the inside of a US courtroom, given their protection by the Russian government.
Nonetheless, indictments against foreign hackers limit their ability to use the Western
financial system or to travel to any country that may have an extradition agreement with
the US. "We have an obligation to hold accountable those who commit crimes— no matter
where they reside and no matter for whom they work—in order to seek justice on behalf
of these victims," US attorney Scott W. Brady said in a statement.
The Sandworm indictment also sends a message to the GRU and others hackers engaged
in reckless attacks around the world that they, too, can be named and shamed, says John
Hultquist, director of intelligence at FireEye, who first named Sandworm in 2014 and has
tracked the hackers across their long, chaotic career. "It's obviously great that they're
finally being accused," Hultquist says.
A Justice Department official speaking to WIRED denied that the timing of the indictment
was related to the approach of Election Day in just two weeks. "We charge the cases when
they're ready to be charged," the official said.
But Hultquist notes that Sandworm was, in fact, involved in the 2016 election interference,
and that Microsoft has already linked another GRU group known as Fancy Bear or APT28
to attempts to breach campaigns and other political organizations involved in the 2020
election. "Plainly, I think they're attempting to discourage them from acting in this election
by using legal tools and outing their involvement in other incidents," Hultquist says of the
Justice Department's indictment.
Election aside, the signaling to state-sponsored hackers is clear, belated as it may be, says
Hultquist: "We know who you are and what you’ve done," he says. And the consequences
of that knowledge will catch up with hackers who cross red lines—even if it takes five years.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

•
•
•

272

Can you distinguish Sandworm’s activities from Stuxnet?
Recall the prior reading’s discussion of international law. Does it appear to you that
any of the activities described in these case studies cross an international law line?
The indictment described in the article brings us back to the early part of this course.
What if anything will this indictment accomplish?

F. The ransomware crisis and state responsibility
In 2021, a spate of high-impact ransomware episodes (most notably involving Colonial Pipeline)
generated a huge amount of public concern about Russia’s tolerance for ransomware crews
(that is, organized crime networks conducting or otherwise making possible ransomware attacks)
conducting ransomware attacks overseas from safe haven within Russia. Consider this account
from Ellen Nakashima and Eugene Scott of the Washington Post, from July 2021:
President Biden told Russian President Vladimir Putin on Friday that the United States will
take “any necessary action” to defend U.S. infrastructure, the White House said, after
Russia-based hackers carried out the largest known ransomware attack to date.
Biden has been under increasing pressure to counter such costly, brazen assaults —
pressure that spiked last weekend after the latest attack, which afflicted up to 1,500
companies, schools and hospitals around the world. It was claimed by a criminal group
called REvil operating largely out of Russia.
In a phone call, Biden warned Putin that Russia must take action to disrupt ransomware
groups operating there, or the United States would impose consequences, the president
said.
“I made it very clear to him that the United States expects when a ransomware operation
is coming from his soil, even though it’s not sponsored by the state, we expect them to act
if we give them enough information to act on who that is,” Biden said….
Asked if there would be consequences, Biden said, “yes.” The president did not elaborate.
… Biden’s call to Putin came after a meeting between the two leaders three weeks ago
in Geneva, during which Biden delivered a similar warning. It was the first time the two
spoke since and reflected the sense of urgency surrounding the surge in ransomware
attacks — something the Biden administration has elevated to a national security threat.
… Some national security experts say Putin has had enough time to curb the attacks. “It’s
time to take the gloves off,” said David Laufman, a former senior Justice Department
official who oversaw prosecution of state-sponsored cyber attacks. He said Biden should
impose consequences now, such as economic sanctions, export controls and lawenforcement actions, to disrupt criminals’ use of computer infrastructure.
According to the Kremlin’s readout of their call, Putin told Biden that Russia had expressed
willingness to cooperate on the issue, but that U.S. law enforcement agencies had not
approached Russian authorities about the recent cyberattacks.
A senior administration official disputed that. “We have relayed multiple specific requests
for action on cyber criminals” to Moscow, “and been clear about what Russia’s
responsibility is with regard to taking action, including again today,” said the official,
speaking on the condition of anonymity under ground rules set by the White House.

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

273

Russian security services are able to identify criminal hackers without U.S. help, say current
and former U.S. officials. Biden, on the call, expressed confidence in the Russian
government’s ability to do so, the people familiar with their exchange said.
Biden’s remarks inevitably raise expectations that the United States will take decisive
action to punish Moscow if the attacks do not abate quickly. Administration officials sought
to temper those expectations.
“This is a broad campaign and won’t have an immediate on-off effect like a light switch,’’
the senior administration official said, “but we’re going to have to stay on top of it over a
long period of time.”
The official alluded to Biden’s statement in Geneva that “we’ll find out within six months to
a year” whether the engagement with Russia is working.
“The president really meant what he said . . . when he said that our assessment of this
process, and our evaluation of Russia’s actions, would take time,” the official said.
The White House strategy extends beyond the bilateral talks. “This is really about our own
resilience as a nation in the face of these attacks,” the official said. “It’s about addressing
the challenges posed by cryptocurrency, which provides fuel for these sorts of
transactions. It’s about ensuring that our allies and our partners are working with us
collaboratively and upping their own game when it comes to resilience.”
Painter, the former State Department cyber official, said he, too, would not expect attacks
to cease overnight. But “we can now expect Putin to take action” and Biden’s remarks
have “set the stage for [imposing consequences on Russia] if they don’t.”
But, he warned, setting red lines and failing to act when they’re crossed is dangerous.
“If you don’t get the change of behavior you’re looking for and you don’t then take an
action, you look like a paper tiger,” he said. “It puts you in a weaker position.”

•
•

•

Given the Russian government’s toleration of this activity, should this situation be
viewed through the grey-zone competition lens?
Would it change your analysis if it were true that some Russian ransomware operators
were providing Russian intelligence agencies with access to data they capture in the
course of their crimes?
Would you handle the situation differently from the approach taken by the Biden
administration?

Electronic copy available at: https://ssrn.com/abstract=3547103

Chesney on Cybersecurity

274

Going deeper…
Congratulations, you’ve reached the end of the book! I’m grateful to you for reading it, and I
hope you feel your time and energy were well spent. Please do not hesitate to email me
(rchesney@law.utexas.edu) with any thoughts or suggestions you care to share; I’ll be happy to
hear from you. Meanwhile, if you want to stay engaged with this topic, I have some
recommendations for you.
First, two cybersecurity-focused podcasts:
The Cyberlaw Podcast - a weekly review of key legal developments relating to
cybersecurity, followed by in-depth interviews with a wide variety of guests.
Risky Business – a weekly review of important news from the technology side of
cybersecurity, also followed by in-depth interviews with a variety of guests
Second, two projects of mine that sometimes touch on cybersecurity issues:
The National Security Law Podcast – Each week, my UT colleague Steve Vladeck and I
review, discuss, and debate the latest national security law developments (always with a
healthy dose of frivolity; the show is not for those who prefer their national security law
discussions to be dry and serious at all times).
Lawfare – Lawfare is the nation’s leading source of online analysis of current national
security legal issues. Co-founded by Ben Wittes, Jack Goldsmith, and me, Lawfare covers
an array of topics including those associated with cyber domain activities.

The end.

Electronic copy available at: https://ssrn.com/abstract=3547103