Fine: 1,200,000 EUR
Number of records affected: 900,000
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.
Since it was a network storage device that exposed the personal data, the breach could have been avoided by:
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.
Fine: 1,405,000 EUR
Number of records affected: 9,400,000
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 payment details of customers.
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.
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.
Fine: 2,900,000 EUR
Number of records affected: Unknown
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.
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 which would have allowed them to see how much data there is and who is making requests to access it.
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.
Fine: 22,046,000 EUR
Number of records affected: 500,000
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.
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.
Always monitor and audit what is going on, inside and outside of your perimeter.
Fine: 20,450,000 EUR
Number of records affected: 339,000,000
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.
Here it seems that Marriot 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 system administrator, then they were able to access the local system account used by the service control manager. If access you need to keep the local system account open, then:
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 who you give access to sensitive data to. 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.
