Cloud Native Application Security: Protection At and Within the Perimeter

What makes an application “cloud native” and what’s so different about protecting these kinds of apps? Ultimately, the answer lies in how cloud native applications are not as tightly bound to the infrastructure as traditional on-premise, monolithic applications. Read on to learn more about how this shift is changing how security leaders think about application security and how Signal Sciences can help protect your cloud native apps!

BeyondProd: A New Model for Application Security

In December, Google published the BeyondProd white paper , outlining a new model for application security for cloud native applications. “BeyondProd” takes its name from Google’s influential “ BeyondCorp “ approach to enterprise network security and their implementation of a zero-trust network. Both white papers argue that security at the perimeter is no longer enough and that access controls should not be implemented just at the borders of a network or edge of an application, but also applied to individual users and devices (in the case of a network) and individual microservices (in the case of a cloud native application). In other words, communications between microservices shouldn’t be trusted based on “where” they are deployed (e.g. behind the same firewall), but rather based on “what” is making the request (identity of the microservice) and “who” the microservice is making it for (end user authentication and authorization).

Why Aren’t Secure Perimeters Enough for Cloud Native?

The term “cloud native” tends to get overused and the definition hasn’t always been so clear. But in recent years a broad consensus has formed around what makes an application truly “cloud native”. This typically entails the use of container-based infrastructure, a container orchestration tool (Kubernetes being the standard), and a microservices architecture (perhaps not as hard a requirement as the first two).

One of the great benefits of containers is portability, which includes being able to run the same application code, predictably, across a whole range of different host types whether that is a developer’s laptop, a bare metal server, an on-premise virtual machine, or a serverless environment like AWS Fargate. The portability of containers is one of the fundamental reasons application security mustn’t stop at the perimeter — containerized workloads can and will be deployed in a large variety of environments, unlike traditional monolithic applications that had pretty set rules on where and when they could be deployed. Google’s point in “BeyondProd” is that microservices today are a lot like today’s users — no longer tied to the same IP address day in, day out, but instead highly mobile and yet have to be secure everywhere.

What’s Needed for Cloud Native Application Security

According to the “BeyondProd” white paper, the following requirements are prescribed in securing cloud native applications:

• Mutually authenticated service endpoints.
• Transport security.
• Edge termination with global load balancing and denial of service protection.
• End-to-end code provenance.
• Runtime sandboxing.

The white paper covers in depth on how Google implemented the above with technologies they’ve built. However, service meshes like open source are now available to handle some of these requirements-primarily the first two. Istio provides mutual TLS (mTLS) encryption between microservices deployed on the service mesh, authenticating microservices to confirm they are who they say they are as well as encrypting that service-to-service traffic. Furthermore, Istio handles authorization with policies that can be set to allow or deny communications between services.

What Does WAF Look Like Here?

Web Application Firewalls (WAF) originated from a time when perimeter security was deemed sufficient (“firewall” being a key term here). WAFs are still predominantly deployed at the perimeter (or edge) of an application, but is there a way for the layer 7 protection that WAFs provide to be deployed in a zero-trust model, ensuring that malicious requests sent between microservices (and not just external requests) are detected and blocked? With a traditional appliance-based WAF this would be impossible. However, newer software-based WAFs with agent-based architectures do have an opportunity here.

In fact, at Signal Sciences, our customers routinely deploy our next-gen WAF both at the perimeter and on individual workloads behind the firewall, made possible by our , deploying our agent-module architecture . Also, now that the Signal Sciences agent can integrate directly with the Envoy cloud native proxy and Istio service mesh next-gen WAF throughout your cluster is even simpler, ensuring the next-gen protections provided by Signal Sciences follows your microservice workloads and APIs no matter where they are running.

Ready to learn more about how Signal Sciences can protect your cloud native applications? Sign up here for a demo !

Originally written by Alfred Chung, Sr. Product Manager and published at https://www.signalsciences.com on February 13, 2020.