Gamification, Reward, And Empathy With Joshua Gamradt

[00:00:24] ANNOUNCER: Hi. You’re listening to The Secure Developer. It’s part of the DevSecCon community. Join us June 23rd for DevSecCon 24. It’s a free, global, vendor-neutral, community-driven conference that connect developers, security and operations teams to learn and enable the integration of security into their development practices. Found out more at devseccon.com.

This podcast is sponsored by Snyk. Snyk is a dev-first security company, helping companies fix vulnerabilities in their open-source components and containers, without slowing down development. To learn more, visit snyk.io.

On today’s episode, Guy Podjarny, founder of Snyk, talks to Joshua Gamradt. Joshua is set on influencing cultural change and introducing security by investing in others through the development and delivery of gamified security. Engineering, customer-centric security solutions, focusing on risk and utilizing continuous feedback and data to drive our decisions. He began the journey of shifting his empathy left and focusing on the customer as a service manager over rugged DevOps at UnitedHealth Group.

We hope you enjoy their conversation, and don’t forget to leave us a review on iTunes if you enjoyed today’s episode.

[INTERVIEW]

[00:01:47] Guy Podjarny: Hello, everyone. Thanks for tuning back in. Today, we’re going to play some games. We’re going to dig into gamification and in general, sort of working with developers and to share his views on all of the above is Joshua Gamradt, who’s kind of more commonly known as ‘Shua’. He’s the director of rugged DevOps at UnitedHealth Group. Shua, thanks for coming onto the show.

[00:02:09] Joshua Gamradt: Thanks for having me. I appreciate it. I appreciate the opportunity and actually, kind of really humbled by the opportunity to in some cases be considered an “expert” or a leader in the field and have this opportunity to come speak, so I appreciate it.

[00:02:23] Guy Podjarny: No, I think it’s all about sharing our knowledge and helping push through as a community. Before we dig into all the sort of meaty topics here. Tell us a little bit about, what does it mean, director of rugged DevOps and maybe in general, a bit about your journey into security and through it.

[00:02:39] Joshua Gamradt: Yeah, absolutely. One thing I always have to share as a part of this is that, I don't have a security background. I don’t have those 20, 25 years in security and seeing the evolution of where things are. I've come from actually more of a Six Sigma background, process improvement, value streams, all that stuff. For the last six years is where I’ve spent in my career within security itself. So not coming from a traditional security background, I come in and I jokingly say this to a lot of people that would help me really get engaged into security, especially with Rugged DevOps and application security, is I have this unhealthy desire for people to like me.

Getting into security space, I always was asking like, “Why do these people not like me?” What they really did was put me down this path and this journey of creating connections and relationships with people that started to help me broaden the understanding of what security means across an entire organization and not just within the security space. Those relationships allowed me to be empathetic and allowed me to see where are the gaps and where things exist today that we should be trying to focus on closing. The last six years has been this journey of relationships, this journey of connections, this journey of working on both the security side and the engineering side.

From an industry standpoint, what you’re going to hear a lot of is this DevSecOps idea, this DevSecOps movement. I came into that movement probably two years ago. The thing that always bothered me around the idea of DevSecOps, especially when I was talking with engineers is, I was already engaged in the DevOps movement, like this idea of DevOps and how long that’s been around. It really felt when we said DevSecOps that we were taking this Ivory tower of security that engineers see and then plopping it in the middle of DevOps and saying, “Hey now, let's start doing DevSecOps.” You have engineers who are saying, “We’re already doing DevOps.” Instead of security, taking on the approach of saying, how do we integrate and assimilate into the DevOps movement as looking at security as quality. Why are we calling our own specific thing, because now we have two kinds of veins in which people are going after. I took an assessment around what do engineers gravitate towards.

This idea of rugged software started coming in my mind around “How are we driving towards impenetrable, quality, deliverable and secure, sustainable, scalable software?”. Rugged software is an idea that exists out there. In my mind is, well, we are trying to create rugged DevOps. We are trying to create this platform of a rugged engineer, that is both on the developer or the IT side, but also on the security side. That's where you're seeing the journey get to me where we are today and why — like here, rugged DevOps versus DevSecOps and all of that.

[00:05:53] Guy Podjarny: It’s a fair and good kind of perspective on it. Buzz words are always tricky, they don’t really encompass the complexity of these big topics. What does it mean then? You explained the rugged DevOps versus DevSecOps. When you’re talking about being director of rugged DevOps, what does that in practice mean in terms of your role in the org?

[00:06:11] Joshua Gamradt: If I change this even just more of a philosophical standpoint of “What am I trying to do as a leader within rugged DevOps?” has more to do than just the company. I'm looking at this from an industry perspective and how have we driven security in the past. A lot of this as I mentioned, the relationships and the connections are a huge portion of what it means to drive a cultural movement, especially within the rugged DevOps space. What that means for me is I’m driving first and foremost a cultural movement within my line of work I'm trying to get my team members who work under this particular organization to build the same connections in the relationships that I have. It's moving us away from being a compliance-based thinker into a human-based thinker or a customer-focused based thinker. It's more of like, “How can I help you?” Not a, "what-have-you-not-done?" mentality.

As we’re going down that path and moving into a more customer-centric focus, then we start to ask how are we changing or evolutionizing the capabilities that we’re focusing on. One of those capabilities for the longest time - and I just kind of mentioned compliance - was we focused a lot of our technology and a lot of our ways in which we applied security from an architectural, but more specifically from a, “I need to identify vulnerabilities at a certain point, and I'm going to base success on how many vulnerabilities that I find. That's going to be my success factor. Whereas, I look at rugged DevOps and what we’re trying to do here is, the success factor is actually in preventing vulnerabilities from being identified in the first place.

What that means is, we need to now start investing into the development of not only our engineers, but also our security people. You're going to be seeing a focus of my team and rugged DevOps of investing into engineers to teach them the awareness, and the skillset that they need to incorporate security as quality into their development lifecycle. At the same time, we are developing a program that teaches security people the awareness and skill set of a developer, so that at some point, we can take both of those human elements from each one of those industries and have them meet in the middle at some point. That is where the relationships, and the connections and the ability to no longer speak in industry terms. You are no longer having to fight or be zealots over specific terms. You now have a common base of knowledge that allows you to say, "how are we preventing this together?" Versus one side saying, “All you’re doing is tell me what I can’t do.”

To me, it seems subtle, it’s a little subtle if you think about it. But really, that’s the crux and the overview of how I think philosophically what I'm trying to do differently from rugged DevOps versus a traditional security kind of program.

[00:09:35] Guy Podjarny: Yeah. It makes a lot of sense, and actually a lot of analogies to sort of the core DevOps, the sort of the embedding techniques, the walk-around-in-their-shoes type perspective. Fundamentally, just core empathy. I think a lot of sense in that. I think we’ll probably dig primarily into the developer side. But before we do that, when you talk about investing, and sort of security people and doing those. What are some concrete practices, like the to do in the team? Is it about hiring different people into them? Is it training? Is it indeed embedding? Anything else? How do you get security people to build up that appreciation or into the world of developers?

[00:10:12] Joshua Gamradt: To be honest, that’s been a journey too, and it’s not over yet. I feel like like that part of my philosophy is that I spent so much time being empathetic to engineers that I forgot about security engineers as I was going on this journey. If you're wondering like “how did that evolution work?”. As we started to build out security awareness, and skillset training for engineers, what I started to find out was, a lot of security people saying, “Well, wait. What if I want to learn developer skills?” That's what really started getting probably less than a year ago is when that particular part of my mind started thinking “We need to start investing in this side”.

You'll see the lessons learned of the topic that we’ll get at really soon, which is the gamification of how we are investing into the developers, how that same lesson learned is being used of how we’re applying it to the security space too. So still, a gamified approach to the high-level idea of increasing their awareness, and skillset, which is kind of helping them walk in a mile of the developer’s shoes. At the same time, to broaden your question or answer the broadness of your question is, yes, as people have come through the training part of the program that has been invested into the developers, we have found a group of talent that have been interested in embedding themselves into the security organization, as talent to be thought leaders and how we try that cultural movement in the security space, which I think is in the — we are in the crux of that industry change at this moment, right?

Like I feel like I'm experiencing that change. It comes with both a passion for thinking I'm doing the wrong thing, because somehow, I am in some cases anyone is going down this might be thought of as, you are stepping on the bounds of what security supposed to be. Versus others who are on board who are thinking, “No, this is right. This is uncomfortable, but it's a legit uncomfortableness that we all must experience in order for us to make it to that next evolution of where we need to be as a security and a developer organization.”

And you have this third category, which is, I have no clue what's going on but I'm just going to kind of go along with it and hope I see where it ends up. All of that being said that it’s been both the training, it's been the hiring of individuals. We’ve had engineering experience within the security space, and then it's reversing my empathy for engineers to also now figure out how I'm empathizing with the security space.

[00:13:03] Guy Podjarny: Yeah. What’s the sort of the core root of the discomfort? Where do you find people are most uncomfortable with regards to this change if they come from the previous different kind of perspective on it.

[00:13:16] Joshua Gamradt: I think you’re now getting kind of the human element or the human characteristic of change is uncomfortable any way that you look at it right. As you and I were preparing for this conversation and you talked about, “I'm moving into a new house. I’ve noticed that as I'm doing different things in my life as talking to a plumber, talking to an electrician, talking all this stuff. I feel like there are things that I'm dropping the ball on, or I’m letting go behind, which creates this uncomfortableness in you. Because it’s something that’s totally foreign to a certain degree to your everyday experiences in life.

Going back to what I said earlier that I'm coming into an industry that I'm working now with people who have been in here for 25 years, who have been in here for 30 years, who have been in here for even 10 years. The amount of change that has happened in the technology landscape has been so fast, that when you look what I see is traditional security skill sets - going to college, building your knowledge and awareness around security, thinking of how you apply it, thinking about the software development lifecycle and how waterfall to agile has even changed - think of how much testing in general has changed from a quality perspective against an application. How you run continuous testing is so different, because from a waterfall, you could wait until the end to test everything. You had this huge — it was almost like the huge event. And the same thing with security, you have this huge event applying security.

Well, now that that comfortability on how we used to do things are being challenged, like anything else, it's like they're going into a new house and having to do something totally different. Not only are they having to do something totally different, they’re being made to do something totally different. And none of us like to be made to do anything. None of us like to be forced to do anything. And I think that is where I feel the discomfort comes from. And until you get them to — it’s kind of like jumping into a pool, right? This idea of, you don't know how cold the pool is, you can hypothesize how cold the pool is, and you build in your mind how bad it’s going to be when you jump into it. But you don't really know until you dip your toes into it. Then, you can start to create and formulate a reality towards your assumptions. I feel like I'm asking individuals to even though their discomfort is there, just deep your toes into it, just take even that little bit of foot plunge in order to open up your mind towards what change could possibly mean for you.

[00:16:07] Guy Podjarny: Yeah, makes sense. Let’s indeed sort of shift to the developer side and sort of — I guess we’ve been sort of taunting with this concept of gamification a little bit. Maybe give us a bit of context about in general, how do you engage or think about engaging with development, then we can kind of go into how does gamification play into this.

[00:16:25] Joshua Gamradt: As I mentioned earlier, this idea of — I started asking the question, like how are we to a certain degree having engineers dip their toes within the security space, right? I think there’s a whole bunch of ideas that have been tried, and what I want to be cognizant of here is saying that I'm standing on the shoulders of giants who have come before, me who have really thought about gamification prior to this. Security learning programs, embedding security champions into teams and things like that. I don't want to make this idea of, I've come up with this on my own because I haven't. I’ve built off of — and actually, that’s what I love about this to, is that I was able to engage in continuous improvement off of things that have come before. I did a lot of looking around and researching of what kind of knowledge things could be put in place, everything like that. There are two things I really thought that needed to come into place for how we work with the engineers. One is, we needed them to understand first of all the security awareness, how are we building out their awareness of what security is. A lot of what you’re going to see there has to do with classroom training, like sitting down, hearing learning, digesting, meditating and having the opportunity to talk about it, right?

The second thing that I thought about focusing on is then the skillset. How are we putting into the hands of the developers the opportunities to actually work now on what they just heard in the classroom? Anyone can sit in a classroom. Personally, I'm horrible at test, so I could sit in the classroom, I could have digested everything and just taken a test and you would have thought, I didn’t listen to anything, just because I’m horrible at <>. For me, the way I learned is through hands-on application. This combination of how are we building the awareness, how are we building the skillset. Third, how are we building excitement around doing it, and this desire to want to be a part of this.

There was the philosophy that we started talk about around gamification and how we created that excitement through gamification, and a psychology of gamification we're honestly hitting upon — that's why I say, like I'm standing on the shoulder of giants is because, all these freemium game people already did this work for me of, why am I so like Candy Crush. That’s kind of what went through my mind right away when I started thinking about — I spent hours playing Candy Crush when it first came out, and I’m trying to think, how do I in a healthy way get engineers to spend time for what they are doing spending time in awareness and skillset of security.

Thinking about in that ways, how are we rewarding our engineers for spending time here. Because I think traditionally, what you would see at is, I constantly hear and I’ll still hear it today. There's nothing wrong with the idea of the stick versus the carrot. I constantly heard as a solve for our problem is, you needed to introduce the stick. In my mind is I’m like, “I mean, okay, I get the idea of policy, law, making sure people are doing it to protect people. However, we can reward people for doing the right thing too. We forget that that's a part that is going to get people to do it. That's where the gamification idea came in is, then how are we rewarding our engineers for spending time doing that.

[00:20:12] Guy Podjarny: Before you kind of dig into the specific of the gaming just for the context of it. So you apply all three approaches, the gamification comes on top of because you have the — if I heard it correctly, you have a baseline of security awareness that I guess everybody needs to undergo which is some form of a training, of classroom. I guess I imagine today, it’s online-type training, followed by some exercises, some sort of application. Then followed by the gamification to lure them in further in their daily lives. The application is on your code, or when you do apply what you’ve learned, is it on UHG code or is it on sort of sample exercises?

[00:20:49] Joshua Gamradt: Great question, because now you're getting at the philosophy of what I think our quest that actually work or the application side of it. In the true gamified thing of it, you’re going to hear me call them quests. If you ever played any type of game or if you’re thinking [inaudible 00:21:07], you always went on these quests and you're given this directive of, you need to do this. In order to do that, you then went out and did it. All of these quests are built in a way to apply to the application that exists within Optum.

The reason that — this is kind of where my idea came in differently compared to what I've seen in other educational programs, was the benefit that I wanted to see come to us also from a security side of things was, their taking what we’re asking them to do and applying it to their application, so that their understanding our best practices and we're benefiting from it because they’re actually applying now what they learn to their physical application, and they’re saying, “Oh! That’s how it works.” It’s also pointing developers towards best practices and repeatable patterns of how they apply what they've just learned to their application as well.

The third thing that I see that came out of that, how it benefited the security side is that it challenged us to look at these questions say, “Are we prepared in a way to have developers walk through this quest and apply what we’re saying?” Right? “Have we made this quest so impossible because we haven’t enabled them to do what they’ve asked them to do?” It’s challenged us in that perspective too.

The fourth thing is, and this kind of gets into what other people might run into a problem with when they're trying to apply some type of learning program or gamification is, a lot of our — if you're looking at funding from a development or an application standpoint, you have a lot of — especially from an agile perspective - you have user stories that are created to create features that the businesses paid for, so there's an X amount of money that's described for the product that you're building upon.

If we created simulations of applications, that would mean that they would have to find time outside of their development cycle to spend towards learning and application. What I wanted to do is say, “Actually no, how about you build these quests into your backlog so that you benefit by doing what you're supposed to be doing within the backlog itself and you’re that much further ahead. That is all a part of what the business is paying for as part of your product in the first place. That is still a philosophy I think that some people totally understand, and grasp, and build into like leaders have grasped it and built it into their backlog. They’re saying that, even though this is training, this is actually application towards a particular user story towards my product. Whereas, I still think we’re kind of fighting the philosophy of those individuals that might still see it more as its own training piece. That's a part of the journey that we’re still evolving through.

[00:24:06] Guy Podjarny: I think lots of great pointers over here from what you said around aligning training time to actually sort of improve the security poster, all of it. It does imply. I love the use of word quest here for it, but it puts a lot of weight into that preparation piece of what — maybe let’s dig in, what is a quest? What’s included in a quest? What’s the definition of a quest?

[00:24:29] Joshua Gamradt: A quest in this, like I said, it’s going to be more attuned to someone who has played video games, especially role-playing games. Is that you as an individual, one element that is missing for developers today is 'why', like the story around why is this particular part of security important to do. If you put yourself into kind of a video game mindset, you're always walking around from role-playing perspectives - talking to villagers, talking to people in the town, and they're telling you a story. They’re telling you, “Hey! I went through this issue” or “This is a problem that I have. I need you to help me solve it.” The first element of our quests is hitting upon that is, we tell the story. Why is this quest important? Why is doing security testing important? How is it even applied to you as an engineer, especially from a quality standpoint? And how do we make it less daunting of an experience? So make it more digestible from that story of what it looks like.

Then what happens when you're in that position, that story then turns into what objectives do you need to do in order to accomplish delivering on this quest. Here’s your story and here are the objectives you need to do in order to solve for that story, in order to help that villager, in order to help that town's person, what do you need to do in order to do it? If you’re thinking of yourself in that person, in that player mentality, this gives you that inventory when you pull up your profile and you say, “Wait! I’m on this quest, what was it I needed to do? Here’s my checkboxes of what I needed to do?” What happens out of those objectives are, there is evidence that is usually collected to prove that you accomplish those objectives. For example, if you are in your video game and it’s like, “In order to protect these people, you must go out and get 20 spiders. You go out and you get these 20 spiders, and they’re now in your inventory to prove that you’ve done it. That’s the third element of a quest is, what evidence can we collect to prove that you’ve accomplished these objectives.

Usually, the last part of that story is you go back to the villager and you say, “Here is the evidence that I did or that shows that I accomplished these objectives. Can you look them over and give me my reward?” That’s the last part of our quest. It’s, you now go back to the subject matter experts that helped build that quest. You show them the evidence that shows that you completed those objectives. We review it and then we release the reward to you. The final step, really of the quest is the release of reward. The release of reward is you gain points towards earning a particular level that you're trying to go after.

For us, you can go from novice, to intermediate, to advanced and to expert. In the novice, you need to collect so many points, so there so many quests that you can accomplish in order to earn those points. There’s the sitting in classrooms in order to like, “I accomplish these many courses to gain those points.” Those rewards come to you in points and once you’ve earned novice, you are then rewarded a badge, a digital badge that goes along with you that you can now have bragging points on LinkedIn for example to say, “I've accomplished this. Here are the things that I did to accomplish this. Here are all the quests that I accomplished. Here’s what I learned. Now, I’m going to move on to the intermediate.”

Wanted to give you, not only answer your question of, “What are the different makeups of — what make up a quest?” But then, how does that fit into the gamification mindset of then, what's next, right? Like how do I make it to the next level?

[00:28:32] Guy Podjarny: It’s a really cool flow and it’s quite unique I must say, like from what I observed. What’s the resolution of this quest, like is it a quest to learn about process drifting? Is it OWASP top 10? Is it secure coding? What’s the unit size here?

[00:28:48] Joshua Gamradt: Yeah. As I mentioned, we've employed a novice to expert level. What you're going to say in answering your question, it’s going to go from easier to hard. The three main quests that we made up in the first release of the security advocate program. We wanted to focus on secure coding, so we used a platform that challenges engineers to look at code to identify vulnerabilities within a code using the OWASP top 10 and how do you identify the vulnerabilities within this code, then how do you fix it. You are graded upon that, so that's probably the only quest and the initial thing that doesn't actually apply to your application. We actually have a simulated area, because then we know these vulnerabilities exist.

Focusing on secure coding. The second thing we want to focus on is threat modeling. A lot of what you're seeing within the architectural space today, threat modeling to me goes beyond security. It’s actually unfortunate to me that it’s just called threat modeling. When what we could be saying is, we are doing solution architecture design, and on top of that, identifying the threat as a part of that solution architecture design. To me, this is an enterprise architecture way of trying to teach. It's now, we’re trying to improve the skillset of an individual to now apply threat modeling to that.

We have them go through a threat modeling course that teaches them kind of lightweight how to apply the threat model to their application itself, and then they deliver us the ability to show how can they apply this threat model, how do they identify threats that they hadn't previously identified with their application, how do they show us that they built a user story to remediate those threats. Then they move on to the next piece, right? But it’s a fairly small. We want an archaic one at the novice level. Like I said, said we focused on the secure coding, the threat modeling and then we talked about security automation, which is now how you are applying security testing or security quality to your — so now that you’ve learned how to secure code, how can you prove that you did it. We want them to automate a security testing capability into their development pipeline.

If you are within your journey of DevOps or CICD in an automated fashion, how are we helping you or enabling you to integrate whatever capability we have today, which again shows you why the value of these quests apply to actual applications is that we as a security team can actually point you to the right tools to use as well, or the tools that we expect you to use. Then same thing, how are you running a complete security test against it, or a scan against your application, show me that you’ve identified some vulnerabilities, show me how you put them into your user story or backlog and how you fixed them.

Then what happens then from there is an evolution of what you just asked, because then it gets harder. As you move into intermediate, you move into advanced. I’d be honest, once you make it to expert, we call the evolution learn to teach, so at the novice level, you’re learning. And as you keep on moving into the program, we expect those who make it to the expert level to actually be teaching all the things we've been talking about.

[00:32:10] Guy Podjarny: Which actually is a great lead into the question I had, which is, who is the training aimed at? This sort of gamified, is the intent that all developers go through this? Is this more like security champions? Because you talked about the security advocacy program for it. Who’s meant to consume this or who’s meant to play?

[00:32:29] Joshua Gamradt: That has been an evolution too, and specifically for our journey. This has been a really, really cool thing is, it all started out with engineers in mind, like how do we take — how I want this to be construed the wrong way. But when you think about who can we target that introduces the most risk to the organization, that's what I mean by empathetic toward engineers and actually investing into them, is that if we see them as the risk, like you always — within the security space, we always said, “Engineers never want to do what we want them to do.” I always thought, in my mind, I always thought, “So we purchase solutions to prove our point or, why are we spending so much money here, instead of investing actually into the risk that you call out, which is the developer themselves. Which to a certain degree, the cool thing is, you can reduce that risk by teaching.

The first goal was to invest into a program that was invested into the engineers. As we did that, we started seeing people apply for the program, like we tried to vet out individuals and things like that, that we thought would be like — asking questions like, do you have an application to work on. If you don't, this program might not be for you. But as we keep on going through that, we started getting people who were disappointed that there wasn't something for them. We actually had a very, very talented individual who is going through the technical portion of the program or the engineering side of the program. She was a business analyst that was going through it and of course was really struggling to make it through that engineer-focused part of it.

She asked, “Can I build a non-technical track, like a business track, like an architecture track?” I was like, “Absolutely. Why not?” Because this kind of gets into the gamification standpoint, but I've always said that this particular program in anyone's journey should be called, 'Create Your Own Journey'. How does an individual who is not an engineer still look at the platform that we put in place and create their own journey? That's what this woman did. She went through and created the same type of — we’re going to sit there and here’s what from a business perspective, you should be aware of, from a security perspective, here are the type quests that we could apply to the business track or an architecture track.

We now have expanded in the last probably four months to not only target engineers, but now to target business people. I think in this broadening of who takes it really depends on who becomes just as excited about getting their peers aware within the track that they’re on in their career, and helping us add that content to the game, you could say. We’re now saying, “Hey! Are you going to be a warrior? Are you going to be a wizard? Are you going to be a —” Right? Like you pick what “race” you want to be a part of in your game or maybe your career picked a race for you. But you can now pick that and say, “How is my journey different as a warrior, or a wizard, or ‘assassin’?”, right? That's what we’re doing is refining different paths that people want to go down and just identifying which part of security we need to teach them.

[00:35:44] Guy Podjarny: It’s great that this sort of applies to everybody and I love the different tracks. Two key questions. One is, what is the rewarding system here? What do people get if they complete things? I know you talked about digital bragging rights. Then the second is, technically, is this sort of spreadsheets driven, is there sort of tooling behind the scenes. How is this implemented.

**[00:36:04] Joshua Gamradt:**The rewarding is, a broad spectrum that’s going to be a challenge, that is going to be different for each person. Let’s say that they wanted to reach out to me, and talk to me about how this work within their organization. There's probably going to be different challenges that exist with each company, and one of those things can be reward. The reason is, is that, you are going to have people on the program that fluctuate from entry-level, to senior people.

Within our organization, how you reward people either monetarily or nonmonetary fluctuates between all of those layers, right? We try to be flexible and reward where we can where people are at. For example, if you are entry-level and we have a reward system here that allows us to apply monetary reward to what you're doing, we try to release as a part of the reward of what you did is where you are within the program, that monetary reward to that individual that is able to have it. If you are not able to have a monetary reward, but it's more focused on kind of for example bonus, right, is what we’ve tried to do is create a copy and paste goal that an individual can put into their development program, like in a — whatever any company has where you’re looking at goals and objectives at the end of the year and how it applied to you for your end-of-year review, to allow you to have that conversation that said, you went above and beyond within your senior position, and then allowing that particular part of the system hopefully take its place.

The other part of reward that we really try to do too though is, swag, right? Like, “Hey! You do this.” We try to give out swag where we can. When you hit the novice level, we send out a certain swag item. When you hit the intermediate level, we send out a swag item. Each person no matter where you are, are going to get a swag item. Think of the non-monetary rewards, introducing individuals who graduated their certain place to the leaders, exposure. Like giving people the exposure to the organization and the leaders that, “Hey! This person is spending time doing it.”

I've really tried to do a lot of arguing with our CISO, with the leadership here to say, “Hey! Can you send a recognition to this person? Like even if it’s an email, I don’t care what it is.” I remember the first time when we first started going out, when we had enough of a small group of people, where we were able to do personal phone calls. I just thought it was great because our CISO, is able to call one of the individuals that had graduated, and I follow up with that individual and  I was like, “Hey! Did you get a call?” They were freaking out because they saw this name come up and they were like, “What did I do wrong?” You’re getting a call from the CISO, and I thought that was a great transition to show the philosophy change of what we're trying to do is, the CISO wasn’t calling you to tell you what you did wrong. We now have it calling you to tell you what you did right, which is totally encapsulating what we wanted to do and where we wanted to go with the program. Now it’s rewarding instead of having — like they thought they’re going to be hit by a stick. Instead, they were given a whole bunch of carrots with it.

Then the other reward like I said is, we do use digital badging here. We have a digital badging system, which allows us to get into the second part of your question is, what’s behind all this? We have a combination of we have developed our own platform, so we have a security advocate dot com. I'm keeping the name of our company out of it, but it’s a name of our company, whatever, security advocate dot com. Where you’re able to see the gamified reporting even. It shows who is the leader, who is all of this. Then beneath that, a data layer that allows us to track all of these things that we’re talking about.

But we've also partnered with other companies, so when we’re talking about the coding portion of it, we partner with companies to offer that particular platform. We also from a learning perspective, we have a learning platform that we work with to apply that as well. When it comes down to the quests, I actually integrated all of our quests into a Git platform, so that individuals would be able to see the quests, they are able to create their own repo of that particular quest, they add their evidence to the repo, they then submit a poll request for us to review their repo and their evidence and then we push that in. We're trying to kind of meet engineers where they were at. Then all of that is automated for how we release a badge, how we released the points, how we identify the points. That has evolved from just how successful we become. At first, imagine a spreadsheet of all the things that’s now evolved into a platform that we’ve developed for it.

[00:41:07] Guy Podjarny: Yeah, excellent. This whole gamification sort of set up is really quite next level and I could see how it scales super well. I love the rewards and it requires a certain amount of tech investment, but it sounds like it’s well worth the effort. I guess maybe one last question would be, how do you know beyond kind of a gut feel and such? How do you know that it’s successful? How do you measure kind of the impact of such a program?

[00:41:31] JP: I think that measuring part is still a part of our journey as well. The reason I say that is, what you would see as common metrics in the security space again gets towards how many vulnerabilities are we identifying, how are we making it so that they're actually doing it, all that stuff. And you take my philosophy of investing into an individual, the goal would be that we could make a correlation between the amount of security advocates in a particular product, or application, and being able to then apply that to the correlation of how many vulnerabilities are being reduced. But there’s so many factors that go into that, that it becomes difficult to create a true correlation between, “Oh! We have 15 security advocates, which means that we’re going to see an average reduction of vulnerabilities by X percent. However, we are building a historical view of trying to see if there is a correlation between those two things.” You're right, there's a lot of trust right now with this, but there’s also a ton of — like the success factors, the amount of excitement that we see with engineers who are wanting to be a part of this game.

Imagine the human factor of it, of how often has security and engineering actually interacted at all from a community perspective. I mean, think about it, we still have separate conferences that we go to. We create separate industries. We create separate stories. However, the success for me so far is that we've been creating an integrated story. We have a community of engineers who are interacting with the community of security individuals. One part of the program that I failed to mention that has its incidents, and its wins and its losses is, there was a coaching/mentorship part of the programs.

So as you as an individual who is coming in, we assign a coach or a mentor for the security side for you guys to interact. We’re trying to create a cross pollination of a community of individuals. When I say that, that was both a success and a learning, is that your experience with that is only as good as the attitudes of the individuals going through that particular piece. When it’s forced piece, you could have a really bad coach or you could have a really bad advocate or you could have bad both. We saw where that relationship still with people who are in there kindled the success of how these people talk to each other, because it opened up the black hole, which was security to an engineering space. But then it opened up the empathetic path that didn't exist before for that security person to be talking to the engineer.

I can’t tell you how many times I've heard security, people who are coaches on the security side and say, “I'm humbled to the fact that I can’t answer these people's questions, and I should be able to.” Where I thought that they were “individuals” who are unintelligent and didn't want to do anything they want to do.” I'm finding out that I'm far behind in understanding the problems they’re trying to solve and how they're trying to solve it.” So even my way of applying security and how you then work at it, they're starting to find out, “Wait! This isn’t apples to apples in how we’re actually trying to solve the same problem.” It’s created this open fuel of a community that never existed before. That’s success to me. That’s success to me, it might not be a success to some organizations, but I sure can tell you that that's the start of success. And hopefully the correlation based upon the history of the data that will going in would be able to tell, like as Paul Harvey said, the rest of the story.

Like I want to be able to have a conversation with you in the future, that's like gamification, the rest of the story, where it does tell and has true metrics that I can say, “Hey! Not only have we showed like the awesomeness that existed before, but we’re actually able to prove the metrics that show how much this works across reducing vulnerability, et cetera.

[00:45:54] Guy Podjarny: Yeah, I know, absolutely. First of all, totally signed up now for sort of that future episode. Second is, I totally fully relate. There’s gold in just breaking down the silos and getting people to collaborate. We’re just a group of people, and the more we work together, the more valuable it is. Shua, this has been spectacular and great, great insight and a great platform that you’ve built over there and approach. Last, before I let you go over here, one question I like to ask every guest coming on. If you take out your crystal ball and you think about someone sitting in your role, in your chair in about five-year’s time, what would be most different about the reality compared to yours?

[00:46:33] Joshua Gamradt: What I see coming, especially — and this kind of a maybe an overused term or misunderstood term is the idea of how artificial intelligence is going to make its way into how we drive security. A lot of what we see today is humans still interacting with their particular systems and [inaudible 00:46:56] technologies to kind of be the mediary to show us the telemetry that gives us, how do I interact with you security analyst point of view to you as a developer. Then how are working through it to identify like false positives. That entire process. What I see coming is, an artificial intelligence platform that identifies based upon input looking at code saying, “Just so you know, you're most likely with your team going to be introducing this type of quality, bad quality into your product. It’s going to give us intelligence to be able to point is the directions that we would have had more human interaction with before that I think artificial intelligence is going to work its way into.

I think the other thing from an artificial intelligence standpoint is that it's going to reduce the amount of like I said, the manual interaction that goes along with how we do our work, and the way we analyze and what we do is going to be totally different I think as we look into the future. I think it's going to free us up to again be more of a community of how we develop together versus having, I see it combination of an industry where you're not necessarily having the security industry and the engineering industry. We’re actually seeing a quality, like a development industry that’s built into it.

[00:48:15] Guy Podjarny: Yeah. That’s a great kind of look out into the future. I relate to a lot of this. Shua, this has been great. Thanks a lot for coming onto the show and sharing these insights and learnings. As we said, you are now signed up to future episodes to do a V2 or sort of learnings of a year later. So we’ll get back to you.

[00:48:35] Joshua Gamradt: I appreciate the opportunity and like I said, I’m humbled to have these conversations, be part of this, the opportunity to actually have the experiences that I’m going through. I appreciate it. As a part of this, I'm always like I said, I'm open outside of this. I don't work for a particular company. I have a philosophy that I love to share, I love to be a part of. If anyone, anywhere has this idea of wanting to reach out to me, please do so and let's talk about how we apply this to make a better space, make a better time for all of us as we’re kind of going down this journey. Thanks again. Thanks for the opportunity. I appreciate it.

[00:49:09] Guy Podjarny: No, for sure. Actually, if someone wants to find you on the [inaudible 00:49:12], where can they find you?

[00:49:13] Joshua Gamradt: Well, you’re kind pointing out though that from a security space, social media isn’t where I spent a lot of my time. But LinkedIn probably right now is the easiest way to get a hold of me, at least from a social platform perspective, it can be identified there. But you won't find me probably anywhere else.

[00:49:30] Guy Podjarny: Sounds good. Thanks again and thanks everybody for tuning in, and I hope you join us for the next one.

[END OF INTERVIEW]

[00:49:40] ANNOUNCER: Thanks for listening to The Secure Developer. That's all we have time for today. To find additional episodes and full transcriptions, visit thesecuredeveloper.com. If you'd like to be a guest on the show, or get involved in the community, find us on Twitter at @DevSecCon. Don't forget to leave us a review on iTunes if you enjoyed today's episode. Bye for now.

[END]