27,99 €
Mehr erfahren.
- Herausgeber: John Wiley & Sons
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Englisch
Move beyond the checklist and fully protect yourself from third-party cybersecurity risk
Over the last decade, there have been hundreds of big-name organizations in every sector that have experienced a public breach due to a vendor. While the media tends to focus on high-profile breaches like those that hit Target in 2013 and Equifax in 2017, 2020 has ushered in a huge wave of cybersecurity attacks, a near 800% increase in cyberattack activity as millions of workers shifted to working remotely in the wake of a global pandemic.
The 2020 SolarWinds supply-chain attack illustrates that lasting impact of this dramatic increase in cyberattacks. Using a technique known as Advanced Persistent Threat (APT), a sophisticated hacker leveraged APT to steal information from multiple organizations from Microsoft to the Department of Homeland Security not by attacking targets directly, but by attacking a trusted partner or vendor. In addition to exposing third-party risk vulnerabilities for other hackers to exploit, the damage from this one attack alone will continue for years, and there are no signs that cyber breaches are slowing.
Cybersecurity and Third-Party Risk delivers proven, active, and predictive risk reduction strategies and tactics designed to keep you and your organization safe. Cybersecurity and IT expert and author Gregory Rasner shows you how to transform third-party risk from an exercise in checklist completion to a proactive and effective process of risk mitigation.
- Understand the basics of third-party risk management
- Conduct due diligence on third parties connected to your network
- Keep your data and sensitive information current and reliable
- Incorporate third-party data requirements for offshoring, fourth-party hosting, and data security arrangements into your vendor contracts
- Learn valuable lessons from devasting breaches suffered by other companies like Home Depot, GM, and Equifax
The time to talk cybersecurity with your data partners is now.
Cybersecurity and Third-Party Risk is a must-read resource for business leaders and security professionals looking for a practical roadmap to avoiding the massive reputational and financial losses that come with third-party security breaches.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 596
Veröffentlichungsjahr: 2021
Ähnliche
Table of Contents
Cover
Title Page
Introduction
Who Will Benefit Most from This Book
Special Features
Chapter 1: What Is the Risk?
The SolarWinds Supply‐Chain Attack
The VGCA Supply‐Chain Attack
The Zyxel Backdoor Attack
Other Supply‐Chain Attacks
Problem Scope
Compliance Does Not Equal Security
Third‐Party Breach Examples
Conclusion
Chapter 2: Cybersecurity Basics
Cybersecurity Basics for Third‐Party Risk
Cybersecurity Frameworks
Due Care and Due Diligence
Cybercrime and Cybersecurity
Conclusion
Chapter 3: What the COVID‐19 Pandemic Did to Cybersecurity and Third‐Party Risk
The Pandemic Shutdown
SolarWinds Attack Update
Conclusion
Chapter 4: Third‐Party Risk Management
Third‐Party Risk Management Frameworks
The Cybersecurity and Third‐Party Risk Program Management
Kristina Conglomerate (KC) Enterprises
Conclusion
Chapter 5: Onboarding Due Diligence
Intake
Cybersecurity Third‐Party Intake
Conclusion
Chapter 6: Ongoing Due Diligence
Low‐Risk Vendor Ongoing Due Diligence
Moderate‐Risk Vendor Ongoing Due Diligence
High‐Risk Vendor Ongoing Due Diligence
“Too Big to Care”
A Note on Phishing
Intake and Ongoing Cybersecurity Personnel
Ransomware: A History and Future
Conclusion
Chapter 7: On‐site Due Diligence
On‐site Security Assessment
On‐site Due Diligence and the Intake Process
Conclusion
Chapter 8: Continuous Monitoring
What Is Continuous Monitoring?
Enhanced Continuous Monitoring
Third‐Party Breaches and the Incident Process
Conclusion
Chapter 9: Offboarding
Access to Systems, Data, and Facilities
Conclusion
Chapter 10: Securing the Cloud
Why Is the Cloud So Risky?
Conclusion
Chapter 11: Cybersecurity and Legal Protections
Legal Terms and Protections
Cybersecurity Terms and Conditions
Conclusion
Chapter 12: Software Due Diligence
The Secure Software Development Lifecycle
On‐Premises Software
Cloud Software
Open Web Application Security Project Explained
Open Source Software
Mobile Software
Conclusion
Chapter 13: Network Due Diligence
Third‐Party Connections
Zero Trust for Third Parties
Conclusion
Chapter 14: Offshore Third‐Party Cybersecurity Risk
Onboarding Offshore Vendors
Country Risk
KC's Country Risk
Conclusion
Chapter 15: Transform to Predictive
The Data
Level Set
A Mature to Predictive Approach
The Predictive Approach at KC Enterprises
Conclusion
Chapter 16: Conclusion
Index
Copyright
Dedication
(ISC)
2®
About the Author
About the Technical Editor
Acknowledgments
Foreword
End User License Agreement
List of Tables
Chapter 12
TABLE 11.1 CVE/CVSS SCORES
List of Illustrations
Chapter 2
FIGURE 2.1 The CIA Triad
FIGURE 2.2 The NIST Cybersecurity Framework
FIGURE 2.3 The Five Steps to a Breach
Chapter 4
FIGURE 4.1 The Four Pillars of ICT SCRM
FIGURE 4.2 The Calculation Flow
FIGURE 4.3 The Four Lines of Defense Model
Chapter 5
FIGURE 5.1 The Cyber TPR Lifecycle
FIGURE 5.2 The RFP to IRQ to Intake Process
FIGURE 5.3 Masking or De‐Identifying Tests in Lower‐Level Environments
Chapter 7
FIGURE 7.1 The On‐site Assessment Lifecycle
Chapter 8
FIGURE 8.1 The Continuous Monitoring Process
Chapter 10
FIGURE 10.1 SaaS, PaaS, and IaaS Stacks
FIGURE 10.2 The Shared Responsibility Model
Chapter 13
FIGURE 13.1 The Vendor Connection Lifecycle
FIGURE 13.2 Vendor Enclaves in ZT for Third Parties
FIGURE 13.3 An SDP Gateway
FIGURE 13.4 The TPM Process
Chapter 15
FIGURE 15.1 The Data Funnel to Reporting
FIGURE 15.2 Red, Yellow, and Green Vendors
Guide
Cover Page
Table of Contents
Begin Reading
Pages
i
xviii
xix
xx
xxi
xxii
1
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
75
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
107
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
185
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
211
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
239
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
315
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
365
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
393
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
411
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
ii
iii
iv
v
vi
vii
xvi
xvii
459
Cybersecurity and Third‐Party Risk
Third Party Threat Hunting
Gregory C. Rasner
Introduction
Third‐party risk (or supply‐chain security) are not new disciplines, and there have been frameworks, regulatory directives, professional certifications, and organizations that all attest to its maturity. Cybersecurity could be considered more mature, since it has been around in some form since computing came of age in the 1970s. Nowadays, it's even more complex in terms of frameworks, disciplines, certifications, regulatory guidance and directives, and avenues of study. Why do the surveys, time after time, indicate that well over 50 percent of organizations do not perform any type of Third‐Party Risk Management (TPRM), and even fewer have anything other than an ad hoc cybersecurity due diligence program for vendors? Reasons for this lack of attention and collaboration can be found in hundreds, if not thousands, of breaches and security incidents that were the result of poor third‐party oversight and a lack of any due diligence and due care for the vendors' cybersecurity.
This book is designed to provide a detailed look into the problems and risks, then give specific examples of how to create a robust and active Cybersecurity Third‐Party Risk Management program. It begins by covering the basics of the due diligence processes and the vendor lifecycle, with models and illustrations on how to create these basic but necessary steps. Then it goes more in depth about the next parts in the creation of a mature program: cyber legal language, offshore vendors, connectivity security, software security, and use of a predictive reporting dashboard.
The book is designed to not only help you build a program, but to take an existing program from one of compliance checkbox work to an active threat‐hunting practice. Many programs that do currently exist are designed and run as an obligation to “check a box” for a regulator or an internal auditor. Yet, no one has ever secured their network or data by doing only what the regulators told them to do. Security is an ongoing activity that requires its application in third‐party risk to be equally active and ongoing. Its activities and results should emulate a cyber operations or threat operations team that focuses its efforts on reducing cybersecurity threats externally at the suppliers. Get away from checking boxes and filling out remote questionnaires and take a risk‐based approach that engages your highest risk and/or most critical third parties in conversations to build trust and collaboration to lower risk for both your organization and the vendor.
Who Will Benefit Most from This Book
A superset of cybersecurity, third‐party risk, and executive leadership will benefit the most from reading this book. On the cybersecurity side, analysts to senior leadership will be able to take their information security knowledge and experience to perform the hands‐on work and management of third‐party risk, while third‐party risk professionals will better understand and appreciate the need to include a more robust cybersecurity risk domain. Executive and senior leadership in business who are not focused on cybersecurity or third‐party risk will gain an understanding of the risk, practice, and frameworks, and how to lower their risk for a cybersecurity event at their vendors.
Looking Ahead in This Book
This book is divided into two sections. Section 1, titled “The Basics,” lays the case for the need of a robust and active Cybersecurity Third‐Party Risk Management program as well as the necessary and basic due diligence activities and processes needed. These are not basic as in “simple,” but in terms that they are the foundation necessary to building a mature program, which is covered in Section 2, titled “Next Steps.” This section details what comes next, after you have built the basic foundation. This “Next Steps” section describes cyber legal language, cloud security, software security, connectivity security, offshore vendors, and how to build predictive reporting that focuses on the highest risk vendors.
Chapter 1 opens with a detailed description of risk by using examples of the SolarWinds and other supply‐chain attacks, which happened in late 2020, as prime examples of how the threat actors have evolved both in their identity and tactics. Examples are also provided in a long list of companies who have lost their data due to a vendor that did not take due care with their data. Chapter 2 provides some basics on cybersecurity. This book does not require the reader to be a cybersecurity or third‐party risk expert, but it does require that a few concepts are defined and frameworks are covered for both topics to ensure all readers are at a set level. Chapter 3 delves into how the COVID‐19 pandemic affected the security landscape and how quickly the attackers adapted to new opportunities. What happens when the pandemic is over and how it will change behaviors and business in ways that will become the new normal will mean a continued increase in cybercriminal activity.
Chapter 4 is an in‐depth look at Third‐Party Risk Management (TPRM) and is included to provide a set level for the readers as well as to tie the cybersecurity and TPRM concepts together, as both domains are aimed at identifying and managing risk. Chapters 5 through 9 cover the vendor lifecycle of intake, ongoing security, and offboarding due diligence activities Chapter 5 reviews the activities and requirements for vetting and performing security assessments of new vendors or services from existing suppliers. Chapter 6 describes ongoing cybersecurity due diligence activities such as remote assessments. Chapter 7 is then devoted to the important complex topic of on‐site assessments, which are essential due diligence processes for the physical validation of security controls at a vendor site and the gold standard for assurance.
Chapter 8 covers the Continuous Monitoring (CM) program and how it is a crucial security control for vendors for the times in between the point‐in‐time assessments. Building a robust CM program means taking a set of tools and internal data to engage vendors on potential real threats that they may be unaware of and reducing risk collaboratively. Chapter 9, the last chapter on the vendor lifecycle, discusses offboarding. Many firms overlook this part of the lifecycle, so this chapter covers the critical steps and due diligence that must be done to ensure there's no risk to the data or connectivity from a vendor.
Section 2 begins with Chapter 10, which discusses the large topic of the cloud. The shared responsibility model is discussed and how it affects the security controls that your vendor is responsible for and what they have outsourced to the Cloud Service Provider (CSP). Cybersecurity, offshore vendors, cloud and privacy legal language and process is covered in Chapter 11; and then Chapter 12 details in depth the possible ways to test and perform due diligence on third‐party software. Connectivity to a vendor is a unique risk that opens a whole organization's network and data to an attacker traversing from the vendor or exploiting the hardware they use to connect, and is discussed in Chapter 13. Chapter 14 contains details on how to manage offshore vendor risk, while Chapter 15 wraps up with ways to take all the data collected with the due diligence and other cybersecurity activities to become more predictive for risks and produce reports.
Special Features
The notes found sprinkled throughout this book are designed to provide an example or expansion on topics that bring the topic (either in the chapter or the book as a whole) into a real‐world illustration or in‐depth analysis. Tips are added in the book to deliver information to the reader on how to improve a process or activity (or a common pitfall to avoid), while definitions help the reader to understand the concepts involved.
Chapter 1What Is the Risk?
On December 10, 2020, ESET researchers announce they have found that a chat software called Able Desktop (Able)—part of a widely used business management suite in Mongolia including 430 Mongolian government agencies—was exploited to deliver the HyperBro backdoor, the Korplug RAT (remote access trojan), and another RAT named Tmanger. They also found and identified a connection with the ShadowPad backdoor, used by at least five threat actors in the exploit. Two installers were infected with the trojan and the compromised Able update system was installed with the malicious software. Evidence shows that the Able system had been compromised since June 2020, while the malware‐infected installers were delivered as far back as May 2018.
The post explains that HyperbBro is commonly attributed to the cybercriminal group named “LuckyMouse,” a Chinese‐speaking threat actor known for highly targeted cyberattacks. Primarily active in South East and Central Asia, many of their attacks have a political aim. Tmanger is attributed to TA428, also a Chinese Advanced Persistent Threat (APT) group. Because these two applications are used normally by different APTs and are now together in one attack, the ESET team theorizes that LuckyMouse and TA428 are sharing data and weapons; they are also likely the subgroup of a larger APT. Given the region and threat actors, it is considered to be a political attack that had been planned as early as May 2018, yet not carried out in earnest until two years later.
Advanced Persistent Threat (APT) is the term given to state actors (i.e., government run or authorized hackers) or large cybercriminal syndicates that have a lot of time and patience to perform very stealthy, large‐scale attacks aimed at political or economic goals.
The SolarWinds Supply‐Chain Attack
On December 13, 2020, FireEye, a global leader in cybersecurity, publishes on its website the first details about the SolarWinds Supply‐Chain Attack, a global intrusion campaign inserting a trojan into the SolarWinds Orion business software updates to distribute the malware. FireEye names the malware “Sunburst.” After the attackers successfully hacked into FireEye, their activity demonstrated lateral movement and data exfiltration. “The actors behind this campaign gained access to numerous public and private organizations around the world… . This campaign may have begun as early as Spring 2020 and is currently ongoing… . The campaign is the work of a highly skilled actor and the operation was conducted with significant operational security,” as explained in the Summary from FireEye's website on December 13th.
The attackers added a .dll file (a configuration file) called SolarWinds.Orion.Core.BusinessLayer.dll to the Orion product, which had been digitally signed and enabled backdoor communications over HTTP (i.e., normal, unencrypted web traffic), to other servers. The Sunburst malware is suspected to have lain quietly for two weeks, while it performed some reconnaissance via executing commands that led to file transfers and to controlling the victim's servers (i.e., reboots, disabling services). Using a native product within Orion, the Orion Improvement Program (OIP), Sunburst blended in with the program's normal functions expertly. It even had the capability to sniff out the antivirus and cybersecurity forensic tools being used, likely to learn how to better go undetected.
“As much as anything, this attack provides a moment of reckoning. It requires that we look with clear eyes at the growing threats we face and commit to more effective and collaborative leadership by the government and the tech sector in the United States to spearhead a strong and coordinated global cybersecurity response,” according to Brad Smith, President of Microsoft (December 17, 2020) as posted on his blog about the SolarWinds attack. This attack was used to steal valuable intellectual property from the top‐tier security company FireEye. As of the time of this writing, it has been confirmed to have affected dozens of U.S. cabinet‐level agencies. Due to the pervasiveness of the SolarWinds product across the world, more breaches will be discovered in the following days, weeks, months, and years to come. Some may never be discovered (or admitted); however, there will be international victims. It is a coup for the suspected perpetrators, thought to be a state actor who used a supply side attack, exploiting the weakness of a popular network and monitoring tool, SolarWinds, to circumvent the tight defenses of the intended victims.
On December 18th, Microsoft released information identifying more than 40 government agencies, higher learning institutions, Non‐Governmental Organizations (NGOs), and information technology companies that were infiltrated, with four‐fifths of them being U.S.‐based, and nearly half of those being tech companies. On his blog, Brad Smith said
This is not “espionage as usual,” even in the digital age. Instead, it represents an act of recklessness that created a serious technological vulnerability for the United States and the world. While the most recent attack appears to reflect a particular focus on the United States and many other democracies, it also provides a powerful reminder that people in virtually every country are at risk and need protection irrespective of the governments they live under.
One act of recklessness that he refers to is that this pervasive software, SolarWinds Orion, was clearly not performing its own due diligence and due care to protect itself and its customers, and this product is used by nearly everyone. Further recklessness was that all the customers of SolarWinds were not performing at expectations for cybersecurity's best practice.
If customers had performed some key cybersecurity assessment on a third‐party software maker like SolarWinds, this attack could have been detected. Were intake questions asked about the type of data to which SolarWinds had access and where that data might go or be stored? Depending on a company's solution type, asking questions about how the secure software development lifecycle is managed and audited is considered to be appropriate.
With the hardware device, what was SolarWind's supply chain security for the hardware parts and assembly? For the company that had ventured to perform an on‐site cybersecurity physical validation of SolarWinds, was any evidence produced on how they performed external security scans (which might have detected the default password on their download page “SolarWinds123”)? Who performed these external scans? The company? Or did they hire an outside firm and were the results viewable? Often, such companies will not share these results, so you must negotiate to at least see the Table of Contents, who performed such security scans, and when.
Final question: Had SolarWinds remediated all the findings in the external security scan? While this is not the first time a breach has occurred, the scale of the SolarWinds breach will dwarf all others.
The VGCA Supply‐Chain Attack
On December 17, 2020, ESET Research announced it had detected a large supply‐chain attack against the digital signing authority of the government of Vietnam (ca.gov.vn), the website for the Vietnam Government Certification Authority (VGCA), which is part of the Government Cipher Committee under the Ministry of Information and Communication. Vietnam has made the digital leap, and almost anyone in the country who requires a government service, product, or approval is required to use a digital signature. These e‐signatures have the same authority and enforceability as a traditional paper document autograph according to government decree.
The VGCA also develops and makes available for download a toolkit to automate the process of e‐signatures. This toolkit is widely used by the government, private companies, and individuals. VGCA's website was hacked as early as July 23rd, and no later than August 16, 2020. The compromised toolkits contained malware known as PhantomNet, and SManager ESET confirms that the files were downloaded from the VGCA website directly, and not the result of a redirect from another location. While these infected files were not signed with proper digital certificates, it appears that prior files were not correctly signed either. This may have led to users not rejecting the improper digital certificates of the trojan‐infected files because they behaved the same before the malware was added.
When an infected file was downloaded and run, the correct VGCA program ran along with the malware. This masqueraded the trojan to the end user because they saw the normal program running correctly, being unaware of the trojan or unlikely to look for it because the program appeared to be running normally. The file eToken.exe extracted a Windows cabinet file (.cab), which was used as an archive file to support compression and maintain archive integrity. The file 7z.cab was the file that contained a backdoor for the attackers to exploit. The attackers went to great lengths to ensure that the backdoor ran, regardless of the user's privileges on the device.
If the 7z.cab file was able to run as an administrator on the machine, the program wrote the backdoor to c:\Windows\appatch\netapi32.dll, which then registered it as a service to ensure it kept running after any reboot. On a device that only allowed the file to run as a normal user, the install placed it in a temporary directory, but the program scheduled a task to ensure its persistence. ESET named this backdoor PhantomNet. They mentioned that the victim list included the Philippines, but no evidence was found of a delivery mechanism.
The trojan was determined to be a simple program, and according to the sophistication of the attack, it is likely there were other more malicious plugins added to exploit the backdoor. When the victim's web configuration was determined, then it reached out to a command and control (C&C) server to get instructions. Communications with the C&C servers was done over HTTPS (secure, encrypted web traffic), and the attackers went to the trouble of preventing the interception of traffic (i.e., man‐in‐the‐middle attack on their own data) by using their own certificates.
Data analysis indicates that the malware was used for lateral movement. Once inside the computer, it enabled the attacker to move around the network for other data. The malware collected and transferred information about the computer, user accounts, and victim. In the post‐attack forensics, no data was discovered nor was the goal of the attack.
ESET wrote on its website:
Conclusion: With the compromise of Able Desktop, the attack on WIZVERA VeraPort by Lazarus and the recent supply‐chain attack on SolarWinds Orion, we see that supply‐chain attacks are a quite common compromise vector for cyberespionage groups. In this specific case, they compromised the website of a Vietnamese certificate authority, in which users are likely to have a high level of trust. Supply‐chain attacks are typically hard to find, as the malicious code is generally hidden among a lot of legitimate code, making its discovery significantly more difficult.
The Zyxel Backdoor Attack
On January 2, 2020, Zyxel (networking device maker) announced over 100,000 of their firewalls, VPN gateways, and access point controllers (i.e., Wi‐Fi controllers) contained a hardcoded administrator backdoor account, which gives root‐level access (i.e., a super administrator that can do anything on the device) on both the secure shell (SSH) and web administrator portal. This is on top of a previous similar incident with Zyxel in 2016, where they had a backdoor that allowed any user to escalate their account to root‐level account privileges. This backdoor is still being exploited by botnets to this day, four years later.
A hardcoded backdoor root account is one that cannot be underestimated in how critical the security flaw is. When an account is built within the code of a product, it cannot be removed unless the code itself is changed or updated by the manufacturer. Additionally, the root account is what is referred to as a “super user,” which has privileges as an administrator. The products affected the manufacturers Advanced Threat Protection (i.e., firewall), Unified Security Gateway (i.e., hybrid firewall/virtual private network [VPN] gateway), USG FLEX (i.e., hybrid firewall/VPN gateway), VPN, and NXC (i.e., Wi‐Fi access point controller) series. These devices formed the perimeter and internal security control points for thousands of companies worldwide. The attacker's ability to exploit these network devices most assuredly gives them lateral access into the victim's network. At the time of this backdoor announcement, Zyxel offered patches for all of the products except for the NXC series; it is not producing a patch for another four months.
Zyxel Patch Release
The expected patch release is April 2021. Until then, the only option for organizations is to unplug and replace the devices to ensure security posture.
The hardcoded user account “zyfwp” and password “PrOw!N_fXp” were stored in visible plaintext (i.e., unencrypted or obfuscated). Dutch researchers reported that the password was clearly visible in the code binaries. Apparently the account had the root‐level access to install firmware updates. In the previous 2016 incident, a hacker would've needed to already have a user account on the device to exploit it and to become a super user. In that instance, the root account is directly accessible on HTTPS (port 443) connection to the device.
According to Zyxel's website, “A hardcoded credential vulnerability was identified in the ‘zyfwp’ user account in some Zyxel firewalls and AP controllers. The account was designed to deliver automatic firmware updates to connected access points through FTP.” A search on Shodan (a search engine that can find computers and devices connected to the internet) shows nearly 30,000 of these devices deployed in Russia; 5,000 in Taiwan, Germany, and Finland; with nearly 3,000 in the United States.
Other Supply‐Chain Attacks
Starting in early December 2020 and into early 2021 ( January 2), there were four major third‐party (supply‐chain) attacks and vulnerabilities announced in the span of 20 days. These attacks or vulnerabilities went on for months or longer. Evidence in the SolarWinds and Vietnam attacks pointed to advanced persistent threats launching into the weaponization of the supply chain. In two of the cases, the attacks were directed at nearly a whole country (Vietnam through the VGCA, and Mongolia through the Able Desktop). In three of the instances, the attackers were all APTs and were stealthy enough to remain undetected for months or longer. These attackers have seen what they can do with the weakest links—vendors—to get to a wide range of targets.
Chief Information Security Officers (CISOs) at Fortune 500 companies have spent billions of dollars in the last decade securing their networks from such breaches. Some great tools have been implemented, like Intrusion Detection/Prevention Systems (IDS, IPS), Cloud Access Security Broker (CASB), Privileged Access Manager (PAM), Security Information and Event Management (SIEM), and Security Operations Centers (also referred to as Cyber Fusion Centers) have been built to track and eliminate threats. However, the level of breaches in 2020 continued to increase exponentially. The number of third‐party breach instances grew because every company is some other company's vendor. As the number of these breaches increased, it meant another vendor with hundreds, thousands, or millions of customers became a victim as well.
Public law enforcement is also sounding the alarm. On December 8, 2020, at the American Bankers Association (ABA) Financial Crimes Enforcement Conference, FBI Director Christopher Wray stated, “The financial sector has the most robust cybersecurity of any industry,” which is why cybercriminals try third‐party channels. Banks can also be affected by ransomware targeting third parties, a threat that Wray said “may be somewhat underestimated by a lot of people.” While he specifically called out financial firms, the same could be said of many other sectors, including aerospace, energy, technology, biotech, and others, which generally have excellent security on their own company's assets. Most of the victims of the SolarWinds attack have been in the technology and government sectors, which typically have had good‐to‐excellent security. In those cases, hackers will target the weakest link, attacking vendors who take security less seriously.
Hundreds of examples like this have occurred over the last decade, across the world, and in every industry: Ticketmaster, Capital One, Tesla, Under Armor, Boeing, PayPal, Chubb, nearly every major worldwide automaker, Sears, Best Buy, Entercom, and T‐Mobile. In the case of FireEye or a customer of Zyxel, these companies lost protected data as a result of a third (or fourth) party. No one in the public realm remembers that third party; they simply remember the company they trusted with their data who let them down. Such breaches cost these companies large amounts of money, which directly affected consumers, and extensively damaged the companies' reputations. In areas where there was a heavy regulatory presence, the breached firms were often left holding fines as well. In August 2020, the Office of the Comptroller of the Currency (OCC) assessed an $80 million civil penalty against Capital One for failure to establish effective risk assessment processes prior to migrating significant information technology operations to its public cloud environment. It is expected to cost Capital One up to $150 million, and it cost the company's CISO his job at the firm.
Problem Scope
The secret is out: If you want to attain protected data as a hacker, you do not attack a big company or organization that likely has good security. You go after a third party that more likely does not. Companies have created the equivalent of how to deter car thieves: Ensure that your car looks difficult enough to break into so that thieves move onto the automobile with its doors unlocked and keys in the ignition. When a burglar sees a car with a car alarm, they know that they can look and eventually find a target that isn't so well protected. Exploiting the weakest link is not new. A bank robber could go to the bank to steal money, but a softer target would likely be the courier service as it brings the money into and out of the bank.
To date, cybersecurity and third‐party risk teams have not often collaborated or understood the common threat, instead focusing their security on their own silos. In most regulated industries, this has led to the typical rush to the bottom to meet the regulatory requirements; meaning, rather than create a security program that secures their data and network, they do just enough to keep the regulators happy. Regulators are never considered to be on the leading edge. Whether it is in financial fraud or cybercrime, they simply do not lead in best practices for any field. However, it is not their responsibility. Regulations are typically designed to limit the behavior of a company that may cause financial or bodily harm. The most highly regulated industries, such as energy, biotechnology, finance, telecommunications, aerospace, and many others, have robust Third‐Party Risk Management and cybersecurity teams. However, if these industries rely on doing what the regulators require of them, they are not going to be performing their best practices.
The most successful companies at preventing their systems from being compromised go beyond what a regulator or regulation mandates them to do for compliance. The regulations and their enforcers get involved after something bad has already occurred. Sarbanes‐Oxley (SOX) was a financial regulation designed to lower the risk of financial fraud by publicly traded companies after the damage done by the tech bubble crash in the early 2000s. The Dodd‐Frank Wall Street Reform and Consumer Protection Act was passed in 2010 after the financial meltdown leading to the Great Recession. These widespread changes in regulation occurred as a reaction to the excesses and missteps that lawmakers felt led to the meltdown. Nearly every regulation passed is due to a previous misstep, not in anticipation of the next misstep or mistake
Being reliant on the government to set the standard for what to do and how to do it is a recipe for disaster. This is not to say, however, that regulations are without their merit when enforced correctly. The argument here is not about whether there should be regulations, but more about if organizations should be advised to view those regulations as the bare minimum to perform. In the case of cybersecurity and third‐party risk, regulations provide some excellent guidance on what is important for organizations. However, if a cybersecurity or third‐party risk team only relies on regulators for the best practical procedures to follow, there's a high likelihood their companies will be hacked. In fact, the likelihood is that they will be hacked quite a bit faster than those companies that view regulatory requirements as their starting point.
To illustrate the point, we can look at the Payment Card Industry Security Standard (PCI‐DSS), which is the payment card standard (using credit and debit cards), to guarantee consumer financial data protection. PCI‐DSS has very specific recommendations and is regularly updated for how to secure networks, protect user data, require strong access controls, perform network security tests, and regularly review information security policies. PCI‐DSS is tested regularly, and its standards are considered rigorous. It is not regulated by the government; instead, it's a group of companies that standardized their practices. Meaning, private companies collaborated to create what is nationally viewed as a success in security.
Third‐party risk, or what another company is doing to lower risk to your company, might seem like it places a CISO and the cybersecurity organization at a disadvantage because they cannot control what goes on at another entity. However, that is a myth. While a third party cannot be directly controlled, there are ways to direct and monitor their behavior and choices to greatly reduce your risk. Anyone who has ever been taught risk or worked as a risk professional knows the mantra: Risk can never be zero. In fact, anything is possible. Regardless of whether your company is using all the fancy technology and expensive software, or employing hundreds of cybersecurity professionals hunting for vulnerabilities, there still is a chance, or risk, of a breach.
The goal is reduce risk to a level that is commensurate with your company's effort to reduce it, based upon its risk appetite. This risk reduction effort of a third party requires a change in a company's cybersecurity approach and attitude. As we dive into the numbers, it will become apparent that not enough companies perform the required due diligence. Out of those that do, some do not perform it at the level necessary to reduce the risk. Often, risk reduction is performed as a compliance effort, and merely viewed as a checkbox to complete in order to keep regulators and auditors at bay. This attitude of “ignoring the risk” or “doing it as ‘checkbox’ security” has caused cybersecurity Third‐Party Risk Management (TPRM) to be absent from adequate attention and activity.
Compliance Does Not Equal Security
Compliance is not security, yet security is an important piece of compliance. By definition, being compliant is when your organization meets the minimum requirements for specific regulations at a specific moment in time. If we look at many of the companies on the recently breached list, it's likely all were meeting their regulatory obligations for compliance in their respective industries. In the case of Target when its payment system was hacked, it had just completed a certification of its PCI‐DSS. Most regulations are simply a form of deterrence (of things like insider trading or dumping chemicals into a river). Regulations discourage bad behavior either by people or companies.
Security is an ongoing activity—a continuously occurring activity and not one that occurs at a point in time. Compliance activities are performed as a checklist by internal or external auditors to verify that a company's team is following regulations. It's is an important activity that helps prevent bad acts. Employees and companies see these checks being performed, then are discouraged from doing bad things, such as ill‐gotten gains via insider trading or killing fish by dumping chemicals. Security has the dubious distinction of being sure data is not lost. Once data is lost, it cannot be retrieved—it is gone forever into the Dark Web or other places. The deterrent must come from the company's cybersecurity efforts, not the government regulators.
A company can be 100‐percent compliant and also be 100‐percent owned by hackers. For example, you can drive a car with seatbelts, an automatic brake system (ABS), collision detection and avoidance, blind spot detection, and more, all turned on. Say your car is up to current safety regulations, you, the driver, are all buckled up and sober. There should be no accidents or injuries. Yet, another driver who doesn't always pay attention to the safety warnings fails to perform their best practices while driving, resulting in a collision with injuries. You, a driver, were 100‐percent compliant, yet another driver was not.
Another difference in compliance activities is the timing of each action. Compliance activities are done at a certain point in time for what is present in terms of controls and checks. Another third party (i.e., auditors, regulators) or an internal team ensures that the company they're working with satisfies a set of requirements that allows it to continue to perform business. When all conditions have been satisfied, the compliance activity is finished. Security, however, is never finished. It is continually monitored, reviewed, and improved.
Third‐Party Breach Examples
Throughout many chapters in this book, you will find case study sections where we dive into some of these breaches. However, it is important to understand the scope and history of how often third‐party incidents occur. Many public breaches attributed to a particular company are, in fact, the result of a third party. One of the most well‐known examples is the Target breach. In fact, it was Target's Heating, Ventilation, and Air Conditioning (HVAC) provider that was breached to get access to Target's data.
Following are a few examples of the major third‐party breaches to show how easily they cross over any boundary (i.e., geographic, sectors, sizes):
Target (2013)
: The data of 70 million customers and 40 million credit/debit card information records was leaked by HVAC company Fazio Mechanical Services.
Lowe's (2014)
: Millions of drivers' records were exposed by SafetyFirst, a vendor that stored the exposed data in an online database.
JP Morgan Chase & Co (2014):
Contact information for 76 million consumers and 7 million small businesses was exposed by a third‐party website used to sponsor a foot race.
Sam's Club, Costco, CVS, RiteAid, Walmart Canada, Tesco (2015):
Millions of customer data records were hacked at PNI Digital Media, which is used for online photo ordering and printing.
T‐Mobile (2015):
A total of 15 million personally identifiable information (PII) records were leaked by Experian, a customer credit assessment company.
Forever 21 and Hyatt Hotels (2017):
An unknown number of credit card data records were released due to its POS system.
Uber (2017)
: Coding site GitHub's misconfiguration caused data for 57 million users to be exposed.
Equifax (2017):
Highly confidential data for 143 million consumers was released due to an undisclosed third‐party tool used to build web applications.
Verizon (2017):
The restricted data of 14 million customers was exposed by customer analytics provider NICE Systems.
Hard Rock Hotels & Casinos (2017):
Sabre Corp, a travel reservation service, was exploited, causing a leak of credit card data for an undisclosed number of customers at 11 of its properties.
ShadowPad (2017):
A server management software (made by NetSarang) used by hundreds of multinational and large companies worldwide exposed a still unknown number of protected data records.
Republican National Committee (2017):
The PII for 200 million registered Republican voters was leaked via the third‐party Deep Root.
BevMo (2018):
Online payment provider NCR Corporation was breached for over 14,000 BevMo customers.
Nordstrom (2018)
: A third‐party tool that managed the direct deposit permitted the personal information about Nordstrom's employees to be leaked.
Ontario Cannabis Store (2018)
: Canada Post, an online tracking tool, allowed the loss of the store's customer data.
SuperMicro (2018):
A flaw present in the microchips used by major companies, such as Apple and Amazon, caused an unknown amount of data to be leaked.
Facebook (2018):
Any platform that shared login credentials with Facebook resulted in the exposure of 50 million user accounts.
The Conservative Party (UK) (2018):
CrowdComms, a conference application used by the Conservative Party, was the party responsible for the loss of protected data about Ministers of Parliament (MP), conference attendees, and journalists.
British Airways (2018):
An undisclosed third‐party misconfiguration of JavaScript caused the financial and personal information of over 300,000 customers to be released.
University of Louisville (2018)
: Health Fitness, a fitness vendor, released employee names, employee IDs, and physicians' names.
Washoe County School District (2018)
: District teachers' emails, usernames, and passwords were exposed by an instructional tool provided by Edmodo.
MedCall Healthcare Advisers (2018):
Over 150 businesses were affected by this third‐party breach, with 7 GB of medical information data being exfiltrated.
GoDaddy (2018):
Sensitive records for over 30,000 servers were released by a misconfigured Amazon S3 bucket.
Air Canada (2018):
An undisclosed mobile application provider caused the loss of customer data.
Fiserv (2018):
This financial third‐party website provider was the reason that hundreds of banks had the records for their customers exposed.
Ticketmaster (2018)
: Inbeta, a provider of Ticketmaster's website application, caused a leak of customer data.
Universal Music Group (2018):
Cloud‐storage provider Agilisium caused the loss of internal File Transfer Protocol (FTP) credentials, Amazon Web Services (AWS) secret keys and passwords, along with internal root passwords for structured query language (SQL) databases.
Chili's Grill & Bar (2018)
: Chili's POS system was breached, causing the loss of an undisclosed number of credit card data records.
Best Buy, Sears, Kmart, and Delta (2018):
An online chat provider used by these firms lost over a million customer records in total.
Applebee's (2018)
: 160 restaurants and their customer data were released by the chain's POS system.
Western Union (2018):
Private data about transactions was released by an undisclosed vendor who performed offsite cloud storage.
Ascension (2019):
A misconfigured server at a third party exposed millions of bank loan and mortgage documents.
Amadeus (2019):
The online booking systems for over 140 airlines worldwide had a critical flaw that allowed hackers to get access to the flight reservation systems.
Adverline (2019):
A third party to online European sellers had malicious code injected, exfiltrating credit card information.
Click2Gov (2019):
An online payment tool used by many U.S. and Canadian municipalities was compromised, releasing information on citizens in St. John in Canada and Hanover County in Virginia.
BankersLife (2019)
: Breached third party allowed the information about Humana's customers to leak.
BenefitMall (2019):
A third‐party administrator for Highmark BCBS, Aetna, Humana, and United Health caused a leak of customer data.
Quest Diagnostics (2019)
: From August 2018 to March 2019, a hacker gained access to Quest's data at a billing collections vendor called American Medical Collection Agency (AMCA). A total of 11.9 million records were exposed.
Suprema (2019):
A firm offering biometric security software exposed 27.8 million unencrypted records for over 6,000 firms, including U.K. Metro Police, Power World Gyms, and Global Village.
LensCrafters, Target, EyeMed (2020):
Luxottica, a breached online appointment application provider, caused the loss of thousands of protected health information (PHI) records.
Insurance companies in Texas and Colorado (2020):
Insurance carriers were impacted by a breach at Vertafore, which provides software to insurance companies.
First Federal Community Bank, Bank of Swainsboro, First Bank & Trust, Rio Bank (2020)
: ABS, a bank software provider, released the PII for the banks' customers.
Hotels.com
and Expedia (2020):
Channel manager vendor, Prestige Software, was breached, exposing names, credit card information, and reservation details.
Australian Stock Exchange (2020):
An undisclosed amount of protected data was exfiltrated from the media‐monitoring vendor Insentia.
Google (2020):
A law firm known as Fragomen, Del Rey, Bernsen & Loewy disclosed information that Google used for the I‐9 process (i.e., proof of ability to work in the United States).
City of Odessa (2020):
Click2Gov, a frequently breached vendor, leaked details on how Odessa residents paid their utility bills.
Tribune Media and Times Media Group (2020):
Marketing company, View Media, was breached, releasing information about 38 million U.S. residents.
Buffalo, NY, area hospitals; FeedMore; and Phipps Conservatory (2020):
Blackbaud, a data management vendor, released the names, medical services numbers, dates of patient services, and a list of donors.
Rochester YMCA (2020):
An undisclosed software vendor was breached for the names, addresses, and gift history of donors.
SEI Investments (2020):
MJ Brunner, a third‐party software provider to SEI Investments, was breached, affecting customers at dozens of investment banks.
Bank of America (2020):
Caused by an unnamed third‐party merchant, Paycheck Protection Plan (PPP) application business details, including Social Security numbers (SSNs), emails, addresses, and more, were released.
Citrix (2020)
: An undisclosed vendor disclosed Citrix's customer data, which was exposed on the Dark Web.
Marriott (2020):
A Russian franchise operator was the reason for the second breach at this hotel chain in just two years. This time over 5 million records were compromised.
T‐Mobile (2020)
: An email vendor's breach was the reason that thousands of customer names, addresses, phone numbers, emails, rate plans, and more were exposed. This is the second public breach for T‐Mobile, with the last one occurring in 2015.
Radio.com
(2020)
: Its cloud‐hosting provider misconfigured their instance, which resulted in its customers' PII being made public.
Chubb (2020):
A third‐party service provider released internal sensitive data about Chubb.
General Electric (2020):
Canon, which was used by GE for business processes, was breached, resulting in information on past and current GE employees and sensitive data being released.
Amazon, eBay, Shopify, Stripe, PayPal (2020):
A third‐party application breach was the reason for the release of over 8 million records on sales information, customer names, emails, mailing addresses, and credit card information including the last four digits of account numbers.
SpaceX, Tesla, Boeing, Lockheed Martin (2020):
Viser, a parts manufacturer, released partial schematics for a missile antenna and other restricted internal data.
Carson City (2020)
: Click2Gov caused the release of residents' names, addresses, email, debit/credit cards, card security codes (CVV), and bank account and routing numbers.
Idaho Central Credit Union (2020):
A mortgage portal provider was hacked, releasing customer banking information.
Nedbank (2020):
Nearly 2 million customer PII records were released by Computer Facilities (Pty) Ltd., a marketing and promotional firm.
Mitsubishi (2020):
A large amount of internal restricted data was exfiltrated via an undisclosed vendor in China.
P&N Bank (2020):
A third‐party customer relationship manager (CRM) hosting company caused the loss of nearly 100,000 customer records.
Ubiquiti Inc (2021):
A maker of Internet of Things devices, it lost an undisclosed amount of customer names, email addresses, passwords, addresses and phone numbers due to a third‐party cloud provider.
Bonobos (2021)
: This men's clothing retailer had the data for over 7 million customers (addresses, phones numbers, account info, partial credit card information) stolen from its cloud data provider.
US Cellular (2021):
The fourth largest wireless carrier in the U.S. exposed the private data of almost 5 million customers from its CRM software.
According to a Ponemon Institute survey in 2019, 60 percent of the companies surveyed admitted to not performing adequate cybersecurity vetting of their third parties. Thirty‐three percent replied they had no or an ad‐hoc cybersecurity vetting process. Fifty‐nine percent admitted being affected by a third‐party breach in the previous year. In that same survey, the companies also admitted to sharing their data on average with and requiring protection from a whopping 588 third parties. Following those numbers, this means over half the companies admitted to not performing their cybersecurity due diligence on nearly 600 third parties. Note, these statistics are pre‐COVID‐19 pandemic. However, post pandemic, the cyberattack increase was over 800 percent, according to the FBI as of May 2020. Prior to the pandemic, the problem was pronounced, with the breaches listed including Capital One, Home Depot, and others. However, the lack of due diligence and programs to review the cybersecurity of third parties by so many firms led to an explosion of breaches. And, as everyone is someone else's third party (i.e., every company is selling to someone and using vendors to assist in that effort), the problem was magnified to a boiling point.
Third‐Party Risk Management
Third‐Party Risk Management (TPRM) as a discipline is not very old. In the financial sector, it was not mandated by the Office of the Comptroller of the Currency (OCC) until 2013, when it regulated that all banks must manage the risk of all their third parties. OCC 2013‐29 defined “third party” as any entity a company does business with, including vendors, suppliers, partners, affiliates, brokers, manufacturers, and agents. Third parties can include upstream (i.e., vendors) and downstream (i.e., resellers) and non‐contractual parties. Other regulated sectors have seen similar requirements, often indirectly via privacy regulations. For example, General Data Protection Regulation (GDPR) or the California Privacy Rights Act (CPRA) require many companies subject to these regulations to perform due diligence on vendors who have access to their customer data. This may not lead to a full‐blown risk management division or group, but someone will be required to perform some oversight in an organized process, lest they get subjected to the extreme financial penalties both regulations require.
Other risk domains exist in TPRM: strategic, reputation, operational, transaction, and compliance domains. Why is the focus in this book on the cybersecurity domain exclusively? That is where the money is. While there are financial and reputational risks for the other domains, none of them provide the level of risk to a firm such as the risk of information security. As described previously, there are number of breaches that can be directly attributed to a cybersecurity breach at a vendor. It is not that these other domains aren't important, but none of them have the impact that a cybersecurity risk poses to a firm, financially or reputationally. Perform an internet search on the other domains, and you will struggle to find results. A similar search on cybersecurity breaches produces more results than one can list in a single page. Like any organization with more than one domain, if one of those domains presents a higher risk for practitioners, and evidence shows that Information Security does, then that domain needs more research, resources, and results.
While TRPM organizations struggle to keep up with the level of breaches and incidents with vendors, evidence shows most cybersecurity organizations are not taking a lead in this domain, and that TPRM groups do not have the expertise to address this gap. According to the Ponemon Institute “Data Risk in the Third‐Party Ecosystem” study (2018), only 40 percent perform any cybersecurity due diligence. Sixty percent perform none or only ad‐hoc cybersecurity reviews. The evidence indicates that a large percent of the 40 percent (i.e., those that perform some cybersecurity due diligence) do not do enough (as evidenced by the level of breaches/incidents). TPRM organizations must begin focusing more on the Information Security domain, and either directly bring cybersecurity experts into their organizations or partner with cybersecurity teams to address the gap. Doing so will also require that a cybersecurity team is able to understand the problem with third parties and address the risk.
While the fines and publicity for failure to follow TPRM guidelines are not as big, instances of regulators acting can be found:
In 2020, the OCC assessed an $85 million civil money penalty against USAA for failure to implement and maintain an effective risk management compliance.
In 2020, the OCC assessed a $60 million civil money penalty against Morgan Stanley for not properly decommissioning some Wealth Management business data centers.
In 2020, the OCC assessed a $400 million civil money penalty against Citibank for failures in enterprise risk management.
In 2020, the Federal Reserve announced an enforcement action against Citigroup Inc., requiring that the firm correct several longstanding deficiencies.
In 2020, the OCC assessed an $80 million civil money penalty against Capital One for not establishing an effective risk assessment process, which led to the breach in its public cloud.
In 2013, the U.S. Security and Exchange Commission (SEC) lowered the burden of proof for proxy disclosure enhancements on risk management inadequacy from fraud to simply negligence. This means that boards of directors and senior management of publicly traded companies can no longer claim they had no knowledge about a risk.
In 2019, the SEC and Commodities Futures Trading Commission (CFTC) charged Options Clearing Corp. with failing to establish and maintain adequate risk management policies, forcing the organization to pay a $20 million penalty.
Cybersecurity and Third‐Party Risk
Cybersecurity as a field is also very young, though it is older than TPRM. Cybersecurity is often thought to have begun after the first cyberattack was thwarted in 1986 in the Soviet Union, when Marcus Hess hacked into 400 military servers and the Pentagon. Intending to sell the information to the KGB, Hess was foiled by American Clifford Stoll.
In the 1970s, several attacks occurred on the early internet. For example, Bob Thomas created the first computer worm named Creeper, which traveled between early APRANET terminals with the message “I'M THE CREEPER: CATCH ME IF YOU CAN.” Also, in the same decade, Ray Tomlinson created the worm, Reaper, the first antivirus software that could find copies of Creeper and delete them. However, the one that finally illustrated the need for information security at the doorstep of the novice IT industry was the Morris Worm.
The Morris Worm
In 1988, Robert Morris, like all curious computer scientists, wondered “how big is the internet”? And like all good curious computer scientists, he decided to write a program to find out the answer of “how big?” The answer was found by his worm, which traveled through networks like wildfire, invaded Unix terminals, and crossed domains faster than a speeding bullet. His worm was so good at replicating that it would infect the same computer multiple times, and each additional infection would continually slow the computer down to the point of damaging it. Robert Morris was charged under crimes covered by the Computer Fraud and Abuse Act. Enacted in 1986, this act was an amendment to the first federal computer crime law and addressed hacking. This act continues to be updated, but only as recently as 2008, which reaffirms our earlier point that regulators are not considered to be at the cutting edge, and that good cybersecurity programs should not be designed to meet regulations. Such programs should exceed these regulations in order to have any hope of being successful. If we consider the 1970s as the start of cybersecurity, it is only within the last 20 years that companies have had Chief Information Security Officers (CISOs) and divisions, groups, or teams who reported directly to them.
Cybersecurity, like any other discipline, has developed several frameworks, associations, testing accreditors, credentials, and subdisciplines over those 20+ years. ISC2, ISACA, and EC‐Council, are just three of the credential/testing accreditors. CISSP, CIPM, CISM, CompTIA Security+, and countless other managerial, technical, and administrative certifications are also available. For the purposes of demonstration on the complexity of the cybersecurity subject matter, we use the Certified Information Systems Security Professional (CISSP) as the best example. This certification is still the gold standard in the industry, and can be proven by study after study indicating that the demand vastly outstrips the supply of certificate holders of CISSP.
Within infosec, they have developed clear subdomains (citing the CISSP 8 domains):
Security and Risk Management
Asset Security
Security Architecture and Engineering
Communications and Network Security
Identity and Access Management
Security Assessment and Testing
Security Operations
Software Development Security
Further subdomains can be found within these cybersecurity domains. For example, let's look at the Security and Risk Management domain:
Security and Risk Management Domain: It comprises 15 percent of the CISSP exam and is the largest domain found in CISSP. The latest editions of the study guides for this exam detail the following:
The Confidentiality, Integrity and Availability of information
Security governance principles
Compliance requirements
Legal and regulatory issues relating to information security
IT policies and procedures
Risk‐based management concepts
This information is in Chapter 1 “Security and Risk Management” in the CISSP All‐in‐One‐Exam, 8th Edition by Shon Harris. Notice there is one bullet on risk‐based management concepts. Within those study guides, none of them have more than two pages on “Supplier Management” or “Vendor Risk Management Process,” depending on how it is listed in the index. The focus of these guides is on the management of a process and compliance language, such as service‐level agreements (SLAs), legal concerns, and privacy regulations. Supplier management is viewed as something belonging to a process team, which certainly some of the work will be, but it misses the opportunity to take an aggressive approach, such as in a Security Operations domain.
