INTRODUCTION TO GCP PENTESTING

Why should you test the security of your GCP Cloud?

Traditional private cloud or on-premise network penetration testing is different to penetration testing cloud environments, in the same way that designing, configuring, deploying and managing cloud architecture is different to the implementation and support required for traditional infrastructure. Public Cloud hosting providers, like Google Cloud Platform (GCP), provide a range of features and services, but typically follow the shared-responsibility model.  Shared responsibility is where the hosting provider is responsible for the security OF the cloud, such as the security associated to hardware and network infrastructure, and the customer is in charge of the security IN the cloud, such as the config of your servers, permissions granted within your architecture, and much more.

Cloud platforms can be compromised in many ways with misconfigurations that can mean your business is vulnerable to attackers. Black hat hackers (the baddies) are not the only threat though.  Employees should also be monitored closely too – for a few reasons – including the potential for their own malicious actions, their capability to be compromised by an external attacker or even their potential for making errors that open security holes.

Penetration testing GCP architecture allows you to audit the security of your applications and infrastructure that typically wouldn’t be directly tested during an assessment or by an external attacker.

GCP pentesting is an authenticated security assessment that aims to conduct almost a simulation of a malicious actor with the same permissions. This comprises an assortment of methods to exploit and create abuse of functionality to benefit the hacker.

The audit will secure an organisation and it’s environment to the strongest level possible for if a malicious actor gains unauthorised access to the network.

How do attackers gain access to GCP?

 Common methods that malicious actors use to gain access to cloud environments apply to nearly all Cloud providers.  Some of these methods include the following: 

1) External 3rd parties.  This can be a malicious entity undertaking actions that you are not aware of or an organisation that you trust that is compromised.  

2) Git repositories.  Mistakes in repository configurations leaking and publishing sensitive data.  

3) App and server vulnerabilities.  Credentials are stolen through a server’s metadata through remote code execution (RCE) / server-side request forgery (SSRF) or creds saved locally are stolen through local file inclusion (LFI) / RCE.  

4) Password re-use.  An old database is compromised and users are still using these passwords or users are using the same passwords across various other logins.

5) Social engineering.  These can be phishing emails, pretext calls or physical threats where physical security is weak. 

6) Internal employees.  Compromised employees can carry threats into your organization.  Their mistakes can lead to unintended consequences.

Strong password policies, multi-factor authentication (MFA) and strong security policies can still often lead to businesses becoming exposed by these methods.  When a threat actor is within your organisation can you be sure that you’ve carried out full testing to ensure that you have the ability to identify and react.

Common GCP Attacks

There are many organisations in the UK that rely on automated scanning to provide ‘security audits’.  However, we provide in-depth audits of your environment to ensure peace of mind. We assess for a variety of different vulnerabilities and misconfigs.  Examples include: demonstrating what an attacker would do with authenticated access, privilege escalation checks for all users / service accounts that access your GCP estate, testing security controls, and many more.

Reporting

Our reporting has been commended by leading UK city legal firms.  We provide customers with a report at the end of the audit that details all issues and vulnerabilities discovered.  We also any more complex attack routes taken while within the platform. We provide guidance to perform swift and effective remediation.

The purpose of the PrimoConnect reports is to help customers understand the weaknesses within their environment, what risks those weaknesses bring, and how to go about remediating security weaknesses.

As we believe all security teams should, if we discover something with a high priority during a penetration test / audit, such as a critical vulnerability with a large associated risk we will report it to you as soon as it is found.  We will of course help you to remediate the issue quickly and learn from the misconfig / threat thoroughly also.

Do I need to Advise Google of Pentesting GCP infrastructure?

Google has an Acceptable Use Policy that must be followed and you cannot target resources that don’t belong to you, but no, Google does not require it to be advised prior to GCP pentesting. Please check with our senior pen testers though for the latest situation in case this changes.

We do not perform denial of service testing purposefull to avoid breaching Google’s AUP.  Also to not interrupt or disrupt any of our customers production operations during our pen testing. Clients are notified of testing window timeframes.

GCP Penetration Testing – Request A Quote

Penetration testing GCP cloud environments should be made as simple and efficient as possible.

Provide us with details on your specific security requirements and a security expert will contact you as soon as possible.  We can walk you through the entire process of penetration testing your AWS environment.

We respond to all enquiries within the same business day.