Falco Feeds extends the power of Falco by giving open source-focused companies access to expert-written rules that are continuously updated as new threats are discovered.
Why visibility without action slows you down in the cloud
SOC and CSIRT analysts are all too familiar with this type of scenario:
A production workload compromise is detected in your AWS environment. Maybe the alert is something minor but annoying, like cryptomining behavior. Or maybe it’s something a little more exotic with suspicious lateral movement. Or maybe it’s even spicier, like an exposed access key being actively abused.
Something is clearly wrong, but what happens next?
Typically you want to first identify the affected resource, and establish where it lives. Then you determine who has the right permissions and open the appropriate tickets.
Then you wait.
They respond and you explain the severity of the situation. Eventually someone logs in and performs the containment.
Even in an optimistic scenario and at a high-performing organization, this process introduces delays in response. It also introduces cross-team friction, and ample opportunity for miscommunications.
The threat actors don’t mind if it takes you longer to mount a meaningful response, since it just gives them more time to accomplish their goals. These constraints lock security teams into an observe-and-escalate posture instead of enabling inline investigation and response.
Sysdig accelerates teams with Inline Cloud Response
Sysdig’s Inline Cloud Response enables analysts to investigate and execute AWS-native containment actions directly from the Sysdig console, without switching tools or requiring additional access handoffs for predefined workflows.
Analysts are able to stay in the workflow they are tackling, without needing to track down resource owners, deal with timezone delays, or scramble for the correct IAM access.
From within the same interface, you can now:
- Trigger AWS-native investigative actions
- Contain compromised resources
- Execute predefined remediation steps
- Automate response workflows
For security teams, this key shift is simple but impactful: The same team that is in the trenches, detecting and investigating threats, can now respond immediately.
Sysdig Cloud Response for AWS allows you to integrate response capabilities directly into your cloud security workflow the same way you can for host and Kubernetes. Instead of stopping at “this is the problem I’ve identified”, Sysdig helps teams move seamlessly to “we took care of it.”
Accelerates analyst response and remove operational friction across business units
It’s a non-trivial task to locate resources, find access owners, and coordinate across teams to contain an active threat. Modern cloud environments are wide, heterogeneous and constantly changing. These changes often happen faster than teams can track ownership across resources.
When response is fragmented and time is sunk into complex operational overhead, metrics like mean time to containment (MTTC) increase drastically. Some incidents may even escalate unnecessarily because of miscommunications. Ultimately, teams need to be able to increase response agility while staying within their clear execution guardrails.
Inline Cloud Response for AWS eliminates the operational scramble.
When a detection surfaces, prescriptive response actions are at your fingertips in the same console you’re using to investigate the alerts, maintaining context and consolidating your workflow.
As the responding analysts, you no longer need to switch into the AWS console and manually figure out which account owns the resource. Pending your standard operating procedures, you may not even need to escalate it to the platform team, saving yourself from needing to open a flood of tickets. This path keeps you in one tool from detection to containment, so you can stay in the investigation flow.
If you're a SOC engineer or part of a CSIRT team, your job is already complex and highly regimented. You’re juggling alerts, constant escalations, false positives, active incidents, and the inevitable post-incident analysis documentation that follows. Every day, you’re expected to have sharp focus, rapidly switch context, and make precise decisions under pressure.
The last thing you need when investigating suspicious activity is additional operational process friction, such as tracking down resource owners, navigating multiple consoles, or waiting on someone else to take action, especially when you're trying to determine whether a detection represents a real threat or just false alarm due to a benign behavior.
Improving SOC and CSIRT investigation workflows in AWS
Inline Cloud Response for AWS makes investigation significantly faster for analysts by enabling teams to drill in without jumping through operational hoops. Leveraging the Sysdig Secure workflows, you can explore the critical context surrounding an impacted resource or resources, validate or disqualify related suspicious activity, and simply rule out false positives from real threats.
Once a behavior is confirmed malicious, you can initiate surgical response actions within your standard operating procedures (SOPs) directly from the same workflow. So, instead of initiating time-sensitive escalation for routine containment, you retain control of the investigation to see it through.
Example investigation: Suspicious AWS API enumeration
A new threat, Suspicious API Activity by User evil-paolo, shows up in the Sysdig Threats console. The threat summary tells us that user evil-paolo has engaged in extensive API activity, including multiple calls to DescribeInstanceAttribute and Get User Data. These could potentially be simple resource management, but the IP address combined with the detection of Suspicious Simulate Principal Policy with enumeration activities like ListClusters and ListTasks makes us suspect this may actually be a threat actor attempting to discover AWS resources.
Looking at the security events logged for the threat, we quickly understand the volume of actions taken in this instance, further tilting the scale towards this being malicious in nature.
Because of the sheer volume of activities, we are going to look through the highlights for priority signals. Here we can rapidly understand what is happening. In this case, it’s a high-severity detection based on Sysdig policy, AWS Behavioral Analytics. This stateful detection shows a rule triggered for a high number of DescribelnstanceAttribute API calls for userData. The highlights also show us who is behaving suspiciously, where they are behaving this way, and a timeline and description of the behavior volumes.
For this scenario we are going to fetch the cloud logs for evil-paolo, specifically for the 15 minutes before the event. With these logs, you can reconstruct what happened during the 15 minutes leading up to the detection, build a timeline of events, scope the incident, and uncover how evil-paolo gained access.
Now we verify and document that the logs have been pulled, and start our analysis of the series of events that led up to the detection.
Understanding that these behaviors are highly likely to be malicious, we are also going to take this opportunity to quarantine evil-paolo.
With just a few clicks, we have successfully leveraged our IAM quarantine to isolate evil-Paolo to prevent any further actions and potential damage.
Reducing MTTC through Inline Cloud Response actions
Once malicious threats are validated, you can accelerate response within the agreed-upon playbooks. This allows you to take action inline to actively contain the threat from the Secure Console, bypassing delays, reducing response latency, and avoiding the liability that comes with waiting for someone with AWS console access to take action.
Example containment: Public S3 bucket exposure
An alert comes in that someone has created a risky public-facing S3 bucket.
As we look above at the threat summary automatically generated by Sysdig Sage, we can see that a public S3 bucket was created and the public access block was deleted. This action along with the name suggest either a serious lapse in security best practices or a potential threat scenario. We know that in a worst-case scenario, this could essentially be a bad actor creating a bridge through which they can exfiltrate data from your organization.
Digging deeper, we open the events to confirm the actions that were taken and understand in full what happened.
Under the highlights, we see bucket not-suspicious-not-for-exfiltrating-your-data was made public by AWSReservedSSO_administrator_c5ef97f9a91c4597 on region eu-central 1. We can later drill into that identity to see what else they have been up to.
We are also able to understand what cloud in our AWS environment is impacted to help with our investigation.
Within our current workflow, we can easily pivot into our response actions. These actions are within our current SOPs, allowing us to take decisive actions as we respond to threats. Looking at our options, we can take investigative actions like EBS volume snapshots or fetch cloud logs. We can also act with destructive actions such as quarantining a user or role and removing public access.
Based on the gravity of the current situation, in this instance we have chosen to immediately convert the bucket not-suspicious-not-for-exfiltrating-your-data to private. It's time to gate the bridge, effectively blocking any chance of data exfiltration through the previously public-facing resource.
Once converted, the bucket not-suspicious-not-for-exfiltrating-your-data should be validated to document the status of the resource.
After stopping the attack, it's time to close the loop with blocking automations to stop attacks using this approach again in the future. In this scenario, we are using automations with automatic response actions against this behavior, specifically for the cloud provider, account ID, and user. Should these criteria be met, the automations will automatically block the action and remove public access.
Be frustrated with commute traffic instead of your cloud security tooling
As a security professional, you want to create an impact, not manage legacy process overhead. Sysdig Cloud Response reduces the struggle of handling incidents and makes some of the most stressful aspects of the job that much easier. These changes enable teams to focus on what they signed up to do: stopping threats.
Business impact: Faster containment and reduced cloud risk exposure
So far we have primarily focused on how Sysdig Inline Response streamlines analyst workflows, but the reality is that it can impact the security organization as a whole, materially reducing organizational risk. In cloud environments, where attacks unfold in minutes and privilege escalation can happen instantly, delays between detection and containment directly increase blast radius and potential business impact.
By enabling SOC and CSIRT teams to investigate and execute AWS-native response actions from the same interface, Sysdig reduces the MTTC, minimizes ownership ambiguity, and reduces unnecessary escalation loops. For security leaders, this translates into measurable improvements in incident response metrics, reduced exposure, and more empowered security teams operating within approved guardrails. All this in turn means teams can act decisively without additional console switching for approved response actions.
Conclusion: From observation to action
In the cloud, visibility alone is not enough. Security teams need the ability to move from detection to investigation to containment without friction, delay, or tool switching. Sysdig Cloud Response transforms the traditional observe-and-escalate model into an active, inline workflow where the analysts closest to the threat can act immediately.
By embedding AWS-native investigative and containment capabilities directly into the detection experience, Sysdig empowers teams to reduce response time, eliminate operational bottlenecks, and focus on stopping threats instead of managing process overhead. Malware, IAM abuse, and runtime attacks will continue to move fast. Your response should move faster.