Web Application Security Without Organizational Resistance
As software-defined networks have replaced the monolithic, server-to-server communication paths of networks’ past, web application firewalls (WAFs) have become staples of organizations’ security technology deployments. First-generation WAFs, launched circa 1990 as extensions to traditional network firewalls, relied on the analysis of signatures for anomaly detection. The validity of signatures determined whether traffic was allowed (whitelisted) or denied (blacklisted). This method was problematic, producing many false positives, and cumbersome, requiring system administrators to manually update lists.
Second-generation WAFs automated list building but still used signatures to determine “malicious” from “not” and thus didn’t significantly reduce the number of false positives or burden on system admins. In parallel, the number of critical apps relied upon by organizations was growing. This reality, along with the rise in zero-day attacks, ushered in the third generation of WAFs in the early 2010s. WAF 3.0 looked at traffic patterns and building baselines; it was an improvement over 2.0, but still couldn’t handle the rapid software build-deploy-update cycles becoming the norm thanks to the DevOps movement.
At this time, as enterprise dependence on software grew, cyber criminals saw opportunity. Software offered a new attack surface, and, coupled with increased use of cloud architectures, security teams knew they had to devise methods to protect their applications and data in a different way.
Different security controls required
Companies like Etsy had gone “all in” on DevOps and cloud; their security executives at the time, Zane Lackey, Andrew Peterson, and Nick Galbreath, decided that the available state-of-the-art wasn’t artful enough. They were legacy WAF customers dealing with its limitations: too many false positives; the WAF would break every time an app was updated, adding frustration and friction to DevOps; because legacy WAFs were hardware or virtual appliances designed for on-premises networks, they didn’t operate well in elastic or ephemeral environments like the cloud.
Rather than fight to retrofit existing tech, the trio decided to stand up a team to build in-house tools that could manage the scale and complexity of DevOps while ensuring applications remained protected, whether they were communicating in the cloud, across APIs, or on-premises only. This new capability had to not only look at signatures and traffic patterns, but it had to account for behaviors and attributes of applications so it could function throughout the SDLC. What they started building, the precursor to next-gen WAF/RASP, they eventually spun out to become Signal Sciences.
Etsy was one of the companies pioneering DevOps and cloud and the shift into DevOps made us rethink the entire architecture of the security products we were using. Dealing with apps and APIs was orders of magnitude more complicated than current commercial technology could manage. Things were breaking all the time. There were too many false positives. So we built our own tool.
Ed and I recently spoke with Lackey, who explained why they felt the need to start a company in a space with a long legacy. “Etsy was one of the companies pioneering DevOps and cloud,” he said, “and the shift into DevOps made us rethink the entire architecture of the security products we were using. Dealing with apps and APIs was orders of magnitude more complicated than current commercial technology could manage. Things were breaking all the time. There were too many false positives. So we built our own tool. We were bullish on starting from scratch—at web scale, from the point of view of apps and APIs—to eliminate our own pain.”
Singular focus
A now six-year-old company, Signal Sciences hasn’t strayed from its roots; they are still singularly focused on building the industry’s best WAF and RASP to secure applications and APIs, which Lackey says are “companies’ #1 most important computing asset.” Indeed, apps are how companies interact with customers today, and their use can’t be constrained by the security implications of where the apps are running or how and when they’re updated.
Signal Sciences is deployed as a lightweight agent which integrates into the DevOps toolchain. “It was important to us to not force our technology down developers’ throats,” said Lackey, “because we’d lived that nightmare as practitioners.” As a result, Signal Sciences offers multiple deployment options (including 42+ cloud native and data center platforms) with full feature parity across environments, and the ability to feed data into a singular dashboard for unified management. Further, Signal Sciences is fully integrated with 30+ DevOps and security monitoring tools and platforms, like Jenkins and Jira, so that data can be automatically sent to existing dashboards, removing the pain of disparate console management, and facilitating easy reporting and triage. Conversely, data from a customer’s other security tools can be pushed into the Signal Sciences dashboard for the same effect.
Ubiquitous control across architectures
The (not-so) secret to Signal Sciences’ success is that the same agent is deployed regardless of environment: on web servers, in a reverse proxy, in containers or service mesh, on a load balancer or hosted cloud, and so on. The only thing that changes across deployments is a small module, a few lines of code written in Go[1], a memory safe programming language. The data collected by the module and agent is sent to the Signal Sciences Cloud Engine, an elastic cloud back end which allows for scale and high performance, where metadata is evaluated for context (beyond signatures and behaviors), and policy is applied.
When asked, “What makes Signal Sciences so successful,” Lackey, in his genuinely humble way, responded with, “I don’t know exactly; we built what we needed as practitioners, from the ground up, and to scale.” But that’s not entirely accurate. The team was early to recognize a critical need, that is, threats had moved to layer 7, and that success in an app- and API-centric future world meant building something that was adaptable and extensible. Even though WAFs/RASPs are traditionally security products, the founders foresaw the influence developers would have in the modern organization and designed a tool that could withstand a CI/CD pipeline and software-defined enterprise.
Starting from a practitioner viewpoint, the Signal Sciences team has truly built a security control designed to be used in modern computing environments and across teams. It offers an architecture that allows for easy deployment anywhere, and without interdepartmental arguments. Signal Sciences is always increasing coverage for more vulnerabilities, like account takeover and bots, demonstrating that they’re not satisfied with the status quo. For these reasons, we recommend you give Signal Sciences a call and learn more about their offerings. As Lackey told us, the proof will be in the pudding.
______________________________________________________________________________________
Original blog post published on Tag Cyber
The post Web Application Security Without Organizational Resistance appeared first on Signal Sciences.
*** This is a Security Bloggers Network syndicated blog from Signal Sciences authored by Katie Teitler. Read the original post at: https://www.signalsciences.com/blog/web-application-security-without-organizational-resistance/
