How to Win over that Elusive Developer with Adhiran Thirmal

Welcome to the Test Guild Security Podcast where we all get together to learn more about security testing with your host, Joe Calantonio.

Hey, it's Joe. And welcome to another episode of the Test Guild Security Podcast. Today we'll be talking with Adaran Dermal, all about how to win over the elusive developer to get buy in for security and much more. We'll probably also touch on SAM v2. Adaran is a security solution architect for Micro Focus, focusing on the Fortify and Web Inspect product suites that cover static application security testing and dynamic application security testing. Previously, Adiran has worked at application security professionals like Telus and SAP, helping build out the application security programs at those organizations and learned how to really win over numerous elusive developers. And because he works for an actual vendor that works with security, he has a lot of inside knowledge on that as well. So really excited to have him on the show. You don't want to miss it. Check it out.

It's no secret that the number and complexity of applications are growing, but what is alarming is that 90% of security incidents result from exploits against defects in software. The need for better application security has never been higher and Micro Focus Fortify is here to help. Fordify is the recognized market leader in application security and it is the most comprehensive and scalable application security solution that works with your current development tools and processes. With Fortify, you can start security applications in a single day, including custom code, open source or commercial components and scale as your needs grow with an on premise as a service or hybrid implementation. Check them out. Head on over to micro focus.com Apple Security.

Hey Adrian, welcome to the Guild.

Hey Joe, Lovely to see you here today.

Awesome. Great to have you. So this session is actually based on. Well, this interview is going to be based on a session you did for the previous Security Guild, but it was so good that I had to share with more people and also want to get your opinions on different things that are happening in security already off topic. I'm just thinking off the top of my head. Coronavirus. You're the first person in security for me to talk to a coronavirus.

From a security perspective. Have you been seeing this as a way to actually get people to compromise security through people trying to socially engineer folks thinking that they're getting a legitimate alert on the Coronavirus and then exposing themselves to a particular hack or exploit?

Yeah, no, it's actually a little bit terrible. Unfortunately with a lot of huge crisis, especially crisis that invokes a lot of anxiety and fear within individuals across the world and especially here In North America, I think it's prime time for attackers to jump up and exploit. One of the big attacks that I've actually seen more recently is a phishing campaign. So there's been a lot of maps and a lot of alerts and different mechanisms for individuals to receive information about the coronavirus. And unfortunately a lot of those have been just phishing campaigns and a way to gain legitimate email addresses, legitimate phone numbers, legitimate addresses for mailing purposes. And unfortunately the Kirks are at it again.

Absolutely. So I guess that's good and bad with the episodes like this one is, I guess it can help raise awareness to security, especially starting conversations with your developers. So one thing you went over at the last secure guild is ways you could talk to your developers to actually get buy in to hopefully avoid particular exploits, especially in times like these. And you went over some conflict resolution styles, I thought we'd go over really quick. I don't know if you remember those conflict styles, but you know, there was avoiding, combinating, competing, compromising, collaborating. And so I thought maybe we could talk about each one and then how it relates to security. So the first one was avoiding for sure.

So with avoiding, ultimately this is kind of that classic do nothing approach. So this is a lot of times actually really synonymous with the coronavirus. You'll see some folks kind of sitting in a corner and just literally kind of curled up in a ball hoping for it all to just end. And it's actually perfectly synonymous with that. A lot of organizations unfortunately run their security program this way as well, where they just do not really start off anything when it comes in towards security itself within their application development. They just hope that it'll happen. But realistically this is kind of a lose lose situation. The developers are typically lost because they don't really know what a security team is trying to expect out of them. And there's just a lot of, you know, miscommunication and ultimately this just results in pure chaos.

Now with coronavirus or things of this nature, because it's like something that's out of the hands of even someone even thinking of would happen when you're planning security. So people aren't avoiding it. Is this part of your plan, how to avoid for unknowns or is that based on risk?

Yeah, no, for sure. And ultimately there are lots of unknowns when it comes in towards the medium of communication. And so in terms of the medium of communication, that is always going to change. Right. And so I think that's what's going, going to transpire through the coronavirus you're going to see a lot of organizations start to invoke work from home policies. We're already seeing that across kind of the western seaboard here. And ultimately that medium of communication, although it's changing, it still doesn't necessarily force an organization to, you know, jump in towards one of these conflict resolution methodologies. It might kind of invoke them to potentially change what they have going currently and towards another. And ultimately that medium, communication, as that changes, you know, with an organization, that's avoiding typically, you know, as especially with organizations that have a much more of an in person, in office type of a culture, as people kind of start disappearing, if there isn't a mechanism to introduce a new communication medium, maybe it might be, you know, a collaboration tool just like Zoom here or like WebEx or Teams or whatever it might be. But ultimately, as long as an organization has a bit of contingency planning, as people start working from home, then you can kind of get around it. The risk is always there. That's kind of the realistic piece of it is just a matter of whether or not you as an organization actually recognize that risk and are doing something to address it.

Cool. So how does accommodating then, what's that conflict style like?

Yes, accommodating is more of a style where ultimately it's a bit of a lose wind. So you feel as though you want to give up something so that the other individual would win. And so in the case of application security, the way that this kind of transpires is security programs ultimately do have a let developers do whatever they feel like. And the way that this is kind of different from avoiding is that within accommodating you're ultimately, you have a little bit of a plan, but your plan is to ultimately put everything in towards the developer's hands. And so it's interesting because, you know, we obviously do want to win over that elusive developer and we want to get some of their buy in, but they need some guidance. Right. So we need some forms of measures to be able to identify whether or not they are progressing, to be able to reduce risks from a security perspective. And so you do want to have developer buy in, but ultimately with accommodating you ultimately allow developers to just do whatever they kind of feel like. So, you know, if there are a number of risks, you might just kind of throw those risks out there and then and you just hope for the best. But again with this, it's much more of a lose win type of a scenario. So potentially the way that this really kind of surfaces is through attacks and you know, a lot of accommodating type security programs usually find themselves on the front page of a newspaper. And at that point they kind of organizations will actually realize hey, like you know, we had a security program, we thought that we were actually doing something with it. But you know, realistically like nothing really transpired through it. And you know, from a developer standpoint there is just no guidance. So there, there's usually a little bit of a lack of focus. And as we all know as developers, there's so many things kind of going on within the developers heads. There's you know, actually creating the proper feature itself, there's dealing with quality, dealing with performance, dealing with security, dealing with accessibility, a whole bunch of different measures that are actually out there. And so unless security is top of mind and unless there is a bit of guidance in terms of this is how you perform security in a mechanism, accommodating kind of takes over and developers just again create a state of chaos.

Definitely seen that. How does competing relate here as well?

Competing is probably the most interesting style to see especially as a, as a vendor. Typically the way that this elicits itself is a competing security program will ultimately shove security down their developers throats and will shove security down, you know, the various other stakeholders. So whether that be hr, whether that be finance and ultimately from a developer standpoint you ultimately have this competitive nature. So this with competitiveness you have this notion of win, lose, where ultimately the security program will win and the developers and the development teams will lose. And so what they ultimately lose is the ability to kind of have control over what they're going to be doing day to day. And a lot of times this competing scenario really comes through after an attack has transpired. So you know, you might have done a number of things to find your organization on the front page of the newspaper. And on day two, once the board of directors meet and you know, once some, some feathers get shuffled, actually what's a better term for that? I don't even know.

Once everything kind of gets shaken up within an organization, when everyone gets back together, this is where competing will ultimately take over and security becomes top of mind. And it becomes almost this idea of you can't do anything unless security is kind of in presence. So within organizations this becomes very much of like a militant type of a scenario. And ultimately developers have no real control over what's going on. And what ultimately happens to this is, you know, realistically for a developer, security is one of the various requirements that they have. And so if you get into a competing scenario, ultimately you might achieve security, but it's only in the short term because ultimately you're going to be sacrificing things that you might not actually see as a security team. You need that involvement from the developers to see what's going on and, and also introduce security appropriately so that it actually gets ingested and kind of combined with other quality measures, with other performance measures, and it's just not sitting on its own. Competing is an interesting one to see. And usually the way that you can kind of see this is you usually have developers kind of crying at the end of the meeting room table or I guess in the next few months on the virtual WebEx meeting. It's when you start to hear the sobbing. That's when computing is taking over.

Your security program is the opposite compromising then? And what are those side effects?

Yeah, and I'm not quite sure if compromising is per se the opposite. With compromising, this is ultimately a lose, lose. And realistically what compromising is is that you realize that the developers need to be at a certain bar and you don't actually really negotiate getting towards that particular state. What you say is, hey, you know, we're going to meet somewhere in the middle, we're going to be, you know, not quite accommodating, we're not going to be quite competing somewhere a little bit in the middle. And realistically with this, this is a really tough scenario because the developers lose, the security program loses. And again, this ultimately lends itself to a state of chaos. With compromising, this is, you know, one of those perfect recipes to again find yourself on the front page of the newspaper and it's a recipe for disaster, primarily because you feel as though you're doing something, you're doing something right. And so potentially from a security program perspective, you might be communicating up towards your leadership, up towards your management, hey, this program is working. This program is actually doing what we should be doing. And hey, guess what? The developers are also happy. And they're not actually really happy. It's just this kind of like, notion. You feel as though you've made them happy. And through compromising and really with compromising, you're doing a little bit of accommodating, you're doing a little bit of competing somewhere in between. And that it's just a really weird state and it's really awkward. I think it honestly, with compromising, it's a bit of a temporary state. You will typically fall into war. It's one of the other four conflict resolution scenarios fairly quickly. It's just a matter of kind of that temporary approach.

Awesome. I believe the last one was collaborating.

And this is the beauty, this is the nirvana state. And so with collaborating, what you ultimately do with collaborating, just like any relationship that's out there is you start by listening. You start by listening and understanding what's going on with the other side of the table. So from a security program perspective, what's going on with that illusive developer? What do they care about what's top of mind and how do you actually invoke some change within what they're actually doing? So potentially you might see for example, an organization where developers are just very focused on features and non functional requirements really get brought towards the back burner. And you see this not only with security, but you'll typically see quality measures, performance measures and a lot of those other non functional requirements really be just sacrificed and just left at the waste. And what happens is, you know, those non functional requirements are on the back burner, then they never become top of mind, they never get actioned. But if you can actually, you know, work with that developer and ultimately create a state where you both win, how do you actually deal with that type of scenario? And so if non functional requirements don't get allocated time, that's where you can ultimately work with the developer and then also work with some of their management, work with some of the product management or project management leaders that might be out there and start creating some time for that non functional requirements, including security. And so through compromising, you know, you typically you kind of, you're meeting somewhere in the middle, you're not quite there. But through collaborating ultimately you create a true win win situation where the developers get the time to do what they need to do, which is that feature development, but they also get some time to focus in on some of the other aspects like security. And from a security program perspective, this is perfect because you win, you have the security brought in and brought into the top of mind there. And through collaborating. One of the big questions that I've received throughout the past year since I've actually done this session was the how the question of how, how do you really collaborate and how do you actually create a good situation where you are in sync with your developers? And I think going back to your earlier question around the Coronavirus, how is that going to change as we all start working from working from home and you know, start to do much more self isol and social distancing and all of those catch terms there. But ultimately, as we start to spend more time with ourselves, how do we actually also be able to include other parties? And this is where ultimately it goes back to that communication medium aspect. And you know, one of the things that I've thought about when it comes to the Elucid developer is typically a lot of elusive developers are gamers. They might not all be gamers, but some of them are. And this might be a perfect opportunity to. So as you are sitting at home on Fortnite or whatever other game that you might be playing currently, that might be a perfect opportunity. Maybe you asked that elusive developer, hey, what are you playing during this time? And maybe you jump on and as you're either shooting some bad guys or building a community, you can actually talk to developers and start building that relationship. At that point some stuff will actually kind of come out and surface. And once you build that relationship and you start listening, you're going to start to understand what the developer is worried about, what they're focusing in on. And you have the ability to ultimately influence what they're going to do. And ultimately through collaboration, what it actually ultimately manifests itself as is influence. And this is, you know, golden when it comes into ward security programs. So if you don't actually just shut security down people's throats, but you influence them to be able to actually introduce security into their own programs, you have the ability to kind of guide them through creating appropriate metrics, through creating appropriate advice so that you get your developers to focus on what you need to worry about. This is different for every organization. You know, for an E commerce organization collecting payment cards, that's huge. That might be one of the first priorities to really focus in on. But for other organizations that might be more dealing with services, personal information is really huge. So being able to actually capture your client information is really top of mind. And ultimately what I wanted to kind of segue in towards was the OAuth Sam and Osam actually just recently had an update which really addresses this, the notion of how do you actually create collaboration between your security program and your developers? And they actually introduced a product brand new section into the OAuth SAM called the implementation section. And so ultimately this, you know, rounds everything up into a five category segment and we'll definitely dive into that a little bit more through this conversation. But the implementation portion of OAUTH Sam really just drives home the how of how do you collaborate with your developers and how do you also measure whether or not you're collaborating appropriately for your actual organization? So you know, it's great to have a relationship with your developer, but how does that actually manifest itself in towards organizational benefit? And the OWASPAM is a great approach to be able to measure that.

All right, so let's touch OWASP SAM then. But folks, I don't know what is sam?

Yeah, so OWAS sam. It stands for Software Assurance Maturity Model. And ultimately the whole aspect of SAM is to make a measurable, actionable and versatile program. And so this is taking your security program and being able to add some structure to it. So this isn't a specific task that you might need to do from a security perspective. So this isn't just hey, you know, we've identified SQL injection within our application on this particular function, within this particular class going and action it. This is more that hierarchy structure into wards, creating a repeatable process that developers and security folk alike can use to be able to drive their program towards success. And this is more of a, of a self acknowledgment type of a program. Again, there are some organizations that will provide some assessments, you know, but this particular program is designed to be a lot more self assessive such that you can actually measure how you're progressing throughout the program and routinely just take measurements. So you can do that litmus test in terms of how you're performing in the various aspects of OSAM on a regular basis. And just quite quickly the very the five key areas for OSAM is governance, design, implementation, verification and operations. And implementation is ultimately that key area if you are trying to win over that elusive developer. And this provide some different techniques and we can just definitely dive into those a little bit further here.

Absolutely. Before we dive in there, you know, you did this session last year. I've been hearing more and more about security lately though. Do you still see resistance against security for developers? And if so, is it the tester's responsibility to let them know about it or is it management? Like what is the roadblock for stopping people from maybe implementing OWASPAM that you see developers may be putting up.

And as you mentioned, for sure, security is definitely top of mind for a lot of organizations. And the issue is the how, how do you implement it and also who is actually responsible for the implementation. And I think the assignment of responsibility is where a lot of organizations fail. So a lot of times through board of directors, through owners, through various other top level management, you have this notion of we've got to do security. But once that boils down and towards a working level with some organizations, they're left kind of wondering like who's responsible? Like, is it that frontline manager that's responsible for security? Is it the development team? Is it the security team? Is it the quality assurance team? And within some organizations there is a clear kind of line of command in terms of this is the, the team that's actually responsible for security. And if they kind of, if they fall into the accommodating or the compromising type of conflict resolution style, a lot of times that also leaves the developers kind of left wondering in terms of like who's responsible for security and who needs to actually take action with that. And so a lot of times not assigning a clear individual, clear group to be responsible for security. That's where it all kind of falls apart. I think there's a lot of attention on security, especially with recent attack and you know, we've all been inundated, whether it be that massive Facebook attack or whether it be a hotel chain or an airline that we might be using that might have been breached. And we get that message, whether that be through email or even as we try and you know, use one of those services where you know, the organization says hey, we've unfortunately lost your information to some attackers. This is what's kind of going on. And it's tough when customers are kind of grappling with that. And I think a lot of times customers will ask for it and that'll kind of flow through that top line management. But then it has to orient itself appropriately at the working level. And as you mentioned, you know, again, Owasam, it's a great framework, but it still doesn't really guide you in terms of who's responsible, what, what are folks actually kind of responsible for and what are they going to be measured against. And I think that needs to be there for success.

How do you get it there? Because I know in the sam it says implement security teams particularly can be a bottleneck. So I guess it's as you shift left you want everyone to be able to do everything. So how do you tell them, how do you educate them to know what they need to do, when they need to do it, at what stage it needs to be done.

And so the beauty of nirvana state is ultimately where security is tightly integrated in with the development process. And so however this actually looks within your organization, ultimately the nirvana state is where security is just embedded in. And so developers stop kind of thinking about oh I forgot to do security, let me go to the security team, let me run, you know, whether it be security tests or getting A security approval. A lot of times when organizations fail, it's where security is kind of left to the very last moment and then it's kind of pushed out. And a lot of times when that's actually being done. Security teams might be able to identify risks, but they can't actually be mitigated or really be action because it's so late in the cycle. And as you mentioned, being able to shift left, this doesn't have to transpire through agile development methodologies or through a very tightly integrated continuous integration pipeline. It could manifest itself just even in processing. And so where security becomes a very early process, so as a developer creates a brand new feature, ultimately that gets tested, tested very early and provides some feedback back towards developers. So, you know, the ideal state is where as a developer is actually writing code, as they're actually, you know, thinking through some of their thoughts and actually making some action from it, if there are some integrations in place, to be able to provide that feedback as you're actually typing, that is definitely something that Fortify offers through both Visual Studio as well as Eclipse. It's a product called Security Assistant. It's awesome to be able to give that initial feedback towards developers as they're creating code. That's an amazing approach. If your organization can't implement that, whether that be you don't necessarily have a standard IDE environment or what have you, ultimately you want to be able to get security as early as possible. And so when the security team gets brought in, if it's brought in as developers are actually, you know, initially flushing out their ideas and pushing that out, that's the perfect time. You know, security teams are able to implement tests and implement measures to be able to assess risks and then be able to mitigate them abstractions of the cost that it would cost if you were to mitigate issues within production or even right before a function or a feature is about to head out the door. And what I would definitely say in terms of shift left is it has to be ingrained where developers and, you know, quality assurance folks, they stop thinking about security in the sense that this is a gate, this is something that we need to do and it's just inundated within the process. So, you know, potentially a static analysis that could just be invoked as early as possible and it's just there, it happens, happens without a developer or quality assurance team member necessarily having to make this outside quest. It's just a part of the regular flow of work. And at that point, you know, the security itself, it's In a perfect state, you're collaborating with developers because you're ultimately invoking feedback as early as possible and you're waiting for the developers as well as other stakeholders to provide their feedback. So not every security issue needs to be mitigated per se through a, you know, line of code fix. There might be some other ways to be able to attack it that might be a lot more appropriate. And so, yeah, definitely, if it's integrated and integrated into wards the whole process of development, we're off to the races there.

So another topic I know you want to talk about was software composition analysis.

One of the big things that I think is coming up with security programs is a lot of times code isn't necessarily fully completely developed within an organization. Sometimes code is brought in, whether that be a third party library or whether that be an open source component. And a lot of times your risk comes from those specific components. And there are a number of software composition analysis tools that are coming out to the market which allow you to be able to identify issues within those components and be able to figure out which particular version of that component is free from security vulnerabilities. And one of the big things that this is kind of letting itself itself towards is a lot of security teams kind of crying wolf, where they might just look at a version being vulnerable and they immediately go back to the development teams or the quality teams and they kind of shove down, hey, you've got to upgrade from this particular version to another one. And you know, as developers, as quality assurance team members, I think we're much more fundamentally aware that, you know, making that change is really difficult. You might have a lot of functions to go back and mitigate and change. And so one of the big caveats in towards software composition analysis is really understanding whether or not you're using the vulnerable component of that library or if you're using outside features, which might actually just still be safe. So just a little bit of a tidbit to throw out there, but that was it.

So before we go, is there one piece of actual advice you can give someone to help them with the security testing efforts and what's the best way to find our contact?

Yeah, for sure. And so the easiest way to be able to contact me and to contact the organization itself of Micro Focus is checking out Fortify Online. There are a number of web assets that we have. If you wanted to give me an email, that's probably the easiest way to get a hold of me. And I think in terms of actionable advice, in terms of being able to actually make sense of your security program. I think what you have to do is just start and the realistic aspect of it is that you are not going to reach a perfect state. And this is kind of the tough thing about security is it's a never ending battle. So it's a tug and pull with.

Adversaries and so that tug and pull with adversaries is never ending. And so you've always got to kind of morph your program. But you know, just starting and being able to get something going in towards your security program adverse that's the best thing to do. And you know, if you don't have it already, one of the easiest places to start is through static analysis to be able to take a look throughout your actual application to identify vulnerabilities that might actually exist within your code and be able to start mitigating there. That's, you know, the first action that you can make. And you can definitely do that through Fortify Static Code Analyzer or through Fortify On Demand. And happy to help and my organization is definitely here to help you if you need some help getting that off the ground.

For links to everything of value we covered in this episode, head on over to testguild.com S13. And while you're there, make sure to click on the Try Today link under the Exclusive Sponsor section to learn all about Micro Focus Fortify, which is the recognized market leader in application security. So that's it for this episode of the Test Guild Security Podcast. I'm Joe and my mission is to help you succeed with creating end to end full stack automation awesomeness. As always, test everything and keep the good. Cheers.

Thanks for listening to the Test Guild Security Podcast. Head on over to testguild.com for full show notes, amazing blog articles, and online testing conferences. Don't forget to subscribe to the Guild to continue your testing journey.