Typically, the Cloud Service Provider is responsible for securing the infrastructure, and the customer is responsible for securing the data and applications. Security in the Cloud focuses on a shared responsibility model that proves essential for businesses to succeed with cloud technology. However, the risk grows when we add internal attackers to the mix. Other scenarios include leaked/stolen SSH keys or stolen IAM credential files left on a public repository. This is especially true if GCP communicates with internal systems and could potentially be a channel back to the core on-premise network.Īttacks may be carried out via a number of external-facing systems such as web servers or Content Management Systems (CMS). Organizations in regulated industries often feel they are obligated to demonstrate such a level of control, so regulators believe the organization has done their due diligence. How do we keep control? Can we just shut down GCP? Would it stop the attack and contain the damage? Imagine an attacker could hack our Cloud systems and exfiltrate sensitive data, or abuse the system to launch an attack.

But how to do that? Is there a right way to do it? Let’s see. I was faced with a difficult question: in the case of a security incident, one customer desired a “big red button” to completely shut down Google Cloud Platform (GCP).

Big red button for incident response: How to approach security incidents in Cloud

Google red button