Cloud IR - same same but different

Cyberattacks, and especially those that lead to breaches, are becoming a weekly occurrence – but technology consumption has changed a huge amount over the last 5 years, so you wouldn’t be surprised to find out that the way we can react and prepare to these breaches has changed too. ?

There are 3 standouts for me that make Cloud IR different.?

The wildly misunderstood shared responsibility with your cloud service provider (CSP). You don’t know what you don’t know, and that couldn’t be truer. If you haven’t been through the situation of needing, for example, your M365 logs for an S1 breach – then you may not have the knowledge that it takes something like 24hrs to download 24hrs worth of logs. At a the time of crisis, uncertainty and potentially pulling your hair out, the last thing you want to do is watch your logs slowly tick along as they are downloaded.?

Until you have your forensic data and/or logs from your CSPs and SaaS tools, your data is not yours to use freely. That’s why having data stored, in a normalised and pre-processed format, that can be used at any point in the future is super important.?

A slight tangent but food for thought using the below diagram – is infrastructure security falling under the shared responsibility. Who’s to blame when you have misconfigurations in your AWS/GCP/Azure environments, and you’re breached? Well, I’d be pretty certain you’d struggle to get A1 service and support from the IR teams at the big CSPs (depending on who you are in the corporate world of course), so having a Cloud IR partner that knows how to use and manipulate the data, store it for you for when (yes when, and not if) its needed, and then hit the ground running as soon as a breach occurs makes complete and utter sense.?

Number 2, I think I’ll go with a difference in data (and infra environments). Your datacentre, your servers and most likely something you know in and out, so when the time comes, you’ll probably feel pretty confident you know where to go and how to get what you need, to get to the bottom of whatever is stirring the pot. For Cloud IR, the data, and the applications we get said data from, is now on external servers with a huge variety of complexity – and that gives rise to a greater likelihood of security incidents happening due to misconfigurations. Credit where it is due, the skill and ability people have now to build in the cloud is phenomenal, and that helps to reduce the chances…but there’s a big disparity in skills that are building in the cloud, and the skills needed to protect and respond in the cloud.?

Going back to data, and in parallel to the comments about a partner who knows how to collect, store and use data – you might have the latest and greatest, and best configured SIEM and SOAR tools, but they are there for their job and their job only – helping you in real time situations. The data we need as incident responders, and specifically cloud incidents, isn’t what your SIEM will give you, and that’s why having expert knowledge on hand for Cloud IR, someone who knows the metadata and what it means, is imperative.?

Last, and maybe the biggest challenge brought by cloud adoption, is repeatability!?

In an op-prem world, Joe Bloggs in the building next to you just shouted over the fence and said they have been breached and have a ransomware gang demanding 1 million dollars. It wouldn’t bother you because your infra is entirely different, it's your own configuration with its own complexities.??

But in the cloud, everything is dynamic, connected and up for grabs to a certain extent. A misconfiguration found in one CSP environment, can be repeatedly searched for and used time and time again to gain access. Suddenly when Joe Bloggs shouts over the fence that his AWS/GCP/Azure account has been taken over, you might be thinking if that could happen to you. Earlier this year Okta had quite a high-profile breach. Okta’s Slack channel mentioned AWS keys, which a certain hacking group then used to gain ‘super access’ to Okta’s systems…reportedly it was 2.5% of Okta’s users who were affected but it builds up the picture of how everything in the Cloud/SaaS environment can somehow link. Okta > Slack > AWS > Okta customers > and so on. That wasn’t a breach from a misconfiguration, but you get the idea.?

But, and a big one at that, this is where automation and the beauty of scalability comes within the cloud, and a tool that we can use. Much like the attacker can automate attacks within the cloud, we can automate incident response in cloud environments. Once we have a successful investigation, and code everything that doesn’t need a human touch, all of a sudden, we have the ability to investigate any number of customer Cloud/SaaS environments, based on the hypothesis of the breach, and give a thumbs up, a thumbs down, or maybe even some small alterations.?

IR in the cloud – it’s the same thing, but with differences.?