The document discusses a major data breach involving Optus, where 10 million records were leaked due to inadequate security protocols and a vulnerable API. It highlights the need for improved digital asset visibility, zero-trust architectures, and better security practices to prevent such incidents. Various security theories are explored, including outside-in and inside-out perspectives, emphasizing the importance of monitoring and securing systems effectively.

10. Jeremy Kirk discovers the
leak on https://breached.to

13. 10,000,000 records * 0.4s/request = 1111 hrs 1111hrs / 46 machines = 24 hrs exfiltration

15. The unauthenticated API endpoint
https://api.www.optus.com.au

16. This endpoint was already known 4 years ago:
https://github.com/tkav/optus-data-usage

17. Leak deleted, apology issued

18. Why did this leak occur? We can think of this in 2 ways, outside-in and inside-out.
From an outside-in perspective:
From an inside-out perspective:

19. Why did this leak occur? We can think of this in 2 ways, outside-in and inside-out.
From an outside-in perspective
Lack of (or poor) security audit
Lack of interface visibility (not truly understanding the data perimeter
Lack of monitoring of endpoints - We believe that Optus did in fact monitor the
exfiltration and shutdown the endpoint.
From an inside-out perspective:

20. Why did this leak occur? We can think of this in 2 ways, outside-in and inside-out.
From an outside-in perspective
Lack of (or poor) security audit
Lack of interface visibility (not truly understanding the data perimeter
Lack of monitoring of endpoints - We believe that Optus did in fact monitor the
exfiltration and shutdown the endpoint.
From an inside-out perspective
Bad opsec security policies that would allow such an endpoint to be created in the first
place by developers or system administrators
Systems are not built "secure by default", or "correct by construction", instead they are
built insecure by default, and then security is bolted on top afterwards (security as an
after thought)
Lack of zero-trust, assuming that only a certain kinds of perimeter is needed, and not
encapsulating this information behind multiple-layers - defence in depth

21. https://www.frontier-enterprise.com/six-key-takeaways-from-the-optus-data-breach
https://www.protocol.com/bulletins/optus-data-breach-api-security
The point about “lack of digital asset visibility” appears to be pertinent.

22. Digital assets unlike physical assets start out being invisible.
Changes are invisible.
Perimeter is invisible.
Access is invisible.
To make digital systems visible, we need to consider both outside-in and inside-out approaches:
You can’t secure what you can’t see.
As systems get more complex, systems and secrets starts to sprawl out.
Outside-In Inside-Out
Monitorin
Visualisation -
dashboards that visualises
the digital castle
Secure by defaul
Logs

23. Future Risks and Future Developments
Zero Trust Architectur
Software Supply Chai
Secret Spraw
Centralised vs Decentralise
What is Trust?
What is trust? That’s a philosophical question to be explored in a different presentation!

24. Zero Trust
Back in 2013, Snowden revealed the extent of NSA spying in US datacenters

25. Perimeter based security is like a castle with only 1 wall

26. Moving to a world of Trustless (Never Trust, but Verify) Systems
End to End Encryption and Authentication at
every layer provides defense in depth
Fine-Grained Access Contro
Principle of Least Privileg
Confused Deputy Attack
Decentralised Control - Checks & Balances
Reduced Blast Radius - Limits Cascading Failure
Secure by Default
Increased Complexity - AWS IAM
Decreased Logistical Agility -
Lazy circumvention
Cybersecurity Bureaucracy?
Benefits
Costs

27. We need better frameworks and tools to shift magnify the benefits and reduce the costs
Sovereign
Identity
E2EE VPNs instead of Client Server VPNs
Capability-based Security rather than complex
and brittle and indecipherable access policies.
Access control policy requires a visual programming language.
Solutions?
No solutions.
But multiple developments
in token management
and policy engines.

28. Software Supply Chain Problem
Log4Shell
Left pad
Heartbleed

29. Secret Sprawl
(it’s kind of like Shadow IT)
Open Source
Decentralised
Secrets Manager
and Trust System

30. Centralised vs Decentralised
It’s about control.
Not about technology.
Single Point of Failure
Redundancy
Users as Stakeholders
Users as Consumers
Sovereign Identity
Sovereign Data
Outsourcing
Economies of Scale
Biased towards Outside-In
Security
(Security Perimeters)
(VPNs)
(Centralised Authority)
Biased towards
Inside-Out Security
(Foolproof)
(Trustless Systems)
(Zero Knowledge
Proofs)
Borderless and
Accessibility
The pendulum is swinging