© The Author(s), under exclusive license to APress Media, LLC, part of Springer Nature 2023
Y. Wilson, A. HingnikarSolving Identity Management in Modern Applicationshttps://doi.org/10.1007/978-1-4842-8261-8_19

19. Failures

Yvonne Wilson1   and Abhishek Hingnikar2
(1)
San Francisco, CA, USA
(2)
London, UK
 

Those who cannot remember the past are condemned to repeat it.

—George Santayana, Spanish philosopher, poet, and novelist, from The Life of Reason, vol. 1 (1905)

We have covered several aspects of identity management relevant to an application development project. Writing an application with perfect identity management will be for naught, however, if flaws in your environment or processes introduce a vulnerability, especially one that compromises sensitive identity data. It is often said that one can learn a lot from failure. When it comes to identity management, however, we think it is preferable to learn from others’ failures rather than your own. Inspired by George Santayana’s advice about the need to learn from the past, we’ve collected stories of past security breaches and their causes to help you avoid making such mistakes in your environment.

This chapter describes failures that resulted in significant breaches or exposure of identity data. There may be some wonderfully interesting and obscure cryptography bugs that have caused a breach somewhere. We won’t be covering any here because, sadly, many breaches have been caused by very simple failures. While there are many attack vectors, the annual Verizon Data Breach Reporti provides some valuable statistics on the top causes behind breaches. Hacking, malware, human error, and social engineering topped the lists in the 2020ii, 2021iii and 2022iv reports. You’ll see those and more in the following stories. Take note of the root causes in each story and avoid them in your projects!

Pay Attention to Process

Our first case doesn’t involve technology or a breach of identity data, but we included it because it underscores the importance of securing not just technology but also processes. In 2015, Edward Hornsey, an enterprising young businessman, hit upon the idea of buying used iPhones, many of which were stolen, and returning them to Apple to take advantage of their liberal return policy. He received shiny new replacement phones in exchange, which he was then able to sell at a handsome profit. Surprisingly, he managed to do this 51 times before Apple caught on. At the time, Apple did not check to see if a returned phone had been reported stolen or was being returned by the registered owner of the phone. Nor did Apple have any check on the number of phones returned by a single person. This demonstrates the necessity of designing appropriate anti-fraud mechanisms and identity checks into business processes. In case you are wondering, Apple did catch on and fix its processes, and Mr. Hornsey was duly convicted of fraud and sent to jail. Don't try to replicate his scheme at home.

Another classic example of an attack that involved no technology beyond charm and chocolate, yes you read that correctly, chocolate, is the 2007 social engineering attack by a perpetrator who purloined 21 million euros of jewels from safe deposit boxes at ABN AMRO Bank in Belgium.v The thief’s charm and gifts of chocolate were apparently used to obtain safe deposit box keys and information about the diamonds. Don’t shortcut security processes, even for charming, chocolate-bearing customers!

Another failure occurred in 2006 when office workers employed by The Boston Globe newspaper mistakenly printed out lists of subscribers’ credit card and bank routing numbers. Rather than shred the printouts, the workers placed them in a recycling bin. This environmentally conscious newspaper used recycled paper for routing slips for the bundles of newspapers they distribute to newspaper vendors. As you suspected, the recycled printouts with customer credit card and bank information were used to wrap bundles of newspapers that were then distributed all around the city of Boston.vi The newspaper certainly earned an “A” for environmental awareness, but an “F” for data protection that day. If you handle any identity information, avoid printing sensitive information except where absolutely necessary. In addition, provide shredders and train all staff regularly on data protection procedures, including shredding printouts with sensitive information. These examples highlight the need to analyze any of your processes that touch identity data and other sensitive information to ensure there are adequate process safeguards to prevent breaches.

Beware of Phishy Emails

Don’t take the bait when someone is phishing! Continuing the unfortunate tale of breaches is Anthem which suffered a breach in 2015 impacting 78.8 million records including social security numbers, birthdays, addresses, email, and income data.vii The Anthem breach is suspected to have originated in a single employee inadvertently clicking on a link in a phishing email containing malware. At the time, Anthem had on the order of 50,000 employees and a single person clicking a dodgy email may have opened up a door for hackers. Sadly, the list of breaches caused by phishing attacks continues unabated. In 2018, UnityPoint Health fell victim to a phishing attack, resulting in the exposure of 1.4 million patient records including names, addresses, medical data, and possibly social security numbers and payment card information.viii Aultman Health Foundation was compromised by phishing, impacting over 42,000 patients.ix MedSpring Urgent Care in Austin Texas compromised over 13,000 patients’ data as a result of a successful phishing attack.x This should underscore the importance of security training, endpoint protection software, and procedures/tools to help employees recognize phishing attacks which may come in the form of emails, text messages, or even voicemails. Implementing a comprehensive program of security measures, for defense in depth, may help reduce or contain the damage if someone falls for a phishing attack, but preventing malware in the first place is preferable.

Use Multi-factor Authentication

While the causes behind some breaches do not involve technology, there are certainly many that do. In November 2015, JP Morgan announced they’d suffered a data breach of 83 million customers’ accounts.xi At the time, it was the largest data breach suffered by an American financial institution. This breach was the result of an attack that began with stealing an employee’s credentials and then gaining access to the bank’s network through a lone server that did not require multi-factor authentication. The moral of this story is one of attention to detail. Have accurate lists of servers, check that multi-factor authentication is required for access to all access points and sensitive resources, and repeat the checks regularly. Rather than rely on error-prone manual processes, use automated processes to identify servers for asset management, build servers with secure configuration, and automate regular security scans to ensure all servers remain configured to secure build standards. Scan networks and use device management regularly to find any equipment that does not meet secure configuration standards.

Stay on Top of Patches

While we’re on the topic of staying on top of things, we should cover the 2017 Equifax breach. This breach exposed the personal data of 143 million people. The breach was made possible when Equifax did not act on security vulnerability notices for its technology stack. A vulnerability in the Apache Struts technology (CVE-2017-5638)xii was made public on March 6, 2017.xiii A patch was promptly made available by Apache.xiv Installing a patch requires time to update the impacted software and thoroughly test applications relying on the patched technology. Care must be taken to ensure the installation of a patch doesn’t cause outages or other issues. In this case, however, aggressive attempts to take advantage of the vulnerability were already being reported in March.xv Unfortunately for the victims in this breach, Equifax failed to patch its systems for this known vulnerability. Equifax reported that its systems were breached in May of 2017, two months after the patch for the vulnerability was provided.xvi The lesson here is the necessity of knowing your infrastructure and technology stack, monitoring the vulnerability announcements for each technology used, and having a process to quickly triage and apply patches for critical vulnerabilities. It is challenging to identify and keep up with patches even in small environments, so leveraging automation, at least for identifying vulnerabilities, is essential.

Secure Your Cloud Storage

Just because you use cloud services with rigorous security practices doesn’t give you a free ride. If you use a cloud service, you must configure and use it securely. In 2018, MBM, which runs a company called Limoges Jewelry (a Walmart partner), exposed the personal information of 1.3 million customers via an improperly secured Amazon S3 bucket. This S3 bucket contained a database backup file and left this information publicly exposed for many weeks. The compromised information included names, addresses, phone numbers, email addresses, plaintext passwords, and encrypted credit card information.xvii A similar incident, in 2017, this time by a Verizon partner, exposed personal information and PINs of up to 14 million Verizon customers via an improperly secured S3 bucket.xviii Continuing the pattern, Uber exposed the personal information of 57 million users in a vulnerable S3 bucket.xix A Florida credit repair firm, National Credit Federation, exposed data including names, addresses, driver’s licenses, dates of birth, social security numbers, and credit reports for tens of thousands of customers in a similar fashion.xx Learn from these examples and check the configuration of any S3 buckets you use, but don’t stop there. There were a surprising number of discoveries by security researchers from 2019 through 2021 of improperly secured cloud databases. VoIP Provider Broadvoice inadvertently left an unsecured Elasticsearch database exposed to the Internet that contained more than 350 million records. The data involved included caller names, phone numbers, city, state, and, in some cases, call transcripts.xxi At the time the breach was reported, it was unclear if the information had been accessed and misused by unauthorized parties. The country of Thailand inadvertently exposed personal information including names, passport numbers, visas, and residency status of over 106 million travelers in an unprotected Elasticsearch database containing ten years of information. Thailand promptly addressed the issue when discovered by cybersecurity researchers and announced that the unsecured database had not been accessed by unauthorized parties.xxii Cybersecurity analytics firm Cognyte exposed an Elasticsearch database to the Internet without authentication required for access. The database contained more than five billion records of data culled from previous breaches, which included names, email addresses, passwords, and the original source breach. It is unclear if the data was accessed by unauthorized users.xxiii Furthermore, researchers discovered numerous mobile applications with improperly secured Firebase databases.xiv An easy way to reduce the likelihood of a costly data breach is to simply take the time to periodically check the configuration of any cloud storage you use, such as S3 buckets, Elasticsearch, MongoDB, and Firebase.

Encrypt Sensitive Data

Another critical lesson can be learned from the breach of Sony PlayStation Network. The Sony attack involved 77 million accounts, 12 million of which had unencrypted data. This resulted in the compromise of names, emails, passwords, addresses, and credit card numbers.xxv The lesson here concerns the need to protect data. If you handle sensitive data, and identity data is by definition considered sensitive, you should encrypt the data at rest and in transit. This protection should extend to backups and log files. In addition, logs should be scanned to ensure sensitive data isn’t leaked to log files. Twitter learned this lesson the hard way when a bug inadvertently wrote out cleartext passwords to log files and they didn’t discover the issue for months.xxvi Legislators around the world are reacting to public outrage about data breaches and enacting privacy legislation with sanctions for companies that fail to adequately protect personal data. In the event of a breach, these fines may be avoided, or at least significantly reduced, if data is protected by proper encryption.

Do Not Store Cleartext Passwords

It is risky to store passwords in cleartext. Unfortunately, numerous breaches of cleartext passwords show that many sites have run this risk, to the detriment of their customers. The third largest data breach in Finnish history resulted in the compromise of usernames and cleartext passwords of 130,000 users of the New Business Center, a site for entrepreneurs.xxvii A breach of ClixSense, a site for viewing ads and surveys, resulted from an unsecured older server with access to a primary database. This breach exposed personal information such as names, email addresses, dates of birth, and IP addresses as well as the cleartext passwords of 6.6 million users.xxviii A service called “Teen Safe,” designed to allow parents to track their children’s phone activity, compromised the data of tens of thousands of customers. The data exposed included parent emails as well as children’s Apple ID and cleartext password for the Apple ID. This incident was caused by improperly secured servers in Amazon Cloud, but the impact of the breach was compounded by passwords stored in cleartext.xxix All we can say is, when it comes to storing passwords in cleartext, just don’t.

Provide Security Training to Developers

Secure infrastructure and practices won’t help if applications themselves contain coding vulnerabilities. A good place to start for advice on secure coding practices is the most recent version of the Open Web Application Security Project (OWASP) Top 10 security and coding guidance.
  • OWASP Top 10 – 2021xxx

This site contains advice about the most common coding vulnerabilities and how to avoid them.

Heartland Payment Systems suffered a data breach in 2008 that exposed 134 million credit cards and was caused by a SQL injection attack.xxxi This type of attack takes advantage of applications that do not properly validate input that is subsequently used to form queries against back-end data systems. The Heartland breach in 2008 might have been prevented had they heeded the 2007 version of the OWASP Top 10, which showed injection-style attacks as number two in the list.xxxii They are easy attacks to perform and automate but can be prevented with proper input validation. To reduce vulnerabilities in application code, ensure that developers are thoroughly trained on the current OWASP Top 10 application security risks and how to prevent them. In addition, to mitigate the risk of human error, institute code reviews and automated software vulnerability scanning to identify vulnerabilities in your application code.

Vet Your Partners

Many companies today use a dizzying array of vendors, and if their access is not properly managed and segregated, the results can be disastrous. The retail company Target announced in 2014 that it had been attacked, resulting in the exposure of 40 million card numbers and personal data of 70 million customers. This attack is suspected to have originated in the compromise of Target’s HVAC (heating, ventilation, and air conditioning) contractor via a phishing attack which installed a Citadel Trojan. Unfortunately, there was inadequate separation between the network access granted to the HVAC vendor and other systems on Target’s business network. The attackers were able to leverage the access provided to the HVAC vendor to access vulnerable systems on Target’s network and from there to access POS (point of sale) systems where they collected credit and debit card data. While Target had installed security tools such as FireEye and Symantec, key monitoring features were either turned off or not monitored.xxxiii The lesson to learn from this breach is to thoroughly validate the security practices of all partners on an ongoing basis and ensure adequate network segregation between low sensitivity systems and systems with highly sensitive data. Applying the principle of least privilege by granting the minimum necessary access to each actor in an environment can provide another layer of defense. Last but not least, ensure monitoring systems are turned on and pay attention to alerts from security monitoring systems.

There are several more examples of breaches related to business partners. [24]7.ai, a customer service and chat vendor used by several retailers such as Sears, Kmart, Best Buy, and Delta, caused a breach in 2018 resulting in exposure of personal data and credit card information for hundreds of thousands of customers of each of these large companies.xxxiv In 2017, Deep Root Analytics, a small professional services company used by the Republican National Committee, mistakenly put the data of 200 million voters on a publicly accessible server.xxxv Volkswagen announced in 2021 that personal data on over 3.3 million Audi customers or prospective customers was compromised by a business partner that left the data exposed sometime between 2019 and 2021. The data involved was part of a dataset used between 2014 and 2019 and included first and last names, email addresses, and phone numbers as well as any cars bought or leased.xxxvi To avoid a repeat of these cases, make sure to track all partners you use, vet their security practices and certifications, and ask for information on whether they share your data with any of their partners and how they’ve vetted their partners.

Insider Threat

Some breaches are caused by insiders. The Verizon Data Breach Investigations Report for 2018 indicated that 28% of attacks were perpetrated by insiders.xxxvii The same report for 2022 shows this has declined slightly since 2018, but is still around 20%.xxxviii While the motivation in most cases remains financial gain, perhaps the most infamous example of insider threat was not. Edward Snowden, a systems administration contractor working at the US National Security Agency (NSA), was able to exfiltrate thousands of top secret documents from a Defense Intelligence Agency network. The exact scope of the breach may never be known, but the impact to political strategy as well as to offensive national cybersecurity interests will be felt for years. Snowden apparently accessed 1.7 million files using automated web-crawling software on networks to which he was legitimately given access or obtained credentials to access. He configured the software to look for specific topics. His activity was apparently not detected in part because he worked in a field office that had not yet upgraded systems to implement the latest security controls which might have detected his activity.xxxix, xl

The Snowden incident illustrates the threat of a malicious insider. Several lessons can be learned from the Snowden incident. The first is to implement the classic security principle of granting each person the least privilege required to do their job and to design access models to enforce segregation of duties. Admittedly, this is challenging in smaller organizations where each person has many responsibilities. A second protection is to encrypt data at rest and in transit and implement adequate protection of the encryption keys. A third technique is to employ security monitoring software that can detect anomalous activity (especially high-volume data retrieval and exfiltration). It usually takes significant time to tune such solutions so that they do not generate a time-wasting volume of false positives. Data loss prevention (DLP) solutions, which are designed to prevent exfiltration of data by detecting anomalous traffic out of a network or device, can also be used. Unfortunately, none of these techniques can guarantee protection against data theft. However, if there is a breach and such solutions are not in place, it will look much worse for the victimized organization.

Summary

This chapter was a very sobering chapter to write. The number and magnitude of breaches seem to continually get bigger and bigger. The root causes are often basic issues that seem easy to avoid in theory, but are proving to be stubbornly challenging in the scale and demands of real-world environments. George Santayana, the Spanish philosopher, poet, and novelist, said, “Those who cannot remember the past are condemned to repeat it.” We hope the lessons from past breaches help you avoid following in the footsteps of the many companies featured in the preceding sections. If you are writing an application that contains or uses identity data, you have an obligation to protect that data. Unlike the game of golf, there is unfortunately no handicapping system to give beginners a break. If you are creating an application, you must follow security best practices for the coding, deployment, and environment of the application as well as people, processes, and partners involved in the project.

Furthermore, in today’s world, it’s not good enough to just implement security technology. You need to be able to demonstrate diligent adherence to security- and privacy-related policies and procedures, which is related to compliance, the topic of our next chapter.

Key Points

  • Processes, in addition to infrastructure, should be analyzed for vulnerabilities.

  • Train users to recognize and avoid phishing attacks to reduce risk of malware.

  • Use multi-factor authentication to mitigate the risk of compromised passwords.

  • Monitor for software vulnerabilities and apply patches when vulnerabilities are announced. Leverage automation and tools for this process where possible.

  • Follow secure configuration guidelines for all cloud-hosted components such as Amazon S3 buckets and cloud databases such as Elasticsearch, Firebase, and MongoDB.

  • Encrypt sensitive data at rest and in transit, including backups and log files.

  • Avoid storing cleartext passwords.

  • Provide security and secure coding training for developers.

  • Vet partners by checking certifications and conducting due diligence evaluation of security practices.

  • Mitigate the risk of insider threat by granting minimum needed privileges and frequently reviewing access grants as well as logs.

Notes

  1. i.
     
  2. ii.
     
  3. iii.
     
  4. iv.
     
  5. v.
     
  6. vi.
     
  7. vii.
     
  8. viii.
     
  9. ix.
     
  10. x.
     
  11. xi.
     
  12. xii.
     
  13. xiii.
     
  14. xiv.
     
  15. xv.
     
  16. xvi.
     
  17. xvii.
     
  18. xviii.
     
  19. xix.
     
  20. xx.
     
  21. xxi.
     
  22. xxii.
     
  23. xxiii.
     
  24. xxiv.
     
  25. xxv.
     
  26. xxvi.
     
  27. xxvii.
     
  28. xxviii.
     
  29. xxix.
     
  30. xxx.
     
  31. xxxi.
     
  32. xxxii.
     
  33. xxxiii.
     
  34. xxxiv.
     
  35. xxxv.
     
  36. xxxvi.
     
  37. xxxvii.
     
  38. xxxviii.
     
  39. xxxix.
     
  40. xl.
     
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset