Securing Apps on Google Cloud Platform, Part 1: Finding Your Missing Pieces
Google Cloud Platform (GCP) has significantly grown in popularity over the last few years. While they have made strides to make their environment more intuitive for their customers, the breadth and depth of their homegrown security offerings to secure workloads in their environment leaves organizations longing for greater richness in control.
In this three-part Cisco Multicloud Defense series on GCP, we will cover an assessment of GCP, some best practices for securing apps in GCP, and how Cisco Multicloud Defense works on GCP. In Part 1, we'll assess the security of GCP—not from the perspective of the cloud platform itself, which Google does quite well, but from the perspective of customer workloads that run on GCP and their network security stack. From there, we will highlight trends in gaps that become more apparent as organizations stand up more critical apps onto the cloud environment.
The network is essential for securing workloads because security can be deployed in less obtrusive, yet effective, ways across all app architectures. We won't get into issues of identity management or other aspects of posture management. Our focus is on how you deploy built-in cloud security controls that can effectively and efficiently stop attacks.
GCP secures its environment, and you secure your apps
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.
Figure 1. GCP network security architecture
The main issue with GCP security is the same as with any cloud platform: There is no comprehensive approach to securing workloads. This means many things can slip through the cracks as your cloud deployment grows, leading to inadequate security for your newly deployed applications, virtual port channels (VPCs), or even projects. GCP, like other cloud platforms, provides some tools, but they lack unified control across them, using 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 access control lists (ACLs), which are 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 conduct deep packet inspection to determine if traffic is malicious or considered sensitive. GCP network endpoint groups (NEG) provide the same IP- and port-based protections for container and back-end services.
Limitation: GCP firewall provides L3–L4 protection only.
GCP Cloud IDS: Content inspection of mirrored traffic with no core ability to decrypt traffic. This does not sit in-line with traffic and cannot prevent or block malicious actions.
Limitation: Protects unencrypted traffic only. In today's world, more than 80% of traffic is encrypted.
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, creating unwanted vendor sprawl.
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 they keep their workloads patched. However, keeping workloads invulnerable is operationally impossible, as recently highlighted by Log4J/Log4Shell. Many organizations will now have to cope with this issue for months despite extensive tooling and automation.
This window of vulnerability that will always exist has organizations returning to the practice of defense-in-depth, highlighting the need for a comprehensive approach to security. Other considerations for returning to defense-in-depth practices include mitigating risk against malicious insiders and impersonation, the latter of which is often a necessary function in the cloud.
The other major issue that stems from a lack of a comprehensive approach to security is the greater time spent and increased overhead cost associated with maintaining compliance. Because of the piecemeal nature of security in GCP, the documentation and controls needed to comply with various regulations, such as the Health Insurance Portability and Accountability Act of 1996 (HIPAA), and agreements, such as PCI. Compliance for such regulations is much more difficult and require more manual effort.
Closing out
When it comes to securing workloads in cloud environments such as GCP, often organizations prefer to bring in a third-party security solution. 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.
