If There Can Be Only One

A few days ago, I attended a application security (appsec) dinner.  I’ll abide by Chatham House rules here and not name names. The dinner & the company was quite pleasant, however, that’s not the topic of this blog, During the course of the dinner, the host asked the group an interesting, if very theoretical and synthetic, question.  “If your application security budget was to be cut where you could only fund the purchase (or license renewal) of one tool, what would that tool be?”

Of course, we all started asking questions that would allow us to game the system, such as “is my headcount budget frozen, reduced, or open?” (answer, “you can hire.”).

While, on the surface, the question and follow-up clarifications are beyond unrealistic, it was an interesting foil to get us all thinking about what the singularly, most important, tool in an application security team’s toolbox is.

There were a few answers that were somewhat out there, but the two that came to the fore were funding bug bounties and a Runtime Application Self-Protection (RASP) platform.

At the time, I was in the bug bounty camp.  We all would agree, I hope, that defense-in-depth is a best practice in today’s threat environment, and there is no one tool that will do it all for you.  The bug bounty crew’s approach was to adopt open source projects to provide that depth, hire to support and adopt those projects, and use bug bounties as a continual scanning tool (think of it as CI/CD/CA, where CA is continual attack/assessment).

The RASP camp was of the opinion that, if all else fails, protect the application.  Ingress controls (such as filters, WAFs, and so forth) were not as important as detecting anomalies in the execution of the code itself.

All of the standard arguments about RASP came up (such as latency, performance impact, etc.).  What was interesting was that none of us (myself included) asked if RASP was still the right approach to inspect and control an application’s behavior in the microservice age.  This is odd as we had earlier discussed how microservices coupled with CI/CD was challenging other security tools such as pen testing and other mainstream tools.

I started thinking about this more on the way home, and came to a different conclusion, at least for a microservice based environment.  Is RASP still the best way to monitor and control your application in a cloud-native or microservice world?

Why am I focusing on microservices?  Let’s think about that for a bit. The whole idea behind microservice architecture is that each functional component is a separate artifact that can be independently versioned, scaled, etc.  The whole concept is based on the premise that smaller, simpler components are easier to continually develop, and that the linkages between components are lightly coupled and well defined.

This contrasts with monolithic environments where all of the components are compiled together and the interactions are internal to the monolithic application.

In the monolithic model, the only way you will be able to instrument, observe, or control those inter-functional interactions is to also be compiled into that monolith.  Hence the development of RASP, and hence my belief that, in a monolithic application, RASP still has a potentially viable place in your application security environment, assuming that the constraints that RASP brings with it (performance, etc) fit within your model.

But let’s look at the former, microservices case.  In that case, the interactions are actually occurring external to the components of the application, over a network, and using a very standardized, (hopefully) well-documented API (usually REST or GRPC-based).  The functions that RASP performed (instrumentation, observation, control and, if necessary, intervention) can all be inserted in the network spaces between the microservices that comprise your application. They do not need to be compiled into the code itself.  By design, the cloud-native community has introduced a concept called the ‘service mesh’ which can be thought of as a very advanced combination of WAF, load balancer, monitoring point, etc. service that is provided by the fabric, to be consumed by the microservices that compose your applications.  One of the rapidly developing instances of a service mesh is the open source Istio project, originally established by Google and IBM.  Tigera is also a major contributor to this project.

We’ve talked about Istio and its capabilities in the past, but it is certainly possible to implement many (if not all) of the functions commonly found in a RASP in an Istio-based service mesh.  Certainly, not all of those capabilities are packaged up as a “point and click” deployment in Istio today, the capabilities are there, and work is on-going to make Istio easier to provision and consume.

An interesting side-note is that the Istio and Kubernetes communities are working on enabling Istio and its default underlying proxy (Lyft’s project Envoy) as an ingress gateway, or in application security speak, a combination of a WAF, monitoring point, and a load balancer.

So, returning to the question “if you could have only one…?” If I was deploying, or planning on deploying microservice architectures, my answer could very well be “give me a service mesh.”  If that might be your position as well, we’d love to talk to you about Tigera CNX.  If not, I’d love to hear your answer to the “there can be only one” question.