Contributor:
Brian Hanrahan
October 26th, 2015

Let’s TalkTalk about data breaches. It’s not so simple

With the fallout around the TalkTalk data breach still happening, many people are left with one primary question: Why do data breaches continue to happen?

Securing an environment against data breach is not a simple affair and involves many layers of security working together to prevent, detect and respond to threats.

In the case of TalkTalk, careful encryption of customer data and a well-executed overall security architecture would likely have failed to protect the customer records. The attackers got inside the software that had unencrypted access to customer data. This wasn’t “malware” it was more akin to sneaking in an unlocked window and cleaning out the till. The web application was vulnerable. It happens to the best of companies.

It’s fairly standard practise to execute routine web application vulnerability scans and periodic penetration tests by highly skilled “whitehat” hackers. These scans and interactive penetration tests often expose vulnerabilities in sites that need to be resolved and can be very valuable. Its best practise for this reason.

Skilled penetration testers, scanning tools and the most advanced detection approaches we conceive don’t catch everything attackers dream up in the continually escalating cat and mouse game. Your security architecture should aspire to isolate breach to the point of intrusion, and look for the symptoms of breach in progress.

Lots of factors contribute to isolating attacks, but one of the most important is limiting the access and privileges of the identities that are most exposed. Human users are often the target of phishing and drive by web attacks – and for good reason! Your business users work with your critical information day in and day out. Web applications operated by every company you know also have an identity or account they run under. It’s often the case that these application identities have unmonitored access to lots of customer data without consideration for the consequences of a successful intrusion. As a result, once an attacker assumes the identity a web application uses by exploiting a vulnerability, they too have access to all the data often in an unencrypted form.

Another common mistake are server applications running with high levels of privilege on the computer where they’re deployed. In this scenario the application identity may not have direct access to sensitive data attackers are after but the high level of privilege means that once in, the attacker can steal the identity of anyone else logging onto the computer. Who else logs on to a server where your applications are running? Database administrators, server support users? Developers? These other identities are really valuable to an attacker who wants to move laterally to other systems for reconnaissance and data theft.

So, what can we do about this?

  1. Least privilege. Make sure that user and application identities have access only to the privileges and data that they absolutely need.
  2. Ensure that privileged identities aren’t accessible for use without approval

Now, we get into containing the damage done once an identity is compromised.

  1. Make sure that every application/process starting as a privileged identity is authorized properly with a question such as: ‘is authorized to run with identity on host based on ‘.
  2. Minimize the breadth of data any one identity has access to. The same identity doesn’t need access to addresses and credit details – we often wind up in this state because of lazy or rushed software development practices.
  3. Avoid direct access to data from the most vulnerable systems. Use separate identities working in the highest practical level of isolation.
  4. Assure that possession of a single secret (password, encryption key etc) doesn’t unlock all the data you’re protecting.
  5. Carefully protect the secrets needed to access the data directly and for the application identities that have access to the data.
    • Encryption keys
    • Passwords
  6. Carefully monitor for unusual access patterns, and unusual volumes of records being requested in a period of time. It’s not foolproof, but most attacks get by with nothing more sophisticated than a smash and grab.
  7. Make sure your data backups, and exports are protected as carefully as the live production copy! If a member of your data backup team is compromised, does the attacker have access to quite literally ALL of your data (up to the backup started yesterday at 11:59 PM :) )

Defending against breach isn’t trivial, and there aren’t shortcuts or shiny new products that solve it neatly. It takes discipline, long term investment and strategy and most of all, thinking like an adversary.

The next time you see a data breach headline dig in to the details and ask hard questions about the measures you have in place to protect the identities with access to your own critical data.

More from the Blog

Related technology and security insights

  • 28
    Jun
  • Story related

    NotPetya ransomware: Attack analysis

    On June 27, 2017 a number of organisations across Europe began reporting significant system outages caused by a ransomware strain referred to as Petya. The ransomware is very similar to older Petya ransomware attacks from previous years, but the infection ...