SAST VS DAST: The Ultimate AppSec Showdown

00:00:00

Speaker 1: Hi, everyone. Thank you for coming. I am Tonya Janka. I am your host. And this is Sharif Koussa. He is my guest today. Welcome to the SAS versus Dassault Webinar, where Sharif and I are going to just talk a lot about OPSEC. There won’t actually be any fighting. As you can see, we are not wearing boxing gloves or. Right.

00:00:21

Speaker 2: I was looking forward to that part just to.

00:00:26

Speaker 1: Welcome everyone who’s coming. So we know people are still kind of like streaming into the chat and streaming into like just connecting. And so we wanted to give you all just a minute or two so that you could join us and get settled, etc.. Do you have a nice caffeinated beverage?

00:00:45

Speaker 2: Sharif I got water. I had my coffees because it’s already noon here in the East Coast.

00:00:53

Speaker 1: I guess if you have a bunch of caffeine now, you might be up all night.

00:00:56

Speaker 2: Yeah, exactly. I’m not going to be I’m not going to be a pleasant person at night. So enough caffeine for the day. What about you? Did you get your caffeine?

00:01:06

Speaker 1: Oh, I have some nice Coke zero or I think they named it zero sugar. Now, some sort of branding marketing thing. I don’t understand everyone in the audience. Could you put in the chat which city that you’re phoning in from? Because as you can see above my head, I’m phoning in from Victoria, B.C., and Sharif is phoning in from Ottawa, Canada, where I used to live, and that’s where we met.

00:01:36

Speaker 2: Wow. All over the place. Arthur, Brazil.

00:01:42

Speaker 1: Lovely. Oh, my gosh. That’s amazing. Kampala, Uganda, Mumbai, Pretoria, Frankfurt, New Hampshire. Oh, my gosh.

00:01:55

Speaker 2: It’s real.

00:01:56

Speaker 1: Tel Aviv. Oh, my gosh. This is totally amazing. All of your amazing. And and yes, Sharif, I am comfortable to talk about all the things So New York, Las Vegas, Houston, Denver is amazing. OC So it’s 4 minutes after the hour. So I think we could probably start. Does that work for you?

00:02:24

Speaker 2: Sharif It does.

00:02:28

Speaker 1: Okay. So welcome, everyone. Welcome, everyone to the joint webinar from Brite Security and also Software Secured and Reshift. So Sharif, how about you tell us a little bit about you and about both of your companies and then I’ll talk about me and my company.

00:02:45

Speaker 2: Yeah, that sounds great. So hello, everyone. My name is Sharif Koussa. I am the CEO and founder of a couple of companies, one called Software Security and Software Security as a penetration testing as a service company based out of Ottawa, Canada. Reshift Security is kind of like a subsidiary of software secured, and it is a static code analysis tool for the software developers. We’re going to explain all about that in the in the next four, 55 minutes or so. But basically, I started out as a developer long, long, long time ago, and I spent about seven, eight years writing Enterprise Code. And then I came this lovely thing called OWASP Open Web Application Security Project. And basically I realized all of the bugs that I’ve been writing in my enterprise software and I decided to switch. So I joined OWASP. I wrote a lot of open source code for OWASP, particularly in web code. One thing led to the other. I find myself writing questions for G exams, the JSP, Java and ASP.NET. If you did one of those exams and you cursed, I’m sorry, that would be me. But then one thing that the other find myself doing. Security Code Review for Wells Fargo. And then I started software secured in 2010 and Reshift in 2019. That’s me.

00:04:15

Speaker 1: That’s awesome. So I’m Tonya Tinker. I’m also known as She Hacks Purple, and I was a Dev for a long time. And then I met Sharif and a bunch of other people that were into OPSEC, and Sharif invited me to join OAS with him, and he was the OSS leader and he arranged all these talks and stuff. And I got to learn more and more. And eventually he started letting me volunteer and I started helping organize different talks and events. And then we ended up forming a much bigger volunteer team with a whole bunch of amazing humans. And basically I got to participate in this amazing community because I met Sharif. So I think he’s pretty great.

00:04:58

Speaker 2: Thank you. Thank you, Diane. Thank you. Appreciate it.

00:05:01

Speaker 1: Yes.

00:05:02

Speaker 2: All right.

00:05:03

Speaker 1: And oh, and bright. Bright. So I founded a startup in 2020 February, the worst time ever to start a startup. And it was called We, right? It was called We Hack Purple, and we got acquired by Brite Security. As you can see above me, in May 2022. And so now I’m working with them and I’m running their developer relations. And what they do is create a dynamic application security testing tool. So that’s one of the things we’re going to talk about today. So Sharif, do you want to just explain what what the heck is Sast and why do we have so many acronyms? Just kidding. You don’t have to answer the acronym question, because that’s that’s too hard.

00:05:47

Speaker 2: Acronyms because we love acronyms. But SAST stands for Static Application Security testing, which is basically static code analysis or lending, if you might call it that, for for for security purposes to find security vulnerabilities in in source code. That’s basically what SAS is.

00:06:12

Speaker 1: Yes. Okay. So dast is sort of like the complement to SAS. So SAS looks at the code your team wrote. Dynamic Application security testing a dast. It looks at your application as is actually running. So it’s on a container or it’s running in a container, it’s on a web server, it’s on a platform as a service. So it’s actually running and then the dynamic tool interacts with your application. So it starts out nice. It just clicks some links and checks things out. It’s like reading requests and responses. It’s being so nice and passive and then you tell it, I would like you to destroy this app now, and then it goes and it interacts with your application and it.

00:06:54

Speaker 2: Actually do that.

00:06:56

Speaker 1: So it sends your own requests and your own responses trying to find vulnerabilities, just like SAS. It’s trying to find as many vulnerabilities as it can, but it’s doing it from interacting with the running app versus looking at your actual written code and not actually running it. So they’re kind of different. But I don’t know, we we call this SAS versus DAST and we’re like, we’re going to fight. But I feel like we can just tell all of you now. Sharif and I don’t really fight and, and I don’t know about you, but I think both are essential if you want to actually have a good look at your app. What do you think?

00:07:36

Speaker 2: Sharif That’s a good point. Actually, I think this statement is true, but there is a lot of parameters around that, such as the size of the company, the technology that you’re scanning, who is actually doing the scanning, things like that. And I hope we can cover all of that for people so that they can understand when to use what obviously for a proper integration of security into into you would kind of need both. But I want to walk people through kind of like what is that really good at? What is SAS really good at? When does it make sense to kind of like use both, When does it make sense to use one? At which stage? Because I’m pretty sure people here are coming from all sorts of industries, sizes, etc.. Tanya what do you like most about Best?

00:08:28

Speaker 1: OC So the thing I like the most about it is that it’s really easy. So when I was like a dev, basically a software developer and then I first started learning about security, the first thing I learned was dast, and I used a free open source scanner and all I had to do was point it at my app and it started finding vulnerabilities. So I had no idea what I was doing. I didn’t know how to configure it. I like I literally knew very, very little and I pointed it at it and I found things wrong. And I know this might sound silly, but I felt very powerful. I was like, Oh, look, I know all this stuff I didn’t know before. Like, I know the secret password sort of thing to get into the stuff and, and also that I could just run it on my app without necessarily having to have access to the source code, because.

00:09:20

Speaker 2: That’s right.

00:09:21

Speaker 1: So, so as I continued working in apps, some places I went to work and Sharif, like since you’ve done consulting at a zillion different organizations, you might have run into this, but I went to work at this one org and the the security team had basically ticked off the developers so much that they wouldn’t even give me read only access to the code repository. They had so little trust there. Like you can’t even look at our code. You’re all such a bunch of idiots. But so then I could dynamically scan their apps and still find vulnerabilities and report it to them and then eventually build enough trust that I ended up getting read only access, even though the rest of the full time team never was granted because they everyone still really was not pleased with them. But I’m like, I knew and I’m not so bad. Please.

00:10:10

Speaker 2: I come in the office, the funny thing is that I started my career not as a penetration testing, not from the dynamic side. I started from the code side as a security coder. That was my first introduction into security. Unlike probably 99.9% of the people in the industry. So when I started software secure, I said, Great, that’s a differentiator we can do. But then I had the same problem is that people source code. No, I don’t want to give you the source code. I don’t trust you. Right. So one of the things I do like about DAST is its technology or tech stack agnostic. It doesn’t really matter what you’re building the application with, it is going to do a very good job whether you’re building it with PHP, with Java, with C-sharp, with with what have you. Right.

00:10:59

Speaker 1: Yeah.

00:11:00

Speaker 2: What do you like about Sast?

00:11:04

Speaker 1: I like that. It shows me exactly where in the code. It thinks there’s a problem. I like that. If so, I’ve worked out a lot of different places, which you have to Sharif. And so sometimes I work with companies. And they need it to be perfect. They need it to be absolutely perfect. They need to find every single possible vulnerability that could happen. And they want to dive down every potential rabbit hole. And so SAS can show you any potential problem and then you can sit there and kind of go through the code and follow the path and then decide for yourself or add extra mitigations if you have a mitigation. But it’s like, I don’t know if that’s the best you can add more or with a dynamic tool, it’s like we think this is exploitable, so go get it. But it doesn’t find every single part of the code. Dast only finds what you’re showing it right, Like it could miss parts. But also there’s sort of newer generation SAS where they like I’ve seen some where they do sort of anti pattern matching and they like some grep stuff like that where they’re like, we know this is bad but they, but they miss some things but they’re faster. Do you know what I mean. Like I’ve seen some stuff like that and so I’ve worked at places where they need it to be perfect and I’ve worked at places where they’re like, We need to not be pathetic. We’re trying to have like a basic for like a line of security that’s not embarrassing right now. It’s embarrassing. There’s injection everywhere. We want to go from embarrassing to respectable. We know that if, like, an advanced nation state is trying to get in, that that is a force to be dealt with. But we want to make sure 14 year olds that are angry in their mom’s basement that they can’t get in. And so it’s nice that SAS sort of gives you a choice of like, I need perfection versus it’s like only show me the sure thing.

00:12:58

Speaker 2: You know what I mean? Yes. I also like SAS because you can teach it new things. So for example, using like if you write rules, it can, it can find really complicated scenarios. So for example, let me tell you like an anti pattern. So basically I worked for a big organization that didn’t want developers to write any SQL code. They couldn’t use an arm for some reason, but they said, okay, we’re still going to write SQL statements from from scratch, but we don’t want developers to write it. So they wrote this library and they exposed a bunch of APIs. So if you want to select, call this library. If you want an update, call this library. If you want to do this, call this library. And they use the SAS to basically not find SQL injections, but find every sample, every single piece of code that is writing SQL without calling the API. Right? So that’s kind of like something cool. That task in the SAS can kind of like cover. So when would you recommend people to use Sast over that and the other way around? Like if I have to use one tool right now, what would that be?

00:14:13

Speaker 1: I think it would definitely depend on how much access you have. So I’ve worked at places where they want to automate everything, but they don’t. Basically, I don’t know how to say this nicely. They’re like all the codes in one spot. The apps are everywhere. We don’t have a correct inventory. We don’t have access to each CD. Every dev makes their own CD, and we have no no access over that. So I’ll often say what you want is sast and you want to connect it to your code repo and every new check in you have it scanned the delta like the new code, and then once a week you have it scan the whole thing. And then it doesn’t matter if the devs are participating, it doesn’t matter if the devs are cooperating, if you can get it connected to the code repo and if theoretically all the code is in the same repo, then you can finally get a look at everything. And so then I would definitely say sass because you can’t have dast just scan a code repo. Right? But if you aren’t allowed access to the code repo but you are allowed in a CD or even if you’re not allowed in the CD, you can just have a dast run every night or every Friday on all of the links that you can find. You can also use the Das to try to catalog all the different links and all the extra stuff and find more things depending upon which tool you’re using. But most of them can do kind of spider ing and cataloging and find all sorts of links that sometimes lead to another page where you’re like, Oh, that’s our app too. That’s nice. Thanks, buddy. I’m going to scan that too now. Yeah. So I tend to do it based on like what type of access and relationship they have with the software developers, I’m assuming from the security team’s perspective.

00:16:01

Speaker 2: Gotcha. Yeah. Gotcha. Yeah, I, I agree. I think if the security team is running it and they have a clear definition because they need a running instance of an application to run a Das by definition. Right. So that would be easier for the security team because now they can go to a developer and say, I found this bug, and here’s my evidence, which is something that SAS doesn’t give you. SAS gives you a potential bug while that gives you this is a bug and here’s the evidence, a screenshot or a request, a response, something. Right. The developers and the developers are running it. SAS might be a good contender because they do understand the code a whole lot better. So they would realize. They would understand what is this piece doing right away, whether it’s really a bug or not. I like dast because of its ability to be integrated into the CI CD. Kind of like before pushing to production. If I have to choose. It really depends on the stage and the maturity of the company. If this is your first thing ever, I would. I would choose a dast. Yeah, it’s easier. It’s quicker. It will tell you what the hacker would be able if they have the same tool, this is what they’re going to see. Right?

00:17:26

Speaker 1: Yes. Yes. Because any. So like when I discovered Das, I was like, wait, so any moron on the internet can download one of these for free because there’s so many free ones, they can point it at my app and then see all these vulnerabilities. And like, I feel naked like, like because, because someone on the Internet, unless you are a company that does open source, someone on the Internet generally doesn’t have access to your source code and therefore they can’t run a SAS and find all those extra things. So when they’re trying to attack a vulnerability that you found only with your last one that your Das did not pick up. That means that if if an attacker is exploiting it, it’s because they’re very creative attacker that they figured that out or they tried a thousand things and they’ve been like gunning for you for quite a while. I just realized the Q&A thing. We have a whole bunch of questions in the Q&A. Harry’s asking, What do you think about? I asked, Interact, give, application security testing. I think that it sounds pretty cool, but it’s very late in the system development lifecycle. So I’ve had some companies that I’ve worked with that have set it up, and the responses I’ve had is it’s really, really awesome if you can afford it because it’s very expensive, but the things it finds are sure things. And I’ve also heard that the instrumentation, like the setting it up, can sometimes take a really long time, but that what it finds is usually really accurate. But you don’t find it until either the testing phase or more likely when it’s in production, then it can find more stuff. So I feel like it’s something I would use in addition to test and test because I wouldn’t want to put something all the way into production without testing it a lot first.

00:19:18

Speaker 2: Yep. Yep. So let me let me explain to people kind of like.

00:19:24

Speaker 1: What it.

00:19:24

Speaker 2: Is, what it is. So we explained what SAS is static application security testing. We explain what does stage, which is dynamic application security testing. It is an interactive application security testing. In a nutshell, what it does is let’s say you have a Java application. So basically there is an agent that hooks into the GVM and through the GVM, this agent kind of looks and say it has access to the source code originally supposed to be running and it also have access to the code that will actually run. So for example, if you have a select statement that says select asterisks from table, okay, that’s the one that’s supposed to be running, but the actual one that is actually running is select asterisks from table union table. Oh, this looks different than this. There is a bug here. So. So that’s why I say to complete the picture for people. There is also another similar technology called Rasp, which stands for Runtime Application Security Protection. So think of a WAF that is very close to the application kind of thing, just to make it simpler for for for folks. So with that being said, I agree with you. It’s a little bit late in the life cycle I heard some people complaining about because it hooks into the JVM. So there is some overhead into the speed of the application. Most of the bugs are going to be found on production because it needs the code to be exercised. It doesn’t have a way. So compared to that, does can force exercise some code that passes. It can force exercise because the way a dast usually works, it kind of like scans. The whole website tries to crawl so it can force a lot of the passes where it cannot do that. So it has to task for to wait for the code to be exercised.

00:21:21

Speaker 1: Yeah. So when he says exercised, folks, he means that the app is being interacted with. So requests are being sent, responses are being read, a new requested sent with new information. And the best way for is to have that happen is actual real life usage of the app. And so you can run it during your QA phase and you can do all your QA testing and you can do all of your pen testing on it like while it’s plugged in there. And that’s nice, but that’s not real normal usage. And what you want to know is that when real humans use it, that it works well and perfectly and it doesn’t do things it’s not supposed to do. And so if you get the most usage when it’s actually being used in production, not testing phases.

00:22:07

Speaker 2: Yeah, you know, the time like when I used it and rest because they usually come together. I see. And rasp are best suited towards application that are in a dormant state where this is application wrote 20 years ago. I don’t want to change. Anything. The developers moved on. There is nothing I can do. But there is a really big bug. Now I need to go and fix it. So Ice-T is going to tell you that. Right. With a very high degree of accuracy. So you have an ROI. And to dig into the code, change it with all of the risks that comes with changing an application that is that is kind of like in a dormant situation.

00:22:52

Speaker 1: Yeah, sometimes we’ll find a bug. And the bug is such that you have to re-architect the entire application to solve the bug. And it’s like that’s going to cost $400,000, but a WAF will be like 10,000 or a rasp will be like 20,000. And you know what? A rasp looks really attractive right now.

00:23:11

Speaker 2: Yep. Yeah, it can work. It can work compared to, as you said, the cost to change one line of code literally sometimes could be could be hundreds of thousands of dollars I worked for. I helped a company that it literally costs that much, not because of the developer’s time, because they need to send a patch and that patch in testing and deployment and client acceptance and client testing, all of that cost combined, they calculated it was $150,000. I remember the number because I was shocked for changing one bug. For fixing one bug.

00:23:50

Speaker 1: It’s a big deal. Sharif It really.

00:23:52

Speaker 2: Is. I know, I know.

00:23:54

Speaker 1: Like a zillion more questions in the chat, which is really awesome or in the Q&A part. So there’s an anonymous one. I’m curious what you see companies using for DAST for cloud applications and how are they using it with cloud applications? So since I work at Brite, I’m seeing companies use Bright to test things, but I see companies using a lot of different dynamic application security testing tools depending upon what they’re doing. I would say that if you’re going to give the tool to a software developer, you want to give them a safer tool. Sharif I don’t know if you’ve ever blown something up with like a web proxy automated scanning tool, but I have acted like honestly, I have accidentally completely destroyed one production site and one still in dev site where my automated scanner is somehow gone to the admin module. It made like a zillion accounts. It deleted the database. It’s like all this crazy stuff before I realized it. And because of the fuzzier. And so I would say that companies, if you’re going to give it to a software developer, you don’t necessarily want it to have a feather in it because that can be the danger zone versus if you’re going to have it in the hands of a security expert like a penetration tester, then they can handle a fuzzier. They can use it like a scalpel and a surgeon’s hand versus a scalpel in a klutz hands. So but how are they using it with cloud applications? I in my opinion, it just works the exact same way as if it’s hosted on premises or not. You just point it at the IP address or the URL that it’s at and then you go to town. Sharif, do you have any?

00:25:37

Speaker 2: That’s the beauty about that, right? It doesn’t care as long as it talks http. It’s all good. It’s all good for a dast right. Some, like some deaths are different from each other. Some are good with JavaScript, some are not good with JavaScript, some good with API, some are not good with the APIs. But the main premise is I don’t really care as a dast. Just give me a just give me an HTTP request. I’m going to deal with it. That’s, that’s the beauty about best.

00:26:02

Speaker 1: And maybe. Maybe. So if your cloud has a web application firewall or a rasp, you might want to add your dynamic scanner to its approved list, sometimes called a wait list. So if you add it to your approved list, then it should be able to get through and actually do the testing and not just be blocked half the time by the WAF. I remember being hired to test the WAF once and I was like, knock, knock, knock, is this thing on? Because 100% of my attacks are getting through. And eventually it started blocking me and I was like, okay, okay, we got it. This is good. It’s like everything was getting through. I’m like, Guys, these are not good things. They should not be getting through to your app.

00:26:45

Speaker 2: There is there are there are two schools of thoughts here. There’s the first school of thought is, well, I don’t want to be fighting with your wife. Right. And getting over it. So just disable the life and let me optimize the time. Let’s say I have a one week test or whatever. Let me optimize my test. I’m fighting with your application, not with the math. And the other schools thought says well. What is the risk here? The risk is an attacker and the attacker is not going to get directly to my application. He has to go through the wife. So that’s a more realistic risk. So I think this is something that people has to kind of like. Just understand if we’re testing with a wife, this is kind of like we’re going to waste a lot of time fighting with the wife, but this is a real hacker would do. If we don’t have a lot of time disabled, though, after not fighting with the wife or just directly with the application and the WAF is just another layer of defense, right?

00:27:38

Speaker 1: Yeah. I also feel like it depends on the purpose of the pen test. Like is the pen test because you want to measure the risk that you’re facing as an organization and gauging how safe you are. Or are you doing a penetration test because you want to find all the vulnerabilities in your application so you can fix them and have a rock solid app. Like I’m just I don’t want to measure risk as much as I want to secure my app personally, like that’s what I would look for. But I’ve also quite frankly had companies say, Well, we’re testing you. We want to know if you’re good. And I was like, Wow, this contract doesn’t pay enough. Like, you hired me. I just assumed, like, Wow, thanks. But there’s more. I have more questions in the chat. So from someone named Thales about dast test in app, the test can break the apps performance. So I think that we need to interpret that question a bit. I’m not sure if what they mean is is while you’re running that dynamic scanner, is that going to cause latency for other people if the app is in production and being used at that exact time? And yeah, it could use up a bunch of resources.

00:28:57

Speaker 2: But that’s basically kind of like exposes a form of like an inefficiency in the application that there is some resource that is being consumed and released. It shouldn’t. Like what happens if you got a bunch of users tomorrow? That’s exactly what the dust is doing. But yeah, it could affect the performance of the application. That’s why the like I would suggest if people are doing that as part of shift left strategy test against staging if possible, right.

00:29:31

Speaker 1: Yes. So someone actually so there’s so many questions, which is so awesome. Thank you, everyone. That’s putting questions. And this is amazing because Sharif and I had a bunch of questions, but I don’t know how to say this. I like the audience’s question better. So someone says, Sorry if I’m being thick, you’re not being thick. Can we outline the differences between I asked and Dast, do you want to do that one or do you want me to do it?

00:29:55

Speaker 2: Sure. So DAST is basically stands for Dynamic Application Security testing. What that means is I am going to do the following as a tool. I am going to find all of the possible requests, methods, everything that I can talk to, the application with all of the gets, all of the posts, all of the heads, all of the deletes. And I’m going to try to find every single parameter into in those requests. So let’s say the get there is a couple of requests. The post has five requests and I’m going to try to send every single piece of payload that would throw the application off. I’m going to try to send SQL injection payloads, cross-site scripting everything. And from the response I get, I’m going to try to figure out if there is an error here. So for example, let’s say that there is a get and there is a parameter called name. In the name, I’m going to put a single code. So I’m going to try first without a single coat. I get a 200 K. I put a single coat. I got 500. Right. See, I just put a single coat, and the response from the application is different. In this case, I might deduce that there might be a SQL injection here because a single code is a very prominent way of figuring out whether it’s SQL injection. So that is very simplistic how a desk works and it works totally different. And I see is basically a piece of code that you put in a JVM or on the server. Let’s just make it simple. So this piece of code will have access to two things. It will have access to the source code of the application, the code that is supposed to run, and it will have access to the course to the source code that is actually running. And it will look at the two versions and it will say, Hmm, this looks different than this. There must be this must be a vulnerability. If they look similar. The code that was supposed to to, to, to, to run versus the code that is actually running, if they’re similar, then there is no bug. Otherwise there is a bug. I’m not sure if that answers the question.

00:32:14

Speaker 1: Though it does. There’s a bit more. So like I said earlier, I dast it doesn’t matter what technology you’re using, if it’s if it’s a web app or an API. Pew, pew, we’re going to get you. It doesn’t matter. But with a rasp, it’s very technology dependent. So a rasp will support, let’s say, Java dot net, but it might not.

00:32:35

Speaker 2: Be a.

00:32:35

Speaker 1: Trip or I am sorry, an I asked, it might say like I just do, you know, I don’t do Ruby. So then that means if half your apps are Ruby apps, it doesn’t work for you. And so there’s also, quite frankly, a price difference. I asked is because there’s only, I think, two or three providers at this point, it tends to be quite high compared to a lot of the dynamic scanners. Not that that means you shouldn’t get one, but I see a price difference generally. But it is a different thing. There’s a question in the chat, what is the difference was and asked. So I think you might mean WAAF and also a WAAF. A web application firewall is a shield in front of your application. It’s generally a whole bunch of regex like regular expressions and it’ll sit on your web server or your load balancer or someplace in front of your web app, and every single input to your application goes through the WAF and the WAF looks at and it’s like, Does this look suspect? If so, it can block or just alert you. I mean, ideally it’s blocking things and basically the tighter you you tune your WAF, like, the more things you’re blocking. You may accidentally block a business, a real business request, and that makes everyone really upset. So you have to walk like a really special line with the WAF of trying to block as many things as possible without blocking any legitimate business requests.

00:34:11

Speaker 2: It looks like Dixy was asking was as in web application scanner. That’s the first for me that I hear this this term. But so what would be the difference between web application scanner and a dast?

00:34:28

Speaker 1: Oh, so I would call that a VA scanner. I would call that like a vulnerability assessment scanner. And so tenable I think you mean Nessus by tenable if you mean that that scans your infrastructure. So that will scan your operating system, it’ll scan a container or a virtual machine and it’ll tell you, you know what you’re missing like 400 patches. And these configuration choices are suspect. And also, this looks weird. You should check that out. Like your you have sstl still enabled and you shouldn’t do that anymore. That’s old. Or you have encryption keys that are way out of date. They’re too small. Your algorithms weak, etc. And so that it’s more an infrastructure look as opposed to a web application. Look at your custom applications that you created or that you bought. You can also test like a SAS product if you have permission. If it lives on the internet, you can test it with a dynamic scanner. If it’s your infrastructure, you would use something, I guess a was. A web application like. Yeah I’ve never heard of the term was before.

00:35:39

Speaker 2: Sure. Yeah, me neither. Me neither. But I agree with you, Tanya. The only thing I might add is something like Nessus. They do check a bit of the web application, but things in the in the realm of Hey, your your application is exposing some like the Java version it’s using or exposing the web application server. Exposing there are some missing. Your ciphers the ciphers are using are weak, but it would not crawl the application. It will not within have something to log in, crawl fuzz every parameter go that deep so it’s more on Hey, these are the patches you’re missing. These are the HTTP response headers that are you leaking things like that. Less so towards the kind of like what I what we described as in crawls. Find all of the inputs, try to fuzz all of the inputs, give you an understanding of whether this is a bug or not. That level, that depth.

00:36:45

Speaker 1: Awesome. Uh, so there’s, there are so many questions, but before one rolls off the screen of the chat, so are the mean time to remediation. So how long from when we find the bug to when we actually fix the bug? Yeah, it’s a core KPI that organizations use to measure success of risk reduction. What do you personally prefer? In a sast solution one speedy scans with some or many false positives or way longer scan times with close to none or few false positives. I don’t find that that’s the way it works. Personally, I find that if a sast is faster, it’s usually doing pattern matching and it’s like I match this pattern. I’m pretty darn sure this is crap, but it has false negatives. It misses stuff. And then the ones that are longer and slower, they’ll find everything and they will have false positives. I haven’t found that a way longer scan means no false positives. What do you think?

00:37:48

Speaker 2: Okay. Okay. So that’s. So I looked into that very extensively. And Whitehat security has a very good report recently, I think 2019, 2020, something like that. And you will find the mean time to remediation in sast. Lower than the meantime remediation to that, but that’s not the whole story. The actual time to scan is nothing compared to the whole time. Meantime, remediation because the longest scan will take a couple of days. Three days. Right. But industry standard is the mean time to remediation. An average vulnerability is about three months. Right. So that scan, whatever is a couple of hours, a couple of days, that’s nothing compared to the total number you’re looking at. The most amount of time is lost in reporting, getting things fixed, retesting, confirming it’s closed. That’s where you need to focus your time, not the actual technologies. Both technologies are probably going to give you good. Meantime, it is just where are we losing time? It is not in the scan. It’s somewhere else. So that’s that’s what I would answer to that one. The reason that I think I, I suspect that in in white hats report SAS was much lower is because developers are running it so it is faster to get back into their workflow. And that was longer because security teams were running it and they have to hop multiple times to get it into the developer’s workflow. If you can get this passed into the developer workflows, we’re going to see a closer number, I suggest, because it’s not if there is a delay, it is not because of the scan time. It is because of the time it takes to report it, get it fixed, retest it right.

00:39:42

Speaker 1: I would like to note that I agree very, very strongly with Sharif about this. It’s so true. And and it will be the security team. They email a report to the devs. The devs get it. They’re like, What the heck does this mean? And then they call a meeting with the devs that takes like another week and then they’ll go over the report. And sometimes the security people just confuse the devs more than is necessary. In that meeting. I’ve seen a lot of like doom and gloom. We’ll all die if you don’t fix this right now. And then and then the devs have to schedule it because they actually have another job other than just fixing things we ask for. And so then they have to try to fit it into the whole stuff they’re doing and then the retesting and actually getting release and release isn’t 100 times a day at every single place. Like I know Etsy and Netflix and fancy companies. Like they’re like, Oh, we release like 20 times a day. I’m like, That’s awesome. Almost no one else is able to do that. A lot of places release every two weeks or even every three months. And so then you could be, you could be waiting forever to get those fixes.

00:40:44

Speaker 2: Yeah, there’s a question, a question here that is I’m not sure if it’s a real question or not, but I’m going to answer it anyway. I’m curious what the pen testers were doing to upset the devs that much would like to avoid doing that in the future. So because I have, I work in a pen testing as a service shop, so I know that quite well. And the truth is developers spend a lot of time building, they are trained to build and we paid testers are trained to break. I’m sorry, that’s the way it does. So imagine yourself building something for a month and I just look at it for half a day and I just tore it apart. How would you feel? Right? Not great, right? How can you help? The way you are introducing that to the developers makes a lot of sense. There are some pen testers that come across and say and just kind of like boast, Oh yeah, that took me half an hour. It doesn’t make it doesn’t make anybody good, right? Building is much easier, as much harder than breaking, let me put it that way. Right. The other thing that the best pen tester will come across saying here is the bug and here is the fix. What else can I do to help you? Right. Yes. So you’re going to get a listening you’re going to get a friend, not an enemy on the software development side of things. What do you think, Tiny?

00:42:03

Speaker 1: Oh, my gosh. So much. I also want to add that sometimes. So if you’re an external penetration tester and you’re coming in and you’re delivering bugs, being humble is important. Like, Hey, I found something. Can we talk about it? Like, here’s how I would suggest fixing it. So, like, no arrogance, no one wants to hear your baby is ugly and I don’t like your baby. But on top of that, sometimes security teams like I’ve come into places where there’s a lot of tension between the devs and the security team and it’s often from not awesome communication. It’s often like security policies that aren’t based in reality. Like I’ve seen I’ve seen secure coding policies where they’re like, developers shall never write insecure code. I’m like, Well, that doesn’t make sense. That’s that’s not impossible. And it’s.

00:42:57

Speaker 2: Impossible.

00:42:58

Speaker 1: Right? And, and sometimes I’ve worked with security teams where they’re like, well, these devs just research crappy code if they just tried it all because it’s so easy. Actually, it’s really hard. It’s really hard to write perfectly secure code if you don’t have a bunch of tools checking and helping you. Like, imagine writing an entire book and never having a spell checker and then someone saying, Oh, you made all these spelling mistakes and typos are so stupid. It’s like, No, we have to offer support to them. They have to have as many tools as we can give them to help them. And then we need to have a second set of eyes on that to find things that are missing. And so sometimes when a security team will say, like, just patch it, it’s not that hard. And meanwhile you have to actually to update that dependency, you have to update nine other dependencies, and that means you have to change these codes and that function’s no longer available, etc.. It’s because it’s.

00:43:51

Speaker 2: Coming from retest and retest everything again. And then the field, if your customer might find other bugs to think about. All of that is not just one line. It’s all of what’s kind of happened after that one line, right?

00:44:06

Speaker 1: And I think it’s about a lack of experience and a lack of empathy because they don’t have that experience because Sharif and I were both devs, we’re like, Oh yeah, this looks like a ton of work, you know, how can we add this to your project scheduler? Because we’ve been there. But when a security person who is an expert at networking or at firewalls or at like peak PKI, like other areas of security and they’re like, just patch it, it’s like that’s I don’t want to say it’s an arrogance, it’s an ignorant statement, and it’s not intentionally ignorant necessarily, but sometimes I think they imagine devs are sitting there and there’s like an upgrade button and they’re not just not pressing the button. It’s like, no, of course they was just pressing a button. Of course they would press the stupid button.

00:44:52

Speaker 2: A lot of work. A lot of work. All right. Which question do you want to take on next?

00:44:58

Speaker 1: So there’s one question. Who is the person responsible for Dast? And I feel that this really depends like when I was a software developer and I switched to security, I started doing pen tests and I would do like manual testing and stuff, and I owned the desk. But then I realized there’s 150 of them and one of me. So then I started teaching a bunch of them to use it, just the basic desk. And I’m like, You don’t need to do super complicated things. Just run the basic scan. And if you find a high or a medium, fix it and I will come give you a high five at your desk and tell you you’re awesome. And, and that was great because between all of them, we got everything scanned. But if it was just me, I’m like, This is going to be a while, guys. What do you think? Sharif, who owns the last?

00:45:48

Speaker 2: Historically, it was a security team for a bunch of reasons. One that was their job, mainly to run the desk. That’s it. Right to the developers. There was nothing called integrate security into a software development lifecycle. Like what is that? Right? Plus, the tools were really hard for developers to use. They were clunky, they needed a server to run on. It needed kind of like a few days of training, etc. came a bunch of tools, including Bright, that made it super easy for you to to run a DAS, to integrate it into your CI for developers to use it. Plus a normal a regular developer now is expected to know at least what OWASP top ten is like, what a SQL injection is, what across five years ago, ten years ago, that was not the case, right? So it needed a special breed of people, if you will, that runs the best. So. So now anybody can run it. Really? In the software development organization yet.

00:46:50

Speaker 1: Yes. And then that that can lead to interesting results. Like I’ve seen some secure some software developer teams where they’re like, give me that. And they like run away with it and they’re like, This is my tool now. And then they start sending me really nice code and they’re like, that SAS tool, It’s mine too. I’m like, Yes, this sounds great to me. Yeah, Not that I don’t want to have a job anymore, but I’m really pleased about that. Oh my gosh, there’s so many different questions. Sharif, do you want to pick the last question? Because we’re running out of time.

00:47:25

Speaker 2: Sounds good. How about this one? How much of coding knowledge is required to be an app specialist coming from an infrastructure side? I want to know this. Okay, So think about it this way. Who’s your customer?

00:47:41

Speaker 1: Right. Your customer is a software developer.

00:47:43

Speaker 2: Exactly. So if you cannot talk the same language as your customer, then it’s going to be a problem. Now, we do not need to be a developer. That’s the that’s kind of like the problem that people run into. You just need to understand what is this piece of code is trying to do. You do not need to write one. Right. You do not need to write the compiler code to be a Java expert. You don’t need to know all of the APIs, all of the function calls. You just need to be one. Not afraid from code, because I’ve seen a lot of security specialists that when they see code, they’re like, No, no, no, I don’t want to see that. Well, you have to break that barrier. That’s one thing. The second thing is you read the code, try to make your best guess and have a conversation with the developer. That’s what you need to do, basically.

00:48:29

Speaker 1: I would also say I would say that it’s really important that you understand the system development lifecycle at your organization. So every organization does it slightly differently. So some people, they do like a very strict waterfall model. I saw a place once that did mini waterfalls, so they had six waterfalls because their project was a year and a half long and they would do like the whole thing six times. And then there’s places where they ship code constantly and they’re doing DevOps and that’s awesome. There’s places where they’re like, Well, we have a scrum meeting every morning, but then they just do waterfall and they call themselves Agile. So what you need to do is know the way that your software developers are releasing code and figure out how you can fit some security stuff in there without pissing everyone off. That’s really important part. It doesn’t mean that there’s never going to be friction, but it’s really important you figure out the way that they’re working and then how you can add security into the way they’re working. And so if they’re doing very strict waterfall, you know, you could go to the project kickoff meeting and say, Listen, in our schedule, I need to have time to hire Sharif to come in and do a secure code review. And then we want them to come in again and do a pen test. And we also have this list of security requirements for you that we want to be included in this project. Like you’re building an API, A plus. I want you to use this gateway. I want you to do this, I want you to do that. And so if you can especially be right at the beginning of the project and tell them your expectations, the end of the project’s going to be a happier time for you than if you show up at the end of the project and you’re like, Why didn’t you do this stuff?

00:50:16

Speaker 2: So yeah, so basically forget about what are you following, Agile or waterfall, this, that because in a lot of cases you’re not doing what you say you’re doing. Like what Daniel mentioned Agile and you’re doing for or for Waterfall and doing Agile. Focus more on the actual activities that the software development team are actually doing and try to. Patiently inject security activities in those.

00:50:43

Speaker 1: Yes. So I have a question for you. Can you tell us a little bit about Reshift? Could you just tell us a bit about it?

00:50:53

Speaker 2: So Reshift is a static code analysis for security, and it’s meant for developers to use it. And why? The question I get all the time is why does the world need another set of code analysis tool? What I have seen. So basically my time at Wells Fargo, this is all what I did. As I said, I started from a code review, so I was using one of the the enterprise tools a lot. And this is not a tool that anybody would enjoy using on a daily basis. Me as a security professional, I did not enjoy it. So how would a developer enjoy it, combined with the fact that if we can integrate fast, accurate checking of some sort in the development lifecycle when the when the developers are writing, that would be awesome. The problem with traditional static code analysis tools is they this is very simplistically how they work. They read all of the source code. They draw a big giant graph in the memory and they use the rules to follow that graph and try to find a relation between the source and the sink. And that would be a bug, right? The problem with that model is as the code is slightly bigger, that giant graph and the memory gets exponentially larger. Right. That’s why literally the tool that I was using cost the organization that I was working, I’m not kidding, $1 million a year. And it would run out of memory scanning JavaScript because a tiny piece of JavaScript, because of the lack of typing and the lack of a bunch of things in JavaScript would lead to a gigantic graph. And in reshift, we are not doing that. We shift work. What we’re doing is taking the same data that would have been thrown into the memory and creating a database like structure with it. So that database can grow very, very big. It doesn’t matter because we know how to work with really large databases, but we do not really know how to work with really large blobs in memory. So we take that data, put it in a database, and this data becomes variable. We can query this data and find exactly what we’re looking for and the rule becomes a query. So think about it this way We take the data, put it in a database like structure, and the rule becomes a query to ask the database questions about, Hey, does this method have any sync, does this sync has any source and things like that? So it’s much faster, much more accurate than traditional traditional static code analysis tools. I hope that helps.

00:53:38

Speaker 1: It really does. And also much faster and way fewer false positives. That helps.

00:53:45

Speaker 2: Yep. Yep.

00:53:46

Speaker 1: So I’m going to obviously tell you about right now. So Bright makes a dynamic application security testing tool and some of the things that really separate us from others is one, we are fast but to we have almost no false positives because basically we do a scan and we find a bunch of stuff and then we do a separate different tests to validate every single result. And if the second test doesn’t work, we don’t report it. And so with that, we’ve managed finally.

00:54:20

Speaker 2: Yeah, because here’s what pissed me off from regular test, right? So for example, this is a very if anybody ran ran like any dust would know this. You’re running a scan. The scan takes a few hours and then 99%, you will come up with a SQL injection that used a weight. To confirm it. Right. And basically what that works is the SQL injection sent a wait, like a delay. Right. And the response came back later than it should. Yeah. Because you’re sending 10,000 requests to the server. Then you just try that again and make sure no doesn’t I have to do that. So I tool that does. That would be amazing.

00:55:03

Speaker 1: And the other thing that we do is we do security unit testing and so this is new and we just started doing it for JavaScript and we’re building it out into all the different JavaScript frameworks. And so basically you can write a unit test that’s empty and then just take that unit of code. So like let’s say it’s doing an input, so we’ll give you a payload that goes into it and so we’ll spin up up to 100 unit tests at the same time and we will run our dynamic scanner against that small unit of code for you. And it’s pretty cool. And it just came out literally like three weeks ago and Akira did a workshop on it occurs in the chat and it was so amazing. But I know I’m supposed to wrap up now.

00:55:47

Speaker 2: Sharif I wanted to say.

00:55:50

Speaker 1: I know I’m going to just as a spoiler. I’m going to try to invite you on the Hack Purple podcast just to like, can I have you back? Because this was such an amazing, amazing conversation and it was so fun to have my friend on my webinar.

00:56:05

Speaker 2: Thank you. Likewise. Likewise, Tony, and thanks for everybody who posted questions. These are amazing Question As Tanya said, we had questions, but these are much better.

00:56:14

Speaker 1: I don’t know. I know. Yeah, these questions. Honestly, I’m like, I could write 100 blog posts with these questions. I want to save all of them. Thank you so much. Sharif Kooser from Software Security and Reshift for coming to the Brite Security Webinar. Thank you for everyone at Bright that did all the support that makes me and Sharif look and sound beautiful. And thank you. You all the people who attended. Oh my gosh, you guys made this amazing. All of you. Thank you so much.

00:56:44

Speaker 2: Thanks, everyone. Thanks, Bright. Thanks, Tanya, for having me.

00:56:47

Speaker 1: Great. See you all next time. Bye.