Network Security for PaaS Workloads

Note: This is an update to a previous blog on network security for PaaaS workloads published in 2019. The challenges and lessons are the same and are as relevant as ever. However, Valtix has evolved significantly since then. Request a demo if you’d like to learn more about how Valtix can protect your cloud workloads including PaaS and serverless services.

These days, questions are being raised on the overall security of public cloud infrastructures (Azurescape, Log4shell, OMIGOD). Cloud Service Providers (CSP) have always maintained that security of the infrastructure is a shared responsibility between the customer and cloud provider. The number one priority for enterprises today as they migrate (or plan to migrate) to public clouds is to get a better understanding of the security model for PaaS including serverless. To meet security and compliance needs, they need more comprehensive ways to improve their overall security posture in this new environment.

Enterprise Public Cloud infrastructures are fundamentally different from the ones in the on-prem data center. Applications (and their workloads) being developed today in public clouds use a mix of IaaS and PaaS services. Enforcing security in this highly variable and dynamic application architecture is a complex exercise as I will describe later.

In this blog, we will focus on the security of PaaS environments and what you as a customer can do to adopt solutions to protect against breaches, unauthorized access, and other risks.

What is PaaS And Why Is It Popular With Developers?

In addition to public cloud migration, one of the tectonic shifts in infrastructure today is the adoption of PaaS (Platform-as-a-Service) services. PaaS services are popular because as developers, we do not have to manage the underlying infrastructure as the usage of the service grows or shrinks. 

The infrastructure provider is responsible for the overall availability of the service irrespective of the scale. In the public cloud world, the provider is highly incentivized to provide and operationalize such services since it’s a win-win situation in terms of ROI — developers are happy to adopt and the CSP has higher margins for these kinds of services.

Security for PaaS Environments

For too long, we’ve assumed that the PaaS itself is secure. Given recent vulnerabilities in the cloud provider’s managed service offerings (OMIGOD, AzureScape, Log4Shell), organizations should secure their public cloud PaaS deployments.​ To provide consistent security for PaaS environments it’s important to know the security model of a PaaS service.

What is the security model of a PaaS service?

Each cloud provider (AWS, Azure, GCP, and OCI) has a very rich model for enforcing security. At a high level, the security model of a PaaS service includes the following.:

1. Authentication and Authorization. These are described in detail here: Policy Evaluation Logic.
   1. Identity-based: Policies attached to an IAM identity (user, group, role, etc).
   2. Resource-based: Policies attached to the resource accessed by an AWS user.
2. Encryption
   1. Data at rest: Support for data at rest encryption wherever applicable (e.g. RDS, S3)
   2. Data in transit: Support for end-to-end Transport Layer Security (TLS).

The following is an example S3 bucket strategy, where access is restricted to specific IAM users and roles.

Here is another example where access to S3 bucket is restricted by a resource-based policy to specific VPCs and VPC endpoints. This is useful to restrict access to S3 buckets to specific VPCs in your infrastructure. You can also specify IP address whitelists.

While these are a required set of tools, these are not sufficient in terms of the needs of enterprise customers, as exemplified through all the breaches over the years. Restricting access to specific VPCs is a step in that direction, but these are simply not adequate since they are too coarse.

Enterprises need a richer set of tools to control the lateral access to S3 and other PaaS services. One such technique is microsegmentation. Given that these are PaaS services provided by the cloud provider, no third-party tool has access to the host providing the PaaS service. Obviously, host-based security tools cannot help here by definition, but the network could be a great leverage point here. Hence, the only possible approach is network security.

Micro-segmentation in Public Cloud PaaS

How can enterprises achieve micro-segmentation in Public Cloud PaaS workloads? Think of the following use cases –

1. Allow only EC2 instances running CentOS 7.x to download a critical patch from an internal S3 bucket.
2. Allow traffic from a non-AWS data center (say Azure VNet) to access the S3 bucket. In this case, the set of source IP Addresses themselves are dynamic. So it is not trivial to keep updating the IP whitelist feature in S3.

Identity Explained (Benefits and Challenges)

One can achieve microsegmentation through IAM policy in certain scenarios. For e.g., one can assign the instances running CentOS 7.X with a specific IAM policy. Similarly, the resources in the non-AWS hybrid environments could share an IAM policy to be used for S3.  As you can imagine, this is simply a non-trivial exercise.

Apart from the complexity in managing per-user policy versus policies associated with a Role (since a group of users or principals will be affected when there are changes), IAM credentials are not tied to a resource. They are, in fact, tied to a principal which can itself laterally move. For example, let’s say the IAM access keys intended for a specific user are leaked. The attacker can now assume those credentials and thus take over as the user.

Overcoming Complexity in PaaS Security With Microsegmentation

At Valtix, we are working with customers to provide network security at a granular level for enterprise use cases. With our cloud security platform, enterprises can create “tag” based Address Objects to restrict access to internal S3 buckets in a multi-cloud/hybrid-cloud environment. These tags can be native attributes such as “VPC”, “Security Group”, “Instance”, etc., 

In addition, they can be “user defined tags” such as classic “Key/Value” pairs. This is all in an environment with full end-to-end TLS encryption between the client and the PaaS workload managed by AWS.

Let’s revisit the challenges and risks described above. Now with Valtix, we would have achieved the above security use cases in the following way.

1. Define an Address Object based on the Tag “OS=CentOS 7.X”.
2. Defined an Address Object for the Azure VNet “VNet=VNetb”.
3. Allow these two Address Objects to access the internal S3.

This works in conjunction with existing security mechanisms for S3, including IAM-based policies, and resource-based policies for the S3 bucket. With Valtix’s platform, customers can greatly enhance their security posture by implementing advanced micro-segmentation based on both user-defined tags of the resources as well as organic attributes across different cloud providers. They can then easily add monitoring (IDS) or protection (IPS, WAF) in addition to egress security (DLP, egress filtering). 

Going beyond micro-segmentation: DPI for PaaS applications

In the previous example, we have shown in forwarding mode how to achieve micro-segmentation. Valtix also provides a full TLS In / TLS Out proxy for PaaS workloads. With this configuration in place, we can enforce advanced IPS and WAF policies for both inbound and outbound traffic. An important PaaS security use case in this architecture is protection against exfiltration of critical data. Another use case is malware detection for both inbound and outbound traffic.

There are various recommendations provided in various blogs as to how this can be prevented in the future and by other organizations with similar architectures and vulnerabilities. Without repeating and going over all those recommendations, we will focus on Valtix’s approach to providing “multiple layers in defense” for enterprises leveraging the network to enforce security policy. Valtix’s approach to PaaS security is also complementary to the tools provided by the CSP, namely, resource-based policies and identity-based policies.

At a high level, organizations can leverage Valtix’s solution in conjunction with AWS (and other CSP) tools.

AWS Tools:

1. Enforce strict S3 bucket-based policies. Restrict the VPCs which can access specific S3 buckets based on usage. This step prevents lateral access of S3 using stolen IAM credentials from an attacker’s virtual machine.
2. Enforce strict IAM-based policies to restrict access to data necessary to the IAM principals.

PaaS Security With Valtix:

1. Deploy Valtix’ discovery solution that builds an evergreen model of your apps and infrastructure. Tag your applications and create the corresponding policy. Valtix will ensure that the policies move with your apps as the footprint changes or increases across your public cloud deployments.
2. Use Valtix’s WAF solution to protect the Application. Build WAF profiles to protect against SSRF attacks. These profiles can be used in all of your multi-cloud deployments. You can also extend from a Valtix-provided cloud WAF profile that has this policy enabled by default.
3. Implement micro-segmentation using tag-based Address Objects to enforce fine-grained access to S3 within the AWS infrastructure.
4. Implement full DPI of S3 services. This is optional. Enable rich IPS policies to defend against exfiltration of data based on configured regular expressions. This step prevents threats such as attackers assuming IAM credentials on an app server and then using those to exfiltrate data from S3 and other cloud data stores.

Looking forward

Enterprises want a single platform where they can:

• Discover their applications across all of their Public Cloud accounts and regions
• Deploy network security by following the apps and workloads as they grow or shrink
• Defend by enforcing comprehensive network security services based on the workloads

Valtix’s cloud security platform is fundamentally changing how network security is being done in public clouds. As Valtix continues to address the needs of enterprises to secure their public cloud infrastructures by adding new game-changing features, we’ll continue posting our response here in our blogs. Alternatively, if you’d like to get an update on where we’re headed and our roadmap sooner, contact us here and let’s get a demo or meet to discuss your specific needs.