By Jonathan DiVincenzo, Head of Product, Signal Sciences
Application security isn’t a young buck anymore. The Open Web Application Security Project (OWASP) is 15 years old. But while application security is well into its teenage years, vulnerabilities like SQL injection and XSS still dominate the rankings of the OWASP Top Ten. This is concerning. But what’s more concerning is that while attack vectors and techniques are still largely the same, software development models have completely shifted, as with the proliferation of microservices architectures, for example.
One major change in software development is the delivery cadence of an application. Instead of a mainly static application that changes only a handful of times per year, deploys now happen continuously. Further, most software development teams have adopted DevOps and have operational insight (via dashboards and metrics) and operational control (via chatops) without root access.
APIs are everywhere and new architecture patterns like microservices are here to stay. But application security problems still persist because all these services run on HTTP, making them susceptible to existing HTTP vulnerabilities. In DevOps and computing, there are four application security defense needs that organizations cannot do without:
With the rise of Internet Relay Chat (IRC) replacement systems like Slack or Teams, there has been an outcropping in the DevOps movement known as ChatOps. This encourages alerting, system actions and events to live where the development team already is: in chat, rather than in logs.
Application security programs should distribute events back to the developer teams. When under attack, messages should appear in Slack showing that defensive measures were taken, like this:
The goal is to bring the team together and keep security data in front of the people who create and deliver the application or service without getting in the way.
ChatOps even offers simple command-driven feedback, a developer or security practitioner can quickly use a ChatOps bot to query a specific metric and it will retrieve the appropriate data.
- Data Visualization and Dashboards
Web Application Firewalls (WAFs) have largely gone un-visualized for their entire existence — developers who actually wrote the applications don’t have access to their security data. Some of the legacy WAF vendors provide high-level metrics; however, most of their offerings resemble log management software and pre-paid analyst services.
Visualization is an absolute must-have. In the modern era of DevOps, sharing is key. Two basic questions that Zane Lackey, CSO at Signal Sciences often asks are:
- Am I being attacked right now?
- Where are the attacks being successful?
Answering these two questions require visual representations in order to detect outliers and statistically relevant data.
- Business Logic
There are inherent parts of an application that are more important to your business than others.
Do you care if someone attempts XSS on your site? Maybe.
Do you care if the number of failed logins has spiked in the last hour? Probably.
Do you care if those are two events are correlated? Definitely.
Do you care if you are seeing SQL injections and HTTP 500’s spike at the same time? You bet!
When dealing with business logic and attacks specific to the application being defended, it’s critical to be able to correlate disparate data sets. This includes:
- XSS, SQLi, CMDEXE, and other application security attacks
- HTTP errors, Tor exit node traffic, and other anomaly flows
- Account Creations, Successful Logins, and other business flows
- Defense against Bots and Scrapers
Some products specialize in keeping out bots and scrapers. Other products like honeypots specialize in enticing them. Not all bots are HTTP-based, however, most application security defense has some method to deal with bots coming in over HTTP whether that be through:
- Analyzing traffic sources
- Fingerprinting traffic and headers
- Anomalous traffic patterns
Since not all bots are HTTP, a pure application security defense approach won’t cut it. However, most AppSec programs implement a safety valve at the HTTP layer.
While application security is no longer in its infancy, the playing field is constantly changing and attackers are pushing the boundaries of their methods. Pin this list to the fridge as your development team experiments with new architectures — it will save you some serious headaches down the road.
About the Author
Jonathan DiVincenzo, Head of Product at Signal Sciences, the fastest growing web application security company in the world, brings his engineering background together with a passion for taking mere ideas and turning them into products. He has experience working in both large companies and startup environments, where his impact in leadership, engineering and product development leaves its mark. Learn more about Signal Sciences online at www.signalsciences.com or follow us on Twitter at @SignalSciences