CG - Cyber Crash Investigations: Seizing the Opportunity to Learn from Past Crises

right good morning everybody Welcome to day two of bides Las Vegas wooo okay so before getting started I just want to make some announcements make sure your phone is on silent and we'll have Q&A towards the end so I'll walk around with the mic and yeah let's jump right into it so the title of the talk is cyber crash investigations seizing the opportunity to learn from past crisis and our speakers for today are David dogs and Julia won so welcome over to you guys thank you thank you welcome everyone thanks so much for coming along to our talk um yep cyber crash investigations is what we're talking about today uh we'll do some quick introductions so my name is Julia I'm a senior manager at PWC Australia um and I've actually had a bit of an unconventional background so before I came into cyber uh I worked in comms and law but don't hold that against me please I'm um on the right path path now uh now I focus on incident Readiness response and recovery so what I look at is kind of endtoend helping organizations prepare for respond to and then recover from cyber incidents doing things like tabletop exercises um desktop simulations uh all the way through to kind of post incident reviews and Reporting um and the thing I love most about what we do and what we get to do is the investigative element and I think the kind of I studi journalism as well and the the legal element really ties in well so um I love trolling through the wreckage of bad things that happen so hopefully we can learn some things today I'll hand you over to my co-pilot Dave big True Crime f as well I think um so my name's David stocks I work with juler at PBC Australia um my background is a bit more of a traditional technology uh background Blended in with some international relations and politics um which has always sort of been a bit of a side interest to me um I've done a few things in security I'm a failed pen tester I tried it for a little bit I wasn't very good didn't I wasn't very patient um I then sort of moved into security strategy before sort of finding my passion in um incident Readiness response and Recovery um the thing that I really enjoy about doing what we do is helping people out during during the middle of a cyber crisis it's um really energizing I think to to help people through those kind of circumstances particularly when they're sort of fresh for people and they've not been in that sort of situation before over to you Captain thank you all right right so before we take off today I'll talk through what we're going to cover um you'll notice there's a strong Aviation theme and the reason for that is we're really quite taken with the way the aviation industry um investigates and reports on crashes that happen um you know understanding what the root cause of a crash might be and then providing some safety recommendations um we think that's a pretty good approach and it should probably be taken more for cyber attacks and we know that you've made some inroads here in the US um but we're hoping that we'll be able to share some lessons learned and contribute to that through uh some of the black boxes that we've had the opportunity to open during our our work and we have we've had a really good opportunity to investigate some of Australia's most significant cyber attacks in the last few years um for a big range of clients and organizations across different Industries so public and private sector um all kinds of shapes sizes and maturities of organizations and despite all that variety there are a few things that pop up time and time again and we started noticing some themes and we thought it' be kind of good to shine a light on some of those themes and maybe it' make people go away and and look a bit harder into the things that you've got in your organizations or with your clients and you can suggest ways to build resilience that you may not have thought of before uh so yeah that's what we're here to do and what we're going to do is talk through it in three different stages so how to prevent a cyber crisis or or try to do that and that's our kind of pre-flight check before takeoff um when you're in flight and something goes wrong how to do some damage control and minimize the impact if you come up against that and then how you can best respond after the crash so picking up the pieces of the wreckage so if we're all ready for takeoff I'll ask you to fasten your seat belts and I'll hand over to Dave to get started and I forgot to mention these are our views and not those of our employer so thank you thank you for that Captain um you know Kandy get rolling uh but before we do that we're going to run some pre-flight checks uh before we take off so we're going to get straight into that and I'll start off with multiactor authentication and password management and I know what you're thinking you're thinking Ro a security talk we're talking about MFA you know of course we know we should have MF everyone knows we should have MFA we've been talking about this for years and years and years and years we have um you know it's not a particularly new thing to say but we're not really saying have MFA we know that everyone either has it or or is trying to to to get there I think more what we're saying is that what we've seen in the in the in the Cyber crashes that we've come across is that it's often inconsistent so it's on some things maybe it's on most things maybe it's on your VPN maybe it's on your you know remote desktop services and um all these other uh remote access mechanisms but it may not be on everything maybe it's not on that one development environment that a third party is logging into or you have one particular service provider that it was really complex and they said it was going to be really hard to try and get MFA working so you've got some sort of exception policy for them and you know it's ipy listed or you've got some other control there but it's it's inconsistent um and I think that often causes uh cyber incidents uh that's certainly been the experience that what of what we've seen the other sort of thing that we've seen in this bace is that it's enabled and lots of users use MFA but it's not enforced um so there are some users who don't have to use it and those users present a window into an or into an organization um weaknesses in conditional access policies often conditional access policies will be used to try provide um you know a balance between usability and security and that's a good thing but sometimes we set them up in ways that um leave too much room for uh threat actors to take advantage of so it's not have MFA of course everyone knows that we should have MFA it's it's about looking in your organization for what those what what what are what are the bounds of your MFA policy you know where are the different environments where you have this we applies and and what are the weaknesses that someone might be able to exploit on password man uh it's about storing keys and passwords in in in plain text that's the sort of thing that we've seen time and time again um causing problems and it's most common um in um in code looking and finding sort of clear text apis in in code that seems to be a really common thing and it allows threat actors to escalate their privileges gain access to new applications when they uh break into an Environ and they're rumaging around trying to extend their access um identity and access management um the the sort of key themes here that we seem to see are that there are too many domain administrators doing more than just domain administrator things um I'm sure that's a a common sort of thing that a lot of you would have experienced as well um but domain admins should really be focused on just doing domain Administration they don't need to be server admins um and uh when you do that you increase the the risk that someone's able to escalate privileges really easily or quickly when they're hunting around an environment um there's not enough use of the protected User Group um Microsoft provides a lovely way for you to try and protect some of those accounts um but we don't see it used enough and that's you know particularly the case in sort of older environments you know that are kind of typical in large organizations where you know you might be running off an older active directory functional level you know this is often still an option that's supported but it's not one that's often sort of taken up or extended or used as much as it could be and it and it really provides some protections there um the last one under this is is around semi-trusted user group so if you think you're an organization where you have a a really large contractor base or perhaps you have a vendor with a large pool of users who are providing a service to you um or maybe you're a school and you have a bunch of you know trusted teachers and a bunch of semi-trusted students um who are all trying to break into the network I know I was when I was a school um if you have that sort of semi-trusted User Group what we've seen sort of time and time again is actually have a very similar level of trust as the rest of the employee base or the rest of the user base and maybe one that's not actually appropriate for the level of risk that they present you I know we're all sort of working towards having no trust whatsoever and strongly authenticating everything but in large organizations you know we're not really there yet um on patching and vulnerability management again it's a similar sort of thing to the uh MFA front we're not saying don't have MF we're not saying you need MFA we've got some fluffy dice uh we had a an outrageous speaker request for a pair of fuzzy dice to hang off the front of the uh excellent no thank you for that that's no much appreciated uh thank you and uh we also had a request for some novelty glasses so I need some audience parti is this what you asked for you anyone willing to wear some of these and stare back at them thank thank you that's uh that's going to make you all f intimidating that is uh that that's fantastic and I'm I couldn't be happier I couldn't be happy uh back to patching obviously that was very distracting but but I'm here for it um back to patching I think the the focus is definitely on your riskiest assets we're not saying you know patch everything obviously everyone knows that everything needs to be patched all the time and we would do it as much as we can but in any organization it's a question of allocation of resources um we we know that there's only so many people and and uh so many teams available to go and um get things patched so it's about focusing on the most risky assets 48 hours for a critical patch across the board sounds great but like your VPN needs to be patched within a couple of hours not within not within a couple of days and uh for other services things might be able to wait a little bit longer um don't let over engineered Change Control get in the way you know we've seen cases where there would have been a patch applied but it needed to go through a approval process that had like 11 approvers on it and the you know the 10th person said n like it wasn't it wasn't there it was on holiday and the change failed because you had too many approvers so don't let that sort of over engineered Change Control get in away or if you are finding that it is the case find out who's the blocker um and and start reporting those names um lots of good work is undone by running end of life platforms and applications um it seems to be a really common theme that uh you're always running into oh yeah but we do have that one Server 2008 server you know that's that's sitting there and you know we've got it wrapped in W as best we can but often it can be the thing that gets you you're done over um lastly on this point making responsibility for patching clear clear so often we found that questions about who's patching middleware or who's looking after end user applications on servers they they're sort of like middle ground in terms of who's actually responsible for them within an organization it's not it's not the Wintel team and it's not the Unix team and it's not the end user applications team so so who's responsible for those things trying to work that out and make sure that there's clear accountability for it really important um and lastly on the pre- takeoff checks front uh we're going to talk about uh some third party risk management um sort of items that seem to crop up and uh really that goes to a little bit too much trust with data exchange um you might often know what a third party has in terms of the controls of they have uh um implemented you'll often ask in your third party you know Assurance requests you know what controls do you have in place um you know and here are all here are all our controls which of these do you have or maybe they'll produce a third party report for you that that sort of Industry standard one um but you might not understand the processes they use where does data actually go in their organization when it's your data so taking the time to sort of understand that is really important and lastly um making sure that the contractual framework that you have with that third party gives you the room to have good security conversations and and baselines make sure that if you've got a contract that's been going for 10 years has your security risk appetite changed in those 10 years then you probably if it has then you probably need to have another conversation um so with that I'll move into a bit of a case study um after this short water break so I want to talk about an organization um that about a year ago uh experienced an incident and they thought that they had MFA in place but um a threat actor got a hold of some credentials um we don't know how that happened like they could have been sold they could have been reused um they could have been fished or mal or device but whatever we we don't know where the where the threat actor got the credits from but they did um and there was this successful log on um the the threat actor was able to log into an M365 environment they were able to access email SharePoint all that sort of stuff and the organization had set up M365 um to enroll users into MFA and but but MFA wasn't strictly enforced so it was enabled but it wasn't enforced and what that meant was um there was a whole group of users um executive users all of the IT team who were logging in every day with MFA and there was just this sort of like subtle conscious feeling that everyone had which was oh yeah we've got MFA we've got MFA in place um you know unless you're looking at those actual conditional access policies and actual um and actual MFA enrollment policies then you're not going to know necessarily that well there were some user groups who weren't on that policy and there were some user groups that weren't in this conditional access policy therefore there's a set of users that actually aren't challenged with MFA at all in any circumstance um and and what that meant was that there were some accounts that were able to log in without MFA such as this user so when the threat actor managed to land on this user's credentials they're actually able to get into environment start accessing email and um actually cause the business email compromise so it's really important to try and make sure that you know you look for those gaps in MFA policies you look for where there might be weaknesses where on the surface it looks like there as a policy and with that I think we are ready for takeoff um and I'm going to pass over to my co- Captain to get us into the air it's very funny looking at at those glasses I really appreciate that um okay we're up and we're in the air so let's talk about damage control control so if you're in the air and you notice that things are looking a bit dodgy or there's lights going off and you're not quite sure what's happening um these are some of the things we see that organizations either do or fail to do that uh can either increase or mitigate the damage that they face as a result of these cyber attacks that we've responded to so the first one is monitoring and detection um and what we see time and time again is despite people having kind of all the bells and whistles and the shiny tools that you need and uh out or socks that cost a fortune or internal socks that cost a fortune for that matter um there are blind spots and there are overlaps and there are things that just remain unseen until someone gets in and then it's too late um and what we see as well is people are paying an absolute Fortune for all these things and it's like you know front line you all need it but you haven't actually tested uh put it in practice and put it to the test and you know red teaming is such a huge element in that and just making sure that you've actually put it to the test with some weird and wonderful um situations and made sure that it's going to perform for you um the other thing is alert fatigue so uh I'm sure you've all come across this but we've dealt with organizations who had the alerts they were right in front of them but they were sitting amongst kind of 50 60 70 other alerts that they were getting daily that were false positives and what that meant was they were ignored and unfortunately the the whole thing was rendered rendered useless because everyone was a bit complacent at that point and no one picked it up um the other thing is if you do have an Outsource sock that you're working with uh we often see that the escalation paths in are unclear especially if that Outsource sock hasn't come up against something that's really caused for concern before um one organization we helped respond to an incident their Outsource sock uh escalated uh a pretty um pretty damaging critical alert through to the service desk instead of the Cyber team so it sat with the service desk for 2 3 days um untouched when it should have been kind of picked up and really handled with a great deal of urgency so there are some of the kind of pitfalls we see in the monitoring and detection space um data management makes me want to pull my hair out it is the one thing that people don't tend to like do well until it's really too late um basically what we see is there's always always a whole heap of data that doesn't need to be there that's there and it kind of amplifies the effect of an incident by you know multiple times and I don't know if anyone went to Christina Lou's talkest today about not actually collecting data that you don't need um but I think we're a bit behind the eight ball in that sense and a lot of organizations only just changing their data management strategies to kind of keep up with that with that approach but when we come in after an incident it's amazing how many times organizations don't actually know what they have so the first time they're doing data Discovery is during an incident response and what that means is your place you you got to like increase your team by a factor of 10 to kind of do all this data analysis and troll through a whole bunch of unstructured data which can go back years and decades even um it introduces all these new you know legal and privacy elements that you wouldn't otherwise need to deal with and you know the whole place is crawling with lawyers and no one wants that and it's just a nightmare so um the other thing we see is people using the wrong systems and the wrong um applications to store and process data and a lot of it you wouldn't kind of think about until it's too late but um not using file repositories as a dedicated file storage um place is is a nightmare because if you're having data passed through things like um email email or file servers or things like that and it's not regularly cleaned up um that can be absolute chaos if you know one of your mailboxes gets popped and that person has delegated access to someone they shouldn't or someone who's pre