Cybersecurity and Third-Party Risk: Third Party Threat Hunting

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 1

What 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