Who Owns the Leaked Access Key?
A healthcare SaaS company runs a patient portal on AWS. The portal uses an S3 bucket for document storage and an IAM user with long-lived access keys for a nightly batch job. During a code review, a developer discovers that the access key was committed to a public GitHub repository six months ago. The company's security team investigates and finds that an attacker used the key to download 50,000 patient records from the S3 bucket. The bucket had a permissive bucket policy allowing read access to any authenticated AWS principal. The company's CISO claims AWS should have blocked the exfiltration, while the third-party payment processor integrated into the portal says the breach was the healthcare company's fault. The company has Falcon Cloud Security deployed but had not enabled CIEM or S3 bucket policy monitoring. They need a clear analysis of responsibility and a remediation plan.
1. Using the shared responsibility model, analyze who is responsible for the exposure of the access key, the permissive bucket policy, and the data exfiltration. Address AWS, the healthcare company, and the payment processor SaaS.
Read the worked answer
AWS is responsible for security of the cloud: physical facilities, hypervisor, managed service infrastructure, and the availability of S3. AWS is not responsible for customer-created IAM users, access keys, bucket policies, or code repositories. AWS provides controls such as S3 Block Public Access and IAM Access Analyzer, but the customer must configure them. The CISO's claim that AWS should have blocked the exfiltration misunderstands the shared responsibility boundary.
The healthcare company is responsible for security in the cloud. It created a long-lived IAM access key, allowed that key into a public repository, and configured a bucket policy that granted read access to any authenticated AWS principal. Those are customer-side identity and data-plane misconfigurations. The company also failed to enable CIEM and S3 policy monitoring despite having Falcon Cloud Security available. Primary responsibility rests here.
The payment processor SaaS is responsible for its own application and the data it processes within its service boundary. If the processor only consumed an API and did not manage the healthcare company's S3 bucket or IAM key, it is not responsible for this exposure. It may share responsibility for integration guidance, but not for the customer's IAM and bucket configuration.
2. What Falcon Cloud Security capabilities could have detected or prevented this incident, and how would you prioritize enabling them?
Read the worked answer
CIEM would have identified the IAM user with excessive permissions and long-lived credentials, and could have flagged unused or over-privileged identities. Enable CIEM first for all AWS accounts, focusing on identities with access to sensitive S3 buckets.
CSPM would have detected the permissive S3 bucket policy and any public exposure. Enable CSPM with S3-specific policies and AWS S3 Block Public Access enforcement. Prioritize findings that combine public access with sensitive data tags.
Code repository and secret monitoring is not a replacement for CIEM, but integrating repository scanning or GitHub secret scanning would have caught the committed access key earlier. If Falcon Cloud Security integrates with your source control, enable secret detection and alerting.
CloudTrail anomaly detection can surface unusual S3 download volumes or access from unexpected geographies. Configure detections for anomalous data access and tie them to the same incident workflow. The priority order is CIEM, then CSPM for S3, then secret scanning, then behavioral detection because the first two directly address the root causes in this incident.
3. Recommend immediate remediation steps and long-term governance changes.
Read the worked answer
Immediate: disable and rotate the exposed access key, remove the permissive bucket policy, enable S3 Block Public Access at the account level, and review CloudTrail logs to scope the exfiltration. Preserve logs and snapshots for the breach investigation. Notify privacy and legal teams because patient records were accessed, and follow HIPAA breach notification requirements.
Short-term: replace long-lived IAM users with IAM roles and temporary credentials, enforce MFA for human identities, and use AWS Secrets Manager for any remaining secrets. Enable Falcon CIEM and CSPM findings for all accounts and require remediation within a defined SLA.
Long-term governance: add pre-commit secret scanning and CI/CD policy checks so credentials never reach public repositories. Use service control policies to block public S3 bucket policies. Require threat modeling and security review for new integrations. Track shared responsibility explicitly in vendor contracts so the payment processor's boundary is documented. Rehearse the incident response plan with the new Falcon detections.