RESPOND AND RECOVER FROM DATA BREACH

Activity Overview:

This lab is part of the Google Cloud Cybersecurity Certificate capstone project. The objective is to simulate a real-world cloud data breach and demonstrate the full incident response lifecycle: identifying vulnerabilities, containing the breach, remediating affected systems, and verifying compliance with internal and external frameworks.

Scenario proposed

"You are a junior cloud security analyst at Cymbal Retail, a global retailer with 170 stores and an online platform across 28 countries, generating $15B in annual revenue. Recently, Cymbal Retail experienced a significant data breach affecting its systems, applications, and customer data. As part of the security team, your role is to support the investigation, containment, and recovery of compromised systems."

Tasks / Workflow:

1. Analyze Vulnerabilities: Access Google Cloud Security Command Center (SCC) to review active findings, prioritize vulnerabilities, and assess their potential impact.
   
   

2. Contain the Breach: Shut down compromised virtual machines and create secure replacements from verified snapshots.
   
   

3. Secure Storage: Remove public access to affected storage buckets and enforce uniform bucket-level access control.
   
   

4. Harden Network Access: Review firewall rules, restrict unnecessary port access, and correct misconfigurations.
   
   

5. Verify Remediation: Run compliance and vulnerability reports in SCC to ensure that all identified issues have been addressed.

Key Skills Demonstrated:

• Cloud security monitoring and incident response
  
  

• Vulnerability identification and prioritization
  
  

• System recovery and secure configuration
  
  

• Compliance verification and reporting
  
  

Task 1: Analyze the Data Breach and Gather Information

Objective:

Gather information about the breach, analyze vulnerabilities, and identify potential remediation steps using Google Cloud Security Command Center (SCC).

1. Access Security Command Center:
   
   

   • I navigate in the Google Cloud console: Security > Risk Overview.
     
     

   • I review the Overview page for a summary of active vulnerabilities.
     
     

2. Examine Active Vulnerabilities:
   
   

   • I scroll to the Active Vulnerabilities section to see current security issues requiring attention.
     
     

   • I use the Findings by Resource Type tab to organize vulnerabilities by resource (e.g., Cloud Storage buckets, Compute VM instances, databases).
     
     

3. Prioritize Findings:
   
   

   • I identify high- and medium-severity vulnerabilities across cloud resources.
     
     

   • Notable findings include misconfigurations in Cloud Storage buckets, potential firewall gaps, and unpatched VM instances.
     
     

Outcome:
By completing this task, I established a clear understanding of the breach’s scope and prepared a prioritized list of vulnerabilities to remediate in subsequent tasks. This step lays the foundation for effective containment and recovery.

4. Next, I review compliance in Google Cloud Security Command Center. Under Compliance, I open the PCI DSS 3.2.1 report and sort the findings by severity. This highlights active issues that need attention and helps prioritize remediation efforts. 

8. Examine Findings for Virtual Machine cc-app-01:

• Review active findings for the virtual machine cc-app-01 over the Last 30 days.
  
  

• Key findings:
  
  

  • 1. Malware bad domain (Low): The VM accessed a domain associated with malware, indicating potential compromise.
       
       

    2. Compute secure boot disabled (Medium): Secure boot is off, allowing the VM to boot with unauthorized code.
       
       

    3. Default service account used (Medium): The VM uses the default service account, granting excessive access.
       
       

    4. Public IP address (High): The VM is publicly accessible, increasing exposure to attacks.
       
       

    5. Full API access (Medium): The VM has full access to all Google Cloud APIs, creating potential for misuse.
       
       

Outcome:
These findings show that cc-app-01 was highly vulnerable. To remediate:

• Shut down the original VM (cc-app-01).
  
  

• Create a new VM (cc-app-02) from a clean snapshot, configured with:
  
  

  • 1. No compute service account
       
       

    2. Firewall rule tag for controlled SSH access
       
       

    3. Secure boot enabled
       
       

    4. Public IP address set to None
       
       

This ensures the new VM is secure and reduces exposure to attacks.

9. Examine Firewall Findings:

• In the Quick filters panel, under Resource Type, uncheck Google Compute instance and select Google Compute firewall.
  
  

• Key firewall findings:
  
  

  • 1. 1. Open SSH port (High): SSH traffic allowed from all IPs, increasing exposure.
          
          

       2. Open RDP port (High): RDP traffic allowed from all IPs, creating a significant risk.
          
          

       3. Firewall rule logging disabled (Medium): No records of applied rules or allowed/denied traffic, limiting audit and investigation capabilities.
          
          

Outcome:
These findings reveal critical gaps in network configuration. To remediate:

• Remove overly broad firewall rules.
  
  

• Implement a new rule that restricts SSH access to only the addresses used by Google Cloud’s IAP SSH service.

4. Create the New VM from a Snapshot:
   
   

• I created a new VM using a snapshot that was part of Cymbal Retail’s long-term data backup plan.
  
  

• I clicked + Create instance and configured the machine:
  
  

  • Name: cc-app-02
    
    

  • Machine type: Shared-core, e2-medium
    
    

• In the OS and Storage section, I selected the Snapshots tab and chose cc-app01-snapshot to restore a clean state.
  
  

• In the Networking section, I:
  
  

  • Added the network tag cc to apply firewall rules specifically to this VM
    
    

  • Set the External IPv4 address to None to prevent public exposure
    
    

• In the Security section, I selected the Qwiklabs User Service Account for the service account.
  
  

• Finally, I clicked Create. After a few minutes, the new VM cc-app-02 was ready, fully restored from the snapshot and secured with proper settings.
  
  

Task 3: Fix Cloud Storage Bucket Permissions

Objective:
Revoke public access to the storage bucket and switch to uniform bucket-level access control to reduce the risk of unauthorized data exposure.

1. Access the Storage Bucket:
   
   

• I navigated to Cloud Storage > Buckets in the Google Cloud console.
  
  

• I selected the bucket qwiklabs-gcp-02-0af57a14d99f_bucket to view its details.
  
  

2. Identify Sensitive Data:
   
   

• • • • • Inside the bucket, I noted a file named myfile.csv, which contained sensitive information that had been exposed by the malicious actor.
          
          

3. Prevent Public Access:
   
   

• In the Permissions tab, I located the Public access section.
  
  

• I clicked Prevent public access and confirmed the change to immediately remove public exposure.
  
  

4. Switch to Uniform Bucket-Level Access:
   
   

• I enabled uniform bucket-level access to enforce a single set of permissions across the bucket and all objects.
  
  

• I removed permissions for the allUsers principal to ensure no anonymous access remained.
  
  

• I verified that users relying on basic project roles retained necessary access without compromising security.
  
  

By completing these steps, I effectively prevented public access, enforced uniform bucket-level access, and removed all unnecessary user permissions, addressing the Public bucket ACL, Bucket policy only disabled, and Bucket logging disabled findings.

Task 4: Limit Firewall Ports Access

Objective:
Restrict access to RDP and SSH ports to authorized source networks, minimizing the attack surface and reducing the risk of unauthorized remote access.

1. Plan Firewall Restrictions Carefully:
   
   

• I reviewed existing firewall rules to understand which rules were overly permissive and could allow unauthorized access.
  
  

• I identified that SSH access for Compute Engine instances tagged with cc needed to remain functional via Google Cloud Identity-Aware Proxy (IAP) while blocking all other sources.
  
  

2. Create a Limited-Access Firewall Rule:
   
   

• I created a new firewall rule named limit-ports.
  
  

• This rule restricted SSH access (port 22) to only the authorized source network 35.235.240.0/20.
  
  

• The rule targeted Compute Engine instances with the network tag cc.
  
  

3. Remove Overly Broad Rules:
   
   

• After the new restricted rule was in place, I removed the existing firewall rule that allowed SSH access from any IP address.
  
  

• This ensured that the network remained secure without disrupting legitimate management access.
  
  

By completing these steps, I successfully limited remote access to critical instances, reducing exposure while maintaining proper administrative connectivity.

Task 5: Fix the Firewall Configuration

Objective:
Remove overly permissive firewall rules and enable logging to improve network security and visibility.

1. Identify Overly Broad Firewall Rules:
   
   

• I reviewed the VPC firewall rules and identified three that allowed unrestricted access:
  
  

  • default-allow-icmp
    
    

  • default-allow-rdp
    
    

  • default-allow-ssh
    
    

2. Delete the Overly Permissive Rules:
   
   

• I deleted these three firewall rules to prevent unrestricted access to ICMP, RDP, and SSH protocols from any source within the VPC network.
  
  

• This action reduced the attack surface and ensured that only authorized traffic could reach the network.
  
  

3. Enable Logging on Remaining Firewall Rules:
   
   

• I enabled logging on all remaining firewall rules to maintain visibility into network traffic and improve the ability to audit and investigate any suspicious activity.
  
  

By completing these steps, I ensured the network was more secure, with controlled access to critical protocols and enhanced monitoring through firewall logging.

4. Enable Logging on Remaining Firewall Rules:
   
   

• I enabled logging for the firewall rules limit-ports (the restricted SSH rule I created earlier) and default-allow-internal.
  
  

• This allowed me to track and analyze traffic permitted by these rules, particularly internal traffic between instances within the VPC.
  
  

• By enabling logging, I ensured ongoing visibility into network activity and improved the ability to audit or investigate any suspicious behavior.
  
  

Conclusion

In this project, I responded to and remediated a simulated data breach in a Google Cloud environment. I analyzed vulnerabilities using Security Command Center, secured compromised virtual machines by restoring clean snapshots, enforced proper Cloud Storage bucket permissions, and restricted firewall access to minimize the attack surface.

By applying cloud security best practices and PCI DSS compliance standards, I successfully protected sensitive data, ensured controlled access to resources, and improved visibility through firewall logging. This project demonstrates my hands-on skills in incident response, cloud security, vulnerability remediation, and access control, highlighting my ability to effectively secure cloud environments while maintaining operational continuity.