Security in Google Cloud Platform (GCP) is straightforward, right? GCP gives you everything you need to secure your workloads? If your answer was ‘No’, you’re in the right place.
Welcome to Part 1 of the Valtix blog series on GCP. In this series, we will cover an assessment of GCP, some best practices for securing apps in GCP, and how Valtix works on GCP. Here in part 1, we’ll assess the security of GCP – not from the perspective of the cloud platform itself (Google does quite well there), but from the perspective of customer workloads that run on GCP. Some significant gaps are becoming more apparent as organizations put more critical apps onto GCP.
We’re going to focus this series on the GCP Network Security stack. At Valtix, we believe the network is the essential place to secure workloads because security can be deployed in less obtrusive yet effective ways across all app architectures. We will not get into issues of identity management or other aspects of posture management. Our focus is on how you deploy security controls in cloud-native ways that can effectively stop attacks.
GCP is Focused on Securing GCP – Your Apps are Your Problem
The first piece that will help us understand how to assess workload security on GCP is the shared responsibility model itself. Nearly every aspect of security for the cloud platform is handled by Google, and nearly every aspect of customer workload security is the responsibility of the customer. This is typical for any public cloud. That said, GCP does provide some tools, but this framing is important to keep in mind as we move through the series.
The main issue with GCP security is the same as with any cloud platform – there is no comprehensive approach. This means that there are lots of cracks for things to slip through as your cloud deployment grows: you deploy new applications, new VPCs and new projects. GCP, like other cloud platforms, provides some tools, but they are best effort – remember, their responsibility is securing their platform, not your workloads. This means these tools are piecemeal with various management approaches for different app architectures. GCP provides the following::
- Cloud Armor – DDoS protection at layer 3 and 4 (similar to AWS Shield) and web application firewall (WAF). This protects Internet-facing web applications against attacks, (ingress security).
- Limitation: Does not cover non-web apps.
- GCP Firewall – stateful firewall and ACLs (similar to AWS Security Groups) that allow traffic on customer-opened ports and approved GCP resources. This serves as a basic segmentation mechanism for ingress, east-west, and egress. It does not actually inspect the content of the traffic to determine good versus malicious traffic, or for sensitive data. GCP network endpoint groups (NEG) provide the same IP- and port-based protections for container and backend services.
- Limitation: No inspection of traffic content, does not stop L4-L7 attacks.
- GCP Cloud IDS – content inspection of mirrored traffic with no native ability to decrypt traffic. This does not sit inline with traffic and cannot prevent or block malicious actions.
- Limitation: Detects attacks, doesn’t prevent, and does not work on encrypted traffic.
These limitations and lack of a single security policy, management plane, or architecture means that fundamental capabilities like visibility and inspecting for malicious flows are casualties and must be augmented by yet even more discrete tools.
The Myth of the Invulnerable Workload and the Criticality of Defense in Depth
Cloud evangelists suggest that identity and access management are adequate, as long as one keeps their workloads patched. The challenge there is that last bit – keeping workloads invulnerable is operationally impossible – as recently highlighted by Log4J/Log4Shell – which many organizations will cope with for months despite extensive tooling and automation.
This window of vulnerability that will always exist has organizations returning to the wisdom of defense-in-depth – highlighting the need for a comprehensive approach to security. The other demand for defense-in-depth comes from other reminders – malicious insiders and impersonation (the latter of which is often a necessary function in the cloud).
The other major issue with the lack of a comprehensive approach to security is that time and cost to achieve compliance go way up. Because of the piecemeal nature of security in GCP, the documentation and controls needed to comply with various regulations (e.g., HIPAA) and agreements (e.g., PCI) are much more difficult and require more manual effort.
Closing Out
The bottom line on an assessment of GCP workload security is that customers need to bring their own. While some components provided by Google may be useful in isolated situations, an enterprise cloud environment requires a much more complete answer for security. In Part 2 of this series, we’ll dive into what that might look like.
