中文
This post is adapted from a presentation delivered at nginx.conf 2016 by Tyler Shields of Signal Sciences. You can view a recording of the presentation on the NGINX, Inc. channel on YouTube.
Table of Contents
0:00 Introduction
Tyler Shields: How many App Sec people do I have in the audience? And you admitted it! Three of you, OK. How many developers or DevOps or operations people? … 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 and acronyms that I’m about to put on the screen.
When I do this presentation for Dev and Ops 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, SAST, DAST, IAST, RASP
Everybody know what that is? Web application firewall, right?
How about that one: [Static Application Security Testing]. OK, that’s static analysis of source code.
How about that one: [Dynamic Application Security Testing]. Dynamic Analysis, that’s right.
[Interactive Application Security Testing]. Interactive, Instrumented, right? It’s one of those two depending on which vendor of the week you speak with. It means testing your application in an interactive, instrumented way.
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.
1:48 Annual Pedants Conference
Welcome to the annual conference where it really doesn’t matter what all of these things mean. 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: WAF
To do that, though, we have to spend some time in these minutiae – 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, and so on.
And we’re starting with basics: web application firewall. This is the one that everyone seemed to know the most, right? An appliance, server plug‑in, or filter that basically applies a set of rules to an HTTP conversation. This is a web application firewall.
It’s essentially 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. 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: RASP
Runtime Application Self‑Protection is a bit of a different beast. What we’re talking about here, and what the vendors that claim to have RASP technology are doing, is taking the concept of Application Self‑Protection and embedding it in 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.
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: NGWAF
And this is what we at Signal Sciences, where I run Marketing, bill ourselves as today: Next Generation Web Application Firewalls [providing] 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. That essentially means 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.
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.
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?
You want to enable your teams, your development teams (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.
[The second thing you want from a solution is] to support a modern architecture.
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. It gets very difficult to manage.
And last but not least, you need a system that provides reliable blocking with low resource overhead. 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? The primary reason why application security has to change today is based around the developmental models. Developmental models have completely shifted in the last 10 years and application security has not kept up.
6:39 Traditional Application Development
For the developers in the room: everyone familiar with the 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 is layered on top of that. 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. 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. 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+ times a day, [and] CI/CD. These are all the terms of modern app development.
It’s very different. Cycle times are now weekly, daily, hourly. 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 one, sometimes a team of two, or three or five, 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 career of 20+ years – 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 the app. Each of these things takes two weeks, four 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. 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 and 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? – Part 2
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. Operational systems basically do three things: take data in (in our case, developmental data, security data, activity data), some kind of decision engine analyzes this data, and out the other side pops accurate, timely, actionable security recommendations on things to fix.
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 … there’s a natural choke point for data collection: 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. We had a natural choke point where we could collect the security data that we needed, as security people, to make those educated decisions.
And it was right at the front of your data center, at the front of your load balancer, at the front of that stack.
Essentially, what the WAF did was look at inbound network packets for attacks, analyze those, and discover and block 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 multiphased approach because we have web server instances, right? We no longer have a single web server, maybe two or three 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. And the key is to have modern web applications where you can inject your data collector at multiple points, remembering that security controls are simply data collection, analysis, and actionable output.
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. Use 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. 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 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. It’s not even sufficient to just look at security inbound data.
