Learning from data breaches: The importance of the fundamentals

“It’s all too easy to get caught up in the headlining data breaches that we’re seeing so frequently today and to think “we’re not that dumb””

We think of data breaches as a result of hackers battling an organisation’s defence systems for hours or days, frantically typing in reams of code in order to gain access to a database. The truth is, it’s often not like that at all. Criminals are lazy. They won’t fight tooth and nail to get into a target if they can sneak in elsewhere, and oftentimes, the job is actually made quite easy for them.

Whether it’s ransomware, malware, SQL injection or even phishing, it seems as though we’re reading about brand new breaches every few days, and we’re growing accustomed to it. With that in mind, what can be learned from the high-profile attacks that grip the headlines so frequently? The answer is: quite a lot.

Marriott, 2020

March 31st saw hospitality giant, Marriott, announce that it had identified that “an unexpected amount of guest information may have been accessed using the login credentials of two employees at a franchise property”. In turn, 5.2 million customer records were exposed – including names, addresses, phone numbers, dates of birth, and further travel information.

As much as we might like to believe that a mysterious hooded figure sat in a dark basement, typing away to breach Marriott’s defences, it’s not true. While they may have been mysterious, hooded or even sat in a basement with the lights off, there was nothing especially difficult that the hacker needed to do in order to gain access to valid accounts.

From Marriott’s perspective, there is a lot that it could have done to prevent the breach. And it would have been both inexpensive and simple to implement. In fact, it may well have been the case that Marriott ignored warnings from its monitoring systems about the breach (as is quite common) – though this isn’t proven. The very same thing happened to Target in 2013 – an expensive mistake that cost the company $18.5 million in settlements.

So what could have been done to prevent the Marriott attack? Auditing logins would have been a start, allowing security teams to track where people were logging in from and detecting potential threats immediately. Furthermore, multi-factor authentication would have scared many away. It’s similar to burglars looking to break into a house. If they see a sign that reads ‘CCTV in operation’, the chances are they would move on to an easier target. Multi-factor authentication (MFA) has the same effect. MFA won’t scare off the strongest willed, or nation state attackers, but many hackers aren’t the most capable, nor the most brilliant. It doesn’t take much to thwart them.

Equifax, 2017

Equifax, one of the largest consumer credit reporting agencies in the US, reported on 17th September 2017 that the names, addresses, phone numbers, dates of birth, social security numbers, and drivers license numbers of 148 million Americans had been exposed in a breach. Further to this, 209,000 credit card numbers had been stolen.

The organisation’s web application was running on open-source software. That, in itself, is not a problem. However, the fact that the software that Equifax used had a known security issue but didn’t patch the software, was. In fact, leaving installed software and important hardware products, like routers, with their default installation settings is one of the biggest entry points for hackers.

Adversaries took advantage of the fact that they could exploit a remote vulnerability. They created remote access that got them into the Equifax network, found a server which had a password file, and used that to gain access to data throughout their IT systems.

Like Marriott, it’s a simple fix: keep software updated, isolate applications, do not keep passwords in clear text, and keep no files of passwords. The vulnerability itself was a well-known problem within the community and that alone should have raised alarms to the security team. If they keep up with patching at the OS level and ensure that applications are patched properly, businesses eliminate a number of ways that an external threat can get in.

Capital One, 2019

If it wasn’t for Paige Thompson bragging online about how she had breached one of the biggest banks in the United States, we might not have been able to figure out what had happened when Capital One was compromised on 19th July 2019.

The numbers on the breach are staggering: over 100 million credit applications, 140,000 social security numbers, 80,000 US bank account numbers and 1 million Canadian social security numbers – all exposed in one fell swoop.

Capital One was operating on an Amazon web server, and the breach was only possible because the bank had misconfigured its setup. Thompson was able to breach the firewall and request privileges and credentials with ease. Once she had these, Thompson could start poking around – before long, she found that she had access to storage, and from there found the unencrypted database backups.

This breach wasn’t a cloud security issue. It was a configuration issue. Amazon Web Services actually tells its users how to configure and secure their operations but leaves it up to them to do the configuration because one size does not fit all. Capital One ignored some of the basic recommendations that it was offered, and Thompson was able to get in without breaking a sweat.

If the web app had the right rules configured, it would have been stopped. If the metadata server had been configured properly, it would have been stopped. If the web app firewall account didn’t have access to storage, it would have been stopped. All of these issues could have – and should have – been fixed prior to the attack if Capital One had configured its setup correctly.

What can we learn?

In each of these instances, a breach could have been prevented if businesses had taken a little more care in their operations. There are four small security measures that organisations can take to drastically reduce their chances of being breached, and with little expenditure.

Principle of least privilege: employees and services like a web app get only the privileges that they need to complete their routine work and nothing more. If someone doesn’t need an access right, they shouldn’t have it. For example, if the web app doesn’t need direct access to storage files, it shouldn’t have it.

Auditing and alerting: everything users do should be logged, especially activities that are outside the routine activities of their job. Once logged, review user activities to make sure they perform only the tasks that they are authorised to complete. If any unauthorised or abnormal behaviour is flagged, like logging into a system far outside of their normal business hours, you can build automated alerting to prevent, track, and stop unwanted or inappropriate activity.

Privileged access management: a system that securely manages the accounts of users who have elevated permissions to critical resources. These accounts are of more value to hackers and monitoring them closely can pay dividends to security teams.

Code review: by consciously checking any code for mistakes or poor practices, like hardcoded passwords, it will not only help to accelerate and streamline software development, but it will also help keep any potential system vulnerabilities to a minimum.

Protecting modern IT systems is surprisingly easy. First, it all starts with an attitude to not be apathetic about security, to not assume that “everything will be ok” when using default settings for software and hardware. Second, it is important to discard the obsolete notions that the default behavior of security systems is to trust everybody.

That assumption should be reversed in new applications, to assume that no user or service is trustworthy until it fully authenticates against your internal identity and permission management systems. Finally, it’s all too easy to get caught up in the headlining data breaches that we’re seeing so frequently today and to think “we’re not that dumb”. But if one thing is clear, it’s that security teams need to be doing the basics right if they are to minimise the risk to their organisation.