Resource Center  >  Webinars

AppSec Coaching: Elevating your team’s security processes


Speaker 1: Welcome everyone to the webinar. I’m Tanya Janca and I’m here with the Akira brand. And we are going to talk about ApppSec coaching so that you can elevate your team and your security processes. Usually it takes people 1 or 2 or three minutes to get into the groove and actually be in the zoom call with us. So, Akira, would you like to make small talk for two minutes while they arrive?

Speaker 2: Oh, is there anything I would rather do that makes them all talk? No, I would love to make small talk. Um, Tanya, what’s the most interesting security piece of news that you heard recently?

Speaker 1: Um, I have been hearing all about AI like we were talking about before this, and just different applications of how to use AI. And I was on a live stream a few weeks ago, and the guy brought up ChatGPT, and it took him under two minutes to get it to make him something malicious. And so I was like, oh, I thought I would at least take a few hours, but just asking it questions within a few minutes he had had it right, a very effective phishing email for him. And I was like, excuse me, I have to go scream. What about you, Akira?

Speaker 2: That’s a good question. Let me see here. I’m trying to pull up an article that I read recently. Hm. Keep riffing on your thing though, while look for this article.

Speaker 1: Okay, so another thing that’s really exciting that just happened is that OWASp has a new project led by Sharif Mansoor. He used to be on the board for OWASp, and he’s done all this cool stuff, and he has made an OWASp AI chat bot. So it is trained on every single piece of content ever created by OWASp and for OWASp members, for free for, I don’t know, I’m assuming forever because it’s OWASp. So if you’re a member of OSS, you can just ask it a question. And it was trained only on all of their thousands and thousands of articles and videos and content on apps like.

Speaker 2: Oh my God, is it free?

Speaker 1: It’s free if you’re a member, so it’s $50 a year to be an OS member. Or if you’re like me, I’m a lifetime member and it was 500 bucks. So for my whole life I get to not only have an email, I get all the different membership benefits like you used to get free course from. We had purple, but now all of our courses are free so everyone has those. So you still get them, but everyone gets them. There’s there’s like a capture the flag secure coding game. There’s like a bunch of membership benefits that are pretty cool. And you get an email address that ends at OSU, dawg. So it’s pretty win.

Speaker 2: Oh, Eduardo says he’s a chapter leader. Awesome. And, Juana, where are you a chapter leader at? Let’s see if he replies in the chat here. We’ll find out. We should look him up. Like who? From Natal city, Brazil. Dope. That’s so cool.

Speaker 1: I spoke for the Apollo chapter in 2019 and it was incredible and they were very nice to me, despite the fact that I can’t speak any Portuguese.

Speaker 2: Well, that’s really kind. And the food was.

Speaker 1: Amazing and the people were beautiful, and I was like, why do I have to go home?

Speaker 2: Yes, I can speak a tiny bit of Portuguese, but only because I know how to sing some songs in Portuguese but don’t actually know how to speak it. I can just like sing you some stuff in it, because I used to do a couple Edda, which is a Brazilian martial art, and part of that martial art is doing a lot of music, including singing. So yeah, if I ever get lost in the street, I could, you know. What’s that?

Speaker 1: That sounds like the most fun of the martial arts. You get to sing and throw people.

Speaker 2: Yeah, it’s it’s that’s exactly it. Yeah. Trip people and stick them in the face. And you’re singing the whole time. Oh, gosh. It’s awesome. Okay.

Speaker 1: So we should probably start because otherwise Lucian and Amanda will be like, what are these two ladies doing? Okay, so I’ll start again. So welcome everyone to the Bright Security webinar on Asset Coaching. Akira Brand and I, Tonya Janka, are going to talk about elevating your teams and your security processes today. And so we would love to see lots of questions in the chat as we go through this. Akira and I are both friendly, as you know, and apparently we might sing you the answers. So. This is our agenda for today. So we’re just going to introduce ourselves. And then we’re going to basically talk about what what do we mean by coaching within application security. And we’re going to clarify sort of the two sort of modes that we’re talking about. And then we’re just going to hopefully talk with all of you. I have a list of discussion points, but we are happy to answer lots of questions if you’re up for it. And so with that, this is us. So Akira, would you like to introduce yourself?

Speaker 2: Yeah, sure. Hi everyone. Thanks for having me. I’m so excited to be here. Um, my name is Akira Brand. I’m an application security engineer at resilience. We are a for profit company that exists to empower and scale nonprofits. It’s very cool work. Check us out. Recently, um, I’ve been working there. I think about God eight months now, which is awesome. I really, really enjoy working with our engineers and working with our internal stakeholders to build an asset program. That’s why I was hired on was to build a program from the ground up. I also co host the Application Security Weekly podcast from time to time. So I pop in, I pop out, you can see me. Oh gosh, I’ve been doing that for almost a year now. So it’s a really good opportunity to if you want to listen to it, to hear lots of different industry perspectives on what’s happening with OpSec, just keep your pulse on the industry. We do a lot of new segments and stuff. It’s really, really great podcast and I speak all over the place. I love evangelizing OpSec. I love talking to software engineers about location security and how they can make their own processes more secure. The last thing I’ll say about myself is that right now I’m really in the threat modeling. So if anyone ever wants to talk threat modeling, like hit me up on my website, Akira Brand and has my contact information there, I am really interested in hearing anyone’s opinions on how to do it properly, because I’m starting to do it at my work and it is a blast. So that’s me in a nutshell.

Speaker 1: Oh my gosh, Akira, you should apply to Threat Mod Con. It is the first conference completely dedicated to threat modeling, which it’s just before global OpSec in DC this year on October 30th or 29th. I forget which day, but I’m going to send you more details. Or we could put threat mod con in the chat if we know how to spell that. Um, also the open the open SF, can you tell the audience briefly what that is and why it’s awesome? Because if they haven’t heard of it, maybe they should.

Speaker 2: Yeah, absolutely. So I also work a little bit on the communications side of the open SF Foundation. The Open Source Foundation is fan flippin tastic. It’s essentially a giant organization that is dedicated to securing the software supply chain through open source. So there’s many, many initiatives within the open SF that exist in order to empower software engineers to build and ship secure software in the open source ecosystem. Check them out. I believe their website is open source, or you can follow us on Twitter, Instagram, Facebook, LinkedIn. Just look for open SF.

Speaker 1: Awesome. They’re great. They are really great. And I didn’t know you were a part of that. That’s fantastic.

Speaker 2: Yeah. Just started like last month.

Speaker 1: Well, congratulations, because they’re really cool and they’re doing really good stuff. So that’s awesome to be involved.

Speaker 2: Let’s hear about Tanya.

Speaker 1: So I’m Tanya Denker, and I’m the founder and CEO of Wee Hag Purple, or as I like to call it, I’m the head nerd. I wrote a book called Alice and Bob Learned Application Security, and I’m writing my next book where Alice and Bob will learn secure coding. This time I speak at conferences and I give secure coding training and application security training. That’s generally what I focus on. And so I’ve been a nerd and I’ve done lots of nerdy things. And it’s July, so that means year 27 for me in tech, which is quite a long time. Um, yeah. So that is what I do. I do lots of that stuff. And when I can, I hang out with Akira. And so today we want to talk about the two types of apps coaching. So Akira would you like to talk about coaching developers. And then I’ll talk about coaching apps tech teams. And then we’ll get into the big discussion.

Speaker 2: Yeah, sure.

Speaker 1: So um.

Speaker 2: We decided to kind of split this by what we have the most experience in, or at least like where we feel the most comfortable talking about it. And for me, what I’ll say is I personally have not coached apps teams, but I have coached a lot of software engineers. So let’s talk about like what does that mean? Right. Essentially what that means is you work with software engineers throughout the system development lifecycle in order to make sure that secure coding principles are built in from day one. Um, this is a lot different than just throwing a WAF in front of your app or scanning it once with a sass and saying it’s good to go. This is actually a really highly collaborative experience between the apps team and the software engineering team. Like I said, to make sure that each phase of that SDLC is done in a secure manner. So that’s that in a in a nutshell. What about you, Tanya? You want to talk about coaching apps like teams.

Speaker 1: Yes. So when I started we had purple. This was one of the things that helped basically us launch it. And so this may sound odd, but when I learned apps like Akira, there was no book. There was no like I would go to conferences and try to learn, but people would rarely talk about how they build their program and how to make sure the program is effective. They would just be like, I’ve heard you have to buy a Dast, so I bought one. What do I do now? And so over the years, I started learning, especially from working with so many apps teams, how a team could be more effective, how they could get more bugs fixed, how they could get better coverage. And so then I started creating blog posts and materials on that. And someone wrote me and said, listen, can you help us build our program? And I was like, oh my gosh, yes. And so then I started offering a service of asset coaching, where basically that specific company and a whole bunch of companies, eventually I’d meet with them regularly and we would go over like, what are we trying to achieve? What are our goals? How close are we getting to them setting goals? And then eventually we created, like the Full Stack Foundations program, where we help you build your whole thing from scratch and show you what all the things mean. But the idea is, is someone that’s supporting you, that shows up and helps your organization make permanent, meaningful change. And that’s what coaching means for anyone, right? Like whether you’re teaching a developer to become a true security champion or you’re helping an app stack team go from sort of responding to security incidents, being reactive all the time to being proactive and getting ahead of the game. And like actually releasing software that’s in good shape to begin with, rather than chasing around and accidentally releasing insecure things knowingly. So I feel like both of these things are really, really helpful. And I feel like, well, let’s go on. So this is the next part. So this is the coaching discussion. And so we actually don’t need to share slides with you and be super fancy. During this time I was thinking you could just see me and Akira and oh have us on Gallery View so I could see like these nice four squares. But I was thinking. So I have a bunch of talking points, but I was also thinking that the audience could ask questions if they want to. So the first one, the first, because you and I came up with lots of topics. So how can an effective coaching and training program benefit organizations in terms of security, posture and risk mitigation? I feel like that’s a really long, ugly group to say. If we’re going to drink tea.

Speaker 2: Yeah. Fantastic. Very articulate.

Speaker 1: But if we’re going to try to coach an abstract team or work with a team to help them do better, what are some of the things that that a team would want to be better at it maybe.

Speaker 2: Yeah. So there’s a lot of ways to measure how you know, you’re doing a good job, right? Um, for us, the resilient we use something called the Sis scores. The Sis is a thing called the center for Internet Security. And they have a vast amount of, like, topics and subtopics of essentially things that you can measure to see if you’re doing a good job with security at your workplace. One of those SES categories is application security, SES 16. And within that SES 16 category, there are, I believe, 16 subcategories that you can measure against to know. Either you are you are. There’s either ranges. Right. Like you’re doing it maybe from like 0 to 10, which is up to your organization to set that metric. Or it’s to say yes or no. So for example, um, doing a distance scan is I think like 16.16, I can’t remember. You can look it up. Um, yes, I know, um, and that’s like a yes or no, either you are doing a test or you aren’t doing a task, or you are doing a SAS, or you aren’t doing a SAS. Um, or then there’s like developer education and coaching, which is why we’re here today to talk about that. And that’s more of a range. Right. Like so maybe you give them a thing to do throughout the year or you like do like ongoing trainings, lunch and learn and stuff like that. Um, what I’ll say is that we have found that that scoring is really useful for us to know what to measure. Otherwise it can be kind of nebulous, right? Like a company can kind of be like, well, are we secure yes or no? And it’s not that easy, right? Like there’s so many factors that go into knowing if your security posture, as we call it, is good or bad or anything in between. Right. And so we love this. We use it for all of our security, um, controls essentially just to have as a basic benchmark of where we are. But Tanya, maybe you can talk a little bit about what else you’ve seen, because I know that is not the only thing that people can do.

Speaker 1: Yeah. So there are a bunch of frameworks and some of them can be quite heavy. So there’s b sim. So b I B’s I’m which I believe is from synopsis. And then there’s also OWASp Sam which is SRM. So software assurance maturity model. And they’re both really heavy. Akira. There are not 16 things. There are hundreds of things. And. So here’s the thing. So I’ll ask Sam. So that’s the one that I’ve read and spent the most time with I really like it’s awesome, but I’ve never worked at a company where we have enough people or money or support for the security team such that we’d be able to do the entire Sam, or even just be able to do every single category, just do something in every single category of Sam, because it’s so thorough. But what I like to do when I work with organizations that so often organizations, they want a framework to follow. And so I’m like, how about this? How about we pick three things or five things from Sam that are that we think will give us the most value, and we just work on those this year. And then next year we either continue to work on these because we’re doing a great job and we think we’re getting a lot of value. Or maybe we’ll change 1 or 2 out as you wish. I feel like so when you have a framework you can compare yourself to others. That’s helpful. But I also feel it’s just helpful to know a list of things that people do for apps and like the idea of okay, so Security Champions program. Okay, so I’ve heard of this, but what do I do? And what do you get out of having one of those. And I feel like. Being able to list some of the benefits of each one could be helpful to the. So I talk about security champions a lot, and I know you do too, because you are building, I believe, a developer education program at the moment, but I think that so the question was supposed to be about program benefits. I feel like if the frameworks could say, here’s the 16 things we want you to do, and here’s how you do each one. And here’s the the potential benefits of each one. Because like when I do a champions program or when I do scans with different tools, when you do a scan with a tool, the benefits are obvious. It’s going to find hopefully a whole lot of your bugs or the grand majority. And then you have a list of things to try to fix, right. So that benefits really obvious. And some of the benefits are less obvious, like with security champions specifically. I’m sorry I keep talking about that one, but it’s sort of my faith right now. Like some of the benefits are really obvious. Like, oh, those champions will be responsible for some of the security work happening on those teams, but other things will be that people don’t realize is they’ll report a security incident to you, like they’ll or they’ll point out to you, oh, that other team’s doing this thing and they’re breaking this policy. And, you know, I don’t want to be known as the person that tattle tales. However, I’m really worried about this. Like they’re rolling their own crypto, like they’re writing their own cryptography instead of using, oh, a product that is made for that. Don’t write your own crypto anyway. But do you know what I mean? Like them reporting potential issues to you, a more positive security culture. So I feel like if those frameworks could list this is the potential benefit you could have, then you could shop the benefits that you want and then choose the controls that work best, or the Sam controls or the BSM controls. ET cetera. That would be.

Speaker 2: You pointed to something really interesting, Tanya, which is like a sort of like soft benefit of doing these controls is to know, like, a good way to know that it’s working. Is are the engineers talking to you? Right. Um, when I first started at Roselia, I didn’t really have a lot of engineer engagement because no one knew who I was. Right. And then when I started working with each of the pods, like, individually, we work in pods. And so we would go, I would go in and work with them on a particular project and take it from a security viewpoint. All of a sudden now I get I get hit up probably like once or twice a day from engineers, like wanting to know, like, hey, like, is this a secure thing? I’m trying to do this thing with zero. I’m trying to do this thing with this particular section of my app. It’s not working like, or like they’ll actually send me like a snippet of code and be like, is this secure? And I think that’s the coolest thing ever. Like, so that’s a good way to know. Like culturally is this working is like how much collaboration is going on here?

Speaker 1: You have built trust.

Speaker 2: That is.

Speaker 1: Awesome. Yeah.

Speaker 2: You know, it’s working.

Speaker 1: I have worked at places where none of the devs ever speak to the software or to the apps team. They’re like, oh, that’s that mean team that says no to us. So that’s like, to be quite frank, that’s a fantastic sign that you’re doing a great job.

Speaker 2: Oh, thank you for saying that. Yeah, it feels really good. I am also like I mean, how do I say this? I think we had really good culture from the beginning too. And that really helps. Right? Like the engineers are really engaged. People are really curious. Like, um, a lot of people work at my company because it’s also like tech for good. And like a lot of people are really invested in the mission. And I think that one of the things I did is I actually communicated like, why does apps exist? And like, what are your responsibilities in like making secure code? Like, why does this even matter to our app and to the customers that we serve? Because we serve a lot of marginalized peoples that have been just historically like just pushed to the sidelines. And it’s actually really important to have security in our organization, because if we have a breach, it’s not just our businesses data, it’s all these marginalized communities that could actually be impacted in a big way. So people are really on board with that at my company, and it’s just really cool to see. So thank you. I want to share that compliment as well with our with our team, because they’re doing just such a good job for sure. Yes. Oh, even.

Speaker 1: In the chat and QA, which one do you want to do first secure which one?

Speaker 2: I just saw the one question which is how to take these frameworks to managers when some of them think Apex focuses on vulnerability management. Let’s have you take that one time because that’s more about like coaching and apps team I think.

Speaker 1: Okay. So generally I. So I talked to the managers and I asked them what they want to achieve. And I often make a lot of suggestions of things that we might want to achieve. And I only do a framework if they specifically want one because I tend to find that each. So in my opinion, each abstract program serve a snowflake and they’re very different. Like some programs really need a lot of tools, and you have a lot of engineers that are able to do them. But sometimes you have an APS team where it’s two people who used to be in compliance who have very, very little technical skills. And so sometimes you want to outsource some things or you want to work with the devs to help have them help you automate stuff. So I don’t usually bring them a framework. I ask all sorts of questions about where they’re giant things that are on fire, because we want to put out those fires and triage as quickly as we can. But then also I talk about like, what types of talent do you have on your team? How many people do you have that are going to run this? Because I want to build something that’s not going to crush them and burn them out, right. Something that’s actually achievable and also what their threat model looks like. So what types of threats does their organization and do their systems face? Because quite frankly, a lot of companies, the threat that they face is just like theft, right? Like or general embarrassment if their website gets owned. But it’s different if you are working with companies like, for instance, you’re dealing with like systems that help marginalized people and they might have specific threats that face them. So you might need to protect your user base more than the average company. So I try to take all those things together. And then rather than saying, well, we should do cis benchmarks or we should do SIM or whatever, I’m like, these are the things we should do. And then I gather like information on each of those things. But having the frameworks in your head is pretty darn helpful, so you can give a lot of options. What do you what do you think?

Speaker 2: Like, yeah, I just want to like restate what I heard from that, which is essentially like, don’t go in and just throw a framework on top of something and expect it to work. Right. More like find out where the problem spots are, discover like what impact a breach would have on the business as well as on your customers. Um, and then from there be like, okay, we can use maybe some things from CIS, we can use things from these other, these other frameworks that you mentioned, Tonya, but don’t necessarily lead with like, oh, I think we should use this now.

Speaker 1: Um, that’s my way. That’s not necessarily the right way. Totally. Like, I know a lot of companies that start with a framework, especially if they used it at their previous organization and it worked really well. They’ll want to bring it with them, and that’s smart too.

Speaker 2: What I’ll say is what we did at resilient is we started with a framework, but we didn’t like tell people we were doing a framework. We just did it. And then like, we’re measuring our own progress against the CIS, but we’re not saying like, hey, engineering managers, we need to boost up 16.9 because that might not translate well. It might mean, I don’t know, like it could, but that’s just not what we did. Right. So we’re using our frameworks much more internally to our security team than we are, like communicating that framework externally to our internal stakeholders. I don’t know if that’s good, but it seems to be working. So I’m going to roll with it.

Speaker 1: There’s for OpSec. It’s not. So, you know, like organizations will have SoC one or SoC two compliance to prove that they have a certain level of security assurance. It’s not like that with apps. I’ve never heard of a company being asked like, well, what level are you rated on OWASp? Sam it’s like, well, that will we’ll have to hire a consultant for a year to get you that number. So no. Whereas with Soc2 compliance, it shows like a certain amount of security across the entire organization. These frameworks only help with the software. There’s a there’s another question in the chat that and then there’s questions that are also in the Q&A. But can you offer some tips for dealing with software engineers that are using a tech stack that’s beyond your knowledge? What should you do? What should you not do? Do you want to start, or did you want me to start on this one?

Speaker 2: I’ll start on this one because this is like speaking to my soul. Right when I started at this last company that I’m working at, um, I did not know our tech stack very much at all. Like, I didn’t know the language that we’re working in. Um, what I’ll say is that if you’re lucky. Your engineers are accepting and good people and interested and engaged, right? So it’s okay to ask questions like a lot of questions like, can you please show me in the code how this is working? Can you walk me through it? Can you show me like where this X class is calling y object and move? The data is moving through Z, you know, function or whatever the heck. Um, so so that really weirdly. But you get the point. Ask them questions. Ask them a lot of questions. Now, if you have engineers and maybe a little less willing to work with you, you might have to do some self study on particular things that people have questions on. What I did at the beginning was I was like, oh man, I’m going to like learn this entire code base like in the first month. That’s unreasonable. Like, that’s not a good thing to do. That’s not where you want to spend the bulk of your time. One thing that is really weird in the application security world is like the question of like, do you need to know how to code? I think it really helps. Like, I wouldn’t want to do this job without at least a rudimentary understanding of how code works. I think you’d be really sunk, otherwise you’d have a really hard time doing your job and communicating with your engineers. However, you’re not an application developer. That’s not your job. You’re an application security engineer. So lean on the app. On the application developers, ask them a lot of questions. Um, another thing I’ll say, the last thing I’ll say is that it’s good to do some research on like common vulnerabilities in your code base language. Right? So if your, your code base is and C, you can look up like security vulnerabilities and C and then you might be like, wow, I really think we should refactor to rust because apparently that’s what everyone does when they learn about security vulnerabilities in C, or likewise in JavaScript or Ruby or whatever it is, right? Also, it’s good to know that a lot of frameworks do take care of a lot of security vulnerabilities. But sometimes for an engineer, they think, oh, I’m just using this framework. So therefore my code is secure and it’s really important to be able to communicate. Like actually that’s like only a place to start. It’s not the end all be all like you can’t just use react and like yes, they have good security measures built into their framework, but it doesn’t necessarily mean that that code is secure. So you’ll learn this through doing your research. But you don’t have to be extremely well versed, for example, in how to write web applications with react. It’s good to know like it’s good to have at least a basic understanding, especially with like software architecture. Like if you don’t know what MVC is, I would definitely recommend like looking at what that means if your company uses an MVC kind of architecture, otherwise you’re going to be in a really bad spot, but don’t feel like you have to become the application security. Excuse me? Don’t feel like you have to become the application engineer. You’re the application security engineer. Your job functions are different.

Speaker 1: I agree. I just yeah, just flat out agree. I also sometimes I’ll ask my security champions. So like what are you working on. Where are you working on next. You know what’s coming up. What’s coming down the pipe. And then if they tell me oh we’re going to I remember they’re like, we’re going to do serverless. And I was like, oh, cool. And then immediately I was like, I need to learn about serverless. Like, what are the best security practices for this? So yeah, I, I do not know everything, but I read up, so I sound smart. There’s another question in the chat. So there’s or in the Q&A and there’s two that I liked. So what are essential metrics to start off with with building an apps program. And can I start with this one. Is that okay.

Speaker 2: Yeah for sure.

Speaker 1: So what I like to do is build goals. So things we want to achieve. And then I figure out activities that I think will lead us to those goals, and then how to measure those activities, which I know might sound backwards. But if you are, if you’re measuring like how many vulnerabilities get fixed every month, that’s nice. But if what you’re trying to achieve is fewer vulnerabilities in prod. That might not be the best way, the best metric for you to measure, right? Instead, what if we can make sure the vulnerabilities never even get into prod in the first place by giving them secure coding training, or by giving them a bunch of tools in their IDE that help them do tests. And then we do tests in the Cicd, or we do this, or there’s so many things that could lead up to less vulnerabilities in production, right? And so often they’ll say, well, we need to buy X tool. And I’m like, okay, cool. What do you want to achieve with that tool? What we want to scan with it okay. So you want to scan, you know this the five whys you ask why five times to get to the real answer. So why do you want to run scan. So to find vulnerabilities Tanya okay. Why do we want to find vulnerabilities. And they’re like because our security posture is pathetic and we want to be more on par with our peers. I’m like, okay, so that’s what you actually want. You want to be on par with your peers. For people that have similar threat models, they’re like, yeah, I’m like, okay, so that doesn’t necessarily mean you have to buy this tool, right? There’s like a bunch of things we can do to get you to that goal. So like let’s find out what your security posture is now and then where you want it to be. And then let’s make that your goal. And we will measure that. And we’ll do a bunch of things to get us there. And they’re like, oh, because traditionally a lot of OpSec is writing checks. It’s buying tools. And then magic is going to happen. But you actually need humans and processes and other things, or you’re not actually going to get all the value out of those tools you bought. So that’s so I know that’s backwards. Anonymous user who asked that question. Akira, what do you think.

Speaker 2: So. I have like a totally different take, which is fine. Your take is also really good. Take. My take is very different. So when you’re first starting an appetite program, what I think you should do is do something a little bit more broad and less focused on numbers, necessarily to start out with, what I like to do is I like to think of it like your threat modeling, hey, your security program. So Adam Shostak is like the seminal person on threat modeling. He created it at Microsoft. Yeah, I have that book to around here somewhere. Um, anyway, but he has like four questions. That is a framework for threat modeling. The first question is what are we working on? The second one is what can go wrong. The third is what are we going to do about it? And number four is what did we do a good job. So you can actually ask yourself like as far as starting metrics, instead of saying like, well what do I want to measure, go step back and be a lot more generic and say, well, what am I working on? And then you can say, okay, what’s going to go wrong with and what I’m working on? And then from there you can start saying, okay, now how am I going to measure what’s going wrong? Then? What am I going to do about it? Okay, well I’m going to do X thing. Then you can start to measure what are you going to do about it in X in like in Y. Um metric. And then did you do a good job. That’s easy metric. Now you can create those as you go along. Like say for example like I’m working on an integration with a third party application that has like too much permission with their API. Right? Like the way that we’re using it, like too many people can get too many permissions. That’s what I’m working on now, what I can measure. Then the second question, which is what can go wrong? Which would be like, well, like I’d have too many users have too much, um, access to too much data, then it can be like, okay, like let’s measure. We have maybe like only ten users can do this as opposed to the 35 that would be able to to access this data. And then what am I going to do about it want? I’m going to make it only go down to maybe 5 to 10 people can actually access this. That’s a measurement. Did I do a good job. Yes or no. Right. Five people or ten people were able to access it. 35 people, 40 people were not. So you can do that like in a larger in a larger way, maybe. Tonya like you have some thoughts on that as well. But that’s what I would start is I would just start really broad and not get too stuck in the minutia of like a need to have the 16 score be perfect at the beginning, because that’s just too that’s too much pressure.

Speaker 1: Usually. So ever since I left the Canadian government, usually I’m a consultant. And so when I come in I need to show value immediately. And so here is my cheater consultant thing that makes every manager want to renew my contract. I do a triage of all their apps, so I get all the previous scans that they’ve done and I smash it into Excel, and then I figure out what their top three apps bugs are that they have across the board that are scary. So if you’re missing one security header, that’s not of high priority, that even if you’re missing it in every app, that’s not the thing, right? So your three big like nightmare things. And then I do education on each of those three and focuses on those three. And then after like four or 5 or 6 months notice like there’s like only 20% of the number that we had. So it’s like I took injection out of production completely. I’ve taken cross scripting and reduced it by 80%. And now we’re actually using content Security Policy header like you wanted us to. And so if you can show like this big change very quickly you get renewed. Yeah. Yeah. And and so triaging like Microsoft Excel can be like the best security tool that and like a good browser but basically like just smashing that stuff together and seeing oh like we have tons of this or we have a couple of this absolutely terrible, terrifying thing. And so if you can clean those up and basically like put out the fires and make them stop having so many nightmares at night, that is a good way to get renewed and and also to just show value immediately of your program and the work you’re doing. Because quite frankly, I see a lot of companies where it’s like this soft, nebulous thing and it’s like, okay, so our vulnerabilities have gone down 5% in like a year. I don’t feel like we’re because they’re still producing new bugs. They’re still like, they’re not fixing legacy. ET cetera. Sometimes. Okay. So I’m going to stop harping on this soon, and I will for sure answer the other question in the Q&A. But like sometimes I’m dealing with companies where their apps tech team are super smart and they have six tools and they’re like, we want to talk with you about which is the next tool we’re going to buy. I’m like, awesome. And my first question is, how many bugs do you have right now in prod that are high or critical? And they’re like, I don’t know, like thousands. I’m like, then don’t buy another tool. Buy an engineer, buy a coder. It’s just going to fix bugs all the time by something that will fix these bugs. Don’t spend your money. You don’t need a seventh tool confirming that you still have all those bugs. You know for sure these are not false positives. If you have six tools telling you the same thing and they’re just like, oh, and so one company, we got an intern and he was just like, smash, smash, smash, smash like little bugs. Not high priority, but he was like, he was basically free because he’s an intern. You pay him so little compared to a real OpSec engineer. And just having him, like, fix little bugs. And I remember anyway, like many companies where they decided to invest in that and just fix all the critical bugs for like a year, like, oh, we’re actually way more secure now. I’m like, and now you can afford that tool because you don’t need to just fix bugs all the time, because now you’ve created a culture of fixing bugs. And so sometimes it’s not that you need to write another check. It’s not always the answer. And I am a person that receives checks. So just to be clear, that is not what’s in the best interest of my company sometimes. But sometimes, like you just got to roll up your sleeves and do the work.

Speaker 2: Yeah, I agree. Yeah. I mean. One thing that we’re doing. This is kind of going back to like coaching engineers. One thing we’re doing is like teaching them also like how to use the tools that we already have before we buy another one, like we use Snyk. Um, and what we want to do is empower developers to actually use the tool themselves while they’re writing code, so that I don’t have to come back in X amount of time and be like, hey, like we have all these high vulnerability bugs or all these critical vulnerability bugs. Like we need to fix them. We want to integrate that tool into their SDLC, which is like the whole reason for an stack engineer. Right? So like again, like kind of even circling way back around to like the whole like, oh, I don’t know the code base. Well good. They don’t know how to use Snyk. So let’s work together here.

Speaker 1: You know.

Speaker 2: Yeah. So I feel like.

Speaker 1: It’s teaching each other.

Speaker 2: Yeah. You were definitely teaching and learning from each other. Absolutely. For sure. For sure I.

Speaker 1: Like that the next. So the question in the chat and or in the Q&A, then I was thinking, unless there’s more questions in the chat or the Q&A, then we could go on to coaching developers, because that is something I know you’re really passionate about, but really quickly, can you speak about that? The different can you speak about OpSec versus product security and how are these two related? Is OpSec more generic and product security more specific? So I actually wrote a blog post about this that’s totally coming out next week on the Purple blog, because this is a hot topic, but my definition of product security is that you do the security for the entire product. So if it’s an IoT device, that means there’s hardware and software. If it’s a software product, then it’s basically the same as OpSec, except you’re just focusing on this one product. So if it’s product security and there’s like physical stuff like let’s say it’s one of the scanners at the airport, then you need to know the how to secure the hardware. You need to know how to threat model like people coming up and doing stupid stuff like putting garbage inside your product because people do stupid things while they’re waiting in line at the security desk. So I view it as like product security, as like all the security for this one product, whereas APS is more a focus on all the software across your entire org, and it’s just focused on software. Do you agree or disagree or do you want to add anything?

Speaker 2: I agree with you. I think that they they like relate I guess, but they’re not like related, right? Like I wouldn’t want a product security person to also do application security and I wouldn’t as an API person, I wouldn’t want to do product security. I think they’re just like completely different, um, work. I think they’re just different jobs. I’m not even sure how the skill set crosses over, because I don’t know a lot of product security people like, I know a couple, but I don’t know a lot about what they do on their day to day job. And I’ve never worked at a company that actually has product security is like a formal job title.

Speaker 1: So it’s new. Yeah, it’s it’s the new hot job title. Like when OpSec engineer became DevSecOps engineer. It’s like just I want to be paid 20,000 more dollars per year, please. And so fanciness of. So I interviewed someone on the We had Purple podcast named Ariel Shin. And if you’re going to watch one episode she’s so amazing. She’s like really, really good at laying things out in a super clear way that are quite complex. And so she talked about how her title basically switched from ops engineer to prod sac when she when their company segment got purchased by Twilio. Twilio. Sorry, too many company names that are weird words, but she’s like, but here’s the thing is that I was that tech engineer that worked on one big giant, huge project called segment, right? And so I was dedicated to this one giant project or product, and it’s just software. So I’m sort of doing apps and I’m sort of like the product security engineer, because I do all the security for this one giant project product versus normal apps that engineers are usually in charge of, like tens or or hundreds or thousands of apps. And you try to do big moves across a lot. Segment has like one big, extremely important product and she knows it inside and out. And so I feel like there’s overlap. If your product is just software for sure.

Speaker 2: Um that’s fair. That’s fair. Huh. Interesting. Yeah.

Speaker 1: But I wanted to ask some questions around like coaching of software developers to help them write more secure code and, and make more design more secure apps. ET cetera. So. What are some of the common misconceptions or myths around coaching a software developer on security? What what are some of the things people tell you are going to go wrong or right?

Speaker 2: Oh, what are some things people tell me are going to go wrong? You know what? There’s this myth that software developers don’t care, which is not true. That is not true at all. Software engineers like care a lot. The thing is, is that you have to frame your coaching in such a way where it works with their workflow, and not the other way around, right? Security people think about security all day long, right? It’s like, oh, that’s so cool. I can go really deep in the security topic. Software engineers do not think about security all day long. They like to think about security, but they have maybe a little bit of brainpower to do it. So if you come to them and you, like, dump the entirety of how to threat model on them and like ten minutes, they’re not going to enjoy that, right? They’re not going to use it. They might think like, oh, that’s cool. But like that has nothing to do with me. So if you can do it in really small segments, it works better. Conversely, if you can do something where you give like a class that people come to and they know that they’re going to come to it for like a couple of weeks, and if you give them a little bit, a little bit of pre-work, like reading or like coming up with like a diagram of like an architectural, an architectural diagram of, like their segment of the application or something like that. That works as well. But when someone asks you a question, the thing that you should not do is like, write them like a ten paragraph answer. They don’t have time, they really don’t. And then conversely, like I think there’s a temptation to get really intimidated by engineers, at least in my case. Like I can feel like, oh my God, like, they do know so much more about this code base than I do. And like, I don’t know. And it’s okay to say you don’t know and it’s okay to ask the engineers for help. Like in for clarification, right? Kind of what I pointed to earlier when I was answering the question about not knowing the code base language very well. So that’s what I would say. Um, trying to think if there’s anything else that people told me wasn’t going to go. Well, I think just that that big one is the engineers aren’t going to care. That’s total BS. It’s not true at all.

Speaker 1: I agree completely, and I think sometimes maybe people think that because like when you’re answering, you’re saying because they only have so much brainpower to listen to this thing. It’s not that they don’t have ginormous brains, it’s that they have 27 priorities set by their boss. Oh, I’m supposed to fix this? This bug? Oh, I’m supposed to add this new feature. Oh, I’m supposed to meet with this client to talk about requirements. Oh, I’m supposed to evaluate this? Oh, I’m supposed to. And then one of them is security. We’re just one. And so it’s not that they don’t care, it’s that they have to care about a whole bunch of things and make progress on they can’t just do security all day as much as a cure. And I would love it if they did that. We’d go out of business pretty fast if they didn’t ever build features. Yeah. Another myth, another myth is one that that you and I talked about offline where we were talking about. So I’ve heard people say to me, well, just tell the developers to fix the bugs and they’ll just fix them. And, and we spend so much time. He’s had so much time trying to convince them to fix bugs. Do you remember your reaction where you’re like, oh my God. True.

Speaker 2: Yeah, just do it. Like, what’s the problem, man?

Speaker 1: Because they’ve been assigned 57 things to do. And we are one of those things. And if their boss says build this new feature and oh yeah, you have like some email from the security team saying, fix this bug, your boss decides if you get a raise, your boss decides if you still work there, your boss decides what your performance review says and all the cool new projects, right? And if you’re not doing like the stuff your boss asks, you don’t get the cool new project. You’re not going to get a big raise. You’re not going to get these things. It’s like, oh yeah, Tanya’s just doing all the security stuff all day long. I remember my manager saying, like, why are you just doing the security stuff? And then the security team offered me a job and she was like, oh, I see what was happening here. But but it’s, I guess, like the myth that you just tell them to fix things and they’ll just hop to it and just do it immediately. And it turns out that’s sadly untrue.

Speaker 2: The thing is, is that like. Something that security teams can do to really improve performance is to actually get the engineering managers on board with what they’re trying to do and not necessarily go through the engineers themselves. So if you can get the VMs on board and maybe even the director of engineering, I speak from experience here, if you can get them on board to make security part of the career path of advancement in the organization, you are going to have those bugs get fixed. You know what I’m saying? Because like, there’s the whole question of like, what’s in it for me? Everyone human, every human has that. When the chips are down at the end of the day, like people are going to do what’s going to be what’s best for them, and that’s fine. There’s nothing wrong with that. So if you can be like, hey, if you can incentivize with, um, career advancement, which equates to more money if you’re doing it right. Um, that like, security could be part of the coding process of an engineer. Then you’re going to see that, um, I’m lucky at resilient people are like, yeah, that’s actually like what we want to do. We’re actually working on building security into the career path of software engineers at Brasilia. If that doesn’t exist at your company, um, it’s definitely a good idea to try. It’s a good idea to try to get the director of engineering on board with that, or at least get the engineering managers on board with like, hey, like what? What can we give engineers in return for their their best efforts with security?

Speaker 1: I love that idea and I’ve actually never heard it before, so I am going to be incorporating that into answers because that’s brilliant. That’s so smart. Thank.

Speaker 2: I would, I would.

Speaker 1: Add something to the performance review that says like, oh, they did this great security stuff, but making it an actual part of their career progression is brilliant, I love that. And there is a question in the chat, and so the question I was going to ask you was, what can leadership and management do to help encourage? And you basically just answered it already.

Speaker 2: Money.

Speaker 1: So Amanda in the chat is asking is it a good practice or a good idea to generate tickets from every bug found by a scanning tool? And I would say no on this one personally, but what do you think of Cara?

Speaker 2: Everybody know. Like you have to kind of pick your battles, right? Otherwise people get bug fatigue. Um, and let’s like you mentioned, Tanya, if you have like one person that all they do is fix security bugs, then yes, of course, there’s also different ways of approaching this. You can either create a ticket or you can block PRS. Um, so for example, sneak has a option to block a PR if there is a bug that is registering it high or, um, not extreme. God, what’s the word I’m looking for? Critical. Critical. Thank you for extreme bugs. Uh.

Speaker 1: It’s the metal bugs.

Speaker 2: Anyway, so that would be something that I would discuss more with your security team and the engineering managers. Because if you’re creating tickets for every single bug, if the engineers don’t have the capacity at that time to look at those tickets and deal with them, you’re actually probably going to hurt morale.

Speaker 1: Yes. Oh my gosh, yes I agree. Ideally, I like to work with the security champions and talk about the threat model for their system or systems and talk about what security posture we’re trying to reach and eventually allow them to triage and be like, these ones are bugs. We’re going to fix these ones or bugs we’re not going to fix. But at first I like to meet with them and talk them out. And sometimes I’m like, no, just ignore that one. That’s not a big deal because blah, this one, blah, that one, blah, blah. There’s new tools coming out. They’re trying to show you the context of a bug, which I find interesting. So for instance, for open source libraries, there’s newer tools that are coming out with. So yes, you have these five libraries that are vulnerable, but this specific vulnerability is being talked about in the darknet by these groups. And they’re trying to exploit and creating proof of concept. So you should fix this one first. I’ve also seen there’s newer tools that are showing. So you’re like you have these 12 libraries but this they all have vulnerabilities in them. But this one you’re calling the function that has the vulnerability inside of it. And you’re using that in your code. So you’re pretty much for sure got this vulnerability versus other ones where you’re not even calling that code. It doesn’t even ever get to that part of the code. And therefore the vulnerability is like 99.9% chance, not exploitable unless you’re logged for, in which case you should just cry. So I’m excited about like how the tools are becoming more accurate and how there’s fewer and fewer and fewer false positives and more information to help you decide. But so we’re supposed to wrap up and I will talk to you all day if I’m allowed. So I wanted to ask you to leave us off with. So if you’re going to start coaching software developers, is there a tip or a piece of advice that you’d want to give the audience if you’re just starting with, okay, so we want to talk to the devs and we want to start helping them become more secure, aware, like anything that someone would want to start with.

Speaker 2: Hmm.

Speaker 1: Start with your goals and then pick the tiniest thing you can do to support that goal and then communicate that tiny thing.

Speaker 2: I love it. And you totally stole my answer. Damn. I was going to say her coaching team is like, come together and brainstorm goals that you want for your program, and then together, pick one or 2 or 3 goals and then go from there. Because with coaching, if you don’t know where you’re going, you’re going to get somewhere, but not necessarily the place you want to go. And like Akira I have worked with now, I think I’m at 46 or 47 different asset teams where I’ve worked with them and they’re security champions, and only two came to me with goals. Every other one was like or their goal was so like vague. It was like, we want to have increased security posture. That means nothing like that’s not a specific thing we can achieve, right? So by that you mean what? And so like, yeah, I guess both of us, if you can set a goal and start with that, that’s the best accurate. Thank you so much for being on this webinar with me. This was a blast. This was.

Speaker 1: Really fun. Thank you Tonya, this is good to talk to you. I am going to.

Speaker 2: Share my screen again so I can show the sorry. Please continue.

Speaker 1: Oh no. I was gonna say thanks to everyone that came. It was. These are really good questions.

Speaker 2: I wanted to end on the contact. So if you want to contact bright resilient or we hack purple, these things are here. But I just realized, you know what we’re missing? We’re missing Akira

Speaker 1: Oh, yeah. Let me put that in the chat.

Speaker 2: Please do. Because if you want to contact Akira, that’s where you should go. For me it’s she hacks purple like that or just basically on most of the platforms, except she acts, which is an imposter. So don’t go there unless you want to.

Speaker 1: Imposter.

Speaker 2: Awesome. Well, this has been an utter pleasure. I know that we have to wrap up. Oh, there’s a bunch of stuff in the chat. Is that you in the chat or is that me and the chat? Okay, so no more questions. We’re good. Okay. So thank you Akira. Thank you Amanda Alicia, for having us. Thank you for organizing this event for us. And thank you people who showed up. We really appreciate you. It’s been a pleasure to chat with you this past 60 minutes and we will see you, I believe, next month on August 6th for the next great webinar. And with that, I think that we’re pretty good, right, Akira?

Speaker 1: Yeah. Think we’re good. Thank you everybody.

Speaker 2: Thank you everyone. Thank you so much for coming.

Get Started
Read Bright Security reviews on G2