Swiss Cheese failure mode example - Google cloud database service critical vulnerability
Take action: Never assume that someone else will prevent a security vulnerability that you are too busy to address. Be certain that everyone else is also assuming you will fix their security vulnerabilities since they are too busy to address them. At the end, all security holes align, and you get the priority to fix them after a security breach.
Learn More
A critical vulnerability in the Google Cloud Platform (GCP) database service has been addressed through a recent patch. Google promptly took action to rectify the issue by releasing a patch specifically designed to mitigate this vulnerability.
We follow up with details of the exploit path, a typical example of Swiss Cheese failure model
What is a Swiss Cheese failure model?
The Swiss cheese model of accident causation likens systems to multiple slices of Swiss cheese, which has randomly placed and sized holes in each slice, stacked one after another. The risk of a threat becoming a reality is mitigated by the differing layers and types of defenses which are "layered" behind each other.
In theory, lapses and weaknesses in one defense do not allow a risk to materialize (e.g. a hole in each slice in the stack aligning with holes in all other slices), since other defenses also exist (e.g. other slices of cheese without aligned holes).
The failure in a swiss cheese model occurs when multiple holes are aligned and the risk vector can pass through.
In practice the swiss cheese failure model is very much caused by the assumption of multiple groups building a solution that some other group will prevent a problem from occuring - so everyone assumes that their "technical debt" is going to be addressed somewhere else. This rarely happens.
Onto our real-life example of a Swiss Cheese failure
A security researcher found that a combination of a gap in GCP’s security layer for SQL Server and a misconfiguration in the roles permission architecture, enabled a path by which they were able to create a user, and grant them sysadmin privileges.
- The first issue enabled the creation of a user with the GCP admin role “DbRootRole”. The "DbRootRole" is not a sysadmin role but it provided a foothold for the attacker.
- From there the attacker was able to exploit the misconfiguration and gain full control of the database engine and access to the host OS running the database engine.
- After achieving access to the underlying operating system, the attacker can access asensitive files in the host OS, list files and sensitive paths, read passwords, and extract secrets from the machine.
Google remedied the issue in April before making it public.
