CVE Program Saved, 1200 AWS Access Key Compromised, & Mastering Cloud Incident Response

Hello from the Cloud-verse!

This week's issue is sponsored by Cloud Security Bootcamp.

Incase, this is your 1st Cloud Security Newsletter! You are in good company!
You are reading this issue along with your friends and colleagues from companies like Netflix, Citi, JP Morgan, Linkedin, Reddit, Github, Gitlab, CapitalOne, Robinhood, HSBC, British Airways, Airbnb, Block, Booking Inc & more who subscribe to this newsletter, who like you want to learn what’s new with Cloud Security each week from their industry peers like many others who listen to Cloud Security Podcast & AI CyberSecurity Podcast every week.

Welcome to this week's edition of the Cloud Security Newsletter!

This week, we focus on effective incident response in cloud environments inspired by the breaking news about a CVE program being saved, which is a reminder for why CVE is critical for cybersecurity threat management as Amazon S3 Ransomware in others news also continues to surge. We feature insights from Andrew Tabona, SVP for threat detection and incident response at a Fortune 500 company & also perspectives from Nick Frichette and Christophe Tafani-Dereeper Security Researchers from Datadog on Kubernetes security, and Damien Burks on automating AWS incident containment.

THIS WEEK'S SECURITY NEWS

💥 MITRE CVE Program Funding Extended After Last-Minute Crisis

The CVE (Common Vulnerabilities and Exposures) program, which was at risk of losing its funding, received a last-minute 11-month contract extension from CISA. The program is vital for the security community's ability to track and share information about security vulnerabilities. More Information here

Why it matters: The CVE program is critical infrastructure for vulnerability management in cloud environments. The NVD backlog hit 16,000+ unprocessed vulnerabilities in the time CVE program was up in the air. Cloud security professionals rely on CVE identifiers to prioritize patching, track exposure, and communicate about threats across platforms and tools. The extension prevents what could have been a significant disruption to vulnerability management processes.

🚨 Massive Ransomware Campaign Targeting AWS S3 Buckets Using 1200 Stolen Access Keys

A coordinated attack has compromised over 1,200 unique AWS access keys, with attackers using them to encrypt S3 bucket contents and demand ransoms in Bitcoin. The attackers are using AWS's own Server-Side Encryption with Customer-Provided Keys (SSE-C) feature, creating a "silent compromise" situation where victims receive no alerts when their data is encrypted. Many affected organizations remain unaware of the breach. More information here

Why it matters: This attack targets a most common AWS cloud storage service that many organizations use for critical data and now even more for cleaning and storing data for AI Applications. The attackers' use of native AWS encryption features demonstrates sophisticated knowledge of cloud infrastructure. Cloud security leaders should continue to periodically audit IAM credentials, implement stronger detection for unusual S3 access patterns, and enforce short-lived tokens rather than long-lasting access keys.

🔍 GitHub Launches Security Campaigns to Streamline Vulnerability Remediation

GitHub has announced the general availability of Security Campaigns, a feature designed to help security and development teams collaborate more effectively on fixing vulnerabilities. During preview testing, organizations using Security Campaigns fixed 55% of prioritized security issues compared to just 10% without the feature. More Information here

Why it matters: For cloud-native organizations using GitHub, this feature addresses a key challenge in the DevSecOps lifecycle turning vulnerability findings into actual fixes. The focus on collaboration between security and development teams aligns with the cloud-native philosophy of shared responsibility for security. This has the potential to bring the security tech debt that often gets left behind as project progress.

CLOUD SECURITY TOPIC OF THE WEEK

Mastering Cloud Incident Response

Incident response in cloud environments requires fundamentally different approaches than traditional on-premises environments. This week, we explore effective cloud incident response strategies with insights from experts who have built these capabilities at scale.

Featured Experts This Week 🎤

• Andrew Tabona: SVP for Threat Detection and Incident response at a Fortune 500 financial services company

• Nick Frichette: Security researcher at Datadog

• Christophe Tafani-Dereeper: Cloud security expert at Datadog

• Damien Burks: Cloud security engineer at Citi

Definitions and Core Concepts 📚

Before diving into the analysis, let's clarify some key terms referenced throughout the discussion:

• Cloud Detection Response (CDR): Platforms specifically designed to detect and respond to threats in cloud environments, distinct from traditional SIEM/SOC tools

• Cloud Security Posture Management (CSPM): Tools that assess cloud environments for misconfigurations, but generally lack real-time attack detection capabilities

• SSE-C (Server-Side Encryption with Customer-Provided Keys): An AWS encryption feature allowing customers to manage their own encryption keys for S3 data

• Containment: The phase of incident response focused on isolating a breach to prevent further damage

• Multi-account strategy: The practice of using separate AWS/cloud accounts for different functions to improve security isolation

This week's issue is sponsored by Cloud Security Bootcamp.

🧠 Our Insights from These Practitioners

With the CVE drama that unfolded this week, our insights are focussed on how practitioners should continue to build resilient systems that are able to detect threats, contain them and respond at speed.

1- Building Multi-Cloud Threat Detection Capabilities

Andrew Tabona emphasizes that effective cloud detection and response requires more than just purchasing tools—it requires a strategic approach focused on prioritization and building the right processes.

Start with detection, not containment: According to Tabona, organizations should focus first on building solid detection capabilities: "If you're looking to build [incident response], I will say the easiest portion to start with is the detection side of the house because when you start to look into how do I want to detect incidents, in that process or in that discussion... you realize that you also need to threat model things."

This approach forces you to identify critical business applications, classify your assets, and determine which cloud services you want to allow or restrict.

Address the CSPM misconception: Many organizations assume their Cloud Security Posture Management (CSPM) tools provide sufficient incident detection capabilities. Tabona clarifies the distinction: “CSPM for me is about hygiene. It's about cleaning up misconfigurations and policy violations. But it doesn't really excel at alerting or detecting real-time attacks like somebody's actively doing something in your environment that you need to know about."

Master one cloud before expanding: For multi-cloud organizations, Andrew recommends a strategic approach to building detection capabilities: "Start with one, master one, understand and basically test what your model is and what your framework wants to be, right? What your process is going to be, and then replicate that across the other clouds."

2- Automating Containment for Speed and Consistency

Incident containment is particularly challenging in cloud environments due to the scale and complexity of resources. Damien Burks explains how automation can dramatically improve containment effectiveness: “I would say average like if there was an incident that happens that detect in the analysis phase pretty much takes between like one or two hours. It's the containment and the recovery phase of it all that takes the longest time... if someone walked in there and decided to pop 500 IAM roles where they leverage 500 IAM roles to create pivot Points in your environment, you have to contain all 500 of those IAM roles."

Burks' team built a containment framework using AWS Lambda and Step Functions to automate these processes, significantly reducing response times.

Practical automation approach: Burks recommends a multi-stage approach to implementing containment automation:

1. Create semi-automated playbooks that still require analyst approval

2. Collect data on success rates and false positives over time

3. Use this data to justify fully automating certain responses

4. Demonstrate the reduction in mean time to respond to build support

3- Kubernetes-Specific Response Challenges

For organizations running Kubernetes in cloud environments, Christophe Tafani-Dereeper and Nick Frichette highlight specific incident response challenges:

Forensic complexity in managed Kubernetes: Nick Frichette explains how forensics differs in cloud environments: "With the cloud, it's spread out, right? It's there, spread out across regions, availability zones, each within different services themselves. And I feel like most tools out there, at least in my experience, aren't really built for the cloud when it comes to forensics."

Cross-cloud credential issues: When collecting forensic evidence across accounts or regions, encryption presents challenges: "When you have it from an IAM standpoint, let's say if I wanted to collect a snapshot for an EC2 instance that's hosted in a different account and I wanted to copy that into another account by using another KMS key... the role that you're using has to have permissions to encrypt, decrypt, re-encrypt and also generate a data key for that KMS key."

4- Building an Effective RACI Model for Cloud Incident Response

Andrew Tabona emphasizes the importance of clearly defined roles during an incident: "Speed is essential for containment, especially in the cloud. So having that predefined RACI and understanding with the business, like how much the IR team can do on their own to put the fire out, so to speak, it's going to be a really important."

This ensures that when incidents occur, responders know:

• Who can authorize containment actions

• Who provides business context about affected resources

• Who can rotate compromised credentials

• Who gathers logs for investigation

This newsletter issue's Takeaway

The insight highlighted are just a glimpse of why CVE’s are important and the fact that over 16000+ backlog in NVD for potential CVE that could have been out in the wild while we are figuring out contract is not a great reflection of cybersecurity’s backbone. Even though it seems to have been saved this time but this should be lesson learned & feedback shared from the community on making sure this doesn’t happen.

📚 Related Resources

• MITRE ATT&CK Framework for Cloud

• AWS Security Incident Response Guide

• NIST SP 800-61: Computer Security Incident Handling Guide

• VX Underground CVE Database Archive

• Datadog Cloud Security Center

Related Podcast Episodes 🎧

Question for you? (Reply to this email)

Next week, we'll explore another critical aspect of cloud security. Stay tuned!

We would love to hear from you📢 for a feature or topic request or if you would like to sponsor an edition of Cloud Security Newsletter.

Thank you for continuing to subscribe and Welcome to the new members in tis newsletter community💙

Peace!

Shilpi Bhattacharjee

Was this forwarded to you? You can Sign up here, to join our growing readership.

Want to sponsor the next newsletter edition! Lets make it happen

Have you joined our FREE Monthly Cloud Security Bootcamp yet?

checkout our sister podcast AI Cybersecurity Podcast