Top 5 Recent Data Breaches: Causes and Lessons

Veteran DPO (ex-McKinsey) and CISO (ex-Deloitte) team up in this article to breakdown recent data breaches and explain how they could have been prevented.

5. MedHelp AB

Fine: 1,200,000 EUR

Number of records affected: 900,000

Background

A telephone hotline offering advice on health-related topics had between 650,000 and 900,000 calls publicly available on a web server. This was due to a misconfiguration of a storage device accessible anywhere online that didn’t encrypt the data stored on it and wasn’t password protected. The company also contracted out the hotline using a follow-the-sun model but didn’t inform customers of this. Read more.

How It Could Have Been Prevented

Since it was a network storage device that exposed the personal data, the breach could have been avoided by:

  • Configuring the network-attached storage device to only have access to the network that it is used on or deprive it of any access to the internet.

  • The misconfiguration of the device meant it wasn’t password-protected; this could have been patched by setting authentication requirements (in the form of a password).

  • It’s also possible that the device could have been set to default or factory settings, meaning that it would have provided excessive port or service access; in this case, the device should have been tuned to the security requirements of MedHelp.

  • Getting subcontractors to regularly pentest their services.

Lessons Learned

Do due diligence on your contractors to ensure that they are handling your customer data securely and employ practices that reduce risk when sharing data with third parties.

4. Ticketmaster UK Limited

Fine: 1,405,000 EUR

Number of records affected: 9,400,000

Background

A cyber-attack took place on a chatbot that the company used on its payment page. The chatbot was hosted by a third party and the attack exposed the payment details of customers. Read more.

How It Could Have Been Prevented

It looks like Ticketmaster didn’t configure the chatbot properly and didn’t have an audit process for API and website requests set up. The company either didn’t mask the CVV when it was entered by customers, or it allowed the bot to decrypt it. In any case, reg 3.2 of PCI DSS specifies that you shouldn’t store CVVs anywhere. This means we know that the third party didn’t comply with PCI DSS; Ticketmaster should have checked this.

Ticketmaster also failed to check the bot’s code before implementing it in their own environment. Inbenta's infected script seemingly stole data from the frontend, so even encrypting the data at Ticketmaster's backend wouldn't have solved the problem. In any case, it’s dangerous to have third-party solutions involved when you are dealing with sensitive data.

Lastly, if Ticketmaster had a set monitoring and audit process, they would have flagged this data breach early on.

Lesson Learned

Don’t run third-party applications where you are receiving sensitive data, follow industry standards and have set processes that vet any third-party apps wherever they are running, and monitor your systems for suspicious activity.

3. Capio St. Göran AB

Fine: 2,900,000 EUR

Number of records affected: Unknown

Background

This health provider skipped the risk analysis before dishing out staff permissions to access patients' records, giving access to staff beyond what their function required. Read more.

How It Could Have Been Prevented

Capio probably didn’t even know how much data they had or how critically sensitive it was. They should have put role-based access in place, setting out who can have access to what. Moreover, they should have used a tool that would have allowed them to see how much data there is and who is making requests to access it.

Lesson Learned

Set access-right policies and adhere to them, then set up a way to monitor how many requests are being made to data stores and flag excessive usage or abnormal activity. Keep track of legal changes and follow them to the letter, then implement best practices on top.

2. British Airways

Fine: 22,046,000 EUR

Number of records affected: 500,000

Background

A vulnerability in third-party Javascript used on the British Airways website was exploited to divert customers to a fraudulent website. Payment details were harvested from this false site by the attackers. Read more.

How It Could Have Been Prevented

The most obvious way to prevent this type of breach is to conduct regular security audits of the web app and development in general. I wouldn’t advise using third-party scripts, but if you have to, you should audit them rigorously to make sure they do not weaken your security. This means you need to understand every character used in their code and you will need a specialist engineer for this.

Another way would have been to actively monitor what’s going on online. If the people at BA kept an eye out for anything that could be seen as damaging to their brand, they would have surely come across baways.com and taken steps to have it taken down. Regular pentesting and automated monitoring would also have helped prevent the breach.

Lesson Learned

Always monitor and audit what is going on, inside and outside of your perimeter.

1. Marriott International, Inc.

Fine: 20,450,000 EUR

Number of records affected: 339,000,000

Background

A web shell had been installed onto a device within Marriott’s systems, giving the attacker the ability to access and edit the contents remotely. Access was exploited in order to install malware, enabling the attacker to have remote access to the system as a privileged user. This provided unrestricted access to the network and reservation data. Read more.

How It Could Have Been Prevented

Here it seems that Marriott hadn’t set up logical access to the database, meaning that the attacker had access rights to revoke others’ access rights and assign to themselves as the system administrator. In this case, they could have better protected themselves by setting high-security requirements to access the account (e.g., 2FA).

On the other hand, if the attacker was able to take control by assigning themselves as a system administrator, then they were able to access the local system account used by the service control manager. If the access you need to keep the local system account open, then:

  • Privileged accounts should be constantly monitored.

  • There should be no direct connection to the database and an extra layer of security should be employed with 2FA required.

  • The database itself should be encrypted, with decryption only possible with admin login and a second admin key or service operation from another employee, or local system account using a vault or key management service.

Lesson Learned

If you have masses of especially sensitive data in one place, the database needs a high level of security. Apply 2FA wherever there is sensitive data and if a person doesn’t need access to the local system account then remove the right to access it.

Segment the network and think about to who you give access to sensitive data. Changes to critical systems and databases shouldn’t be carried out directly and this shouldn’t be possible; all changes should undergo verification and mandatory approval, especially if this concerns admin rights.

Lastly, you need to be monitoring critical components of systems, databases, and traffic at all times.

Like this article? Check out some other explainers and insights at the intersection of security and privacy.



Relevant Blog:



Recent Comments

No comments

Leave a Comment