<div dir="ltr"><div dir="ltr">Official penalties helps make security top of mind, but realistically it should already be there anyway.  Optus has to know (or have known) that when something like this happens it has a serious impact on the companies credibility and costs them serious money in lost customers/future business.<div><br></div><div>However the simply fact is that most companies likely have something similar to this floating around somewhere on the website - no latter what controls they have in place. Possibly not as big as this one, but whilst ever humans are involved with the process, bug will exist. Serious effort should be put into minimizing those bugs, limiting their impact, and quickly detecting and fixing them, but odds are some will still get through.  It's one of the classic cases where the development/security process needs to get it right 100% of the time - 99.99% isn't good enough, and perfection is hard to achieve.</div><div><br></div><div>I've got a bit of experience here.  As well as previously working for companies that were involved in detecting/blocking attacks like this, over the years I've found similar vulnerability in dozens of websites.  Only a few weeks ago I found a similar vulnerability to the Optus one in the Dish Networks/Boost Mobile (4th largest mobile provider in the US) - <a href="https://blog.docbert.org/boost-mobile-vulnerability/">details available here</a>. In that case it was an authorization issue rather than an authentication issue, and the scope was less due to US providers not having the need to ID customers as is required in Australia, but the fundamental issue is similar.</div><div><br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>What seems to be the pervasive mentality is more akin to "it will never happen to us".</div></div></blockquote><div><br></div><div>Exactly.  The correct mentality is that it WILL happen to you. If you're lucky, the person that finds it will be on the side of right, and will notify you and you can fix it with minimal impact.  But if the wrong person finds it...</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>I'd suggest in the wake of this whole mess, it might be a good idea to go have a talk to the relevant people inside your various businesses and start thinking about how to run tabletop exercises on what would happen should a breach occur, and how it might happen.</div></div></blockquote><div><br></div><div>Not just should a breach occur, but multiple variations of what could occur. If someone contacts you can let you know of a vulnerability, how should you communicate with them. I've had too many companies simply fail to talk to me when I'm trying to report an issue (the Dish/Boost one mentioned above is a perfect example - to their credit we're now communicating on multiple levels and they recognize the flaws in how they handled it). If the notification is from a white-hat, do you have the tools/logging in place to make sure that nobody else has accessed the same vulnerability.  If it's a black-hat, can you tell what they access (if they technically had access to 1 million records, but your logs show they only accessed 3 then you're in a much better spot than if you don't know!)</div><div><br></div><div>Most importantly, have a path for people to report issues to you.  That could be via a formalized bug bounty program (eg, BugCrowd, HackerOne), but at a minimum a you need to have a path to reaches the right people quickly and efficiently.</div><div><br></div><div>  Scott</div><div><br></div></div></div>