Security Champions With Simon Maple

Transcript

Dormain Drewitz: Welcome to Page It to the Limit, a podcast where we explore what it takes to run software in production, successfully. We cover leading practices used in the software industry to improve both system reliability and the lives of the people supporting those systems. I’m your host Dormain Drewitz. You can find me on Twitter, @dormaindrewitz. All right. Today, we’ll be talking about Security Champions and how this matures DevSecOps practices. Joining me is our guest, Simon Maple, currently field CTO at Snyk and the author of a recent white paper on Security Champions. I’m also joined by Quintessence, one of our developer advocates here at PagerDuty. Quintessence, say hello.

Quintessence Anx: Hey everyone. Nice to be here.

Dormain Drewitz: Awesome. Thank you and Simon, thank you for joining us today and welcome to the show.

Simon Maple: Thank you very much. It’s my pleasure, and always happy to talk about Security Champions and fun topics like this.

Dormain Drewitz: Yes, I am looking forward to digging in on that topic, but before we do it, just have a quick get to know you question. Simon, coffee or tea.

Simon Maple: Coffee in the mornings.

Dormain Drewitz: Coffee.

Simon Maple: In the mornings. Yeah.

Dormain Drewitz: Yeah. How do you take your coffee? Is it, is it cream sugar, or just straight from the dispenser into an intravenous bag?

Simon Maple: I quite like a latte.

Dormain Drewitz: Ooh.

Simon Maple: And then I’ve just recently bought one of these like super strong filters that you’re supposed to have about five cups from during the day or over a few hours. And basically, I drink one cup of that and then my mind is in overdrive and I can’t even bear thinking about another cup, so I’m working on it.

Dormain Drewitz: Wow. Okay. So that’s an interesting self-limiting proposition.

Simon Maple: Absolutely. Yeah.

Dormain Drewitz: Yeah. Well, fantastic. I’ve been drinking a lot of tea myself, but I do love a good latte. So I’m with you there.

Simon Maple: Do you take it black or do you have milk with your tea? Because this is a thing that the British sometimes do particularly badly.

Dormain Drewitz: No, it’s latte, but never adding sugar. It’s just, there’s enough sugar in the milk in a latte. So that’s where we go. Quint, how about you?

Quintessence Anx: All of my local friends will laugh the second I start speaking because there’s this place near me. It makes these lattes and they make their own housemate syrups, none of this purchase pump stuff, and they make orange rosemary and white chocolate lavender and stuff. So I drink those aggressively.

Dormain Drewitz: That sounds pretty delicious.

Quintessence Anx: I also developed a liking for unsweetened iced tea as a kid. Something I didn’t appreciate as a kid. So sweet tea is a Southern US thing, again, aggressively. I didn’t know what it meant that my grandma was from Ken Turkey like in this context, but she always had multiple things of brewed iced tea, unsweetened because she was diabetic. And so I just had this constant stream of unsweetened iced tea as a kid that I really developed a taste for. And it wasn’t until sometime in adulthood when I encountered the thing, I was like, “Oh,” just like that.

Dormain Drewitz: And then you have sweet tea and just you practically spit it back out on the face of whoever handed it to you. And you’re like, “Oh my gosh.”

Quintessence Anx: I don’t. But I have to be in the mood for it because it very much is a 50% sugar, 50% tea concoction. So when you really want a bunch of sweet tea goodness, I can be there for it, but I really need to be in the mood, otherwise it’s unsweetened.

Dormain Drewitz: Okay. Well, I’m glad we established these very important facts about everyone here on the show. That’s the business part. Now let’s have some fun, let’s talk about Security Champions. Simon, can you tell us a little bit about your experience with Security Champions?

Simon Maple: No, absolutely. I think it was probably about four or five months ago that I really caught the bug of talking to as many people as I could about Security Champions programs. And what I really wanted to do was just talk to as many people who have run them, learn from them their best practices, learn from them where some of their Security Champions programs failed or didn’t grab traction. And my goal here wasn’t to set up a cookie cutter Security Champions program that just fits them all because I don’t believe one such program exists. I think what I really wanted to be able to do is talk to others who want to create a Security Champions program or already have an in flight program and just give them ideas and say, “Hey, this is what some people are doing, or this is how some people are having problems with their programs,” and people can gleam certain ideas or certain things that they’re doing and say to themselves, “Yeah, this is something that I feel would fit our company culture or would work well within the team’s security or dev team that we have here.” So that was my goal. And yeah, I talked to plenty of different folks, some in big enterprise organizations, some much smaller startups who are just bringing in their first security folks or perhaps don’t have security folks, but still want to have that secure development through their engineering team. So yeah, that’s where I’ve taken a lot of inspiration from, and a lot of learnings really.

Dormain Drewitz: Yeah. Just out there learning from the field. And I like that you’ve run the gamut in terms of who you talk to, and your point about how there isn’t one size fits all. It’s just we’re going to come back to the tea, right? Not everyone wants a sweet tea all the time or completely unsweetened. You’re going to find, what’s the ratio for you? Right. But I promise I won’t come back to ice tea.

Simon Maple: I like this. I think we should relate everything back to it. And maybe even try for as many tea puns as we can as well throughout.

Dormain Drewitz: Oh yeah. Like this good one from my son, what starts with a t, ends with a t and has t in the middle?

Quintessence Anx: It’s a teapot. Is it? I don’t know.

Simon Maple: Oh yeah. I agree.

Quintessence Anx: Oh, yes.

Dormain Drewitz: Yeah. Word puns. Okay. So I got a bunch of questions I’d love to pick it. Like, what you’re noticing for bigger companies, smaller companies, but let’s come back to just also the baseline because the notion of Security Champions has been out there for a little bit, but yeah, it’s still an area where folks try and wrap their head around it. So I think it’s great that you’ve been doing the research on behalf of everyone else. If there’s one myth you would bust about the whole Security Champions thing, what’s kind of a bubbled up for you?

Simon Maple: The one thing, and I think there’s probably a number of things that link into this and this is goes beyond Security Champions or security in general. But the one thing which a lot of people just assume will work fine but in my experience never does, is that assumption that a developer who is going to be a part of a Security Champion or is assigned some security work, if they don’t have that as a recognized part of their job, and they’re just expected to do this thing as a, “Oh yeah. Just do that when you have time, when you’ve got some free cycles,” that’s one of the many things that just will never get done day in day out. And particularly when you try and scale these programs to just say, “Yeah, developers they need to push these product features out, et cetera. And as and when they confine time to do these extra security things, they’ll do them.” And I think to rely on that, you’ll just essentially be in exactly the same position one year’s time down the line as you would be today if you think that kind of thing is going to happen. So my biggest myth, I think there is, if you expect things to happen through just asking for things, but don’t make it a recognized part of someone’s job that they take a percentage of their time out and that is accepted by management product teams, et cetera, it just plain won’t get done.

Dormain Drewitz: Yeah. I mean, there’s that the adage of, if you want to get something done, make it someone’s job, which I usually think of in the context of, everyone’s complaining this thing is broken, so you have to actually put someone in place, say like your job is to do this thing. But here you’re really talking about it’s everybody’s job. Like the goal is you’re actually trying to have, to scale security. Effectively you want more developers who are taking it on as part of their job, but it has to be recognized. So that’s interesting. Make it someone’s job, make it part of someone’s job. How have you seen that recognition play out in terms of, how does it become recognized as part of their job?

Simon Maple: Well, there’s two, I guess, ways in which that can be played out. I think it stems from the top. And I think for it to be recognized as being a part of someone’s job, it needs to be voiced by a senior lead in an engineering team, for example, who states not just that security is important to our organization and to our development, but we’re going to go as far as to say, “I would like teams to spend X amount of whether it’s for velocity points or however the teams work, on security.” For a Security Champion, so that’s typically one individual in an engineering team who is connected to this official formal program, Security Champions program. What we’ve seen is various amounts of percentages of time that can be spent. And often that can be up to 20% of the Security Champions time. So 80% of the time they’re a developer, but that 20%, that one day a week effectively is dedicated to Security Champion work or securing, or adding security processes and things like that into their development team. But yeah, it has to come from the top down. And the second thing, which I think is equally important is to not omit the work that is done by those individuals as part of reviews and recognition. So if a developer is able to do more development work, because they’re not doing this 20% of security, that’s to be expected. And developers that are at 80% capacity of development work and 20% capacity of security work, they should be recognized for their development work, but equally recognized for that security work. It should be a part of their review plan and a part of their recognition plan as well.

Dormain Drewitz: Have you seen folks even going so far as to adapt say their performance review like templates or whatever is getting formally used for those processes? Are you seeing folks actually adding in security contributions in some capacity? That’s not the right wording, but so it is like getting checked in on?

Simon Maple: Yeah, no great question. I haven’t seen the format of a review change because of that, but what we very often see is two things. First of all, developers are more inclined to actually put those targets and goals into their quarterly or yearly development plans. But secondly, one thing that we have seen, which is really, really important, it’s more and more companies these days mark security as one of their core goals or core focus areas. And there are many companies that are very open, Atlassian is a great example where they’re very open about saying how you reliability and security are core things that developers should work on first. And then once those things are sorted, then feature work comes behind that. And I think when you’ve got those kind of company goals, company ambitions, when individuals in teams start creating their quarterly yearly goals, et cetera, they tend to come from company goals and team goals. So you see them more being pulled into those review plans from that.

Dormain Drewitz: Yeah. I’m going to use the W word here, but those goals do tend to waterfall down. And it’s hard for me to say.

Simon Maple: That’s very agile use of that word there for me.

Dormain Drewitz: Thank you, Simon.

Quintessence Anx: Kind of on the opposite side. So we have the IC’s concern, but when you have people at the management and exact layers initially starting to discuss, especially if they’re not doing it out of the gate, which is going to be common in any company that’s older than say a week old, right. They’re probably making pivots. So they’re discussing how do I prioritize this? Like I need to make this a priority. I need somebody to own it. How do I put this above or below other things that I’m giving my contributors or my teams?

Simon Maple: It’s a very interesting question particularly among organizations that have really wrong pulls in a certain direction. I mean, I can take Snyk is a great example, whereby we’re such a fast growing company. Things like features and product requests really can pull an organization in a particular way, and all companies have various pulls in certain directions. So it’s very challenging for development teams to focus on those areas. One aspect, which I’ve seen time and time again, actually in a couple of ways benefit development groups to be able to prioritize this time, and actually be better at adopting security processes as well is visibility and transparency. So being able see how good or bad your part of the organization is doing. So that might be anything from looking at scorecards to understand the adoption of security culture or the processes that are being done in those teams. But also down to metrics, things like vulnerable management, how many vulnerabilities we have in certain projects, or whatever it is. So that’s one place so that the team is aware of the situation they’re in. The second piece is transparency. And I think with developer adoption in particular, this is very, very important to have almost developers gamify where they spend time, because no one wants to be seen as one of the worst parts of an organization or the worst business unit, et cetera. And when you get that transparency of how your team, your business unit, your department, et cetera, are doing in comparison to the rest of the organization, you do tend to get more of that push from the top down of as well as well as the bottom up. Because the developers know they need to do a lot of these things, but are they getting the support? And when you have business unit owners in engineering teams see that their scorecards and their metrics are not as compelling reading to compared to other departments and business units, they know that their exec teams are going to be pushing down pressure on them. So they start making it more of a big deal for their dev teams to focus on. So visibility and transparency for me are the two things that empower developers to be able to focus time on those kind of things.

Dormain Drewitz: Then to bring it back to Security Champions, right? If visibility and transparency are what are really empowering developers, how do the Security Champions fit in with that? How are they using that information while also then providing like, “Hey, you’re motivated based on this very transparent information about how you’re doing, that’s providing the motivation to do something.” And the Security Champion is then saying, “Here’s how you can make this better.” Is that the right balance between those two? You’ve got the why, but then there’s how do they answer the how? Or does the secure champion really need to be also be part of that transparency and visibility push as well?

Simon Maple: Yeah. The visibility and the transparency push, I think that’s something that is very important for everyone to be a part of, everything from the exec level, all the way through to the devs and the champion so that people can see everyone’s dashboard and people can see how everyone compares. How is a really interesting question in terms of what works best for that team? And I think another myth actually that we could debunk is the Security Champion, the individual developer, typically per development team, is the person responsible to do that security work. And that’s not always the case. They’re the person who’s responsible to make sure the work gets done. That could be done by anyone on the dev team, including themselves. But I think in terms of the, how, that’s where the communication really starts happening, not just between the dev teams, the Security Champions and the security groups, but also across teams, across dev teams. So as with any organization, you’ll have some dev teams that are leading edge. If they hear about a technology they’ve not heard of before they want to implement it, that kind of team. You’ll get other teams that haven’t changed in 20 years, and they keep off my lawn and keep off my grass teams where it’s like, we’ve been doing this for 20 years. It’s always works. We’re going to keep doing this. And so, one of the ways in which we’ve found really encourages dev teams to move forward is to be able to transparently and visibly compare two teams to say, “Look, if you want to improve X or Y, whatever it is, here’s a team that’s not so dissimilar from you, but has actually achieved these things, and changed their processes in these ways.” And it adds a couple of things. First of all, a team that’s local to them potentially have already walked that path and walked that journey, and can give you experiences that worked well or didn’t work well. But secondly, you’ve got devs talking to devs, which is a very different dynamic to a security team, the traditional security team giving bad news or telling a development team how to do their job or what they need to do. So that dev to dev exchange tends to be a richer environment where they’re talking the same language, they’re there with no agenda, just trying to help each other out so that they can similarly see similar results after those changes.

Dormain Drewitz: So this is making me think of another role that here and now just it’s going to be the next big thing, I promise. Right. I feel like what you’re thriving in terms of someone who’s able to make use of the visibility and transparency, but then also take that next step. Say like, “Well, if we really want to ship this team, we have to find a similar team.” It’s like, you’re talking about a security anthropologist or something. It’s like someone who’s doing a qualitative research on like, what are the species in their natural environments responding to?

Simon Maple: I’m willing to endorse that skill on anyone’s LinkedIn now. I think we can make that take off. I think we can get that trending.

Dormain Drewitz: Yeah. We’ll just keep coming up with the exciting time titles, but in all seriousness, it’s interesting. And again, I’m going to come back to like, is that the Security Champion’s job? As you said before, it’s like the Security Champion is making sure that the team is doing the security work. They’re not necessarily doing it themselves, but part of making sure that it gets done is making sure that they’re motivated on some level. And so, how do they go about finding the right comparisons within the organization? That can be hard. I mean, I just know internally, right, like finding what’s the right case study for someone that’s like, “Oh, it’s got to be this industry. And got this particular challenge.” And you end up being like the librarian of all internal examples.

Simon Maple: It absolutely is hard. And I think it’s not always possible as well, which is another challenge because you might be that team that is either doing this for the first time, or wanting to follow the examples of other teams, but those are the teams work in different ways. Maybe you’re a team that love using GitHub Actions, for example. But if another team that has already done certain things, haven’t implemented a security process or whatever it is in that way, you are now implementing it slightly differently. So you’ll never get a complete match necessarily. But I think it’s really good to like have allies that you work with who are of a similar ma dev and security maturity, so that as a Security Champion, you can workshop these ideas together with people. One thing that I know a number of groups that I talked to did was when they joined the program as a Security Champion, one of the first steps they did was take a security, like a scorecard. And that scorecard was effectively a self-assessment of whether or not they are practicing certain processes, whether or not they are doing things throughout the pipeline at different times, and how they react to that. And ultimately, they give themselves score. They rank themselves on certain things. And one of the things that I’ve seen work really well is allowing the dev team to own that scorecard. So they’re self-assessing, they’re the people who can choose where they as a team want to progress next. What is the thing, which is the biggest pain point for them as a Security Champion or their dev team, and how can they fix that? A really good way that you allow that Security Champion not to work in isolation or as a silo is to find others within a group or within your business unit, for example, that have the similar needs. So who are the people that equally have the same pain, or for whatever reason have chosen that as the next thing they want to overcome? And get people together to talk about the problem. Why is it a problem? How are they thinking out overcoming it? Because one team might completely overlook a solution that another team is trialing. And I think it equally allows people not to make the same mistakes. They can see things that just plain won’t work, but on paper looked good, and they can share that knowledge and those examples. So yeah, I feel like that is a core part of that Security Champion role.

Dormain Drewitz: Okay. Yeah. And so you’re referring to how, like really almost the programmatic element of Security Champions, where there should be something formal about that program. And part of that is that it gives those folks a place to connect, exchange ideas, share best practices, understand like, “Hey, my teams identified this.” I love what you’re saying about letting the dev teams really drive it and do their own self assessment and then prioritize, “Uh, this is where we want to spend time.” And then the Security Champion can say, “Hey, this is where my team wants to start. Who else is walk this path already?”

Simon Maple: Yeah. There are always going to other things, other initiatives that the organization might want to achieve. And perhaps they can say, “Here’s one thing that we all want to step forward together in as an organization, but we also want you to pick one thing.” And I really mean one thing, because it’s one of the other big problems that people can get into is try to achieve too much too quick. And it can be very overwhelming to development teams and actually quite frustrating as a security team or a Security Champion whereby you want to achieve these five things and think you can do that in three months or four months. But actually, you need to go at the speed which the development team can adopt and actually take these changes on. And we always think that’s faster than it actually is in real life. So yeah, literally one or two things, maybe one thing a quarter could be a good cadence to build up and grow slowly within that team rather than just switching something on.

Dormain Drewitz: Yeah. There’s a lot of parallels that to application modernization, which is certainly a world I’ve been immersed in for a while, but the classic breakdown of trying to boil the ocean and bring in consultants, and they’re going to spec everything out, and it takes 18 months and to even figure out like what the first problem should be. And by then, it’s like the problems moved anyways, but, yeah. That boil the ocean approach really doesn’t doesn’t seem to work out very well. So that’s a great call out as well. One thing is part of how you and I started talking about this was maybe almost a year ago, you had tweeted about how you didn’t recall DevOps taking off because there was some champions program, and sort of you were asking this question, if you will, about why is security taking this model of a Security Champion when we didn’t do that for DevOps? And so, I wanted to poke at that a little bit, that was many months ago, you’ve had a lot more conversations. What have you taken away in terms of, there’s certain parallels? And it was interesting to hear you call out like, where companies that set those really high level goals on these nonfunctional requirements that they’re still going to say are super important, reliability, security. So there’s parallels there, but to your point, the champions thing seems be different. What have you learned about folks trying to take this approach versus how they’ve approached DevOps?

Simon Maple: Yeah. You mentioned that and I’m desperately trying to remember what some of the answers were, some of the replies were to that tweet. No, I think it’s a really interesting comparison. And I think one of the things of course, with the DevOps and DevSecOps comparison of the, you write it, you own it, you write it, you maintain it, or you write it, you secure it. I think one of the core differences between them is when we see DevOps build out and grow, and operations more becoming code and developers writing that code and maintaining the infrastructure’s code in the cloud config and things like that, what I feel we’re ultimately seeing is the app grow in scope based on what a developer or a DevOps individual would need to deliver. So that’s growing in scope in the sense of a developer would typically… My career originally started 20 years ago at IBM. And the idea of writing an application and throwing it over a wall wasn’t too far away. But the idea now of actually you write the application, you think about the infrastructure it’s going to build upon, you think about the container it’s deploying in and you start writing then. Maybe you have some golden images that you’re pulling through and making some infrastructure as code changes, checking it all. And the difference between that and the security model, there’s no security deliverable that is a part of the application that you deploy per se. It’s much such more similar in my opinion to more of the functional, the integration testing that developers have adopted. In that sense, there are more similar parallels where testing for regular bugs, integration testing it’s about minimizing risk. Security is exactly the same. You’re trying to mitigate risk across your organization and understand where that risk might sit. I think one of the other core differences and big separators here as well is that with things like infrastructure is code, bringing those operational deliverables much closer to the developer, DevOps teams need to be much more developer oriented. And they very often sit in development teams as well, depending on organizations, but the discussions that you would tend to have between a dev and a DevOps team would be actually much more relatable and much more on the same level with a developer. However, from the security point of view, you tend to have preexisting security teams that are more traditional audit style and presenting those audit results to the developer that then has to go through, and fix. The two there are very different levels where you see the security teams care much more about risk and exposure, while the development teams care less about that, and more about how to actually fix what is it actually impacting in my application and how reachable is that? How exploitable am I? And they think about things from a very different level. And I think it’s that not seeing eye to eye between the dev and the security teams, that is one of the most critical areas that needs to be worked on. And that’s ultimately what Security Champions programs are, they’re mechanisms in which security teams and dev teams can better collaborate at a level that makes sense to developers. And the idea of a Security Champion being on the dev side really, really works to that case. It’s about a dev talking to the rest of their dev team about security, rather than a more traditional security individual with an audit mentality and audit background, trying to push that message to a dev team, which we’ve seen time and time again gets pushed back from dev teams.

Dormain Drewitz: One thing that you’re hitting at there is also this notion of, yeah, what you can measure and what is done. Because yeah, your comment about a traditional security team, that’s got an audit mentality is thinking in terms of risk exposure. And it’s like, it never drops to zero. It’s like, there’s always something there that’s difficult if you’re like, “Well, just is it broken? Is it working? Is it up? Is it down?” Which those are conversations that both dev and ops can have that are a little bit more binary. Then there’s the whole range of questions in terms of really the developers building a thing. And it’s like, is it converting the customers? Is it doing whatever it needs to do for our business? Sure. That can be that awesome total question of like, well, it’s never zero, but it’s never done. But when you come to something that’s it’s not that part of the code that they’re developing, it’s like, have we done it? Can we just move on from this? And the answer’s never yes from a security perspective, there’s always something else. And I think where your question got me thinking, your question many months ago, I started to think about the role of an SRE where it’s like, “Hey, we’re going to establish these service level objectives.” Right. And again, the answer isn’t 100% up, and we’re going to manage a different number, but again, you at least have something you can measure. So the SRE is maybe in depending on how it’s implemented is like a reliability champion in some ways, but at least they’ve got something a little bit more concrete that SLO that they can work around and they can know like, my work here is done. This team is at a satisfactory level and they don’t need to have the handcuffs anymore because they’re operating within this SLO. And so it’s interesting. Like, thinking about security, it’s like, yeah, how would you measure that? You can’t. And then, so you inherently are like, this is to me another big difference and why you need this intangible collaboration to just be ongoing. But I imagine that’s something that folks probably struggle with a lot. Just how far do we have to take this? When do we know we’re in a good place? Because the security audit team will always come back with something.

Simon Maple: Yeah. And do you know what, that is a really hard question to actually get a good answer to. And I think we always say, “Hey, this year is the year that we’re going to really crack security measuring and things like that.” There’s a couple of things which I think are really core differences here. With the ops teams, exactly like you say, you effectively look at reliability, you look at, how many nines can we achieve? With security, what does that look like? And I think ultimately in security, you count up not down from a number, right? So you say, how many vulnerabilities have right now? What does that mean for our risk? What is a high risk number? And it’s like, unless you actually have context for those numbers, they’re just numbers. And I think context list numbers are extremely dangerous to throw around. One thing, actually that [Gopo 00:32:38] and Patrick de Boer did some work on, is the idea of actually what dual, a four nines, five nines style approach from a security point of view would be, and starting at a hundred, rather than count up from zero, depending on your number of vulnerabilities, et cetera, and things like that. You start from a hundred in the same way, liability works, for example. And depending on how your dev teams, for example, address their critical vulnerabilities, whether they’re doing it within the right SLA times, et cetera, it’s the process and the behavior of the teams, which you see those numbers drop and you’ll be year to say, “Here is a number of our processes, our culture effectively, our practices.” And that is a number we can strive for. And you can look at that service to service or team to team, for example. So that was an interesting way of looking at it. I know Alyssa Miller is another wonderful person in the security space who did some really interesting work about thinking about how you can provide context to numbers. So for example, if you see a project that has vulnerabilities that are increasing, what does that mean? Does that mean that project isn’t getting enough love from the security angle? Or has that project just recently doubled in size and the number of vulnerabilities per line of code that has been committed is actually halved? So one of the things that she looked at is building up these models, where you have relationships and you care more about the relationships between nodes, or between numbers than the actual numbers themselves. So for example, as I commit code, that is a good growth relationship between that and the number of vulnerabilities or bugs issues that you would expect in that code. As you add code, you expect more issues in that code. So you can see those relationships, and depending on how the various numbers react to each other, you can determine whether you are improving your general security in those spaces or not. So, yeah, measuring is something which is very hard to do nowhere near correct. And I think bringing it back to Security Champions, one of the core things, because nothing’s ever done is really important to actually be able to reward based on what people are doing and accomplishments that teams or individuals have made. And that’s a really a good way of rewarding individuals and teams so that you can actually share and say, “Hey, this team achieved this, let’s get this VP or this SVP or C-level to acknowledge this and give shout outs in the right places. Or let’s get these people out to, I don’t know, Blackhat or DEFCON, or different places in which they can grow their nodes because they’re showing real value to the company, and we want to build that up and we want to reward those individuals.” And that’s also a great way to show a path that one team has taken and encourage other teams to strive to achieve the same thing. It’s equally a great way of recruiting people into the Security Champions team, because they see others whose names are up in lights, who are achieving wonderful things. And they think, “Hey, I want to be able to do that. I want to be able to be that person who can achieve that for my team.” And it’s a great way to get people in less of a voluntold way, but in a voluntary way into a Security Champions program.

Dormain Drewitz: Well, as we wrap up here, there’s been lots of good tidbits, and I know also the paper that you’ve written, which is available and we’ll provide a link in the show notes for folks. Final thought, one thing that folks could start doing this week that would help them on this path towards having a Security Champions program, right. That’s benefiting their organization. What would that be?

Simon Maple: That’s a really great question. I could give answers around tools or processes or practices, but I think the most important thing is culture. And the biggest challenge to any individual is to go over and talk to the security team, or be able to understand where the security team can help. And I think having that empathy and trying to make sure the other teams that you’re working with have that same empathy for you. So being able to very clearly explain and define the problems, the restrictions that you’re working in, et cetera, I would say that is the most important thing. Everything else can follow, but if you get that communication, that openness, and that willingness to want to work and share with other teams, that is the most important thing. And you’ll find that typically when you start building those relationships up, you will begin to have shared goals with other teams based on those relationships.

Dormain Drewitz: Okay. Well, that is a great assignment for anyone who’s listening, catching up on this podcast, go have a quick convo with someone on your security team. First, always feel free to ask them if they’re a coffee or tea drinker. We all know-

Simon Maple: I was going to say, bring a tea as well, and have a conversation.

Dormain Drewitz: Well, maybe the first conversation you got to find out are they coffee or tea, so the next time you talk to them, you show up with one in hand and you already know what they like.

Simon Maple: You don’t want to bring a sweet tea to someone who clearly just doesn’t want sweet tea on that day. Right. So that’s a good opener.

Dormain Drewitz: Yeah. So you got that opener. That’s my gift to you. And then yeah, ask him like, “What keeps you up at night? What does good look like from your perspective?” I think those are great questions and this is a great call out, Simon is just to get people to start to each other. Thank you.

Simon Maple: Pleasure.

Dormain Drewitz: Okay. Well, with that, thank you again for joining us on this conversation about Security Champions. We tapped into a lot of different topics. This is Dormain Drewitz, and I am wishing you all an uneventful day. That does it for another installment of Page It to the Limit. We’d like to thank our sponsor, PagerDuty for making this podcast possible. Remember to subscribe to this podcast if you like what you heard. You can find our show notes at Page It to the Limit, and you can reach us on Twitter @pageit2thelimit using the numeral two, that’s pageit2thelimit. Let us know what you think of the show. Thank you so much for joining us and remember, uneventful days are beautiful days.