On 22nd September, Optus was the victim of a cyber security event that resulted in millions of customer’s data being exfiltrated from Optus. What do we know about the event? What can we learn from the Optus breach? In this post, we concentrate on the technical learnings from the breach. We aren’t going to delve into how to handle communication and your reputation. That’s could be a whole other blog post!
Note that I don’t work for Optus and I never have. I have no insight into the controls that they may or may not have had in place at the time of the attack!
What we know about the Optus breach
The data from around 10 million customers was downloaded during the breach. Based on the information we have to date, a non-production API endpoint was exposed to the Internet. This endpoint provided access to customer data. It had no authentication enabled. Optus shutdown the endpoint when they noticed suspicious activity. The data held included not only customer details but also details of their identity information, such as passport and driving license numbers.
About a week later, 10 000 or so records were released onto the Internet along with a ransom demand in relation to releasing more data. A short time later, the ransom demand was withdrawn. The hacker claimed to have deleted all the data. However, it is impossible to verify this.
What can we learn from Optus’s experience?
Based on what we know (which may change as the investigation continues), there are several areas that we should all think about in our own services to try and avoid a similar scenario.
Control changes to your endpoints
Exposing anything to the Internet is a privileged operation. Use highly refined roles for job functions. A normal user or developer role should not have access to do this using their day to day role (or access). Define a tightly managed set of job roles that people or tools can assume to perform these kinds of actions. The ability to use the role should be closely managed and heavily logged. Use strong authentication methods, such as multi-factor (MFA), to reduce the likelihood of compromised credentials.
Not only should you control who can do this kind of action, but you should know about it as well.
In modern Cloud environments, we have immense power but we need to yield is carefully. Gartner predicts that by 2025, 99% of breaches of services running on the Cloud will be due to preventable misconfigurations. Manage that access and ideally define your infrastructure in code. Know about misconfigurations and even use automation to resolve them.
Monitoring & visibility
In business, we like to make data driven decisions. Our technology teams should be doing the same!
We can’t expect our teams to just “know about” changes without the tooling to support it. Make sure your environments are heavily instrumented so you know about changes when they happen. You should have near real time visibility of activity in your environment so you can spot unusual activity as soon as it starts happening, not 24 hours later. User behaviour analytics should be implemented so you can understand when something is “off” and respond quickly.
Adopt a zero trust approach
No service should not make any assumptions about who is calling it. Your services, whether public or private, should ask the caller to prove who they are. APIs typically use unique keys that provide access to the API. These keys should be carefully managed, regularly rotated and closely monitored. Allowing an API to be used without any authentication is rarely a valid choice, except in the case where you are hosting a public data set.
You should have a relationship with who is accessing the data you hold. They need to be trusted and they need to be managed so that they can only access what they should and what they need!
Only store what you need
The best way to avoid an actor exfiltrating sensitive data is not to hold it in the first place. Only store the minimum that you need to provide the service. Encryption is a fantastic protection mechanism against someone taking a copy of your storage. However, if they are accessing the data through your API, encryption is unlikely to help as your API has the power to decrypt the data.
If you require data for a short period, such as for proving someone’s identity, delete it once you are finished with that step. Keep some metadata on the fact that customer X used an Australian passport to prove their identity but no details on the asset itself.
If you don’t want to go anywhere near that kind of data, you can use a third party such as Green ID to do that for you!
Where next after the Optus breach?
As alluded to at the start of this blog, there’s a massive cleanup exercise for Optus in this. There is even talk of Optus being liable for financial loss. This opens up a whole can of worms which is way outside my knowledge.
What I do know is that there are solutions out there that can help your organisations not be the victim of the next Optus breach. The good news is that they are well known, well understand and easily implementable!
Wrapping up
If you’d like to know more about the Optus breach or how you can validate the security of your services, please get in contact with us here at RedBear.
