We started this series detailing the major ways cloud affects SecOps before delving into updating our core capabilities and processes to better manage the cloud. Now it’s time to show some practical examples, both of which we have implemented in the real world

Example One: Misconfiguration Remediation 

Your tooling finds an S3 bucket that is open to public internet access. This is in an account that does have other public buckets, but this one is unexpected. It’s similar to finding a new open file share or SharePoint site that isn’t a clear policy violation but is definitely concerning, especially since data may be exposed to the internet.  

 Your objective is to detect, analyze and respond as quickly as possible.

 Monitor, Detect and Analyze 

• By monitoring resource configurations in real-time (using cloud security posture management (CSPM) or an equivalent) you detect the possible misconfiguration the moment it opened to public access.  
• Your tooling enriches the detected misconfiguration with the before state, after state, who made the change and the history of that bucket. 

Communicate 

• This alert routes to the SecOps team via Slack since anything newly public is of high or critical severity. It also creates a Jira ticket for tracking. 
• Simultaneously, the alert routes to the cloud team that manages that AWS account. All high and critical issues route to the owning team, while medium and below just create backlog tickets. 

• Alice, on the cloud team, recognizes that the API call was made using a role assigned to a contractor. She looks at the bucket and sees it does not yet contain sensitive data. 

Respond and Remediate  

• Alice fixes the bucket policy and has a stern conversation with the contractor. 
• The SecOps tooling recognizes the remediation and clears the alert and the ticket.  
• Since the issue was of high severity, the SecOps team reviews the configuration change history and double-checks to make sure no data was exposed.  
• The issue is detected and remediated in around 15 minutes. 

This example shows the value of our core principles. The exposure was detected in real-time. It was communicated to both SecOps and the team that owned the environment. Based on the IAM of the API call, the cloud team recognized the source of the exposure and, in this case, was able to remediate the issue before it was a problem. 

Example Two: Incident Response 

You just detected a new snapshot of a customer database unexpectedly shared to another account at 3 a.m. How long has it been there? Is the data sensitive? Is that one of your accounts, or is it under the control of an attacker? Was this a deliberate change, an accident or an attack? This is the cloud equivalent of realizing a database backup was open to the internet and possibly exported externally. 

The process here is similar to the first example, but this scenario shifts gears to deal with activity that is more indicative of an attack: 

Monitor and Detect 

• The monitoring system detects the cross-account sharing API call.  

• Your tooling evaluates the configuration of the snapshot. It looks up the shared account ID and sets the issue as critical since the ID is not known or on an approved list. 
• This creates an issue that is enriched with the details of the API call, including the IAM entity. In this case, it’s an IAM user account called “BackupManager.”  

Analyze and Communicate 

• The alert routes to the SecOps team and the cloud team that owns the account.  
• Since it’s 3 a.m., the SecOps team initiates their off-hours playbook for a potential customer data exposure. 
• SecOps logs into their response tooling for further investigation. They see the API call history of BackupManager and note that this activity occurs at an unusual time, from a new IP address and with a different user agent than normal. 
• SecOps also determines the AWS account is not a known corporate account, and they submit an abuse notice via the AWS support portal. 
• The responder reviews the current resource configuration of the database in their inventory system and identifies that this is a production account with production data (based on the database’s name and tags). 

Respond and Remediate 

• Due to the late hour, the responder is unable to contact anyone from that cloud account’s team and progresses through the playbook for an emergency response. 
• SecOps triggers their ‘break glass’ access, which requires a manager to approve within their tooling. The responder is given a 30-minute session to access the account. 
• The responder disables the sharing and triggers their IAM  containment automation script. This locks use of BackupManager to only a known corporate IP address.   
• The cloud SecOps responder engages with their colleagues to investigate how the BackupManager credentials leaked (e.g., a compromised data center server). 
• With the immediate threat contained, SecOps arranges to collaborate with the cloud team when they get to work in the morning for a permanent fix. 

This example relies less on communications and more on automation and responder access. During work hours, you might have had the cloud account team handle the remediation in coordination with SecOps, but since this was a potential critical exposure, security used their playbooks, emergency access, and automation instead. In case you didn’t know, sharing snapshots to accounts under an attacker’s control is a common data exfiltration technique that works on every cloud provider. 

These examples do a good job of showing how to build a modernized SecOps process for the most common security operations scenarios — remediating a misconfiguration or vulnerability and responding to an incident. In both cases we are able to detect, respond to and remediate the issue within minutes. We enabled rapid detection, information enrichment and communications across silos to engage the most knowledgeable team members and supportive automation.  

Hopefully, you noticed the key differences between these examples and how many organizations run their existing operations. Assessments are continuous and real-time; we don’t rely on daily or even hourly scans that could leave resources publicly exposed for longer windows. We treat misconfigurations as potential attacks, not just mistakes to backlog. Activity (log) data is also timely, and SecOps isn’t relying on slow feeds that force them to operate 15 minutes or more behind attackers. Automated enrichment and routing via ChatOps reduces the negative impact of decentralization by engaging teams across silos instead of security emailing out spreadsheets of vulnerabilities. Responders have the access and automation to make changes during emergencies and larger incidents, while the teams that own the cloud deployments can handle most issues themselves. 

Through modernizing our tools and processes, we manage the biggest security challenges of the cloud: Decentralization, administration via the internet and any resource a few clicks away from being public. Using our combination of core principles,  tooling and process recommendations and practical examples should help any SecOps team improve their cloud security operations.