DAST or WAF...Which is Better?

Speaker 1: All right. Hi, everybody. Welcome. Welcome to all that are coming today. My name is Akira Brand. I’m joined here with Aubrey King. We are so excited that you are here. Three time. So, Aubrey, do you want to kick us off and kind of just tell us a little bit about who you are and what you do?

Speaker 2: Sure. Absolutely. I’m Aubrey King. I am I’m so used to saying that I’m a solutions engineer from F5, but I am no longer a solutions engineer. I was a 12-year presales engineer for five, and now I have made the switch to move over to become a community evangelist for Dev Central, which is the 20-year-old user community that we’ve had. We’ve had some strength in for a very, very long time. You know, it’s one of the things that brought me into F5 and to use it as a product and now, you know, I’m there working on it.

Speaker 1: Community. I want to ask you a question, and that question is what are you most excited about in your work right now?

Speaker 2: I’m. Wow. Oh, wow. That’s hard. I mean, like you could say a million different things. It could be technology related. You know, as far as security. It could be lenses that I’ve got, etc. Working on the theme music for shows. I mean, so many new things. But I guess as far as the excitement I’m most excited about, really, I guess the transformation that is happening in our company, Right? I mean, we have really kind of gone from being this hardware sort of juggernaut out there and known for nothing but load balancing to becoming a software company known more for security products in a very short period of time. So it’s like it’s a really exciting time for me to be covering the community at this great time of change. That’s got to be the most exciting piece.

Speaker 1: Yo That’s so true. Like, especially when everything’s in flux and you get to kind of be that person that glues and like not necessarily like you to stitch and hold everything together. You can be that intermediary and like that translator between, like, here’s what we were, here’s what we are now. That’s really cool.

Speaker 2: Yeah. I love it. Nice. How about. How about you?

Speaker 1: Yeah. What do I do? Who am I? Well, everyone. My name is Akira Brand. I work in developer relations at Bright Security. Here you can see our little fancy logo up here. We are a DAST company, which is one of the reasons that we’re having this conversation with Aubrey today is that DAST is our main offering. So that stands for Dynamic Application Security testing. We’re going to get into that a little bit more about what that actually does and what that means for software developers and other people in DevOps. What else can I tell you? I have been working here for a little under a year. I really like it. I am kind of similar to Aubrey in that a lot of my job involves communication, right? So I do a lot of teaching. I do things like this kind of webinar, and I’ll wrap up briefly my intro by saying two things. One is that I used to be a professional musician, so we may actually jam out at some point. So that would be pretty sweet. And the most exciting thing I’m working on at my job right now is a visual novel to explain the different aspects of AppSec to beginners. So me and my colleague are working on writing and illustrating this entire visual novel, and I’m going to present it at an RSA event in January, and then we’re going to publish it. I’m going to use Ren Pi to build it. I’ve never used Wren Pi, so I’m going to learn a lot. I’ve actually not coded in Python for four years, so we’ll see what I remember. But apparently Wren Pi is quite, quite user-friendly. So I was inspired by a visual novel called Okey Dokey Literature Club. It’s a horror game. It’s terrifying, it’s a wonderful game. And I was like, Well, I’m not going to make this scary, but it is going to be really cool. So that’s me in a nutshell. So let’s jump in then into what DAST is and what WAF is. For those of you who may not know and if you do, the section is not necessarily for you, but we’ll make this quick and then we’ll get right into the pros and cons, one versus the other. So Aubrey, would you like to tell us a little bit about what a WAF is and what it does for WEP?

Speaker 2: WAF for those that don’t know stands for Web App Firewall. And recently there has been a bit of a change in that segment to include API defence. So you may also see the acronym WHAP, WRP web app and API protection. So those two are very, very similar in nature. And so the idea behind a WAF is that you can put up defenses between your users and really your abusers and your application, right? The idea is that no matter what’s going on behind there if we get some criteria that cause us to stop, whether that’s a signature or whether that’s something that we’ve learned dynamically from under the understanding, the application over a period of time, we’ll meet criteria and stop that traffic going forth towards your application.

Speaker 1: Life is short and sweet. I loved it. Well done. Well done. Why do you feel like if someone was coming to a website with absolutely no knowledge at all and needed to understand, like, what could it do? Like immediately for their applications? What would be like the five seconds? Like, explain it like I’m five sort of version?

Speaker 2: Sure. Well, the easiest thing to do if you’re people discover Raf’s, a lot of times when they’re under attack, they don’t even know it exists. And then all of a sudden, oh my gosh, I’m experiencing an application attack. Well, there’s a web app firewall thing. Check that box. And so that’s something that at five we refer to as checkbox RAF. It’s a very simple way to get things stopped. It’s not very effective and it usually is something that is able to be done fast and you feel some impact from that. But typically an experienced hacker would retool and be able to get around that sort of thing. So the 5 seconds really it just turns it on and it blocks the bad things from hitting your app.

Speaker 1: Nice, right? Okay. Yeah, that’s I love that. Just blocks the bad stuff from hitting your app. It’s almost like it’s like a literal shield. I like to think of it as cling wrap or something like around a piece of food. I don’t know what just because cling wrap WAF kind of rhymes I don’t know and stuff can’t get in through the cling wrap. Anyway, that’s my weird experience of WAF.

Speaker 2: So I guess around the same, the same kind of thing. If you could kind of tell me really what, what is the base definition here of DAST? Like what are the expectations?

Speaker 1: Yeah, for sure. So like I said earlier, DAST stands for Dynamic Application Security testing. What a DAST does is it’s sort of like an automated pen test, as it were. It doesn’t go as deep or like necessarily as targeted as like a hired pen tester with ten, 20 years of experience or whatever. But it can essentially what it does is it takes your app and it attacks it from the outside in the similar way that a pen tester would or a malicious actor would while your application is running. So it’s a little bit different from something like a SAS, which is a static code analysis tool that essentially will look at your app’s code and analyze the code itself to say, okay, what vulnerabilities is this code exposing? The DAST will actually look at the app again as it’s running and attack it from the outside in as opposed to looking at it from the inside out. It’s also called black box testing. I’m actually going to draw a little picture here if we can. Yeah, here we go. So can you guys see my little picture? Little screen? Okay, so here’s your application. And a SAS would kind of look at the application from the outside and right away it would look like at the code. At the code itself. So while there’s a lot of shapes going on right now, I love it. And what it says is it’s going to attack it from the outside and like this, But it doesn’t look at the code, right? It’s this is all this right here is all a black box. You. Absolutely can’t you can’t see any aspect of anything going on in here. This is all hidden from the DAST. So expectations of it, it’s essentially to see what kind of vulnerabilities you can get into if you are an attacker or if you are a malicious a malicious actor. Yeah. Does that does that make sense? I can draw way more boxes than visual aids.

Speaker 2: You know. Absolutely. That that that is a that’s a that’s a good one. Code analysis obviously can happen in a couple of different ways. And I guess one of those things that I’ve had customers say to me, you know, is like, boy, but that takes some time. So, yeah, what are what are I guess how can you how can you really make that process as quick as it can be with. Sure. Because I. You know that that is one question that I had for it.

Speaker 1: Yeah. So you got to know it. You got to know. Well, let me say it this way. DAST used to have a pretty bad reputation. I’m not going to lie to you because it was really, really slow. So in the olden days, the olden days where people release software on a waterfall last month. Yeah, 5 minutes ago. Where people release software on a waterfall method. A dam would probably be run toward the end of the software development lifecycle. It would take potentially like a day, right? Or at least several hours. Sometimes it would take a couple of days to run the whole thing. But since it was a waterfall method that wasn’t that big of a deal, right? You could you could accommodate for that in the in the in the building of software. But now people are doing things like Agile. They’re doing things like dev ops, which is even faster than agile. And if you have an agile sprint, like an average two week sprint, you can’t afford to have like at the very end of your sprint to take 2 to 3 days to run a DAST on your stuff. That’s insane. Like it doesn’t, that doesn’t make sense. And even more so in DevOps. We have customers that release software hundreds of times a day. Like you can’t you cannot have that amount of amount of time. What I will say is that DAST are getting much, much faster. And also you can do things like now you can put DAST into CD pipelines and scope them appropriately, You can scope them with HA files, you can scope them by like the type of technology you can scope like that you want to actually scan. You can scope them by like different segments of your application. So DAST are also they’re getting a lot faster. And one other thing that’s actually really cool that we’re doing here at Brite, and I’m not sure if anyone else is doing this if they are, that’s also really sweet, but we’re actually integrating DAST scanning in at the unit testing level so you can start writing your unit tests and then scan each individual piece of code before you even before you integrate it into the into the rest of your application, which is freaking sweet. They do take a little tiny bit longer than regular unit tests, which is we’re trying to get a lot better at that. So normally a unit test will run like lickety-split right around super fast for us because we have to boot up our DAST engine and it’ll take about 30 seconds to a minute to run a test. But at the end of the day, if you’re testing that soon in the software development lifecycle, 30 seconds to a minute to find and remediate a vulnerability is still pretty, pretty, pretty solid, especially considering, you know, if you have a test suite with maybe 20 tests. Okay, that’s 20 minutes, but that’s better than three days at the end of a release cycle.

Speaker 2: So I guess with micro segmentation of applications now, so what you’re saying is that an app developer could then maybe just take care of their own application while developing it with DAST and then kind of contribute it to the greater whole once you put that in with a sprint?

Speaker 1: Yeah, exactly. So which is, which is really cool. I think that a lot of DAST Tools and a lot of security tools in general are doing this whole thing called shifting left, which essentially means we want to put these tools in the hands of developers and then the people that are building the software much sooner, as opposed to having the apps team come in toward the end and. Essentially kind of mess with everybody’s stuff, as it were. So it’s really exciting. And I’m curious, Aubrey, from you. So like I said with that, you used to have a pretty bad reputation because it was super slow. Laughs also had a bad reputation because they claimed to essentially give you this security. And a lot of people were like, No, they don’t. It’s a total false sense of security, like there’s false positives. Things get in that shouldn’t get in all the time. Like it’s gnarly. So what’s your answer to that now?

Speaker 2: So that is kind of the beginning of why if we used to hear that a lot at five and, you know, it’s really complicated to sit down and figure out how to how to develop a policy once my application’s already in place. So you want me to turn on this new security software and mitigate 20 billion false positives before I even, you know, before I even know what’s happening or what kind of traffic is flowing into my application. That really has been the past of WAF. And you ended up with back in you, as you said, the olden days, right? You ended up with a lot of false positives, right? So there was just everything’s blocked. In fact, I. Took a look at a community message today where someone was saying, look, I turned on my, you know, my web app firewall and everything’s blocked. Now. I don’t know what to do. Well, that’s because of improper policy building. And, you know, you don’t want to start with the most advanced portion first, right? I mean, you wouldn’t go ahead and do an engine transplant if you were just learning how to change your oil. That’s not you know, that’s not what you want to do. So for the most part, you know, the the the thing that’s cool with WAF these days is you have a number of different places where you can actually inject that web app firewall and you can determine how much you get where. So, you know, also back in the day, we used to kind of shy away from this idea of a security onion for a while because, you know, you had a lot of people that were saying, well, you know, defense in depth is actually expense in-depth, Right. I don’t want to just spend and spend and spend and spend. But what we have found is with a distributed wave policy or placement, you end up actually spending less and not getting all these false positives. And how is that done? Well, if you can cut off a lot of what I consider the garbage with a low-level WAF at the very front as traffic comes into your environment before it even hits your environment in our in our five distributed cloud is where we’re doing a lot of that today. So it’s out there. You get all of the signatures and stuff taken off the top that we just know it’s garbage. You get the most common bots and things like that taken off the top. We know that’s garbage also. Everything that’s left could then be handled by a much more intelligent and smaller web app firewall at a perimeter. And then even on down further where you can WAF at the observer level with something like Engine Engine X app Protect, that’s something that we if we are using a SIM which as a good security practitioner, I hope all of you out there have a sim in your environment that you’re contributing to, right. But if you have an application server firewall web app firewall that’s contributing to a SIM and your perimeter is also contributing to the same SIM and your cloud WAF is also contributing to that same sim, you know exactly what your traffic looks like at every step of the way and you have a lot less false positives and a lot less spend. So yes, that’s that’s it. It has it has changed quite a bit in the past really couple of years for especially for F5. But in in the entire WAF industry, it’s changed.

Speaker 1: Was there a particular reason that it changed other than like maybe an uproar of like this doesn’t work, like you guys need to fix it?

Speaker 2: Well, honestly, I think I think what changed it is really is, is really micro segmentation of applications. Again, it’s like, you know, as we move into this new kind of Kubernetes area of technology, you know, you’re looking at everything is so small and agile, it’s hard to put a big honkin, you know, very complicated firewall in there as well. And as you guys said after the fact, Right. That’s not when you want to get it done. It’s during you know so building your policies, you know as you guys said, the same kind of thing. If your application developers are taking a look at their DAST right. They should also be understanding of what a WAF picks up as a default policy. So that that’s just again, good, you know, good security practices.

Speaker 1: That’s actually really interesting. Oh, sorry. Go ahead.

Speaker 2: Oh, that. That was it. I was just going to say that. So that’s it. Really. Like clarification. All this stuff really is, I guess, the answer, right? Because when people go out and they put up something in Google or they put up something in Azure, they put up something in AWS, there’s a little checkbox that says Web app Firewall, and they don’t know whether that’s good or bad. They just know it says web app Firewall and don’t even really know what’s covered. So once we started seeing that, then it becomes difficult for our guests to understand what’s actually there as they’re scanning web app firewalls. Then it’s very difficult for any sort of unification when you have applications that exist in AWS, Azure and GCP, which is something that we see all the time now. So really, what’s your firewall policy when your app exists with three different web app firewalls you don’t have? Yes. So that’s what’s made this evolution, I think in Web app Firewall recently is really the way that apps have changed.

Speaker 1: Interesting. Okay. That makes perfect sense with with DAST. It’s sort of a similar thing. Like it was a little more like it’s sort of six of one half a dozen or the other. Right. So we have these different ways of software being built and the software itself was different. And that’s kind of what we saw as a big miss in the market, is that DAST were just taking so long and we figured it’s better to have a DAST that works well like a test. It isn’t just going to really mess with your stuff as opposed to people. Just stop, stop using DAST, because that’s what we were also seeing is people were just not using it anymore because it was completely obsolete. But DAST does is very powerful and you don’t want to not use it. But my God, if it takes 2 to 3 days off your development time, forget it. It’s insane.

Speaker 2: Oh, yeah. And even funnier, I can’t even imagine, like our customers back in the day would, would have a have an attack or whatever they’d go through there. They’d go through their upgrade process and then they’d check their web app firewall for all this new stuff and start going through that. And then they’re going to scan the application afterwards, like the Web app firewall portion is going to take a day and then the DAST portion scanning is going to take, you know, my customers did it overnight. They would just say, okay, I’m going to set it and just scan the heck out of this thing because my customers had massive applications and it would take a like you said, it would take a long time. So by that time, like you said, you lose time. So I think we need these new technologies and I think we’ve needed the new applications to force these technologies to become better and faster.

Speaker 1: Yeah. I mean, as the tech evolves, the tools have to evolve with it. Like, imagine trying to work on like a brand new Mercedes with, like, I don’t know, some kind of really obsolete auto tool or just tool in general. I’m drawing a blank. I’m like, Well, I’m trying to think of it old an old automobile. My first thought is like a plow and a home. Those are totally different experience. Tractor John Deere Modern modern farming without tractors. That would be insane. So.

Speaker 2: You know, we’re starting to see things like and this may be a little bit of a tangent, but we are starting to see modern farming with those kinds of needs as well. Micro segmented farms that exist with five g towers instead of wi fi to pilot drones and things like that. I do think that in the future even, you know, especially large scale farms are going to need technologies exactly like DAST and WAF to make sure that y I mean if you’re if you’re, if you’ve got a drone army that’s responsible for keeping your fences operational and for understanding what your soil temperature is, you know, every square foot and whatnot and moisture levels and that sort of thing, you are going to have APIs and you’re going to have developed code. You’re going to need to scan those API endpoints and you’re going to need to defend those API endpoints. So, you know.

Speaker 1: It’s so true. Like the APIs are eating the world. And that actually brings me to a question that we had in the Q&A. So let me go ahead and go to that. The question was, is authentication to access an API endpoint enough to prevent being abused? This is a really good question. What other strategies can we use? The Oracle did a great a great answer, which I’ll read outside. Read outside, read out loud right now. She goes, Hi. Okay, that’s not enough. We want to harden the API via secure coding security, testing DAST or pen test code review, putting an API gateway in front of it and there’s more. But there would be a really good deployment. So yeah, it’s like with these APIs. I mean, I’ve seen some modern farm equipment and just like stuff that we think is this old school that is the most advanced stuff I’ve ever seen. And I mean, if you can’t just do it, you can’t. Like the Oracle said, you can’t just authenticate your APIs and be like, okay, that’s good. So we have all these suggestions from the Oracle. So again, that’s secure coding, security testing code review and putting an API gateway in front of it. But how do you think Aubrey like a WAF would fit into this?

Speaker 2: Oh, that’s an awesome question actually. So with the authentication question and specific, this is one that I’ve, I’ve had to had to face more than a few times. Just because you have something that’s authenticated doesn’t mean that authentication engine can’t be abused. To two instances that I can think of off the top of my head. One, I worked with a customer that was building something with Active Directory, and an attacker had figured out that essentially they were doing a directory search across a very large directory. This is a huge, huge employer and when you have some sort of tool that’s going to expose an x 500 directory like AD or LDAP, and you get something, a web application that is going to do a search against that, well, that takes up a lot of resources so somebody can actually exhaust your API and essentially shut it down by asking your authentication mechanism for something it doesn’t expect. So yeah. So if you’re Yes. So if you’re if you’re looking to do let’s say you figure out that you can put specific directories within the Active Directory appended to the name or whatnot, you can have all kinds of all kinds of havoc and make sure that that authentication is super tied up and then can’t serve any more customers. Or another example would be Samuel. Right. So Samuel is not just your average, your average authentication mechanism. We’re talking about tokenization, not just a username and password, but also proving that, hey, this place is good with me so you can federate me here, right? So that’s kind of what Samuel is doing. So both of those things I’ve seen abused heavily in applications. Now the weird thing, the thing that was in common with both of them, neither one of those customers, the application developers, had no clue that they were under attack. They didn’t know why the why the application was performing slowly because man in the lab, it just works. It’s so fast, it’s quick and no issues. But you know, you get a hacker at it who’s figuring out how to search directories. That is, is going to shut things down pretty easily. So a web app firewall, how that would fit in very simply a couple of different ways. Number one, if you have, say, a signature based WAF, that’s the easiest piece to get going. If you have maybe a specific signature that is saying, you know, Active Directory, for instance, we’re looking for this signature, that signature and that other signature. Right? We’re going to evaluate those things. And if we match, we’re going to block that traffic and we can actually block that traffic for a long period of time or block that IP address, add them to a deny list, whatnot. But more importantly, the better way to do it is when a Web AMP firewall is appropriately configured to understand your application. Over time, we have per URI understandings of what should be a request size-wise and what should be a response. Size-wise, we have a certain number of times that a client can hit from the same IP address, and things like that. We have JavaScript that we can run to make sure that we have a human. Things like that are all in front of the application at that point. So we’re able to patch those things really quickly, especially if we have an advanced web app firewall that does have an understanding of the application. Now for me though, what I don’t understand, of course, is the opposite side of that. Once we have identified that and shut things off, I think there’s a tendency for customers, from what I’ve seen, at least my customers are typically network folks and they just sort of forget about it. Okay, well, it’s blocked. That’s blocked. So not my problem anymore. So same question to you, Akira. What then happens once we once we’ve figured this out and we’ve got blocked traffic, what then would a DAST do to correct the issue?

Speaker 1: Sure. That’s a really good question. How would DAST correct that issue? So at the end of the day, the DAST is sort of like our oracle, right? It shows us the way, it shows us what’s wrong. And if it’s a good guess, it’ll also show us how to fix it. So maybe you still are running DAST scans on your application. You can also do things like you can add DAST to a WAF approved lists of endpoints. The Oracle just spoke to this a little bit ago and kind of use the two in tandem. But the way that really what would happen is you would run a DAST tool against your application, even if there’s a WAF in front of it and some traffic is being blocked and you would be able to see the vulnerabilities that still exist in your application. And then it’s up to the developers then, or the apps team and the developers together to fix those problems. So it’s not like the DAST itself can go in and fix it for you. It. Again, it’s just like our oracle. It’s our it’s our seeing or seeing eye dog or our gazing into the abyss, as it were. And it will reveal the viewer the answers to you, but it won’t actually enact them. Was that your question, Aubrey?

Speaker 2: Absolutely. And, you know, that’s one of those things why, you know, at least from what I’ve seen over here at F5, we always talk about making sure that there’s a synergy between your networking teams, which again, largely our F5 customers and the application developers, because it’s not over. I mean, once we’ve locked that thing, you need to use your DAST to figure out how to fix that code on the back end, because ultimately, you know, your firewall is going to stop that traffic for a while. But hackers are smart. They keep poking. They don’t you know, they don’t just go away. Most of the time we see them try and when they’re thwarted, they try again. They retool and not, you know, you don’t see a whole lot of hackers out there who are good that have one trick. They have.

Speaker 1: Yeah, they have a ton of stuff they can do. Yeah.

Speaker 2: Yeah.

Speaker 1: Yeah. That’s gosh, it’s actually it’s kind of a side note. It reminds me, I read an article yesterday in the LA Times about scamming and like, cryptocurrency scams and like, phishing scams, cat phishing scams that people were being actually trafficked into into doing. These are these are this is something I think that I didn’t really realize or didn’t don’t often think about is I’m like here in my cushy nice office or whatever like getting paid money to do this is that the people that we’re trying to defend against are genuinely like huge crime syndicates. Like this is not like a random person in their basement. Like so you talk about people having tricks. Not only do they have tricks, they have they have people power behind this like they really do. And it’s quite sad how they get those people. It’s definitely it’s deeply messed up. And that’s something I think we need to we need to remember. It’s like you can’t just set it and forget it with any of this stuff because these people that are trying to get money from other people or trying to scam other people, they’re not going to rest. So why should we? Right. Which is I think why it’s so important to do things like have a WAF, but also like run a periodic desk scans, like put everything in your pipeline. Like when our company, when we find a new vulnerability, we’ll have usually within 24 to 48 hours like some kind of test for it, right? So like people are always finding new stuff. They’re always looking for new and improved ways to like, mess with you and you got to keep on top of that. And that’s why I feel like it’s such a bummer that there usually can be such animosity between the apps and development teams or the networking and development teams because, I mean, this is serious stuff. You know, these are these are real assets that we’re trying to protect. And even on the other side, these are real people that are potentially being trafficked or abused in order to to do these things. So I don’t know. That kind of was a sobering article. I know it’s a little bit of a tangent, but it just kind of reminded me a lot more of the human aspect of what we do. It’s not just hanging out in rooms and being like, Ha ha DAST and why this is better? It’s like, No, this is like real stuff.

Speaker 2: Well, you know, obviously, you know, I’ve spoken to you about this in the past, but for me, truthfully, these are two technologies that I think are absolutely necessary. As someone who’s been pitching tech for a very long time, you know, and feeling like we were alone, I mean, God in our in our company when the world was paying attention to next-gen firewalls and you have some of these next-gen firewall companies saying you don’t need a WAF because you have a next-gen firewall. Oh my God, no you, you need and, and I had a friend at a next-gen firewall company who, who hit me up and said what, what is the WAF do different than our next-gen firewall. Why is that, Why is that a necessity. Why do people think they need this thing? And the answer is pretty interesting. One of the things is you have to be able to profile an application over time and like I said, understand exactly per pre-WWII what it is. And for those that don’t know what you or I is, let’s say the URL. I think most people know w w w dot dot com. Right. The you or I is the rest of the stuff after that. Right. So or the path, as some people call it. So per you or I statistics on what’s expected on every single request and received that that is something that is necessary. But another one of those things that that I said as you know that I said to this guy as a necessity for a good WAF, right, because that’s a difference. You can have a checkbox WAF you can have a bare minimums, you can have 17 pieces of flair for anyone that gets that. But you, you know, you’re, you’re, you’re much better off if you have something that is also integrated with DAST. And that really truthfully is something that we have said for a very long time when we when we purchased ASM, which is the predecessor to our CAF product, I think it was called Magnifier, actually back in the in the day when in the nineties, really like when we were looking at this thing and Magnifier had scan tools to build policy from. So we just continued with that kind of thing. And we’ve tried to make sure that if somebody has a generic scan tool they can take the results of that, and export it to XML. Usually, there or CSV is another thing that we will work with as well and, and then create a policy from that desk so you don’t have to do all the crazy policy building and mitigating a million false positives as such when you’re direct integration between these two technologies and when your DAST and your WAF are working together hand in hand, that those are the most secure shops that I see. Those are the web monsters out there. They all have these two technologies, all of them. So but that is, that is an imperative integration between the two and understanding your application over time.

Speaker 1: Yeah, absolutely. And I would say even adding more tools like SAS is always good to have, right? Like just not, not even necessarily stopping at those two. And I do want to have a little bit of a conversation about like what else we could include and we have a bunch of questions. So maybe let’s hop over to the chat and kind of see what people are asking. We’ve had the Oracle doing a great job of answering some of them, but there’s one, especially in the Q&A that I want to get your opinion on. AUBREY So here it is. Are we ready? Yes, Susan McReynolds asked. We’ve seen a huge uptick in LFI attacks versus cross-site scripting, which used to be the predominant attack vector for our retail customers. Any insight or ideas as to why is suddenly, since the beginning of the year so popular rush to deploy new tech without input testing etc.. Looking for some hypothesis. So sorry. Really quick. Just really quick. Lfi, for those of you who don’t know, stands for local file inclusion. And that’s when a hacker tricks an application into giving it access to the files on the web server. So go ahead. I’ll be sorry to cut you off there.

Speaker 2: Yeah, no, that’s okay. It’s funny. It’s funny As far as why insight, it’s so hard to understand the insight We run. So our F5 labs team runs some scanners along the Internet backbone to try and pick up and understand what the most used hack utilities are out there right now. What? And by CVE we also try to make sure that we understand what’s out there. And I’ll tell you what, the most popular CVS being hit right now are from 2018 and 2019. So it’s like these back in the past kind of attacks, they’re still there and they’re still open. Now, as far as local file inclusion, though, this reminds me of there was a time maybe ten years ago when directory traversal was the exact thing we’re talking about here, like it’s directory traversal and it was a popularized thing because by default NT servers not to pick on any any particular server vendor. Sorry, Microsoft but NT servers for a while came default with these directories open and so a hacker could really just. I mentioned you or I before so you would include path in there and you if you’re root directory of your Microsoft web services where like you know C colon slash X, y, z you just dot slash and then program like I mean you can expose the the the server itself with a directory traversal attack. Now why local file inclusion? I think it’s also because of exactly what I mentioned before, the trivialization of applications. Right. We’re able to bring them up anywhere. But here’s a quick question. When we bring an application up somewhere, let’s say a developer goes out to the cloud and says, I want to bring up this cool container thing that does something and I’m going to bring it up in Google Cloud. And they do that POW. They bring up a container. Well, what’s that container? Are you sure that that container is locked down tightly, or is it something that’s just easy to use? Well, I can tell you that I’ve talked to a lot a lot of developers out there who will just use the first Ubuntu container that they see out there in their cloud provider. They haven’t. They don’t check it. They don’t take the time to scan it to do the due diligence. The full and the security teams oftentimes don’t have the time or understanding that those things are even there. Boy, I’ve worked with customers they didn’t even know that their developers had a huge lab environment in a public cloud provider, much less that that was a massive security threat. So so yeah, I really do. I think it’s just because we have these utilities, they’re common and I don’t think they’re fully patched. So I think that you know, as far as local files, I think hackers are really picking up on that. Hmm.

Speaker 1: That’s really yeah, I wish I had to say, because I honestly have no idea. So I’m really glad that you had some tips and hints on that. Susan, I hope that answers your question. Or if you have any follow-up questions, feel free to put them in the chat or in the Q&A. Okay, cool. She says very helpfully. Awesome. Right on. Okay. Let’s see what else we got, if there are any other questions. All right. I’m just going to kind of scroll up to the top. That’s the Oracle had a thing she wanted us to mention, which is you can use Bright, which is the DAST scanner we’re talking about today to test an API. What you do is you upload your API schema file, which is like the open API or the swagger file, and it will scan it and you can edit your definition while inside bright to ensure it’s in the right format for testing, which is pretty cool. The first time I saw that, I was like, No way. It’s like a little security linear on your APIs, which is pretty sweet. Let me see. Someone asked, Do you support web sockets in DAST? Oh, sorry, go ahead. Aubrey.

Speaker 2: I was just going to say actually like that’s a really great point to be very, very nice to see build WAF policy from swagger. If five product development folks are listening.

Speaker 1: Oh, is that a thing that you can do?

Speaker 2: Oh, well, hey, why not? That’s what I’m saying. Probably you want to push for that sort of thing, right? It’s because if I can get it from a DAST, a DAST, an output, if I can build policy from that, I can build an API protection policy very easily from swagger. I mean, obviously. But it would be very nice to be able to do that with a full WAF policy as well, if I had my wishes.

Speaker 1: Oh, here’s a question for you, Aubrey, too. This is a staff question. So here we go. How can a WAF protect when there’s a zero-day being exploited in the wild?

Speaker 2: That’s an awesome question. And this is like cheating for me because of who I work for. One thing that makes our WAF a little bit different is this lovely thing called Eye Rules, which allows you to pick apart traffic at layer seven and change literally anything. I mean, I’ve changed packet payload from, you know, from very bizarre FTP streams and that is typically how F five has stopped that as far as typical UAVs, as far as let’s say checkbox WAF for instance, anyone who’s secure in their public cloud WAF that’s out there zero Day that’s not you’re not going to stop that. It’s just not going to happen. But I can tell you that if you want to try to do something like that, probably the best bet would be to take a bot defence that is updated all the time. That’s going to. So our bot defence, for instance, is updated every 5 minutes. I think a lot of other bot packages are very similar and at least they’re you will be you will be protected from the automated threats that are out there trying to execute the zero day stuff. And if you take the automated garbage off the top, like I say, take the garbage off the top, That’s the that’s the easiest way to do that because without. Taking the garbage off the top. You’re going to be watching log files stream by as your attacker is just taking whatever they want. Yeah, that’s that’s it. When you cut the garbage off, you can actually see what the attacker is doing and then you can try and mitigate or honeypot or whatever, whatever you want to do. Now, again, go ahead. I was going to say I rules. That’s that’s another thing. So typically, if you look at dev Central, our user community. Right. Shameless plug. We have a million zero day rules out there that have stopped things that were supposedly impossible. The most famous one is probably the GHC sstl handshake dos. So that one is is legendary because that was something that OpenSSL said would not be fixable for eight months. We had it fixed in under 8 hours.

Speaker 1: Thing.

Speaker 2: But but we were the only web amp firewall vendor that did because of rule.

Speaker 1: So here’s something that just popped into my head. This is like a little bit tangential, but I want us to kind of like go back and forth on it a little bit. And then, Crystal, we’ll get to your question in just a moment. So I recently read this amazing article. It was a write up by a man named Guillermo Rambo, I believe is his name. He discovered a bug that allowed for just crazy for Mac OS devices to have apps that could listen to you via AirPods and Beats Studio had like your little headsets. And it was only through those two, those two things. It wouldn’t be for like just a regular like any any Bluetooth headset which was interesting to me. And he didn’t do he didn’t find this on purpose, right? He just was like working on something else and then was like, wait a second. Like I’m seeing a lot of hexadecimal in my terminal when I’m speaking. This is incorrect. Like, why is there is there unencrypted sound files happening? But anyway, so what I want to say is like, what about that kind of goofy just misconfigurations that a WAF and a DAST can miss, right? Because they’re not like necessarily like a cross-site scripting issue. It’s like some weird hardware issue and it’s like how, how do you reconcile this know, like how do we, how do we do all this tooling? We have all these layers and still there’s problems where someone accidentally misconfigured a daemon incorrectly, and now Siri can listen to me when I’m not talking to Siri.

Speaker 2: It’s funny, you know, you’re always going to go after the unknown. And actually I and Crystal, I see your question there too. I’ll get to that in a moment. But Sarah, your question is absolutely related to what Akira was just saying, the outbound threats, right? So the unknown, that’s one of those things. Can you configure a WAF to scan the the outbound stuff? Well, that’s normal data leakage protection stuff that is very, very typical for next gen firewalls and whatnot. But I will tell you this, one of the things that we typically do in our configurations is not we don’t typically put a WAF policy on there, but what we will do is we will utilize deny lists for outbound traffic. So and those denial lists are typically populated with known C and C servers, right? If you’ve got command and control stuff out there that’s known which our IP intelligence package is, what we typically refer to that’s something that can be updated on any of our devices or Engine X, same thing, right? So if you’ve got outbound packets from any of F five or engine X stuff, yeah, you’re going to be able to filter out any sort of attempt to get to known hacker utilities. So for the unknown, Sarah, the answer to your question I think is really a great one to cut down on the unknown that you asked about it here.

Speaker 1: Totally, Yeah.

Speaker 2: Real quick, if I could touch on crystals for a second?

Speaker 1: Yeah, sure.

Speaker 2: Right. So you asked about the Silver Line specifically. So how to is it possible to wrap a specific URI but not a whole FCN? Absolutely. You can do that. And in terms of of silver lining, it really boils down to your policy. If you wanted to hit me up, feel free. I’m on Twitter. Aubrey Kang at Aubrey King, of course. And I’m happy to help you dive into that a little bit more. I don’t want to spend the entire time on that one.

Speaker 1: What’s your Twitter handle? Aubrey King, F5.

Speaker 2: AD Aubrey King, F5.

Speaker 1: Awesome, cool, cool. Right on, right on. Crystal, Welcome to AppSec. I’m also relatively new. I’ve been doing it for a little less than a year. So we’re in this together. We’re all learning at the same time. It’s great.

Speaker 2: Oh, and Tahj wondering what the difference is. AWS managed WAF versus F five. Wow. So real, real quick. That’s also managed. WAF is going to be typically they have the checkbox WAF and they have the ability to maybe look at your policy. But the thing that’s interesting for me, I’ve had a couple of customers that have explored that and, and what they came down to is really they don’t, they don’t really know all the WAF stuff. My opinion, I mean it is, it’s a, it’s a, it’s a minimum sort of viable product and really that is what AWS is shooting for something that’s going to be effective. It can be turned on right now and they’re the best in the world at doing that for sure. But you know, you’re, you’re good. Hackers have gotten around a lot of that stuff. And really you’re finding that you know and we’re not the only advanced WAF out there there are other websites out there that do similar things right There are choices. But to me, I would just say that checkbox WAF is the one to get away from.

Speaker 1: It’s interesting that, like, you kind of keep coming back to that thing of like, hey, like, don’t do the easiest possible option because it’s not actually that in the world is still the false sense of security.

Speaker 2: Yeah, Yeah. It’s for emergency use only, right? I mean, really if, if that’s what’s there and that’s, that’s the only thing between the hacker and your app. Turn it on. Absolutely. Turn it on.

Speaker 1: Yeah. But it’s like, it’s like having like a house and you’re like, okay, put one window in.

Speaker 2: So. That’s right. We only need one way in or out. Know all the air comes in through one portal.

Speaker 1: Yes.

Speaker 2: Oh, my God.

Speaker 1: All right. We have.

Speaker 2: There are better ways.

Speaker 1: There are definitely. There are definitely better ways, for sure. I want to just do one last call for questions because we have about 5 minutes left. So let’s just see if there’s any things in the chat. I’m also your thing again. One last time I was Aubree king F five at Twitter. Do you have a LinkedIn, Aubrey?

Speaker 2: I do. Aubrey King.

Speaker 1: Okay. Okay, cool. All right, let’s see here. I’m just going to type this out so I can share my screen in a second and then people can take a picture of how to reach us. All right, let’s see here. Yeah. Okay. So there are also two communities that you can join, which are amazing. The first one is the Bright Discord Server. We’re working on building that up, and it’s a lot of fun. We like, and share memes and we talk about how to use bright. We talk about DAST to talk about all kinds of things cybersecurity. Also, the week Purple community is amazing. It’s free and it has a ton of free courses about apps and things related to apps, and that is that we hack purple dot com. We’d love to have you join us at one or both of those the links for those are in the chat. Thank you very much to the oracle and yeah follow. You can follow Aubrey on Twitter at at Aubrey King F5. I don’t have Twitter because I turn into someone I don’t like on Twitter, so I just don’t use it. I use it way too much when I do use it. So I have a LinkedIn. I’ll put my thing in here. Here we go. Here it’s just LinkedIn, dotcom slash Acura brand, which is great. Yeah. So we’d love to reach out to you and talk to you.

Speaker 2: Definitely. And I did want to just the idea of purple that brought me up to something I know I wanted to touch on for this. I want to.

Speaker 1: Oh, yeah.

Speaker 2: That everyone understood that these two technologies are not red or blue. These two technologies should be considered purple always. And I only say that because you think of a web app firewall as, Hey, this is a web app firewall. It is definitely going to be just for stopping traffic. But I have seen hackers that use web app firewalls to develop an outbound proxy to put in front of an application so that they can just run normal traffic at it and understand exactly what that application is doing underneath. So if you are good at at web app firewalls, you can use that for terrible, terrible purposes. And by that same token, anyone who is good with a scanner can also pummel an application and really do some things that you’re not supposed to do to that application. You know, I was I was actually talking to Kyra about using an open source application that comes default with a particular Linux standard. And, you know, you can you can shut things down with that. I’ve had to utilize that for very large attack traffic in simulations before.

Speaker 1: Yeah, that’s a good point, because if I can point a DAST at my site, at my website and get results on where the vulnerabilities are, literally anyone can point A to ask to your website and get information about where the vulnerabilities are. So it behooves us to really use both of these technologies because I mean, especially for DAST, anyone can. So it’s kind of like it’s sort of like not putting locks on your doors. Like anyone can just walk up to your door and just push it open, right? Like you might as well put the lock on it because it’s so easy to break in. Otherwise, if it’s not, again, it’s not like hiring a full-blown pen tester. It’s not like the most in-depth, extreme thing you can possibly do. However, it’s it’s let’s let’s get the low-hanging fruit right. Let’s make sure that the doors are locked. There’s there’s actual glass on the windows with locks on it. Let’s put a little security system on and then later we can hire a consultant to tell us, oh, yeah, you know, you’re based on windows are actually kind of kind of insecure or whatever it is. Right. I just bought a house, so I’m all about like, house analogies right now. So, yeah, one last thing I just wanted to share again, I literally just made this in the past 5 seconds, so I’m going to share my screen here and just put our contact info. It’s it’s beautiful. This is probably the best slide show I’ve ever made. So yeah, if you want to reach out to us, feel free to do so there. And Aubrey, any last thoughts as we wrap up today?

Speaker 2: No. Honestly, I just had such a blast talking to you. I’m glad that, you know, we did this, and I’d love to do it again. Any time you guys need help with wife stuff. I love talking about it.

Speaker 1: Yeah, this was amazing. I am also really glad that we’re both musicians because I feel like we had kind of a chance to sort of riff, you know what I mean?

Speaker 2: Yes.

Speaker 1: Yeah, for sure. For sure. For sure. All right, cool. Well, everyone, thank you so much for your time. Abhay, thank you so much for your compliment. I really deeply appreciate that. That’s very kind of you. I actually am going to take a picture of it later and just use it for remind myself when I’m if I ever feel down, I’ll be like, Oh, he’s on my side. So I appreciate that. That’s amazing. Okay. Well, I guess that’s it, y’all. We’ll stay on for like a couple more seconds here just to say goodbye. But again, everyone, thank you for coming this. This now concludes our webinar on WAF versus DAST. I hope we’ve all can convinced all of you to use both as often as humanly possible and don’t both, both and whenever you can. And don’t just do the little check mark that says do the easiest way out. And yeah, thank you again, everyone, for coming and you’re welcome and thanks for the energy and thank you for the questions. And this was wonderful. So have a good day, everyone, and I’m going to go ahead and stop my share and we’re going to end the webinar right here. Thank you, Aubrey, and thank you, Tanya.