13.1.1 Security Flaws

Cloud providers work hard to project an image of invincibility since customers naturally seek to host their data in a secure place. However, cloud providers suffer from vulnerabilities and data breaches, just like other organizations. These can occur because of bugs in software developed by the cloud provider, issues involving third-party applications, or staff errors.

For example, the Dropbox file sharing service, used by millions of people around the world, has suffered a string of highly publicized security issues that may have resulted in data breaches. In 2011, Dropbox pushed out a code update that accidentally removed authentication requirements for customer accounts—meaning anyone could access customers’ sensitive data, even without a correct password. Customer data was exposed for nearly four hours before Dropbox implemented a fix.²²

22. Ed Bott, “Why I Switched from Dropbox to Windows Live Mesh,” ZDNet, July 4, 2011, https://www.zdnet.com/article/why-i-switched-from-dropbox-to-windows-live-mesh/; Arash Ferdowsi, “Yesterday’s Authentication Bug,” Dropbox Blog, June 20, 2011, https://web.archive.org/web/20110718041143/ http://blog.dropbox.com/?p=821.

The following year, Dropbox customers sounded an alarm when they began receiving targeted spam messages to email addresses that, in some cases, they had created exclusively for use with Dropbox.²³ Dropbox investigated and announced that an employee’s password had been stolen and used by attackers to access a document containing customer email addresses.

23. Ed Bott, “Dropbox Gets Hacked . . . Again,” ZDNet, August 1, 2012, https://www.zdnet.com/article/dropbox-gets-hacked-again/; Emil Protalinski, “Dropbox Finds No Intrusions, Continues Spam Investigation,” ZDNet, July 20, 2012, https://www.zdnet.com/article/dropbox-finds-no-intrusions-continues-spam-investigation/.

Reportedly, the Dropbox employee had reused a password on his or her LinkedIn account and work account. After LinkedIn was breached, criminals used the employee’s stolen LinkedIn password to log in to the employee’s work account, too—neatly illustrating how breaches can lead to more breaches.²⁴ The events triggered scrutiny of Dropbox’s internal security and password management practices. In response, Dropbox announced that it was introducing two-factor authentication as an option for customers, in addition to other security measures.

24. Samuel Gibbs, “Dropbox Hack Leads to Leaking of 68m User Passwords on the Internet,” Guardian, August 31, 2016, https://www.theguardian.com/technology/2016/aug/31/dropbox-hack-passwords-68m-data-breach.

Four years later, the other shoe dropped. In 2016, cybercriminals on the dark web were found peddling a database containing 68 million Dropbox user passwords. Dropbox sent an understated message to customers, explaining that “we learned about an old set of Dropbox user credentials (email addresses plus hashed and salted passwords) that we believe were obtained in 2012. Our analysis suggests that the credentials relate to an incident we disclosed around that time.” Never mind that four years had gone by, and Dropbox had never previously indicated that any customer passwords could have been stolen. Now, Dropbox confidently declared that “[b]ased on our threat monitoring and the way we secure passwords, we don’t believe that any accounts have been improperly accessed”—although the company offered no evidence to support that claim.²⁵

25. Joseph Cox, “Hackers Stole Account Details for Over 60 Million Dropbox Users,” Motherboard, August 30, 2016, https://motherboard.vice.com/en_us/article/nz74qb/hackers-stole-over-60-million-dropbox-accounts.

Third-party software can also lead to cloud data breaches. For example, in 2016, a WordPress plug-in known as Custom Content Type Manager began stealing admin credentials after an update installed a malicious backdoor. Similarly, in 2018, a popular website accessibility plug-in called Browsealoud was infected and used to install a cryptocurrency miner on thousands of U.S. and U.K. websites. The plug-in’s developer, Texthelp, said it was the victim of a “cyber attack,” illustrating how a single vulnerable product can lead to widespread, cascading compromises in the modern software ecosystem.²⁶

26. Matt Burgess, “UK Government Websites Were Caught Cryptomining. But It Could Have Been a Lot Worse,” Wired, February 12, 2018, https://www.wired.co.uk/article/browsealoud-ico-texthelp-cryptomining-howcryptomining-work.

13.1.2 Permission Errors

When data is already up in the cloud, a checkbox can make the difference between proper security and a serious data breach. Too many unfortunate system administrators have experienced the sudden heart palpitations that come with the discovery that sensitive data was indexed on Google or found by an unusually inquisitive web visitor—often due to a simple permissions error.

For example, beginning in 2017, a series of data breaches involving Amazon S3 buckets (a type of data repository) was reported by security researcher Chris Vickery of UpGuard. Dow Jones exposed personal data of 2.2 million customers. An analytics firm working on behalf of the Republican National Committee exposed personal details relating to 198 million Americans. Booz Allen exposed more than 60,000 files containing highly sensitive data, including cleartext passwords used by contractors with Top Secret Facility clearances. The consulting firm Accenture exposed four buckets containing “highly sensitive data,” including passwords relating to the cloud accounts of major customers. The list went on and on.

The breaches occurred because, in each case, someone had put sensitive data in an Amazon bucket that was accessible to the public—or, somewhere along the way, someone mistakenly unchecked the checkbox that limited access. The problem was rampant; security firm Skyhigh Networks estimated that 7% of all Amazon S3 buckets were publicly accessible.²⁷

27. Catalin Cimpanu, “7% of All Amazon S3 Servers Are Exposed, Explaining Recent Surge of Data Leaks,” BleepingComputer, September 25, 2017, https://www.bleepingcomputer.com/news/security/7-percent-of-all-amazons3-servers-are-exposed-explaining-recent-surge-of-data-leaks/.

Breaches of this type are often discovered and reported by members of the public. It’s easy to check to see whether an Amazon bucket is public simply by typing the name of the bucket into the address bar of your web browser, as part of a URL. In recent years, plenty of open-source tools have emerged to quickly enumerate public buckets and check their contents. Once reported, the first step is to remove the unauthorized access as quickly as possible. If access logs exist, investigators can analyze them to determine whether the data was actually accessed by an unauthorized party. Granular log data can enable investigators to rule out a breach. However, often access logs are not collected in the first place, or if they are, the logs go back for only a short period. Response teams need to collect and preserve cloud access logs as quickly as possible in these types of cases, in order to maximize the chances of ruling out a breach.

In many cases, third-party service providers are responsible for the error—but the contracting organization still bears the brunt of the reputational damage. For example, Scottrade Bank suffered an embarrassing data breach after a third-party vendor, Genpact, left 20,000 customer records in a public Amazon S3 bucket.²⁸ In a similar case, Verizon was shamed in a July 2017 breach announcement after one of its suppliers, NICE Systems, accidentally left 14 million customers’ personal information sitting in a publicly accessible Amazon S3 bucket. The customer data included names, phone numbers, account details, and PINs.

28. Steve Ragan, “Scottrade Bank Data Breach Exposes 20,000 Customer Records,” CSO, April 5, 2017, http://www.csoonline.com/article/3187480/security/scottrade-bank-data-breach-exposes-20000-customer-records.html (accessed February 19,2 019).

For responders, the involvement of a third party can dramatically complicate breach response. For one thing, your organization may not have direct access to the misconfigured cloud account, leading to delays in containment. This can also cause delays in evidence preservation, which can result in lost evidence and make it harder to “rule out” a breach.

13.1.3 Lack of Control

One of the most common (and least-detected) forms of a data breach is when employees upload sensitive documents to their personal email or cloud accounts. Often, they do this for well-meaning purposes, in order to work remotely or share files with collaborators, not realizing that this can lead to serious security problems. Once the employee hits “send,” the data is functionally outside the organization’s control. It may be analyzed by third-party cloud providers, stolen by undetected hackers, stored on the employee’s home computer, or improperly tossed away.

Simply uploading files to the wrong cloud provider may trigger a data breach, depending on the type of data and the legal framework that applies. This is because cloud providers may routinely access user data, sell or share data with third parties, or even create derivative data products. Meanwhile, unknowing users may blithely upload regulated data, expecting it to be private, without understanding the consequences.

For example, Oregon Health & Science University (OHSU) was hit with a record $2.7 million fine that was due in part to improper use of the cloud. In 2013, a faculty member discovered that physicians-in-training had uploaded a spreadsheet of patient data to Google, in order to “provide each other up-to-date information about who was admitted to the hospital under the care of their division.”²⁹ Despite the residents’ best intentions, the outcome wasn’t good. The hospital launched an investigation that uncovered another, similar practice in a different department, and ultimately discovered that more than 3,000 patients’ information had been uploaded to the cloud without authorization.

29. Oregon Health & Science University, “OHSU Notifies Patients of ‘Cloud’ Health Information Storage,” July 28, 2013, https://www.ohsu.edu/xd/about/news_events/news/2013/07-28-ohsu-notifies-patients-o.cfm.

At the time, Google’s general terms of service included the following statement:³⁰

30. “Terms of Service,” Google, March 1, 2012, https://www.google.com/intl/en_US/policies/terms/archive/20120301/.

When you upload or otherwise submit content to our Services, you give Google (and those we work with) a worldwide license to use, host, store, reproduce, modify, create derivative works . . . communicate, publish, publicly perform, publicly display and distribute such content. The rights you grant in this license are for the limited purpose of operating, promoting, and improving our Services, and to develop new ones. This license continues even if you stop using our Services.

OHSU’s representatives attempted to confirm that Google would not use the data in the ways they described, but they were unsuccessful. Absent the ability to rule out unauthorized use, OHSU notified the public and the Department of Health and Human Services. Later, the Office for Civil Rights conducted an investigation and concluded that there was “significant risk of harm to 1,361 of these individuals due to the sensitive nature of their diagnoses.”³¹

31. U.S. Department of Health and Human Services, Office for Civil Rights, “Breach Portal: Notice to the Secretary of HHS Breach of Unsecured Protected Health Information,” July 28, 2013, https://ocrportal.hhs.gov/ocr/breach/breach_report.jsf; U.S. Department of Health and Human Services, Office for Civil Rights, “Widespread HIPAA Vulnerabilities Result in $2.7 Million Settlement with Oregon Health & Science University,” July 18, 2016, https://web.archive.org/web/20160813124846/ https://www.hhs.gov/about/news/2016/07/18/widespread-hipaa-vulnerabilities-result-in-settlement-with-oregon-health-science-university.html.

Google, of course, is not alone in its approach to analyzing and leveraging user-uploaded data. Nor were the hospital physicians-in-training at all unusual: Many dedicated employees decide, independently, to upload work data to the cloud in order to facilitate collaboration with peers or work from home. Unfortunately, when it comes to the cloud, employees’ good intentions can cause big problems.

Controlling cloud use is difficult, particularly in complex environments such as hospitals and academia. Users crave the convenience of the cloud. Absent strong technical controls or safe alternatives, employees may unwittingly perpetuate data breaches.

13.1.4 Authentication Issues

All too often, the easiest way for criminals to break into cloud accounts is right through the front door, leveraging stolen passwords or other authentication weaknesses. In recent years, password theft has become a widespread epidemic, leading to countless data breaches. In 2017, Verizon reported that fully 81% of hacking-related breaches leveraged weak or stolen passwords.³² This isn’t surprising, given the shocking number of passwords that have been exposed in previous breaches, and the sophistication of cybercriminals’ password-stealing tools.

32. “Verizon’s 2017 Data Breach Investigations Report,” Verizon Enterprise, 2017, http://www.verizonenterprise.com/resources/reports/rp_DBIR_2017_Report_en_xg.pdf.

In a 2017 report, Google researchers revealed that they had found 1.4 billion unique username and password combinations available on the dark web in a one-year period. The vast majority of these credentials were exposed in a data breach of a cloud service, such as MySpace, LinkedIn, or Dropbox. The researchers also found that criminals collected, on average, 234,887 credentials every week using phishing toolkits, and 14,879 credentials per week using keystroke loggers.

While that may sound like a lot of stolen passwords, it was undoubtedly just a subset of the total. “We emphasize our dataset is strictly a sample of underground activity,” the researchers wrote, “yet even our sample demonstrates the massive scale of credential theft occurring in the wild.”³³ By October 2017, Yahoo announced that 3 billion customer accounts had been affected by a data breach—a single provider whose exposed accounts dwarfed those reported in Google’s study.³⁴

33. Kurt Thomas et al., Data Breaches, Phishing, or Malware? Understanding the Risks of Stolen Credentials (research paper, Google, Mountain View, CA, 2017), https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/46437.pdf.

34. Nicole Perlroth, “All 3 Billion Yahoo Accounts Were Affected by 2013 Attack,” New York Times, October 3, 2017, https://www.nytimes.com/2017/10/03/technology/yahoo-hack-3-billion-users.html.

Stolen passwords are bought and sold (or sometimes just given away!) by criminals on the dark web, who use them to compromise victims’ accounts, often to commit financial fraud or steal more data. The damage caused by stolen passwords is vastly amplified because of the fact that many people reuse passwords (sometimes with minor variations) for multiple accounts. Cybercriminals now routinely conduct “credential stuffing” attacks, taking lists of exposed credentials and automatically trying them on other websites in order to break into more accounts.

Two-factor authentication (2FA) can dramatically reduce the risk of account breaches, by requiring a second method of identity verification so that passwords alone cannot give a criminal access to your account. However, only an estimated 28% of people used two-factor authentication by late 2017, accounting to Duo Labs’ State of the Auth report.³⁵ Those that do use 2FA often rely on a weak second factor, such as a PIN sent through SMS (text message), which can be intercepted or captured. Users that input a code from an application or device as their second factor can also be tricked into entering it into a phishing site, allowing criminals to access the victim’s account in real time.

35. Olabode Anise and Kyle Lady, State of the Auth (Duo Labs Report, 2017), 5, https://duo.com/assets/ebooks/state-of-the-auth.pdf.

13.2.1 Business Email Compromise (BEC)

Email account break-ins seem to happen as often as the common cold—and often, users shrug them off. Business emails contain valuable data, such as banking details, SSNs, passwords, credit card numbers, and other details that can be sold on the dark web or used for fraud. Criminals that hack into email accounts find a wealth of valuable data, ready to be harvested.

Over the years, it became easier and easier for criminals to break in to email accounts. With the emergence of Microsoft Office 365 and other high-quality, cloud-based enterprise platforms, businesses of all sizes shifted to cloud-based email services, enabling users (and criminals) to access their inboxes from anywhere in the world. Between the rampant theft of passwords and the success of targeted phishing attacks, cybercriminals groups found that email was an easy target.

Organized crime groups soon developed repeatable, scalable methods for breaking into email and committing financial fraud. “[S]cammers have been using sophisticated email campaigns to defraud businesses of all sizes through the use of fake invoices, wire transfers, and international payment requests,” reported Duo Security in July 2018. “The scams often rely on compromised email accounts inside a target organization, and the operations are growing at a terrific rate, with losses in the United States alone of nearly $3 billion in the last 18 months.”³⁸ Globally, more than $12 billion was lost due to email account compromises in the same time period.³⁹

38. Dennis Fisher, “The Rise and Rise of Business Email Compromise Scams,” Decipher, Duo Security, July 16, 2018, https://duo.com/decipher/the-rise-and-rise-of-business-email-compromise-scams.

39. Federal Bureau of Investigation, “Public Service Announcement: Alert Number I-071218-PSA,” July 12, 2018, https://www.ic3.gov/media/2018/180712.aspx.

Office 365 accounts have been particularly targeted. This makes sense given the popularity of the cloud solution. By 2018, Office 365 was widely recognized as the leading cloud office software provider, when a global survey of 135,000 corporate domains showed that it had achieved 56.3% market share⁴⁰—well above that of the second leading provider, G Suite. As a result, many criminals fine-tuned their scams to take advantage of Office 365 features, designing phishing landing pages that mimicked the service’s login pages and modifying the configuration of compromised user accounts in order to better hide their tracks.

40. Bitglass, “Cloud Adoption: 2018 War,” p. 4, https://pages.bitglass.com/rs/418-ZAL-815/images/Bitglass_Cloud_Adoption_2018.pdf

In one common scam, an attacker hacks into a victim’s email account and searches for references to an upcoming transaction (such as invoices or wire transfer instructions). Then, the attacker creates a spoofed invoice or wire transfer notification and sends an email requesting that the funds be transferred to the new location. Typically, the attacker’s email is very similar to a real party in the communication, and because it is sent in the context of an existing transaction, the recipient often does not detect the scam until the money is gone and it is too late. Sophisticated criminals add mail filtering rules that send the real recipient’s messages to the system archives, further lengthening the time to discovery.

Once criminals break into an email account, they often make a point of targeting related accounts, such as coworkers, clients, or anyone listed as a contact. In many cases, criminals download entire accounts of correspondence in order to mine the data offline.

13.2.2 Evidence Acquisition

Access to evidence is critical for BEC cases in order to rule out a data breach. Absent evidence, organizations face a tough choice; they can either:

1. Notify a broad group, which may result in overnotification and unnecessary financial, reputational, or legal damage, or

2. Refrain from notification, and risk costly fines and public outrage if the breach is later discovered and confirmed.

For BEC cases, useful evidence normally includes:

• Login events, including date, time, duration, IP address, and browser type

• Search events, logged by session ID and tied to user account accesses

• All email activity, including read events, duration of message views, cration, delivery, etc.

• Attachment view events

Unfortunately, cloud email providers rarely provide the same depth and variety of log data that is available from well-instrumented on-premises installations. In many cases, granular log data is not collected in the first place or, if it is, getting it from the cloud provider may require extensive conversations or legal action—and even then, the response team may not be successful.

Challenges for cloud-based evidence acquisition include:

• Lack of logs - The cloud provider simply may not be logging activities needed for resolving potential data breaches. Even when a cloud provider does have logs, it is typically just authentication or application logs, and not the full depth of activity logs that could be available from a local enterprise environment.

• Limited or inconsistent export capabilities - Cloud providers may cap or throttle the amount of log data that can be exported at a time, slowing investigations or causing errors.

• High costs for log export - There can be a cost to export data from the cloud, and log data is no exception. Unfortunately, the cost of exporting logs is typically not built into the budget (or even considered) when migrating to a cloud provider.

• Changing log format - Cloud providers can (and do) change the format of their logs at any time. This can create special challenges for investigators, who require a standard format to parse data in bulk.

• Lack of documentation - Investigators need to understand the meaning of important fields in logs, but all too often the format of log data is not well documented or existing documentation is outdated/incorrect.

Since Office 365 has been particularly targeted, many investigators find themselves gathering evidence from Microsoft’s native cloud logging system or on the phone with Microsoft support teams. However, until early 2019, granular logging for mailbox activities was not enabled by default in Office 365. That meant that many organizations suffered a breach, only to discover that they did not have the evidence they needed to rule anything out. Even for organizations that wanted to implement logging, many did not realize that mailbox logs had to be enabled in two different places, and when it was turned on, the evidence produced was of limited value in BEC investigations.

In 2019, after the saga of the “Magic Unicorn Tool” played out in the public eye, Microsoft implemented default logging of mailbox activities for all new corporate accounts. More logs were available for higher-tiered customers, but a basic level of logging was stored for all corporate users, greatly facilitating investigations.

13.2.3 Ethics

The saga of the Magic Unicorn Tool raises important ethical questions for breach responders, forensic analysts, and the broader cybersecurity community. Below are a few such questions.

• What is the responsibility of cloud providers to support forensic investigations?

Data breaches involving cloud accounts are inevitable, much like fires in a city. When a data breach happens, however, customers may not have access to the information they need to detect, contain, or investigate the crisis. Forensics evidence is critical for detecting and resolving data breaches. Yet all too often, cloud providers do not make it available to customers, or if they do, it comes with a hefty price tag that many cannot afford. Customers often do not realize that by moving to the cloud, they will lose easy access to critical log data that is readily accessible from on-premises software installations—until it is too late.

As a result, many organizations do not have the visibility to support early detection of data breaches in the cloud. When they get hacked, they end up over- or under-notifying since they do not have the detailed evidence to fully understand what occurred. This is an especially challenging issue for cash-strapped organizations, which cannot justify paying a premium for logs.

Like fires, data breaches don’t just damage individuals. The impact extends to the wider community. For example, when an email account is hacked and thousands of people’s stolen personal records are used to commit fraud, the impact can spread to financial institutions, merchants, insurers, and ultimately the customers they serve. When a million cloud account passwords are stolen, fraudsters use these as ammunition to break into innumerable other accounts, such as bank accounts, medical portals, e-commerce sites, and more, causing far-reaching consequences. Any individuals or other organizations with potentially compromised sensitive information may experience follow-on attacks, fraud, extortion, or other negative consequences as a direct result of a breach.

There are ways to reduce the risk of fire, to contain it, and to prevent it from spreading. Society has collectively invested in fire mitigation and developed prevention and response tactics using community resources. Healthy cities have effective fire prevention strategies built into building code, as well as fast alerting and response systems. Fire hydrants with standardized measurements are installed throughout the city to ensure that responders have access to the water they need, wherever they are. Building elevators are fitted with fire keys that are distributed to responders in advance of an emergency. All of these are measures that most individual organizations could never implement alone.

Similarly, there are ways that society can reduce the risks associated with data breaches. If an appropriate level of logs were readily available to customers of any cloud platform, then data breaches could be detected more quickly, and the investigations would be far more effective, reducing risk for all.

There are many reasons that cloud providers do not make log data available to customers. Collecting, maintaining, and delivering log data is a cost. There are the costs of configuring their systems to generate logs in the first place. There are costs associated with storage: hardware, software licensing, power, etc. There are the costs to develop an interface for customers to retrieve the data. There are the human resources costs involved in supporting the delivery of log data. Customers typically do not include logging as a top selection factor. In short, there is currenly little incentive for cloud providers to invest in forensic log data collection and production because the increased costs, if passed along to the customer, would simply make them less competitive.

Once again, there are parallels in fire management. For example, fire suppression systems and other physical safety mechanisms are a cost for building owners. Imagine if landlords offered fire suppression systems only as an option (not a requirement) and charged tenants an extra fee to install and maintain them! Many of the poorest and most vulnerable tenants would choose to save the money and take the risk, leading to more fires and ultimately costing the larger community. This is essentially what is happening with cloud service log data today.

Today, Microsoft has finally enabled Office 365 logging by default, after extensive pressure from customers, insurers, attorneys, and others. Customers don’t get all the logs for free; those that are willing to pay a premium get more data about their environment and a longer retention time. Still, Microsoft’s decision to make a minimum set of logs available by default for all corporate customers is an enormous step forward, and one for which the tech giant should be commended.

Cloud breach detection and response is a team effort, which necessarily requires support from the cloud providers themselves. Like landlords, cloud providers are in the unique position of controlling the infrastructure. They can decide what type and quantity of evidence will be made available to customers. In order to reduce risk, all cloud providers need to make an appropriate amount of logging available to customers by default. If this became standard practice, it would increase early detection and improve the speed and accuracy of investigations for everyone.

The cloud provides an incredible opportunity to centralize and standardize logging and breach response tactics and trained personnel. To take advantage of this and reduce risk, cloud providers and their customers need to join together, develop standardized methods for accessing logs and other critical resources, and ensure that responders have the resources they need quickly and efficiently.

• Should “unauthorized” sources of evidence be used to determine whether a data breach has occurred?

By all accounts, the secret Activities API was not designed for forensic purposes. Even after the Magic Unicorn Tool was revealed, Microsoft’s staff insisted that the data was “not a forensically sound data source” during conversations with customers and breach responders. “The info there is accurate,” stated one Microsoft specialist, “but some records may be missing because they are back-end logs used for a different purpose.”⁴² If there is a possibility that some records are missing, investigators cannot reliably use the data as a method for ruling out unauthorized access to sensitive data. Yet forensics firms have long touted the secret Microsoft API as a reliable log source, attorneys have made decisions based on the output, and insurers paid for their work. In cases where cloud providers cannot or will not confirm that a source of data is accurate or complete, response teams should be extremely cautious about using the data as a basis for drawing conclusions.

42. Direct conversation between the author and representatives from the Microsoft’s Global Incident Response and Recovery Team and the Diagnostics and Recovery Toolset (DaRT) group, February 2019.

• What standards should forensics professionals hold themselves to for disclosure of “zero-day forensic artifacts”? What responsibility do attorneys, insurers, and other trusted providers have for circulating and disseminating critical information?

In cybersecurity, a “zero-day vulnerability” is a vulnerability that defenders do not yet know about. “Zero-day” refers to the number of days that defenders (such as software manufacturers or enterprise security professionals) have had to mitigate the vulnerability. Publicly disclosing a zero-day vulnerability can place innocent organizations at great risk since attackers can immediately begin exploiting the vulnerability, while defenders have had no time to fix it. Over the years, there has been extensive debate about the ethics of vulnerability disclosure, and it is generally considered good ethical practice to notify software manufacturers and other defenders privately first, to give them time to fix the problem, prior to disclosing the issue to the world.

“Zero-day forensic artifacts” are a newer concept. The term refers to forensic artifacts that are not publicly known, such as Microsoft’s Activities API. In some cases, the organization producing the evidence may not even be aware that it exists. Forensic artifacts are critical for investigating data breaches and other cases involving digital evidence. The more forensic artifacts exist and the more granular their data, the more likely it is that investigators will be able to reach correct and complete conclusions.

In the case of the Magic Unicorn Tool, only a handful of forensic analysts knew about the secret source of evidence. Its very existence was kept hidden by several respected forensics firms, as well as Microsoft itself, for well over a year by several accounts. (Many individual Microsoft employees appear to have been genuinely unaware of this data’s existence.) Those that were in the know believed that they had greater ability to resolve data security breaches and could “rule out” access to data that others could not, therefore reducing or even eliminating the risk of overnotification for their clients. They were able to charge a premium for access to the secret API, greatly bolstering their revenue. Over the years, they engaged in a concerted effort to hide the existence of the secret API, in order to prevent other firms from similarly obtaining the data, and also out of fear that Microsoft might shut down direct access if it became publicly known (which Microsoft did).

While this was going on, countless organizations that did not have access to the information (and did not even know it existed) were forced to make decisions based on incomplete information, resulting in unnecessary risk not just for their own organizations but for the affected data subjects.

Clearly, withholding critical information from data breach victims and the forensics community was harmful. Many organizations over- or underreported due to lack of evidence, when the evidence may have actually existed—they just didn’t know it. Since BEC cases were a huge epidemic, there were economic consequences as well. Forensics firms and attorneys that did not have access to the secret tool were inexplicably cut out of the market, hurting small firms in particular. In the meantime, the firms with access to the secret tool raised prices, in some cases gouging customers and insurers that had no other options.

After the fact, many questions remain about the completeness and accuracy of the secret data, particularly since Microsoft’s team itself has repeatedly stated that it was not designed for forensics purposes. Secret sources of evidence cannot be vetted by the broader forensics community, raising the risk of omissions, misinterpretations, and errors in investigations.

There are clearly many benefits to encouraging transparency in forensics artifact disclosure, much like vulnerability disclosure. By sharing information about forensic artifacts, they can be vetted by the wider community and made available to all data breach victims that need them. Transparency also creates a healthy, competitive market, ensuring that forensics firms and attorneys are hired based on the quality of their service, at reasonable, fair prices. Finally, transparency ensures that cloud providers themselves are in the loop and can speak to the quality of their own data sources.

13.3.1 The Beauty of End-to-End Encryption

End-to-end encryption is a perfect example. True end-to-end encryption renders data inaccessible to anyone except the person who holds the key. This is a very powerful tool for cloud security. Theoretically, it is possible for users to upload data to the cloud, while ensuring that no one—not even the cloud provider—can read the data. To accomplish this, the decryption key would be stored on a device that is controlled by the user or the organization’s IT team, and not the cloud provider. (For maximum security, it can even be stored on physical removable media such as a Yubikey.)

BEC cases, in particular, could be dramatically reduced if end-to-end email encryption were widely and correctly deployed. Imagine: Even if an attacker broke into an email account, only the message headers (such as sender, recipent, and subject line) would be legible. The contents would be inaccessible without the decryption key. (This is accomplished using public key cryptography, discussed in depth in Chapter 5, “Stolen Data.”) There would be no need for responders to worry about which emails were read or comb the messages for spreadsheets containing PHI, tax returns, or SSNs. As long as the decryption key was stored separately, none of the message contents could be read by a third party.

If John Podesta had used end-to-end email encryption, the contents of his messages would have been unreadable, and the Clinton campaign megaleak would not have occurred. If the Oregon Health and Science residents had used end-to-end encryption to protect their spreadsheet prior to uploading it to Google, patient medical information would not have been exposed. If Booz Allen had used end-to-end encryption for data in its Amazon S3 buckets, it wouldn’t have mattered so much that the permissions were set incorrectly—the contents would not be readable.

Phishing attacks, too, can be prevented using the same technology that supports end-to-end email encryption—public key cryptography. Using public keys, senders can digitally sign their messages, and recipients can verify the sender. Instead of relying on spelling errors and “out of character” language, users could simply check the message signature to determine whether an email was truly sent by the person they expected.

13.3.2 The Ugly Side of End-to-End Encryption

Although in theory, end-to-end encryption can solve many security problems, in practice there are many challenges to implementing it. Key management is particularly tricky. In order to read encrypted emails, users need to have their private key stored on any device they use or in a place accessible to all of their devices. In order to send an encrypted email, users first need a copy of the recipient’s public key, which requires a distribution mechanism. These are just a couple of the issues that arise when implementing end-to-end encryption; there are many other logistical details to consider, such as key escrow and enterprise access for purposes of data-loss prevention and malware detection.

Compounding the inherent complexities is the fact that email and cloud-based storage products have advanced and matured over the past two decades—but end-to-end encryption was not integrated along the way. In fact, end-to-end encryption technology was largely left to atrophy. There are reasons for this: businesses and government organizations alike have a vested interest in analyzing user-generated content. Cloud providers actively mine communications and document repositories in order to generate ad revenue and to offer features such as search and spam filtering. Government agencies such as the National Security Agency (NSA) wanted the ability to read peoples’ emails easily and engaged in a decades-long effort to undermine the implementation of encryption. While it is possible to deploy end-to-end encryption in such a way that authorized third parties can still access contents, this creates additional work and slows down analysis efforts. Absent strong pressure to deploy end-to-end encryption, it was easier for providers to just leave it out entirely.

The tide began to turn when HIPAA and other regulations emerged and gradually gained traction. These regulations incentivized organizations such as healthcare clinics to deploy encrypted email and file transfer solutions in order to protect sensitive personal information. However, by that time, enterprises, cloud providers, and government agencies were already reaping the rewards of their data-mining programs, and many important security tools such as spam filtering software relied upon access to unencrypted content.

Instead of implementing true end-to-end encryption solutions, it was easier to leverage existing solutions like secure web portals or encrypted PDFs. Organizations deployed “faux” email encryption, where recipients received a link to a “secure” message stored in a web portal or an encrypted PDF. Faux email encryption is clunky, annoying, and (ironically) not very secure. When it is implemented in a web portal, recipients typically choose weak or reused passwords, and when it is implemented as encrypted PDFs, the password is often weak or sent in a subsequent email message, rendering the encryption pointless. The technology worked well enough to meet compliance requirements, however, and so it remained.

The result was that end-to-end encryption products were not developed at scale and were never integrated with popular cloud services. The technology stagnated. While this enabled governments and businesses access to monitor email, it also left a gaping security hole. Attackers who broke into email and cloud accounts found reams of juicy, sensitive data, unprotected once the login interface was breached.

Integrating end-to-end encryption into popular services now is a much harder problem than it might have been at the dawn of the industry since it is more difficult to “bolt on” technical solutions after the fact, as opposed to building functionality into early prototypes. In certain environments, deploying end-to-end encryption today is feasible. For example, at the author’s consulting firm, all internal emails are GPG-encrypted automatically because the business has full control over the endpoints and a relatively small user population. However, in more complex environments such as hospitals, it remains a difficult challenge. In recent years, there has been a resurgence of interest in end-to-end encryption, for reasons that we will discuss in the coming sections.

13.3.3 Large-Scale Monitoring

Communications encryption experienced a renaissance when Edward Snowden, a mild-mannered Department of Defense contractor, breached the NSA. After vacuuming up an estimated 1.7 million documents, Snowden fled to Hong Kong and began contacting reporters, exposing the NSA’s shockingly ubiquitous monitoring programs.⁴³

43. Chris Strohm and Del Quentin Wilber, “Pentagon Says Snowden Took Most US Secrets Ever: Rogers,” Bloomberg, January 10, 2014, https://www.bloomberg.com/news/articles/2014-01-09/pentagon-finds-snowden-took-1-7-million-files-rogers-says.

Snowden’s leaked documents showed that to gain access to communications, the NSA had broken or circumvented key Internet security technologies and installed monitoring systems that gave them immediate access to private data hosted by major cloud providers, including:

• AOL

• Apple

• Facebook

• Google

• Microsoft

• Skype

• Yahoo

• YouTube

According to one internal NSA presentation, accessible data included:

• Chat

• Email

• Photos

• Social networking details

• Stored files

• Video

• Voice conversations

Any monitoring system increases access and therefore inherently increases the risk of a data breach. As discussed in Chapter 2, “Hazardous Material”:

The risk of a data breach increases with (a) the number of people who have access to the data, (b) the number of ways that the data can be accessed, and (c) the ease of obtaining access.

Security expert Bruce Schneier called attention to this point when analyzing the NSA’s extensive communications monitoring capabilities. “The more we choose to eavesdrop on the Internet and other communications technologies, the less we are secure from eavesdropping by others,” he said. “Our choice isn’t between a digital world where the NSA can eavesdrop and one where the NSA is prevented from eavesdropping; it’s between a digital world that is vulnerable to all attackers, and one that is secure for all users.”⁴⁴

44. Glenn Greenwald, No Place to Hide (New York: MacMillan US, 2014), 205.

13.3.4 Investment in Encryption

The revelation of the NSA’s surveillance programs spurred developers and users around the world to invest in stronger cloud security programs.⁴⁶

46. Robert Hackett, “Snowden Leaks Advanced Encryption by 7 Years, US Spy Chief Says,” Fortune, April 25, 2016, http://fortune.com/2016/04/25/snowden-encryption-james-clapper.

Google quickly launched an “End-to-End” encryption project, releasing a open-source browser plug-in that encrypts Gmail messages using PGP.⁴⁷ Although the project was highly touted in the wake of the Snowden leaks, Google eventually dropped the development, leading Wired to declare the project “vaporware.”⁴⁸

47. “FlowCrypt: Encrypt Gmail with PGP,” Chrome Web Store, accessed June 5, 2019, https://chrome.google.com/webstore/detail/flowcrypt-encrypt-gmail-w/bnjglocicdkmhmoohhfkfkbbkejdhdgc

48. Andy Greenberg, “After 3 Years, Why Gmail’s End-to-End Encryption Is Still Vaporware,” February 28, 2017, https://www.wired.com/2017/02/3-years-gmails-end-end-encryption-still-vapor.

At the same time, a group of scientists from around the world founded “Protonmail,” a webmail system that supported multiple levels of encryption—including the “Paranoid” option where only the end user has access to the encryption key.⁴⁹ Protonmail reportedly has no way of accessing user emails—or providing third parties with access—when they do not hold the decryption keys in the first place. “There are many companies and governments that would love to see us fail,” say the Protonmail founders.

49. Hollie Slade, “The Only Email System the NSA Can’t Access,” Forbes, May 19, 2014, https://www.forbes.com/sites/hollieslade/2014/05/19/the-only-email-system-the-nsa-cant-access.

A plethora of new communications and cloud products have emerged since then that incorporate end-to-end encryption—including WhatsApp, Signal, and other popular tools. While end-to-end encryption still remains elusive for mainstream email and cloud file-sharing products, the epidemic of data breaches has sparked discussion and created new incentives for investing in strong encryption in the cloud and beyond.