LAST UPDATED August 2, 2021
Last week we had a great webcast and discussion on the topic of securing APIs and microservice architectures. Based on the feedback during the webcast and the many conversations we have with prospects, this is becoming a very hot topic (and source of frustration) for many of you in application security.
This shouldn’t come as a surprise given that these two topics are shifting some of the fundamental assumptions that old-school WAFs have relied on for years. Instead of everything coming in through the front door, applications are increasingly accessed via APIs that can be both Internet-facing, as well as connected on the back-end. Likewise, as applications become more modular and broken into microservices, the old appliance-based model of WAFs is increasingly out of the loop in terms of seeing and enforcing application traffic.
Many of the questions we received in the webinar mirrored questions and challenges we regularly hear in the field when engaging with AppSec teams. So with that in mind, I wanted to quickly run through, and provide answers to, some of those questions.
QUESTION #1:
We are increasingly deploying our apps in Kubernetes. Why would you recommend a sidecar approach instead of simply integrating the WAF as a plugin in my webserver (Nginx, etc)?
This is a good one and one that comes up a lot. First, a quick bit of background. Kubernetes makes it easy to orchestrate the deployment and scaling of containerized applications. And this, in turn, makes it easy to break applications into smaller constituent microservices. This does, however, create a challenge for traditional WAFs that are based on physical or virtual appliance models. In a Kubernetes environment, there is no longer a single monolithic stream of traffic where an appliance can sit and see all the traffic. Instead, the application will have many pods that can spin up or down and microservices that may need to communicate to one another internally.
We recommend building security into the pod so that your WAF is a standard part of a new pod when it is created. This ensures that security can automatically scale and adapt as the application itself changes. However, we also want to make sure that the WAF doesn’t disrupt the application or cause problems. If the WAF is built into the webserver itself, you open up many potential complications. Does updating the rules on the WAF require you to restart the webserver? Likewise, performance and failure scenarios can get complicated quickly. The sidecar approach makes sure that security stays in lockstep with the applications, while still being independent enough to ensure that security does no harm.
QUESTION #2:
Given that we are looking to support new architectures and DevOps, how integrated or independent should security be in relation to the DevOps process?
This is another, very common, and important area of discussion in the industry. From the ThreatX perspective, we want security to benefit from DevOps, while also remaining independent.
For example, the more security and development teams work together, the better. As a case in point, ThreatX can begin training our behavioral models for applications during the development and testing phases before they are rolled live. This enables the WAF to learn even before applications are in production and are up-to-speed as soon as they are deployed.
On the other hand, we don’t want security to introduce friction into the DevOps process or CI/CD pipeline. By building security that aligns with the way applications are deployed, such as in the Kubernetes sidecar example above, we allow security to scale and evolve along with the application. It happens automatically, but both sides retain their independence.
QUESTION #3:
We have countless APIs and sometimes we fail to keep track of all of them. How do we protect APIs if we don’t even know about them?
One of the benefits of deploying security in pods with your services is that security becomes built-in, even as new instances are spun up or rolled out. This means that regardless of the path that a user takes to your application, all roads lead to security. This is a big change for organizations that are used to the physical/virtual appliance model. Instead of constantly trying to track down new apps or new APIs, security rolls out with the application automatically.
QUESTION #4:
How does this product apply to inter-microservice APIs vs. just public APIs?
This is directly related to the question above. But because the WAF can be built-in as a part of a Kubernetes pod, it can easily protect the APIs that connect between microservices. This is a major advantage over traditional models, which more often than not, would not be in a position to even see this inter-service traffic.
QUESTION #5:
If east-west APIs aren’t exposed to the outside world, do I really need to worry about them?
It’s very important to understand the inner workings of an application and be able to see the potential progression of an attack. For example, ThreatX analyzes threats in the context of the kill chain, and this context is incredibly important to understanding the overall risk. Additionally, ThreatX constantly learns the normal behavior of an app. Seeing anomalies in the internal communication of the APIs gives us a great additional model for detecting and confirming threats.
QUESTION #6:
Can you share a bit more about your overall threat ID and protection model? Seems like it’s pretty seamless protecting APIs vs. other vulnerabilities, which is cool!
ThreatX takes a very different approach to detecting threats compared to a traditional WAF. Instead of using signatures or rules, we bring together a blend of machine learning and active, attacker-centric analysis to reliably identify threats. For example, as mentioned above, we constantly analyze the behavior of applications and users. If applications begin behaving unusually or we observe unusual intensity changes, we recognize this as a potential problem and raise the risk score.
However, we don’t want to simply rely on detecting anomalies. Sometimes unusual things happen, and systems that only rely on behavioral anomalies can be prone to false positives. To circumvent this, we leverage a wide range of attacker-facing detection techniques in addition to behavioral anomalies. This includes learning the unique behaviors of attackers, such as their tools and techniques. We then also actively engage with potential threats to test a suspicious visitor and fingerprint them for further analysis. We can track their long-term behavior, evaluate them in terms of how they progress along the kill chain, and even employ active deception of the attacker.
This just scratches the surface of what we do, but the combination of application and attacker focus, paired with passive and active analysis techniques gives ThreatX a truly unique and accurate approach to the detection of threats.
If you have additional questions, please post them in the comments and we will follow up. Learn more about the ThreatX Next-Gen WAF during an upcoming live demo.
