Unpacking the Ticketek data breach with industry experts!

um welcome to today's webinar today we'll be diving deeper into the tick data breach um I'm joined by vaugh Shanks and David Dennison um Dave V would you like to introduce yourselves okay I'll go first thinging I'm not on mute already so hi everyone uh thanks for your time today uh as we as we unpack this the tick Tech dat Bridge here and we're lucky that um mandans uh also provided their instant response report on this so that'll that's providing going to provide some further detail there essentially my background we're going dating back a bit 16 years Special Forces 16 uh and 16 years security intelligence and then out of there and into internet 2.0 as the vice president of the Consulting practice Advanced practices and the Chief Information Security Officer Chief security officer there um there for a number of years and then then out bit bit further study and then M Ray and then C with Cy and doing a lot of Consulting there with Cy at the moment that's sort of me and an nutshell thanks Dave yes I'm vaugh Shanks um co-founder and CEO at sidearm Technologies and we're actually a software vendor based out of Melbourne and what we do is we make software used in security operations centers and it's based around the simple idea of case management uh so we help customers in federal state and sorry federal government state government um Department of Defense um and critical infrastructure and a few other Industries um and yeah very uh proudly australian-owned and Australian operated uh my own background is uh largely government working in government and for government uh building software and uh I'm very interested in this breach because uh I like probably many of you on the call got an email uh on late on a Friday evening on the 31st of May and uh I'm a a a customer of tich there's also a lot of interesting lessons here in terms of supply chain and finally as a software vendor I think there's quite a few things that we can look at uh from the from the angle of snowflake who are hosting the the data but I won't go too far into that uh and spoil the show so yeah back over to you Ray NIS thank you V thanks Dave for for your introduction as well um I'm Ray Panda I'm the director of GRC at cybernic um we're a pure play cyber security GC consultancy um and we also provide penetration testing services um without further Ado let's kick into today's topic so we'll be um we'll have a quick overview about the incident what happened um what parties are involved uh by the sounds of it until until about two days ago it was only about three entities um that were impacted but based on Mandan report this morning um it looks like it's a larger chunk um impacting more than 16 um we'll also unpack some public statements made available um and what action items vendors as well as individuals should take um to protect from cyber attacks in the future here we've got a chronological event update of um when the incident actually started um until the date so until the 2nd of June um vaugh would you like to unpack this so what we have here so so this uh was hastily together after mandan's report that came out while we were sleeping last night and what we're showing here is where tich fits in relation to the broader set of issues that have been uh confronting people using snowflake um so from mandian timeline uh they discovered that they had a report uh from one of their customers that uh that there was uh you know potentially data breached from this customer and they went to investigate and found the data had been exfiltrated from a snowflake instance run by that customer um so that was back in April uh then we've got uh April 17 uh the the use of this tool called frostbite uh code named frostbite it's got another name which I won't say uh in front of a family audience but um uh someone wrote some custom software to exfiltrate data rapidly uh then uh they started their investigation on April the 19th um come May the 14th Mandan has suddenly realized uh that this this issue is probably going to be manifested across a lot of snowflake instances um and at around the same time um Santander uh so a uh big European based Bank uh revealed that they'd had a a massive breach and I think Ray from your report it was something like 500 demo databases or something is that right we're we're compromised yeah I think it's just over just over 500 yeah 5 or something demo instances yeah this threat actor is going going after sender hard and you know it's a bank so of course if you're a criminal uh that's that's the you know really caps off a great career in crime then Flash Forward a few days and Ticket Master released a Form 8K to the United States security Exchange Commission and this is where you you have to State anything that may have a material impact on your Revenue uh so that your shareholders can be aware that they're risk now in this case Ticket Master said uh you know they they'd had a breach of um over 500 million customer accounts uh and they said this will have no material impact that we can see on our business which is pretty cold uh but that's that's the reality of the of the cyber world we live in um and then wind forward um a few more days uh we had the the snowflake data for sale on cyber crime forums and I think that was uh The Ticket Master data I'm not sure if the the Sant tendura data went for sale as well maybe it did uh May 30 uh mandant sorry not mandant snowflake released released guidance on or a statement to say some of their customers have been um have been attacked and also a set of guidance on how to to hunt for threats so a set of IP addresses look like mostly um VPN exit nodes uh and then a few commands if you see these database commands running in your snowflake instance chances are you have been compromised if you see these user agents chances are you've been compromised um the day after that and again uh Friday night disclosure uh around sometime at around 9:30 p.m. um tich um put out a notification uh that got picked up by the ABC here in Australia and some other news outlets and that was um yeah pretty much all over the news by Saturday uh that tiger Tech had been done so tiger Tech private Australian company very different to Ticket Master which is a big global company headquartered in the US uh and you know just a coincidence that they basically make up the the duopoly that sells most of the tickets in Australia which means probably just about everyone in Australia who has ever bought a ticket uh is somehow swept up in this so what we don't know uh we do know that tich claims they've notified the OIC the um the office of the Australian gosh I'm gonna foret information commissioner thank you I always forget that acronym uh they've notified acsc you can report a cyber crime to acsc what we don't know is when they first discovered they were compromised so did they get the guidance on the 30th of May and do a very quick hunt and in fact discover they've been compromised and rush out a press release or the less charitable interpretation is they've known about it for some time and they thought we're going to drop this on a Friday evening uh and hope no one picks it up uh so obviously all speculation we can't really know what happens unless they come out and give us a blowby blow but that's essentially how it went down and then we have June the 2nd a joint statement coming out um about the investigation and uh since then there's been some yeah some other snowflake have been incrementally adding to their guidance and uh and there's been you know various other Revelations have come out so that's basically where tick Tech fits in the broader scheme of things and uh obviously it's a matter of significant National importance but I would say on the global stage it almost student rate a mention next to Ticket Master in Sant andere so yeah yeah and then I'm tying it back to the threat actor as well um initially the group shiny Hunters claimed um that they were responsible for the incident but now it turns out it's actually UNC 5573 are they actually the same group or same entity um are they different no they're not there's a whole supply chain at work here uh there are initial access Brokers well not even initial access there are there are people people selling um or giving away stolen credentials uh that's that's happening way further up in the supply chain so info steel is being deployed there is the 5537 thread actor I think we need to find a a better name than that something that's more uh more you know something with some kind of anime character but uh so so they are the ones who have initiated this campaign against snowflake customers using credentials that they were able to get from info Stealers and then shiny Hunters I believe actually bought the data that un 5537 had stolen and then shiny Hunters are now trying to get a ransom for that so my understanding is they're more of a uh you know a bagman type operation as opposed to doing the you know the xfill yeah and from what we know um the SEC were able to bring down one of the websites where data was up for sale um but they've quickly created another site as well um so it's still off for grabs and I think they're demanding um for Sant demanding about $2 million and um for The Ticket Master they demanding about just over 1.5 million which is which which is quite a significant amount right yeah it's those amounts are that's that's life-changing money for a threat actor um in terms of the amount of damage that's being done by this incident at large uh it's Chum change really the and I think that's something people forget is that the proceeds of crime are a fraction of the damage caused by the crime and and something else that's not actually shown on this timeline because I think snowflake were pretty Keen to bury it because it was full of mistruths at least read that way a group called Hudson Rock actually interviewed one of the alleged alleged UNC 5537 threat actors and uh there was some there were some statements made about how they had hacked a snowflake employee which made it sound like snowflake itself had been hacked but turned out it was just yet another credential theft and a sales engineer had a their database rumbled sometime in um earlier this year or late last year um there was also something in there where the threat actor appeared to give the uh to give the impression that what they really wanted to do was to pressure snowflake into paying them so if they managed to uh extort enough of snowflakes customers maybe snowflake would be fearful of the backlash and would pay them a larger amount say $20 million in order for them to cease and desist from their activity and uh and stop harassing these snowflake customers but snowflake it seems have denied any wrongdoing and I think quite rightfully taken a stand against this and and said No in fact this is a shared responsibility model and uh you know it's it's up to the customers to you know to protect their data better but we'll talk bit it's interesting B that that you know mandad tracked this threat Act uh and this info stealer um back to snow like involved with snowflake but in November 2020 and now it's you know so there's significant you know period there you know three and a half years and then and then these have started to come out this year so there was clearly snowflake would have been aware of a problem though as well you know back in in 2020 uh yeah I I think if they've been monitoring info stealer logs although it's not it's hard to tell whether the info stealer logs were actually capturing credentials that could be tied back to snowflake instances or were they credentials that have been reused across many systems and the thread actors were clever enough to figure out that that this user is the same user that is a snowflake admin and we can use their credentials to access snowflake when in fact they might have leaked it on some other website um but certainly it does beg the question about whether uh whether snow lake is is aware of um you know these info stealer type accounts that are producing all this information every day and and you know there are people who are just not changing their password for several years yeah I think I think that's right and as you mentioned the shared responsibility model and I suppose the sharing of information when this comes out because if this had been you know made aware then companies could have you know been proactive as well like essentially the uh Cloud providers responsible for the security you know of the the cloud and then you're responsible for your data that sits within it but yeah which we can get down to later but uh yeah numerous measures could have been put in place as as you know over and above the what's mentioned in the report by uh Mand and the report also um reveals the whereabouts of threat actors I'm So based on the report that was released this morning um I believe one of the members is in North America um and the other one's tied to Turkey so they're able to um jot it down but they're probably not able to identify the exact person um moving take very long for them to find the North American uh individual I don't I don't think that's going to end well for them definitely not um this is the communication sent out by tich on the 31st of May um around 10:30 p.m. um this was addressed personally to myself um and based on this uh they've basically told me that they've notified the Australian cyber security Center as well as the office of the Australian information commissioner um and they' they provided some level of assurance that you know the the passwords are encrypted um you know my tick account itself is not compromised um and my identity documents were not shared right um they've also further um provided assurance that my credit card information was not impacted as well but what was impacted was um the threat Act is well able to get hold of my name uh my date of birth and my email address I think it comes down to what can a threat actor do um with a name um date of birth and email address right so what sort of damage can they cause well they can they can that can be the start of of uh you know fishing campaigns spam like text M you know it's just as they've sort of said here they've they've matched up they've got say they've got some details of yours Ray but then they can go back through other historical captures of other data and then cross reference and then you know with big data then look to form a more in-depth formative picture of yourself to then decide how they wish to Target you you know that's that that's you know in one way um for for me yeah there's a couple of couple of takeaways here and I noticed the wording on the tick Tech communication was very very specific it said the as far as we know the personal information that may have been exposed was the name the date of birth and the email address now tich also holds your home address they also hold your credit card number um now clearly the home address wasn't compromised um and that tells us that the home address presumably was never loaded into tick snowflake instance um the credit card number as well credit cards weren't compromised and that tells us and tich are very careful to point out that the credit cards go through a different channel so they've done their PCI DSS homework check but what they haven't spoken about is what other information about you that is not personal information may have been captured in the breach so we can speculate but you know are the tickets that I bought to different uh you know music events Arts events uh you know games of footy are they are they part of the breach uh I mean when I look at a platform like snowflake I mean what it's used for is doing data analytics uh they use it for feeding AI they use it for doing other kinds of statistical analysis on data uh it's a it's a sort of data warehousing and workflow and prep Tool uh it's a very sophisticated platform it's not cheap I doubt that the information that was stolen was only your name and date of birth and email address so if you got an email that claimed to be from someone that seems to know what footy team you go for because you bought a lot of tickets to that to those footy matches and they have your email address and they're you know giving you a surprise on your birthday I would potentially be careful because that that data could well be in the breach uh just we don't know yet yeah so I think there's there's a little bit more to it uh tick Tech have told us the minimum and and they've you know in one sense they've done the right thing they've told us what we do need to know but there might be some other things we don't know yet that have not been revealed so i' I'd be careful what other collateral you know threat actors might have on you you definitely need to be vigilant and keep an eye out for um suspicious links and and targeted attacks like you mentioned for um this is one segment of the ticketed communication that was sent out on 31st of May right um and subsequently a couple of days later there was another bit that was sent out as well let's unpack that bit that's the second communication that went out um and it was General guidance around cyber security actually ra if you go back to the previous one yep and I missed this actually until someone pointed out to me I'd missed this cuz I I got the same email as you mine I got another personalized email just like yours if you look down in the second to last paragraph it says we recommend that you review the cyber security guidance available at this link and is actually in almost the same color as the rest of the text if you click that link that takes you to the PDF which is in the next screen shot that one there and this is it so it's a PDF you can download from Tick's website and this is this General advisory around dos and don'ts right so if you've been um victim to breach what should you look out for what what you should do and what you shouldn't do do you do you think this is a good um communication that was sent out I was left scratching my head to be honest I thought most of this is data you could get straight from cyber. goo. auu or any other reputable credible Source um I think every you know every uh state or federal government agency has something like this you just link to cyber. goo. honestly that one down there under security with um check the strength of your passwords on password Checker websites I was curious I was like what what are they doing here this this feels like this is insane it does actually go to a New South Wales government website which and I've confirmed this today actually has a password checker on it uh the instructions are you enter your password in the box and you check and it tells you if your password is good or not now I don't know what possessed people to do this uh my advice is never do this it's probably on a local Javascript app it's not it's not actually going to leave your browser uh but you should not be sharing this with anybody that you care about uh because you're encouraging them to test their passwords on password Checker websites I mean this is just like a terrible idea terrible idea it it Rees of actually um I can't remember what was the hotel chain in in the US that was um that was breached I can't think of MGM um MGM casinos in in Las Vegas oh no I think it was no it was it Hilton or something um but years ago it was years ago and and it was they bought another another hotel chain and then and that was extremely poorly sort of uh poor security anyway when everyone's data got breached the email that was then sent out was a um again was a nefarious uh link to you know claiming to support because i' had all their accounts then then emailed everyone saying register here provide all these details you know to um get benefits and support and we'll support you so they got done again yeah so sending out something where you've been done with a link to put your password and it's just yeah so the expert advice here clearly is not to follow Tick's advice on this particular matter obviously um remain Vigilant against um the risk of fishing attacks but do not enter your password anywhere impact so what what's what's the what's the impact on affected parties so um by the sounds of it it's not just ticket tick and Ticket Master and sand Tander um about 165 more organizations will be joining the party um unfortunately um it's not good news there right so there's obviously heightened data exposure um leading to financial loss reputational damage needless to say um as well as legal um implications right um but vaugh if we want to take if we want to take a step back um and then dissect what actually happened so it is my understanding that data stored on snowflake databases were leaked right so through um stolen credential is that exactly what happened yeah the best understanding we have uh you know given this this uh breach is probably a a a copy of of the sanur breach and The Ticket Master breach and and all the other the breaches that snowflake are describing is what we have is a credential uh so a username and password combination that had been previously used somewhere else and was was stolen with an info stealer has basically been used to provide authentication to this snowflake instance that TIG Tech um had their data in and the thread actor has been able to use that credential pair to go in through the front door and essentially run a a common ordinary database client of some description and just basically pull out all of the data uh so that there's no no fancy malware being used here there's no you know no no special like remote code EXP it's literally just logging with a username and a password getting a a standard database driver and just exfiltrating as much as you can now there are some mitigations I think we'll go into that later but yeah it's it's not it's not a very sophisticated attack uh and I don't think anyone is claiming it sophisticated so yeah that's my read yeah and obviously from from legal implication perspective um in Australia we obviously follow the Australian Privacy Act 1988 um and there's um if if it's a regulated entity um if it was a bank like sender if sender was Australian bank then um obviously AA would would would jump in there as well but as of now um I believe tich is the only entity that we've recognized as impacted um from European perspective U there's gdpr um and in America obviously you've got the Hippa compliance that might that might have some legal implications related to this incident So vaugh based on what you're telling me it was um a simple login um to exfiltrate data which could have been prevented by using secure password or rotating password or as simple as having a multiactor authentication in place is that correct yeah either uh having a unique password would have probably prevented this unless the info stealer was running live on the machine that the individual was using to uh to legitimately connect to Snowflake and and then they would able to get that password uh off the machine as it was being used for snowflake but assuming this is a a credential breach that happened uh some months ago presumably they've reused the password so first of all using a strong and unique password would have potentially defeated this attack using multiactor authentication would have potentially defeated this attack allow listing so that means and and don't get me wrong snowflake has very sophisticated security they they support all of this stuff you can Implement SSO you can have certain IP ranges that are allowed to connect anything else traffic gets dropped if that had been configured by whoever set up the Ticket Master instance uh they could have avoided uh this this outcome and just in terms of the the regulatory angle you know it's not critical infrastructure but they do have obligations for notifiable data breach and also to um under the revised privacy rules they could be liable um for you know pretty severe penalty and rightfully they've notified the um OIC as well um From oic's perspective then Dave um what do they do upon notification well you've got you know with with sort of data like this I think it's still 30 days you've got got to notify um then there's a range of measures um that they can undertake um but and they could be liable you know obviously you know Financial penalties I think sry you've asked me question I didn't quite go into that one in too in depth there but um so I don't want to I don't to speculate to you there but um oh we may have lost Ray yeah I'm back sorry okay if I could add to that uh so yeah it is still 30 days for OIC um there are other government entities that have shorter time frames but tick Tech is not beholden to any of those um there is however uh the OIC can decide as they've done with medy bank uh to go after tick attack and uh and to make them pay and I think the language in the Privacy Act and the Privacy Act amendments from late last year so that they're not going to face a $21 trillion fine like like medy bank is currently looking at but the language is that they could be find up to 30 of their annual revenue their annual turnover uh now I because ticket take is a private company we don't know how much that is uh but given the number of tickets they sell that is a decent chunk of change uh so they could be facing a huge fine and I think the specific language is for anyone who is found to be interfering with people's privacy and interfering includes collecting information and then putting it behind flimsy authentication so uh it's you know it's it's perhaps not looking good for tick Tech Y and we can only hope that there was no card holder data as part of it so no no credit card data because on the Sho volume of transactions um tich performs on an annual basis that'd obviously be um a level one Merchant um and the implication of data Bridge of that nature would be massive from financial and penalty perspective as well um so yeah just looking I think well the incident done um how do we prevent um such in incidents in the future um and how do we ensure better security so V you touched on MFA and then password obviously to start with but other than you know like making sure we use secure passwords we rotate them and we enforce MFA um so clearly obviously snow um wasn't on the wrong here right um as a vendor they've got that security feature made available for people to come in and use um it's the users complacency that has led to this incident correct I think I think uh Ray like absolutely yeah who knows why I think there's the question there I saw why wasn't MFA used no idea you know like it's um that that and the yeah passwords you know not being allowed to four four years or what have you having the same password password for the four years you know rotating passwords updating passwords not using the same uh username and password across multiple uh logins but I think um you know beyond that you know for these cloud infrastructures like you know a data loss prevention uh tool us user Behavior analytics uh you know would have detected uh essentially all of this uh being removed you know like obviously the cheapest the cheapest thing and as War said that would have would have stopped all this MFA you know um and uh you know rotating the breach breached uh you know passwords Etc so you know if if you know these businesses have um you know cyber threat intelligence does does this monitoring um and it makes them aware of um you know employees breached U breached data and then you know as you get on you can like yeah put those uh dat you know I can't figure out why they don't have a data loss prevention tool you know and um and behavioral analytics on this that would have detected it you know like AWS you know you can configure guard Duty as your Google all have all have inherent these uh built into the platform that you can enable so I'm not sure why that you know this is because as we spoke about there can be the financial penalties but it's the reputational damage as well you know if if everyone else gets um gets breached but you know say ticket Tech didn't that's a competitive Advantage you know what you know so this is you know looking at that bigger picture and what does cyber security um you know enable it does enable competitive Advantage so that's yeah that's that's very interesting I mean from from vendor management perspective right managing your supply chain managing your second party third party and fourth party respectively I think comes into picture as well um the main report did mention something about um contractor accounts being used um V do you know much about that yeah so snowflake is a very specialized environment of course not every organization is going to have internal expertise or the time to train people so one thing you can do is hire Consultants or contractors to implement it for you and of course those people aren't using your corporate infrastructure and according to the ment report um some of them were using they were bringing their own device to do the work and that could be the same device that they use for gaming or even downloading pirate content uh which we know is a great way to get a um an info stealer uh deployed on your on your machine and that is potentially how those credentials were were getting stolen so in terms of uh what the end user organization could have done better uh if you do get a contractor working on an untrusted um host to be working for you in a in a shortterm capacity you could for example rotate all the passwords after they depart you would probably want to also knowing a bit about how um like I read read up a bit on how snowflake does its Key Management you might also have to actually deactivate those accounts for a period of a few hours so that any uh any residual uh credentials get uh expired and can't be refreshed uh and then bring the account back online you know with the updated password um so a few things you could do now as a vendor um and I realize you know the the the language and snowflake is very keen to push this narrative is that uh is that uh this is really it's a shared responsibility model and the customers made a mistake um but as we saw with with AWS and the public S3 buckets uh as a vendor I think it does behoove you to use guard rails to prevent your customers from making these sorts of mistakes and I think a couple of things they could have done so apparently if you believe the Hudson Rock now deleted blog post one of one of the engineers at at snowflake was was breached and clearly that that allegedly happened late last year uh I'm going to use the word allegedly a lot because we can't entirely trust the threat actor but I will say the the identity of the the individual who is alleged to have had their credential stolen and abused seems to have been largely cleansed you can find a a sort of a Tombstone where their LinkedIn page used to be and and a few other things have been taken offline so I think it is a real person and they are actually uh probably getting harassed quite a bit over this uh but the question is you know if if you were doing uh you know if you're running an organization avend all the size of snowflake uh should you be using thread Intel uh to detect uh you know when when user accounts are potentially for sale you know through info Stealers or on the dark web you know can you actually front run that with rad Intel and be aware that that some of your credentials are compromised some other things because I was really geeking out on this I found a a video where someone was showing you just how easy it is to set up a snowflake trial and so the guy fills out the form he gets a login panel he enters his username he puts in a password twice and boom he's away at no point did it say would you like to install MFA we strongly recommend it um there were some password complexity requirements but that was about it and I think some advice recently from the US government I think it might have come from Cesar or NSA was that vendors should move towards not so much shipping software within a hard guide you know you see a lot of software it's like all right here's the software well if you want to switch on encryption you know there's a special magic button in this control panel instead release everything with maximum uh you know security lockdown apply sled and then have a softening guide so you can say look if you can't use MFA for unspecified reasons maybe you work in a in a government facility you're not allowed to bring your phone in so you can't really be scanning QR codes off a screen okay you can switch off MFA at your own risk but you got to click through a warning to say I know what I'm doing um if you want to roll without an allow list okay so we ask you when you when you sign up what cider are you coming from if you don't have a CER or you can't think of one you have to click through a warning saying I don't know what network I'm going to be logging in from I want to open my instance to the whole world so you're knowingly making these uh these decisions to reduce your security posture and the vendor is trying to guide you towards better decision- making I think that would be an improvement that I'm sure would would be beneficial for everyone yeah definitely I mean security does come at at a cost and that cost might be convenience right but then if you do a risk analysis and do a cost benefit analysis um you know do the cost outweigh um a minor inconvenience in terms of the user experience um and again it goes to show the importance of Frisk assessment right um vendor reviews as well periodic vendor reviews making sure they're doing the right thing um and then on on post sorry post vendor review um I've seen a lot of organizations perform a vendor review but not do anything with the findings so part of this part of this exercise if tich had done a proper vendor review and done a risk analysis just on should we enforce um multiactor authentication and what are the ramifications of not having it enforced um if they' done that and then hopefully had a risk treatment or mitigation plan against it that could have Pro probably prevented the attack as well sorry the data proof and I think some of the problem with systems like this is maybe when they signed up for it they signed up for a demo or a Pock you know so you sign up thinking well I'm just going to use you know admin 123 because after all we're just going to throw some synthetic data into this platform and just see how it looks right and then time goes by you forget and you start loading real data and before you know what it's being used for production workloads and you know we end up with a situation very similar to what we saw with Opus where you have your entire production data set loaded into a system that was actually only used for test I mean we don't even know whether tick Tech was running this as a production workload or they were just triing the platform but happen to use real data in it we don't know yeah definitely um now vaugh obviously you do this for a living you've probably faced a million incidents in your life and and Dave you you've let some um pretty large scale um incidents as well what are your thoughts and opinion um on how this incident was managed and what could they have done better well I think that uh the the communications the that that went out I suppose I I think there's a you know you can always be better being transparent is is the best thing and as one said like Friday Friday nights and and and launching that sort of thing I think uh essentially they should have I think you do want to collect you do want to come out with a certain amount of data to to explain the situation um and not just go we we're dealing with something we don't know what we're dealing with but but um yeah that's where that's where I think having your instant response in your playbooks and and of and have worked the process you know have have undergone this I think that goes a long way as we as we discussed about the you know the other the other um inform you know PDF that was sent out with the link to the um you know check your check the strength of your password and the like you know as we said should have just been you know referred to the acsc but but I think it's it's h working their process coming out with a with I think more detail than what they've actually you know what what they sort of communicated and communicating in honest transparent way and actually you know maybe make a statement see someone someone stand up and take take some accountability and responsibil and say this is the situation um we're dealing with it this is where we're at at the moment and and and explaining that don't need to go any Tech anything technical but but just communicate with the general public about it I think is um you know that that will always I think you know look better than just a statement yeah that was I think a common sentiment um I heard from a lot of people as well that they weren't aware of the incident and the organization failed to inform them that they'd been a subject to data bridge and um instead they found out from third party which is obviously not nice vaugh what's your take on it yeah I think I'd agree with everything Dave said and you know one thing I find particularly irksome is when you have a you know a a well-meaning and very you know a statement saying how much we care about you and we've done this and that and we're getting the best Consultants to make sure it won't happen again but then no one signs their actual name to it and I think contrast this with you know two flip sides of the same coin now snowflake have actually said we've been breached L they haven't been breached um but they do feel a sense of responsibility it seems towards their customers and the uh the SEO himself is signing off with his full name on the updates so he's taking full accountability for it and maybe they haven't gone into explicit detail about dates and times as much as I would have liked uh but certainly in the case of uh tich uh we haven't seen a blowby blow description of when when exactly did they become aware of the incident when exactly uh did they escalate when did they scramble you know some some defer assistant to come and sort it out you know why did they did they find it because I mean if they if they started hunting as a result of the the May 30 guidance released by snowflake it' be nice to know that's what triggered them to go and Hunt that they're being they're being proactive in discovering threats um but we don't know any of this and so we're left to fill in the blanks and and I think it's now on the flip side you know Playing devil's advocate while I would like all these things to be out there because I like to know the facts and we'd all like to know that these are responsible custodians of our data if I want to go see the footy next weekend where am I going to buy a ticket I don't really have a choice I can't see this other than coping a big fine I can't see this really doing any damage to their business I don't know anyone who is going to stop buying tickets uh because they were involved in a data um you could argue here are the things one should do to retain trust but you could also argue on the flip side they don't really need to retain anyone's trust because other than maybe the AFL or some of their larger suppliers who are choosing to sell tickets through them I don't think there's very much threat to their business I think that's a good point V I think it it's very hard for the individual to you know put the pressure on but I think you know these these big event like AFL what have you tennis Australia or something could they can they can be the ones that can say well hang on you know uh you know our clients you know are trusting you so and I think like you said before just to Lo back on it they they they said you know this data was captured but as we sort of had a look yesterday in their you know uh data and privacy statement what they actually collect is far much is is a lot uh is a lot bigger so I think it uh they could have explained more if like we can clarify that this was collected this and this wasn't collected or maybe it was you know we we can't determine yet but they definitely as you as as is evident in their um in their policies about they collect a lot more information and and I think that could go a long way to to clarifying for people you know what exactly wasn't collected and what was yeah and part of the problem is we're not regulated by any any legislation in Australia right so if there is an inent like a part from AA and if you're not an AA regulated entity in this instance obviously ticketed is a is a PTY LTD they're not obliged by any sort of legislation to come out and give us the facts are they correct yeah so yeah I mean one one of the bigger takeaways here I think is um the last point which is around user education right so your organization is only um as safe as its weakest link um end of the day um it came down to users not rotating the passwords users not implementing multifactor authentication or the organization as a whole failed in um enforcing the feature that was available um so I think that that's one of the key takeaways for our audience as well as um other organizations in the future is to ensure rotate your passwords invest a bit on user education and awareness training right um and then and emphasize on the importance of multiactor authentication I think right yeah and if I could distill it down into two to two um buckets I suppose you've got as you mentioned those there's those they're prevention prevention measures like if you went they can conduct these prevention measures by that the multifactor stanic so went back over it again and then your detection measures you know where you you can have uh you know data loss prevention and and you know us Behavior analytics and stuff I I think th those two things when you're running like prevention and detection and you know about it and you've got that um by putting those guard rails in and you you you know um obviously there's a cost benefit and Elis that takes place said but MFA doesn't real you know like that's where you can go well we've got this we've got you know we've got this much protect prevention measures we've got this much detection measures or you can work you can work that but you know that's that's like that should be I think a guiding strategy behind it you know for businesses to you know there some of the takeaways like you know th those sort of security measures how much you're putting into each and is that is that secure does that leave you with a secure environment yeah the only thing I would add to that is the uh I mention again allow listing as a powerful tool now I know it's Fallen a bit out of fashion with the whole zero trust strategy and uh you know we can open everything up to internet because everything is 100% secure right it's like well actually no we can't uh a lot of these systems do rely on um on credentials and it could be because there's a service principle that needs to log in and we haven't figured out how to implement mtls or some other kind of second factor for the service principle so we have a shared secret uh that's being transmitted over the wire and uh and anyone from anywhere in the world can can do that then I think I would limit it to say actually which IP addresses need to log into that it's a fairly crude form of um of security some people would put it down and say it's obfuscation um but it's actually very effective uh it's it's very hard to get inside that unless you can actually first get a foothold in the organization and then start doing credential stuffing so it just just putting yet another barrier in the way of the attacker yeah and definitely um post breach there's um it's it's a heightened alert level for fishing and schem risks as well so um for organizations um if you're reive any emails in a corporate um Corporate email I think it's important to look for minor variations um to verify the center and make sure it's legitimate and make sure not to share any personally identifi information um unless you share about the identity of the um of the recipient right um and then especially I think it's important to be cautious of emails that sort of create a sense of urgency right so act now or well the footy games tomorrow click on the link um to claim your free ticket um things like that so it's just important to stay vigilant um from an individual perspective though um vaugh what do you recommend um are there some recommendations for individuals to look careful yeah so anything suspicious uh i' saying this is this is probably more for your uh I suppose for for people who are at least part technical um SPF dkim and dmark are your friends you know if you are at all suspicious or if you receive an email from a user who's suspicious because or a relative they're not sure if this is legit uh just looking at the headers can very quickly reveal if it did come from the actual sender domain although I think a lot of the email providers will will block anything that uh that doesn't uh match up I haven't actually checked whether tick Tech implements dmar but I would imagine they probably do by now if they weren't already um the other thing that uh I changed my password on tich out of an abundance of caution now there is no MFA for end users uh they don't provide that um I did change my password because my rationale was well if if a credential got compromised for their snowflake database uh what if the same admin or an admin with a similar understanding or or lack of understanding of security is controlling other parts of their infrastructure and creating other opportunities and for all we know uh there could be other breaches going on but you know that's pure speculation um but no harm in changing your password um and actually a uh a an idea I heard from from a friend was um set the password to something completely random and extremely long that you don't even know yourself so just lock yourself out of your own account and next time you need to buy a ticket just click the forgot password button that means you have to log in through your your hopefully very secure you know uh uh email account you know whether it be Gmail or or Outlook or whatever with you know uh Global Enterprise grade security and retrieve your password that way uh by having a special link email to you uh so you know bit of a bit of a quirky way to go about it but probably safer than uh than you know having your account be uh be live all the time Y and and if you're a security professional I think one of the key questions that you can ask to your friends and family around who are not Tech savy and we don't know much about security is when's the last time you changed your password right um and if the answer is well I don't know you should probably tell them well maybe it's about time right because um credential harvesting has been been an issue for multiple years um and part of the reason we're talking about the pre at the moment is that as well um so I would encourage people anyone listening to this um maybe go out speak to your friends speak to family ask them when when's last time they changed their password and encourage them to change it is there anything you'd like to add on top of that day no no we do have a couple of questions here I see as well yeah sure sure let's take them I think can you see them Q&A Y no open questions I I I can read them if you want yeah two first one says why wasn't MFA used on these snowflake instances good question I I'll I'll have a crack and say well firstly uh no one asked them to set MF uh so that certainly the snowflake instance didn't say now do MFA uh and presumably they didn't think to do it uh it was just lack of Education uh maybe an oversight I believe now that they are working on installing or have installed MFA now yeah and it also begs the question around governance risk and compliance right so it needs to come from a policy level that's approved by the top management right within the organization that clearly hasn't happened here so um going back to the point that I made early on around risk management um this is part of risk management right um making sure you've got a policy that mandates multiactor authentication when you when you interact with um external vendors especially when there's personally identifiable information attached to it right so that's probably an answer to the question I'll just read the second one here wouldn't it be fair to say the whole issue could have been mitigated by them not keep Pi information when it wasn't necessary I last used TT service TIG about 3 years ago why were they holding my information for so long there is there is it's it's it's it's a question that um I guess we're asking ourselves as well um and well PCI guidance in in terms of storing card holder data is if you don't need it don't store it right um and that's a very logical justification um however in this instance they clearly have no it um I don't know why they require data birth um you know they're selling sporting events and in concerts and gigs right musical performances I do not understand why they require um date of birth to start with but yeah that's an interesting question T targeting analytics like emails and the you know so it's all yeah so so the date of birth not there to positively identify you it's more there just to uh to figure out what you might be into yeah and I think that's another like under privacy um you know really that this is where you coming down you know this needs to be almost like you know you know government Le here but um is there a requirement like when this it's not actually a requirement to buy a ticket I hate it you know you going to buy a pair of jeans what's your email address I just want to buy a pair of jeans can we just not make a simple transaction here that's all you know you don't need you don't need my email address for it so this is the thing like if they don't need it like that's where I think uh you know government can set these uh can set the agenda here um if it's not required they shouldn't have it yeah I mean if they want to know uh like you know are you are you into n music from the 1980s they could just say what year were you born yeah I mean unless they're planning to surprise me with a voucher on my birthday if I get an email on my birthday now I'm not clicking on that that's right 24 hours to accept you can ride it off yeah and I think the second bit to that question is lack of data retention policy as well right so like the gentleman asked the question last year's tick three years ago now if you're holding financial data if you're holding uh payment information things like that I think um the general rule of Thor in Australia is 5 to7 years that's that's a retention period I think health record is around 5 to seven years as well but I think it comes down to an entity identifying the crowns and the business requirements and then setting data retention guidelines against those sensitivity levels right um that also hasn't been practiced here by the looks of it yeah yep awesome looks like we're at time as well do we have any further questions take that as a no um vaugh Dave thank you for your time um audience have been brilliant thank you very much um until next time thanks R thanks Ry thanks B