PERSPECTIVES
Editor: Sean Peisert, sppeisert@lbl.gov

Perspectives on the
SolarWinds Incident
Sean Peisert | Lawrence Berkeley National Laboratory and University of California, Davis
Bruce Schneier | Harvard University
Hamed Okhravi | MIT Lincoln Laboratory
Fabio Massacci | University of Trento and Vrije Universiteit Amsterdam
Terry Benzel | USC Information Sciences InstituteCarl Landwehr | University of Michigan
Mohammad Mannan | Concordia University
Jelena Mirkovic | University of Southern California Information Sciences Institute
Atul Prakash | University of Michigan
James Bret Michael | Naval Postgraduate School

Editor’s Note
A significant cybersecurity event has recently been discovered in which malicious actors gained access to thesource code for the Orion monitoring and management software made by the company SolarWinds and inserted
malware into that source code. This article contains brief perspectives from a few members of the IEEE Security &Privacy editorial board regarding that incident.

A

serious cybersecurity event
was recently revealed: malicious actors had gained access tothe source code for the SolarWinds
Orion monitoring and management software. They inserted malware into that source code so that,when the software was distributed
to and deployed by SolarWinds
customers as part of an update, themalicious software could be used
to surveil customers who unknowingly installed the malware andDigital Object Identifier 10.1109/MSEC.2021.3051235
Date of current version: 15 March 2021

1540-7993/21©2021IEEE

gain potentially arbitrary control over the systems managed byOrion. Of course, such a level ofcontrol has given attackers opportunities for further exploitation
as well.
At the time of this writing, it isreported by SolarWinds that the
update containing the malware wasinstalled by thousands of customers, including numerous U.S. federal agencies and businesses aroundthe world. The cybersecurity company FireEye was among the firstreported to be actually compromised by the malware.

Numerous technical details on
this incident appear online and ina variety of other publications aswell as from SolarWinds itself.1
At the same time, there remains
a great deal to say about how wemight best respond to and recoverfrom the incident as well as how wemight avoid similar such events inthe future.
The news of this event broke ata time that made it infeasible forIEEE Security & Privacy to write afull, detailed piece by the production deadline for this issue. However, due to the magnitude of the

Copublished by the IEEE Computer and Reliability Societies

March/April 2021

7

PERSPECTIVES

incident, the Editorial Board stillwanted to address it in some way
without waiting two months forthe next issue. Therefore, this issue
contains two pieces related to the
SolarWinds incident: This firstarticle contains brief perspectives
from some members of the IEEE
Security & Privacy Editorial Board,
including numerous questions
asked by Editorial Board members
and also some suggested solutions.
The second is a companion “Point–
Counterpoint” column article by
Fabio Massacci and Trent Jaeger
that digs specifically into the quandaries and questions of software
patching that relate to the SolarWinds incident. Additional details
will undoubtedly continue to surface, and IEEE Security & Privacy
expects to cover this occurrence further and in greater detail in futureissues as we continue to learn about
this compromise and its effects.
— Sean Peisert

Editorial Board Members’
Perspectives
SolarWinds and Market
Incentives
Bruce SchneierT

he penetration of governmentand corporate networks worldwide is the result of inadequatecyberdefenses across the board.
The lessons are many, but I want tofocus on one important one we’ve
learned: the software that’s managing our critical networks isn’t
secure, and that’s because the market doesn’t reward that security.
SolarWinds is a perfect example.
The company was the initial infection
vector for much of the operation. Its
trusted position inside so many critical
networks made it a perfect target fora supply-chain attack, and its shoddy
security practices made it an easy target.
Why did SolarWinds have suchbad security? The answer is because
it was more profitable. The company

8IEEE Security & Privacy

is owned by Thoma Bravo partners, a private-equity firm known
for radical cost-cutting in the nameof short-term profit. Under CEO
Kevin Thompson, the company
underspent on security even as it
outsourced software development.
The New York Times reports that thecompany’s cybersecurity advisor
quit after his “basic recommendations were ignored.” In a very real
sense, SolarWinds profited because
it secretly shifted a whole bunch ofrisk to its customers: the U.S. government, IT companies, and others.
This problem isn’t new, and, whileit’s exacerbated by the private-equity
funding model, it’s not unique toit. In general, the market doesn’t
reward safety and security—especially when the effects of ignoring those things are long termand diffuse. The market rewards
short-term profits at the expenseof safety and security. (Watch andsee whether SolarWinds suffers any
long-term effects from this hack, orwhether Thoma Bravo’s bet that it
could profit by selling an insecure
product was a good one.)The solution here is twofold.
The first is to improve government
software procurement. Software
is now critical to national security.
Any system of procuring that software needs to evaluate the securityof the software and the security
practices of the company, in detail,to ensure that they are sufficient tomeet the security needs of the network they’re being installed in. If
these evaluations are made public,
along with the list of companies
that meet them, all network buyers
can benefit from them. It’s a win foreverybody.
But that isn’t enough; we need asecond part. The only way to force
companies to provide safety and security features for customers is throughregulation. This is true whether wewant seatbelts in our cars, basic foodsafety at our restaurants, pajamas that
don’t catch on fire, or home routersthat aren’t vulnerable to cyberattack.
The government needs to set minimum security standards for software
that’s used in critical network applications, just as it sets software standards
for avionics.
Without these two measures,it’s just too easy for companies toact like SolarWinds: save money byskimping on safety and security andhope for the best in the long term.
That’s the rational thing for companies to do in an unregulated market,
and the only way to change that is
to change the economic incentives.
Hamed Okhravi

The SolarWinds hacks are notnovel or unique. Software Trojans and supply-chain attacks havebeen understood in the community
for many decades; as a case in point,even the logo of the IEEE Symposium on Security and Privacy, oneof the top-tier venues in computer
security, is a Trojan horse! However,the SolarWinds hack highlights someof the troubling trends and important lessons that we, as a community,
should pay attention to and work on
resolving with better technologies aswell as policies.
First, for decades, one of themain paradigms in security has been“additive” security. We “add” tools,
antiviruses, intrusion detection/
prevention systems, ­m onitoringand management tools, and soon to make a system more secure.
Every new tool, while it might
reduce parts of the attack surface,also adds a new attack surface: vulnerabilities in the tool itself becomea new possible vector of compromise for the system. Numerous
recent vulnerabilities discovered insecurity software further highlight
this tradeoff.2
This is not an easy problem toresolve. While some security software programs close many moreholes than they open, others, by
the virtue of their sheer size andcomplexity, can make the system
March/April 2021

more vulnerable. We, as a community, do not have a proper,
quantitative understanding of thistradeoff, and, thus, decisions for
deploying or not deploying a newtool are made without proper
understanding of their implications. This also highlights the needfor another paradigm that requires
more attention in the community:“reductive” security, or making asystem more secure by removing its
unnecessary services, libraries, features, and so on, thereby shrinking
its attack surface.
Second, software supply-chain
attacks are as important—if not
more important—than hardware
supply-chain attacks. Because of
the vast complexity of modern
software and the comparatively
low cost of introducing malicious
logic into the code, this threat vector can be expected to become
more prominent over the next few
years. The traditional security
mechanisms that are developed toward off malicious “outside” code,such as code signing, digital certificates, secure update delivery mechanisms, transport security, and soon, have little impact on this threat
vector, as evidenced by the SolarWinds hack. Deeper analysis techniques, code provenance tracking,and liability mechanisms as well
as novel technologies and refinedpolicies are necessary to mitigate
such attacks.
Finally, cobbling together software code and libraries from various
and sometimes unknown sources may
be a good way of developing tools
quickly and cheaply; it is certainly
not an effective way to develop tools
securely. Large software projects
often incorporate code and libraries
from many sources3 with unknown
provenance. At best, these code
pieces can be buggy or faulty, and, atworst, they can contain malicious,
implanted logic. Rapid and secure
software development remains as
tantalizing a goal as ever.
www.computer.org/security

Fabio Massacci

S

olarWinds offers network anddatabase monitoring and logging services. SolarWinds, like allmodern IT suppliers, grew out ofmergers and acquisitions. A simple investigation on the company’s
FAQ page1 shows that the “vulnerable platform” is, in reality, a patchwork of services: 18 (sub)products
are, indeed, affected by the vulnerabilities (from Access Management,
to Web Performance Monitor, to
Log Analyzer—which was recently
acquired); another 40+ (sub)products are not affected.
So, for example, Log Analyzer
is affected, while Kiwi Log Analyzer, Log & Event Manager, Log
and Event Manager Workstation
Edition, and Loggly are not. The
Database Performance Analyzer
Integration Module is affected, but
the Database Performance Analyzer
is not—or, more precisely, “we donot believe is affected.”1
You have no chance as an end
administrator to know what you are
getting onto your systems. Figure 1
illustrates the stark reality for modern administrators.
Of course, as all system-monitor­­ing
tools, SolarWinds systems are properly
integrated with various mechanismsof authentication (such as Microsoft(a)

Active Directories), possibly withsingle sign-on (SSO) (which is agood security practice, isn’t it? But
I will return to that) at the finaluser sites. If one of these system
tools from the patchwork is compromised, the end user administrators are likely compromised. This isindeed quite clear from the instructions in the Emergency Act 21-01.4
What lessons do we learn fromthis story?
■■ This is not about third-party software; it is about fourth- or eighthor 16th-party software. We don’tknow what we are installing, andeven the people who sell it to us
have no clear idea.
■■ All security procedures are design­­ed for first-party software. ( Just
think about threat analysis and
STRIDE, or quality gates, and soon.) We can claim that suppliers
should stick to security procedures and so forth, but are we willing to pay the price? If nobody isliable for anything. . . .
■■ Several security mechanisms (likeSSO) that we conceived to be usedwith first-party products (which
are secured as first-party products)
can be damning in the new worldorder, as you SSO into something
you have no idea about.

(b)

Figure 1. (a) How we think the world is with good security gates and processes.
(b) How the world really is. In the framework of a week, SolarWinds fetched avulnerability (SUNBURST) to find out that another one was there (SUPERNOVA).
(Source: Anna Formilan for the European Union AssureMOSS project. Used
with permission.)
9

PERSPECTIVES

Terry BenzelThere has been a lot of important technical discussion todate, but I would also like to seesome conversation about what thethreat is, what the motivations arefor exploiting the vulnerabilities,
and how those fit into the larger
social–political landscape. Given
the extent of access gained, what is it
being used for? Is it “simply” exporting data and information? Are theaccesses being used to change theinformation/platforms/integrity ofdata and processes?
The wide variety of organizations
that have been attacked makes it difficult to attribute a single motivation.
How do we close all of the doors thathave been opened and understandwhat was done during the long timethat access was available?
Finally, we should note that this is
not unique and not specific to adversaries. This is just a highly visible
move in a grand game that has beenongoing for a very long time. Understandably, digging very deeply in thisarea will quickly become sensitive,
but I do think that we owe the readers a bit of discussion about the bigger picture.
Carl LandwehrWe all accept digitally signed
software updates. SolarWinds evidently distributed validly signed updates that included
malware, so customers who trusted
them and installed the sabotaged
updates became vulnerable. Perhaps
the first time this kind of attack was
written about was in Ken Thompson’s Turing Award lecture “Reflections Trusting Trust” in 1984. Whatcan be done about this problem
from a technical standpoint? One
possibility might be to develop
tools that would help consumers
of updates assess their security
more deeply than merely checking that a digital signature is valid.
The signature provides provenanceassurance and nothing more, and if

10IEEE Security & Privacy

the signing key has been compromised, even that is lost.
What if the consumer could
run checks on the signed update tocheck it for vulnerabilities? This is
the approach taken by the Securely
Taking on New Executable Softwareof Uncertain Provenance (STONESOUP) program at Intelligence
Advanced Research Projects Activity in 2009. Of course, this approach
will never ensure there are no vulnerabilities, but it could raise the bar
substantially. Considerable technology has been developed by STONESOUP and subsequent programs,
including DARPA’s Cyber Grand
Challenge, that demonstrates theability to perform significant automated analyses on both source codeand binaries to expose potential vulnerabilities (and, in some cases, evento remove them). This technology iscommercially available.
Even better would be to put the
responsibility on developers, who
are in the best position to apply serious effort to ensuring that their
updates don’t contain malware. Why
not establish best practices for the
release of updates and make thosedevelopers who can’t show they followed these practices liable for themalware they distribute? If we want
to improve the resilience of our software systems, why don’t we start byestablishing liability for companies
who distribute sabotaged updates?
Nation-state attackers may still penetrate defenses, and relief from liability
should be available to companies thatcan show they followed the best practices. Establishing liability requires
policy action, but perhaps the severityof the Solar Winds compromise canprovide sufficient political will to help
the software industry begin to assume
responsibility for its products.
Mohammad MannanSecurity products, like other software applications, come withnumerous vulnerabilities and design
flaws, and are exploited in cyberattacks every now and then. As of January 26, 2021, a quick search at cve.
mitre.org on SolarWinds/McAfee/
Symantec returns hundreds ofCommon Vulnerabilities and Exposures (CVE) entries. SolarWinds ismaking the headline now, but will
possibly be forgotten sometimesoon (recall the RSA hack from2011). I would argue that security
products should be a distinct software category—perhaps be made tofollow some standards. Other software categories provide direct anduseful functionalities. In contrast,
security products don’t enable any
new functionality—designed only
to secure other systems and applications, and as such, must not create
new security nightmares.
Some suggestions along this line
seem apropos:■■ Security products should do noharm. They should be designedwith failure in mind—i.e., theymust fail gracefully, without
reducing the security level of theprotected system compared tothe original state (without the
product itself). This will requirethem to work with less privilege.
To some extent, these products
should be treated like medicine/
vaccine—the bottom line should
be to avoid any harm.
■■ The operating system (OS) itself
should take over more responsibilities gradually for tasks requiring system-level access. (The OS
is the necessary evil that we needto keep secure anyway.)■■ Security products need to accept
liabilities if they downgrade thetarget system’s security in any
way—this can force them tobecome a security company (i.e.,
adopt the best security practices,
including in development/deployment/management phases) as
opposed to yet another software
company that happens to makesecurity products Instead ofrequiring an abuse to happen to
March/April 2021

trigger penalties, another avenue
could be to incur a certain amountof fine for each new CVE, andafter a certain threshold, the product or company may lose their“security” label.
Of course, these suggestions
here are incomplete and need more
serious consideration. However,
if no concrete measures are taken
soon, we should not be surprised
when (not if) the next SolarWinds
like incident happens.

somehow. In this specific case, newInternet destinations were contacted by compromised machines,
and data were exfiltrated. This could
potentially be detected, althoughcommand and control servers were
hosted on public clouds (Microsoft
and Amazon), which may not havelooked suspicious. Therefore, thethird weak link is our reliance on
clouds and allowing organizations
with high confidentiality requirements to communicate with public clouds.

Jelena Mirkovic

Atul PrakashIt is important to note that this wasa well-planned, well-executed
attack. For example, the changes incode were done at the source codelevel over months and possibly byan insider.5 The changes were subtle, using coding styles and naming conventions that were alreadyin the code. From that point on,
the code was tested, signed, andreleased through the SolarWinds
platform. After infection, the code
was dormant for two weeks. After
that, it mimicked another known
protocol to exfiltrate credentials.
These credentials were used toaccess Security Assertion Markup
Language token authority and craft
new tokens. These tokens were thenused to access confidential data.
In my opinion, there were two
weak links that the attack exploited:
insiders in the companies producing
software/hardware and installingmonitoring software that precedes
encryption (otherwise, credentials
could not be stolen). The first is
impossible to eliminate. The second—perhaps, but there will always
be tension between the desire tomonitor everything and protecting
privacy (in this case, the privacy ofcredentials that were later used tocompromise the security of data).
I think the better question is
how one could detect when suchhigh-level compromises occur. Oncestolen, data have to be exfiltrated
www.computer.org/security

T

he issues surrounding theSolarWinds incident raise
important questions. First and foremost, this is clearly a supply-chain
attack. I think that a number of myquestions are around potential privileges, both in this incident specifically and in software supply chains
more generally. In this incident, werethe compromised SolarWinds servers more overprivileged than necessary to function properly? Toward
answering this, what capability did
SolarWinds provide, and how is
it typically deployed? Why did its
compromise then lead to the compromise of internal email accounts,
even assuming that the SolarWinds
server was fully compromised andgave root access? Does the server
act as a man in the middle, or is it
also installed at end servers, suchas mail or authentication servers?
If it is a man in the middle, why did
end-to-end authentication fail toprotect mail accounts? How manyother such third-party services that
could allow deeper compromise ofother services are out there?
James Bret MichaelDamage assessment will likely
take months to accomplish,
given the reach of SolarWinds(i.e., the number of customers and,through transitivity, other parties
affected) and the large number oforganizations (e.g., the U.S. Federal

Bureau of Investigation, the UnitedStates Cyber Command, and security firms) involved in the investigations of SolarWinds.
Cyber hygiene still seems to be astumbling block to thwarting the successful use of low-hanging exploitable vulnerabilities. Of the 300,000
customers (granted, not all use theOrion software or were still licensed
to do so), a relatively small numberof customers actually uploaded the
updates. Preventing another SolarWinds debacle is a technical (e.g.,
eliminating unnecessary systemcomplexity to make it feasible toassess the trustworthiness of the software/firmware updates and the organizations providing those updates)
and human problem (e.g., getting
the bureaucracies in organizations toaddress supply-chain issues).
There doesn’t seem like there
is much we can do to solve thesupply-chain problems. Software, hardware, and co-design are global. Lots ofsystems and apps comprise components sourced from multiple suppliers. Governments do not control the
supply chain, just as they do not control innovation or how products andservices are used. Governments havebeen somewhat ineffectual in handling
supply-chain issues. They complain
a lot but don’t seem to have workable
solutions or good leadership in the
supply-chain arena.
SolarWinds appears to have
involved one or more insiders andexternal actors, making it challenging
to perform a full damage assessmentand nearly impossible to detect adulterated software components. Like I
commented before, I don’t see anything new here in SolarWinds. It is justthat a lot of people are embarrassed(including top cybersecurity firms),
and the media is having a field day.
Why weren’t the more sophisticatedusers of the software monitoring theirown systems more closely?
It will be interesting to see theforthcoming attempts to apply
artificial intelligence to detect the11

PERSPECTIVES

types of reconnaissance, commandand control, and other aspects ofpenetration that were employed bySolarWinds. However, the first stepshould be to use a bit of common
sense to think through the problem
before trying to apply AI.
SolarWinds takes advantage ofvulnerabilities in widely used platforms (.net) and protocols (e.g.,
Domain Name System). Can they
be fixed? What does it take to getthem fixed or replaced?
Initial findings indicate that adv­
anced tactics, techniques, and procedures (TTPs) were employed bySolarWinds. The c yberdefense
teams are always trying to catch up
with the latest TTPs and new implementations of well-known TTPs
used by the attackers. Addressing
TTPs requires better communications between the offensive anddefensive sides of the house.
Overreaction by governments to
SolarWinds could have a profoundly
negative effect on global innovation.
Then again, governments are not in
the driver’s seat here. The private sector
will continue to innovate.
The way forward may be to take afundamentally new approach to security in the near- (e.g., cloud hypervisors
pushing security rather than individual
customers patching—or not), mid(e.g., zero-trust, or something like it),and long-term (e.g., quantum-based
approaches). The other part of theequation that needs to be addressedis motivation—getting the market toinclude security as a requirement.
Disclaimer
The views and conclusions contained
herein are those of the authors andshould not be interpreted as necessarily representing the official policies
or endorsements, either expressed or
implied, of the authors’ employers.
References
1. “SolarWinds Security Advisory.” SolarWinds. https://www.solarwinds.com/

12

IEEE Security & Privacy

securityadvisory (accessed Dec. 24,
2020).
2. “How to compromise the enterprise
endpoint.” Google Project Zero.
June 28, 2016. https://googleprojectzero.blogspot.com/2016/06/
how-to-compromise-enterprise-endpoint.html (accessed Jan. 8, 2021).
3. A. Nappa, R . Johnson, L. Bilge,
J. Caballero, and T. Dumitras,“The attack of the clones: A studyof the impact of shared code on vulnerability patching,” in Proc. 2015
IEEE Symp. Security Privacy, pp.
692–708. doi: 10.1109/SP.2015.48.
4. “Emergency directive 21-01.” Cybersecurity and Infrastructure Security Agency, U.S. Department ofHomeland Security. Dec. 13, 2020.
https://cyber.dhs.gov/ed/21-01(accessed Dec. 13, 2020).
5. T. Pericin. “SunBurst: The next levelof stealth.” Dec. 16, 2020. https://blog.reversinglabs.com/blog/
sunburst-the-next-level-of-stealth(accessed Jan. 8, 2021).
Sean Peisert leads computer security

R&D at Lawrence Berkeley Natio­
nal Laboratory, Berkeley, California,
94720, USA, and is an adjunct associate professor at the University of California, Davis (UC), Davis, California,
95616, USA. He is the editor in chiefof IEEE Security & Privacy. Peisert
received a Ph.D. in computer sciencefrom UC San Diego. He is a Senior
Member of IEEE and the Association of Computing Machinery. Contact him at sppeisert@lbl.gov.

Bruce Schneier is a security technolo-

gist, fellow, and lecturer at the Harvard Kennedy School, Cambridge,
Massachusetts, 02138, USA, andthe chief of security architectureof Inrupt, Inc. Boston, Massachusetts, 02210, USA. He blogs at
www.schneier.com. Contact him
at schneier@schneier.com.

Hamed Okhravi is a senior staff

member at the Massachusetts

Institute of Technology (MIT)
Lincoln Laboratory, Lexington,
Massachusetts, 02421, USA .
Okharavi received a Ph.D. in electrical and computer engineeringfrom the University of Illinois at
Urbana-Champaign. He is also
the recipient of two R&D 100
Awards, MIT Lincoln Laboratory’s Best Invention and Early
Career Technical Achievement
Awards, and NSA’s Best Scientific
Cybersecurity Paper Award. He isa Member of IEEE. Contact him
at hamed.okhravi@ll.mit.edu.
Fabio Massacci is a professor at

the University of Trento, Trento,
38123, Italy, and Vrije Universiteit, Amsterdam, 1081 HV, The
Netherlands. Massacci received aPh.D. in computing from the University of Rome “La Sapienza.”
He received the IEEE Requirements Engineering Conference
Ten Year Most Influential Paper
Award on security in sociotechnical systems. He participates in
the FIRST special interest groupon the Common Vulnerability
Scoring System and the European
pilot CyberSec4Europe on thegovernance of cybersecurity. He
coordinates the European AssureMOSS project. Contact him at
fabio.massacci@ieee.org.

Terry Benzel is the director of net-

working and cybersecurity re­­search at the Information Sciences
Institute of the University ofSouthern California, Los Angeles,
California, 90292, USA. Benzel
received an M.A. from Boston University and an executive M.B.A.
from the University of California,
Los Angeles. She is a senior member of the IEEE Computer Society,an associate editor in chief of IEEE
Security & Privacy, and a memberof the Board of Governors of theIEEE Computer Society. Contact
her at tbenzel@isi.edu.

March/April 2021

Carl Landwehr is a visiting profes-

sor at the University of Michigan,
USA, where he received a Ph.D.
He is an IEEE Fellow, a member of the inaugural class of the
National Cyber Security Hall ofFame, and served as editor in chiefof IEEE Security & Privacy for four
years. He is a member of the boardof the Center for Democracy
and Technology. Contact him atceland@umich.edu.

a Ph.D. in computer science inthe area of Internet authentication and usable security from
Carleton University. Contact him
at m.mannan@concordia.ca.
Jelena Mirkovic is a project leader

at the Information Sciences
Institute of the University ofSouthern California, Los Angeles, California, 90292, USA .
Mirkovic received a Ph.D. incomputer science from the University of California, Los Angeles. Contact her at mirkovic@
isi.edu.

Mohammad Mannan is an associ-ate professor at the Concordia
Institute for Information Systems Engineering, Concordia University, Montreal, Quebec, H3G
1M8, Canada. Mannan received

Atul Prakash is a professor of com-puter science at the University ofMichigan, Ann Arbor, Michigan,
48109, USA. Prakash received aPh.D. in computer science fromthe University of California, Berkeley. Contact him at aprakash@umich.edu.
James Bret Michael is a professor

in the Departments of Computer Science and Electrical andComputer Engineering, Naval
Postgraduate School, Monterey,
California, 93943, USA. Michael
received a Ph.D. from George
Mason University. He is an associate editor in chief of Computerand IEEE Security & Privacy.
Contact him at bmichael@nps.edu.

MAY 23–26, 2021 • ONLINE

42nd IEEE Symposium
on Security and Privacy
REGISTRATION IS NOW OPEN
S&P 2021—Since 1980, the IEEE Symposium on Security
and Privacy has been the premier forum for presenting
developments in computer security and electronic
privacy, and for bringing together researchers andpractitioners in the field. The 2021 Symposium will markthe 42nd annual meeting of this flagship conference.
This year’s program committee has selected over 100
outstanding research papers covering a wide range of
topics.
For more information, visit:https://www.ieee-security.org/TC/SP2021
Sponsored by the IEEE Computer Society
Technical Committee on Security andPrivacy in cooperation with the International
Association for Cryptologic Research

AFFILIATED EVENTSMay 27: Conference workshops• WMTC: Workshop on Traffic
Measurements for Cybersecurity• ConPro: Workshop on Consumer
Protection• DLS: Deep Learning and Security
Workshop• LangSec: Workshop on LanguageTheoretic Security and Applications• SafeThings: Workshop on theInternet of Safe Things• SADFE: Workshop on Systemic
Approaches to Digital Forensic
Engineering• WOOT: Workshop on Offensive
Technologies

Digital Object Identifier 10.1109/MSEC.2021.3060556

www.computer.org/security13