By SidSecure | 9 November 2022
The Optus data breach via a vulnerable API is a widely known topic across Australia and abroad. As security professionals, the useful question is not "who is to blame?" but "what practical lessons can we learn from this?"
The Optus incident is a good example of the security threats to API interfaces. Several issues were apparent: the API endpoint appears to have involved shadow IT systems, it did not implement proper authentication or authorisation checks, and a test endpoint was public facing while using real customer data.
An API in its development and test stages should have limited inbound access: internal networks where possible, or a whitelisted set of IP addresses via firewall rules and ACLs where public access is required. Public release should go through change control including security penetration testing before exposure.
Developers are naturally given freedom. Educating them about current attack patterns matters as much as policy. If the people handling systems and data are not motivated by the requirement for security, they will find ways around controls.
Use scrubbed customer data (personal fields replaced with random but valid values) for testing wherever possible. Any system that stores, processes or transmits real customer data should be treated as production in its security requirements, with proper controls enforced from the moment it is deployed.
API security testing is one of the most common assessments we perform. For non production environments we specifically request whitelisted access so we can test thoroughly and provide feedback before exposure to the public. If your business can benefit from expert API testing, get in touch.