Cortex Cloud Remediation During a Production Freeze
Metro Retail has 14 AWS accounts, 6 Azure subscriptions, and 2 GCP projects. Cortex Cloud reports 1,100 critical findings across 4,000 workloads: 23 public object-storage buckets, 41 over-privileged IAM roles with wildcard actions, 19 internet-facing workloads running critically vulnerable software, and 300 unpatched container images. The production account is under a change freeze for 10 days. Agentless scanning runs every 24 hours; 12% of workloads have no agent. Developers receive 400 tickets per week and close 35% as 'won't fix' due to missing owner tags. The security team wants to auto-remediate all public buckets. The cloud team says auto-remediation in production caused an outage last quarter. Only 40% of workloads carry a cost-center tag, and the cloud team has no shared exception process.
1. Which findings should be remediated first, and why not all 1,100? Build a prioritization logic using exposure, data sensitivity, and exploitability.
Read the worked answer
Not all critical findings carry the same risk. Score each on three axes: internet exposure, sensitivity of data or identity, and exploitability. First are the 23 public buckets that contain customer, payment, or health data; those are confirmed data-exposure paths. Second are the 19 internet-facing workloads with critically vulnerable software, but only if the vulnerability is reachable and exploitable from the internet. Third are the 41 wildcard IAM roles that are attached to internet-facing workloads or high-privilege identities; a wildcard role with no reachable path is lower priority. Fourth are unpatched container images, unless they are deployed in an internet-facing production service. Use attack-path analysis to find choke points rather than fixing 1,100 items one by one. A public bucket with no sensitive data is not equal to one with patient records. The 12% without an agent means some findings rely on agentless evidence; validate exposure before declaring a workload safe or critical.
2. How would you design a safe remediation workflow across 14 AWS accounts with a production change freeze and 12% agentless? Include preventive controls.
Read the worked answer
Separate detect, contain, and fix. During the freeze, do not auto-remediate production. Apply low-blast-radius containment where possible: account-level public-access block for storage, restrictive security groups, and WAF rules. For non-production accounts, auto-remediation can continue with an audit trail. For production, create a ticket with the owner, evidence, and a proposed change, and route it through the 24-hour approval path if one exists. Fix the ownership problem before scaling remediation: require cost-center and owner tags through infrastructure-as-code, and reject deployments without them. Add policy-as-code checks in CI/CD so new public buckets and wildcard roles never reach production. Use cloud connectors and agentless scanning for inventory, but require an agent on high-value internet-facing workloads for runtime detection. Create a shared exception process with an expiry date; otherwise developers will keep closing tickets as won't fix. Measure containment time and recurrence, not just ticket closure.