For twenty years now, the web application firewall (WAF) has been our first line of layer 7 defense against cyberattacks on our Internet-facing applications. While far from perfect, the WAF has undoubtedly protected many insecure and legacy applications from getting owned despite their loose security postures and deprecated third-party components. But in today’s fast-changing world with never-ending software supply chain security vulnerabilities, solely relying on your WAF and its team of support engineers to properly catch every CVE relevant to your application is a strategy for failure. Tactically speaking, it is simply not realistic.
Supply chain attacks on open source software grew 650% in 2021. Gartner predicts that these software supply chain attacks will continue to double each year until 2025, impacting nearly half of all organizations globally. What does this tell us? That our collective defenses are not cutting it, and our adversaries are still ramping up to exploit these vulnerabilities.
While the best defense against software supply chain attacks is solid DevSecOps processes like software composition analysis (SCA) integrated tightly into your software development lifecycle (SDLC), what about protecting your purchased COTS applications? What do you do when you can’t upgrade vulnerable software libraries directly? Sure, you can complain to your vendor, but that won’t protect your application from its nasty new CVE in the meantime.
Speaking of vicious vulnerability windows, did you know that within 24 hours of the Log4j CVE more than 200k attacks were launched, and that grew to 1.2M in a week? Patching is not a realistic solution for such short timeframes, but there is now a solution available to break the kill chain on these relentless software supply chain attacks: Java Runtime Protection.
Third-party software risk is difficult to manage as updating libraries or applying patches can break things without adding any functional value while consuming scarce developer/IT resources. MergeBase, a software supply chain security company with a leading SCA and SBOM platform, has released a patented supply chain “superpower” called SCA Runtime Protection. It protects applications before (or without) patching by blocking vulnerable Java libraries or specific functions from exploitation, buying time to calmly patch and remediate on your own schedule.
Runtime Protection can also be used to identify what third-party software dependencies are actually used in an enterprise application and then proactively block all unused Java components and methods to harden applications against known exploits or CVEs as well as unknown or future zero-day vulnerabilities. This can reduce the attack surface by up to 99%.
For software libraries or functions that are actively used by the application yet vulnerable to exploitation, Runtime Monitoring can be integrated with a WAF to send it an alert when that vulnerable function is used, so the WAF can keep an eye out for suspicious behavior and terminate the session if required. By providing real-time threat intelligence automatically to your WAF, Runtime Protection can highlight a potential attack before it becomes a data breach, empowering the WAF and its support team to take corrective action in time to stop an attack.
Learn more about WAF and Java Runtime Protection
Watch this mini webinar about WAF and Runtime Protection. Hosted by Jim Manico, appsec guru and global OWASP leader, along with Julius Musseau and Shannon James Smith, who will explain how WAF differs from Java Runtime Protection (JRP):
- Do you need both? What’s best?
- While different, there is some overlap, yet ideally, you would have both.
- Runtime Protection is internal, while WAF is external. Runtime is precise, while WAF is fuzzy.
- WAF is more expensive to scale and time-consuming to maintain.
If you want to learn more about Runtime Protection (and WAFs), you can download our white paper for a deeper understanding. Or book a demo with us and learn more about Runtime Protection.
WAF + Java Runtime Protection = Massive Attack Surface Reduction(Transcription)
Shannon James Smith: Good morning everybody.
Jim Manicode: Morning.
Shannon James Smith: We’re almost at the top of the hour here for our official start time, and we’re going to talk today about WAFs. They’ve been around for 20 years. It’s amazing. I did a search on LinkedIn, and there’s like, I don’t know, 10, 20,000 people that have WAF in their title, or it’s like it’s proliferated. I mean, there are a lot of people using WAF than ever.
That doesn’t change the inherent downsides of WAF, but there they are useful for certain things, and there haven’t been a lot of options in this area. And so, I figured we’d talk about how runtime protection differs and also can be used in conjunction with WAFs.
So, all right, without any further ado, thank you guys for all attending today. I’m going to just go through a few slides, and then we’ll kind of get the conversation jump-started here.
Julius Musseau: And Happy Valentine’s Day, Everyone.
Shannon James Smith: Yeah, Happy Valentine’s Day,
Jim Manicode: I wore my Valentine’s Day shirt for all of you today.
Julius Musseau: Have you got Valentine’s Day earrings on as well, Jim?
Jim Manicode: No, no, I just wear these every day. These are my black earrings. I don’t have Valentine’s Day earrings. Just a Valentine’s Day shirt, Julius. That’s what, so you,
Julius Musseau: Okay.
Jim Manicode: You got the rose.
Shannon James Smith: Okay. Okay. All right. All right. Well, thank you, Jim, for joining us today. Jim’s our special guest. Jim is the CEO at Manicode. They do security training, and he’s very busy, but if you book in advance, you can get a session with him.
And then, we have both our co-founders on the call today, Oscar, the CEO, and Julius, our CTO. And we’re also joined by Al, one of our new partners. And thank you, Jan, for joining us as well. And, of course, Camila, without her, this wouldn’t be possible. She runs marketing for us.
Jim Manicode: Thank you.
Shannon James Smith: Thank you, guys, for joining us today. We’re going to talk about web application firewalls and runtime protection, how they’re different, and how they can work together. So here we go. Just current. For anybody that hasn’t seen this, I’m just going to take us through a couple of slides to set the stage.
And the number one thing I want to say is, according to IBM’s breach report for multiple years now in a row, the number one attack vector for data breaches is still and probably will be, for some time, the application layer.
Nearly 50% of data breaches start at the application layer. And we haven’t seen any change in that in recent years, except maybe probably more attacks start there. And then this is, of course, exacerbated by the rise of software supply chain attacks, which really took off as we approached 2020 and then really took off after that with a huge increase of 650% in 2001.
And Gartner predicts that it will continue to double for many years to come. And most companies know they’re vulnerable to these attacks and are trying to figure out what to do. A lot of this comes about because of the fact that open source software and public repositories on GitHub were below 50,000 10 to 12 years ago, and now they’re well over probably 30 million by now. So this is a complete sea change, and basically, problems that we knew about back then are now being exponentially shared across the world.
Jim Manicode: Shannon, let me add something really brief. Go back to the beginning of the Java era, which is one of the first big languages driving the web, right? Java back in the late 90s, even then, from the Apache Foundation, we were using hundreds of third-party libraries in the late 90s. So this problem started honestly in about 1997, 1998,
Shannon James Smith: Sure.
Jim Manicode: When the proliferation of third-party libraries began to grow exponentially. And so this really goes way back, 20.
Shannon James Smith: Yeah. And back then, as we talked about last session, the kind of standard practice was, hey, include all the libraries. You never know if you might need to make a call in one.
Jim Manicode: Oh, Shannon, it was like if there was a function you could write yourself, don’t do it. Use a library. So a common Java project in the late 90s is literally 100 or more libraries for nonsense reasons, Shannon.
Shannon James Smith: Yeah. And no one was thinking of attacks surface back then.
Jim Manicode: No.
Shannon James Smith: And most of the attacks were coming at the network layer. But today, Java has grown up and has more critical vulnerabilities than all other languages combined, or at least the ones that we all know and love and work with every day. And as a result, the majority of huge supply chain hacks like the Equifax thing from the Apache Stress Library happen. And a company can lose $5 billion in market cap in one day and not recover that as Equifax really hasn’t over the years.
Basically, if you’re still unclear about what we’re talking about when people build a business application or any application really; usually 10 to 20% of that application is the custom original code they’re writing. And the other 80 to 90% are these open source libraries that people are pulling in.
So they don’t have to reinvent the wheel. The problem is they pay a lot of attention to the 10% that they wrote. And traditionally, they haven’t really paid much attention to all these software components that are pulled in, many of which are Java. And when these things become vulnerable at any day or night, then all of a sudden, the whole application is vulnerable to those exploits.
In the past, before runtime protection was around, really there were not a lot of good defenses other than just to continue making your SDLC more secure and building more secure applications, and continuing to drive secure code practices, which is, of course, what Jim teaches, and the whole industry has gathered around in the last 10 or 20 years.
But beyond that, for IT and for security, there’s this thing called the web application firewall. I remember doing a partnership in 2005 with our security company in F5 because, basically, this was a new concept back then, and you had your normal firewall nowadays.
You got your DDoS, your cloud flare, or whatever; you got your firewall, you got maybe your IDS or your IPS intrusion detection systems, and you got your load balancing. And then the last line of defense before someone gets to your application is that web application firewall.
And so that’s kind of where it fits in. And as you see, over the last few years, WAFs haven’t gone away despite the fact that they’re not easy to use or super effective. In fact, every cloud service has one, and Akamai offers one to everyone. You can see Imperva here has a gateway, a box basically, as well as their cloud version.
So WAFs aren’t going away; they’re just getting virtualized and being put in the cloud now. That helps them scale faster, I guess. And there are definitely some advantages of being in the cloud, and there are what they call next-generation WAFs now that are supposed to be smarter and less likely to take your production down.
So this is still a big industry, and there are tens of thousands of people out there that are skilled at babysitting these things. And the basic idea is the WAF is supposed to stop the bad guys and the bots, and the spammers from getting to your app. And really, just let the people that are supposed to get in there.
That’s the idea. Right. It looks at your incoming traffic, and it reports on abnormal payloads and usages. If that suspicious activity looks really bad, it can be blocked, whether manually or automatically. And please correct me if I’m off base here, Jim; I’m relying on you to keep me honest.
Jim Manicode:
Shannon, I’ll give you my opinion on WAFs. Are you ready? WAFs are for wimps. WAFs are for wimps, Shannon. Maybe they get some traffic introspection. Maybe you can block a few categories of easy, easy types of problems. I’m quoting Jim Roth from 15 years ago. Wafts are for wimps. Fix your damn code, Shannon.
Shannon James Smith:
Yeah.
Jim Manicode:
Fix your damn code or find more comprehensive solutions because WAFs inspect HTTP traffic fire off a rule system, and applications are way more sophisticated than just HTTP traffic introspection. So,
Shannon James Smith:
Yeah.
Jim Manicode:
I’ve been rallying against it for years. I like some of the next-generation stuff, but again, they have limited use in our industry, and you know all this, Shannon, you know all this.
Shannon James Smith:
Yeah. No, no, 100% right. I mean, I’ve been, I mean WAFs, that’s why there are tens of thousands of people that have WAF in their title out there is because of the fact that these things take a lot of maintenance and a lot of handholding if they’re going to work and add any value and be effective at all without.
And the problem is that if you put them on automatic and they block the IP if it’s a false positive now, you just block production. Right. You just turned off your business to the world. And that trying to separate known traffic from good traffic, it’s hard. Right.
It uses signatures; it looks for things like cross-site scripting and injections. It looks for a lot of common attacks, which is great. It’s great to have something out there looking for this stuff, but it’s not very discreet. Right.
Jim Manicode:
No.
Shannon James Smith:
It’s fuzzy logic. And to turn it on auto and allow it to truly block production because it thinks something’s bad without any kind of confirmation,
Jim Manicode:
Good luck with that.
Shannon James Smith:
It is really dangerous. Right. And which is why most people that buy it in production just sit there like you, what do you call it? Testing mode or listening mode.
Jim Manicode:
Yeah, yeah, non-blocking mode. And I see one of two things. People either put their WAFs in a non-blocking mode, and it becomes basically an IDS. At that point, it’s just intrusion detection, and you’re getting alerts that you may or may not pay attention to.
The other thing I’ve seen people do in the WAF world, the web application firewall world for web applications, is they’ll reduce the rule set. They’ll look at the rules that are more aggressive and that fire more frequently and could block production, and they’ll just drop a lot of those rules, still be in production with a highly reduced and less effective rule set. And so all these paths are mammoth expenses. It takes people to help maintain them or a service to help maintain them, and they provide a minimal defense. There you go, Shannon.
Shannon James Smith: Yeah.
Jim Manicode: This is not what we want to depend on.
Shannon James Smith: Yeah.
Julius Musseau: We have a question in the Q&A.
Shannon James Smith: Okay, great.
Julius Musseau: I’m not familiar with that acronym, especially with the two A’s in the middle.
Shannon James Smith: It’s a web application, maybe API or something. Can someone,
Jim Manicode: Which one?
Julius Musseau: How do you see WAAP?
Shannon James Smith: Yeah.
Julius Musseau: Yeah.
Shannon James Smith: Do you know what WAAP is? I closed my browser down so I wouldn’t have any performance problems. So it’s not easy to be able to look it up.
Jim Manicode: I’m looking it up right now.
Shannon James Smith: Get a, yeah, someone can look it up. Yeah, we’ll get that answered. The trick here, though, and this is what I wanted to explore with you guys today, is I think WAFs aren’t going away is the bottom line. I mean, despite all the stuff that you said, Jim, which I basically had agreed with now and agreed upon within 2005, when I first started working with WAFs, I knew tuning them was always going to be a problem.
And the bottom line is if we can get runtime protection if we have a vulnerable method that cannot be blocked by runtime protection inside the application because it’s actually used occasionally, maybe once a week or once a quarter or once a month by the app, then you can’t block it.
But when you can turn runtime monitoring on and watch it closely, and then if somebody accesses that, you can send that alert to the WAF saying, Hey, keep a close eye on this IP and this session. And if you start seeing things like exfiltration of data or other behaviors that are suspicious, block it. Right.
So now the WAF is operating on the fact that it’s got intelligence from the runtime protection system that says somebody’s access to a vulnerable method. This Log4j lookup it’s only used usually once a month by this app. If you think this is suspicious, block it. I mean, does that sound like a realistic integration there, Julius? I mean, what do you guys think?
Julius Musseau: Absolutely. Yeah, go ahead, Jim.
Jim Manicode: No function level, introspection intelligence to understand how my application’s running at the core of the app runtime inside the virtual machine and using that information to inform a firewall that is brilliant. And there’s a lot of teams trying to work on that.
And it is, it’s like the integration between IAS, not IAS, but all the runtime defense and firewall defense by informing each other. This is hard work to build products like this, but I think it is a huge boon for the future of defense. Absolutely.
Shannon James Smith: Yeah.
Julius Musseau: I look at it,
Shannon James Smith: Go ahead.
Julius Musseau: Oh, sure. I kind of look at it from a purely theoretical point of view. Right. So this HTTP traffic that comes in, this little piece of HTTP payload comes in. Right. So the problem there is HTTP can apply to anything, right?
Shannon James Smith: Yeah.
Julius Musseau: HTTP has kind of become a universal protocol, whereas on the runtime side, oh, this library that’s never been even loaded before, no code has ever executed through this library before, has suddenly been activated. Oh, this library’s suddenly firing up and doing stuff, and it’s never done that before. Right.
It’s such a different way of looking at things like versus, oh, I have an HTTP payload and way at the front. So I’m going to determine if it’s a good payload or a bad payload versus, oh, well, this is an actual piece of the libraries of the code that we’re suddenly looking at.
We have so much more context, such a deeper, richer context to evaluate goodness or badness when you actually have the actual libraries, and you have the profile over time of which libraries tend to be used. And we also have CBDs, which vulnerabilities typically are affiliated with the libraries. It’s just a much richer context with the runtime.
Jim Manicode: Another interesting note, I think, is that having that visibility into what’s running inside of the application and then passing that message out is. I think that is number one that is so fundamental because of the way applications work today.
There is so much interaction between services that we’re not seeing out at the HTTP level in terms of looking at how the app works. I talked to an app that app talks to a service, which talks to a service, which talks to a service. And now I have all this internal communication that I don’t have visibility in looking at external HTTP.
The point I’m trying to make, Shannon is that HTTP introspection when my app was one web server and one database, which was the norm back in the late 90s, 20 years ago when this text first started coming up; looking at HTTP was not unreasonable. But that’s not how apps work today.
Shannon James Smith: Yeah. No, web services are like seven layers deep.
Jim Manicode: Exactly.
Shannon James Smith: Listen to this. These are the things that are popping into my head.
Jim Manicode: Shannon, real quick. I got the WAAP; when you want me to WAAP you, WAAP. I got the WAAP story when you’re ready, Shannon.
Shannon James Smith: Okay. And Oscar answered the question. So it does have to do with APIs, which is what I was thinking. So it’s a specialized service for APIs. So we’ve already talked about, we turn runtime monitoring on for a method that now has a CVE on and is vulnerable; someone accesses that. We can send that as an alert to the WAF to start looking closely at that session and maybe block it if anything suspicious happens. That’s one scenario I think we all agree on.
Another scenario, which I think is interesting, is how about the methods that we block, right? We go through an application, we do monitoring for weeks or months, and then we block every Java method in the application that’s not needed by that application.
Block all the libraries that aren’t loaded or are not being used, block all that attack surface, and then share at least that information of any of the stuff that was blocked that’s not just blocking for a zero-day purpose, but, say it’s we’re blocking it because there’s an actual CVE on it, right, which means the attackers out there know about this, then feed that information into the WAF saying these are CVEs that we’re now blocking for, that can’t be executed. But if somebody comes in trying to execute these, we know it’s an attack.
Now we have a true positive, right, where we know if somebody’s coming to hit this look-up method in Log4j that we’ve blocked, it’s an attack. So number one, they can’t execute it anyways, but they might try to look for something else. And that’s definitely not real use, right? That’s a hacker. That’s an attacker.
Now we can give intelligence back to the WAF. So if somebody’s attacking something we’ve already blocked and we know it’s bad, the only reason they would be executing on that is that they’re bad too. Right. So I mean, does that seem reasonable to give that information back to a WAF?
Jim Manicode:
It’s challenging in that the way that I call a library at the Java function level and the way that I call an application at the HTTP level differs. But the good thing is I could see that the initial HTTP hit, and I see that endpoint being hit, and I see that internally that that hit called an insecure library. I can immediately then block that feature instantly so no one else can hit it. I would say there are dozens of ways we could build that integration. It is absolutely, it’s a challenge, but it’s absolutely possible.
Shannon James Smith:
Yeah. And I think with these next-generation firewalls, I mean, we could take advantage of some of the APIs that they offer and start to really bring runtime protection closer to these external protection systems, giving them the intelligence they wouldn’t otherwise have. The other thing runtime protection’s going to do is by using it and locking down 99% of your attack surface that’s not needed by the application. Right. Now you’ve got a 1% attack surface.
So the WAF can really focus in on the one area, the areas that you know that didn’t block, right, that could still be attacked potentially. And now, I mean, it’s just like if you’re a guard and you have a 100 doors, you have to watch. Someone might slip through one when you’re on the far one on this side or that side, right, but if you only got one door to watch because all the other ones have been locked and bolted, you’re going to be able to focus your attention better and spend more processing on anything that might try to come through that door.
Jim Manicode:
I think that’s fantastic. And how about this, Shannon? This is going to be a buzz-worthy quote. Are you ready? Are you ready? This is for marketing. I’m getting out my marketing muscles for you. Shannon, are you ready?
Shannon James Smith: All right. All right. Thanks, Jim.
Jim Manicode:
You’re going to get visibility into your use of your supply chain at the individual function level during runtime. And not a lot of people can say that right now because we have this supply chain, we have all these libraries and components we’re using; it’s a bit mysterious. People say, oh, just do an SBOM. Yeah, whatever, SBOM. I’ll give you an SBOM. So I really don’t understand in detail what I’m really using, right?
Shannon James Smith: Yeah.
Jim Manicode:
I get point-in-time SBOMs. Everyone’s happy. It’s really not that helpful. But what is helpful is understanding in runtime what supply chain I am actually using so I can understand how to make defensive choices. That really interests me when I’m analyzing an application a lot more than some SBOM does.
Shannon James Smith:
Yeah, and it’s also interesting once you block all this potentially bad stuff that you didn’t need anyways; it’s just extra weight. That’s also going to focus on that. I mean, when you’re not, it’s just, it’s going to focus everybody’s attention on the stuff that matters, right? And it’s going to block anything that doesn’t matter outside and really allow the application to be more performant at the end of the day.
Julius Musseau: Let’s open this up, this discussion to everyone.
Shannon James Smith:
Yeah. So if anybody, all the guests here I’ve enabled. So if anybody has questions, you can chat with them, or you can unmute yourself and ask them. We got 10 minutes here for Q&A. It could be on WAFs, it could be on runtime, and it could be on whatever software supply chain issues or questions you might have.
Julius Musseau: My question,
Shannon James Smith: Go ahead.
Julius Musseau: In case unless anyone else has a question, do you think WAFs will go away? How about, is anyone here ready to turn off the WAF?
Shannon James Smith: No, you can’t. They’re not going away. They’re just getting easier to turn on and off, and they’re virtualized, right? And every cloud service now has one.
Jim Manicode:
I’ll tell you this; I think web application firewalls as a standalone category will go away. They’ll migrate to WAAPS, and then WAAPS will migrate into traditional firewalls, and it’ll probably take 10 years or 20 years. But my guess is that these technologies, just like previously specialized firewalls, will eventually roll as one feature in your standard enterprise firewall. That’s my guess. It’s not going to go away.
Shannon James Smith: Yeah. Yeah. I agree with that 100%. I mean, what’s the next-generation firewall,
Jim Manicode: I didn’t hear that. What was that? I didn’t hear that. What was that, Shannon? Can you say a little louder? What?
Shannon James Smith: I agree with that 100%.
Jim Manicode: Okay. Thanks. Want to make sure I got it.
Shannon James Smith:
Yeah, absolutely. I mean, next-generation firewalls, they’re going to look at more than just one layer. They’re looking at application firewall as your layer seven defense. Right. But,
Jim Manicode: Exactly.
Shannon James Smith:
At the end of the day, a firewall could look at many layers, right, and have many different layers of logic there and connect at different points in the stack.
Jim Manicode: I’m with you, Shannon.
Shannon James Smith: All right. Let’s see. Any open questions here? Not yet. Okay. So,
Jim Manicode: Sorry.
Shannon James Smith: That’s all right. It’s all right.
Jim Manicode: I’m in my Valentine’s Day cabin keeping the fire going because I’m in a webinar on Valentine’s Day for you, Shannon. That’s how much I love on-time protection of the supply chain.
Julius Musseau: Yeah. Yeah.
Shannon James Smith: Okay.
Julius Musseau: Does anybody remember the ages before firewalls? Anyone? I guess my kids don’t. My kids will never experience life without a firewall, but I certainly, Ooh, do I,
Shannon James Smith:
Yeah, I remember launching my first servers. We didn’t have firewalls. And then I remember all of a sudden one day in the early 2000s at a data center, one night at two or three in the morning, and all excited because we just powered everything down and powered it all up, and it’s all working. And we go out for a late-night cup of coffee or something and come back at four in the morning an hour, hour and a half later, and the whole server owned.
I don’t know what happened. It was just on the internet for an hour. And we hadn’t run every patch yet, and it’s owned. It was real quick, from like 98 to 2002, that four-year period, it went from, you could leave a server for days or weeks on some random IP, and you were fine. And then three or four years later, you couldn’t leave it there for a few minutes without it getting known if it wasn’t patched.
Jim Manicode:
Shannon, I thought you were going to say back in my day we had no firewalls, and we would slag our own core memory in the backyard for our RAM. I was waiting for that one.
Julius Musseau:
I guess I remember it was in 2000. Yeah. And I was just setting up my first Windows network in my home network. I’d never had a home network before and shared files between the two computers, and then my printers started printing weird things like pictures of penises. And I was, why is my printer doing that?
Jim Manicode:
American audience may not need to hear that, but anyways, I know you Canadians love it, though. But yeah, it was always fun to see open Windows networks, and one of my neighbors continually kept stealing vegetables out of my garden, and I’m like, really, dude, really? You’re going to hop over the fence and grab lettuce?
Oh, I need fresh lettuce. So I went, and I saw his printer active; I connected his wireless, saw his printer there, and printed out to him; I’m always watching. Stop eating my vegetables. And this scared him so much. He apologized. He brought me vegetables for a month. It was great.
Julius Musseau: Oh, I like that. That’s a modern take on Rapunzel. I love it.
Shannon James Smith: Okay. Guys, well, if there are no questions, I’m going to clip this.
Jim Manicode: That was fun.
Shannon James Smith: We don’t need to run it. I mean, I think the point here is WAFs aren’t going away. They might get bundled into other stuff and stop being a separate product category,
Jim Manicode: Yeah.
Shannon James Smith:
But they’re not going away anytime soon. Tens of thousands of engineers out there are experts at tuning these things and making them work as best they can work. But the good news is with runtime protection; you can send that intelligence back from the runtime, back from inside the; I’m going to just show this one last slide shot again. So the app itself on the right over here can send information back to the firewall, right, with intelligence about how to discern this stuff that’s going on on the outside better and more efficiently. So the real story is runtime protection is incredibly powerful but can also work with WAFs. Thank you all for coming today.
