Incident response is an investigation. The same principles that apply in physical law enforcement translate directly to the digital world: preserve evidence, understand the scene, identify the actors, and contain the damage. Gerard Johansen, a cybersecurity professional with over a decade of experience in incident response, digital forensics, and threat intelligence, brings a law enforcement investigative mindset to cloud security. Currently focused on incident response within an MDR provider, he shares how to build muscle memory for incidents, what evidence actually matters, and how cloud-native tooling has transformed forensic capabilities.
You can read the complete transcript of the episode here >
What are the common challenges in incident response?
Gerard identifies two compounding factors that derail most incident response efforts:
- The initial shock: Losing production data or incurring downtime creates intense stress. Whether the incident is accidental or adversarial, that stress impairs decision-making at the worst possible moment.
- Lack of specific expertise: Knowing where to pull data from to understand what is happening requires specialized knowledge that many teams do not have readily available.
These two factors multiply each other. Stress combined with knowledge gaps creates paralysis. The solution is preparation: preloading a plan so the team can execute from muscle memory rather than improvising under pressure.
The key technique: get to containment as fast as possible. If you know where the attack is in the network, isolate that section immediately. You will lose that portion of the network temporarily, but it slows lateral movement and gives the team breathing room to craft a better plan.
How do playbooks and preparation change incident outcomes?
Playbooks are the single most important artifact in incident response. Gerard is emphatic: without a preloaded plan, teams panic and make decisions that increase liability and damage.
What effective playbooks contain:
- Evidence collection procedures: Specific steps for preserving forensic artifacts, simple enough that a systems administrator with two to three years of experience can execute them.
- Triage workflows: How to quickly identify the four key data points that matter: initial access vector, execution method, lateral movement tools, and command and control infrastructure.
- Containment actions: Pre-approved isolation steps (endpoint isolation via EDR, network segment quarantine, credential revocation) that can be executed without waiting for approval chains.
- Retrospection procedures: Post-incident analysis steps to identify root cause and prevent recurrence.
The critical insight: you do not need to test the entire IR plan in one four-hour annual exercise. Twenty to thirty minutes per week of targeted playbook practice builds the muscle memory that performs under stress. Each repetition makes the next incident less chaotic.
How do cloud-native security tools affect incident response?
Cloud adoption has fundamentally changed forensic capabilities, largely for the better:
- Speed: Instead of physically locating a laptop or desktop in a campus environment, responders can dial into an endpoint within 90 seconds using cloud-based agents.
- Remote evidence collection: Tools deployed in AWS, Azure, or DigitalOcean can push out agents and collect evidence from anywhere, eliminating the geographic constraint that previously slowed investigations.
- Endpoint isolation: EDR tools with cloud management planes allow analysts to isolate compromised endpoints with a single click, stopping lateral movement immediately.
- In-cloud analysis: Snapshots can be taken and analyzed directly within the cloud platform, eliminating the need to download disk images to a local forensic workstation.
For teams with limited budgets, Gerard recommends Velociraptor (by Rapid7), an open-source tool that can be deployed on an AWS EC2 instance in 15 minutes. It provides endpoint isolation capabilities and extensive evidence extraction without commercial licensing costs.
What evidence actually matters during an incident?
Gerard focuses on four key tactics that tell the story of an attack:
- Initial access: How did the attacker get in? Drive-by compromise, phishing email, compromised credentials?
- Execution: What ran on the system? What processes were spawned?
- Lateral movement: How did the attacker move between systems? What tools did they use?
- Command and control: How is the attacker maintaining persistence and communicating with their infrastructure?
The practical insight: on Windows systems, the trace evidence needed to answer these questions (prefetch, amcache, event logs) represents less than 1% of the disk. A triage package of approximately 500 megabytes gives investigators the vast majority of insight they need to understand an attack. Teams should be aggressively collecting this evidence at the first sign of anomalous activity rather than waiting for confirmation.
How does incident response change in multi-cloud and hybrid environments?
The architecture understanding becomes the primary preparation step:
- Logging is not always on by default: AWS, Azure, and GCP all have logging capabilities that may not be enabled. For example, AWS CloudTrail must be properly configured. The preparation step is knowing what is available and ensuring it is active before an incident occurs.
- Data source mapping: Understand where network flow data lives (VPC Flow Logs in AWS, Network Watcher in Azure), where identity events reside, and how to correlate across platforms.
- Platform-specific playbooks: AWS evidence collection differs from Azure, which differs from GCP. One-for-one mapping between cloud providers ensures teams can execute in any environment.
- Cloud-native advantages: Fire off a snapshot in AWS and analyze it within the platform. Push tooling into cloud infrastructure rather than downloading evidence to local workstations.
The key challenge: understanding the nuances of each platform. This requires ongoing research and sweat equity, but the efficiency gains from in-cloud forensics far outweigh the learning investment. This is why understanding your cloud security posture and architecture before an incident occurs is essential preparation.
How has the incident response landscape evolved?
The shift in recent years, driven largely by ransomware prevalence:
Before: Organizations wanted deep root cause analysis, understanding every mechanism of the attack variant. Outages lasted days while teams investigated.
Now: Organizations prioritize four data points (initial access, execution, lateral movement, C2), containment, and restoration. The goal is hours of downtime, not days. With good backups and restoration processes, getting back to operational is the priority.
The driving factor: business impact. In healthcare, nurses doing manual note-taking because patient record systems are down creates immediate pressure to restore rather than investigate. The evolution is from “understand everything” to “understand enough to contain and restore safely.”
Can AI tools like ChatGPT help with incident response?
Gerard takes a pragmatic view: AI is an enabler, not a replacement.
Where AI helps:
- Generating playbook templates that teams then customize for their environment
- Creating Sigma rules and YARA rules from malware samples (with modifications)
- Reducing time spent on documentation, which is typically the trailing task in security operations
- Providing focused threat intelligence: “Given our environment, what are the top 10 things to worry about this week?”
Where AI falls short:
- Generic outputs need modification for specific environments
- Cannot replace the investigative judgment that human analysts bring
- Will not eliminate the need for security professionals but will handle repetitive grunt work
The net effect: AI handles low-level repetitive tasks, freeing security operations personnel to focus on threat hunting, investigation, and the judgment-intensive work that AI cannot perform. Gerard is cautiously optimistic that this enablement will make teams more effective, not smaller.
