Resource Center  >  Webinars

Global Application Security Panel: Best Practices for Tackling OWASP's Top 10 Web Security Threats

Webinar

00:00:00
Speaker 1:Hi, everyone. Welcome. Thank you for coming. As you all stroll in and while we’re waiting for everyone to enter the webinar, we’re just going to ask where everyone is calling in from. Or I don’t know if the correct grammar is where you’re zooming in from, but I’m in Canada right now, just outside Victoria, British Columbia, so West coast near Seattle. Where is everyone else coming in from? And this means panelists and yep in the chat. Essex, United Kingdom. Awesome. Where is everyone else from or where are you? Israel.

00:00:42
Speaker 2: Yeah. I’m Israel. I’m from Israel.

00:00:49
Speaker 3: Same here.

00:00:50
Speaker 4: India? Yeah, I’m from India, guys.

00:00:54
Speaker 1: Nice.

00:00:55
Speaker 3: Hello. From a small country, Lithuania.

00:01:00
Speaker 1: Oh, very, very nice. Awesome. So we have Phoenix, Arizona, Canada. So that’s like a pretty big place from the Philippines. Oh, very nice. Oh, DC region and Toronto. I was in Toronto, Karen two weeks ago. Yeah, this is wonderful. Awesome. So we’re going to start in just a minute. I just wanted to see that everyone actually got into the room that’s trying to get into the room. I don’t know if any of you have ever noticed the numbers of the participants, how they just keep scrolling up. We don’t want to start before everyone’s here, but we have quite an amazing panel today for you. There’s yeah, there’s a lot of us from all over the planet that. Are you actually in India right now?

00:01:49
Speaker 4: Yeah, I’m in India from Srinagar. City of India. Yeah. Currently residing in India only.

00:01:58
Speaker 1: Oh, my gosh. What time is it?

00:02:01
Speaker 4: It’s 9:30 p.m.. Yeah. Okay.

00:02:06
Speaker 1: I have a friend in India, and we were always, like, working hard to figure out times we can phone each other.

00:02:14
Speaker 2: The only time zone with 30 minutes difference.

00:02:18
Speaker 1: Oh, you know. Well, they’re a really big country, too, right? So lots of time zones.

00:02:26
Speaker 4: Yeah.

00:02:27
Speaker 2: No, I think they have one.

00:02:31
Speaker 1: Really? For all of you.

00:02:33
Speaker 4: Yeah. Yeah. Whole India has one time zone.

00:02:36
Speaker 2: That’s why the 30 minutes.

00:02:38
Speaker 4: Yeah, that’s right. I know it’s surprising. It’s. India is a big country, but. Yeah, we have one timezone only.

00:02:47
Speaker 1: Oh, wow. Okay, then. That Canada has five. It’s like we’re high maintenance that way. Okay, let’s start the webinar. So welcome everyone to the Global Application Security Panel. I am Tanya. I’m your host, and we’re going to talk about best practices for tackling the top ten Web security threats and risks. And so I’m going to just kind of moderate while all these brilliant humans have awesome discussions. And so I was wondering if we could start with Ziggy’s and each one of you could introduce yourselves and just tell us who you are and a little bit about what you do.

00:03:29
Speaker 3: Yeah, I see. We started from the most difficult name, so my full name is Gigi Mantas. But that’s like even hard for native Lithuanians to pronounce. I guess. So I’m calling from Lithuania, from the company North Security. And you probably know the company Nord Security, at least from one of the main products that we are really advertised. So Nordvpn, it’s used globally around the world. So my team is heavily working on this product as well as the others. So I’m application security team lead and well by application security In this context, I mean more on the client side. Security though I had experience also in the past with web security related stuff. So some some knowledge to share and that’s basically it. So I’m really the technical guy who works quite a lot of hands on with all the security matters and like newest and greatest security ideas.

00:04:25
Speaker 1: Nice. Sad. Could I ask you to go next?

00:04:29
Speaker 4: Yeah, sure. So my name is Zed. I work in extinction as a security lead. I’m from India, so I have a diverse background in offensive and defensive security, as well as have an extensive experience as a security researcher. Uh, on the offensive side, I have owned my skills through actively looking for vulnerabilities and doing tests. Uh, and on the defensive side, I have closely worked with the developers building robust security controls, doing secure architecture reviews, threat modeling, different secure SDLC practices. So my goal has always been to create a secure environment for applications and protect the data. Valuable data. That’s it from my end.

00:05:16
Speaker 1: Nice. Vitaly, could you go next?

00:05:22
Speaker 2: Yeah, yeah, sure. So I’m Vitaly. I manage the app research for Bright Security. We actually look for the vulnerabilities and the way to implement them in the product. Uh, I’ve been in the security and application security field for the past 15 years doing various roles from pentesting to team management to application security, architecture design. Um. On all sides of head of both customer and and the and the client kind of and consulting departments like starting new things and building things for fresh. So yeah.

00:06:06
Speaker 1: Nice. He is also telling us how he got really good at budget back in the day and giving all of us pointers before we started recording. So he has lots of knowledge to share. Chris, can you go next and then you go after.

00:06:22
Speaker 5: Sure thing. So. Hey, Tanya, this is Chris Romeo. I’m the CEO of Kirk Ventures. Previously, I was the co-founder and CEO of Security Journey, a security education and training company. And I’ve been in the world of security for a long time, like 26 years at last count. And I’ve done a lot of different things in my time. But application security has been my focus for the last, I don’t know, 12 or 15 years or so. And I really enjoy sharing the knowledge that I learned with the rest of the community via various podcasts and talking about threat modeling apps and security champions.

00:06:58
Speaker 1: Awesome. Awesome. Okay, Igor, it’s your turn.

00:07:03
Speaker 6: Thank you so much. Thank you, everyone, for being here. My name is Greg. I’m originally from Bosnia. I grew up in Canada, actually all the way to I was about 15, 16 with a couple of degrees from Montreal. I’m currently San Diego, California, so far away, and I’ve been in security since about 2010, 11, something along those lines. But I’ve joined clockwork, one of the products back in the day. I am currently a manager application security at R1 RCM. I’ve just arrived to the company a few months ago. I’ve been in GitHub prior hand and yeah, I look forward to answering questions and participating today. Thank you.

00:07:41
Speaker 1: Awesome. So when they asked me to do something about the top ten, I was really excited. If you work in application security, you generally know who I aspire, but I was wondering because we don’t know the level of every single person that’s here, if we could talk about what the heck is Owasp does? Does anyone want to volunteer for the what the heck is Owasp and the next person is going to volunteer for was the top ten, because otherwise I’ll talk the whole time. So I guess, do you want to tell us what Owasp is? Perhaps.

00:08:13
Speaker 3: Well, I know the formal definition, which is kind of open web application security project, but in a sense, I would say in simplified terms, it’s a very good resource not only for security people, but also for like tech and even non-tech people to get to know about the like different security problems that might occur. Well, if we are talking about our top ten. So this is kind of a top ten of the risks that occur most often, I guess, and I’m not sure how many people know, but there is not one top ten. There are more than ten of top tens, even though the other ones are not so kind of publicized. But this is sad for me as I often need those other top tens than the main one in my daily life. And I want you to see, you know, these to be more kind of popularized and used by the people and known by the developers. So that would be the short intro, I would say.

00:09:10
Speaker 1: Yeah. No, that’s perfect. Thank you. Yes. And Owasp has chapters and projects and tools and all sorts of amazing things that are giant community all go together to create. So I was wondering if I could ask each person what their experiences with the top ten. And I was thinking I would start with Chris and Chris. Could you start off with is the top ten a standard?

00:09:37
Speaker 5: Ooh, that’s a loaded question right there. Loaded question. We see the top ten so often specified as a standard or a purchasing criteria when in fact, the document itself says this is not why this thing exists. The top ten exists to share the top ten application security risks. That’s the key term here. It’s not the top vulnerabilities, not the top exploits. It’s the top ten application security risks. And this is a document that’s been compiled in its latest few versions and almost entirely data driven. So Brian Glass and Andrew Van der Stock and the rest of the team that are behind this, ask folks in the industry, various vendors, send us all your data about the different vulnerability Web vulnerabilities that you’re seeing. And then they take that and compile it. And then they they go to the the community and they ask for suggestions for two of the items just because they want to they want to make sure they’re taking practitioner input. But really, my experience has been using this thing as a learning tool primarily for as long as I can remember, maybe not the original one of the top ten, because I wasn’t quite in knapsack at that point. But for me, it’s really a learning tool.

00:10:50
Speaker 1: Awesome. Igor, have you used those top ten network before or. And if not, why not?

00:10:58
Speaker 6: Absolutely. Absolutely. From from our perspective and was quite a bit in sales back in the day as a sales engineer and solutions architect. A lot of customers, clients prospects. It was a go to standard, quote unquote. If you if you had coverage from the static analysis perspective or dynamic analysis perspective within top ten vulnerabilities, and if your tool can actually do something and create reports about it. That was that was the bare minimum. And it kind of I think it speaks to the to the importance and comprehensiveness of ASP as well, what it contains, what it really hits the different types of different types of obviously kinds of threats that exist within it. So absolutely, I think what’s top ten is, if anything, everyone would start with that and at least in web application security and kind of build from there if they want to extend their posture.

00:11:46
Speaker 1: Cool. Vitaly In your work, do you use the top ten when you do security research? Is that a thing?

00:11:53
Speaker 2: Actually, yeah. We try to build upon, so we try to map the attacks, the attack vectors that we want to simulate according to the top, uh, the top risks. And we also address the API top ten. So there as well as us. Right.

00:12:12
Speaker 3: And did you give us.

00:12:16
Speaker 2: I will get it right on the second time. All right. As you mentioned, so there in the past, we’ve used mobile as well. There’s the mobile top ten, but now we’ve mostly focus on the Web and the API top ten, and we use them extensively to try and focus ourselves on the newest and greatest. And by the way, the top ten just was published yesterday. I think the newer one, the 2023 one. Oh, it was working On adopting that. Yeah.

00:12:47
Speaker 1: Yes. I did not know it came out. Yeah, I knew it would be any day now. Awesome. So we’re hearing news on the webinar. This is great. There’s a question in the chat and I want to ask it to Ziad. So this is from Syria. So the top ten has been around for quite a long time, like relatively, right, 21 years now, I believe. So what are the real challenges for continuing exploding code security risks? So like there’s tons more risks happening all the time, Like are there gaps? So I realize that’s an open ended question, but can you answer some of it? Like, what are we doing about lots of new risks?

00:13:29
Speaker 4: Okay. So yeah, so I believe like the challenge for like adopting this Owasp top ten is there are a lot of work around it, so we have to know the background. Developers should always have the knowledge of AWS top ten. When they have this knowledge they can implement, they can do the secure coding and avoid writing these bugs into the code. So that is the actual the big challenge is the knowledge of Owasp top ten. Uh, another thing is we don’t have the right tools, but bringing up the right tools for maybe for the dast and says can we, can we can have how the plugins in the IDs that that will tell us where right we are we are making open access bug here we are creating access bug here. So that kind of stuff needs to be there. Yeah. Other panelists can open add some info here.

00:14:37
Speaker 1: Yeah. How do we handle how there’s so many new risks that keeps happening? Like, I know that a lot of people ask me, do I have to memorize all of them? And I’m like, Well, I don’t think that memorizing all of them is reasonable. Does anyone else want to add on a bit more to this question before I move on to more questions?

00:14:53
Speaker 2: Well, they do change from time to time. It’s not like they’re constant. So you do have to keep kind of tracking on things and sometimes they even merge. It changes according to, as Chris said, they change according to the actual propagation of those issues in the wild. It’s not the end of an all and B, all of all the security issues. That’s just the main areas of focus that happen now.

00:15:20
Speaker 5: And we do. We do see some progress happening to like one of the things that I’m so proud of us as an industry is where if it’s not in the top ten anymore, it’s like 13 guys. So it’s not completely gone from our lives, but it doesn’t appear in the top ten. So yeah, we do. We do see some things getting better. We see because I think sometimes when we look at the top ten, it can be like all doom and gloom. Like we’re not we don’t want to, you know, I made this joke forever, the top one when it used to be injection. Like, why don’t we just focus on the top one? Why do we always have to talk about ten? But we are seeing some progress. We are seeing developers learning about things and Csrf is a perfect example. It’s no longer in the document because the frameworks have gotten better to be able to deal with it.

00:16:03
Speaker 1: Chris I totally agree. And cross-site scripting dropped a way down the list over time and I feel like the framework creators so like dot net framework, the Ruby on Rails framework, all of those frameworks, they’re adding even more security into things like automatically open encoding, things, automatically passing an anti surf token. Like I, I’m very, very happy how Owasp? I feel like Owasp is like achieving its mission a bit at a time just now, as quickly as all of us wish that we could. So there’s there are more questions in the chat and they’re so good. So one of the questions was, are there any open source toolkits to help exist to help test against the top ten? And I feel like we could talk about that all day because Owasp has many tools that can help you find some of the top ten. But then there’s also manual processes. Does anyone want to recommend any specifically open source tools or toolkits?

00:17:07
Speaker 4: Yeah, let me answer this. Yeah. So for dash testing for you can do Zap. Zap is an open source tool. And there’s another thing, one vulnerability kind that is vulnerabilities within the components. So for that we do software composition analysis. So there is a tool called dependency checker, so we can use that. That is again an open source tool. Yeah. The tools I want to add there definitely.

00:17:38
Speaker 1: And there’s dependency check and dependency track and one is for a CI CD and the other one is just to run manually because not everyone uses a CI CD and that’s okay. Um, there is another question that oh, and Igor also put a link in the chat for you as well. Um, so from Pooja in the chat, are we targeting newer generations to be better educated? And I really want to say yes to this, but I don’t know if it’s true. Does anyone want to chime in on the status of education where they are? Chris, I’ll.

00:18:17
Speaker 5: I’ll take a I’ll take a stab at it because education, something I’m super passionate about. When there was an article that came out, I can’t remember the exact source a couple of months ago that looked at the top computer science programs across the United States, and it found that almost nobody was teaching security in the university system. And so that’s something that I continue to trumpet. I know a bunch of the other folks that are on this panel are doing the same thing, that we do have an opportunity to take apps and education into the university system. Like imagine a world in the future where developers are not just learning build web apps with Java, but in that class they’re learning about what the top ten is at the at the time and they’re learning how to mitigate it with the proactive controls as a companion. So I don’t think we’re doing a very good job right now in preparing the next generation. I’m seeing pockets of different places where some university folks are starting to get it. Like, Hey, there’s an opportunity for us here. But I think I think as an industry, we’re not doing a very good job yet.

00:19:23
Speaker 1: I agree completely.

00:19:25
Speaker 2: Want to just chime in on that. So there was a time when security and Appsync was considered a certification. Kind of. Yeah, you get you go get the certification diploma and that’s where it stopped. I do see that some programs have security courses. That’s kind of sporadic, as Chris said. I did see a graduate program, I think in Canada they have a couple of graduate programs for security. But again, that’s focused on graduate students and not on on newcomers, not on new developers. And that’s kind of. Trying to focus them towards research and not towards getting their kind of fit with in the field.

00:20:11
Speaker 1: I agree completely. Vitaly When I wrote my first book, my whole plan was then they’re going to teach at universities and they don’t. There’s a handful that have it, but most of them teach it only to their security students. No, it’s the stuff for developers. I want to read the book, so I’m writing another book. We’ll see how it goes with secure coding. So hopefully I can like get more on task with the universities. But we’ll see. There’s more questions in the chat. But I actually wanted to kind of switch the conversation a little bit to be about mitigation so all the people on this panel work to help fix these problems and prevent these problems. But all of you, like the reason why you were chosen is because you do it from different angles. So I was wondering if we could start talking about how we can fix this. And so one of the things is how do we implement secure coding or how do we do devsecops? Like, does anyone want to volunteer to talk about how we could start a devsecops program or what the heck that even is? So put up your hand if you want to answer that. Oh, come on. Because I’m going to. Yeah. No, it’s too late. It’s. It’s Ziggy’s and then Vitali and then Igor. I’m going to pick on you after for the next question.

00:21:26
Speaker 3: Yeah, I could start very brief, and then I guess my colleagues will pick it up. So as devsecops something that we are kind of implementing right now in my current company, I would say that in the first place, this is like a huge cultural shift. So it’s not like one specific tool or something like that. It’s more connecting all the dots from technical and even non-technical roles, and it’s not so easy to to spin up as like, you know, just buying one tool and running it. So that’s the thing. But I guess you feel first need to get the support from stakeholders for sure. Without that you won’t move anywhere, you know, in any direction and you need to start small, you need to start small. It depends really on the company side. You’re trying to implement the devsecops, but this is a complex process. It’s not so easy to start and when you start, there will be a lot of kind of exotic cases, drawbacks, issues here, and there are things you won’t even consider before anything. So when you start small, it’s easier to maintain that and scale that afterwards to the to the company. And I would say that that’s as a process overall, it needs to support business. Some people still, at least from my experience, they see security as kind of policeman who kind of makes the rules be implemented in a physical or not so physical way. But if we go with devsecops, this this kind of old approach, if I may call so it doesn’t work like this. So security needs to be integral part and work hand in hand with development. Like almost no distinction between who is the security guy, who is the developer or operations guy. So it’s very easy to get over complicated. You need to avoid that for sure. And from my experience, what is really crucial is to think about metrics. So when you start with the whole process, if you don’t think about metrics before, it’s really hard to prove that you are getting to some kind of improvement to some value. If you don’t have a no numbers charts, anything nice to show that all the company, all the developers would believe that this is well, right way to go. And yeah, that’s probably that any kind of one shiny tool won’t help here. You need to really push forward like through all the scope possible.

00:23:53
Speaker 1: Okay. Vitaly Did you want to add to that?

00:23:56
Speaker 2: Yeah. So I think the a couple of things that took me a while to understand, first of all, that management and management tends to treat security as a project and not a process. Which kind of complicates things because they tend to do it. All right. We’ve gone up to this point and now we we have. We have arrived. That’s it. Right? We’ve done the compliance part of this, and now we have to do something else and we’ll focus on something else. And we’ll do people there, here and there and back. And that kind of halts the whole process. I did agree with Start small, starting my team, start processes and start adopting them kind of in bigger and bigger circles. That’s one. Second thing that aligning to business, sometimes compliance actually drives the business. When the company sees the opportunities that they have in gaining new customers with getting a compliance. So I know that the price for a company that worked for jumped when actually we were able to adopt NAB and that kind of opened the whole new market for us. And that was a security driven kind of effort.

00:25:15
Speaker 1: Cool. Very cool. Igor. I was hoping that you could talk about how can we so one or the other. So there’s a long list of things that we’re going to talk about during this, and we’re never going to get through all of them. But one of the other first steps that was suggested is how can we implement secure coding or how can we help developers code more securely? And then, Chris, I’m going to ask you to add on to his answer after, because I already know you want to answer this question, but where can you start?

00:25:46
Speaker 6: Yeah, I think we should start with the basics. Start understanding first what security means, what return is going to yield to you. I think there’s a lot of stigma and hesitation in implementing security because it’s typically regarded I don’t use this word but as a burden, right? You already have your your functional testing you’re doing, you’re already creating software, you’re creating, you’re creating something tangible, something that you want to to function a certain way as you’re tasked to do. And then on top of that, back in the day, remember, way back in the day, unit testing was was really frowned upon. Why? Why would we do this? We have testers, I’ve had testers are there. That’s their job. Why am I doing my job and their job right if that’s going to go to them anyways, No one really thought about proactive way of just fixing something, even security aside, taking care of it, and then making sure that that’s just kind of like a safety check. Security the same way non-functional testing security testing is probably called functional these days has completely changed the way that we that we interact with this as well, because we’ve added yet another layer of of tasks and demands, I would say, to engineering teams, which I think them understanding the concept of what it means in the long run, how it’s going to how we may come back to them and what it really means if they miss opportunities and miss certain threats that they could have taken care of early on. I think that’s a that’s a big thing. So we have to just educate that this is, in the long run best for everyone without really intruding necessarily into into their into their agile sprints, into whatever they’re doing. We’re going to be just yet another set of tasks that they can take. Take care of and think about. So in a really, in a really nice, polite, non-intrusive way, adding security early on would be great. On top of that, just to maybe conclude, I thought it’d be education as well. A lot of folks don’t necessarily mean we talked about this too. What is SQL injection? What does that really mean and what is parameterization of queries like how do I even do that? Well, here’s an article read about it. You know, they read about like I still I still don’t get it. What’s different? Right? They didn’t see it in action. So some sort of education where you can you can visually comprehend and see what these things can yield to and what they really mean. That went a long way talking to someone about cross-site scripting versus showing them forms and how the information is passed through and how it accesses certain things internally goes a long way. So I think it’s a combination of these things understanding how engineering works, educating them and just ensuring that that they take the right approach. But just a quick summary.

00:28:07
Speaker 1: No, I like it. Chris, did you want to add on to that? Chris has worked in education for a very long time for our viewers. Yeah.

00:28:15
Speaker 5: Yeah, Happy to. To add just a little bit about education. And then I want to I want to go in a little bit different direction that I think will be complementary to what Igor said here. But certainly the learning by doing principal when dealing with developers is a very powerful construct. So you can spend eight hours lecturing at developers about what is SQL injection, what is cross-site scripting, what is, you know, problems with vulnerable third party libraries. But until they put their hands on the keyboard, which is what they spend most of their day doing, they don’t it doesn’t really cement in their brain as far as what the challenges are. And so to to also kind of come at the secure coding question from a little different angle, something that I’m very passionate about is secure by design, secure by default. And so by having a better design and let’s face it, everybody does design. I don’t care if you’re in DevOps and you tell me you don’t do design, that’s not true. You may do design on a piece of paper next to your keyboard when you grab a user story that’s still design. And so like Sisa, for example, has an excellent document they’ve recently put out on Secure by Design, secure by default. And what this really all points to is threat modeling is the answer for how we help developers design things in a more secure and more privacy centric manner so that then when they’re writing code, they’re not they’re not pushing something to production that they have to come back to six weeks later and go through some big rework exercise because, oh, we didn’t think about that threat. Modeling secure by design, secure by default. These are all constructs that you can use earlier in the process. Everybody, we’re not even going to get into shift left shift, smart shift to the moon. I don’t know. Whatever the the latest shift is at this point. I’m making this up on the fly. But really, threat modeling and secure by design is something that can really make your secure coding easier because you’ve got a solid foundation, a solid design to build off.

00:30:07
Speaker 1: Yes. Okay. So I love that we have a bunch of questions in the chat and one of them was, can we please have the top ten updated every single year? Because every four years it’s getting updated and that’s not enough. And that’s a great question, but it’s a twofold answer. And one is it’s volunteers and they don’t get paid. And so we can’t be like, hey, work for free more. But the other issue is industry and industry just not answering the call for data. That’s why it’s so difficult. Their job would be way easier if everyone just gave them data immediately when they asked. They didn’t have to chase them and it was all in the right format. But getting enough data is a big struggle, which is a thing the public, I think, isn’t generally aware of. But several had. So serum’s been giving us a lot of questions in the chat and one is what are the real challenges for developers to adopt secure coding best practices? Like is it a conflict of the sorry, is it a conflict with the business or is that they’re not given enough time to do it? Like what are ways where security could partner with coders to help them do better secure coding? So not just education, but what could we do beyond that to support them? Does anyone want to put their hand up or start talking? Or am I going to pick someone names Add?

00:31:26
Speaker 4: Wow. Okay. Think already answered this question, but I will just add some more info. I think the major obstacle for developers is the knowledge. They don’t have the proper knowledge about the secure coding or top ten. So that is the main thing here. So another thing is we don’t have the that secure coding guidelines in our organization that is the must must thing. So developers always have to check that guidelines when doing doing the coding. If that guideline is missing, they will code their own way. So that is the another thing. Another thing is review. We should have a code review of before every push. So that is another we should have a code review experts who will review the code. Yeah, at the first instance, developers will make the mistake, but when the code reviewers will tell them these things need to be developed this way, this this particular secure coding needs to be done. The second time, they will start implementing the secure coding practices within their development. Yeah.

00:32:37
Speaker 6: Maybe I can just add on to that real quick. Everything was said. Absolutely. And on top of that, one thing that we also saw work in different companies to is having some sort of recurring I just call it a meeting, but let’s perhaps office hours where security and engineering talk where they share success stories, they share troubles and obstacles. They share what is what is working, where they’re stock or what help they actually need. The unfortunate, I think reality too, is that there’s the ratio between security and engineering is quite different, just like it used to be with an engineering. So you may have one security engineer, pretend regular engineers or developers, which is hard to actually handhold everyone. But there’s nothing like having that that one on 1 or 1 on group time with security, just just kind of showing you the ropes. So office hours used to be pretty, pretty successful and something would continue doing even even at R1.

00:33:29
Speaker 5: And Tanya, if I can just add two words, security champions. That’s the that’s the answer. I’ll let somebody else explain to somebody else. Explain what it is. Somebody has to tell what it is.

00:33:41
Speaker 1: Chris and I both feel that’s important. Who wants to explain what security champions are? Who wants to do it?

00:33:47
Speaker 2: So security champions are basically members of development teams that help you achieve the goal of securing the application or basically driving the security requirements into the team. They lead the by example. They they have panels. We used to host panels for internal panels for security champions. We train them and they kind of pass the knowledge onwards into their teams and they kind of watch over and help Instead of going developer by developer, it helps you kind of build a community across those and try to communicate with them.

00:34:26
Speaker 1: I love it. They also make it just so much easier as a security person. Oh, do you want to add more sugar?

00:34:32
Speaker 3: Yeah, just for a few cents to what Igor has said about the kind of knowledge sharing, Right. Between security and developers, what we felt was missing for quite a while and what we’re trying to encourage and I guess security champions concept really works on that is to transfer the knowledge between developers, the security knowledge, because in bigger companies, when there are tons of teams, this knowledge somehow gets lost in between. And then like one team is pretty, pretty good with security and then the other seems like doing quite the similar work, but there is no knowledge transfer. So I guess the security champions concept, when there are some representatives from different teams, also kind of really helps to share the same in between the company.

00:35:16
Speaker 2: By the way, just a small note. I used to promote people to to allocate people to security, to be security champions as the people who argued with me most. So they kind of got to feel the the requirements and for being productive arguing.

00:35:37
Speaker 4: Yeah. So talking about the security champions, so will, I will just share some knowledge regarding the service based company I’m working in Accenture. So what we do there, So for all the projects we have the security champion who drives all the security activities within the project. So he’s responsible for giving giving the sessions about security to developers, implementing the tools then, then getting the vulnerabilities, understanding, making the proper understanding to the developers about that vulnerabilities, helping them with the remediation plan, tracking all those vulnerabilities. So yeah, that’s what like security champ doing service based companies.

00:36:20
Speaker 1: Excellent. I just wanted to summarize for people who can’t see the chat. For instance, watching it later, we had a bunch of questions after Chris mentioned threat modeling. And so some things that you could look at or read after you’ve watched this whole video is Threat Modeling Manifesto, which is available online, and several books by someone named Adam Shostak. And also you can follow all the people on this panel. And I have a feeling all of them have said something about threat modeling at least once. And so there are so many questions in the chat, thinking really hard to choose from because there’s so many good ones. But one that just came out was how can we help front end developers integrate the top ten into their designs and workflows, which I realize is sort of a twist on a previous question we had Does anyone want to try to tackle this one? I feel like we haven’t heard from Chris in a minute.

00:37:15
Speaker 4: Yeah, Chris can answer this question otherwise. Yeah, I’m happy to.

00:37:19
Speaker 5: I’m trying to be careful and not talk too much because I love to talk. So when I think about front end developers and top ten, the first thing that comes to mind for me is ensuring that my developers understand the controls that exist inside of React, inside of Angular, these web JavaScript, web front end frameworks have done a really good job to Tanya’s point earlier about integrating security into the framework itself. And that’s really the key for where we want to go in the future. We want more things to be automated for the developers inside the front end frameworks. And one of the things I just love is so React has it has renamed their functions, their bad functions to dangerous functions. So if you want to do something, you have to run set. I think it’s dangerous in our HTML or something like that. Like you have to actively type into your IDE the word danger in regards to something that’s going to take input from the user and not do any validation or sanitization on it. So I think it really comes down to understanding what are the security capabilities of the JavaScript framework you’re using and ensuring your developers understand that so that they can be productive and they can implement and not violate the controls that the front end frameworks have already built.

00:38:38
Speaker 1: Awesome. So I have so many more questions and I’m going to try to get us back because I made a list of questions before this event because I wanted to ask all of you what are some common issues that organizations can come up against? So I want to go through a bunch of them. So let’s say we’re trying to implement. So we have some DevOps happening, but we want to kind of push us towards adding security and weaving security throughout it. What are some common challenges that we professionals have faced when trying to do that? So anyone want to add in on that one? Okay. Well, I think. Oh, there we go.

00:39:20
Speaker 4: Okay, Sure. So you’re asking what are the major obstacles or challenges for Devsecops? So yeah, I would say Chris has already shared some info about this. Like we don’t think of security at initial stage. That is the major thing that that that’s causing problems to developers. So what they are thinking, we will prepare the full application and then we will start doing the pen tests. So that’s totally a wrong approach. At the end we will be bombarded with the vulnerabilities and then fixing those vulnerabilities will be the nightmare they have to change, change their whole design to fix a simple vulnerability within the access controls or something. So I would say threat modeling, secure design reviews are the top one priority. They should do this way. You will avoid writing bugs into the code. So I would say like a why not avoid bugs at the initial stage? Why write the bugs in the code then testing those and remediating those? So that is the important thing. We should we should always implement security at the initial stages of SDLC. Uh uh, yeah, that that’s, that’s it. Anyone, anyone else want to add? Yeah.

00:40:40
Speaker 2: So I will add more from a technical point of view actually. And what I’ve stumbled across is when people kind of, they go out of their idea and start integrating into, into the build. So they start implementing into the CI CD flows. And I see a lot of people getting concerned about build times and about compile times and about deploy times because you’re kind of stuck in the middle of the chain and people are waiting for this. That’s one. And once you kind of integrate into the CI CD, you also need to be vigilant about the amount of things that you tackle. So you need to make sure that you have improvement and you have some sort of some kind of graph going and showing that you have remediated those issues and not just accrue them.

00:41:30
Speaker 4: Okay. Yeah, good point.

00:41:32
Speaker 1: Yeah, that’s definitely one that I’ve seen where we’re good at finding tons and tons of bugs and no one is fixing any of them. And it’s like, we don’t need five more tools to tell us this bug exists. We need one dev to give us some time. So some of the other things I wanted to talk about so we have such a long list and I feel like we don’t have enough time and I could keep you here all day. So one of the items that we’ve seen a lot of problems with and that’s focused on in all of the top ten lists are authentication and access control, identity and authorization, like managing sessions and not having it be a disaster. How could organizations kind of focus on authentication and authorization because it’s such a high profile problem right now. So if each of you could give me one example of ways and we don’t we don’t all have to we don’t have to have six examples, but does anyone want to comment on how maybe we could try to get this right more often?

00:42:37
Speaker 3: I have very short answers, so I guess I could start first. So follow best practices. Don’t invent the wheel. There is everything documented properly if you just don’t try to experiment, cut the corners. Everything should be at least all right.

00:42:55
Speaker 1: Like that. Who’s next?

00:42:58
Speaker 6: Maybe also making sure folks understand the implications of security and what that means to be educated, how to properly authenticate, to be educated, to use two factor authentication to know how to create properly passwords. Just basics of of of providing good authentication authorization from just from the get go, which goes back to this point of best practices.

00:43:23
Speaker 1: I. Oh, Chris, did you put your hand up to say something?

00:43:25
Speaker 5: Yeah, I’ve got a I’ve just got another one I’ll throw in. It’s also pretty short and sweet. It’s keep it simple. How many times do we look at an application and say, why are there three different authorization mechanisms happening here? Why didn’t we just pick one and standardize on it? And the same thing is true for authentication. And so that’s kind of my high level guidance is let’s just keep it simple.

00:43:45
Speaker 1: I like that. And quite frankly, to add on to. Oh, Vitaly, did you want to add something? Yeah, please.

00:43:52
Speaker 2: Use one identity provider and standardize it across all of the application. Just make sure that everybody implements the same libraries. That’s kind of chiming on top of that.

00:44:04
Speaker 1: Yes. What all three of those gentlemen said, I want to endorse all of that.

00:44:10
Speaker 2: You can also verify on the code level that the developer developers actually called that library. So you can put it as a gateway check on the build.

00:44:21
Speaker 1: Very nice. Very nice. So we had a question in the chat that I want to bring up, and it’s a hard question and I get asked this all the time, so I want to hear everyone else’s opinion so I can give the best answer ever. But what potential challenges do we see and how can we address? I built code and how insecure it tends to be. What are some things that we can do to try to ensure if our software developers are using AI to help them write code, perhaps like GitHub, copilot or something like that? What are things we could do to try to make sure that code is safer to use? And I’m wondering, Zaid, could you start with some ideas? Yeah.

00:45:04
Speaker 4: So it’s like the same practices we will follow. We will do the have our standard code review. We will test the code with the different tools. Yeah. But I believe, like most, maybe a lot of common bugs will will be avoided through because they already have learned how to write the secure code. But we should always not totally. We don’t have to test that like we will think like we will not be testing that code. We have to test that code. We have to do our manual review. Yeah, that can be done. So it’s the normal procedure we will follow if a normal person is writing the code.

00:45:44
Speaker 5: And I can add some additional context on this. So like all of us, I’ve thought about AI and generative AI and how does this play into the life of the developer? And I think we need to think about this differently. We need to think about generative AI as something that can help a developer be more productive but not write code for them like and that’s where I’m seeing generative AI be really powerful right now. Like even a senior developer can can take advantage of some, some code that’s laid out like the generative AI gives them the framework of a particular routine and then they, they do the magic, right, with the five lines of code that, no, I could create probably for the next five years. But having the scaffolding set up by the AI allows every developer to be more productive. It allows junior developers to understand the structures. And so I think we just have to we have to be careful about about just concluding like GitHub copilot is going to write code for us and we’re going to have to look at it for vulnerabilities. Yes, we should scan designs point, we should scan everything in the same way. But let’s think about AI as something that can be something that makes our good developers great, makes every developer better versus something that’s a replacement.

00:46:51
Speaker 1: Oh, I really like that. I’m also noticing that companies are starting to come out with security AI models. So Owasp just launched a new project with Sharif Mansoor leading it about how to use AI specifically to answer security questions that we can design better apps. And then Microsoft came up with security copilot to try to help secure the things that the AI does. And so I feel like industry is really listening. They really listened to our feedback and I like both of your answers a lot. So okay, so we only have so much time left and I’m like, there’s so many good questions. So in the chat, Victor asks, How do you deal with different tools for detecting different findings in static analysis versus dynamic analysis and or not finding the pen test findings from third parties like sometimes. So one of the questions I wanted to tackle with this panel was vulnerability management. When we have tons and tons and tons of vulnerabilities and like how do we get on top of those and get those fixed? So does anyone want to talk about how we deal with different tools, finding different things? Does anyone want to volunteer for that one?

00:48:01
Speaker 4: Yeah, I can answer that. But Vitaly has raised his hand for it.

00:48:06
Speaker 2: I’ll start. Uh, so basically what you can start and aggregate the data according to the component that you’re being that you’re scanning. And I think most tools will not give you the same issues. Also, pen testers are not automated tools and they give different value. A lot of times the automated tools will not find things that the pen tester might find because, well, we have human brains. That’s kind of we have the ability to prod and poke and to interact with things in a manner that no automated tool at current point by generative AI might change that in the future. Currently we need to aggregate the issues according to the component, uh, to the component that we scan, and then we can kind of address all the issues in one kind of stack.

00:48:58
Speaker 1: Sad than eager.

00:49:00
Speaker 4: So yeah, definitely. Telly has put the right info here. Will add up something here. So a lot of tools will give you a lot of vulnerabilities. Then we have to do the false positive analysis. So every bug is not the valid bug. So if you talk about sast, so how do the false positive analysis is? I checked the sources and syncs so that that is the one thing. Then I another thing I check is if it’s an open source. If so, in our code we have a lot of code. What they do, they scan the open source code as well as the custom code written by developers as well. So 70% issues you will find in open source, but that’s not really the valid bugs. And talking about pen testers are finding the different set of vulnerabilities which has said set it right. So human testing is different. They have a broader vision on the application, how the application interacts. This these kinds of bugs tools cannot fight. They have a certain kind of rules. They just check the issues through those rules. But human testing want to insist here, like human testing is very important. Manual testing is very important. They will give you give you a lot of issues which any tool cannot find.

00:50:28
Speaker 1: Igor, did you want to add on to that? Because I saw you wanted to talk to you at.

00:50:32
Speaker 6: Yeah, no worries. I think you got covered pretty well. The only thing that I would say is that really, there’s no golden answer. There’s no right answer. There’s really. This is frustrating for everyone. You can even if you’re just using one tool such as what’s Pixar’s, you’re going to get dump of findings depending what actual tool you’re using. And as someone mentioned, I think it was. Vitaly Different tools would give different results anyways. There’s going to be some overlap. I think the key thing to note to note would be prioritization one. One thing that works other than mobility management platforms out there is how do you prioritize what you get? I mean, if you’re going to get 100 findings of sast and 50 of dust and 20 of of Pentesting and I’m really putting this way down, it’s usually in thousands. Then what do you really look at? I would I would start by just looking at criticality and severity and saying I want to start with top high and critical and SaaS and same thing in the US. Then maybe some of the top finding in Pentesting because the more the criticality, the lower the criticality is or severity typically more false positives will arise, more time will be wasted looking through the weeds, trying to check off every box. So I just one thing that worked previously would be prioritization of based on criticality and kind of going top down. Um, there really is again, I don’t think there’s really a right answer. Once you have those findings, it’s hard to, to, to ignore them, to neglect them, to sweep them under the rug because it is your responsibility to look at them. But if you had only a certain amount of time, I’d just I’d use that categorization.

00:51:55
Speaker 2: And criticality of the component as well.

00:51:58
Speaker 6: So exactly.

00:51:59
Speaker 2: A sensitive API is different than something that might serve just static content or something.

00:52:06
Speaker 6: Exactly. Types of projects and applications too.

00:52:09
Speaker 3: Yeah. I have one suggestion. I don’t have the answer, but just for people to try. There is a category of tools called application security orchestration and correlation tools, SOC tools. And this is basically like one stop shop where you could plug all your sources. And at least in theory, they should do some, well, intelligent analysis, maybe the duplication, maybe some prioritization. So it might help at least for you to increase the visibility of what you have on plate, because if you have like ten tools going each and everyone into like web console panels or I know spreadsheets, it will be a disaster. As you know, Igor said, those numbers are not like in hundreds. It’s usually thousands and more and more and more. So you really need a convenient solution. Otherwise, it’s it’s very hard job to solve.

00:53:03
Speaker 1: I agree. I agree. Okay. So we are near the end. We have seven minutes left and we have five panelists. So you’re all going to get approximately one minute. And I’d like to ask, which I feel is the best and most difficult question, which is if you are going to try to give the audience one takeaway from this panel or maybe something else in security, what would that be like? What do you wish that they would take away from this? Because I recovered so many topics and I want to have my takeaway be that we need to educate our software developers and quite frankly, all of it in security so that they can do their jobs securely and how we get there as a whole. Another panel for another day. But that’s the takeaway I’d like to have. And yes, we will share the recording. Since you’re here, you’ve signed up for the email and they’ll send you a thing from great, I believe, at some point. But let’s go. Let’s start with usages and then we’ll go. Chris Igor Zaid. Vitali Only because that’s the way I see you on my screen. And what would be a takeaway that you wish the audience would have from this?

00:54:19
Speaker 3: Well, if the audience are from more from security area like working in some security team, I would say that you should always focus on how to support the business. So not the of abilities that would matter. At the end of the day, it’s how you as a security team help the whole company, the product developers grow. And this is this is the thing that should be your main focus priority. And this is how you should build all your tactics and strategies from security champions to devsecops to trainings and and other initiatives. So we have a lot of tools, a lot of possibilities. We just need to be like, you know, integral part of the business overall.

00:55:06
Speaker 5: My call to action. Tonya, for the the audience, I’m going to reiterate something that I already said, and that is secure by design, secure by default, threat modeling. These are principles and practices that we need to put in place so that our developers can save time and eliminate rework because of security issues that they could have seen, they could have learned and understood how to see them in the design so that they can eliminate security and privacy challenges. So secure by design. Look up that I can never know how to say that correctly. Cisa look up. They’re secure by design, secure by default document. They published it about 2 or 3 weeks ago. Excellent resource.

00:55:45
Speaker 1: Thanks, Igor.

00:55:48
Speaker 6: Thank you. So the only thing I want to mention is obviously security is is complicated, right? There’s quite a lot of different factors at play. Curveballs will always be thrown. Threats will always be there. The best thing we can do is continue staying up to date, continue staying educated, continue exploring different tools and different mechanisms available to us to remedy these problems and continue practicing defense in depth, making sure that that we’re just we’re always we’re always assuming breach. We’re always assuming that that something, something wrong is going on, even if it’s internal. And we should we shouldn’t really let our guard down. I mean, it’s a challenging thing. It’s a difficult thing. But but continue being educated is great. Back in the day, we used to think, hey, if something is not external facing, who cares, right? It’s it’s our own thing. It’s our own internal thing, as we know. It’s it’s everybody cares. There’s quite a lot of things that can happen internally as they can externally. So do not make those assumptions and just take it easy one step at a time. You know, one certificate here, one core is there. Just stay up to date and stay aware, I would say.

00:56:49
Speaker 1: Wonderful that.

00:56:54
Speaker 4: Okay. Okay. So on closing doors, I would say raise awareness, educate your developers, develop, have a secure guiding policies. That is another thing. And another thing I want to mention about secure. SDLC is secure by design. As Chris mentioned, Am also a big fan of threat modeling. Strict secure designing threat modeling test every feature. If you if you are if you are introducing any new feature before that, do a threat modeling do a secure design of that feature, then only start doing coding and pushing it to the production. Yeah, these are my closing notes. That’s it.

00:57:35
Speaker 1: Nice. Vitaly.

00:57:39
Speaker 2: Uh, actually, I want to start with something that Igor actually closed with. So that’s take things. Baby steps, small steps, one step at a time. A lot of patience. This field takes a lot of toll on us. Um, it’s not easy being a security in the field of application, security and security at all. Kind of. And one more thing that I wanted to chime in on is that is not all about just the top ten. There’s the excellent guide that I want to show the application security verification standard that a friend of mine, Josh, is leading the project. It’s amazing. It’s a great tool for the developers to get kind of started with building the foundations right from the get go.

00:58:27
Speaker 1: Yes, Yes. Okay. I want to pile on to Vitale’s thing and say all of Owasp is wonderful. If there’s an Oasis chapter in your city, I absolutely 110% recommend you go there and meet the people. I have met some of my most wonderful, amazing friends through the community and their global events are amazing. Their projects are amazing, their tools, their books. Their everything. Yes. Thank you all so very much for being on this panel with me. I really appreciate it. Thank you all for sharing so much. Thank you to the audience for asking a trillion amazing questions. I know we answered as many of them as we possibly could. Chris, we are all jealous of your ninja shirt that you have in the background. Yes. And thank you very much, all of you, for your key takeaways, because it actually helped me summarize all the things you said in my head quite well. And with that, it’s exactly on the hour when we are supposed to end and say goodbye. And for once, I am not late ending a webinar and a good job. Me because I always talk too much. So thank you all again and everyone who is listening. You will receive a copy of this in your email so that you can see this and you can see the invitations for all the upcoming webinars that they’re going to have, including this Owasp Global Panel, Global Application Security panel. With that, I’m Tanya. Thank you. Zyga thank you Chris. Thank you. Igor z and Vitaly.

00:59:56
Speaker 7: You guys.

00:59:58
Speaker 2: Thank you for having.

 

Get Started
Read Bright Security reviews on G2