Last updated at Tue, 14 May 2019 19:34:02 GMT

We at tCell are excited to announce the availability of tCell’s Web Server Agent (WSA). The WSA joins our stable of agents for JavaScript, Java, Ruby, Python, Node.js, and .Net, extending our monitoring and protection capabilities to common web servers (NGINX is available now, and we’re accepting requests to join the tech preview for Apache and IIS.)

But first, why this move? For that, I’ll need to take you back a few years, when people were All About that Bass and yelling “Timber”.

In the Beginning

When Michael Feiertag and I started tCell together in late 2014, we had a driving vision: we believed that the best way to defend applications was from inside the app itself. In the era of DevOps, the emergence of microservices, and the rapid adoption to the cloud, we saw very clearly that the weaknesses of WAFs–a technology that often came with the curse of high-maintenance, giving less than satisfactory results in traditional deployments–would only grow more pronounced with time. The fundamental concept around WAFs was wrong from the start. When we talk about apps, that’s entirely software. Even in networks, the industry has redefined the relationship between software and hardware (hint: it’s all about software). So if you want to monitor and defend applications, that, too, requires a software-centric approach. Further, as the name implies, a “firewall” heavily emphasizes perimeter defense. As any modern full-stack developer will tell you, perimeters are not easy to define when half the application is running on the user’s browser.

The RASP

We weren’t the first to attempt in-app instrumentation. Runtime Application Self-Protection (RASP) was coined by Gartner in 2012 (presumably in between calling Carly…maybe, and setting fire to the rain); when RASP came out, the technology had already existed for several years. Here again, prior concepts limited the potential for a new direction. The approaches in the past were heavily server-centric and inspired by code analysis.  The result was that RASP had an early reputation of high overhead impacts on production services, a non-starter even for security-conscious companies.

We studied prior approaches, and designed a RASP from the ground up that is low overhead and natural to deploy for the modern stack–whether that’s for on-prem deployments, cloud, or container. Further, we extended what RASPs would traditionally focus on. From our first premise, we arrived at a corollary: in order to defend the application, we need to do so not only on the server-side. This was the inspiration behind our first minimal viable product, which dealt with cross-site scripting (XSS). XSS happens on the browser, so why was everyone focusing on the server? With that in mind, we built a Content Security Policy (CSP) building tool which enables security, operations, or development to quickly create a CSP based on runtime information from the browsers themselves. (CSP, in case you don’t know, is the industry standard for XSS prevention. To learn more, read this excellent introduction by Mike West (https://www.html5rocks.com/en/tutorials/security/content-security-policy/.) Further, since CSPs have some limitations around inline scripts, we added monitoring/analysis of inline scripts via our JS Agent. We were doing both what WAFs couldn’t do, and what prior RASP implementations hadn’t thought of doing.  AppSec without borders!

Our approach to RASP was also distinctly different. Taking cues from my experience at Splunk, and from the adoption of new gen APM tools such as New Relic and AppDynamics, we designed the agents to be lightweight collectors of telemetry and enforcers of policy, with the cloud-based analytics backend providing the computing muscle for capabilities impossible with a pure in-app implementation.

From this foothold, we’ve been able to expand to cover many use cases of customers that adopted WAF, but in a way that fits with modern and potentially heterogeneous deployment infrastructures. We’ve added integrations such as webhooks, Slack, PagerDuty, and more, enabling seamless integration with the DevOps toolchain, and contributing to the industry move to DevSecOps. Further, we improved on the RASP concept to provide a performant, robust agent that can stop zero-day attacks from within the application on multiple tiers.

WSA Today

Fast forward to today, when we’re moving anything but despacito (slowly).

The natural step, after covering applications’ browser-side and server-side vulnerabilities, is what’s in between. Many of our customers and prospects currently front-end their application servers with NGINX, Apache, and IIS. Further, behind those servers we often find legacy apps, which won’t be upgraded anytime soon. It became clear to us that the best way to help people in these situations was to extend tCell to this tier of the application.

With the introduction of the WSA, customers now have the following benefits:

  • Single-Page Applications – Not all requests are served from application servers. Especially for single-page applications, the static content can be hosted on the web tier. tCell can then cover monitoring and defense of these levels of the application.
  • Legacy Applications – Not all applications behind the web tier require RASP, yet there’s still high value in providing web-tier level protection, given the lack of maintenance for some legacy applications (no upgrading to the latest patches, etc.)
  • Cloud Transformation – For companies transferring their business to the cloud, traditional WAFs are quickly are eliminated from an architectural standpoint. WSA supplies the same protections, but in a way that fits with cloud and container infrastructures.
  • RASP Users – For RASP users, this provides an additional layer of defense. Especially for companies that have a plethora of apps, or have moved to microservices, the additional layer opens up new potential for our analytics to identify and stop attacks.

Forward

It’s an exciting time for app security as an industry. Formerly a sleepy segment where WAFs were the state of the art, the industry now thrums with a newfound excitement for the possible, thanks to new approaches like tCell’s. The last decade has seen a dramatic transformation of how web applications are built and deployed. This has shifted the threats, and much of the industry remains behind the curve on learning about those threats, let alone effectively addressing them. The release of the WSA is one more step down the road of bringing runtime monitoring and defense to a wider number of companies and providing defensive capabilities that never existed before.