Introduction
Welcome to our series on preparing for incidents in the cloud, the reason for writing this series is that especially in the cloud preparing for an incident is key if you want to perform 'proper' incident response. We have helped many teams in the past months with improving their readiness. Oftentimes this starts with a readiness assessment followed by specific recommendations on what they can do to be prepared. In the first part of this series we will discuss how you can prepare your team and organization for the inevitable, an incident in the cloud. In the second part we will dive into all the different logs you can collect, followed by part three that will explain what cloud infrastructure you can prepare before an incident.
For a CISO, mastering cloud incident readiness means more than just adopting new technology—it requires a paradigm shift in how you approach risk, visibility, and response. By recognizing and addressing the common shortcomings mentioned below, you can build a robust, proactive defense that minimizes risk and enhances your organization's resilience in the face of evolving threats.Call to Action: Review your current cloud incident readiness strategies in light of these insights. Identify gaps, update your IR plans, and schedule regular training sessions to ensure your team remains vigilant and prepared.
Part I: Ensuring access when it matters most
Every incident starts with an intake call, where we will go over common questions such as "What happened?" and "What have you done so far?", at some point in this conversation it will pivot to "What logs do you have available and can we get access to the logs?". Oftentimes this is where it gets interesting especially for larger organizations, because most onboarding processes are not that flexible and not fit for emergency access. This results in unwanted delays in your incident response. So let's figure out what access your incident response team or external provider needs.
Are you responsible for cloud security or incident response in your organization? We can help you with assessing your forensic readiness in the cloud, the development of a cloud incident response plan or playbook and testing your incident readiness. Schedule a call to discuss your needs with an expert.
Azure & Entra ID
Let's start with the Microsoft cloud covering Azure and Entra ID permissions. Here are some common challenges and pitfalls we see in real life cases:
- Access limited to specific subscriptions, we have had cases where the security team only had access to specific subscriptions. The issue is that you don't know what you can't see, effectively you're trying to protect a border, but you don't know where the border is or where it ends.
- Insufficient permissions, in a lot of cases the security teams only have access to logging and security tools in the cloud, but not to resources and Entra ID details. One of the issues here is that your team is able to see potentially malicious logins, but not what actions were taken with that account against Azure resources.
To make sure the right access is available for the right situation we differentiate between Standard and Emergency access, where standard can be used in day-to-day scenarios and emergency should only be used in active breaches to "stop the bleeding". The below table outlines the access we recommend setting up beforehand:
AWS
Permissions in AWS are very different to Microsoft, to start of you have different types of policies, you can set permissions directly on a user or leverage an IAM group with attached policies or an IAM role and attach permissions. Here are some challenges we have faced in the past while doing incident response in AWS environments:
- No point of contact for an AWS account, this is especially a problem in larger organizations where teams have the control over their own AWS accounts. Having a list or overview of accounts and who is responsible helps, it's even better if there's information on what services are used. This will help in scenario's where you would see an often abused service like Amazon SES used by an account that should only be running workloads in ECS for example.
- No AWS organization, it can get worse when you are responding to incidents especially if there are stand-alone accounts. Without an organization it's not possible to use Service Control Policies (SCP) and most importantly an organization allows you to setup a central CloudTrail trail, which is invaluable in an incident response scenario.
In AWS we can use built-in policies that can be assigned to roles, those roles should only be assumable by the security team, ideally from a separate Security/IR account. The table below shows the policies you should configure:
Google Cloud
For Google Cloud there are also several ways in which you can provide access and managed IAM. For the purpose of this blog we have assumed the Google Cloud built-in IAM solution is used. With that we can use the Basic roles to arrange access to Google Cloud resources. Let's look at some example of common challenges we faced when doing incident response in Google Cloud:
- Access setup at the 'wrong' level, for example at the project level, the concept of a project in Google is quite similar to an AWS account. That's why sometimes you will only get access on the Project or Folder level. This causes the same issue as described before you can only see what you have access to and not the rest of the organization.
- Insufficient expertise on IAM, from the big cloud providers it seems to be that Google Cloud skills are the more unique one. Especially when it comes to IAM this can be quite the challenge and in an IR scenario you don't really want to start reading the docs.
The table below shows the Basic roles we can use for Google Cloud:
Conclusion
In this post we went over what kind of access your teams and consultants should have in case of an incident. We consider this a starting point, for most of our client we would tailor the access to their environment and services and we recommend you do that too. For example one of our clients uses Kubernetes in AWS and sends the logs to CloudWatch we need to be able to access that too in case of an incident. Generally speaking you want to make sure that your teams are able to read all relevant information and for specific scenario's have the ability to elevate to write permissions to contain an incident.
Coming up next..
Cloud incident response is all about logs, so sit tight in the next part, we will cover the logs you can use, should use, but must configure before an incident happens. Closing of with the final part of this series where we will discuss infrastructure you can leverage in case of an incident.
Do you want to get an independent assessment of your cloud security state? Don't just trust on what the cloud providers tools ($$) tell you! Schedule a demo to get actionable insights based on our in-house developed assessment software. Built by practitioner for CISO's and decision makers that want to keep their clouds secure.
About Invictus Incident Response
We are an incident response company and we ❤️ the cloud and specialize in supporting organizations in preparing and responding to a cyber attack. We help our clients stay undefeated!
🆘 Incident Response support reach out to cert@invictus-ir.com or go to https://www.invictus-ir.com/24-7