Web Application Security
td {
padding-right: 10px;
}
This post is adapted from a presentation at nginx.conf in September 2016. You can view a recording of the presentation on YouTube.
Table of Contents
0:00 Introduction
How many App Sec people do I have in the audience? And you admitted it: 3 of you, OK. How many developers or DevOps or operations people? All right, that’s pretty much the normal ratio of every company we talk to, by the way, just so you know. The security teams are always pretty much beat up.
0:17 Acronym Soup A
So, I’m going to talk a little bit about the differences between all the different technologies that are out there today to help you secure your website or your web app. I’m going to use those terms interchangeably: I always mean web app or larger web application.
But first things first: I want to do a quick kind of survey and see which of these terms resonates with you guys in the audience.
When I do this presentation for security people, they know about half to three-quarters of the terms, of the acronyms that I’m about to put on the screen.
When I do this presentation for DevOps people, it’s a very different type of audience, right, and they have different goals in mind.
So, let’s just start here.
1:00 Acronym Soup WAF
Everybody know what that is? Yeah, all right: Web Application Firewall, right?
1:07 Acronym Soup SAST
How about that one: Software Static Analysis, right? OK, that’s static analysis of source code.
1:17 Acronym Soup DAST
How about that one: Dynamic Analysis, that’s right.
1:23 Acronym Soup IAST
Interactive, Instrumented, right? It’s one of those two depending on which vendor of the week you speak with. But again, testing of your application in an interactive, instrumented way.
1:37 Acronym Soup RASP
How about this one? This is the one that I like the best, but it doesn’t seem to be getting enough traction: this is Runtime Application Self-Protection, right?
1:48 Annual Pedants Conference
Welcome to the annual conference where it really doesn’t matter what all of these things mean, right? We’re getting very pedantic about breaking these things apart and trying to just slice and dice an industry or a market – in our case application security – into a bunch of different verticals that it really doesn’t need to be sliced and diced into, right?
At the end of the day, you just want something very simple, very straightforward, that secures your web application.
2:13 Definition of Terms
To do that, though, we have to spend some time in this minutia, this world of breaking down exactly what the differences between the technologies are, so that you can understand which vendor you need to get them from, who you need to get them from, what features you need them to have, OK?
And we’re starting with basics: Web Application Firewall. This is the one that everyone seemed to know the most, right? An appliance, server plugin, or filter that basically applies a set of rules to an HTTP conversation.This is a Web Application Firewall.
It’s essentially, in a nutshell, looking at inbound and outbound HTTP traffic for specific signatures, usually, and blocking requests that are dangerous.The key here – and this is how I’m defining it – the key here is that this is generally external to the application.
Most Web Application Firewall vendors sell it as an appliance that sits out in front of your web application, OK? All the traffic hits the appliance. The traffic goes through the appliance to your web application, presumably safe and secure.
3:14 Definition of Terms, continued
Runtime Application Self-Protection is a bit of a different beast. And what we’re talking about here, and what the vendors that claim to have RASP technology are doing: they are taking the concept of Application Self-Protection and embedding it into the app itself.
They’re adding context of what the app knows and what the app has access to, to help them make better and more informed security decisions, OK?
So, a security technology that is built or linked into an application, or application runtime environment, provides self-protection. The application is now smart enough to protect itself in real-time, runtime attacks.
3:53 Definition of Terms, continued
And this is what we billed ourselves as today: Next Generation Web Application Firewalls, we being Signal Sciences, the company that I run marketing for: deep security coverage across web applications from multiple points in the application stack.
Right now we’re calling it a Next Generation Web Application Firewall. What that essentially means is: you don’t necessarily just have to put us out in front of the application, we can embed in the application and provide contextual data that some of the RASP vendors can provide to you, but we can also sit out in front and operate in a reverse proxy mode, or you can embed us into the source code itself, right?
And the key here is that we are a holistic web application protection platform.
4:35 Does The Difference Even Matter…
But at the end of the day, does the difference really even matter? Not really, right? These are just marketing terms. These are terms that people like me sit in the coffee shop and make up as we go hoping that you guys say hey, that’s something I need, right?
And at the end of the day, the term doesn’t matter. What matters is that you get the value, the business value that you want out of your security technology.
4:56 What You Really Want From A Solution
So, what is it that you should be wanting?
4:59 What You Really Want From A Solution, continued
You want to enable your teams, your development teams, right, the majority of the people in this room, to move quicker and your security teams to prioritize efforts through shared, actionable real-time data, security data.
Just like you make your decisions, when your application is running, on how to tweak it, make it more performant, make it cleaner, make it better, add new features: all of that is data-driven. Your security controls should be the exact same way.
5:25 What You Really Want From A Solution, continued
And to support a modern architecture, right?
A lot of the traditional application security mechanisms do not work well in a modern architecture. Sitting out in front of the application as an appliance does not work well in modern architecture when I can spin up 1,000 new instances in the cloud.
How do you handle that as a physical appliance? How do you handle that even as virtual instances that have to be put up in front of my scalable environment when I’m going horizontal 1,000, down 100, up 1,000, down 500, OK? It gets very difficult to manage.
5:58 What You Really Want From A Solution, continued
And last but not least, you need a system that provides reliable blocking with low resource overhead, OK? This is key. You need a system that’s smart enough and has the application context and intelligence to not take up a dozen people’s time tuning it, tweaking rules, creating rule packs that you have to upload into that environment every time you push to production.
6:24 Why Does App Sec Have to Change?
So, why does App Sec have to change, right? The primary reason why application security has to change today is based around the developmental models, OK? Developmental models have completely shifted in the last 10 years and application security has not kept up.
6:39 Traditional Application Development
For the Devs in the room: everyone familiar with the waterfall, traditional waterfall development cycle, 6 to 24-month release cycles that take forever and never actually meet requirements because by the time you develop it and build it, your requirements are completely out of date? Everybody’s familiar with this pattern.
6:56 Traditional Application Security
Well, App Sec layered on top of that, right? So, during requirements and design, we had a secure design process. During development, we did code review, peer review, static analysis. During testing and QA, we brought in the red team, that evil red team that would rip your application to shreds and give you a stack of vulnerability reports about this high.
And last but not least, you get into production and your maintenance team has to do bug and vulnerability fixes, right? Well, this is the old way that applications get developed and it’s the old way that application security works.
7:27 Modern Application Development
This is modern App Sec development, OK? And I’m sure you guys in the room probably are all very familiar with agile development, DevOps speed to market, pushing to production 30-plus times a day, CI/CD, right? These are all the terms of modern app development.
It’s very different. It’s now weekly, daily, hourly cycle times, OK? You’re not taking 6-24 months to run your cycle, you’re doing a full cycle every hour or every couple of hours, sometimes as a team of 1, sometimes a team of 2, or 3 or 5, but you’re doing it quickly. And the reason for this is so that you can deliver on those requirements before they change underneath you, OK?
That’s the primary reason: delivering features and value to your customer as quickly as possible to meet their needs.
So, how do we, as application security professionals – where I’ve spent my 20, 20-plus years’ career – where do we fit into this? We don’t have 6 to 24-month cycles anymore to do secure code review, peer review, design review, pen-test your app. Each of these things takes 2 weeks, 4 weeks, a month. We can’t possibly fit into this model.
8:38 Modern Application Security
What ends up happening is: you end up having checkpoints throughout this process. You embed security into the agile development process, OK? And to do that, we have to upend how we do security today.
We have to completely change the overall secure process and bring it from a 6-month to 24-month security process down to a process that can run hourly. It’s a very daunting task for us as application security people.
So, security has to be embedded into each individual step. We have to educate development, we have to educate operations people to be self-sufficient when it comes to creating secure applications.
This is a long process for us as security people. We’re going to have to spend many, many hours helping folks get up to speed on how to properly secure their applications.
One of the key components here is unit tests. You have to create security unit tests just like any other unit tests that you create for your system. Security is absolutely just another feature that needs to be built into every single feature that you create.
And at the end of the day, security people cannot block the development of the product.
If, at any time, the security person gets in front of development and feature release of the product, they’re pretty much guaranteed to fail as a security person.
The security program is going to die right around them, die on the vine, because the development people cannot be stopped. They have to be able to get their stuff out the door as quickly as possible.
9:59 Why Does App Sec Have to Change?, continued
What’s the second reason that App Sec has to change? The second primary shift that we’ve seen in the last 5-7 years is that the architectural models of applications have completely changed.
10:13 Operational Security System
Again, remember: security hasn’t changed much, OK? Operational systems are basically 3 things: you take data in – in our case, developmental data, security data, activity data – you have some kind of decision engine that analyzes this data, and out the other side pops accurate, timely, actionable security recommendations on things to fix, OK?
This is what a security system is.
10:39 Traditional Web Applications
But how does that work in traditional web applications?
Well, in traditional web applications, the data that we collect – there’s a natural choke point for data collection, OK? And that’s the WAF. And this is why everybody knows what WAF is.
For the last 10 years, there was a natural choke point when we built on metal in our data centers, in waterfall models, OK? We had a natural choke point where we could collect the security data that we needed, as security people, to make those educated decisions, OK?
And it was right at the front your data center, at the front of your load balancer, at the front of that stack, OK?
Essentially, what the WAF did was: it looked at inbound network packets for attacks, analyzed those, and discovered and blocked attacks in real time as best it could.
11:27 Modern Web Applications
But in modern web applications, we don’t have a single single choke point, a single point of failure. That concept is gone.
We now have kind of a multi-phased approach because we have web server instances, right? We no longer have a single web server, maybe 2 or 3 behind a single load balancer, we now have 1,000, 2,000, 5,000 instances that we spin up, spin down on demand in different containers and different AWS instances, wherever you’re putting it.
And behind that, those applications are actually run on a huge number of instances that are providing an API. Microservices, right? As soon as we started to shift to microservices, we completely upended our individual choke point because now our users can actually create their own code and go directly to that API if they want to.
So, how do we go ahead and secure the modern web application?
12:21 Modern Web Applications, continued
The key is not to rely on a single choke point, OK? And the key is to have modern web applications that you can inject your data collection – remember: security controls are simply data collection analysis actionable output, OK, where you can collect your data, your security data at multiple points, OK?
It’s no longer sufficient to just sit out in front of your application. You need to have collection potentially at the web server instance itself, in the source code itself, in the runtime interpreter if possible, OK, using all of these points to get as much security data as you can back into that decision engine.
12:59 Security Decision Engine Differences
So, we talked about pulling data in, right? It’s insufficient to have a single choke point anymore. You have to pull in data from multiple sources, and you can even go so far as to say that we can pull in data from development systems.
Take, for example, if you were able to take in your release moments of release and map that onto security flaws, or map that onto 500 errors, you could get a lot of information that can educate your developers on security, right? It’s not even sufficient to just look at security inbound data.
The post Web Application Security appeared first on NGINX.
Source: Web Application Security
Leave a Reply