Build Secure Software, Like a Boss

00:00:00

Speaker 1: Hi, everyone. I’m Tonya Janka and I have been a friend of Brite for quite a while. I met the Founders right before I started. We had Purple, and then after a while I came on as a technical advisor and we’ve done a whole bunch of workshops together and talks. We built a course together. So we’ve done a lot of stuff together, including this webinar. And so I want to talk about building secure software. And I added like a boss because I think I’m funny. OC Next. So where are we going to talk about today? We are going to talk about why Insecure software is a problem. I’m sure that all of you have seen lots of things in the news about cybercrime, etc. but I’m going to tell you a bit more about it. Why you specifically you listening and watching right now need to secure your applications. And then we’re going to go over a secure system development lifecycle. So this might not be your secure system development lifecycle, but I’m going to give you basically a bunch of different things that you can do in every phase of the system development lifecycle to make sure that your apps are secure. You don’t have to do all of them, but I hope you do some. And then I’m going to give you a bunch of things you could go and do right now. And part of why I wanted to do this talk specifically with Brite is because the first thing that I suggest and I’ve been giving variations of this talk for a long time, but the first thing I suggest is you hacking your own app. So we’ll get into that more later. But for now, this is what we’re going to talk about. So, oh, and then I always give free resources at the end of every talk, and then I will invite you all to the We hack purple community if you’re not already a part of it. I recognize a bunch of you. So yeah. So who am I? I am Tonya Janka. I am a gigantic nerd. I am a technical advisor at Brite. Like I said before, and Brite used to be called neural legion. They just changed their name. So if you’re like, Who’s bright? They used to be called neural legion, so you probably heard me talk about them before. So I’m the founder of We Hack Purple and I’m the CEO, but I really prefer to say head nerd. But whatever I’m known as she acts purple. Some of my hair is purple. I wrote a book about OPSEC because it’s very important to me. And I am I’m an advisor at a bunch of companies now, and I’ve worked in tech a really long time, like what some might say forever. And basically I am a giant nerd on the Internet. Oh, okay. So that’s just going to show up, really. So I’m using Google Slides for the very first time. Oh, thank you, Mark idea. This is my first time using Google slides, so forgive me if it’s a bit kind of not perfect. I’m getting used to it. So let’s do this high fives. Okay, So I want to tell you a little bit about the current state of affairs. And I know some of you because you told us what you do. You work in apps, so some of you are going to know most of this. But I want to make sure if anyone’s new that we’re starting kind of at the same level. And also maybe there’s some stats you don’t know. So I’m just going to tell you a few things. It’ll be like 2 minutes and then we’ll get into the good stuff. So first of all, everyone’s getting hacked. Oh, this used to say getting people will say, yes, they’ve been hacked, that they got hacked. And that is such poor grammar. But despite the poor grammar, if we could put that aside because I really like good grammar, there’s lots of vulnerabilities that are out there being exploited by malicious actors. A thing you might not know is that 29 to 40% of all data breaches are caused by insecure software, and this includes APIs and the Gartner or sorry, the Verizon breach report every year since I’ve been reading it. So I started reading it in 2015 every single year. Top placement for causing data breaches. It’s insecure software and last year they’re like, Oh, let’s change it up a bit. We’ll have web apps and APIs as two separate categories. Guess what? Now we’re number one and we’re number two. And I was really hoping that’s not what would happen. And so if you look at your budget for your security team, you will notice that 26% to 40% is not how much is going towards securing software. And I think this is part of the problem we’re seeing. Another thing is I see a lot of security teams, so they’ll have 20 people on the team, but only one is for OPSEC and the rest are doing enterprise security. So like web filtering, email filtering, you know, not letting people have admin privileges. And we’re doing awesome as an industry at that. There’s people where they’re doing the firewalls and they’re doing network security. And I have to say our industry is doing pretty awesome at that too. But when it comes to OPSEC, our industry, we don’t have enough people doing all the jobs. We don’t have enough people with that deep knowledge of how software is built and it’s a problem. So what the heck is application security and why is Tanya color OPSEC? It’s because it’s too long. There’s a lot of syllables there. But what is it? What am I talking about? So any or ever. Every single thing that you do to try to ensure that your software is secure, that is application security. Some of it can be very formal as part of a security program, but some of it can be informal. So if you are a software developer and you start listening to a security podcast and you hear, oh, there’s the vulnerability and this framework that I’ve been using, I’m going to go to work and check if we’re using that version. And you’re like, Oh, no, one of our apps is using that version. We should upgrade off of it because there’s a big vulnerability in it. And right now it’s being attacked by malicious actors. That is you fighting the good fight with us, me and Ali and everyone else who works in OPSEC. That’s you helping secure the world. Seriously, it’s a big deal. Every person that kind of puts their hand in and tries to help, we need all of you. And so application security can be very formal. It can be a secure system development lifecycle that we’re going to talk about. But it’s also all those informal things that you do. Anything to just try to make sure your software is secure. Oh yeah, I said that. Okay, so more things, so current state. So when I was a software developer, the first job I switched over to was penetration tester. And I have to say I would get called in at the very end of the system development lifecycle. They’d be like, We’re going live in two weeks, and they’d been working on it for a year. And I come in and they’ve had no security requirements, they’ve had no design review, they’ve had zero training, zero guidance, and they’ve just been coding away, working really hard and ensuring that it meets the requirements. But there were no security requirements there and all the testing and user acceptance testing was all not focused on security. And then I come in and I would love to tell you that I was the best hacker and I was a total badass, but I was not. I was total middle of the road. But I would find so many things wrong because I was the very first person who ever looked because there had been no guidance and no assistance for the devs because there have been no testing before me. And so I would look really smart. However, like very quickly I started saying to the devs, Hey, I know I’m scheduled to come in in two months, but could I come in sometime this week? And I’ll just do like some quick scans and update you on a few things and we’ll just talk about your architecture a bit. And I might point out a few things and then I’ll come back later and I’ll test for real. And basically I was starting security earlier and the system development lifecycle because I’d been a dev and I’m like, why are we why are we telling them at the end? Why don’t we just tell them as soon as we know? And it turned out that that is a job called OPSEC, not penetration tester. And so I switched jobs into OPSEC. But the point of the story is that if we just do penetration testing at the end, we’re spending a lot of money and we’re not necessarily getting the best value for our money. This is the CIA triad. When I show this to a room full of software developers and I say, Who’s seen this before? There’s usually like one or two hands at the back and they look really unconfident and they’re like, Oh, I saw that one time out of meet up. So. So basically, security is really good at keeping secrets and we are not very good at marketing. We need some lessons from the marketing people because we need to get the message out that it is our job and it is our mandate to protect the confidentiality, integrity and availability of all the systems that we create and maintain in all the data. That’s our job. That’s why we’re hassling all of you nice software developers and ops folks, because it’s our job to protect the CIA. And when I’m showing it to people and no one’s seen it before, that makes me really worry. So you’ve probably heard of shifting laughter, pushing laughs. So I talk about this quite a bit. All he talks about it. All of us security folks were really obsessed with this idea and what it means. So this is the system development lifecycle. So whether you’re doing DevOps and you’re going like this, I don’t know if you can see the infinity sign. If you’re doing Agile, you’re doing tons of little circles and iterations on this, or if you’re doing Waterfall, you’re doing one big thing and then boom, release. It doesn’t matter which way you’re doing it, you still need requirements, design, code testing, and then the fun part release. What it means to shift left is if you imagine there we go. If you imagine the system development lifecycle written out on a piece of paper, the further left that you go the earlier you are in the system development lifecycle. And what it means is that US security folks want to be invited to the party earlier. I want to meet you in your kickoff meeting and tell you I’m your person. If you have a security question or need or anything like that, you come to me and I will help you. And then when there’s requirements, I’m going to add requirements. When there’s design, I want to do more stuff with you. And the idea is, is us security folks, we don’t want to come and spend. At the end and tell you you’ve made mistakes, then we want to tell you at the beginning what we need from you, and then we want to help make sure you can deliver that. And so shifting left, part of part of the reason we do it is because then you can build better software, but you also you save tons of money, you save tons of time. And when you fix things last minute, it’s not always a beautiful fix. I’m sure anyone that writes code knows that sometimes it’s a bit of bandaids, duct tape and hope and a prayer. And so if you design it secure from the beginning, you’re just building tougher, more rugged software. And so whenever someone says shifting left, that’s what me and all the other people are talking about. So that was the intro. And so now I want to get to the real stuff. So like how do we build secure software and then see her cap like a boss? I looked all over for this picture. I’m like, Yes, so how do we do that? And the answer is, you follow a secure system development lifecycle. So this could also be called an application security program. It depends on how you want to word it. But the idea is, is that every single step of the system development lifecycle, there’s one or more security activities. And the idea is, is that every single new project does that. And if every single new project does the same steps, then we know we can have a certain security posture for our entire organization and we can I don’t know how else to say it, but we can win a lot more in the security space. Also, it might sound weird, but you also end up spending less money rather than having emergencies at the end. And so that’s what we want to do. We want to follow a secure system development lifecycle. So the formally the formalization of security within how we build software, let’s go pressing next, hoping Google slides is going to get what the program. Hmm. Okay, totally clicking the next button. Let’s do it. OC There we go. Come on, come on. Google slides. We can do this together. Yay! Sorry. I’m in a hotel in New York City right now, and so I have to just bear with them in their Internet so we can do this. So the first step of the system development lifecycle is requirements gathering. And I want security requirements. That’s what I want. Will I be able to jump up in the air above a bunch of mountains and do that pose for you? Probably not, but I can provide tons of security requirements so whenever I start a new project so you do not have to read all of this, don’t worry. And if you want to actually you could get a PDF from me and Ollie after with this and more. But whenever I start a web app project I give them a huge list. Well, not a huge list. There’s like 12 or 14 things on it of security requirements for a web app. I have a list for APIs too. And so if we look at the first one, encrypt all data in transit at rest, use the latest version of TLS as per the encryption policy of your organization. Again, I’m not going to read all of these, but the idea is, is giving specific actionable things to software developers so they can make sure what they build is secure. If we don’t give them any requirements, how can we expect them to actually do the things we want? So we start at the beginning. Then the next is secure design. So I could do that pose. I know that yoga pose. I have to find a rock and a waterfall and all of that, but I could do it. So now you’re in the next phase of the system development lifecycle and you’re in design. So what could we do to make our design more secure? So first of all, we could start with doing a whiteboarding session. So you just have basically a security person like me and then you have the software architect and maybe you want to invite other people, maybe you don’t, and you just draw out what it is. Okay, so you’re going to have a front end. Awesome. That’s here. And then you have three APIs, cool lines there, and then, oh, some of those APIs call this database, some call that database. Cool. Oh, and then there’s this cool serverless app that does this and you draw it all out and then the security person just starts asking questions like, Oh, is this encrypted from here to here? How do you know that you’re talking to your API and not someone else’s API and you just go through it and and you just talk it out and then you end up finding some holes and the security person helps you fix them. The next one is, Oops, okay, well, how can we make all software architects, also security architects? Gabrielle You send them to the security school, I guess. But I mean, I am working on some stuff on that, but I digress. So another thing you can do is learn secure design concepts. So I have this new talk I’ve been doing at conferences where I present like six of the main secure design concepts, and we just talk it out as an audience and go through it. I’ve been giving this as part of the training for a long time and I’m like, I’m just going to make it free for everyone. But you just talk about the concepts and if they. Apply and how can you apply them when you’re designing threat modeling? So threat modeling is super fun. It’s basically a brainstorming session where you’re evil, so evil brainstorming. And basically you talk about everything that could go wrong. You a security person, you want a software developer and you want the product owner or some sort of representative from the business. Like what keeps you up at night? If you were going to hack your app, how would you do it? And then you write down all the potential threats and then you figure out mitigations for them and that’s it. You just write it out. Oh, and then the next one, I have secure coding standards, but actually let’s skip that one because that belongs in the next section. I think that that’s too early. OC Giving them security reference materials. So this could be books. I have a bunch of architecture books and some of them touch on security and so just provide some books that help them. OC Oh, and training, always training. So these are just some of the things that you could do during your design process to make it more secure. K, next slide. Oh, right. There we go. So the next one is secure coding. I love this tree. So what can we do for secure coding? First of all, you could generally practice secure coding practices, right? Like we know we’re supposed to validate inputs. We know we should use stored procedures or other sorts of parameterized queries rather than doing inline SQL. But you could also make a standard for your organization. Another one is you could create unit tests that actually test security. And so that’s a newer concept that I’ve been talking about for a while. And there’s some exciting news from startups about this that all he’s going to tell you about later. But basically this is a thing that is starting to become more accessible rather than you having to write them all from yourself. Soon there’s going to be templates for you to have code review. So I know that a lot of people don’t feel code reviews. Very sexy, but it’s actually super important. Like when you try to review your own code, it’s like reading your own resume for the 400th time and you miss a typo because you’ve read it 4000 times. But having someone else review your code for security issues, they’re much more likely to catch something than you. There’s also creating secure coding practices or guidelines, secure coding, training and other education around that. So there’s all sorts of cool things, like there’s cyber rangers, there’s ETFs, there’s secure coding types of interactive exercises. You can create a secure code library and templates and other things so that basically a secure coding library is where you have code that’s already been tested and just battered upon by a pen tester. And then you reuse it in various places. So let’s say you have to have a login screen. You write that once and get it tested like over and over again, and then you send out that fix to all the different apps that have a login screen. So you reuse known good code, ID plugins. There are so many cool ID plugins that can help you with security now if you aren’t sure. Open up your ID. So whatever it is that you program in all day and then look up extensions and just type security or type DAST or SAS or SCA. We’ll get into some tooling in a bit, but there’s so many things that can help you with this directly in the thing that you program all day. Oh, look, I made a list for you. Yeah. And renting. So the next one is security testing, and this is why Ali is here and he’s going to talk to you more about this. But I like how like the person’s like super powerful. Like, yes, security testing. So in the testing phase, obviously, we should also be testing security. Right? User acceptance testing, super high priority. But I feel security testing. To me it’s the same priority. It’s equally important for me and I know I’m super biased because I do security and I love security, but I think it has the same importance as all the other types of testing. Because if your app is beautiful and it does every single thing the client wanted and it’s fast and you know, like it’s got all the features they asked for, but if a malicious actor can hack in in 5 minutes. It’s not awesome. So security testing, what are there like four types and options? So the first one is dynamic application security testing. So this is where your app is on a web server or container somewhere or a platform as a service in the cloud and it’s running and then a tool automatically scans it and interacts with it, like sending requests, reading responses, updating it script, attacking again, and it tries to find all the possible vulnerabilities. We’re going to talk about this more about it’s one of the things that you can do at home as a dev. The next one is static application security testing. So this is something you can also do, but you need a bit more training, I find to be able to get good results, but I still feel it’s an extremely valuable activity. Software composition analysis. So this is much easier than Sast and it checks all of your third party components. So sast the second one, it checks all the code your team wrote. Well, SCA checks all the code that you included in your app, but you didn’t write. So libraries, frameworks and you get packages, Ruby Gems, all of those things where you didn’t write that code, but because it’s part of your app, you’re still accepting that risk. And so it’ll tell you ones that aren’t very good and maybe you should update. Another thing is security unit testing. So again, you want to run your unit tests before you check in your code every time and you want to make sure you pass, not just check your code in any way. And so some of those tests should be security unit tests, code review. You can still do code review during security testing. So if you end up finding vulnerabilities for the other things before you check it in or when you check it in, ideally someone will review the changes you made and look for potential security problems or just you know that you’re meeting your regular code quality standards listing again listing. Let me explain what that is. So listing is sort of like the grammar police for your code. It makes sure that you’re following the letter of the law when it comes to your framework and your language. So there’s no poetic license in how you’re using it. It’s like you’re not doing it the right way. You have to do it Like this listing is important because it helps avoid ambiguity or letting your app fall into an unknown state. And whenever your app falls into an unknown state, that is where hackers and vulnerabilities like to spend their time. Penetration testing. Yes. So penetration testing is where you hire a security expert and they take a whole bunch of tools so they’ll have a dynamic scanner, but they’ll have all sorts of different tools and they will manually test your app and they will spend like days or even weeks on your app interacting it with it, just like trying to punch it in the face as much as they can to find every single potential vulnerability. This is different than just running automated tools, but it’s also way more expensive and time consuming. So you usually only get to do this one time well with the others. If you buy the tools, you can just run them every time. So the fifth and final one of the system development lifecycle is deploy, release, maintain. So these are all kind of crammed into the same phase, the fifth phase. So deployment is part of this, which means CI, CD pipelines and all the DevOps people are like, Yes, and releasing it and then all the project managers are like, Yes, and then maintaining it and then all the ops folks are like, Hmm, if we do a really good job maintaining it should be easy for the ops folks. So what do we do when we’re doing this? So we want to do security testing in our system. So if we’re going to deploy this over and over again, especially if you’re doing Agile or DevOps, you want to have automated testing so that you’re not just repeating boring manual work all the time. You want to have logging, monitoring and hopefully alerting on if there’s vulnerabilities or there’s something going on with your app. It looks like it’s being attacked. This is how you catch when something bad is going on and it helps you improve for next time. Ideally, even if you’ve released it and you’re not doing new bug fixes, I still personally absolutely continue logging, monitoring and alerting and I continuously do security testing still. So I’ve automated scans run at least once a month to make sure that nothing new has come up. And I know that might sound weird, but you can still find vulnerabilities because your apps so apps don’t age like wine. They don’t get better and better and better if you are not updating them and fixing them and improving them. They age a bit like cheese in the sun. It’s not good. And so we want to continually test to make sure that they continue to be good. So advanced things. So these are more advanced things that you might do if you need a very high level. Of security assurance. So the first one is bug bounties. If I could get it to show up on the screen, we can do this. So coordinated. Let’s do bug Bounty and then I’ll go back to coordinated disclosure. So bug bounties is where you have a copy of your system and you invite security researchers to test it for you. So this could mean anyone could come and test it, and that would be like a public bug bounty or you more likely to have a private bug bounty that you’ve arranged with some sort of company that brokers these sorts of deals and helps you organize it. And they will also help you triage because so the thing they don’t tell you with bug bounties is you’ll receive a zillion reports and a lot of them will repeat the same thing over and over, and they’ll test things that are out of scope and they’ll have reports that don’t make sense. And so having someone triage that is very valuable. But I feel this is an advanced things. You should only do this if you’re already doing a whole bunch of other security activities. You don’t want to pay 500 or 1000 for a cross a scripting bug that you could have found with one dast scan. So you do a bunch of scanning and testing on your own. You fix all of those things and then you do a bug bounty if you need a very high level of assurance. So. Oh, there’s a question. So you’re saying that we that should be on a copy of the system. What if you don’t have that? And what’s to stop the bug bounty hunter using their skills on a real site? So when you run a bug bounty program, generally you give them a copy to run it on because they’re doing tests that can be destructive. Right? And you’re giving them express permission to test if security researchers are doing testing on your site. If any of it violates the terms of service, you can sue them. You can call the police for real. A lot of people do that. Sorry, I don’t know why, but my voice is being smeared. So what’s to stop the bounty hunter using their skills on a real estate? Well, ethics and the law. Some of them still do that. When I worked at a place that I won’t name, we had a lot of people do account takeovers of our customers and then try to send it to the bug bounty and be like, I want money. And we’re like, You attacked our customer. You’re a jerk. No, I’m not going to give you money. First of all, you broke the law. Second of all, you broke the terms of service. Third of all, you ticked off our customer. First of all, you think we’re going to pay you for that, and it’s in the scope that that is not allowed. And so there’s a lot of people that aren’t very ethical on the Internet. And I don’t know what to say about that, but I don’t call those people bounty hunters. I call them something else, criminals. I’m just trying to be honest, but they’re not supposed to do that. And it does happen quite a bit where they don’t follow the scope. And so that is another risk of doing a bounty program. OC Coordinated disclosure used to be called responsible disclosure, and this is where basically you give people a way to report problems to you. So I actually did a thing with Brite where like there was this bank and I was doing some things and I found a problem and some of my friends at Brite knew them and I was like, Listen, I want to report this. And they’re like, Well, they have a coordinated disclosure program. TONYA So why don’t you just report it through that? And I was like, Well, thank you. That’s exactly what I should do. Okay. And I did. And they thanked me and they didn’t sue me. And that is the point of coronate disclosure. It’s like, please tell us about the problem so that we can fix it and we’ll take it seriously. And the last one here is Red teaming. So a lot of people ask me, why is it she hacks purple? And that’s because I started doing red team things and then I switched to Blue team and I keep kind of going back and forth and thus purple because red and blue make purple. So blue team are defenders. Every time you patch something or you follow secure coding guidelines or you do something to make sure your app is secure, what you are doing is blue team you are defending. But when you do offensive security and by that I mean pushing boundaries, trying to exploit things, doing penetration testing, attacking that is red team. And so when I say offensive security, I don’t mean that you like call people names. I mean specifically that you are on the offensive side. So you are trying to figure out all the real risks and pushing the app to its absolute limits. And so that is red teaming. OC So at this point of the talk, it is my hope that you want to build secure software. I mean, you showed up here today and there’s a lot of things on the Internet or off the Internet that you could have been doing instead, but you decide to join me and Allie. And so I want to tell you how you can take steps right now and go and build secure software. Okay, let’s start. So the first thing is. Test your app tester app. And so you can’t necessarily do all the tools. But the one that I usually start with is called Dynamic Application security testing. So I advise that everyone do this one first for a few reasons. When there’s a bunch of them on the Internet where like the companies let you use it for free, so they’ll let you run X number of scans or X number of hours or whatever. And basically, like you can get a really high quality tool for free for you to just test your app a few times. And for Sast and SCA, there’s not a lot of good ones that are free. And by free I mean like you can’t use it at work every day for your entire team for free. But I mean, like basically for you to go and start learning this stuff, it’s free right away. And so I think that’s important if you’re going to try things. The next reason I start with Dast is because it’s really easy. I know maybe I’m not supposed to say that, but I find it really easy. Like right away I was able to just be like Pew, Pew, pew, pew, and then I found all these vulnerabilities and I felt really awesome about it. And I was like, Yeah, I fixed my app. It’s awesome. And so because it’s easier to use than a lot of other tools, so like a static application security testing tool, like you’ll get tons of false positives. It takes a long time to even understand what the vulnerabilities are. And I’ve just always found that easier. And then the third reason. Oh, that’s a great question. Okay. Okay, there’s two awesome comments, but I’m just going to finish this thought. So the third reason is because so when your app is on the Internet, anyone can point a dynamic scanner at it. Anyone, if you have really good alerting and maybe you have like a firewall and all these other things, maybe you could push them away. But a lot of companies don’t have those things and so anyone can point it and then find those same vulnerabilities. They don’t have a copy of your code usually, so they can’t do SCA or SAS. They don’t have access to your web server unless something’s very wrong. So you can’t do is asked Rasp. So this is the one that anyone can do to you. And so for me, those make those vulnerabilities higher priorities. So David mentioned some graphs, so I happen to think some graphs. Awesome. So some graph is a very new type of SAS that’s very different and I find it a lot easier to use than traditional SAS. Yeah, I’m with you, David. And then for Putra. Sorry, I’m sorry. I’m not saying your name correctly. Doesn’t easy mean that it’s not effective? Peters Okay. Oh, thank you. Sorry. Oh, Peter. Peter So it’s easy to learn how to use a dynamic scanner, but that doesn’t necessarily mean it’s not effective. So what I mean by easy is you can set it up in 5 to 10 minutes and then you have it scan, and that can take anywhere from 15 minutes to a few hours. So if your app is really complex and very, very big, it could take quite a while and then you get the results. And so what happens is they’ll say like, this is wrong and this is how we found it and this is how you could like retest it yourself and then here’s how you fix it. That’s usually how they work. So I think it’s easier because it just doesn’t take very long to learn how to do it. And so does that mean it’s not as effective? Well, not as effective as what? So you’re going to find vulnerability. You’re going to find a bunch of vulnerabilities there, vulnerabilities that someone else could find easily. So I feel you have to fix those. Some of those vulnerabilities you could find if you use a sast or SCA tool and some of them you can’t, and just the same in reverse. So when you use a static application security testing tool, it’s telling you about potential vulnerabilities that it thinks are there, but it doesn’t necessarily mean they’re exploitable. Well, with a dynamic tool, it’s telling you like I’m seeing it live. It does work this way. This is exploitable. I hope that answers your question, Peter, but if not, please elaborate. Cool. So I have a few things to say about Dast before you run off and do it though, so it will automate tests for you. So you introduce it to your app and you like point there scan and then it will start going back and forth and doing requests and responses and it will tell you what and how to fix the vulnerabilities. If you have an open source one and it’s not telling you that you want to get a different one, there are there are much better ones out there. If it’s not going to tell you how to fix the problem, that’s less helpful. So there’s free versions, there’s paid versions, and then there’s a bunch of versions where they are paid if you’re using them at work full time. But you can either use them a little bit or like if you’re doing open source stuff, a lot of them will let you use it for free. But this is the fine print. Do not use a dast on an app you don’t own and you don’t have permission to test. So you want permission in writing to test something if it’s not yours. So if you’re on your own computer and you’re going to spin up a VM with an app and you’re like, pooh, pooh pooh and you’re doing everything in local host, like, do whatever you want, but you should not take a dynamic scanning tool and then pointing at Amazon or Walmart or whatever website unless you work there and your boss gave you permission to test it in writing, don’t do that because you could cause problems. So some scanners are basically safer to use than others. But I remember when I was first a pen tester, I pointed my Das at an app and it utterly destroyed the data. So it was very, very vulnerable. It was not intentionally vulnerable. It just was so it was not great for the client. And I destroyed their whole database, their web server, like it was such a disaster because their admin console had been like just open and it wasn’t supposed to be. They thought it was safe and it wasn’t. And so you need to have permission in writing and always have a backup of your data and your app because some are safer than others and you want to make sure you really don’t want to get into trouble with this because technically it’s a hacking tool. And so again, only pointed out places that you have permission to test. So the next thing that you can do, I’m just going to check the time. Good I have lots of time is you could threat model your systems so you need a security person for this if you’re a dev, if you are some other area of i.t, you still are going to need a security person. If you are a security person, you can lead this activity. So i like this picture. I feel like she’s really got a zillion threat models there. So what does threat modeling mean? So it’s figuring out negative use cases and ways that you can defend against them. It’s like a brainstorming session that’s evil. And so I want a dev there. I want the product owner there, and I want a security person to figure out how your app could be abused. Ooh. Comment from Ben. Hi, Ben. When something is complicated, there are more things to get wrong. For example, Amazon cloud accounts that are set to public. I was trying desperately to relate the example to cheese. I had to give up. I know. I know that she has a question. This is Holly. This is from my podcast. I’ll explain later. But we always have this question.

00:36:39

Speaker 2: About I’m trying to make the connection, but I thought maybe there is three buckets or whatever it is a wholly like a cheese maybe not sure. So Swiss cheese.

00:36:52

Speaker 1: I used to have a boss and he referred to our firewall exclusively as the Swiss cheese. And all my Swiss friends are like, I hate that. That is what people call Swiss cheese. We have hundreds of types of delicious cheese. Yes. Okay. So. So threat modeling is you brainstorming and figuring out what could be going wrong. And so you want to search your code for your threat model. So when you do code review, you want to look for that. When you do security testing, you want to look for that. But point blank, thinking like an adversary is really fun. Threat modeling sessions can be very fun and it can be very interesting and it can be really illuminating for the other teams to start seeing risks like you do. When I first started at it because I’d been a software developer around 17 years and then I switched to security, I really stunk at it. My professional mentor would say, Take off your dev hat. You keep trying to make everything work correctly, take it off and put on your evil hat. And I was like, I don’t even wear a hat usually unless it’s cold. But the point is, is it takes a while to learn to think this way. And once you do, you can’t stop seeing flaws everywhere. So review your code. I used to be kind of anti code review if I’m being honest, because I found it boring and because I wasn’t very good at it. And then I got better at it and I started using more modern like security tools that help you review code. And then I started actually being successful at it, and then I started liking it a lot more. And so I like code review a lot more now than I used to, especially when I first started in security. And if you don’t know what you’re looking for, it’s a lot harder. But when you take secure coding classes, it’s like this is what it should look like every time you see, Oh, there’s input. Where is the input validation? Does it look correctly? And then, oh, there’s this, is there this and you just start knowing what to look for and then you can’t stop seeing it everywhere. And so getting good at code review feels good. So more about code review. So I like to use some sort of sast tool, like a static application security testing tool, and it will tell me all the things that things are a problem and there are more modern ones and there are less modern ones. Oh, there’s a comment from. SAS SAS tools generate lots of false positives. They are per issues which are very easy to find. Low hanging fruit Pen testing is better than automated testing, isn’t it? It’s different. So SAS and US tools are improving a lot because basically a lot of people aren’t willing to put up with that in. Dynamic tools tend to have a lot less false positives than SAS tools. Newer SAS tools are having a lot less false positives, but then they have a lot of false negatives, which means they’re missing things. Every automated tool has to kind of measure. Are we going to have only true positives or are we going to allow some false positives in? But we’ll find everything. And so it’s kind of like a thing that they’re all trying to do right now and it is improving. However, yeah, pen test, if you have an excellent penetration tester is better because they’re spending weeks on it and you’re spending like $25,000 on it. So it depends on what you’re doing. I can’t run a pen test every time I change one line of code or I add one new feature, I can’t afford that. Or I couldn’t when I ran OPSEC. Programs like that wasn’t in the cards for me. I would often get like 4 hours. Like you have 4 hours to test this app. I’m like, I can’t even finish my scans. So I’d be like running this scanned and doing this and that. And it’s like I have like 20 more apps I have to test this month. I just don’t have time. So it’s about the scale you have, how much money you have to work with and what security posture you need to maintain. So if you work in a top secret environment with state secrets that are very important, where if they got out, it could harm your whole country, you’re probably going to have a lot more time in a bigger budget to secure your applications. And then I would use automated tools and I would definitely hire a pen tester or hopefully already employ one full time. But if you’re a regular company and it’s like you have one app stack person. Automated tools will make it so that they can do a bigger, huger, larger reach, if that makes sense.

00:41:16

Speaker 2: So is the main point. Sorry, Tanya. I think the main point, particularly in relation to the on cars question or comment, is I think you will always need a pen test eventually. But when we look at CI CD, when we look at DevOps, when we look at the speed at which developers are creating features and releasing into production, actually it’s impossible to scale. And you mentioned the scalability there, it’s just impossible to scale. So yes, they’re very good at finding the low to medium and in many instances the high hanging fruits. That actually means that the pen testers don’t need to do it further down the line. It means you’re more secure by design. Perhaps something I can talk about later is the false positive aspect, because actually I think you’ll find on CAR that that’s something that’s definitely being looked at, particularly with Bright. That’s something that we really pride ourselves on. But I think that relying on a periodic pen test, whether that’s once a month or every six months or probably in most instances once a year just for a compliance checkbox, actually, you want to be able to find those low to medium hanging fruits early and often, because typically if you look at the majority of the breaches that are that are occurring with some pretty big organizations, it’s the low to medium hanging fruits that people are still exploiting to actually breach and hack and everything else. And as a developer or as a security architect, actually being able to build secure software like a boss obviously is really what it’s about. And not relying on on just a pen test. And just as a last comment, if you are a pen tester and test will always be needed. But the number of meetups that I’ve been to with pen testers that are actually sick and tired of finding the low to medium hanging fruits, whether in an automated way or in a manual way, Actually, they want to focus on the nitty gritty, the logic, the business logic stuff, not to have a ten day pen test assignment where literally they’re just giving handing in a report because, you know, there’s so much of the low to medium hanging fruit stuff here. So that’s my that’s my $0.02 on it. I think it’s always needed. But early and often as security testing is really the best approach.

00:43:44

Speaker 1: I also feel like not every pen tester is created equal. So like I said, I was middle of the road. There is a bunch of pen testers where they’ll just run a quick scan with burp and then they just delete any of the results they don’t like and then they just copy and paste it into word and then try to charge you $10,000. I have had a lot of pen testers write me and say like, Hey, and they ask these questions where they clearly have no idea what they’re doing and they’re asking me for advice of like, basically what? To do it their clients. And I’m like, If you’re not going to pay me to consult, I’m not going to work for you for free. Buster. If you’re not a good pen tester, that’s your problem. But this actually happens like quite a bit where there are these really amazing, awesome pen testers and they charge more and they take way longer and they’ll give you better results and there’s somewhere there. Their work is not very good. And so you have to also be careful that you’re hiring a high quality tester. And yeah, a lot of people don’t talk about that, but they’re not all good. There’s a lot of people that have pen tester on their resume and they’re not they’re not even as good as an automated tool, unfortunately. So buyers really have to beware. With that. I have like a list of people I super trust that I know are really good at it that I will recommend. And then like there’s lots where they’re like, What about this person? And I’m like, No comment. No, seriously. Och. More so. Gabrielle says. Pen test oc fixing the vulnerabilities. Nope. Yeah, I’ve seen that quite a bit. I’ve had a lot of pen tester friends were there. Like I go back year after year and things are still there and I’m like, No. Yes. And then Amkor adds Automated testing plus once or twice a year, pen test will produce more secure software. Yes, it will occur. And Melissa says it’s always good to have a third party test regularly to test your security program. Ooh, I like that. To verify that your testers, scanners and process are actually effective. I like it. Okay, I’m going to try to finish my slides because I’m supposed to let Allie talk to and I’m being a hog. Okay, so software composition analysis, SCA, we talked about this briefly. So basically it tells you if your libraries or frameworks or other third party components are known to be bad, so they don’t actually analyze it for you, they just compare it against a list that they have worked very hard to make. And if it’s on the bad list, they tell you and they tell you why and they tell you which version you should try to get to so that your app will be safe, you can review your code manually, which we talked about how Tanya used to suck at it and now she’s okay at it and she likes it better. And you want to search for your threat models, like when you’re doing testing and when you’re doing code review. And when you do these things, you can find more than just security bugs you can find. I worked somewhere and we found memory flaws and there are holes where we were leaking memory and we hadn’t realized it. And we found a few and we fixed them and our apnea to run on a 32 kilobyte kill a bit modem in the Arctic. And we managed to make it run on that effectively, which is really exciting because we were developing the system for voting and we wanted to be able to reach like every part of Canada. And there’s not really great Internet in the Arctic, but those people still have the right to vote. And so we found all these memory leaks, we fixed all of them, and then our app ran really, really well. So the last one is writing better code. And I don’t mean this in a condescending way. What I mean is, so imagine you are a professional athlete and you practice for the day. You don’t go home, sit in your lazy, your La-Z-Boy, drink beer, eat Cheetos and do nothing. The professional athletes, the cream of the crop, they perfect their skills over and over again. They’re constantly honing their skills to get better. And you can do that too. So I have some ideas on that. So write better code. We can train ourselves on secure cutting practices. So I share tons of free content on this. There’s tons of awesome content on the internet about this. That’s how I learned. There’s many online resources. Some are free and some are paid and some are kind of a mish mash. And there’s courses, there’s conferences, there’s all sorts of things you can do. You can. So every time you go to look how to do something and you’re going to go to StackOverflow because that’s what I did look for the most secure way to do the thing. Whatever’s voted to the top on a regular stack overflow page is usually super insecure because they’ve peeled off all the security to make sure it works. Look at the secure part of Stack Overflow and you’ll get much better quality code. And becoming the security expert on your dev team helps your whole team and you and it looks awesome on your resume. It really, really does. Trust me, if you put like secure coder on your resume instead of software developer or software developer specializing in secure coding that they’re just like all the other resumes. Just throw them away. I want that person So brief Summary. What did we learn today? So insecure software is a giant problem. It’s a big problem and it’s not acceptable. Pushing left means stirring security earlier in the system development lifecycle and secure stocks produce more secure software. Yes, and with that, I am going to turn it over. So that’s me. Hi, I’m Tanya. And then I want Ali to talk now because it’s always turn. If you want to take a screenshot of this, you can, but there’ll be more about Ali and his slides. Ali, go.

00:49:20

Speaker 2: Yeah. Thank you very much Tanya, for always very, very enjoyable and enjoyable talk and there’s a lot there for people to take in. But I think one of the main fundamental sort of points that I think Tanya is really addressing is, is the ability for developers to start owning the security testing process and automating the security testing with with the developers managing that. So next slide, please, Tanya. So I just want to give a quick introduction into into who Brite are. And Tanya did speak for a little bit too long, so I’m going to scoot through this for quicker than I thought. But we’re a global team of engineers and security experts and we built what is a diverse. First dynamic Application security scanner really built to be to be loved by developers, to test your apps, APIs and more. But trusted by security, I know there’s some security folks with us today. Developers you’re releasing faster than ever. Security needs to keep up. And this process actually needs to be owned by the developers. As I mentioned, that shift left the security testing automation into the hands of developers. And we can enable you, the developer, to to build the scan surface from the very first unit tests running test on every build on every pull request seamlessly integrated into your pipelines, but more importantly, with no false positives. So you can actually start to trust the output to make detecting and fixing security issues really, really quick. Really, really simple. And going back to what Omkar said previously, absolutely. Very much go by the mantra of testing early and often as part of the SDLC and supplement that with penetration tests. But let’s just take a quick look at what’s underneath the hood. And, you know, sure, we have a nice UI for the security folks to play around with and configure scans manually, but we’ve been built for developers to actually own this security testing process. So if you haven’t already done so, you can sign up for free account at the private sector com website and you’ll see the nice UI. But more importantly, you’ll immediately see that you can start to run scans via the CLI, install it via Docker, compose NPM or indeed win. And you can actually configure scans as code or use global YAML configuration files in your GitHub actions or circle CI integrated into your into your CD. Next slide, please, Tanya. Thank you. In terms of of coverage, you know, we’ve really made sure that we’ve sort of got that covered. Again, you can scan every bill for security vulnerabilities as part of your PSI, whether that’s against your web apps or internal apps, APIs, whether soap, rest or indeed, GraphQL. Microservices and single page applications. But of course, be fully supported with that. Whether that’s pointing the scanner to local or indeed a production URL ingesting your API documentation or schema, you can also support Postman collections, for example, as well as half files or HTTP archive files. And this really means that you have the ability of really defining the scope of the security test perhaps against a single entry point or endpoint to be very, very targeted and perhaps specific even to a specific feature or change that you’ve made on your application. And these discovery methods can be used or run either separately or indeed currently, meaning the developer or the security team or indeed the QA actually can actually handle client side, dynamic content, JavaScript and more. And if you are using tools like Selenium, Cyprus, any other form of proxies, you can actually start to leverage your existing functional scripts and start scanning with these half files. And this is another way of the shifting left, as Tanya was mentioning. Actually, some organizations like to start right or shift a little bit center and then move back as left. As you build your processes and developers in QA can actually work together to start treating security bugs like you do your functional ones without the need to be a security expert. Either way, scans are fast. You’re running for minutes and hours, not sort of days. Maintain your DevOps speed. Next slide, please. Tanya from the security folk there today. You know, the more you fix, the better. The more you can detect and fix, the better. You have a comprehensive list of testing categories covering the technical top ten. But our engine also understands context, the responses that we’re getting back from the application server. And we can use this information to actually carry out automated business logic security testing. So this isn’t just sort of trivial injections. How can we actually bypass the logic or the validation mechanisms within your applications and APIs? And again, this sort of removes the reliance on manual testing so that you can implement and integrate, deploy more robust security testing as early as possible on every build if required. If you have authenticated scans that need doing and of course, we have full support for that too. But the biggest issue. Next slide, please. Tanya, the biggest issue that we everyone faces is particularly with security scanners, is accuracy. And if you want to put up your virtual hands, who loves false positives? I know this is virtual and I can’t really see you, but I’m sure all of you have your hands firmly on your desks. And how much time are you spending validating issues or fixing issues? Six months or a year ago because they weren’t valid? How are you prioritizing your remediation when you don’t actually know what’s where and when? Tanya was alluding to DevOps? See, I said It’s all about automation, right? So how can you do that without accuracy? Developers, security really doesn’t matter. You want to know real issues. Organizations always talk about reducing false positives. Bright We really look at removing them completely. So whether that’s or whether you’re a startup. Smaller organization with without a dedicated security team, it might be a large enterprise organization where developers outweigh security 50 to 1 or 100 to 1 in many cases. You’re developing a breakneck speed, multiple builds a day. False positives really are slowing you down and compounding technical and security debt. These are crippling or rapid release cycles. The bright scanner will actually automatically invalidate every security finding we have. So you’re removing the noise. We’re losing the alert fatigue. And actually, you can actually now start to automatically generate a ticket because you know it’s there. Next slide, please. Tanya, in terms of if you now know what is actually being reported is real, how can you fix them from a developer’s perspective? You’ve got Volvo’s full visibility of what’s happening. You can understand where your recurring issues are being detected. Again, fully and automatically validated developer friendly remediation guidelines. With further resources, you can understand where the issues are and how to fix them. Full view of all the requests response headers, all of which can be copied as a code for debugging, and each of those can be assigned to a specific project for remediation. And if you are on the security side of things, global visibility via the sort of projects reporting. Next slide, please. Tanya, just very conscious of time. This is the last minute. This is really what it should look like. Typically you look at dust typically occurred at stages four and five. Start automating security testing to help you build secure software like a boss by shifting security left putting security testing into the hands of developers. And yeah, if you haven’t already done so, next slide, please, Tanya. You can sign up for a free account with with Brite. Just go to our website. You can be up and scanning within minutes and there is a full documentation for basically complete self service if that’s indeed what you needed. Tanya I don’t know if you wanted to have a passing comment, but I hope that everyone found that Tanya’s part of interest and perhaps you can see how bright developer First security scanner can actually complement many of the facets that Tanya spoke about during her talk, but conscious of everyone’s time. Thank you. Thank you very much for joining us. Tanya, can you hear us? We’re talking about you’re talking about tacos and stuff.

00:58:29

Speaker 1: Yes. So tonight in New York City, we have purple communities having our first in-person meetup and we changed the location. It was going to be Castro’s, but we realized it would be like $200 per person for dinner. And I was like, No, no, no. So we switched to some place called Las Tacos specifically so that I don’t want to pay $200 for dinner. So, yes, Ali, there is actually. So I do have some free resources I wanted to give away and I’m sorry we’re a bit over time, but.

00:59:00

Speaker 2: Okay, most people are still here. So we’ve obviously done an okay job.

00:59:04

Speaker 1: There is a question from Samuel. He was asking how how does Bright eliminate false positives?

00:59:11

Speaker 2: Okay. So it’s a it’s it’s a good question. And, you know, to to focus on the how I suppose a good example would be a reflective, cross-site scripting security issue where the where the exploit will execute a pop up, for example, which the hacker can take you or the unassuming user to a site of their choice that could, for example, mimic your website. Really, really not a bad thing, a high severity vulnerability. Now we run a headless browser technology in the background. So this is a classic example of how the lengths that we go to to automatically validate security. So we run a headless browser. We actually spin up the application or render the application and web page, look for the reflection and actually take a screenshot of if it’s an SQL injection, for example, we will actually look to exfiltrate database net, for example, and if we can get the database name or a table or something on those lines, we have access to everything. So we do have more information on our docs, on the links that we go to. This is actually going to be made better for loss of a better a better word over the next few weeks. But Samuel, all I can really say is if you’re already using a dast put us to the test and have a look compare us to other ones. More than happy to be able to put a test by you. But you’ll see once you sign up for a free account. The information that we provide that clearly demonstrates and shows that this issue is real, but there’s multiple of different validation mechanisms that run in the background to ensure that you’re not having false positives. For us, a false positive as a bug, and this is removing all the alert fatigue, as I mentioned, and the noise for developers. When you talk about shifting security testing left, what you want to be able to do is give developers actionable results immediately so they can fix those security issues now or at least give you. Whether you’re an engineering manager or on the security team, the ability to immediately prioritize what we want to fix and when. If you have a report with 200 vulnerabilities and 150 of those false positives, what actually happens is you put that report to the side, someone will pick it up and actually you probably end up just released releasing into production without really doing it because this is the compounding security and technical debt that I mentioned. So I hope those two examples, Samuel, were were enough for you. But like I said, and this goes to everyone, you can sign up for a free account and give it a give it a give it a test. Drive yourself and see how we do. I don’t know if there are any other questions.

01:02:02

Speaker 1: I don’t see any other questions in the chat, but shall I give everyone their free resources before we leave?

01:02:09

Speaker 2: Absolutely.

01:02:11

Speaker 1: Ben. Last tacos. What we’re talking about is a we hack purple in-person meetup tonight in New York City. I know there’ll be cheese on the tacos. Don’t worry.

01:02:21

Speaker 2: Let’s cheese.

01:02:22

Speaker 1: OC. So get ready to take some screenshots just in case. So resources. So I have a podcast and it is rebooted and it’s starting for real. So season two is starting to come out. I’m recording new ones almost every week at this point and they’re not live anymore. I know by Michael, but basically they’re short lessons on a specific security thing. There’s awesome books and I recommended these books for a while. But basically if you want to know more about DevOps, here are some awesome DevOps books and my book about application security going, we have purple community, so it’s free, There’s no upsell and now we have free courses in there. So we have two free courses in there and we’re adding a third one very shortly. So bridge crews making a free course for us, which is really awesome. And the first course that was free was from right, I made it with Bar one of the founders and he’s super funny. The whole course is so fun and we smash all the things and resources. Me So I am on the interwebs and I have a newsletter and all of the things, so feel free to check me out. We hack purple and bright, and with that I want to say thank you very much. This is my last slide.

01:03:35

Speaker 2: And there is a there is another slide actually telling you, if you go to that, I’m going to finish I’m going to finish on just in case people missed the other slide has an updated if anyone missed it, you can. There we go. There we go. Yeah. You can sign up for a free account, by the way. It is free. Free forever. I think we we call it. We don’t ask for any card details. You can literally be up and scanning in a few minutes. Built for CI CD, built for developers to own the security testing process. I know there were a few security professionals on the call. Many upset professionals love our tool and testing companies. By the way, Omkar who use our technology to automate a lot of the preliminary scans that they do love. The fact that there’s no false positives, full support for multitude of different APIs and authentication mechanisms, but also try and let us know how how you get along. But thank you very much for joining everyone. I’m very, very jealous that I’m missing out on Los Tacos. Oh, well, it’s a good thank you very much for everyone for joining. Also for us, running late. Pretty much everyone stayed until the end. So I’ve obviously got nothing else to be doing than been talking to us. But we can give you the ability to go back and do some work now. Tanya, thank you very much. Excellent talk. Really, really useful. We look forward to doing it again. And yeah, thank you very much, everyone. Until next time. Okay.

01:05:18

Speaker 1: Bye, everyone.

01:05:19

Speaker 2: Thanks, everybody.

01:05:20

Speaker 1: I’m waving like this.

01:05:21

Speaker 2: Bye bye. Bye.