Respond and Recover from a Data Breach

This project is a simulation of a real-world data breach for a global retail giant. You are a Junior Cloud Security Analyst for Cymbal Retail, a global retail powerhouse with 170 physical stores and an online platform spanning 28 countries. In 2022, the company reported $15 billion in revenue and employed 80,400 employees worldwide. With millions of transactions occurring daily, ensuring the security of customer data, employee information, and operational assets is critical to maintaining internal and external compliance.

To begin investigating the data breach, I open up Google Cloud Security Command Center to analyze available data and gather key information. By reviewing active vulnerabilities, I can gain an overview of the current security issues affecting resources such as storage buckets, virtual machines, and firewalls. I will focus on findings by resource type to identify vulnerabilities tied to the attack. This initial analysis will allow me to understand how the attackers gained access, helping me prioritize and take the necessary remediation steps to secure the environment.

This report highlights multiple critical security issues:

• Lack of proper logging, making it hard to audit network access.

• Open RDP and SSH ports expose systems to the internet, increasing attack risks.

• Publicly accessible VMs and storage buckets make sensitive data easy targets for attackers.

• Overly permissive default service accounts could allow attackers to perform high-level actions if compromised.

Each of these vulnerabilities needs to be addressed to secure the environment and meet PCI DSS compliance standards.

The vulnerable virtual machine (VM), "cc-app-01", needs to be shut down and we will create a new VM from a snapshot of the original VM prior to the malware infection. This will restore the system to a clean slate, ensuring that the new VM will not be infected with same malware. We stop the original by clicking the box next to "Name" and there is a prompt to "Stop". 

In this task, I’ll secure the storage bucket by removing public access and applying uniform access control, which greatly reduces the chance of a data breach. By revoking all user permissions from the bucket, I ensure that only authorized individuals can access the sensitive data stored inside.

To do this, I’ll navigate to the Cloud Storage section, locate the storage bucket that contains a publicly accessible file (myfile.csv) with sensitive information exposed by a malicious actor, and remove public access. Then, I’ll switch to a uniform bucket-level access control policy, ensuring that permissions are consistent across the entire bucket and its contents.

It’s important to manage this carefully, so users with legitimate access aren’t accidentally locked out. After making the necessary changes, I’ll confirm that public access has been revoked and verify that all users who still need access retain their permissions.

This task helps tighten data security and addresses the issues of public access, bucket policy, and logging.

In this task, I’ll focus on securing remote access to the system by limiting RDP and SSH ports to only authorized networks. This is important because reducing the number of entry points helps lower the risk of unauthorized access.

When adjusting firewall rules, it’s critical to ensure that legitimate traffic isn't accidentally blocked, as this could disrupt important operations. In this scenario, I’ll make sure that virtual machines labeled with the "cc" tag can still be accessed via SSH from Google Cloud’s Identity-Aware Proxy (IAP) address range (35.235.240.0/20). To ensure management access isn’t interrupted, I’ll first create a new firewall rule that restricts SSH access to only authorized IP addresses, before removing the old rule that allowed SSH connections from anywhere.

This step is about tightening security without affecting system functionality.

In this task, I’ll remove three firewall rules that are currently allowing open access to important network protocols, such as ICMP, RDP, and SSH, which can create security risks. After that, I’ll turn on logging for the remaining firewall rules to keep track of any activity going through the network. This ensures that only the necessary traffic is allowed while maintaining visibility into the system’s security. 

After diligently addressing the vulnerabilities I identified in the PCI DSS 3.2.1 report, it's essential to verify the effectiveness of my remediation efforts. In this step, I will rerun the report to ensure that the previously identified vulnerabilities have been successfully mitigated and no longer pose a security risk to the environment.