Matt McGrath — Security coaches

0:01Chris RomeoMatt McGrath is an old-school Java developer that made the transition into security. Matt has had success in rolling out a programmatic approach to security improvement called security coaching. A security coach is much more than a wellness or life coach for your developers. They have some commonalities, but the security coach is thinking about how you help the developer want to get better at security. In Matt's experience, developers are not going to kick and scream away from security, but will embrace it if given the chance. The job description for a good coach does not require a development background. The biggest thing you need is a passion for security. Communication is one of the most important things for a coach to have as well, and technical skills do not hurt. We hope you enjoy this conversation on security coaching with Matt McGrath. I want to take a moment to introduce you to Security Journey. At Security Journey, we believe security is every developer's job. We work with our customers to help them build long-term sustainable security culture amongst all their developers. Our approach is to provide security education that is conversational, quick, hands-on, and fun. We don't do lectures. Instead, we let the experts talk about what's important. The modules are quick, 10 to 20 minutes in length. We believe in hands-on experiments, builder and breaker style, that allow developers to put what they learned into action. And lastly, fun. Training doesn't have to be boring. We make it engaging and fun for the developers. Visit www.securityjourney.com to sign up for a free trial of the Security Dojo. The Application Security Podcast.

1:41Robert HurlbutHere we go. Hey folks, welcome to this episode of the Application Security Podcast. This is Chris Romeo, CEO of Security Journey and also one of the hosts of this podcast. Also with us today we have Robert. Hey Robert. Hey Chris, yeah, it's Robert Hurlbut, Threat Modeling Architect.

2:19Matt McGrathGood to be here.

2:19Robert HurlbutAwesome, and our guest today is Matt McGrath. And Matt, we always start with this question for everybody that we talk to. Our listeners are already sitting there in their cars with their headphones in listening, yelling, hey, we know the question. I'm gonna ask it anyway. What is your security origin story or how did you get started in security?

2:41Matt McGrathYeah, no, welcome and thank you for having me on. I really appreciate it. Yeah, so my security journey really, started, I was always into computers, you know, growing up. I think my first game, I'm going to go back to the Oregon Trail days, and then a little old MacBook. It wasn't even a MacBook at that point. It was a little square box. But yeah, I always got into computers and loved it. Loved it so much I got into the development side doing applications, Java applications specifically, and then really moved into the e-commerce world. And I was in there for a manager for about 15 years. In a retail industry and moved into the financial services industry. And yeah, it was still on the— still on the e-commerce side of it. And what really got me into security is just how it's always constantly changing. You know, you have to sit there and you're building applications and trying to create these wonderful site and you love it, but then you never really think of the other side of it. How do you break it down? How do people break into it? And that's what, that's what really drives me in security. I mean, you create something and somebody finds a way to break it down. So how do you outsmart them? How do you get better? And it's, and it's one of those things where it's always evolving. You're always learning something. You're always challenging yourself. You can't get stagnant because it's easy to be stagnant building applications like, hey, I got it. We're making millions of dollars on this website every month, everything's doing good, but how do you get better? How do you constantly, you know, take that next step? And security for me is one of those things that I'm really passionate about now, and it's one of those things that it just— it's constantly challenging me and then having ways for me to think differently and even out of the box. And that's one of the things I really love about it. So yeah, that's what always— and honestly, that's what really got me into security.

4:36Robert HurlbutVery cool. And so when I hear someone who comes from a development background from some years in the past, I always have to ask this follow-up question. So is any of the code that you wrote still in production? And if yes, does that make you afraid?

4:52Matt McGrathYes, I do have some code still in production in some companies I've worked at. Yes. And yeah, it does. The nice thing about some of the code is it's internal. One of the ones is a stock program that just went out to Yahoo and some other sites to query stock prices. So internally we could see what was going on, and this was years ago. I'm not going to date myself too much, but yeah, that stayed internally. If that was external, yeah, that would scare the heck out of me. And some other ones— there are some other ones out there, but I think they may have gotten rewritten behind the scenes already. But yeah, I'll be honest, back then Security to me, I don't ever want to say it wasn't a concern, but it wasn't my first concern. My first concern was getting hit by the business saying, make sure I have stuff delivered, delivered fast, delivered done. And I would always put, unfortunately, security on the side saying, I'll go back and harden that later. And you never really get that chance to harden it because the next, the next wave of requirements are coming down. So yeah, I would tell you, knowing what I know now, that going back then, yeah, it would scare me.

5:57Robert HurlbutYeah, that's, that's great to hear that you've walked a mile in your, your target audience's shoes though, right? As a developer, you know the, the stresses they're facing about shipping code, and I find that makes for very interesting security people because people that come from kind of a classic security background, a lot of times they don't get developers because they haven't been there, they haven't done this before. Uh, and so it sounds like you've, you've had that perspective, and I think that's Likely going to kind of help you describe this whole idea of security coach that we're going to talk about today because you've been there in their shoes.

6:35Matt McGrathNo, yeah, yeah, it's, it's, it does help a lot. That's one of the things when I first got into security, that was one of the, uh, things that they loved, that the fact that I was there, I've been in that side. I hate to say, I hate to use the other side of the wall, term, but it is one of those things where it's, you know, you've been there, you've done that, and how do you help relay that now, what you're learning from security, and translate that over to how a developer can leverage it? Yeah, and that's— yeah, I agree, it's been helping me out so far.

7:09Robert HurlbutYeah, let's talk about a security coach. Let's introduce this idea because I'm not sure everybody knows or has ever heard this term. Putting these 2 words together, a lot of people probably have an idea what it means when we say security coach, but I'm curious, Matt, from your perspective, when you say security coach, what do you actually mean?

7:26Matt McGrathSo really what we tried to do with this concept of security coach, I mean, when you think of coaches, you think of, at least for me, I think of like sports coaches and wellness coaching and even life coaching, and a lot of those things have a, have common is that they're trying to help, not even just win. I mean, yeah, if you think of a sports team, you're thinking, how do I win? But really, how do you help the individual, you know, really get forward themselves and not just do it for them? But how do you help them want to get better, want to do things? So you think of a wellness coach, you know, how do they want to, you know, they have to want to be better at wellness. Because if you tell them that you have to do it, they may or may not do it. Same thing with security here, right? You can sit there and tell— and I know this because I've done it, you know, you can tell them what they have to do. But if they don't understand why they're doing it and the value that it adds, it's not really going to stick, you know. And that's one of the things I always thought is good coaches really help the individual come up with their own solution because they know it. It's just how do you get it out of them? That's really what we wanted to do here with security coaching. We hand these developers requirements, the security requirements, and we hand them all of these things. You have to build this secure. Our number one vulnerability is input SQL injection, so fix it. Well, they'll fix it, but why do they need to fix it? What's the ramifications if they don't? What if they hurry up and shortcut because they're getting bombarded with requirements and the product owners are, you know, we need to get the next deliverable out. And you want them to be able to remove these security blocks, not just quickly, but with high quality so that application is as secure as it can be because it just takes one slip for a hacker to find a way in and there goes your brand, there goes your identity, there goes, you know, your reputation, the trust. And so what we try to do with the security coaches is really build that, hey, we're not just going to hand you things and tell you to go fix it. We're here for you. We want to help guide the developers. We want to help them build things securely. We want— we know they have it in them. I mean, I was a developer. I know, you know, I don't build a code base and just want to whip some code and throw it out there and say I'm done. You know, that has my name on it.

9:58Robert HurlbutRight.

9:58Matt McGraththat has my reputation on it, and I wanna build it good, I wanna build it secure, and I got all these external factors pushing me to hurry up and do it fast, that's why we have coaches. Here, we'll help you, we'll guide you, we'll lead you to where you need to be, just engage us. And that's really what the concept here for coaching is. It's nice because it's like internally here, it's really a comforting, word for them to say, you know, I need some help. Here's, here's a coach that can guide me, that can lead me, not just tell me what to do and walk away. They're going to take the time so I understand it.

10:32Robert HurlbutYou said something at the beginning about kind of the wellness coach perspective and the fact that somebody who's using a wellness coach actually has to, I guess, acknowledge that they have a problem and they need the help. Like, you're not going to drag somebody kicking and screaming into a weight loss program, right? Because they're never going to lose weight. So, how do you tie that back to the world of security coaches and working with developers? So, do you feel like the developers actually— are they kicking and screaming, or is it the situation where nobody's ever led them towards security goodness, and so they don't understand? Yeah, I know you mentioned that they have to understand why, But how do you bring that all together? Are they kicking and screaming, or are they more happy to just come along with you when you lay out the plan?

11:23Matt McGrathCan I say it varies and leave it at that?

11:26Robert HurlbutYou can, but we'll need more explanation.

11:30Matt McGrathNo, absolutely. So, I would say the coaching there, that wellness example, it really is, it's not just for developers, because a lot of developers aren't, you know, they know that they know security to a point. They're not ignoring it. It's not something that they're doing on purpose. They're not creating a vulnerability on purpose. They're building the application as best as they can. There's a— like I said before, there's a lot of external factors there. In that wellness example, there's a lot of external factors with development teams because it's not just developers, right? It's the product owners. The product owners really are the ones that are pushing for, hey, what's the— this is the next deliverable I want. Well, yeah, you can have that next. You can have all the nice shiny bells and whistles out there, but if this code isn't hardened and there's an issue out there, all those customers that are on your code base, they're gone. You know, they're not going to come back. They're going to go to the other company who has similar features and functionality because they haven't had an issue yet. So a lot of this is really helping to sell why we're doing some of this as well. So, because the developers want to do it, they don't— they're not kicking and screaming. You know, there could be some. I mean, yeah, hey, you know what, if they're kicking and screaming, it's probably because they have a backlog if they're in Agile, or require, you know, their requirements deck in the waterfall project, or whatever, you know, methodology somebody is using. There's probably a list of 20 things that they have to do in one day. And they're, you know, they know that, you know, they can't get that done. So, and then throw requirements on something that's already been delivered, security requirements on something that's already delivered or going to be delivered, and they have to go back and rework something, that's, you know, that never really goes well. So I would say there could be a time where they are kicking and screaming, but that's again where this coach is, hey, listen, I know it's frustrating, you know, I know it's not easy, I know you may have to do some rework, but we're here, we're here to help you, we'll help guide you to do that. And think of it this way, when you're, you know, in this example we're talking to the developers, when you're already doing your next set, now you have this in the back of mind. So they're not, in my experience as developers that I've run across, I would say the majority of them aren't going to kick and scream. If they are, it's because they have so much other work that they have to get done that it's, you know, they wish they could have probably got to it earlier.

13:54Robert HurlbutSo I guess what's the job description then? When you think about a security coach, is there a set of bullet points that defines the person who's actually doing the coaching?

14:04Matt McGrathYou know, so I'd say there is a high-level job description that we kind of use, and it can be curtailed to anybody who's trying to put the same concept in. The one thing— so I'm going to go back to coaching, right? You can have a successful coach that could be the greatest player of all time, and, you know, they should be an unbelievable coach, right? And it just doesn't translate well. And you can have, you know, somebody who probably doesn't hardly— never played a sport before be a coach, and they're probably one of the best coaches in the world. So I guess what I'm going with that is, you know, I never want to put like a, hey, you have to meet these 5 bullet points because if you don't, you know, you're not going to be a good coach. Like, I don't want to say you have to be a developer to be a good coach, because I can— I do know some people that never had a development background, but man, they could persuade and they could really help lead somebody. So, but I would say there are some, you know, in my term, if you want to be a good coach, you have to have a passion for security. You can't just, you know, say, I'm going to be— I want to be a coach in security. Okay, well, why? I mean, you have to have that passion. You have to have that Understanding security always changes, how you're coaching these developers have to change. The ability— ability to communicate would be one that I would say has to be there. If there has to be some bullet points as well, like that, they have to be able to communicate. Because if you can't communicate well, then you're not gonna be able to really help lead those developers, or not even just developers, but lead, you know, that discussion appropriately. Because sometimes It's not just with developers, it's with the business as well. But I would say communication is really key in a job description for that. And yeah, a lot of it is nice to have, you know, if you're, if you're an ex-developer or a current developer, yes, I mean, that's all, that's always a plus. Because, you know, you're going to help them with a lot of different areas and code reviews and, you know, walking through why this code snippet is better than what they currently have. But again, I would say if you're not a developer, and the reason why I say you don't have to be a developer, as long as they can understand the flow of code and understand, you know, what it's doing high level, they don't have to be a developer. But most of my coaches are, and most of those are because I have been. But, and the reason why I just don't want to discourage people, because there could be somebody out there that could probably be one of your better coaches, but may not have a strong background. So that's why I just don't want to— I don't want to say that there's no— you have to have— you have to be a developer, because I don't want to discourage somebody who's not a developer. But that does help.

16:51Robert HurlbutYeah.

16:52Matt McGrathBut communication really is key, because you got to know your audience. You got to be able to figure out what developer— how, like, how they can communicate, what's their communication style, and be able to translate that, because not everybody receives a message the same way. And that's one of the biggest keys I've come across in, in with coaching is making sure that, you know, hey, you may have something, you may know the answer, your audience may not. You also have to know how to communicate that over to them. Because if you, if you communicate the wrong way, they could take that message the wrong way as well. And they may not want to engage us in the future. So one of the biggest things that they have to be able to do is soften that message as well.

17:30Robert HurlbutYeah. Yeah. So when you, when you think about technical skills, then I mean, you mentioned that, you know, a couple things I wrote down from the job description: communication's key, passion for security, you know, developer, ex-developer is a plus, having that type of a background. This— what do you find as far as the level of technical depth a good security coach needs to go to?

17:54Matt McGrathOh, that's a good question. Um, If they're good, if they're a really good coach, they would allow— they would be able to pull out from the developer the ability to have that developer dive deeper in themselves and want to take it on and go. So for example, I've seen a coaching engagement go where it was a really complex ask. And the coach, the coach, you know, got all kinds of materials and references and some documentation and even some code snippets. And they were a little bit nervous when they came to me and they were like, you know, I'm gonna, I'm gonna need your help on here because I don't know how deep I'm gonna have to go. And the way they communicated it to the developer was, was really good. They knew the developer, they knew their style. And they started off by explaining, hey, you know, I know this is a tough, tough code to write in. this vulnerability is really, really difficult to see when you were developing, but here's why we need to address this. And they were gonna start going into really technical details. And the developer's like, whoa, oh, I get it now. Well, let me take a step back. Let me go back offline. Let me take some of your material and read through it and let me go address it and then we'll come back. And they were just like, wow, I thought I'd have to really dive in and go into the code and do, you know, do not a manual code review with them, but really dive into the code alongside them. So it's going to depend. But I'd say the majority of the coaches that coaching engagements I've had is, or been across or seen, is that it's not super deep dive into the code. It's pulling up a little bit higher level and giving them some starting requirements and even some starting reference points and some explanations and not really having to— they've never had to— I haven't had a coaching request, or I haven't came up— we haven't come across one yet where they had to actually write the code either. So from a depth perspective, I don't think it's really driving down and pulling up their, their editors and helping them out. I think it's more of, again, it's if you're, if you're, if your coach is effective, they can guide them into resolving it. They do have to do research on their own. Like a lot of coaches, if they don't know it, or if it's a new stack that we're not familiar with, or if it's a a new vulnerability or something or whatever that they're not 100% on top of, they may have to do a little bit more digging and get a little bit more technical, but it's not— yeah, it's not too terrible.

20:29Robert HurlbutYeah. So Robert, you have spent an amount of time as a developer, and I think you were a developer before you were a security person, right, Robert?

20:41Matt McGrathRight, right, correct.

20:42Robert HurlbutYes. So If you were— I'm going to ask you to jump in the Wayback Machine here, Robert. And if you were— say you were a developer that didn't know anything about security and you got this request for a meeting from the security coach, what are the type of things that you as a developer would be asking that security coach? Well, because I also work with developers as well and been a developer for a long, long time before that, I think probably one of the number one things I would ask is, or maybe actually let me make a comment, brief comment on something you mentioned earlier, that developers don't necessarily want to do the wrong thing, the bad thing.

21:25Matt McGrathRight.

21:26Robert HurlbutI agree with that. But one thing they may say though is, what extra things do I have to do? I am so busy with all the other things that I'm doing and now you're asking me to also include something about security. That's one more thing I have to think about. So I think my first question would be, how can you help me manage this better? How can you help me think about this so that it flows with all the other things I'm doing? It makes sense. It's probably something I would consider. And now I'm going to pretend this is a real-life situation and say, hey, Matt, how would you answer that question?

22:02Matt McGrathHow would we answer that question? I'd say, did you take our security training program? So, you know, So that is a great question. And if we focus just on the coaching aspect of it, it would be a little bit difficult to— because you can't just have a coach and call it a day and think your program is going to be good. Without getting into programs, one of the things that makes— one of the things that really helps our coaching— our coaches here is the fact that we have a pretty good—

22:36Robert HurlbutYeah.

22:37Matt McGrathtraining around it as well. So we have— what we try to do is make sure developers have enough training that they have, you know, certain fundamentals they have to take, and then there's extra courses that they have to take anyways. But, um, but yeah, as a coach though, I would, I would say, hey, look, um, leveraging some of those courses, hey, have you had a chance to look at any of those fundamentals? Because, because the biggest thing, to your point, is You know, how do you get out in front of that? You know, we may not be out in front of it now, and unfortunately, that's where still the coach has to be a little sympathetic in their communication style and say, look, I get it, I understand, I feel your pain, and it's, you know, we'll work through it together. Just in the future, you know, if you can come to us before you start writing a line of code, that's the other thing I try to teach my coaches is within your engagements, making sure that, you know, let them know, hey, when you're starting your next sprint, or your next release cycle, whatever it is, whether you're agile or whether you're waterfall or whatever methodology, hybrid or whatever, before you, before you start writing a line of code for your next release, think about what you're building. Think about from a security standpoint what types of changes you're making and if there's anything unique or different that we may need to— you might want to talk to us about beforehand. So when you're writing code the first time, you're writing it with security at the top of your mind. And if you have questions, let us know. We're here for you. We can help guide that. So, so to that question, I would say, you know, minus everything else that everyone else's programs have, it really is— and you brought up a good point— you want to get out in front of it. You want to get out in front when you first start writing code. You know, and, you know, we get a lot of it. There's a lot of legacy code out there as well. And you're going to ask that question too, is, well, you know, yeah, but if I'm touching this code, you know, Now, I'm going to get on a rabbit hole because I'm going to start fixing one thing and something else may break. And it's, you know what, let's just take it one step at a time. We'll work through it together.

24:33Robert HurlbutYeah. Work from kind of— look forward and fix the things in the rearview mirror that we have the ability to impact. So, do you— when you think about the kind of job description of a security coach, I'm almost imagining this is the type of job where you're trying to work yourself out of a job. You're trying to get to the point where that developer's like, you know what, I don't actually need this anymore. I got this figured out. And it's kind of how I always taught threat modeling when I did that for a big company as well, is I was trying to figure out how can I get these folks to the point where they're like, we don't really need your help. We can just do it ourselves. So is that, Matt, is that your goal when you're kind of entering into these coaching engagements is to basically have somebody outgrow you as the developer?

25:21Matt McGrathYou know, I would say yeah. I mean, if you're a good coach, you know, you're good. Part of your goal is to really help so they don't have to come back for that particular task again, right? Or, you know, you give them— you pull that knowledge out of them, or you pull that drive out of them that they're going to do this more research on their own before they write code. So yeah, you kind of are going to coach— I want to say coach yourself out of that particular aspect in that security. So for example, if we're focusing on cross-site scripting or SQL injections, you want to be able to not to have them just focus on that area, but the entire application itself and make sure that they constantly are looking out for that. But yeah, I would agree. I would agree, as a good coach, you're going to want to coach yourself out of that job from that area, but you're never done. Security's always changing. You always— you can't just say, okay, you fixed these 10 things, we're good now, because there's another 10 things that may come right behind. And then, well, yeah, we're on Java, we wanna move to cloud development now, or we're on C and we wanna move over to a different language, for example. There's all different things that's constantly changing, new— everything's being pushed to the limit.

26:39Robert HurlbutYeah.

26:41Matt McGrathAnd, you know, the development teams aren't gonna be able to go do research. The coaches have to do research themselves too and try to get out ahead on those things as well. So yeah, I mean, I would say, yeah, you do kind of, you know, you kind of want to say— I do kind of like that terminology, you're coaching yourself out of a job. But there's— with security, that's never done.

26:59Robert HurlbutYeah. So that's my goal in every job I have. Like, that's always my goal. Like, how am I going to get to the point where they don't need me anymore?

27:07Matt McGrathYeah, that's, that's one of the jobs of a coach too, because you think about it, if you're constantly doing coaching requests all day long, you don't— you're not doing anything else that you're really, you know, responsible for too, because you're not gonna have a coach that's just gonna sit there and wait for a request, right? Those coaches are gonna have other responsibilities within their, within their job. And that's not their only job for the whole, you know, company.

27:30Robert HurlbutYeah.

27:31Matt McGrathSo it's, you know, they, they're never going to get to what else they need. or even start future thinking or even doing research if they're always doing coaching requests. So part of that job, Chris, to your point, really is coach, you know, help lead, help those developers want to lead themselves to get better, to do their own research, to try next time instead of just coming to us. Here's a couple more things you can try. Here's some good research sites to go to so they can almost feed themselves.

27:56Robert HurlbutYep.

27:57Matt McGrathAnd then eventually they're gonna hit, you know, like anything, they're gonna get so far, they're gonna get stuck again. And then jump right in, do it again. And also, the biggest thing I tell those coaches is the more you help the developers help themselves, the more your next coaching request is going to be more fulfilling for you guys because it's going to be something more engaging and not just the same old repetitive stuff as well. So the better they do from a coaching standpoint, the more interesting their requests are going to get as well.

28:24Robert HurlbutYeah. So do you see coaching, this security coaching, this sounds like this is not a full-time role then. in how that you recommend people do it. So, folks have, that are doing this, have a day job, for lack of a better term, and then they do this as a kind of a side project as far as coaching goes. Is that the model that you'd recommend, or is this something that you have dedicated people that are coaches that are just doing this all day long?

28:52Matt McGrathWe have, so I would recommend, you know, even to start, It— I think when we started this, it was more of like a side job. Hey, we know we started getting requests in, people needing help. We kind of like, all right, can you go do that? Can you do this? And then we were like, okay, we need to be something a little bit more. So we started this coaching role. So it is a responsibility. It is, it is one of a team member's responsibility. So it's not— I wouldn't want to push it off as like a side job. It's one of their main responsibilities because they're going to own it. They're going to get requests. They own— however big a company is or however small a company is, you can kind of compartmentalize certain areas and say, you're going to be a coach for this section or this line of business or this application. So you can kind of curtail it to how the need is, and then you can start putting some metrics around how many requests are you getting a month, how typically long are those requests taking. And maybe eventually, you know, it could be a company that, yeah, you could have, you could eventually maybe have 1 or 2 roles where that's all they're doing is coaching, coaching stuff. And that coaching, and you could even expand it to, you know, coaching and walking through and coaching and training. You know, so it can morph to whatever the need is for Whatever somebody wants, however they want to craft it. But yeah, for us really, it's, you know, it's a responsibility. I don't want to say a line item of what, but that's one of their responsibilities of their job.

30:31Robert HurlbutSo it's part of their— It's part of the day job. It's not something that's like, hey, squeeze it in wherever you can. It's part of their responsibilities, which is a good thing because they're going to be able to dedicate time to it.

30:42Matt McGrathYeah, absolutely. And we try to put a little bit of a structure around it too. So you're not just getting a random email. And if you do, we try to make sure we record it somewhere. So there's a lot— there's a couple things that come out of that, right? When you record those things and you track it, they can be leveraged in like a knowledge base. So you're not— it's not just a coaching request. It's one and done. It goes away. You know, now, you know, when we talk about feeding the developers, hey, they can look up the knowledge base. Hey, I wonder if anybody ever, ever tried to talk to them about X, Y, and Z.

31:11Robert HurlbutYeah.

31:11Matt McGrathThey can search it. Oh, they did. There was a coaching request. It was like 247. That's perfect. That's exactly what I needed. And they can, without even putting a request in, they can get their answer. So we try to put a little structure around it too, to where we can track how many requests are coming in per month, or even break it down per week, and then how long those requests take. And then as well as record those as well and put them in the proper areas. So if we have coding, secure coding standards somewhere, we can put the coding request there. If it's just a question and answer, then we can put it somewhere else, anywhere where they could be able to try to leverage it themselves too.

31:47Robert HurlbutSo what's the right interval then? Are coaching requests something that we should just take, collect emails when somebody sends a request and they just notify us? Or is this something that's more proactive? Could it be more proactive where we're like, we're meeting with one developer, say, once every month we have a standing meeting where we're getting together and because that developer is interested in security.

32:10Matt McGrathIt can be a combination too. It can be, you know, sort of how you said that, meeting with a developer once a month. We've gotten emails where it can be an email, hey, you know, I didn't know what to do, so I just figured I'd email you guys. We have a site where you can fill out a formal request. The other thing we try to do is we— I try to get our coaches because they have, you know, if they, if they're over a particular area, we try to make sure that they plug into any architectural design meetings, any business meetings and say, hey, you know, I'm gonna be your coach as well. So we kind of let certain areas know that they have a particular coach that they can go to. So they're comfortable. They know they can go to— I'm going to use Joe over here, and Joe can be their coach. And so they have that formal engagement with Joe too. So it's not Joe's, it's not just they're just sending an email in a random box and, or putting a request out there and they're just hoping they get somebody. They, each area knows who their coach is. And that coach, I let that coach really work their avenue if they want, how engaged they want to get in giving them that freedom. I see a lot of, a lot of the coaches I have really want to get involved. They want to work with their partners and peers and You know, at the end of the day, there's, there's, everybody has performance reviews and stuff that they have to meet anyway. So, Yep. It's, you know, a lot, a lot of the people who want to be coaches really want to help out, and they want to be able to provide the best service that they can. So, I kind of let them figure out how they want to get engaged and how they want to engage their teams. But I definitely make sure that each, each, each area or each team knows who their coaches are so they can go to them at any point in time as well. So, it's more of a They don't feel like it's a process, but they can, they know they have a person and a face that they can go to talk to as well.

33:58Robert HurlbutSo I got what I think is the million-dollar question here, and I've been, I've been trying to answer it myself, and I'm gonna not even gonna share my thought. I'm just gonna, I'm just gonna leave it out here for you to kind of give us your thoughts. But what is the difference between a security coach and a security champion? Because we see a lot of people using the security champion, security advocate, security guild member. You know, there's a lot of different terms.

34:26Matt McGrathSure.

34:26Robert HurlbutBut it's not— when I think of that classic definition of a security advocate or security champion, it's not what you're describing here, but it's like what you're describing here. And so how do you kind of separate those 2 into different categories?

34:44Matt McGrathWow, that's a good question. It's a loaded question 'cause I think a lot of it depends on what you're— what are you defining as a security champion? Because if it's very like a coach, and we, you know, I've been around areas that use champions as well. If I think of what I hear when I hear a security champion, I hear, I think of that person as a, a go-to for anything with security. So, hey, I don't know what department I need to work with or what group I need to work with in security. Can you help me? Yeah, we can direct you over to there. You know, where I see a coach is a coach would be very specific and almost more of a— I would think of a security champion as like a GM of a team and a coach is the coach, right? Your GM is going to make the decisions, a lot of the decisions around that team. Your coach is going to help corral the talent that they have on that team and make sure they get their best foot forward given what they have to work with. And that's where I see these coaches working with these development teams they have. They're on these specific areas that they're going to help guide that. You know, this is who you got to work with. Help them. You know, you're going to lead them. You're going to— they all have their answers. They all know how to develop. They're experts in developing. just help them with security, guide them to it, want them to do it. And then your champion would be there for, you know, making sure that, you know, their schedules are lined up. And yeah, I think a lot of it depends on your terminology of what you would define as a champion too. I think each company is probably going to use a champion differently. They'll probably use the term coaching differently too.

36:26Robert HurlbutYeah, no, and I think— and when I think of a champion, I think of it similar to how you described it here, where a security champion a lot of times is someone who either has volunteered or been voluntold, which is a popular quote.

36:42Matt McGrathI love that, voluntold.

36:43Robert HurlbutThey've been, they've been said, hey, you're gonna go and be our security champion. So a lot of times I think of the security champion in the model you're talking about, the security champion is actually the one on the other side of the table from the security coach, because in your model you've got the security coach who's already somebody who loves security. They have as part of their job to help developers and other folks in the organization kind of get further down the road in understanding security and why we should care about it. So I could see somebody having a security coach program and a security champion program, and they're gonna support each other, but they're not the same thing, at least from my perspective. What do you think about from that perspective of security coach versus Yeah, that's what I was thinking as well. The way it was described, it did sound like 2 sides of the table. Obviously, you know, similar goals, but yeah, 2 different sides. So yeah, security champion are, you know, typically on the team or working with the team directly, but look to the coach to help them, guide them, maybe, you know, get some support for what they're doing as well. So yeah, that's what I'm thinking as well. All right, so one other question, Matt, that we had was what are some of the best practices for other organizations that want to deploy security coaches for their teams? And let's just keep it simple. Let's just say, hey, you can only tell us that— you can only give us 3 things. Here are the 3 things we got to consider that we have to do if I'm going to roll out a security coach program. If you could only give me 3, which will make the question a lot harder, what 3 things would you tell me as another company out here who says, hey, I like this security coaching thing, what should I do, Matt?

38:30Matt McGrathI would start out by— well, that's a good one too because it's going to depend on your resources and the availability of it, but I would say, you know, if and how effective your program really is, but I would say you'd really want to make sure that you carve out some time with your security team to make sure you have individuals to help. I hate the word handholding, but really be able to partner with other areas and help guide them and answer questions and be there for them. And then you start small, right? Start small, grab a couple resources who are really passionate, who want to help out, I mean, you'll know who those are. I mean, you'll know who the people would be. Coaching, coaching, in my opinion, you can have a lot of individuals, but you can pick out, this person would be really good working with other areas, other teams. So with this person, kind of grab a couple of those people and start small, you know, and see how it goes and see if it's well receptive. Because the one thing you don't want to do is have coaches and you're not getting requests. And if you're not, you got to figure out why, because maybe coaches aren't good, or maybe they don't understand that they have a process, or Maybe they just don't know to ask. And so, I would start small, maybe even take a sample group or whatever or section or an area in the business and assign a couple coaches, communicate out that you have this new program or new thing you want to try. So, you carve out some resources, you communicate out that you want to have this program try and just Market it, right? Because if people don't know you have it, they're not going to use it. So you kind of want to market that you're going to do some coaching. You want to have communication around and, and tracking on your coaching requests that you're going to pull in and then get some people who really want to do it to start it out.

40:20Robert HurlbutYeah. So I wrote down basically of the 3 things, the first step is to find those folks on your team who can be your resources. So find those coaching resources that you have available. Second thing was start small and potentially use a sample group or maybe a single part of the business. And so don't release it to the whole organization to start and get overwhelmed. Start with a smaller group and then refine the idea as you go, and then you can slowly branch out to the rest of the organization. And the third thing was marketing communications and then ticket tracking, for lack of a better term, but keeping track of how many requests you're getting and some of the metrics behind that to justify the need for additional coaches at some point in the future. So I think that sounds like a really solid way for folks to get started with these coaches, this idea of security coaches. And so I just, I wanna tell you, I love the idea. When we first talked about this a number of months ago, I was like, I love this idea, I wanna learn more. And so, you know, I'm here asking questions on behalf of our audience, but I'm actually asking on behalf of myself because I was really curious about this topic. And I feel like I really have a good idea now about what a security coach is, what a coach has to do to be successful and how I could roll this out in a bigger organization. So, Matt, what can you leave our audience with as far as like a key takeaway or a call to action or something that they can leave this episode with?

41:48Matt McGrathYeah, I would say the biggest thing is really just partner with your teams. You know, the big one of the reasons why we did security coaches is because you know you can have a great security program, but if people are struggling with it or you know don't have the time for it or don't fully understand it or you know they just think it's another checkbox to mark off. For us, security coaching really goes a long way. It helps drive home that message of why it's why you know why we're doing this. We're not just doing this to to settle regulators and regulations. We're not just doing this to check a box off on a policy or a form, but we're really trying to do this because. Because, you know, we care about what we're delivering, we care about the brand, you care about your reputation. I mean, at the end of the day, each individual person who's developing and writing code, and even, you know, from PMs, BAs, everything, product owners, they're all, you know, having their hands at some point on these projects, and that's where security coaches really help out, really get that understanding. And, you know, it's a constantly changing environment out there, everybody knows that, and coaches allow coaches— allow, you know, they can stay on top of that and they can help bring that information to developers who are staying on top of their, their own niche as well. And that it kind of brings it together. So.

43:04Robert HurlbutThat's great advice. And so we thank you for joining us and sharing your expertise with us and with your audience. And we look forward to hearing more about security coaches into the future. Thanks, Matt.

43:18Matt McGrathOh, thank you.

43:19Chris RomeoThanks for listening to the Application Security Podcast. Our intro music is 8-Bit Kung Fu by Born and TJ, and our outro music is Southern Delight by Stefan Cartenberg. You'll find the show on Twitter @AppSecPodcast or on the web at www.securityjourney.com/application-security-podcast. You can also find Chris on Twitter @edgeroute and Robert @Robert. Robert Hurlbut. Remember, security is a journey, not a destination.