Let's talk about the Optus hack

In case you’ve been stranded on a desert island for the past week, Optus, Australia’s second biggest telco, just suffered a doozy of a data breach.

Several media outlets reported that up to 9.8 million customer records may have been breached — including email addresses, dates of birth, and even passport and drivers licence numbers — making it one of Australia’s largest ever data dumps.

The company has so far provided very little technical information on how the attack was performed but there have been several reports that provide some clues. Note that I’ll base any analysis here on the information that is currently available and will update this post if and when we learn more.

There were 2 primary issues in play with the Optus hack:

1. Sensitive data was accessed by unauthorised parties

The obvious issue is that data was accessed that shouldn’t have been. According to a tweet by Jeremy Kirk on Saturday, customer data was likely accessed via an insecure API. The API was intended to be a centralised tool to query customer records for other Optus (and possibly 3rd party) services. The API was not protected with any authentication and was publicly accessible.

However, Kirk noted that the API endpoint was only accessible if specified using an unusual format, indicating a possible misconfiguration in the Optus firewall or load balancer used to control access to the API. It appears that the Optus team did not intend to make the API available public, but it remained accessible due to a misconfiguration.

2. Optus was unable to determine exactly which records were accessed

The second issue is perhaps less apparent. Optus said they were struggling to identify exactly how many records were accessed. They said that as many as 9.8 million customer records may have been breached — presumably because that’s how many were stored in the database behind the breached API.

Knowing which customer records were accessed could have saved Optus — and their customers — a lot of heartache. If the number of affected customers was only a few hundred, this would have been a relatively minor incident. However, it does appear that because Optus was unable to prove which records were accessed, they notified all customers who could have had their data breached.

You’d be forgiven for immediately asking questions like: “who stuffed up?”, “who should be fired?” or “why did a review process not pick up the mistake?”.

In a company of over 10,000 employees, the likelihood that no employee will ever make a mistake is essentially zero. We are humans, we make mistakes. And my thoughts go out to the engineer who made an (understandable) error this time around. It’s not good, but it happens. Lord knows I’ve made my share of mistakes in my career.

Instead of finding employees to scapegoat every time there is a breach, we should be asking more fundamental questions: how is it that one mistake by an employee can lead to the exfiltration of customer records of over a third of Australia’s population. Indeed, how is it that Optus is unable to identify exactly which records were accessed?

So are we fighting a losing battle to protect digital rights and the inherent trust on which the modern world is built?

Despite the huge odds stacked against us, I don’t believe we are, and I believe that encryption can play a critical role in turning the tide.

Approaches to data security must be resilient or even “anti-fragile” and 3 fundamental principles need to be applied:

1. Restrict sensitive data access using Encryption-in-Use

Encryption-in-Use is one of the most powerful data protection techniques available. While Encryption-in-Transit is used to secure communications across the Internet (such as between your browser and your bank), Encryption-in-Use ensures that sensitive data remains encrypted at all times - particularly when it is stored in a database.

However, most organisations aren’t even aware of Encryption-in-Use, let alone using it.

If the claims were true about the Optus data leak occurring via an insecure API, encryption likely wouldn’t have provided much protection. Though that assumes the API itself performed any decryption before sending any data to the client. Having the API return encrypted data for decryption later by 3rd parties may well have avoided the issue but that’s a story for another day.

However, a particular kind of encryption, called envelope encryption would have made it possible for Optus to know which records were accessed.

2. Log when data is decrypted, and by who

If you’re old enough to remember going to a library to borrow a book, you’ll remember needing to have the book checked out by the librarian and your library card number recorded against the title. The librarian has a record of which books were borrowed when and by who.

Imagine if there was no librarian and anyone could just walk in and take whatever books they wanted whenever they wanted. It would be next to impossible to know whether a book was taken or not.

This is a reasonable analogy for what happened at Optus. Attackers read customer records from the API but there was no digital librarian keeping tabs on what data was taken and by who.

Applying Encryption-in-Use with envelope encryption, requires that all data accesses are decrypted by a semi-trusted key provider and logged. It is the logging of data access that is important and could have saved Optus a world of pain.

In a large organisation, data is accessed constantly, in lots of places and by lots of people. Even if it is impractical to centralise where data is stored, a centralised key management system can behave like the digital librarian and ensure that no matter when data is accessed, it always logged.

3. Limit who can access and decrypt sensitive data

In the intelligence world, data is made available on a “need-to-know” basis. While a customer record certainly isn’t as sensitive as nuclear launch codes, applying this idea to corporate data is compelling.

Cyber security folks call this concept, least privilege. Think about the data in your organisation. What data is sensitive? Consider who genuinely needs access to it to do their job. I wager that most employees have access to more than they need.

In the Optus attack, data was (allegedly) accessed via a test network that was unintentionally accessible via the Internet. So the question is, why did the test engineers have access to customer data at all?

I can see an argument to give them access to the database infrastructure (to perform maintenance, run backups and so on) but not to the sensitive data itself.

This pattern is all too common in the modern enterprise. Engineers, data-scientists and testers have access to far more information than they actually need, because there are no practical ways to separate access to systems and infrastructure from access to data.

In other cases, access to whole datasets is provided instead of limiting it to only the fields or data subsets that are actually required. Once again, this is usually because mechanisms to apply such fine grained control are difficult or even impossible.

Encryption-in-Use provides a simple, yet powerful solution. By applying access control to key management systems, least privilege principles can be effectively applied to the data across your organisation.

If the test network at Optus, or even an engineer who has access to it is compromised, the data itself would still have been protected.

I have no doubt that the team at Optus do the best they can to protect customer data, and I commend the CEO for publicly acknowledging the issue.

But while the breaches will continue, Encryption-in-Use is a strong defence and we believe will be the way forward for companies to better protect their customer data.

Dan Draper

CEO, CipherStash