The second blog in our series on GCP security is about “GCP security best practices”. If you haven’t checked out the first part, check it out for more context on part 2.
Now that we’ve identified the missing pieces to securing your apps in GCP, what to do about it? Do we need a big, heavy framework like we had in the data center? Do we need more developers? Do we need lots of security people to look at lots of disparate event streams? Ok, sorry for being a bit dramatic, but some of my conversations do go like that. Here, in part 2, we’re going to cover some of the approaches available to enterprises to secure their apps running in GCP.
For the GCP security best practices article, part 2 of our Google Cloud Platform security series, we’re going to use a guiding quote from part 1: “The 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.” Our job here is to fix this. Keep reading for GCP security best practices.
- Comprehensive visibility and control
- Features and functions
- Compliance
Comprehensive Visibility and Control
So basically, step 1 in our GCP security best practices is comprehensive visibility and control. Knowing what apps you have, how they are connected, and being able to control and place controls on that connectivity is what we’re talking about. There has been a significant emphasis placed on posture management – which is good – but that’s not what we’re talking about here.
The focus here is on actual control and actual protection, and not just misconfigurations. The visibility required to place that protection – not only awareness of what you need to patch. We have described it as “visibility for control’s sake”.
There are a couple of ways to do this in the cloud – agents that sit in the compute infrastructure and network-based solutions. Architecturally, agents have some advantages in that they can control the compute environment the app is running on, but that specificity comes at a cost (you need a specific agent for each kind of app environment – and the agent architecture doesn’t work for serverless or cloud-managed PaaS).
We like the network implementation for three reasons:
- All apps touch the network – one implementation works for every application architecture
- A single policy is possible
- Visibility and control are through the same aperture
A word on encryption: everything is encrypted in the cloud (TLS). And a security architecture must accommodate that at a system level. Otherwise, potentially each app or security function’s decrypt/encrypt might have to be managed independently, which does not scale from an operations perspective – a non-starter for many organizations.
Features and Functions
In terms of the features and functions required for a comprehensive approach, without the policy and control gaps we identified in step 1, we see cloud firewalling as the basis.
Segmentation (at varying levels of granularity) is a foundational requirement – determining which workloads can be accessed from the outside (ingress) by other workloads (east-west) and can make connections to outside services (egress) is the starting point.
Segmentation does not have to be about access control alone but also can be combined with granular inspection policies based on workload context and security requirements. Beyond that, we see organizations placing a lot of emphasis on IDS/IPS in the post-Log4Shell era, especially to prevent lateral movement of attacks. Compliance teams also are putting WAF and DLP on the agenda.
So, in summary, the requirements for GCP security look like this:
- Inbound threat defense (IPS/WAF)
- Cloud microsegmentation
- Outbound threat defense (C&C/DLP – egress security)
In the data center days, this would point to a big rack of appliances. In GCP, appliances are an awkward fit at best, like other public cloud platforms. Cloud-native services for security, like everything else in GCP, are the standard. A single control plane, using a single policy per app – across all of these security functions – is even better.
Compliance
I mentioned compliance earlier. It’s worth bringing up again as a final point. Most organizations are touched in some way by the need to comply with various regulations. Most standards for compliance have specific requirements for network-based controls that are easier to manage than app-based controls at enterprise scale. And when you have a comprehensive security approach that includes segmentation, IDS/IPS, and Cloud WAF, time and cost to compliance are greatly reduced.
We hope you enjoyed part 2 of our series, GCP Security Best Practices. In part 3, I’ll cover the product choices we made at Valtix, and how enterprises use Valtix in GCP.
