Talking Application Security Awareness with Derek Fisher

In this episode of the AppSecEngineer Podcast, we have a conversation with application security leader Derek Fisher. He began his career first as an engineer designing circuit boards, and then a software developer. Currently, he serves as the Vice President of Application Security at Envestnet, and is an adjunct professor at Temple University, Philadelphia.

As a big advocate of security awareness, he talks about how it’s important to educate the general public about the importance of security in daily life. He’s undertaken several initiatives to demystify security for all age groups. Fun fact: Derek’s even written a children’s book teaching them how to be secure online! On the enterprise side of things, Derek shares some insight about his experience with ThreatModeling, his contributions to OWASP ASVS, and challenges with implementing DevSecOps in modern tech stacks, particularly on cloud-native applications.

Talking Security Awareness and Threat Modeling with Derek Fisher| AppSecEngineer Podcast

Abhay - All right. So thanks everyone for joining us. I'm very happy to be here. With me is Kishore and I'm, of course, going to introduce our guest a little bit later. So, first of all, my name is Abhay. I head We45. I head technology and most of the technology-related operations at We45. I also handle a lot of the training and head out a lot of our training efforts.

We do training at Black Hat. We do training at OWASP with several other events, probably a lot around Application Security, Container Security, Cloud Security, Kubernetes and so on. With me is Kishore and I'll have him introduce himself... Kishore. 

Kishore - Hey all, my name is Kishore. I work very closely with the Abhay in, you know, pre-training programs, working with universities as well and with many of our clients and conferences as well to put together training programs.

So I primarily head the training operations along with Abhay in We45 and am happy to be here. 

Abhay - Great. Thank you. Thanks Kishore. So now it's, I think, it's the time for us to talk about our guest. Our guest today is Derek Fisher and Derek has been an Application Security leader for some time now. In fact, we've been running into each other often at conferences and stuff, but we're really glad to get a chance to talk to him and hear his thoughts on anything AppSec, InfoSec related.

So I'll allow Derek to introduce himself. Derek all over to you. 

Derek - Sure. Thank you. So my name is Derek Fisher. I have a couple of decades now, I guess I'm aging myself here, but in the hardware and software space and engineering. I started out my career in hardware as a drafter and designer for circuit boards, made the switch over to software.

And then I got interested in security when I was working at Siemens. You may have heard that company, but was working at Siemens as a software developer, was really interested in security. I saw a couple of my peers and, and some individuals that I really admired. They were in the security space and decided to pursue a degree in cybersecurity from Boston University and got into security business.

And it's been a wild ride since, definitely made the right call getting into that. And, and I know a lot of us that are in the security space truly appreciate being in this industry. It's, it's a dynamic industry. There's a lot going on. There's always a lot of things to learn. And you also feel to an extent that you're, you're really providing value to the... to the company and the enterprise that you work in and more importantly to, to people that are using technology.

So, you know, I feel that there's a lot of benefits to the work that we do and that we're really bringing good security principles along with us. So been in the security space for probably, I guess, about eight-nine years now. And I also teach an application security course at Temple University in Philadelphia.

I've been doing that for a couple of years now, looking to expand that actually in the fall to a second course. So a lot of my focus has been not just in the engineering space, but also in the security awareness and, and education space. You know, I feel that part of our role in security is really to be able to provide the means for engineering resources and staff to be able to take a lot of the work out of our hands. There's a lot of, I think, misconception that security is security's job, right? Security should be designated to the people that are in the security team. And in some cases that makes sense. But, especially in the engineering space, we want to try to enable engineers to be able to perform with security in mind.

And one, one of the best ways to do that is through education. So my class, I teach at Temple University, is always full. In fact, there's been multiple times where the request has come in to increase the capacity of the class. So that to me is promising. I think that's good to see that there's a lot of interest in that space.

And one of the first things I tell the students when they come into that course is that having this security background even if you come out of this with only knowing, you know, the OWASP top 10 and understanding Threat Modeling, Risk Assessments, and some of the basics, you're gonna position yourself better as you, as you go out into the world and become an engineer.

Abhay - I think that having these skills is certainly helpful. Absolutely. Now, thanks for that Derek. That was a really good introduction. Glad to see that you are doing a lot of different things, not just, you know, doing your day job. You also have so many other diverse interests, especially teaching and equipping the community.

That's really nice to hear. Now we usually start off these segments with how did I get into security?. And you know, the question: how did I get into security? And that's another thing that we'd like to ask you. What prompted you to get into security? How did you fall in love with it? And you know, where did you decide that this is what you want to be doing for at least a lot of your life? 

Derek - So, yeah, I think it really came down to really seeing where the industry was going and understanding that security was becoming a  bigger factor in engineering in general. So seeing some people that I really admired that were at least, you know, the peers that I was working with that were in that security space and people that I really appreciated their insight into security.

I felt, you know, kind of caught the bug, I guess, and, and felt that it was a good path to go down. There was definitely a lot to learn. You know, security has obviously been around for a long time. It's not, it's not like I suddenly discovered it, you know, and it was like taking off.

It was, you know, security has been around for a long time and I really, those that have been in the industry for a long time, I have a huge appreciation and admiration for but you know, I think it really came down to seeing the writing on the wall that that security was, was definitely something that was becoming extremely hot. I like to kind of be in those types of spaces where I can learn something new and, and be a part of something that's bigger than me. So, I think, it was just a matter of just catching the bug and getting on. And like I said earlier, I think being able to kind of provide that security awareness to others, like, I feel like maybe in the past, security was seen as dark magic. And it was seen as something that you know, that was relegated to people that, you know, had secret languages and things like that. I really view it and this is why I got into the education space as well, is that I really view it as something that we should, we should kind of demystify security and make sure that everyone has that appreciation for it.

Because again, as you see with devices and everyone carrying, you know, a smartphone or having a tablet and when everybody's using technology, it's everyone's responsibility to be more secure. So I feel that I enjoy that part of it, demystifying security and making it easy for regular people.

And in fact, I did actually write a children's book recently and published it, related to security for  children because, I think, you know, as you see technology kind of expanding, you find that that more and more people are using it. And, we want to make sure that those people are using it securely because that makes our jobs easier from a defender perspective.

Abhay - Right. Absolutely. That's great to know that, you know, you've written a book for children because children tend to be an especially vulnerable group, especially at, you know, when COVID- 19 is happening and we have so many different phishing scams all over the place and, of course, children are all at home.

They're on their iPads and mobile devices all the time. This is a perfect opportunity for people to target them and, you know, leverage them in whatever, you know, nefarious things that they want to do. So I really appreciate the fact that you are taking a lot of your time to do these things.

That's really cool. So one of the things that struck me, when we were looking at your profile for this show was the amount of work that you seem to have put in the secure software development side of things. And. I'll kinda continue that question a little bit. You - correct me if I'm wrong - started off as a developer.

And now you've, of course, moved into security. So what is your take on a Secure Software Development? How have you seen this evolve over time? Because, obviously, you've seen this evolve, different companies are doing different things. You were in Siemens. You're now in a, in a completely different

organization that's doing something completely different. How do you see this has evolved and where do you see this going in terms of your crystal ball gazing, so to speak, right? Where do you see this going? 

Derek - Yeah, so, you know, it's funny. I've worked in the healthcare space; the financial industry, back in my hardware days, I worked in military contractors.

So I've seen, seen a lot of different ways that systems and software get developed. And I think, you know, I've really grown to appreciate the process and I know that sounds silly because a lot of people hate process, but I kind of really appreciate the, you know, the process of making what we would say, making the sausage, you know, when it comes down to making software.

And I think a lot of different, you know, industries and even within the same company, you see teams doing things completely different. And I think that's been, you know, some of the challenges not just from a security point of view but from an enterprise-development perspective is that teams that are sitting even on the same floor with each other in an enterprise are developing their software completely differently. And it could be because the language that they're developing is different. Their tech stack is different. But it's always, you know, there's always some difference there. So one of the biggest challenges that I see kind of going forward, especially with security, is that, how do we, how do we bake security into that development life cycle?

And, you know, you're seeing even things like, when I first got into security, you know, eight- nine years ago, Static Analysis was taken off. That was the hot thing. Right. You know, that you had to get whether it was a HP fortify or IBM AppScan or what are the, you know, the other types of Static Analysis Tools that were out there, it was about plugging them into the development life cycle.

Well now there's not many people using fortify. You know, a lot of it is because the way that we develop software has changed in just such a short period of time to the fact that the tools that worked, you know, seven-eight years ago don't necessarily work in the same,development life cycle.

And a lot of that comes down to the way. You know, the introduction of DevOps. I think that's made some significant challenges in terms of plugging in security tools into the development life cycle. So as I kind of see things going forward and I know this term gets overused a lot but with the, with not being able to rely on tools as much, I think we really do need to look at, you know, shifting left. So how do we build requirements early on? How do we identify threats and risks early on so that we can develop that into the development life cycle? And have less reliance on the tools in the backend.

There's always going to be, you know, the need for, for those tools down throughout the development life cycle but as you, you know, build that capability and understanding of security issues early on, you have less reliance on things like Static Analysis. 

Kishore - Absolutely. So Derek, you talked about how things have changed. I mean, how tools were used in the past and how, you know, how they are being used today. In the sense, they still have a role to play but you know, they're maybe not as important as they were before or you know, they serve a specific function.

Now, coming from that transition of how security has changed and today as you're focusing more on secure software, how has your work in Threat Modeling figured, in the sense that, you know, me and Abhay, we've seen that, Threat modeling, in many places continues to be an approach which is, you know, Abhay likes to use  this a lot, it's like boil the ocean, kind of  thing. Everything has to be Threat Modeled at one single point in time. And, you create a large Threat Model, which is very difficult to understand in the current DevOps development process. So how have you seen that change over the years? Because Threat Modeling used to be a very, very once done is done, and then, you know, people forget about it. But today with, you know, secure software, how does that play a role in what you have been doing in the last few years? 

Derek - Yeah. So the answer may surprise you, but I've actually not seen many organizations do Threat Modeling well, and I think there's a couple of reasons for that. One is that, to your point,Threat Models become large, unwieldy, very difficult to meet, you know, manage and maintain. And it's a once and done thing. Maybe you, you know, have this little checkbox where you say we're going to review it, you know, every year. So it does kind of become a bit of a, you know, a checkbox exercise with Threat Modeling.

And then you see some organizations they just don't have a formal process around how they perform Threat Models. Not that they're not doing it. They understand the risks, they understand the threats. They are doing it more at a, I'll say, like an Ad hoc type of method where it's like, okay, we know that this is our risk. We're concerned about, you know, credentials being stolen by our admin. So how do we lock that down? You know, how do we get privileged access management controls around that? So, you don't see that more formal Threat Modeling process as often as I think, you know, we would like to see but, as you know, ways of trying to get Threat Modeling baked in, I think it really comes down to making that part of the early on process so that it becomes a tool to develop use cases, requirements and, ways to validate, your controls are working.  So I think pulling that again, shifting left, pulling that as early in the process is possible and not viewing it as like a security tool,I mean, although it is not looking at it as a security tool, but looking at it more as how do we get those requirements and use cases out of the Threat Modeling tool or the Threat Modeling process so that we're building security in. 

Abhay - Right. Absolutely. That was you mentioned a couple of interesting points that I would like to circle back to.

So first of all, when you were talking about Threat modeling, one of the things you said was use cases. And one of the things we have started to see, especially at We45 and we've built a tool around this as well, which is open source, where is to use Use cases and stories or user stories to start your Threat Modeling process rather than have a system-wide sort of Threat Model.

This is something that we've seen accelerating the Threat Model and staying as part of the Agile cycle. You also said something about most organizations not doing Threat Modeling well, which I absolutely agree with. What is your definition of Threat Modeling done well? What would you do? Wishlist. 

Derek - So... well, that's a good one.

You know, the way I see it being done well is number one, there has to be the upfront collection of data. So things like system diagrams, data flow diagrams that are good architecture processes to begin with. So,you know, again, set aside the security aspects of that, especially when we get into this, you know, this DevOps, you know, mentality or, you know, and I not using the term DevOps, but this develop code quickly, you know, mentality that we have right now.

Yeah. I think things like the mundane things that, that, you know, and I was, I was, a developer and so, you know, creating..creating documentation was always a drag, right. You wanted to get in, you wanted to write code, you don't want to create documentation. So, but I think having that upfront stuff, you know, should be a priority for Engineering teams.

So having data flow diagrams, having architecture diagrams, having a system description, like how, how you should tech stack the pooling where your accounts, where's your data? How's it classified? So all those components need to be developed by the, you know, the Product team or the Development team. Once that's created, that makes your, makes creating that Threat Model easier,

right. Because you have a lot of upfront documentation. You have things, references that you can leverage in order to create a Threat Model that makes sense. But, you know, there's, there's not a single answer for, for, I think doing it well. I think, although maybe there is. The best Threat Modeling process or best Threat  Modeling structure is the one that gets used.

All right. That's the bottom line. If you're not using it, it's not effective. Right. So, whether you're using a tool, whether you're using a manual process for creating Threat Models, it really has to fit the Engineering team. It has to fit the organization, the enterprise and as long as that upfront information is there, it makes it a little bit easier to create that with perhaps pulling in the security SMEs within the team or from an Application security team, having the product owners, the Development SMEs get together, make sure that everyone agrees on that Threat Model that it's accurate and being able to tease out all the risks and threats out of that and then acting upon those. So, you know, it's not a one size fits all. I think it really depends on the size of your organization, the type of organization that you're in and, and culturally, you know, will it work. So...

I know that's a little bit of a roundabout answer there but it's one of those, I hate to say, it's like one of those, it depends on types of. 

Abhay - Yeah, of course. Yeah. I know. Obviously, one size definitely does not fit all and it's usually a recipe for disaster. It's definitely something that you should look at case by case, but if you were to kind of not strategically but more tactically define what you should do Threat Modeling wise, in the sense that how should we, one of the challenges, let me tell you where I'm coming from. One of the challenges that I've always seen with Threat Models is that the Security team is the only one doing the Threat Model and that's becoming a huge bottleneck.

Right. And that's, that's to your point about it being used, it's never going to be used unless there is skin in the game. Right. So how would you in your years of experience, how would you potentially bring that skin in the game? In the sense, how will you make it easy for developers or architects or

business stakeholders too, you know, include themselves or you include them as part of a Threat  Model and what would you do and what we do not do? 

Derek - Yeah. So, you know, it really comes down to the Engineering team or the Product team owning that Threat Model and making it part of their standard process for, you know, and the Security team needs to be involved in that and maybe it's the Application security team or maybe depending on the risk of that application, you know, risk in the sense risk to the organization.

Like, if it's a high-risk product or application that's being developed, then you probably want to bring in the full weight of the security, you know, the Application security team to, to at least assist with that, with that Threat Model, but there really needs to be a co-ownership in terms of the Engineering team needs to own that product. You know, the Threat Model itself whether you do it in a tool and you know they need to own that, you know, that output or own, you know, the diagram of it. But there needs to be, you know, the Security team also needs to be able to know that they need to be engaged and maybe that's a periodic thing. So they know that every six months or every three months or whatever that is or every major release that the Application security team comes in and says, hey, you know, we know you got your tooling all set up. We know where your vulnerabilities are because we've been engaged all the time.

By the way, have you updated your, your Threat Model and if not, let's sit down and go through it. So I think it, you know, and in the sense of, you know, how you develop Threat Models, whether you're using a tool, which I tend to think that if you're using a tool like Microsoft Threat Model or I think it's called AppSec Threat Modeler. If you're using a tool like that to do Threat Models, a lot of times, you know, the Engineering team can go off and do that on their own.

If you're, if you're going down more than manual process, where you're in a room, you got a whiteboard, you have the SMEs there and everyone's, you know, on this everyone's agreed that we're gonna, you know, do this, you know, do this thing. Then, you know, it's easier to pull people together and get everybody kind of on the same page and engage there.

So, there's you know, it really, I've been kind of blessed with at least the company I worked for right now, where we like the Application security team is embedded with every engineering, the vast majority of engineering functions, that's the model. It does not only scale and that model always works everywhere.

So, you know, I've been kind of lucky with the sense that we're able to engage with the Engineering team on a regular basis to make sure that, you know, again, the tool is working, that they're getting the value out of the tools. We're, you know, making sure that they were keeping track of vulnerabilities and, and making sure they're being tracked at, you know, closer to completion.

And, so building a Threat Modeling process into that is a little bit easier because we're already engaged with the Engineering teams. 

Abhay - Right. Absolutely. Cool. So coming back to security awareness. Now, one of your big areas of focus has been awareness, you know, obviously with your experience in academia, as well as your, you know, personal efforts as well, what do you think about now, obviously, security awareness is different for different groups of people. Now, when you are looking at Engineering teams, especially Engineering teams going at the speed of light, so to speak. What is your take on security awareness? How would you look at security awareness for these engineering DevOps, Ops,

SRE teams? How would you approach that and what would your take on that be? So, one of the things that that I'm currently looking at is, is, you know, how do we, how do we get the basics? Right. So there's the one-on-one type training. So there's, you know, an introduction to OWASP top 10.

As I mentioned, you know, teaching at Temple University, the class is always full, and you know, there's, there's always some people still trying to get into class. So getting those bases, you know, I feel that's a good indication that people are wanting to get that knowledge.

But I don't know necessarily that were, I know that when I went through my computer science degree that there wasn't, we didn't take a security class. You didn't learn that until, you know, later on when you were actually out in the field. So I, I think, you know, getting that base layer, you know, I'll call it the base layer of application security or secure engineering built in, which is, you know, around OWASP and around, secure development techniques and all that.

And then, you know, I see it as, you know, there's a step-up type of curriculum where maybe there's more advanced tech things that your developers, your developers don't need to necessarily take things like Threat Modeling, maybe risk assessments that kind of stuff, you know, is more geared towards like the architects, maybe even product owners to an extent.

But, you know, you want to have basically an add-on to that base layer. And then, I think above that you want to have more targeted, focused types of education or awareness where things like Container Security, API security, you know, DevSecOps, like where you have more focused types of awareness training around security principles that are targeted again more towards those people that are in that specific channel.

Because the one thing, you know, you don't want to do is and, you know, for most of us, we know this that, you know, education is not a one size fits all either, right? You know, I think understanding secure engineering principles in terms of OWASP is great, everybody should know that, you know, whether you use it or not, everyone should know that, but as you get into that, you know, things like Threat Modeling, Risk assessments, API security, Container security, you know, that kind of stuff is more targeted towards people that are actually, you know, in that space and need to know that. So I do, I like the kind of model where, you know, you're able to basically build  skills based on where you're at in terms of your organization. 

Abhay - Right. So, yeah, I mean, totally I think that makes a lot of sense because one of the things that we see, so, and we do a lot of training on DevSecOps and Containers and stuff like that, most of these classes we're seeing that the lines have blurred quite a bit between the people who supposedly need to take them and the people who are actually taking them because everyone is now kind of in this, right. So if you're a Pentester and you don't understand Kubernetes or you don't understand cloud or something like that, you are kind of lost.

And so the audience that is suddenly expanding, we're seeing that with our classes, whether it be at a conference like Black Hat or even our own live online classes, we're seeing that there is a whole lot of different sets of people from management right down to, you know, folks who are doing the stuff on the ground, we're seeing that, you know, take off quite a bit. 

Derek - You know, I think that you know, as you were talking, I was thinking that, you know, one of the biggest challenges that we've had in many of the organizations that I've seen and worked in is that, you know, finding out who should take those courses.

Right. You know,  you can say the base layer that one-on one course, you know, it needs to be assigned to all Engineering staff  that you can probably work out. It depends on your organization, you probably know that, but yeah, to your point, you know, figuring out like, you know, does, you know, "Does John down the hall need to take the cloud security course when he doesn't you know, quote-unquote work in, you know, in cloud but maybe because he has other, you know, other tests or work that, that kind of bleed over into that. And I think that's, you know, that's a valid point. 

Abhay - Yeah, absolutely. I think.. I think that's, yeah, the, the, the kind of, especially now with the landscape expanding so much, and people jumping into technology a lot of times without understanding what the implications of those technologies are.

Like, I see this a lot with Cloud and Kubernetes, especially that people just want that shiny new thing and they just have it implemented in their project without understanding the massive security downside that they've not really thought about. So that's something, you know, which scares you as well because these are the things that constantly happen and, you know, people, not able to cope with that for a lot of times.

Derek - Right. 

Abhay - The other thing that was interesting to me that you have spoken quite extensively about, ASVS and ASVS relates largely... so for those of you listening, OWASP ASVS is a very interesting open source project called the Application Security Verification Standard. Now, the ASVS is currently at V4 and it is of course evolving all the time.

It's largely a set of very detailed controls on different domains, authentication, authorization, cryptography. Now, Derek, of course, has presented on ASVS at least four or five times based on the talks that I've seen. At least some of the references I've seen outside. What is your take on things like ASVS, especially because these kinds of templatized, standardized things make sense to some but completely don't make sense to others.

So where, where do you stand on this sort of initiative? 

Derek - Yeah. And, and you're, you're bringing back. It's been a while since I talk about ASVS, although I do talk about it in my class, in Temple. But... but yeah, it's bringing back some, some horrible memories, but a lot of the talks I gave around ASVS was really how ASVS can be used in, in, and in an organization. So to your point, it's, you know, at it's simple, as parts as a check, it's a checkbox exercise. I think, you know, looking at something like the SKF, the Security Knowledge Framework, that is done with OWASP, yeah, there's, there's, they've built in ASVS into the SKF so that, I know there's a lot of acronyms there, but where it's made things a lot easier for Development teams to be able to to understand what their coding risks are in the context of the ASVS. So just to step back and kind of go talk about the ASVS a little more specifically, you know, it has multiple domains and each one of those domains has what they call requirements.

So, you know, there's an architecture domain, there's an encryption domain and things like that, and in each one of those domains, there's  these requirements that say verify. And that's why we always get kind of stuck on the term requirements because anytime a statement starts with the word verify, that's a testing, you know, that's a testing statement, not a requirement.

So the ASVS is a way to be used by somebody like a Penetration tester or QA, and that's one of the things that we were actually looking at was, can we leverage the ASVS to allow quality assurance or you know, testers to be able to use this checklist to do security testing for us so that we're not, you know, and again, it's that whole model of Defense in depth.

So we're not relying just on the Penetration testers in our, in our, testing tools to work, but we can provide this list, you know, to our QA or testers and say, hey, can you, can you discover, you know, these issues exist and that's a little tricky because obviously your testers are not, you know, security people, but so, you know, the bottom line was that when we first looked at the ASVS, you know, as I mentioned, the first thing you see is it says verified, which means it's not, you know, it's not a requirement.

So we actually took all the ASVS statements and turned them into actual requirements and then pushed them on to Development teams. And we were looking at ways to make that into a, a more approachable method where we had a web application that you can go in and select the functions or the features that you're implementing within your product and on that, it would spit out the requirements that apply to you.

So that's one of the things, you know, about the ASVS. I forget it, maybe it's 180, you know, statements that are in there. You don't need to take all of them if you're not using, you know, some of those features that are impacted by those, by those statements. So the reason I bring all that up is that the SKF, the Security Knowledge Framework has done a lot of that work.

So the new iteration of the SKF has done a lot of that, where, you know, you go in and create a project and you say, you know, here are the things that  are the features that I'm including in this project that I have that I'm working on. And so it'll, it'll provide you the requirements that you need to be concerned about.

And additionally, once you, you know, it's going to tell you like, okay, you're using a database and I'm being general here, but you're using a database be aware of SQL injection. And then, when you're completed with that, it's going to give you a checklist that you can then say, hey, verify that there's no, that you're scrubbing your inputs and there's no SQL injection possible there.

So I think the ASVS, there's a lot of benefits to that, especially when used in the context of something like the Security Knowledge Framework. But what I really, really liked about it was that you have the ability, so we don't want to write, you know, as the Application security team or as a developer, you know, developer or product owner, you don't want to have to go out and write security requirements. The nice thing about this was that they were there. You could just take them off, for the most part you could take them off the shelf, maybe modify them a little bit, but you don't have to create that framework of security requirements. They're, they're mostly already built for you.

You know, you can use them and push them onto the Development teams and like any good framework, there's some customization that needs to happen in order to get it to fit within your own organization and the way your organization works. But it's a great starting point. 

Abhay - All right. 

Kishore - Yeah, continuing to that question or what you talked about ASVS while you were, while you were talking about customization and how it can, you know, apply to different teams, you know, how you can adapt the framework to your requirements, one of the things that we have been, I specifically have been discussing with certain people is that, you know, and this is the reason why I'm asking this question, because you have in the recent past,or even now working in industries which are very heavily regulated, right. So you're either in finance or healthcare, both are heavily regulated.

Now, we understand that ASVS as an application security standard is very good because it talks about things which can be implemented. It's very practically implementable from a development standpoint as compared to others, you know, general compliances and regulations that, you know, your industries have.

But when you're looking at large teams. When you are looking at a large product team put together in a large organization, everyone has a different way of doing things in a different way of implementing the product. So what has been your experience in implementing this and customizing this?  You know because

You know, in a very recent conversation, somebody was saying that, you know, I have a lot of different teams, some people are very mature in security, so they'll be able to take it a breeze. And some people, we don't know what they're doing. So, therefore, how do I customize the framework or build it in such a way that, you know, I have a standard set of rules but you know, it is something that everyone can take up and, you know, start, you know, implementing as part of their project. So how have you overcome the challenges, especially in the regulated industries?

Derek - Yeah. You know, there was a lot of effort put into mapping the ASVS to other regulatory, you know, frameworks and, you know, like the Cybersecurity Framework for NIST and for other, you know, types of regulations and such. But you know, it really comes down to because the other challenge that we ran into was that a lot of the requirements weren't new.

Right. It wasn't, you know, a requirement that said that, you know, and I'm, again, speaking generally here, but, you know, again speaking generally here but “thou shalt encrypt sensitive data in the database.” Well, okay. Most, you know, most matured organizations, most matured Development teams are already doing that. Right. So there was a bit of, you know, going through and making sure that the requirements that were actually being pushed on to Development teams weren't ones that were already being, already being completed.

One of the ways, you know, and it, it, it's not, it's not going to be a great answer, but you know, the way that we found that to work is that there was just analysis that needed to be done when these, when these requirements landed onto the requirements tracker for Engineering team.

There was just some analysis that needed to be done to just say, are you doing this? Yes or no? And if you are, you know, then you can close this, this requirement, it could be completed but we at least had the traceability that said, hey, you know, and we tried, as I mentioned, we tried to filter down what actually was applicable.

So we didn't just give the ASVS over to an Engineering team and just say, here, go do all these requirements. You know, we tried to tailor it down to what's actually applicable to that team. And, then once they got their list, which could be, you know, it's going to be a subset. So it might be a third or  you know, a quarter of what the actual ASVS said.

Then, they're able to then go in there and say, look, we're already doing these handfuls. Great, fine. Market is, you know, market has complete provide evidence that it's completed within that, you know, requirements tracking tool. And whether you're using something like a JIRA or, you know, a different type of requirements tool, we just, we just asked that the evidence was applied there, just close it and you're done.

So, you know, it's, not a great solution but it was, but at least worked for, for the use cases that we had. 

Abhay - Right. Absolutely. Now that's useful to know that, I mean, there are ASVS, a lot of times I counted as, you know, the panacea that can fit all, but I see that obviously, especially with different types of teams, it might be a little bit of customization, a little bit of making sure that it is more easily palatable, I suppose, in terms of its consumption.So definitely that's, that's a valid point.

Derek - And, it's like any other framework. It's, you know, it's going to be, right because you can't, you know, if it's targeted, if it's too targeted, it's not going to work. If, you know, if it's broad, then it's on you to narrow it down. 

Abhay - Right. It's like, yeah absolutely. So I mean, I think we're almost out of time but I just thought we'll address one more question before we close. So one of the things that especially is happening today, probably you've seen it and experienced it to a certain extent as well is that we're starting to see this entirely cloud native view of the world, right where a lot of these products and even companies are born in the cloud. They're not even, there is no concept of, you know, a data center or, you know, them hosting their own services. They're already born in Amazon or Azure or Google cloud and they continue on that. They scale out on that. We're seeing a lot of zero trust discussed

and in some cases mildly implemented as well. And, of course, we're seeing a host of new technologies in the Identity Access Management space as well as, of course, you know, at cloud scale, at massive scale. So where do you think... Where do you think application security as we know it is going to go, I mean, how do you think it's going to evolve and what are your predictions?

You know, of course, in 2020, I realized that we're not in the best shape for making predictions, but at least around something like this where do you think we're going and where do you think you're likely to see things in the next three to five years from now? 

Derek - So I think one of the biggest challenges that, you know, that application security has, has always had is, is number one, keeping up with the technology, you know, number two, keeping up with the Engineering teams and making sure that our tools are effective. So, you know, I don't see a lot changing in the sense, you know, of whether a Development team is going cloud native or whether, you know, they're on a DevOps pipeline or they're going, you know, old school, but, you know, I think it just, it's a matter of stepping back from an application security perspective and saying what's important to us.

You know, for us, it's a matter of making sure that we're not, you know, allowing vulnerabilities to get out in production. That's our, that's our, you know, that's our stated goal from an application security perspective. So how do we do that in a way that may have less reliance on specific tools?

And it does come down to, again, I know this has always, you know, rainbow, rainbows and unicorns here, but you know, how do we get closer to the left and how do we get embedded early on into the process so that we're, we're baking in those security requirements upfront, and we have less reliance on those tools at the end, but I do think, you know, especially as we talk about cloud and as, as teams move to cloud native, I'm a big proponent of the Application security teams knowing what security tooling is available, cloud native as well.

So we don't want to, you know, I think one of the biggest problems and, and just, you know, stepping back and talking about just cloud in general, one of the biggest problems that I think a lot of enterprises realized early on  was that picking up your data center and moving into the cloud wasn't cost-effective, right. It's not the, it's not the, you know, you're not going to save a ton of money by doing that. It's really when you're leveraging the tools natively is where you're going to see the savings not just from a cost perspective, but also from, you know, from maintenance and, and you know, operational perspective as well.

So I think, you know, likewise the Application security team needs to continue to look at those cloud native tools that are, that are available that will still provide us some coverage from a, from a security perspective, but it really comes down to baking it in early on. So things like security awareness, risk assessments, threat models, security requirements.

Again, they're not, they're not the fun thing. They're not, they're not going to get you a booth at a RSA. But they're, you know, they're the things that honestly make it, make our jobs a lot easier. 

Abhay - Yeah, the boring things are the ones that actually last, you know, while you know it's funny. 

Derek - I complain about this every time I go to a conference and walk the floor, always saying, hey, where's all the AppSec stuff. And it's like, it's like, Oh! they're in the back, you know, where the, where the coffee is being dumped, you know, it's like, [Laughter] you know, [Laughter] I'm sorry that is a joke. I mean, there are some tools out there that obviously play in the AppSec space, but they're not. It's not the firewall tech and, you know, where the less fun part of security.

Abhay - So, yeah. [Laughter] we are getting there. We have lots of exploits coming our way, so we are always keeping ourselves on our toes. But yeah. But yeah, I mean before we close Derek, is there something that you'd like to say? I do realize that your book is available on Amazon or something like that? What's the name? 

Derek - Yeah, so I am planning on writing a series on it. So this is the first book. But it's called Alicia Connected. That's the name of the series and it can be found on Amazon, both in Kindle version and on paperback. So feel free to look it up. You can also find me on LinkedIn, get more information on me and, and the book. I'm actually running a blog for the book as well where I'm releasing a kind of that security-awareness type of information to, again, the general public.

So it's, it's not security what we'll call security wonk type stuff. It's more just general security awareness for parents and for children. 

Abhay - Yeah. So this is the link for Derek's book. I just found it on Amazon. So if you want to check it out and get your child some security awareness, maybe this is the book to look at.

And, of course, we'll also post Derek's blog information as well on the show notes once we release this episode. But yeah, I mean it's been a great time talking to you Derek. We really enjoyed ourselves and I think all our viewers and listeners will find this to be a worthwhile of their time. So thank you very much for taking the time. 

Derek - Appreciate the time. And this was, this was great. It's, it's always good to kind of talk, you know, application security, because again, like I said, we're not the fun part of security, but it's, you know, I think it's obviously, I think, it's important because that's why I'm doing it.

Abhay - So, absolutely. Thanks so much. 

Derek - Thank you.