Threat Modelling Cloud Platform Services by Example: Google Cloud Storage
Introduction
The consumption of cloud services has grown rapidly over the last few years and one of the major providers to benefit from this growth is Google Cloud Platform (GCP). The security challenges faced by small/medium companies and enterprises when deploying new services into the cloud can often be daunting, so to get a better understanding of these challenges on GCP and help pointing out the necessary and available security controls, we used a threat modelling approach.
As a first step we chose to threat model GCP’s Google Cloud Storage service. To gain a better understanding of the service, we identified its key features and then drew a high-level diagram of the service. During the construction of the diagram, it was possible to identify the main data assets involved and any base security controls that were enabled by default. From there, it was possible to create a threat model for the Google Cloud Storage service with all the available features, security control recommendations were provided that would mitigate the identified threats.
The STRIDE model was used to create the threat model, as it provided a well proven methodology and an industry recognised approach.
The first several sections of this post look at threat modeling generic public cloud services through a STRIDE threat modeling framework (as applied, by way of example, to Google Cloud Platform and its’ specific terminology, architecture, and services), but could equally be applied to other cloud vendors as well to think through potential threats in their services. In the Threat Mitigation section toward the end of the post, we offer some more GCP-specific configuration choices that can help mitigate some of these various types of security threats.
STRIDE Overview
The STRIDE model can be used to visualize network and infrastructure threats, derived from the architecture overview and the data flows. The STRIDE model derives its name from an acronym for the threat groupings that it uses to categorise the threats (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service and Elevation of Privilege).
The method builds on the diagram, and the security controls implemented, to enumerate distinct methods that may be used by an attacker, either independently or in conjunction with each other, to compromise the system.
- Spoofing – Spoofing is a violation of authenticity.
- Tampering – Tampering is a violation of integrity.
- Repudiation – Claiming to have not performed an action.
- Information Disclosure – Information disclosure is a violation of confidentiality.
- Denial of Service – Denial of service (DoS) is a violation of availability.
- Elevation of Privilege – Elevation of privilege is a violation of authorisation.
Source: https://en.wikipedia.org/wiki/STRIDE_(security)
Google Cloud Storage Key Features
Using publicly available documentation provided by Google, it was possible to identify the key features of the Google Cloud Storage service.
| Feature | Description |
| Storage Bucket | Stores uploaded data objects. |
| Object | Data is uploaded to a bucket as an object. |
| Upload/download objects | Objects can be uploaded or downloaded from a bucket. |
| Bucket IAM Permissions | Access to a bucket can be controlled through Identity and Access Management (IAM). Uniform and Fine-grained access models. |
| Signed URLs | Signed URLs contain authentication information in their query string, allowing users without credentials to perform specific actions on a resource, such as buckets. |
| Object ACLs | Access to individual objects can be controlled Access Control Lists (ACLs). Fine-grained access model only. |
| Object versioning | Objects can have multiple versions. |
| Retention Policy | Deletion or modification of objects can be prevented for a specified minimum period after they are uploaded. |
| Object lifecycle | Based on lifecycle rules, actions can be applied to objects when certain conditions are met. |
| Replication | Replication of data between regions. |
| Encryption | Storage is encrypted using either a Google Managed Key, Customer Managed Key or Customer Supplied Keys. |
| Event-based hold | When enabled, event-based holds are placed on objects when they are uploaded to the bucket. |
| Prevent Public Access | Ensures the bucket and objects are not publicly accessible. |
| Labels | Key-value pair labels are used for organising resources. |
| Logging & Monitoring | Logging and monitoring are available through Google Operations. |
| Static website content | Static website content can be hosted in buckets. |
| Organisation Policies | Constraints can be set over the use of the Cloud Storage service. |
| VPC Service Controls | Access restrictions can be set on the Cloud Storage API. |
| Access from other GCP services | Other GCP services can access cloud storage buckets, through the Google API. |
| Single of multi-regional | Depending on performance, and availability requirements, data can be single, dual, or multi-regional. |
Diagram
The diagram of the Google Cloud Storage service was produced using the publicly available documentations and through access to a GCP console in a test environment. The aim of the diagram is to provide a high-level view of the main interfaces and components involved in the Google Cloud Storage service.
Assets
Assets represent data, functionality, or an attribute of a system that a threat actor is interested in acquiring. The assets identified that would need protection when using Google Cloud Storage, would likely to be the data stored in the buckets, the authentication credentials that would be used to access the service, and any audit log related data.
| Asset ID | Asset Name |
| A01 | Bucket object data |
| A02 | Authentication tokens |
| A03 | Log data |
Threat Actors
Threat actors are individuals that attack the system to either gain access to sensitive information or disrupt the system’s normal behaviour. We could consider the following potential threat actors to model attack scenarios against Google Cloud Storage.
| Threat Agent ID | Threat Agent |
| TA01 | Internal attacker |
| TA02 | Internal malicious user |
| TA03 | Compromised internal service |
| TA04 | Compromised external service |
| TA05 | External attacker over the Internet |
| TA06 | Google Engineers |
Attack Goals
An attacker’s motives and goals are often hard to accurately predict, but for Google Cloud Storage are likely to fall in the following categories.
| Attack Goal ID | Attack Goal |
| AG01 | Gain access to data content |
| AG02 | Compromise stored data integrity |
| AG03 | Disclose data content |
| AG04 | Tamper with security controls |
| AG05 | Elevate Privileges |
| AG06 | Host malicious content |
Default Base Security Controls
Transport layer encryption and data-at-rest encryption are enabled by default on Google Cloud Storage and cannot be disabled by GCP users. These represent the default base security controls identified for the threat model. By default, data-at-rest encryption is enabled on buckets using a Google Managed Key, however Customer Managed Keys can also be used.
Other security controls are available and configurable on Google Cloud Storage, as can be seen in the key features. When enabled and configured correctly these can significantly improve the security of the service.
| Control ID | Default Base Security Control |
| C01 | HTTPS transport layer encryption |
| C02 | Data-at-rest encryption |
Potential System Weaknesses
By examining the diagram, it is possible to find areas of relative security weakness (i.e.: opportunities for stronger security configurations) in Google Cloud Storage, when only the default base security controls are in use. The following potential weaknesses and opportunities for user-driven increased security were identified.
- Weak administrator credentials, without Multi-Factor Authentication (MFA) could be stolen or guessed, which could lead to disclosure, modification, or loss of data. This could also lead to the weakening of the Cloud Storage security settings.
- Like for all cloud services, user credentials with Cloud Storage permissions could be stolen or guessed (e.g. through phishing and password guessing attacks), which could lead to disclosure, modification, or loss of data.
- Like for all cloud services, service account credentials used by external services and other GCP projects could be stolen or guessed (e.g. through phishing and password guessing attacks).
- Like for all cloud services, service account credentials used by other GCP services to access the storage bucket could be intercepted, stolen, or guessed (e.g. through phishing and password guessing attacks).
- External service is compromised, which could lead to the disclosure, modification, or loss of data.
- GCP service or application code is compromised, which could lead to the disclosure, modification, or loss of data. For example:
- Vulnerability in code running on a VM.
- Vulnerability in code running on App Engine or Cloud Functions.
- Vulnerability in GCP service itself.
- Cloud storage bucket is publicly exposed, which could lead to the disclosure of data.
- Overly permissive access controls could lead to loss of confidentiality, integrity and availability by other GCP projects or Google Identities.
- Cloud Storage service outage causing loss of access to data, or loss of data.
- Service issues not being identified and resolved quickly, due to:
- Lack of monitoring
- Lack of logging resulting in and inability to identify issues
- Organisation/project owner
- Lack of detailed logging, impacting security investigations and repudiation.
- Google personnel accessing data stored in Cloud Storage buckets.
List of Potential Threats
Based on the potential security configuration options and their associated strength/weakness identified in Google Cloud Storage, the following are a list of potential threats.
| T01 Theft of Google Cloud Platform login credentials or access tokens |
| An attacker steals credentials stored on a user’s computer or on an external service, allowing access to the Cloud Storage service. This relies on compromising or having access to the user’s computer or the external service. |
| Impact: With low privileged access, an attacker could gain access to the bucket with potentially read/write permissions. With administrator permissions, an attacker could adversely modify the buckets security settings in the associated project. |
| Threat Actor: TA01, TA02, TA05 |
| Targeted Assets: A02 |
| STRIDE Categorisation: Spoofing, Elevation of Privileges |
| T02 Guessing of Google Cloud Platform credentials |
| An attacker obtains credentials through a guessing attack, allowing access to the Cloud Storage service. |
| Impact: With low privileged access, an attacker could gain access to the bucket with potentially read/write permissions. With administrator permissions, an attacker could adversely modify the buckets security settings in the associated project. |
| Threat Actor: TA01, TA02, TA05 |
| Targeted Assets: A02 |
| STRIDE Categorisation: Spoofing, Elevation of Privileges |
| T03 Unauthenticated access to Google Cloud Storage bucket |
| An attacker attempts to access the Google Cloud Storage bucket without authentication. |
| Impact: With weak access controls configured on the bucket, potentially sensitive data could be disclosed over the public Internet. It should be noted that some scenarios exist, where unauthenticated public access to buckets is required. For example, when sharing non-sensitive information to the public. |
| Threat Actor: TA01, TA05 |
| Targeted Assets: A01 |
| STRIDE Categorisation: Spoofing, Information Disclosure |
| T04 Authenticated access to Google Cloud Storage bucket |
| An attacker with a valid Google identity can gain authenticated access the Google Cloud Storage bucket. |
| Impact: Depending on the permissions obtained, an attacker could potentially gain read/write access to the bucket. The permissions obtained will depend on the roles granted to the credentials used to access the bucket. If weak access controls have been configured, data could be disclosed, modified, or deleted. |
| Threat Actor: TA01, TA05 |
| Targeted Assets: A01 |
| STRIDE Categorisation: Elevation of Privilege, Information Disclosure |
| T05 Deletion or Modification of data stored in Google Cloud Storage bucket |
| An attacker could tamper with the data stored in the Google Cloud Storage bucket, affecting its integrity. |
| Impact: An attacker with sufficient permissions, could gain write access to the bucket.This could lead to data being modified or deleted. |
| Threat Actor: TA01, TA02, TA05 |
| Targeted Assets: A01 |
| STRIDE Categorisation: Tampering |
| T06 Writing malicious content to the Google Cloud Storage bucket |
| An attacker could write malicious content to the Google Cloud Storage bucket. |
| Impact: An attacker with sufficient permissions, could upload and host malicious content, which could then be used in further attacks. |
| Threat Actor: TA01, TA02, TA05 |
| Targeted Assets: A01 |
| STRIDE Categorisation: Tampering |
| T07 Exfiltration of data stored in Google Cloud Storage bucket |
| An attacker could exfiltrate data stored in the Google Cloud Storage bucket. |
| Impact: An attacker with sufficient permissions, could gain read access to the bucket.This could lead to data being downloaded from the bucket and utilised by the attacker for their own gain. |
| Threat Actor: TA01, TA02, TA05 |
| Targeted Assets: A01 |
| STRIDE Categorisation: Information Disclosure |
| T08 Exploitable vulnerability in external service |
| An attacker may exploit security flaws in the external service, which may lead to the compromise of the affected service. |
| Impact: An attacker who has compromised an external service, such as a third party, could potentially gain access to service account keys and utilise them to gain access to the bucket. |
| Threat Actor: TA05 |
| Targeted Assets: A01 |
| STRIDE Categorisation: Elevation of Privileges |
| T09 Exploitable vulnerability in the application code running on Google Cloud Platform services |
| An attacker may exploit security flaws in the application code running in Google Cloud Platform services, which may lead to the compromise of the affected application or virtual machine. Such Google Cloud Platform services include App Engine, Cloud Function or Compute Engine. |
| Impact: An attacker who has exploited a vulnerability in an application, could potentially utilise the applications functionality or service account keys to gain access to the bucket. |
| Threat Actor: TA01, TA05 |
| Targeted Assets: A01 |
| STRIDE Categorisation: Elevation of Privileges |
| T10 Exploitable vulnerability in Google Cloud Platform services |
| In the event of undiscovered vulnerabilities in GCP services, an attacker may exploit security flaws in the Google Cloud Platform services themselves, which may lead to the compromise of the affected service. |
| Impact: An attacker who has exploited a vulnerability in a Google Cloud Platform service utilised by the project, could potentially gain access to service account keys or other methods and use them to access to the bucket. |
| Threat Actor: TA01, TA02, TA05 |
| Targeted Assets: A01 |
| STRIDE Categorisation: Elevation of Privileges |
| T11 Logs do not contain sufficient data |
| Logs do not capture enough data to support an investigation following an incident. |
| Impact: With insufficient logging of events, it would be unlikely that an attack would be detected quickly, and the source of the attack identified with any certainty. |
| Threat Actor: TA01, TA02, TA03, TA04, TA05 |
| Targeted Assets: A01 |
| STRIDE Categorisation: Repudiation |
| T12 Deletion of Logs |
| An attacker could delete log entries in the Google Cloud Platform logging service, affecting the log integrity. |
| Impact: An attacker with sufficient permissions, could delete the projects logs potentially covering the tracks and activities. |
| Threat Actor: TA01, TA02, TA03, TA04, TA05 |
| Targeted Assets: A03 |
| STRIDE Categorisation: Tampering |
| T13 Access to log data in Google Cloud Platform |
| An attacker could gain access to log data in the Google Cloud Platform logging service. |
| Impact: An attacker with sufficient permissions, could access the projects logs and gain security related information. |
| Threat Actor: TA01, TA02, TA03, TA04, TA05 |
| Targeted Assets: A03 |
| STRIDE Categorisation: Information Disclosure |
| T14 Google Cloud Storage bucket become unavailable |
| An attacker could make the Google Cloud Storage bucket unavailable. |
| Impact: An attacker with sufficient resources could potentially render the Google Cloud Storage bucket unavailable, making it impossible to read or modify existing data stored in the bucket, or write new data to the bucket. |
| Threat Actor: TA03, TA04, TA05 |
| Targeted Assets: A01 |
| STRIDE Categorisation: Denial of Service |
| T15 Google personnel accessing Cloud Storage bucket |
| Google personnel access the storage bucket, affecting the stored data’s confidentiality, integrity, and availability. |
| Impact: Google Personnel, such as an engineer could gain access to the bucket and potentially read, modify, or delete data. There are Access Transparency and Access Approval option to prevent it. |
| Threat Actor: TA06 |
| Targeted Assets: A01 |
| STRIDE Categorisation: Information Disclosure, Tampering |
Threat Mitigation
Google Cloud Platform provides a range of security controls that can be used to mitigate the threats identified. The following section gives more security control recommendations and security best practices that can be used to mitigate each threat.
T01 Theft of Google Cloud Platform login credentials or access tokens
- Enable Multi-Factor Authentication on all Google identities.
- A strong password policy should be used to set passwords on all Google identities, using uppercase, lowercase, numbers, and special characters. Passwords should be a least 10 characters in length.
- Where possible do not use service account keys, use an alternative service account authentication method:
- Service account impersonation
- Attached service accounts
- Workload Identity
- Ensure that Google Cloud Storage roles are granted to principals using IAM rather than primitive roles, following a principle of least privileges.
- VPC Service Controls can be used to restrict which IP addresses and principals can access the Google Cloud Storage API.
T02 Guessing of Google Cloud Platform credentials
- Enable Multi-Factor Authentication on all Google identities.
- A strong password policy should be used to set passwords on all Google identities, using uppercase, lowercase, numbers, and special characters. Passwords should be a least 10 characters in length.
- Ensure that Google Cloud Storage roles are granted to principals using IAM rather than primitive roles, following a principle of least privileges.
- VPC Service Controls can be used to restrict which IP addresses and principals can access the Google Cloud Storage API.
- Security Command Center with event threat detection can be utilised to identify attacks.
- Configuring log metrics and alerts in the Google Operation Monitoring service, will help detect persistent requests being made to the login API.
T03 Unauthenticated access to Google Cloud Storage bucket
- Google recommends using “uniform” access controls on Google Cloud Storage buckets, rather than “fine grained” access controls. Uniform access controls can be enforced on buckets across the Google Cloud Platform organisation, by enforcing the “Enforce uniform bucket-level access” organisation policy.
- Ensure that Google Cloud Storage roles are granted to principals using IAM rather than primitive roles, following a principle of least privileges.
- Avoid granting access to the “AllUsers” principal, as this will all public access.
- To disable public access on a bucket, select “Enforce public access prevention on this bucket” during its creation, or the “PREVENT PUBLIC ACCESS” option once the bucket has been created.
- Public access on buckets across the Google Cloud Platform organisation, can also be prevented by enforcing the “Enforce Public Access Prevention” organisation policy.
- VPC Service Controls can be used to restrict which IP addresses and principals can access the Google Cloud Storage API.
T04 Authenticated access to Google Cloud Storage bucket
- Google recommends using “uniform” access controls on Google Cloud Storage buckets, rather than “fine grained” access controls. Uniform access controls can be enforced on buckets across the Google Cloud Platform organisation, by enforcing the “Enforce uniform bucket-level access” organisation policy.
- Ensure that Google Cloud Storage roles are granted to principals using IAM rather than primitive roles, following a principle of least privileges.
- Avoid granting access to the “AllAuthenticatedUsers” principal, as this will allow any Google Identity to access the bucket.
- VPC Service Controls can be used to restrict which IP addresses and principals can access the Google Cloud Storage API.
T05 Deletion or Modification of data stored in Google Cloud Storage bucket
- Using IAM, restrict which principals can delete or update objects in the bucket. Follow the principle of least privileges.
- Enable object versioning on the bucket, so that previous versions of the object can be recovered.
- Configure a retention policy on the bucket, to prevent objects from being modified or deleted for a minimum period. A retention policy can be enforced on buckets across the Google Cloud Platform organisation, by enforcing the “Retention policy duration in seconds” organisation policy.
T06 Writing malicious content to the Google Cloud Storage bucket
- Using IAM, restrict which principals can create objects in the bucket. Follow the principle of least privileges.
- VPC Service Controls can be used to restrict which IP addresses and principals can access the Google Cloud Storage API.
- Configure a cross-origin resource sharing (CORS) policy on buckets to specify which origins are permitted to access the bucket.
- An event-driven pipeline can also be implemented that automatically performs malware scanning on objects uploaded to Google Cloud Storage.
T07 Exfiltration of data stored in Google Cloud Storage bucket
- Using IAM, restrict which principals can list and view objects in the bucket. Follow the principle of least privileges.
- VPC Service Controls can be used to restrict which IP addresses and principals can access the Google Cloud Storage API.
- The Google Cloud Data Loss Prevention (DLP) service can be used to automatically obfuscate sensitive data.
T08 Exploitable vulnerability in external service
- Using IAM, ensure that the service account used by the external service to access the Google Cloud Storage bucket has the minimum permissions required and does not have permissions on other services unless absolutely required. Follow the principle of least privileges.
- Enable “Data Read” and “Data Write” audit logs on the Google Cloud Storage service.
T09 Exploitable vulnerability in the application code running on Google Cloud Platform services
- Using IAM, ensure that the service account used by the application to access the Google Cloud Storage bucket has the minimum permissions required and does not have permissions on other services unless absolutely required. Follow a principle of least privileges.
- Enable “Data Read” and “Data Write” audit logs on the Google Cloud Storage.
- The Google Cloud Web Security Scanner can be run against the application to identify potential security problems.
- Security Command Center can identify potential weaknesses in Google Cloud resources.
- Cloud Armour can provide DDoS and Web Application Firewall (WAF) protection for the application.
- Notably, like any computer system, we cannot fully defend against yet-to-be-discovered exploitable vulnerabilities before they are found, so these mitigations are inherently incomplete, as they would be for any cloud service of software/hardware in general.
T10 Exploitable vulnerability in Google Cloud Platform services
- Google Cloud Platform services undergo rigorous security assessments.
- The Google Bug Hunters program allows groups or individuals to find and report vulnerabilities within Googles products, including Google Cloud Platform.
- Notably, like any computer system, we cannot fully defend against yet-to-be-discovered exploitable vulnerabilities before they are found, so these mitigations are inherently incomplete, as they would be for any cloud service of software/hardware in general.
T11 Logs do not contain sufficient data
- Enable “Data Read” and “Data Write” audit logs on the Google Cloud Storage service.
T12 Deletion of Logs
- Using IAM, ensure that only the logging service administrators in the project are granted permissions to delete the logging buckets. Follow a principle of least privileges.
- VPC Service Controls can be used to restrict which IP addresses and principals can access the logging API.
- Configure a retention policy on the log bucket, to prevent logs from being modified or deleted for a minimum period. A retention policy can be enforced on buckets across the Google Cloud Platform organisation, by enforcing the “Retention policy duration in seconds” organisation policy.
T13 Access to log data in Google Cloud Platform
- Using IAM, ensure that only the appropriate operations team members for the project are granted permissions to view the logs. Follow a principle of least privileges.
- VPC Service Controls can be used to restrict which IP addresses and principals can access the logging API.
T14 Google Cloud Storage bucket become unavailable
- Google Cloud Platform is globally distributed for resilience and high availability.
- To improve performance and availability, buckets can be created in two or multiple regions, making them more resilient to attack or regional outage.
- VPC Service Controls can be used to restrict which IP addresses and users can access the Google Cloud Storage API.
- Enable “Data Read” and “Data Write” audit logs on the Google Cloud Storage service to improve logging and monitoring.
- Configuring log metrics and alerts in the Google Operation Monitoring service, will help detect high volumes of requests and traffic.
T15 Google personnel accessing Cloud Storage bucket
- Enrol the organisation in the Google Access Approval service. Once the organisation has been enrolled, Google Personnel will require your explicit approval before they can access data. Access Approval ensures that a cryptographically signed approval is obtained before Google personnel can access an organisation’s content stored on Google Cloud.
- Enable “Access Transparency” within the organisation or project. Access transparency logs provide insights into Google personnel activity, such as fixing faults.
Conclusion
The threat modelling exercise has demonstrated that user/tenant configuration choices matter when evaluating the overall security posture of an instance of Google Cloud Storage, and that a number of relative weaknesses can be improved through deliberate choices on behalf of the user. We would also recommend, as we would in any cloud platform, that the storage bucket (in this case, the Google Cloud Storage bucket) be fully secured prior to the ingress of non-public or otherwise sensitive data.
GCP and the Google Cloud Storage service provide robust security controls that can mitigate all the threats identified during the exercise. When configured correctly, these security controls significantly improve the security of the bucket, making it more suitable for storing more sensitive classes of data.
原文始发于Ken Wolstencroft：Threat Modelling Cloud Platform Services by Example: Google Cloud Storage
转载请注明：Threat Modelling Cloud Platform Services by Example: Google Cloud Storage | CTF导航
相关文章
