Farshad Abasi -- Three Models for Deploying AppSec Resources

Farshad Abasi shares three models for deploying resources within application security teams:

1. The Dedicated AppSec Person Model involves assigning an AppSec person to work with each team. Farshad shares his experience of working with developers and the challenges faced in getting them to understand and implement threat modeling. He also discusses the transition from waterfall to Agile and how it affected threat modeling.
2. The Federated Model: A security consultant attends weekly standups and sprint planning sessions in this model. They work with a checklist to quickly determine if any user stories could be security sensitive. This model reduces the allocation required to 10 to 20% of an AppSec consultant.
3. The Champion or Deputy Model: The AppSec team deputizes developers to do the bulk of the application security work, and the AppSec team becomes a resource and escalation point for more complex problems. Each DevOps team appoints a security champion, and these champions form a working group supported by an AppSec person. The champions handle day-to-day issues and threat modeling, with the AppSec team providing mentorship and support.

Over several years, Farshad's journey progressed from the expert-led model to a fully-deputized, champion-driven approach to AppSec. 

After careful consideration, we conclude that the fully deputized model is the only path to scalability.

FOLLOW OUR SOCIAL MEDIA:

➜Twitter: @AppSecPodcast
➜LinkedIn: The Application Security Podcast
➜YouTube: https://www.youtube.com/@ApplicationSecurityPodcast

Thanks for Listening!

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Transcript

Chris Romeo: 0:00

This episode is different than our typical interview approach to application security. I've been creating the Threat Modeling Podcast using a narrative, storytelling technique, and this episode is the result of a piece of a conversation that didn't precisely fit with threat modeling, but was too good not to publish. In discussing developer or software focused threat modeling with Farshad Abazi, he described three models for deploying application security teams: expert led, federated, and champion deputy. Enjoy an excerpt from our conversation where Farshad describes each model deeply.

Pillar Ad: 0:41

Coding more securely from the start saves your organization time and money while protecting your and your customer's data. Security journey provides hands-on secure coding training in an application sandbox that allows developers to identify, break and fix common security vulnerabilities. Give your developers the opportunity to recognize and prevent common and emerging security issues before they become a problem. Visit security journey.com to try our training today.

Chris Romeo: 1:20

If you can just, tell me your name and then just gimme a bio, kind of walk me through your, history.

Farshad Abasi: 1:26

Hey, Farshad Abasi, hailing from Vancouver, British Columbia up here in Canada. Um, I started as a software engineer. Um, you know, went, did the ComSci thing, went built software, started building, you know, web applications back in the.com era. You know, it was literally full stack. I ended up working for Motorola where it's just like you're writing, you're truly just an engineer writing a piece of code. And then, you know, went to, did a startup in the dot-com era. We had our own company building, what today would've been Netflix, um, you know, learned about distributive systems. In fact, that was my first foray into threat modeling. We're like, Hey, we're we should get someone to do a security audit. You know, I've never, this was a new thing to me. So we hired these guys from, from the states. And they, they did design reviews and threat modeling. So that was my first introduction to that type of a thing. And it was kind of neat as a developer. I sat on the, you know, we had a bunch of workshops with them. They asked us questions. I was completely like oblivious to what was going on. Funny enough, 20 years later, that's what I do now. I go to developers, Hey, show me your design document. Show me the architecture list, thra model this together. I find the attack pathways. Now it all starting to make sense. So when I think back, I think of the developers that are in my shoes. The startup didn't work, you know, dotcom blew up and, you know, I ended up, uh, going back to the corporate, worked at Intel for a while, wrote. Drivers there, again, as a software engineer, worked on a bunch of security related things. So again, learn, learned a lot about looking things at from a security perspective and building security into products. And then, you know, fast forward to 2008. So buddies having lunch with me said, Hey, you're a developer, but you know, you know security. And at that point I'd been teaching network security at local college, you know, just on the side. And he said, have you ever considered come and work for HSBC? They were pretty forward thinking that they decided that software security was really important and they would create an AppSec team within the software development organization, although they already had risk, they already had IT security that this team would be special. This team would work directly with developers and help integrate security at all the different stages of security development lifecycle. Um, applied for the job, got the job and you know, it was one of the original people that formed that team. So we ended up forming a global AppSec team. And, you know, the program was fantastic. It was really ahead of his time.

Chris Romeo: 3:28

When approaching application security in a large organization, there are multiple models that we see organizations use. The first one is the dedicated AppSec person model.

Farshad Abasi: 3:40

They had too many projects and they were trying to assign an AppSec person to work with each of these teams. And at the time, these were waterfall teams, right? So we said, decided let's take the flag teams that are building flagship applications and let's work with their developers. And one of my first tasks was that hey, you know, divide and conquer. Each of you, there's like, you know, 20 teams. So we ended up trying to figure out what is the best way, uh, to, to have developers do that threat modeling, right? So they signed each of us to a number of dev teams and they're like, Hey, Go and work with them closely do it so that they learn. But you know, of course they don't wanna learn. They're like, oh, you're here. You do it for us. You're the security guy. Right? So it was this challenge of like, how do you, some teams I saw after about a year, I saw that that change, they were like, they were coming to me, they were identifying the issues. They were able to actually look at it from that perspective. Um, you know, and then of course the world changed from waterfall to Agile that it was like, oh, now we have a new challenge. Because before thread modeling was a bit easier. You would get the full design finished and you had the whole architecture document complete, and you could thread model that. But then when we went to Agile, they're like, oh, now you're getting bits and pieces of the information you have to do, you know, threat modeling for agile teams. So then they, you know, they took me and a couple of people that said, Hey, Faria, you go figure this out. Like you, you know, we don't know how to do this. No one's done this yet. So we were all security professionals. The, the developers had no idea how to do so. Initially we were doing it for them. So the how it worked is that, Engagement management. We would receive a new project. They're like, Hey, here's a new team building this project. They don't know anything. They're building it. We would do the threat modeling. We would come up with the threat scenarios. We would give it to them. As we went into that agile and DevOps world, then they wanted us to attend their standups and be a part of the team. So then they were like, okay, you know what? Before you were just, you know, you were part of the develop the waterfall model, it was a bit better. Like you weren't an outsider. At least you're part of the developments team. But you come in at a certain phase, you do the work, you are, you produce the output. But then that doesn't scale because you know, we have so many projects and you know, we can't be, like, the conclusion we came to was like, we can't be doing that for every project. Plus it's not very agile. So as they went into Agile, it was like, well, what do we do there? You know, at first they were like, well, You know, you guys gotta cover every team. We're like, well, there's hundreds of teams. We, you know, I have a small amount of security professionals, so what do we do?

Chris Romeo: 5:44

A second approach to AppSec in larger organizations is to rate all the applications and then focus on the ones with the highest security criticality. Sometimes called the federated model. AppSec team members work on the highest priority applications and lower tier applications. Run through an automated pipeline without any personal attention.

Farshad Abasi: 6:05

We can tier our applications into like tier one, two, and three. So the really important ones, that's the ones we assigned the AppSec consultants. For the ones that are like not so important, we just scan them. We don't do much for those. And for the middle ones, we decide based on a case by case basis. Even then we didn't have enough AppSec consultants, even for the tier ones. We had, you know, I think in total in North America we had about 20 globally. We had a bunch of AppSec people in the low cost centers, but they weren't able to do that design review that, that, that types of AppSec. That requires a higher level of expertise. So then what we did is, We said, we, we said, you know, it's not necessary for, you know, one, one of my team members to go to every standup every morning to go to all the sprint planning sessions and really be a part of the team. Why don't we scale it back instead of a sec? Uh, my security AppSec consultant going in. They'll go in every day. Instead, they'll go once a week. So we would have a security weekly standup, and then instead of going to the sprint planning and being there for four hours, why don't they give us a list of backlogs in that, the user stories in the backlog, and then we can run through, we create created a checklist. So you know, that would determine. Very quickly, if any of those user stories had anything that could be security sensitive or matter from a security perspective. So by using that filter, we would reduce the number of user stories we had to look at. So we reduced the amount of the allocation are required to about 10 to 20% of a of a, of a AppSec consultant. Right? But even that doesn't scale super well. Even if you reduce, you know, at one consultant can handle, let's say, Four, three to five clients at most. Three to five different teams.

Chris Romeo: 7:30

The third model is the champion or deputy model where the AppSec team deputizes developers to do the bulk of the application security work, and the AppSec team becomes a resource and escalation point for more complex problems.

Farshad Abasi: 7:46

We just took each DevOps team, they pointed a security champion, and then we had these working group forums where the champions would come in, um, and then we would assign an AppSec person to run that working group with all the champions to. Disseminate the knowledge to support them so that the champion could be there on the ground, deal with the day-to-day issues, that they come up from the security team and do that threat modeling and be there, and then we, you know, train them. And then we would also set up these weekly sessions where we would work at a mentorship capacity, where they would bring that filtered list of user stories, not all of them. And then we would. Initially we would threat model it, but the expectation that they're gonna learn. And then we would turn the tables around. Usually after three to six months, they'd be like, okay, now we're gonna stop doing it. Now we're gonna watch you do it. And with some of the teams, we would see them doing it really well. You know, they just jump in there, they're identifying the threat scenarios and I would just have a big smile on my face. It's like, this is actually working. Some teams it took longer and they were, you know, more difficult to turn the tables around and get them to have that conversation.

Chris Romeo: 8:40

In Farshad's case, the expert led, federated and deputy approaches were a progression. He started with expert led and progressed to a fully-deputized, champion-driven approach to AppSec over several years. No matter where you are on your application security journey, find the suitable model that works for your organization. My conclusion is the fully deputized model is the only path to scalability.