Chapter 1. Dark Matters
It was the Sunday after Thanksgiving, at a crowded bus station on the east coast. A young man stood in line outside, waiting to purchase a bus ticket from the ticket vending machine so that he could make his way home. He swiped his credit card. The machine spit out a one-way ticket and a receipt. Next.
Unbeknownst to anyone, the machine also recorded the young man’s credit card number in a vast and growing database stored there on the sidewalk, along with millions of other credit card numbers. This wasn’t supposed to happen.
Years earlier, a coder who worked for the ticketing system’s vendor was debugging a tricky problem. The machines weren’t processing credit card numbers correctly. He quickly turned on a debugging routine that automatically wrote every credit card number to disk. Aha! He fixed the code—but forgot to turn off the debugging routine. The new version of the software was installed on all new ticket machines deployed around the world. Each ticket machine sat silently on the sidewalk for years saving all the credit card numbers that anyone ever swiped.
Just a few minutes after the young man swiped his credit card, the ticket machine made a web connection to a city employee’s home computer. This definitely wasn’t supposed to happen.
The city’s employees were allowed to work from home and frequently connected their home computers to the city’s network in order to access files or check email. At home in the evenings, they also used their computers to download movies, play games, and surf the web. Their teenage kids traded emails and instant messages. Their home computers became infected with viruses and worms. Then, at the start of the workday, they connected their computers to the city’s network again. The firewall allowed full access between the employee home computers and the rest of the city’s internal network—including the ticket vending machines.
The city’s IT staff regularly installed software patches on desktops and servers, which protected them from many viruses and worms—but the ticket vending machines were different. They ran an older version of Microsoft Windows. The ticket machine vendor refused to support the machines if the latest Windows updates were applied, and so the city had to wait until the vendor was ready to apply patches—which happened sporadically and rarely. Nobody wanted to accidentally break the city’s bus ticketing infrastructure by applying software patches without the vendor’s support. So, the machines sat, unpatched and vulnerable, there on the street.
Meanwhile, the employees’ virus-infected home computers frequently probed the entire network for other vulnerable systems—and found the ticket vending machines, which stood quietly on the sidewalk, storing millions of credit card numbers.
Months and years went by. Eventually, the city’s IT management realized that the internal firewall rules were wide open and fixed them. Months after that, the vendor notified the city officials of the debugging routine. City officials investigated. Management had one question: Had credit card information been stolen?
This was where I came in, a young digital forensic investigator. I earned my living as a subcontractor in a time when very few people had real-world digital forensics experience.
The city launched a forensic investigation and handed 10 TB of network logs to a third-party forensics firm. The firm called me in to conduct the analysis. At the time, 10 TB of log data was an enormous volume. As soon as the call came in, I rushed out and purchased an expanded storage system with superfast connectors to handle the case. Two days later, the log files arrived on a hard drive via FedEx, and I immediately began the decompression process.
Log files are simply records of events that happen on a network. An event can be literally anything: a user logging in, or a packet traversing the firewall, or your antivirus software alerting on a Trojan that you accidentally downloaded. This seemingly simple definition belies a deeply challenging problem: When you have hundreds of thousands or even millions of recorded events, how do you find a needle in the haystack? Even more of a challenge: There is no standard format for log files. As a forensic investigator, you never know what information you’re going to be handed or what will be left out. Every firewall vendor and IT team sets up its logging system differently. You might simply be handed a file with lots of numbers on every line, and your first job is to figure out what each number means.
At the time I worked the ticket machine case, there were few tools available for analyzing logs, and very little available documentation. Before I could even start to analyze the evidence files, I essentially had to conduct a mini-investigation to understand just what I had been handed; determine what, if any, information would be relevant to the case; and figure out the most efficient way to process all that network-based evidence.
As the evidence files were decompressing, I took a sample of the logs to analyze their format and began writing the custom scripts that would be needed to properly “parse” the evidence.
The logs were full of gaps. Sure, the ticket machines’ network activity had been logged—sometimes. There were only ten months of intrusion detection system (IDS) alerts, remote connection records, and firewall log data relating to the ticket vending machines. All of this data was very high level, with only source and destination IP addresses and ports logged, along with the amounts of data transferred. There was no information about specifically what was transferred at any time. The city did not have a data-loss prevention (DLP) system or filesystem monitoring that would have alerted if credit card information specifically was transferred over the network. No operating system logs, no packet contents, and no hard drives were provided for analysis.
The evidence showed that the ticket vending machines had communicated with dozens of systems throughout the city’s network, including many employee home computers. The IDS alerts included alarming notices such as “SMB login successful with Guest Privileges,” “Server Service Code Execution,” “Windows Workstation Service Overflow,” and “Outbreak Prevention Signature.” The machines had exchanged data with remote servers (often in foreign countries), as well as other computers on the city’s network.
The ticket machines were clearly vulnerable, and they had been scanned and probed by infected home computers, which easily could have installed viruses and malware on the unpatched equipment. An attacker that broke in would find huge volumes of credit card numbers, stored unencrypted on the machines’ hard drives. The machines exhibited strange behaviors, such as unexplained communications with foreign countries, at all hours of the day and night. The traffic patterns showed obvious symptoms of malware infection and unauthorized access.
However, there was no smoking gun, no direct evidence that credit card numbers stored on the ticket machines had been stolen by an attacker. How could there be, when there was no network or file monitoring in place that would alert on such activity, and the hard drives weren’t provided for analysis? There was no information about the malware’s capabilities or exactly what information a criminal may have gained.
In the forensic report, I stated that, due to lack of security controls, there had been ample opportunity for access, but lack of evidence prevented a definitive conclusion on the question of whether credit card data had actually been compromised.
I assumed that the city would publicly disclose the incident. There had clearly been unauthorized access to the ticket machines, and private credit card information was stored on them. It seemed the ethical thing to do. In all likelihood, there was probably sensitive information on the other infected computers within the city’s network, as well as employee home computers, which might have been accessed by criminals as well. I knew the city wouldn’t disclose the fact that other computers on the network had been compromised (that was an alltoo-common occurrence in most organizations), but I hoped the investigation would at least spur a review of its network architecture and logging practices. As a low-level technical analyst, my role ended once the forensic report was delivered, and I was never privy to any further conversations about the incident.
Weeks, months, and years went by. I kept an eye on the news but never saw a public notification. Other forensics cases came in, and I wrote reports with similar conclusions: not enough evidence. Not enough logs. No way to prove a theft beyond the shadow of a doubt. They never made the news, either. Once, I got a phone call from a company that suspected a breach of its point-of-sale system, which processed credit cards. A representative called back five minutes later to say that the company had decided to just format and reinstall the computer, and not investigate at all.
Most of all, I wondered about the calls I didn’t get, the cases that were never investigated, and never even detected in the first place.
1.1 Dark Breaches
It’s shocking to realize that the number of data breaches that actually get reported represents just a small fraction of the number of data breaches that actually occur. Even the information we do have about data breaches is often skewed, and it certainly doesn’t represent any kind of statistically valid sample set from which we can draw scientific conclusions.
“Most businesses that get hacked surely do the right thing and inform customers,” reported BusinessWeek, naively, in 2002.1 This reflected a common assumption once held by the general public that organizations would “of course” report leaks of personal customer information. Experienced security professionals know that reality is much more complex.
1. Alex Salkever, “Computer Break-Ins: Your Right to Know,” BusinessWeek, November 11, 2002.
Consider that in order for a data breach to be publicized, the following events must occur:
Detection - Symptoms of a potential data breach must be detected.
Recognition - The event must be recognized and classified as a data breach.
Disclosure - Information about the data breach must be disclosed.
Each of these steps sounds fairly straightforward, but reality is often full of technical failures, gray areas, and miscommunications. If an organization’s data breach management process fails at any of these three steps—detection, recognition, or disclosure—then the data breach will simply go unreported, and often entirely untracked.
In physics, scientists have for decades inferred the existence of dark matter, as described by CERN:2
2. CERN, “Dark Matter,” CERN, https://home.cern/about/physics/dark-matter (accessed January 5, 2018).
[D]ark matter does not interact with the electromagnetic force. This means it does not absorb, reflect or emit light, making it extremely hard to spot. In fact, researchers have been able to infer the existence of dark matter only from the gravitational effect it seems to have on visible matter. Dark matter seems to outweigh visible matter roughly six to one, making up about 27% of the universe. Here’s a sobering fact: The matter we know and that makes up all stars and galaxies only accounts for 5% of the content of the universe!
Similarly, “dark breaches” exist. These are breaches in which information may have been compromised, but the incident is never disclosed to any reporter, government agency, or researcher. It may never have been detected in the first place. As with dark matter, there is evidence from which professionals can infer the existence of dark breaches.
1.1.1 What Is a Data Breach?
The question of whether a data breach gets reported is very closely linked to the bigger question: What is a data breach?
“I always say it’s defined by the law,” says Chris Cwalina, Global Co-Head of Data Protection, Privacy and Cybersecurity at law firm Norton Rose Fulbright. A veteran of the data breach response world, Chris got his start in cybersecurity as the legal “quarterback” in the infamous ChoicePoint data breach back in 2005. One fall evening in Virginia, Chris was kind enough to meet me so that I could pick his brain about data breach response.
Sitting across the table from each other, an attorney and a digital forensics examiner, we each represented key functions of modern incident response—with very different perspectives.
“What a data breach is to somebody like you is different than what it is to lawyers who practice in this space,” Chris mused. “When you have an unauthorized actor on your system, it’s really important to define ‘data breach’ carefully, and to say that only your outside legal counsel can make that determination. If you are inside, you should be saying that it is an incident. It’s the lawyer’s job to determine whether it is a breach, as defined. Lawyers need expert help from IT and IS professionals, but ultimately, the decision comes from applying facts to law. That, unfortunately, is just because of how the laws have evolved.”
Security practitioners often refer to cybersecurity “events” and “incidents.” Long ago, the National Institute of Standards and Technology (NIST) defined these terms as follows:3
3. Paul R. Cichonski, Thomas Millar, Timothy Grance, and Karen Scarfone, Computer Security Incident Handling Guide, Special Pub. 800-61, rev. 2 (Washington, DC: NIST, 2012), https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf.
Event - Any observable occurrence in a system or network. Events include a user connecting to a file share, a server receiving a request for a web page, a user sending email, and a firewall blocking a connection attempt.
Computer security incident (often referred to simply as an “incident”) - A violation or an imminent threat of violation of computer security policies, acceptable use policies, or standard security practices.
When does an “event” or “incident” become a bona fide data breach? In the United States today, there is no federal definition of a “data breach,” or even a federal data breach notification law which applies to all types of organizations. Instead, the United States has a patchwork of state and local laws, often implemented in conjunction with industry-specific federal breach notification laws such as the Health Information Technology for Economic and Clinical Health (HITECH) Act.4
4. HITECH is a U.S. federal regulation established to “promote the adoption and meaningful use of health information technology.” Passed in February 2009, HITECH included a game-changing data breach notification provision. For more details, see “HITECH Act Enforcement Interim Final Rule,” U.S. Department of Health and Human Services, last revised June 16, 2017, https://www.hhs.gov/hipaa/for-professionals/index.html.
“If you look at the state definitions for what a security breach is, they’re all pretty close,” says Chris Cwalina. Most laws are architected to require “notification” in the event of a “breach of security” of “personal information.”
According to the law firm Baker Hostetler, LLP, the most common definition of “breach of security” is:
the unlawful and unauthorized acquisition of personal information that compromises the security, confidentiality or integrity of personal information.5
5. Baker Hostetler, “Data Breach Charts,” Baker Law, July 2018, https://www.bakerlaw.com/files/uploads/documents/data%20breach%20documents/data_breach_charts.pdf.
That means that in order for the general public to find out about a breach, the event must first fit the definitions of both “breach of security” and “personal information,” and also meet any other requirements for notification. “The problem is,” Chris explained, “some states [require notification upon] unauthorized acquisition or access [of personal information], in some states it’s unauthorized access and acquisition (note the ‘and’ versus the ‘or’), in some states it’s just access, and in some states it’s just acquisition. There should be more consistency with what a data breach is.”
Many states also have a “harm trigger,” Chris elaborated, which modifies the requirement to notify based on an assessment of whether the information has been or is likely to be misused. “Let’s say there’s access to the data, but you say there’s zero likelihood that this information is going to be misused,” explained Chris. “Then you can make a determination not to notify. In some cases you have to consult with law enforcement, like in Florida, and then document it, notify the attorney general of your decision, et cetera.”
All of these different definitions and laws have led to a great deal of confusion, both regarding what a data breach is and how to react when one occurs.
1.1.2 Unprotected Personal Information
When Target was famously hacked in 2013, customers received a notification which stated that “criminals forced their way into our systems and took guest information, including debit and credit card data.” Target went on to state that “your name, mailing address, phone number, or email address may also have been taken during the intrusion.”
Oddly left out of Target’s data breach announcement was a very sensitive topic: your personal shopping history and customer profile. It was left out for a reason—and not because the data didn’t exist.
The New York Times exposed Target’s extensive data collection and analysis practices in 2012, when it ran a story describing how the company leveraged statistics to generate, for example, lists of customers who were pregnant. At the time, Andrew Pole, a statistician hired by Target, revealed that Target assigns each customer a unique “Guest ID” number and ties this to a history of all purchases, as well as a vast array of other personal information. “If you use a credit card or a coupon, or fill out a survey, or mail in a refund, or call the customer help line, or open an e-mail we’ve sent you or visit our Web site, we’ll record it and link it to your Guest ID,” Pole said. “We want to know everything we can.”
Target also keeps extensive records of your personal details, potentially including sensitive information purchased from data brokers and combined with your customer record. Using this detailed personal information, Target can draw conclusions about your health, needs, and habits, which it can then use for financial gain.
“Also linked to your Guest ID is demographic information like your age, whether you are married and have kids, which part of town you live in, how long it takes you to drive to the store, your estimated salary, whether you’ve moved recently, what credit cards you carry in your wallet and what Web sites you visit,” reported the New York Times. “Target can buy data about your ethnicity, job history, the magazines you read, if you’ve ever declared bankruptcy or got divorced, the year you bought (or lost) your house, where you went to college, what kinds of topics you talk about online, whether you prefer certain brands of coffee, paper towels, cereal or applesauce, your political leanings, reading habits, charitable giving and the number of cars you own.”6
6. Charles Duhigg, “How Companies Learn Your Secrets,” New York Times Magazine, February 16, 2012, http://www.nytimes.com/2012/02/19/magazine/shopping-habits.html?pagewanted=1&r=2&hp.
If data exists, then it can be stolen. When Target was hacked, what happened to all this detailed shopping information and the resulting lists of consumers with health issues or other categorizations? Target took the time to reassure consumers that “there is no indication that PIN numbers have been compromised,” but shopping histories weren’t mentioned at all—one way or another—in consumer notices. Why would they be, since information of this type—which seems so personal to consumers—is not, in fact, covered by state or federal data breach notification laws?
According to Baker Hostetler, the most common definition of personal information in U.S. state law is:7
7. Baker Hostetler, “Data Breach Charts.”
an individual’s first name or first initial and last name plus one or more of the following data elements: (i) Social Security number, (ii) driver’s license number or state-issued ID card number, (iii) account number, credit card number or debit card number combined with any security code, access code, PIN or password needed to access an account and generally applies to computerized data that includes personal information. Personal Information shall not include publicly available information that is lawfully made available to the general public from federal, state or local government records, or widely distributed media.
What’s left out of this definition? An absolutely enormous array of information that most people consider private, such as:
Shopping history
Location information (such as the coordinates of your favorite hangout locations or the route you drive to work, captured by your cell phone or car)
Health information, including prescription drug records
Emails
EZ-Pass, FastLane, or other travel records
Last name plus Social Security number (SSN) (no first name or first initial)
And much, much more
Think your health information is protected? Only in certain contexts. In 2016, the U.S. Department of Health and Human Services issued a report outlining the gaps in privacy and security of entities that are not regulated by the Health Insurance Portability and Accountability Act (HIPAA) of 1996. HIPAA (as amended by the HITECH Act in 2009) is the primary federal law that protects personal health information in the United States. It applies to “covered entities,” such as healthcare providers, health plans, and healthcare clearinghouses, as well as their “business associates” (persons or entities acting on their behalf, such as billing vendors or IT providers).
Notably, “[t]he wearable fitness trackers, social media sites where individuals share health information through specific social networks, and other technologies that are common today did not exist when Congress enacted [HIPAA].”8 There are many apps and websites that “allow individuals to enter their health information to monitor blood sugar, eating habits, or sleeping patterns. Other health data websites may provide information or send out e-mails with information about medications or specific conditions such as allergies, asthma, arthritis, or diabetes. Twenty-seven percent of internet users and 20 percent of adults have tracked their weight, diet, exercise routine, symptoms, or another health indicator online.”9
8. U.S. Department of Health and Human Services, Examining Oversight of the Privacy & Security of Health Data Collected by Entities Not Regulated by HIPAA (Washington, DC: US HSS, June 17, 2016), https://www.healthit.gov/sites/default/files/non-covered_entities_report_june_17_2016.pdf.
9. U.S. Department of Health and Human Services, Examining Oversight.
Google, which once ran a service called Google Health that enabled users to store health information in the cloud, had an online FAQ that explained:
Is Google Health covered by HIPAA? Unlike a doctor or health plan, Google Health is not regulated by [HIPAA]. . . . This is because Google does not store data on behalf of health care providers. Instead, our primary relationship is with you, the user.
Due to gaps in the law, certain unauthorized disclosures of health or medical information may not be subject to state or federal breach notification laws. In other words, if your cloud provider gets hacked and loses your health information, it may or may not not be required to tell you.
1.1.3 Quantifying Dark Breaches
From the early days of information security, the U.S. government published reports that clearly illustrated the problem of “dark breaches.” There were even some attempts to quantify unreported breaches. In 1996, the GAO issued a report to Congress that described the Defense Information Systems Agency (DISA) Vulnerability Analysis and Assessment Program:10
10. U.S. General Accounting Office (GAO), Information Security: Computer Attacks at Department of Defense Pose Increasing Risks, Pub. No. B-266140 (Washington, DC: GPO, May 1996), 19, http://www.gao.gov/assets/160/155448.pdf.
Since the program’s inception in 1992, DISA has conducted 38,000 attacks on Defense computer systems to test how well they were protected. DISA successfully gained access 65 percent of the time. . . . Of these successful attacks, only 988 or about 4 percent were detected by the target organizations. Of those detected, only 267 attacks or roughly 27 percent were reported to DISA.
Figure 1-1, which is from the 1996 congressional report, illustrates the percentage of attacks that were successful, detected, and reported. As shown, only a very small percentage of successful security breaches were properly reported to DISA.
The GAO report went on to state that “DISA estimates indicate that Defense may have been attacked as many as 250,000 times last year,” but cautioned that since such a small percentage of breaches was actually detected and reported, the exact number of successful breaches—and therefore the full extent of related damage—was “not known.”11
11. GAO, Information Security, 3.
“Not known,” of course, doesn’t mean “nonexistent,” as DISA knew all too well. From the GAO report:12
12. GAO, Information Security, 19.
According to Defense officials, attackers have obtained and corrupted sensitive information—they have stolen, modified, and destroyed both data and software. They have installed unwanted files and “back doors” which circumvent normal system protection and allow attackers unauthorized access in the future. They have shut down and crashed entire systems and networks, denying service to users who depend on automated systems to help meet critical missions. Numerous Defense functions have been adversely affected, including weapons and supercomputer research, logistics, finance, procurement, personnel management, military health, and payroll. . . . While Defense is attempting to react to attacks as it becomes aware of them, it will not be in a strong position to deter them until it develops and implements more aggressive, proactive detection and reaction programs.
1.1.4 Undetected Breaches
Detection is key. By DISA’s analysis, the overwhelming number of security breaches (96%) were not reported because they simply weren’t detected in the first place. There is evidence to suggest that lack of detection is still a critical issue today. For example, when Yahoo disclosed a major breach of user account data in 2016, the public was shocked to find that it had apparently taken more than two years for the company to fully understand what had occurred.
“For a firm like Yahoo, which is a technology firm no less, you would expect that they would be able to detect and even disclose the breach a little quicker,” said cybersecurity professor Rahul Telang, of Carnegie Mellon University. “It was surprising that Yahoo didn’t know about it until the user data hit the black market.”13
13. Tracey Lien, “It’s Strange Yahoo Took 2 Years to Discover a Data Breach, Security Experts Say,” Los Angeles Times, September 23, 2016, http://www.latimes.com/business/technology/la-fi-tn-yahoo-data-breach-20160923-snap-story.html.
But is it really surprising? There are plenty of published reports of data breaches where hackers lurked for well over a year before discovery. For example, the hackers who stole more than 45 million credit card numbers in the infamous “TJ Maxx” breach of the TJX companies were reportedly in the company’s systems for 18 months, between July 2005 and December 2006, according to ComputerWorld.14
14. Jaikumar Vijayan, “TJX Data Breach: At 45.6M Card Numbers, It’s the Biggest Ever,” ComputerWorld, May 29, 2007, https://www.computerworld.com/article/2544306/security0/tjx-data-breach–at-45-6m-card-numbers–it-s-the-biggest-ever.html.
After Goodwill’s data breach was publicly exposed in 2015 by investigative journalist Brian Krebs, the nonprofit published a statement to customers indicating that “some Goodwill member store locations may have been affected by a data security issue” for more than 18 months. The stolen data included “payment card information—such as names, payment card numbers and expiration dates—of certain Goodwill customers.”15
15. Letter from Goodwill Industries International President and CEO Jim Gibbons, September 2, 2014, http://www.goodwill.org/wp-content/uploads/2014/09/Letter.pdf.
Even the U.S. federal government was the victim of long-running compromises. In June 2015, the U.S. Office of Personnel Management (OPM) publicly acknowledged a breach of at least four million personal records that reportedly started over a year earlier.16 “While the attack was eventually uncovered using the Department of Homeland Security’s (DHS) Einstein—the multibillion-dollar intrusion detection and prevention system that stands guard over much of the federal government’s Internet traffic—it managed to evade this detection entirely until another OPM breach spurred deeper examination.”17
16. David E. Sanger and Julie Hirschfield Davis, “Hacking Linked to China Exposes Millions of U.S. Workers,” New York Times, June 4, 2015, http://www.nytimes.com/2015/06/05/us/breach-in-a-federal-computer-system-exposes-personnel-data.html; Patricia Zengerle and Megan Cassella, “Millions More Americans Hit by Government Personnel Data Hack,” Reuters, July 9, 2015, https://www.reuters.com/article/us-cybersecurity-usa/millions-more-americans-hitby-government-personnel-data-hack-idUSKCN0PJ2M420150709.
17. Sean Gallagher, “Why the ‘Biggest Government Hack Ever’ Got Past the Feds,” Ars Technica, June 8, 2015, https://arstechnica.com/information-technology/2015/06/why-the-biggest-government-hack-ever-got-past-opmdhs-and-nsa/2.
Why can it take so long to discover a data breach? To the public, it may seem inconceivable that an attacker could walk out with a huge amount of data undetected, like a criminal walking out of a bank branch carrying sacks of cash in broad daylight. But cyber attacks are often less visible and far more pervasive.
For starters, consider the relative sizes of an organization’s attack surface in the physical world versus online. Your bank branch is designed to have a limited number of entrances and exits. For modern organizations, however, every employee who surfs the web or checks email represents a potential entry point for malware or an exit via which data may be lost or exfiltrated. The huge attack surface is overwhelming and difficult to monitor or control.
Technology has evolved to automate detection, and it helps—to a point. Organizations with a large enough budget can install cyber intrusion detection systems (IDS) on their networks and computers. These systems monitor for signs of malicious behavior and alert staff when issues are detected. “False positives,” where the IDS mistakenly classifies legitimate network traffic as suspicious, add to the noise and make more work for analysts. Conversely, “false negatives,” where the IDS fails to alert upon a suspicious event, can result in missed events, with devastating consequences.
Over the years, modern intrusion prevention systems (IPS) evolved to further reduce manual labor. These systems automatically stop suspicious activity, in addition to alerting. However, using an IPS introduces the risk that “false positives” may cause the system to block normal network traffic and therefore possibly interfere with the organization’s daily operations.
Malware itself is constantly evolving to avoid detection, with antivirus authors and IDS/IPS vendors struggling to keep up. Dedicated attackers may choose to space out data exfiltration over long periods of time—months or years—so that only a small amount of information is stolen each day. Attackers may also deliberately try to “blend in” with the organization’s normal traffic, disguising their activities as web traffic or similar common protocol, and paying careful attention to timing.
Once a breach triggers a cybersecurity system alert, staff need to respond. This can be a challenge, too, because often cybersecurity systems generate far more alerts than staff can handle (hundreds or even thousands for every security staff member each day). In these situations, the cybersecurity logs can represent a liability because the organization has a record of a potential breach but doesn’t have the resources to fully investigate or act on it. Even when the volume of alerts is reasonable, humans need to be available 24/7 to respond, which is often not possible given staffing constraints. Many organizations outsource monitoring to third-party managed service providers (usually a smart tactic), but not all organizations have the budget for this specialized service, and those that do may not have the resources to effectively oversee their vendors.
If a cybersecurity alert is reviewed by incident responders and declared an “incident,” then responders need to investigate and make decisions such as whether to clean malware off any affected systems and whether to notify any higher-ups or consult with legal counsel. Front-line staff members often make the call. If the staff member does not have enough training or experience, or if the organization’s incident response policies are unclear or simply not aligned with best practices, then sometimes signs of data breaches can be swept under the rug or misclassified internally without upper management ever knowing. Indeed, when internal IT staff discover evidence of a breach, they may be fearful of blame or simply not recognize the potential implications, and fail to report up the chain.
“Don’t expect . . . hackers to alert you to their presence,” explained Verizon in their 2018 Data Breach Investigations Report. “When [breaches] are discovered it is typically via external sources such as detection as a Common Point of Purchase (CPP) or by law enforcement.”18
18. Verizon, 2018 Data Breach Investigations Report, Verizon Enterprise, 2018, 28, https://enterprise.verizon.com/resources/reports/2018/DBIR_2018_Report.pdf.
1.1.5 Dark and Darker Breaches
Certain types of data are more likely to be noticed quickly when stolen or detected by third parties because of how the stolen data is used. Payment card information is immediately useful for fraud. When fraud occurs, this is quickly known—and often detected—by card associations such as Visa and Mastercard, issuing banks, or the affected person whose information was stolen.19 Investigative journalist Brian Krebs, who broke stories on the Target, Home Depot, and Wendy’s cardholder data breaches (to name a few), described how he found out about a 2016 breach involving the fast-food restaurant CiCi’s Pizza:20
19. Brian Krebs, “How Was Your Credit Card Stolen?” Krebs on Security, January 19, 2015, https://krebsonsecurity.com/2015/01/how-was-your-credit-card-stolen.
20. Brian Krebs, “Banks: Credit Card Breach at CiCi’s Pizza,” Krebs on Security, June 3, 2016, https://krebsonsecurity.com/2016/06/banks-credit-card-breach-at-cicis-pizza.
Over the past two months, KrebsOnSecurity has received inquiries from fraud fighters at more than a half-dozen financial institutions in the United States—all asking if I had any information about a possible credit card breach at CiCi’s. Every one of these banking industry sources said the same thing: They’d detected a pattern of fraud on cards that had all been used in the last few months at various CiCi’s Pizza locations.
The quick and widespread impact of a cardholder data breach, combined with the ability to pinpoint a common point of purchase, means that major breaches of cardholder data tend to be detected very quickly. This is not the case with, say, a breach of internal corporate document repositories.
Mandiant’s famous 2013 report, APT1: Exposing One of China’s Cyber Espionage Units, analyzed the activities of a hacking group it dubbed “APT1,” allegedly a unit of China’s People’s Liberation Army. Mandiant described how the hackers would “periodically revisit the victim’s network over several months or years and steal broad categories of intellectual property, including technology blueprints, proprietary manufacturing processes, test results, business plans, pricing documents, partnership agreements, and emails and contact lists from victim organizations’ leadership.” Rather than immediately monetizing this stolen data, the report claimed that the Chinese government used it for the purposes of gaining long-term economic advantages.21
21. Mandiant, APT1: Exposing One of China’s Cyber Espionage Units (Alexandria, VA: Mandiant, 2013) https://www.fireeye.com/content/dam/fireeye-www/services/pdfs/mandiant-apt1-report.pdf.
Data breaches of this type are hard to detect because unauthorized recipients of the stolen data can leverage it without revealing that the data was ever stolen.
The same can be true of personal data repositories, such as email accounts or documents stored in the cloud. Bloomberg reported that in the 2016 Yahoo breach, “[h]ackers may have accessed millions of Yahoo accounts for years undetected.”22 Consider for a moment: If your email account was hacked, would you know? Imagine if your username and password were stolen and sold to an organized crime group, which scraped your email account for any information of value. Criminals are all too happy to pay money for your SSN, financial details, and other data that can be used to commit fraud. Marketers will pay money for information about your health issues, marital problems, personal interests, etc. Background-check companies might pay money to know if you smoke pot or have employment issues. How would you even know that this information was stolen at all? If you did find out, how would you know it was stolen from your email account specifically?
22. Jordan Robertson, “Yahoo’s Data Breach: What to Do If Your Account Was Hacked,” Bloomberg, September 22, 2016, https://www.bloomberg.com/news/articles/2016-09-22/yahoo-s-data-breach-what-to-do-if-your-account-was-hacked.
Service providers, from IT companies to attorneys, may likewise never detect that customer records have been stolen. Nor do they necessarily have incentive to invest in effective detection systems. For many organizations, plausible deniability is the (perhaps unconsciously) chosen approach.
In January 2013, the Department of Health and Human Services issued an update to HIPAA that changed the definition of a “breach” and related notification requirements. Importantly, the change shifted the burden of proof. Now, “[a]n impermissible use or disclosure of protected health information is presumed to be a breach unless the covered entity or business associate, as applicable, demonstrates that there is a low probability that the protected health information has been compromised.” In other words, data stewards must presume that data has been breached unless there is evidence that indicates otherwise. This fundamental legal shift created incentives for affected organizations to implement effective logging and detection systems, so that they could prove when a breach did not happen and accurately determine the number of persons affected when a breach did occur.
This change applies specifically only to HIPAA; most breach notification laws do not yet include this shift in the required burden of proof. As a result, for many organizations, ignorance is still bliss.
1.2 Skewed Statistics
The public is hungry for information about data breaches. What industries are the most targeted? What are the latest causes? What will happen next year, and the year after? Journalists, in turn, gobble up reports on the topic and regurgitate them to the public. Any new whitepaper containing “trends” or “statistics” related to the topic is likely to receive a stream of publicity.
The result is a plethora of whitepapers published by corporations and nonprofits, ranging from vendors such as Symantec and Verizon, to the granddaddy Privacy Rights Clearinghouse (a nonprofit) to the Ponemon Institute (a for-profit LLC). Typically these whitepapers are based on public records of data breaches, surveys, or the internal data of corporations involved cybersecurity and breach response.
While journalists love to quote these whitepapers—especially the well-marketed ones—few, if any, are developed with the rigor of a peer-reviewed academic publication. How could they be, when information about data breaches is so limited? Due to the problem of “dark breaches,” there is inherent bias in every report. Only rarely is this mentioned in the media.
In this book, I often quote statistics or findings from public sources and some of the more reputable industry whitepapers. While these sources aren’t perfect, they are the best we’ve got at this stage in the development of data breach analysis. Whenever appropriate, I will call attention to inherent biases that likely influence the findings.
As a foundation, let’s take a moment to look at common ways that the sources of data and methodology used in these reports can affect the validity of their conclusions.
1.2.1 Public Records
It’s tempting to blindly trust studies that are based on public records of data breaches. Government agencies such as the Department of Health and Human Services (HHS) are required by the law to “post a list of breaches of unsecured protected health information”23 In addition, nonprofit organizations such as the Privacy Rights Clearinghouse (PRC) collect breaches reported through “government agencies or verifiable media sources” and make these lists available online.24
23. U.S. Department of Health and Human Services, “Cases Currently Under Investigation,” Office for Civil Rights, https://ocrportal.hhs.gov/ocr/breach/breach_report.jsf (accessed October 14, 2016).
24. Privacy Rights Clearinghouse, Chronology of Data Breaches: FAQs, https://www.privacyrights.org/chronology-data-breaches-faq#is-chronology-exhaustive-list (accessed October 14, 2016).
But of course, the mere fact that a breach has been publicized means that it is part of a skewed sample set. Once you recognize that published data breaches represent only a subset of the actual numbers (and likely a small one, at that), the inherent limitations of analyzing this data become clear.
As an example, let’s critically examine one of the top findings from cybersecurity company Trend Micro, whose 2015 report on data breaches is based exclusively on information from the Privacy Rights Clearinghouse database, which in turn is based on public reports of data breaches:25 “The healthcare sector was most affected by data breaches, followed by the government and retail sectors.”
25. Trend Micro, Follow the Data: Analyzing Breaches by Industry (San Diego: Privacy Rights Clearinghouse, 2015), https://www.trendmicro.de/cloud-content/us/pdfs/security-intelligence/white-papers/wp-analyzing-breaches-by-industry.pdf.
Media outlets have cited this finding left and right. DarkReading, a popular cybersecurity news outlet, released an article with the headline “Healthcare Biggest Offender in 10 Years of Data Breaches.”26 Fortune magazine reported, “Hackers love to attack the healthcare industry. . . . The healthcare industry leads the way as a hacking target, followed by government and retailers.”27
26. Sara Peters, “Healthcare Biggest Offender in 10 Years of Data Breaches,” DarkReading, September 22, 2015, http://www.darkreading.com/analytics/healthcare-biggest-o_ender-in-10-years-of-data-breaches/d/d-id/1322292.
27. Jonathan Vanian, “Five Things to Know to Avoid Getting Hacked,” Fortune, September 25, 2015, http://fortune.com/2015/09/25/five-facts-cyber-security.
But is it really true that the healthcare sector was most affected by data breaches—or does the healthcare industry simply report breaches more often? Certainly healthcare providers have more regulatory requirements relating to data breach notification compared with most other industries. The federal HIPAA/HITECH laws mandate that covered entities report data breaches affecting more than 500 persons to the public, and the Office for Civil Rights (OCR) conducts audits and fines entities that do not comply. Likewise, retail companies, by their nature, handle extensive volumes of payment card data, which is easy to detect when used fraudulently—likely resulting in a higher percentage of reported breaches than other types of data.
The Trend Micro report goes on to say: “An increase in the number of reported incidents strongly indicates that the total volume of data breaches has also risen and vice versa.”28
28. Trend Micro, Follow the Data.
This is a big assumption—and one that overlooks the impact of major changes in law, insurance coverage, regulation, and technology. In fact, a rise in the volume of detected and reported breaches can actually signify a good thing. Sure, higher numbers of reported breaches could signify a rise in actual breach occurrences—but this trend can also be caused by:
Improvements in detection systems
Breach notification laws that are increasingly aligned with public expectations of privacy
Effective third-party audits and systems to hold organizations accountable for breaches
Maturation of incident response processes and procedures
Growth of data breach insurance coverage options
Cybersecurity vendors have incentive to interpret the data as an increase in the number of actual data breaches that occur (“The sky is falling! Buy our product.”) In reality, we can only conclude that there has been an increase in the number of detected and reported data breaches within their sample set—an important distinction.
Another finding of the Trend Micro report was that29 “[l]ost or stolen physical devices, such as ‘portable drives, laptops, office computers, files, and other physical properties’ combined were the primary ‘breach [method] observed across industries.’”
29. Trend Micro, Follow the Data.
This generated a spate of news articles with headlines such as “More data breaches caused by lost devices than malware or hacking” (Network World)30 and statements like “Nearly half of all data breaches occur when ID-theft criminals access information because we lost a device” (AZWorld).31
30. Patrick Nelson, “More Data Breaches Caused by Lost Devices than Malware or Hacking, Trend Micro Says,” Network World, October 5, 2015, https://www.networkworld.com/article/2988643/security/device-loss-data-breach-malware-hacking-trend-micro-report.html.
31. Mark Pribish, “Lost Electronic Devices Can Lead to Data Breaches,” AZ Central, September 30, 2015, http://www.azcentral.com/story/money/business/tech/2015/09/30/lost-electronic-devices-data-breaches/73058138.
But is it really true that more data breaches were caused due to lost or stolen physical devices? All we really know is that there were more publicly reported data breaches of this type. An alternative: Could it be that stolen laptop incidents are more straightforward to detect and analyze than a sophisticated spyware infection, leading to higher reporting rates?
Again, cybersecurity vendors and media outlets have clear incentives to produce reports with strong, quotable conclusions, but readers have to take all of these findings with a grain of salt.
1.2.2 Raise Your Hand if You’ve Had a Data Breach
Due to the often-inaccessible nature of data breach statistics, many publications base their information on surveys. Unfortunately, surveys themselves contain inherent bias and flaws.
In a scathing 2011 report by Microsoft, two researchers ripped apart various survey-based cybercrime and identity theft reports, including the FTC’s Identity Theft Survey Reports, the Gartner Phishing Survey, and more.32 Microsoft’s researchers concluded, “Our assessment of the quality of cyber-crime surveys is harsh: they are so compromised and biased that no faith whatever can be placed in their findings . . . our cyber-crime survey estimates rely almost exclusively on unverified user input.”33
32. Dinei Florêncio and Cormac Herley, “Sex, Lies and Cyber-crime Surveys,” 10th Workshop on the Economics of Information Security, Fairfax, VA, 2011, https://web.archive.org/web/20110902055639/ http://weis2011.econinfosec.org/papers/Sex,%20Lies%20and%20Cyber-crime%20Surveys.pdf.
33. Florêncio and Herley, “Sex, Lies and Cyber-crime Surveys.”
1.2.3 Cybersecurity Vendor Data
You can’t throw a rock without hitting a whitepaper on data breaches or cybersecurity “threats” produced by a product or service vendor. Practically every major cybersecurity corporation has recognized the marketing value of coming up with such a report and releasing it for the media to spread. Often, these whitepapers are based on information generated by the vendor’s own security products or consulting team.
Over the years, some of these studies—such as Symantec’s Internet Security Threat Report (ISTR) and Verizon’s Data Breach Investigations Report (DBIR)—have developed into important industry resources with respected methodogies (although they still have limitations). Other vendors simply jump to conclusions. Let’s take a look at the evolution of these reports, so that we can better understand both the value and the inherent limitations.
One of the earliest cybersecurity reports was released by a groundbreaking but largely forgotten company called Riptech, Inc. Led by Chief Executive Officer (CEO) Amit Yoran (who later went on to become the president of RSA Security), Riptech was, in 2001, “the only provider of real-time managed security services” (at least according to the company’s own press release).34 In 2002, Riptech released a landmark paper: the Riptech Internet Security Threat Report (ISTR), which was eventually taken over by Symantec.
34. Business Wire, “Riptech Unveils Caltarian, a Next-Generation Managed Security Platform,” Free Library, April 2, 2001, http://www.thefreelibrary.com/Riptech+Unveils+Caltarian,+a+Next-Generation+Managed+Security...-a072584421.
The inauguaral Riptech ISTR was novel in that it represented the first time that a company engaged in managed security services had leveraged its own collection of data to produce a published report on cybersecurity attack trends. From the inaugural report:35
35. Riptech Inc., Riptech Internet Security Threat Report: Attack Trends for Q3 and Q4 2001 (Alexandria, VA: Riptech Inc., 2001), http://eval.symantec.com/mktginfo/enterprise/white_papers/ent-whitepaper_symantec_internet_security_threat_report_i.pdf.
Riptech analyzes data produced by numerous brands of firewalls and intrusion detection systems (IDSs) used by hundreds of clients throughout the world. Using a sophisticated combination of technology and human expertise to analyze this data, Riptech identifies and investigates cyber attacks that occur on client networks in real-time. A by-product of this daily investigation of Internet attacks is a vast amount of data on cyber threats that can be analyzed to reveal interesting and actionable trends. . . . We believe this study provides a uniquely accurate view of the state of Internet threats.
Riptech’s data set could not possibly represent an “accurate view” of the Internet as a whole. Its sample size was approximately 300 companies, more than 100 of which were apparently located in the same netblock, and all of which had taken the highly unusual action (for 2001) of engaging the services of a managed security services provider. However, it was a groundbreaking concept.
When Symantec purchased Riptech later that year, it continued to release the ISTR annually, over time adding Symantec’s growing pool of data sources.
By 2016, the Symantec Internet Security Threat Report was all grown up. Symantec stated that the threat data that it used for analysis came from the Symantec Global Intelligence Network, which consists of “more than 63.8 million attack sensors.”36 Of course, even this large sample set is still intrinsically biased, if only because the vast majority of the sources had engaged Symantec as a vendor. Nonetheless, the ISTR is widely considered to be one of the best resources for tracking data breach and cybersecurity trends.
36. Symantec, Internet Security Threat Report vol. 21 (Mountain View, CA: Symantec, April 2016), 4, https://www.symantec.com/content/dam/symantec/docs/reports/istr-21-2016-en.pdf.
Verizon has also emerged as a key player in data breach investigations and response, with the 2008 inaugural publication of the Verizon Data Breach Investigations Report (VBIR). According to this report, the Verizon Business Investigative Response Team handled “over 500 security breach and data compromise engagements between 2004 and 2007.” Staggeringly, the report claimed that Verizon’s case load represented “roughly one-third of all publicly disclosed data breaches in 2005 and a quarter of those in both 2006 and 2007 . . . [including] three of the five largest data breaches ever reported.”37
37. Wade H. Baker, C. David Hylender, and J. Andrew Valentine, 2008 Data Breach Investigations Report, Verizon Enterprise, 2008, http://www.verizonenterprise.com/resources/security/databreachreport.pdf.
In a notably artistic flourish, the first VBIR prominently highlighted a quote from William R. Maples (Dead Men Do Tell Tales):38
38. Baker, Hylender, and Valentine, “2008 Data Breach Investigations Report.”
That’s how I feel about the skeletons in my laboratory. These have tales to tell us, even though they are dead. It is up to me, the forensic anthropologist, to catch their mute cries and whispers, and to interpret them for the living.
Verizon itself was the first to note inherent bias in its data set, since the entire sample consisted of customers who had, obviously, engaged Verizon to investigate a suspected breach. This required a certain level of awareness of cybersecurity within the breached organization, as well as resources available to retain digital forensics and incident response experts.39
39. Baker, Hylender, and Valentine, “2008 Data Breach Investigations Report.”
The company continued to publish the VBIR each year, and as industry response teams diversified, Verizon partnered with a growing population of security companies and incident response teams to enlarge the sample size. To faciliate reporting and analysis of data breaches, Verizon developed the Vocabulary for Event Recording and Incident Sharing (VERIS), which is a publicly available “set of metrics designed to provide a common language for describing security incidents in a structured and repeatable manner.”40
40. VERIS: The Vocabulary for Event Recording and Incident Sharing, http://veriscommunity.net (accessed January 5, 2018).
By 2016, the data set was “made up of over 100,000 incidents, of which 3,141 were confirmed data breaches. Of these, 64,199 incidents and 2,260 breaches comprise the finalized dataset that was used in the analysis and figures throughout the report.”41 Certainly an enormous leap from the 500 breaches analyzed in 2008!
41. Verizon, 2016 Data Breach Investigations Report, Verizon Enterprise, 2016, 1, http://www.verizonenterprise.com/resources/reports/rp_DBIR_2016_Report_en_xg.pdf.
1.3 Why Report?
It’s tempting to ask the question, “Why aren’t data breaches reported?” but perhaps a better question is, “Why are breaches reported?”
Organizations that report data breaches suffer potentially devastating consequences, including reputational, operational, and financial impacts. For example, after Target announced its credit card data breach in 2014, its fourth-quarter profits dropped 46%, or $440 million.42 CEO Gregg Steinhafel resigned a few months later, in a move publicly linked to the breach.43
42. MarketWatch, “Target’s Profits Down $440M after Data Breach,” New York Post, February 26, 2014, https://nypost.com/2014/02/26/targets-profits-down-46-after-data-breach.
43. Antone Gonsalves, “Target CEO Resignation Highlights Cost of Security Blunders,” CSO Online, May 5, 2014, http://www.csoonline.com/article/2151381/cyber-attacks-espionage/target-ceo-resignation-highlights-cost-of-security-blunders.html.
Home Depot was hit with a painful consumer lawsuit after its data breach, which it finally settled in 2016 for $19.5 million. “The home improvement retailer will set up a $13 million fund to reimburse shoppers for out-of-pocket losses, and spend at least $6.5 million to fund 1-1/2 years of cardholder identity protection services.”44 After the security company RSA was hacked, its parent company, EMC, spent $66 million “on transaction monitoring for its corporate customers who worried that their RSA security tokens—long considered the gold-standard for protecting sensitive data—had been compromised in the attack.”45
44. Jonathan Stempel, “Home Depot Settles Consumer Lawsuit over Big 2014 Data Breach,” Reuters, March 8, 2016, http://www.reuters.com/article/us-home-depot-breach-settlement-idUSKCN0WA24Z.
45. Hayley Tsukayama, “Cyber Attack on RSA Cost EMC $66 Million,” Washington Post, July 26, 2011, https://www.washingtonpost.com/pb/blogs/post-tech/post/cyber-attack-on-rsa-cost-emc-66-million/2011/07/26/gIQA1ceKbI_blog.html.
Reputational impact is harder to quantify, but very real. A 2011 Ponemon Institute survey of 843 “senior-level individuals” found that the average “diminished value [of corporate brand] resulting from a data breach of customer data” was 21%. If the breach affected only employee data, the diminshed value of the brand was only 12%.46
46. Ponemon Institute LLC, Reputation Impact of a Data Breach: U.S. Study of Executives and Managers (Research Report Sponsored by Experian, November 2011), https://www.experian.com/assets/data-breach/white-papers/reputation-study.pdf.
Data breaches can also have more formal reputational effects. For example, Standard & Poor issued a report in 2015 warning that lenders that suffered data breaches could have their ratings downgraded.47
47. Roi Perez, “S&P Could Downgrade Lenders to Standard and Poor for Cyber-Security,” SC Media UK, October 1, 2015, http://www.scmagazineuk.com/standard-and-poor-to-downgrade-banks-credit-rating/article/441892.
The operational impacts of a data breach can cause direct losses and brand damage, as well. In 2014, Forbes and IBM released a joint study showing how business disruptions—caused in part by data breaches—can have deep and lasting consequences for businesses. As summarized by Forbes:48
48. Hugo Moreno, “Protecting Your Company’s Reputation in a Heartbleed World,” Forbes, April 14, 2014, https://www.forbes.com/forbesinsights/ibm_reputational_IT_risk/index.html.
Lost revenues, downtime and the cost of restoring systems can accrue at the rate of $50,000 per minute for a minor disruption. . . . But what about the greater toll a sustained outage or major security breach can take on a company’s reputation?
. . . If customers can’t log on to your site, you not only lose a sale today, but you also risk losing future business, particularly for retailers. For financial institutions, a security breach can scare away customers and open the door to fraud. A network outage for any telecom or IT company may leave clients wondering why they should trust their own reputation to a vendor who might make them look incompetent.
With all of these negative pressures, and absent clear laws that require reporting or even a clear definition of a “breach,” why do organizations report data breaches at all?
Data breaches are typically reported to the public for one of three reasons:
The data breach is already public or likely to become public. If you look at most data breach reports that hit the news, you’ll notice that they are often first reported by an investigative journalist or involve sensitive information that has been publicly leaked. The affected organizations reported because, well, it’s already out there. When investigative journalist Brian Krebs found Home Depot’s customer credit card information for sale on the “dark web” in 2014 and published an article about it, Home Depot had little choice but to immediately issue a public statement.
There is a clear legal requirement to report, and harm to the organization (such as fines) would occur if the breach improperly went unreported. For example, the OCR has the ability to impose fines, as well as civil or criminal charges, due to HIPAA violations (which include data breach reporting requirements). That doesn’t mean the breached organization will notify the public; it just means it has more incentive to do so than in other cases where HIPAA does not apply.
The information leaked is at high risk of being misused and the breached organization may be liable for damage. For example, LastPass, an online password storage application, issued a statement in 2015 notifying users of a breach and encouraging them to “change their master passwords.”49
49. Joe Siegrist, “LastPass Security Notice,” LastPass, June 15, 2015, https://blog.lastpass.com/2015/06/lastpass-security-notice.html.
Absent one of these motivating factors, there are few (if any) incentives for organizations to publicly disclose the data breach.
Even when breaches are reported to the public, often key details are left out. Symantec highlighted incomplete reporting as a critical issue in the 2016 ISTR:50
50. Symantec, “2016 Internet Security Threat Report,” ISTR 21 (April 2016): 6, https://www.symantec.com/content/dam/symantec/docs/reports/istr-21-2016-en.pdf.
[M]ore and more companies chose not to reveal the full extent of the breaches they experienced. Companies choosing not to report the number of records lost increased by 85 percent. . . . The fact that companies are increasingly choosing to hold back critical details after a breach is a disturbing trend. Transparency is critical to security. While numerous data sharing initiatives are underway in the security industry, helping all of us improve our security products and postures, some of this data is getting harder to collect.
1.4 What’s Left Unsaid
Who knows what data breaches are happening right now, which we will only hear about in the years to come? The public is flooded with news reports about breaches every day—but oceans more are never reported. Organizations that detect breaches are faced with an ethical dilemma, in that there is no clear “right” path, and those that disclose may suffer far more than those that keep things quiet. This very fact prevents us from even knowing the true extent of the problem.
Even the very definition of a “data breach” is up for debate. How can we effectively respond to something when we can’t even agree on exactly what it is?
As a society, we have a lot of work to do. It doesn’t benefit anyone if a data breach destroys an organization or sucks resources away that it could have used to support jobs or provide better services to customers. In the years to come, we need to come to a consensus on a definition of “data breach,” figure out how to gather data, and develop accurate models. We need more transparency, so that we can analyze the impact of data breaches and identify effective strategies for reducing harm.
We have to decide what we, as a society, want organizations to do in the event of a data breach. Then we have to clearly define that through law, industry standards, and guidelines, and give breached organizations incentives to do the right thing.
Since ancient times of computing (the 1970s), breached organizations have wrestled with the same problems, time and time again. Even the earliest breach cases share many similarities with those we see today. In the next chapters, we’ll examine some of the earliest data breaches, see what we can learn, and introduce a new, modern methodology for managing data breach response.