Talking security infrastructure and compliance with Brian Levine

In this episode of the AppSecEngineer Podcast, Rahul Raghavan is in conversation with Brian Levine from Axway. Brian talks about how compliance should be a byproduct of security and not the other way around, and gives us a closer look at how he builds small and large-scale security programs from the ground up. And for all you prospective AppSec engineers, tune in to see how people like Brian hire talent for their ever-expanding security programs. If this helps you get the job, be sure to give us a holler!

Why Coders Do Better at AppSec with Brian Levine | AppSecEngineer Podcast

Rahul - All right. So welcome everybody to another episode of the AppSecEngineer podcast. And, for today we have somebody special . This person, someone, that I've had the opportunity to kind of work and interact closely with over free different er reduce the past couple of years and is definitely someone who shares a lot of the passion in Product and Application Security. Without further delay, I'm goin Reed 5g to glad to kind of introduce today's guest, Brian Levine, from  Axway.  Hey, Brian, how's it going?

Brian - Hi Rahul. How are you? I'm good. Thanks. I'm glad we could do this.  

Rahul - Yeah. So like I said, we've been, talking and interacting for a while, but we've never really had the opportunity to kind of do this because a lot of questions and a lot of thoughts that we've been having or rather that I've been putting together for this chat is ironically we've never had the opportunity to chat. So I'm excited about asking some of these questions to you. 

Brian - Yeah. Looking forward to it.  And you know, we've worked together the past couple of years and done a lot of cool stuff, but we've kind of stepped back and just had a chat about, you know, kind of the program and some other things outside of the day-to-day. So I'm looking forward. 

Rahul - Cool. All right. So Brian, the first and foremost thing that I want to do is, again, this is something I've never, I've never asked you, I guess. So what is it that kind of got you into Product Security, Brian? So where did it all start off from? 

Brian - Yeah. Good question. My genesis story [Laughter] although it's probably not as exciting as a story or anything like that, but yeah, so kind of my background, just kind of, so we kind of have some time here just kind of start back in ancient history I guess, there was kind of growing up . My friends and I were kind of nerds back in the day. And we used to like to , you know, the first kind of, one of the first things we did when we got our first computers was, you know, get modems and hook them out to , you know, to the telephone lines.

And so throughout the time and aging myself, but that's about that time, you know, the movie war games came out. And so, you know, that was really cool to see, you know, hacker with, you know,  what's possible.    [Laughter] So we wanted to try some of that stuff and so we went and you know, put our modems to work and put in the war dialers and see what happened when we tried that stuff out and and learned what happens when you try to mess with the telephone companies and learned about that. And I kind of, I guess, would be kind of the start for my interest in information security if you call it, and, you know, back in those days, of course, we didn't call it information security, having fun and really kind of seeing what abuse cases could be done and what things could be done.

And obviously, surprisingly, there was very little thought put in by the people that were setting up, you know, these systems early in the day about how someone might misuse that and it made things obviously very easy. And so, obviously, things evolved and security got much, much, much stronger. That's kind of like the far past, kind of jumping a little bit forward, you know, career wise, I started working , you know, with businesses in Aerospace, Federal and Defense.

Oh! I did not know that. Oh!! okay. Okay. Yeah. And in those kinds of environments , you know, security, access control, encryption and cryptography was, you know, very important. And so just kinda-sorta got fascinated a little bit by that and looking at, you know, encryption and access privileges on, on, you know, the networks and the systems that we were working on.

And that's where I became sort of a side job, kinda-sorta became the , you know, the resident expert when talking to customers and how the products worked in that space. And then, so, you know, this is a kind of a long intro but, ... it's fine, as we have a little time. My full- fledged security journey, I would say began, you know, full-time security role when I was interviewing for a security product manager role. So it was for a SAST, you know, basically Enterprise File Sharing Application, SAST application, kind of a startup stage. And I was, they were looking for a security product manager to come in and build security features. So, you know, during the interview process, I said, well, that's, you know, it's very exciting.

I really liked to talk to your CISO and I love to talk to your head of security engineering and I got kind of a awkward stares and some kind of blank stares and pauses and effectively the answer was well, we don't think we really need that yet and so maybe you can handle that for us too.   [Laughter]  

And so, you know, it kind of started there, trial by fire, playing the role, you know, security officer, security product manager, and security engineering, architect all rolled into one. And it's been kind of gangbusters since that, 

Rahul - you know, interestingly, what's interesting with that transition is it's very close to heart in terms of the progressions that probably I have had in the credit as well or even, even, even in terms of the progressions that We45 has had, because it was never an application security back then, right. It was always cybersecurity, was information security, and then you kind of got into application security. And talking about motivations for security, I think compliance has probably been the first tick that teams have ever had in terms of taking security seriously to a large extent even today but I think, thankfully we moved to a time where it's not just compliance, there's a lot of proactive involvement in including security. But, I know that you've kind of handled it not just in Axway, I'm sure in your previous experiences as well in terms of managing compliance and security.

So how do you kind of see that balance Brian? I mean, do you see a shift in that perspective of compliance being the first step towards security or is that a thing of the past and you know what people all of them understand. 

Brian - Yeah, now that's a great, a great way to put it. And yeah, it's also interesting in terms of  how you guys have evolved in your business from, you know, doing kind of the security audits and security frameworks, and now obviously much more focused on the AppSec. So it's really interesting the way you mentioned the word tick in that, in that example too, because when I, when I first think of security and compliance and

you know, kind of segueing security and compliance together, or, you know, maintaining the balance between security and compliance, the first thought is, you know, I would much rather start with security and then arrive at compliance. And I think, if we want to really deliver on the design intent and the reason we have compliance programs to begin with, I think, if you start with security, the compliance almost effectively takes care of itself.

And that's kind of the initial thinking about it. But it's very interesting too that you mentioned because compliance often is how customers or companies, enterprises finally get serious about taking security seriously and doing the things that they should have been doing. So there is sort of that balance because oftentimes you will try to get traction on your program, but until some event comes along like a SOC audit or a Sarbanes-Oxley audit or some type of an actual contractual obligation when people start to get serious and start to pay attention and do these things.

So, I think, you know, using it to justify your program, of course, is effective. And , and I hear it a lot too from certain, you know, segments of the industry, you know, in banking and finance, for example, because they have such a high bar around compliance, then they are pushing the bar a little bit on the security side. But again, I think, you can do compliance and not be secure but it's... start with security. You're much likely, much more likely to arrive at the compliance you really intended with security in place. And kind of a personal note on that too is, you know, I was at my point in my career sort of a crossroads if you will, they're kind of thinking, you know, do I want to go full-time privacy and legal and maybe more compliance side but really more on the privacy space, you know, when obviously, Privacy Shield and GDPR and, and everything that's happening; even these days in the world of privacy is a, is a huge industry of itself. And, you know, I was considering making a direction to become a data protection officer and was kind of approach to be a, you know, a DPO.

But, you know, I just felt like you can't really achieve privacy without strong security, right. You can do privacy compliance and privacy legalities and privacy legislation but if you don't have strong security controls in place to protect the personal data in the first place, then your privacy is just paper. And so I really, I kind of stuck with the security side of, of, of that equation and really kind of made that my focus and obviously, you know, privacy is still a big part of what we do, but you know, not my main job. 

Rahul - Yeah. And, I think, while you were saying that and looking, if I were to kind of think back at, at actual compliance mandates , there was a time when and this is probably when we were starting off in 2010 or 2011, where an ISO 27001 was probably the most closest that a generic compliance got to Application security. You always had the HIPAA and the PTI, but then cut to today and, and there are a lot of iterations that have gone through, even in compliance requirements.

Right. I mean, I'm sure people who do look at compliance as a means to achieving security can even look within those opportunities to kind of improve in terms of their...in terms of their software security program as well. I mean, I'm sure a lot of these are in compliance because it's been a while since I kind of looked at the 27K or the SOC mandate. I'm assuming that these regulations have done their part in terms of trying to keep customers, or programs more iterative there. 

Brian - Yeah. That was very interesting. And a great point. I mean, I think if you look at, you know, customers are getting smarter about the questions they ask around, you know, using the cloud or using, you know, your, your enterprise software .  The auditors are getting smarter as well. And, so if you look at a SOC audit from say 20, you know, 2011, 2013 , it was a... lot of these things were kind of new and sorry, I was talking about the cloud and what is Amazon and what is, you know, and now when I'm sitting down, you know, with auditor's doing a FedRAMP audit or something to that level, they're getting very fine-grained and savvy about the architecture and the underlying technology and almost in some cases educating us about, okay, well, this is what FedRAMP, you know, NIST 800-53 looks for, for Amazon RDS encryption at the database level or Amazon RDS protection. And, it's no longer capable of just saying, well, no, that's, you know, that's handled by the cloud.

And, so the  infrastructure provider controls that layer and they audit that layer. Now, they're looking for additional layers of control and going down to like, okay, S3 and RDS and the different [pause] components to a much more granular level. So it is interesting to see how that, you know, that compliance frameworks are starting to evolve and pick up and catch up.

But still application security, I think they can go further in terms of how in-depth they get at the application layer, usually it's maybe part of a control family or maybe one control family. And they kind of looked okay, did you do a Pentest? Okay, great. [pause] Right. You know, something [Laughter] 

Rahul - Now, interesting, you mentioned about application security specific. I wouldn't call them compliance but, let's say, application security specific frameworks and I want to.. that's a great segue for my next question, which essentially is Axway has particularly been a huge contributor to programs like the VSAM or it could be individuals from Axway who potentially contributed to OWASP projects and things like that. So, in that sense, I'm sure Axway has kind of been that as an organization has always been a proponent of application security. So, I want to kind of pick your brains a little bit on implementing a security program in that sense. Right. So you've obviously, I know for a fact that you've had the opportunity to kind of implement programs at smaller companies and then move to today where you're kind of doing something very similar in a much larger and a different scale at Axway. So talk to us a little bit about what does it what, what, what is really the hop, skip and jump if you will of building out a product security program, you know, and as much as you could kind of tell us about Axway, that's great, but even without that I just want to understand what would be your opinion of having done something like pull this out from like the say womb-to-tomb, if you will.

Brian - Well, yeah, it was a great, great question and a good, a good bone to chew on. So, yeah, I mean, I think, I loved the way you kind of, kind of segued into that too in terms of, you know, we were talking about compliance frameworks and I think, you know, when you look at what's out there, NIST and ISO and things like that, they kind of just sort of barely scratched the surface in some places on, on AppSec. But BSSIM and the OWASP SAMM and the Microsoft SDLC, so those are definitely three frameworks that I think, you know, anyone building an AppSec program should become intimately familiar with, you know, download the BCM report, read it, digest it, stick it under your pillow... 

Rahul - as much time as it takes 

Brian - [Laughter] so OWASP SAMM and the Microsoft SDLC, I mean, those are great sort of frameworks to look at and not to say you're going to go out and now I have to go build BSSIM or go build OWASP SAMM because you'll never, you'll never, you'll never accomplish that. They're, they're more sort of frameworks and guidelines. And, you know, I think if you distill your commonalities between those and then, you know, like you said, kind of, sort of, what have I sort of experienced from starting from, you know, very small programs to more midsize, larger  programs, you know, I think there are some, some critical core components and foundational components that, and you can find great advice and examples and, and specifications, even on those, you know, I think number one is, is really starting with your Core Central Security Group.

And that's, you know, it could be, you're the first, it might be you, and you're the first AppSec engineer at your company and someone said, hey, we need, you know, we need to scale this, show us how to do it. Or you might have a collection of decentralized, you know, larger organizations. You may have pockets of application security spread out in the organization, but the idea here is to centralize, you can kind of central... center of excellence if you will, or a software security group.

So this is like a core AppSec team you want to put in place and give them a charter and give them a defined objective and a defined charter and make sure you have executive sponsorship, sponsorship and executive buy-in of that charter as this is, this is the team, this is what we're set out to do and start there. And then you know, and then organizationally, I think the other elements you really, really have to have in place before you do anything again, is that, you know, organizational and culture aspect. And, so I think it was that group gets going they're gonna need what most people call security champions and BSSIM talks about security champions.  And there's some great resources from SAFECode about, you know, security champions program. And OWASP SAMM also talks about it. But your security champions, I mean, that's how you scale. That's your, you know, your boots on the ground. Your, you know, your feet on the street because you can't,

the course AppSec program, as you scale cannot be in every conversation, cannot be in every design review, it cannot be in every interaction with product team and the designers of the products and the scrum teams, you know, planning out what we're going to do for security. So you need those security champions to help you scale.

And those sorts of, sort of those two groups become sort of the foundation really to say, okay, you know, the core AppSec team is really kind of looking at, looking at the common security problems and coming up with tools and best practices and frameworks and infrastructure to help kind of build a global program.

And then, the security champions really are a little bit more responsible for actually executing and using those tools and frameworks that, you know, the core team is driving. And then, you know, as you grow and mature, you know, there's a nice give and take because a lot of times the security champions now are on the forefront and they're the ones finding new application platforms they want to work with. Right. They, they have , we're going to do a new project and we're going to use it, we're going to write it Go or we're going to write it in Vasco or we're going to do, you know , something with Kubernetes that no one else on the team has done or in the organization has done.

And so they are going to be kind of on the forefront and saying, okay, well, here's what we found. Here's what works from a security standpoint. And, here's some tools that we think work as well and feed that back to your central AppSec group, and then that can kind of become like a standard. So those, you know, like I said, I mean, those are kind of, kind of to sort of before I would go out and

do governance or do process or policy, you know, starting with the culture, starting with the organization , security awareness training, the security champions and that core team get, get that in place and then you can go and start doing some of the more mature layers and formalize your program.  Right... that, you know, on and on and on about that.

Rahul - No. I definitely want to kind of delve further into some of these things, but you talked about scaling these programs and that kind of triggered another chain of thought in mind because one of the most significant water cooler conversations that we have at the We45 is, you know, I always keep telling teams and I've said that to some of the other guests here as well, that one of the things that Application Security and DevSecOps marketers need to really kind of think about is building castles in the air as far as potential as DevSecops and Automation really being that magic pill that kind of solves a lot of these issues and I've had, I've personally kind of seen a lot of product security engineers, or executive kind of really have that excitement on their face when they say, Oh! you can automate this, Oh! my God, this, you know, there's this amazing levels of tools that are there and things like that

but we know that's not true. I mean, there's, it's, there's a lot of bumps on the road in terms of really getting to that idealistic Utopian land called completely automated software security process. And not that it's not achievable, but what is a realistic goal for, for software teams to kind of have when they're talking about DevSecOps and tooling and things like that.

And I guess what I'm really asking is we've got a lot of people talk about the, the amazing things that, that, that AppSec automation can achieve, but I want to kind of move away from that and really talk about the potential gotchas and, and, and the issues that one needs to keep a watch for life because I'm sure there's a lot of interesting content out there where people are going to talk about the amazing things that AppSec automation can achieve, but I want to really play the devil's advocate and talk about the flip side of the coin here.

Brian - Yeah, yeah, for sure. And yeah, I mean, I agree there's a lot of marketing and, and obviously security vendors are, you know, very very , you know, riding the hype cycle sometimes a little bit on, you know, what the tools can do and, and so yeah, it's a great, great kind of subject to segue into and , you know, again, that having that core team is again why that critical because like you said, it's, yes, automation will solve a lot of problems for you and yes, you will get a lot of quick wins or early wins out of tooling and automation. But, obviously, there's also a lot of noise that comes out of security tools and there's also a lot of overhead that goes into managing any type of automation, infrastructure, security, quality, build environments, all require, you know, care and feeding and maintenance and management.

And, so there's no sort of magic pill, I'm just going to drop off. I started code analyzer and you're just going to plug it in and it's going to automate everything and you guys are gonna be secure. So , yeah, I think a lot of what I've seen and I have also studied rather to point to that sort of this, this middle ground or middle

ground where companies kind of sorta stall out a little bit in scaling the program because of that, because of that challenge. And so , I mean, I think one of the first things you have to do is just engage with the development teams and see the security challenges that they are having before you go out and build a process or build a implemented tool.

We kind of want to coexist and work side by side and make sure, you know, obviously the whole DevSecOps mission and, and mentality gets right is that it's really not about, Oh! the security team does that and that's something that the security team does or security is something we do after we release or at the end of the, you know, at the end of the life cycle, then we'll do all our security tests.

And so, you know, the DevOps mindset or DevSecOps mindset is kind of ingraining security in every step of that SDLC life cycle and every step of the DevOps life cycle, there's some level of, of security procedure or security tool or security process. I have a pretty good graphic on that. I don't know, maybe we can, we can share it after and you can pop it in here. But if you look at the DevOps, the classic DevOps sort of infinity , you can, you can really see. And it, it hits a lot of people too who've been doing DevOps for a while and haven't really stepped back and considered, you know, all of the touch points that you know, security hits in your plan, code, build, test, release, deploy, operate, and monitor.

But , you know, kind of, again, back to your, back to your question is that, you know, showing up, being in the planning sessions and seeing the problems and solving problems and helping fix problems is where you have to start but then ingraining that mindset that, you know, until everyone is starting to take some ownership of their piece and taking some ownership of fixing the security issues that are identified or helping maintain the tooling and the infrastructure. Because if you say, Oh! that's a security thing, that's the security champions job or that's the security team's job to maintain the tools. Well, then, you know, your, your strongest application security engineers now are not doing application security work there, they're managing Jenkins or they're managing, you know, tools and that's, you know, that stuff is obviously important and you need people that to know, you know, site reliability engineering and tools automation, and, and that's a specialty and you want to, you know, use your specialists and team members that's and, and use your AppSec team for application security and not tooling.

And so that's really that, that shifting a little bit to say, okay, security, isn't something that just the security team does and security isn't something that the security champion is responsible for. And kind of, you know, relieving some of that, some of that burden, burden when it comes to, you know, tools and automation and so I think that's critical, you know, definitely part of, part of that equation. And, so I don't know if I completely answered your question about, you know, DevSecOps and tooling, but .. but yeah, I can definitely, you know, go further. 

Rahul - No, I think, I think there was a lot of insights in that's really the beauty of  DevSecOps and AppSec. I think that's really the beauty of AppSec being not a one size fits all. And, we've discussed this many times. It's, it's never going to be that the challenges for Axway for example, is going to be the same as, let's say, the challenges for another company that's like Axway even in the same domain, because you're really kind of talking about multiple variables not just in terms of the business model, which is on the business side but even when you look at the tech stack, it could be the kind of developers that work there, the architecture and whatnot. So, I'm sure if application security is not one size fits all, so therefore the challenges as well are quite kind of unique . Talked about, we talked about  Axway's core team and I think what you really talked about is like a hub and spoke kind of a model where with a center of excellence in application security kind of really driving these multiple pods of security across.

And while I was just kind of looking at, you kind of, I mean, your formal designation says Senior Director Product and Cloud Security. That's a pretty expansive kind of, kind of a role. And, and that combined with what you told me about having a core team of, of, of application security engineers and then driving that security champions program, that kind of led me to my next question is purely in terms of skills in application security and one of the, one of the larger

aim of the application security engineer podcast is for us to kind of really throw some light in terms of budding secure, for, for budding security engineers or, or, or, or for anybody who's kind of building out an AppSec program or somebody wants to get into AppSec or scale themselves up to the next level in AppSec is kind of get them insights from practitioners and executives such as yours. So. ..I know, I know..I know... saw a couple of LinkedIn posts a couple of weeks back where Axway was hiring for an AppSec engineer. So, let's say, if this is a, if this is a higher call or or somebody is trying to apply for that role what would it take for Brian to kind of hire an AppSec engineer and, and what, what is it that you're looking for in an AppSec engineer , which is really a representative sample of what other, what should AppSec engineers be kind of looking to hone in terms of skills, if they want to really look at a serious career in Application Security. 

Brian - Yeah. Great. I'll be happy to plug the fact that we are hiring so if you're interested, go to LinkedIn, it's .. we're in October right now so depending on when you're watching this, hopefully, you know , maybe we’ll have openings but, and, and before I kind of get into that, I want to sorta kind of to your last point, and to this point, put some context around our program because I don't think I kind of introduced that, I mean, that our sort of security program and environment at Axway you know, we have a sort of global R&D organization. So we have 7 R&D sites, you know, geographically, you know, throughout . I guess we're on probably 4 different continents. And about 600 developers in the R&D organization, and about 150 products and call services in our catalog.

So if you're, if you're going to the Axway store and you want to buy an Axway product, we have 150 licensable products. And ,so we're talking about a very diverse , developer community and which is, you know, again, some context for when we talk about scale and solving some of these problems. If you're a monolith and a small, you know, shop and your whole codebase,and your whole stack is, you know, one codebase or one stack and, you know, some things might be a little bit more, you might not need some of those things in terms of scaling, but as soon as you start to mushroom out into, you know, new stacks, new products, new platforms , more sites, more developers, then, you know, that's kind of where that scale plays in. And , and especially the reason you need that kind of organization too because there is no sort of one size fits all.

Okay, we're just going to say everyone, this is how you do a data input cleansing for Ruby and so now we're secure. It's now, because we're supporting, you know, Go, Rust, Java, C -Kotlin, Ruby Python, you know, and, and 12 other languages and whatever language comes up tomorrow. No  AppSec team is going to have to roll with that and adapt it, so you know, it was kind of context and also kind of, I guess, a good segueway to, what are we looking for. You know, and I'm sure some of this stuff, I'll start with the basic stuff that you would see on pretty much any AppSec job description. So, obviously, we want people that, you know, are, are have.. have have depth in several of the core, you know, application security domains, and that can be you know, just kind of spitballing, you know, cryptography or supply chain management or, you know, protocols and SSL and Data at Rest and Data in Transit where , you know, you're more core, maybe has a developer background somebody who actually has written code and been a developer is also obviously a strong, strong thing to have, especially, you know, when sitting down with developers and explaining why something is exploitable. If you can look at the code or explain to them in the code, obviously that's, that's, that's a, that's a plus.

So it depends on the personas as well. I'm not saying you have to be a developer. If you don't have that developer background, maybe you're a strong security architect or maybe you have a strong architecture mindset and just kind of looking at the bigger picture and how different pieces of the system fit together in  more of a threat modeling fashion.

And you can sit down with a team and do a threat model and sit down with a new application or existing infrastructure and just model it out and say, okay, well, where are the weak points and the potential attack points and what can we do about protecting those? So those are, you know, it's a little bit different persona and also something that, you know, of course we look for.

And then, I think, you know, what you don't see in a lot of the job descriptions and what I think make people successful in the role is really that having some communication skills, you know, it sounds , maybe, a little obvious but communication skills, having that flexibility and the, the almost consultant or teacher mentality and, and patience, right

to sit down and really have to be patient with someone and be patient with the development team in a... in a group too. You know, walk them through it. You know, security is not everyone's job. Everyone doesn't care about security. Some people hate security. And, so when you sit down and [Laughter] you'll explain something...Yeah...  you have to be very patient.

And communication skills, of course, I mean, when I talked about, you know, we have, you know, four or five different languages spoken in our company, so , you know, not everyone …

Rahul - not just the programming ones...yeah 

Brian - [Laughter] just programming ones. The written language, the spoken language , you know, obviously, we have lingua franca English but still, you know, when you, you know, you might be talking to someone several times zones away and you know, so being able to really overcome that in written communication and documenting things and saying, okay, here's what I'm trying to tell you, but let me put together a blog or a Wiki or, you know, an internal post about it

and so you can see in an example and so, you know, those communication skills, like I said, are not something that you might see written strongly into the job description. I think that's key and it comes through in the interviewing and it comes through when, you know, when you hit the ground and the job.

And now, you know, we're not just, we assume you have a lot of the technical competency, and all that technical ability. It's, you know, now, you know, how can you use it? And, you know , what are the other things we would look for, of course, is, you know, what results have you gotten in your past roles. You know, talking about security vulnerabilities, etc., but what have you done to fix security issues? You know, how have you resolved security challenges? And that's, you know, obviously, the , the ultimate goal of our role and the reason that we exist. It's not just to find security weaknesses and tell people, you know, how ugly the baby is. And , you know, all the security weaknesses, it's what have you done about it?

How have you helped people stop making those mistakes? How have you helped people fix those, those mistakes? And so, you know, when we're hiring, you know, definitely looking at the result they've gotten in their past roles and certainly you want to highlight that, you know, during the interview process and say, okay, you know, let me tell you about a time when we, you know, did a CTF and trained the organization on these vulnerabilities and how they were able to use that  being their own products and things like that.

And so, yeah. Again, those are some, some ideas. 

Rahul - I love the fact that you mentioned. I mean somewhere in that last three or four minutes, you mentioned a couple of things. You mentioned a development background and, and that really gets me exciting because, and this is something I do with all my guests, right.

Because I, while I might be really passionate about a particular opinion of mine. I always want to kind of validate that with practitioners to see whether we are in the same line. Now, it's our personal belief here, We45, and mine as well. And, that's something I have in a lot of my presentations is , might sound redundant for people who listening to this again, but anyway, so, I mean, we were in a, we were in a time a couple of years ago where security engineers, which is going out there and saying, hey, developers, you need to understand security. Hey, QA guy, you need to understand security. Hey, DevOps guy, you need to understand security. I think cut to 2020, these guys are going to come back and say, hey, security guy you need to understand how to code. Right. You need , you need to get code. And this is something that I think fundamentally kind of is, is that, that line and that, that, that chatter I see is very fundamental to building up an application security program.  And, and the reason I say that is, and, and I'm really looking for, I mean, I really want your honest opinion here is because how important do you think, and do you think is for an application security engineer to understand code and I'm happy if you could kind of debunk some of those myths that I might have or the team might have, but I'm still kind of yet to meet someone who's going to completely disagree with that because I kind of see that a lot of them have a lot of value.

Brian - Yeah. I mean, one hundred percent I agree. The more you understand about the code or how, you know, how to write software, how to develop software, you know, it's going to permeate into various aspects of the role. Number one, like you said,  sitting down with a developer and explaining to them why something is a vulnerability.

If you understand the code, you're going to be able to explain it and then you're going to be credible versus, you know, if you're in a situation where you don't understand the code but you, you know, you ran, you know, static code analyzer and it came back with, you know, twenty vulnerabilities that are marked critical and you're telling someone they have to fix it.

And they're saying, no, I don't because that's not exploitable. That's a false positive. That person might be wrong, they might be right. If you don't understand the code, you have nothing else to go on but, you know, what they just told you. So definitely in terms of having those dialogues and conversations is certainly , certainly an asset for you.

As well as we talked about, you know, touched about the DevSecOps land, you know, the automation and the integration, etc.,. At some point, you start building all this stuff out, your tool becomes a production application, right. You can't just, you can't just bailiwick, you know, something together and, you know, hacking a little bit of code together and okay now my static analysis system talks through my threat correlation engine and spit the ticket out to JIRA to go fix something. Well, what happens when people now are relying on that and then something broke because of the code you wrote to do it. And so, you know, you might not think of it as, as obviously but you know, when you're building some of these processes and procedures, you know, being able to write production, robust code and robust systems is pretty important. Again, I guess, when you have development teams that are trying to ship and release something to production today and your tools broke, and you don't know how it works.

You're in trouble. 

Rahul - Yeah. And I think even at a... and we talked about sitting down with developers, being patient with them and, and really those non-technical skills coming in. And, I personally feel one of the biggest advantages of security people understanding code is at a philosophical level, you're going to be able to strike that conversation and really kind of empathize, I guess, with mutually with the development team. They're gonna, you're gonna understand what they're going through. You, you're probably going to be closer to their tribe if you kind of understand code, right; otherwise, you're always going to be that person who does not really understand what you're going through as a developer.

I think, I think at a philosophical level too, I think understanding and being closer to code, gives you the perspective of whole cultural bit of code aswell .

Brian - Yeah. I think .... I don't know if our audio is clicking out, or thats me.... 

Rahul - No, I can hear you well. 

Brian - Okay. Yeah. I mean, that's a great, great subject. I think there is another idea you raised there that reminded me of something as well, and it's not just the code itself. It's understanding what it's like to live life as a developer and what CI/CD is. If you don't, if you don't know what.., how continuous integration works, if you don't know how continuous delivery, continuous deployment works from the developers side of it, how do you plug your security process into that?

And so you're understanding what is , you know, how build works and understanding how CI/CD works and then say, okay, here are the points where we're going to put our security tooling into that chain. You've never lived the life of a developer, then you definitely coming at it from a weakness I think because now you're instituting something in a process that maybe you don't really understand so much or you haven't had that experience.

And so, yeah, I don't think it's mandatory to be an application security engineer, an AppSec specialist that you have to have a developer background and obviously you can be very successful in, in a security career without being a developer, but it definitely is an asset and if you have that background or if you're wondering should I focus more on it?

I would say,  yes. I mean, it's definitely an asset and it's going to be, you know,  your code helping you out.  The point I forgot to mention on your question about what we're looking for in AppSec engineers is the non-AppSec stuff is cloud. Right. We talk about, and now you have infrastructure as code, right.

And so [pause].. We're still waiting for some of the tools to catch up, but you know, when it comes to static analysis on Ansible or static analysis on Terraform or static analysis and understanding, okay, what are the vulnerabilities that are getting introduced in the infrastructure as code. When this thing hits, you know, the cloud layer, when it hits the infrastructure layer, how is, how is that exportable, what errors or mistakes might we be making in our infra as code?

As, you know, as an exercise from an AppSec standpoint and an AppSec mindset is, okay, well, what, how do we threat model that? How do we do, you know, SAST on that? And how do we incorporate that into some of our, you know, security tools and security processes from one aspect as well as just being able to have those conversations again with operations teams or developers who are developing something for the cloud, and everything's built on, you know, Kubernetes and Docker and having, you know, sitting down and having a threat model conversation with them. You need to be able to understand how those underlying components work and, you know, how they're being, how they can be exploited.

And so definitely, today's, I would say modern AppSec engineer, if you will, or the budding AppSec engineer, I think you, you can't do yourself any harm trying to pick up , you know, the basics of Amazon, basics of Azure, basics of GCP; how does, how does it work, you know, and the security specialties in those, you know, cloud platforms, as well as, you know, things like Docker and

Kubernetes and that sort of thing, so that it's not a mandatory must have, but certainly, certainly also something that will, will set you sort of above a lot of other people you might be competing with for those. 

Rahul - Yeah. And, Brian final question that I have for you is , I think, this was pretty custom made for you because I remember I was talking about this a couple of years ago. I know is the relationship that that, that a CISO or a product security executive in companies like yourself, now be it Axway or large or predominantly software product companies, have with the sales teams right, because progressively what we're seeing is security is not really that function that's really hidden behind in organizations.

And, we're seeing a lot of conversations about security coming up in, with sales teams right. Today we are, today we're at an age where sales teams need to have war cards ready with them, battle cards ready with them that talk about how security or application is, what are you doing from a security perspective?

So, how have. I know for a fact that you've been in that kind of been in part of those discussions, you've probably been part of, I know you've been part of go-to-market road shows and things like that. So what can you tell us about, about that, you know, that, that dance, that, that CISOs and sales teams have with end customers?

Brian - Yeah. That's a great , also a great topic and yeah. So let me think about that. How to start because it is obviously not an, I don't think that I have a day in my, you know, my work where I'm not either on a call with a customer or responding to a question from sales or responding to a question from a customer.

So it's you know, very much ingrained in our security program and what we do. I would say, you know, for starters, you know, if you look at, especially, you know, your question is around sales, so if we look at, you know, sales pipeline, right, and the sales cycle, right. And what happens, what's the customer experience from, you know, identifying this is something I want to, you know, maybe this is a vendor or a product I'm interested in too closing the deal. And, I'll probably start from the back, you know, from the end of the life cycle and work my way forward because I think that's sort of how, you know, AppSec or code security sort of easy evolving in that starting from the back now going to the ... shifting left if you will or moving to the front of the sales cycle and then front of the marketing side of it.

But, you know, when you get to the end of a sales cycle, usually you're dealing with the procurement and risk and security management side of the house. You know, if you're, if you're, you know, selling to the enterprise , you're going to have somebody who gives you a spreadsheet of, you know, 300 questions, I had downloaded the cloud security CAIQ, filled it out. I downloaded the SIG, fill it out. And so, you know, starting out the security program is doing a lot of reactive. Right. I got the security questionnaire and now I have to fill it out and answer all these security questions so that we can close this deal and sign a contract.

But as you evolve and grow, you know, the security team has to have those assets already built and already ready. And so you shouldn't be... the customer shouldn't, you shouldn't be answering them when the customer is asking for it. You should already have that pre-populated so that if a customer is in, the sales cycle at the end and says, Oh, I need this, you have it right? And so you're, that's sort of, you get into your compliance and core security controls, right. The NIST controls and PCI controls and SOC controls, they all have to be documented. But, you know, really, you know, ideally, so you have to have those assets , but at the front of the sales cycle, it's like, okay, well, how do I, how do I make secure?

Because everyone, everyone assumes you're doing that stuff, right.  They [pause] one way I look at this too, is kind of a, the Maslow's hierarchy, if you will, right. There's, there's self-actualization or those things that differentiate you from a security standpoint. And then there's things that people just assume that you are doing like food and water, right.

You're not happy if you have breakfast and lunch today, and you have some water to drink and shelter. So food, water, and shelter, that's just, you expect that to be there. And so buyers, you know, they expect that you have all these core AppSec programs in place, the core InfoSec operations in place, they not impressed that you're doing it, right. 

Rahul - And I think, I think that expect... that that baseline as we go forward is kind of increasing, right. It's customers are kind of increasing that baseline. So that's interesting too. 

Brian - The bar and the table stakes and, and, and they assume that stuff is there. And so, you know, you need to do it. You need to do it very well.

You need to demonstrate you're doing it. And, and if you're doing it extremely well, then it becomes, can become, you know, a top line. You know, as a hierarchy, it can be self-actualized or it can be a differentiator. But, you know, when you talk to sales and marketing, they're going to be more interested in those differentiator things.

And so, you know, the stock compliance and PCI compliance. They assume you have that. They want that in the sales cycle because now, when you talk to sales on the front end of the chain, right now we're doing marketing and we're doing road shows and we want to get people interested in us because of our security.

Now, we're talking about more security features, right. Security things that we can offer customer facing security controls that maybe our competition doesn't offer, right. And so in this side, you're, you're, you know, you're, you're talking to sales and marketing, but you're also need to be working with your product managers and your developers or also your development teams and your product managers to say, okay, and we've done this too with some competitive analysis, right.

So they'll say, okay, well, what does, how does you know our product in this category? Here are  five competitors in that category. How does our security model and our security features stack up against theirs and we'll do some analysis and some matrices and then say, okay, yes, here are actually things that they're doing that we're not, and here are things we can add that they don't have, and then use those again to garner security differentiation and, and and, and kind of use that as a carrot, right.

And say, okay, this is a reason why you want to choose Axway because we have, you know, enhanced controls around privacy or enhanced controls around encryption and and, and use those kinds of features as your leadings. And so , you know, that's a, that's a big aspect of it and a big... No, interesting , you know, the white papers and blogs and making assets like that available to describe, okay you know, we have these advanced data protection controls. Now, how do I put that into a white paper. How do I put that into a webcast or an event like that? 

Rahul - So multiple hats. There are multiple hats that a product security head needs to wear these days, right. It's  not just looking inward, it's looking outward.

It's, it's external interactions, internal interactions. So it's pretty interesting  And, that's the reason I knew that I could, you know, throw that question out at you because I know somewhere in there you'd have those hats that you wearing, 

Brian - yeah... [pause]

And reflecting on probably a conversation I had today, you know, it's talking to a customer and you talk to sit, you know, sometimes there's that back and forth and emails and you get an email from a salesperson, say, okay, the customer says, I must have X, Y, Z, and it's a security feature,  security control that maybe is not part of your, your base platform.

[And so. ...okay, Mr. Salesperson, let me please have a conversation with this customer. And so, you know, they get that and I said, okay fine. And we set up the call with the customer. And then, now finally, you know, you can imagine a very large security or very large enterprises have huge security departments and a lot can get lost in emails and back and forth.

So,  finally got on the phone with the person from the , from the buyer, from the customer who was the security responsible kind of driving those questions. And then, it was such a different tone when you can get two security people on the phone together to really talk about what it is and getting lost in translation and sales teams spending a lot of cycles saying, we must have this, we must have this.

We must have this because the customer said so, and it's like, well, please just let me have a, you know, conversation with the customer. And then when we talked through it,  I said, well, here's what you're asking for and I know why you're asking for it. I don't do exactly what you asked for, but here are five things we do, which satisfies the need for that control.

If I do that and if I can demonstrate that we're doing that for you, will that meet your requirement? And they said, absolutely yes. That sounds, that sounds like it would meet our requirements. You know, please, please show us that, demonstrate us that and it will be great. And so, I think, again having that confidence to step in and not, you know, listen to, well, sales said I need this or the customer said I need this, you're having that confidence to say, reach out and say, okay, let's actually get on the phone, get face-to-face with the customer and find out why are they asking for this. And either, you know, maybe it is absolutely a must have and okay, now we're going to go build it. But now, we know we're building it because we understand the use case.

We understand the buyer's problem. We understand what they're trying to accomplish. And now, we can justify the engineering resources to go and build it versus building something because somebody said so, but they didn't really understand the use case. And so, you know, as a, as a, as a gatekeeper, I think, you know, that's really helping the customer. That's helping sales and that's helping engineering, so that they are not building security features or fixing security issues that really, maybe, don't have to be fixed and, you know, really saving everyone's time so they can go work on things more important. And, I think that's also, you know, throughout the program, right what you want to do is make people focus on the value and not just fixing things because some tool or some things that, Oh, we, we have to fix it just to, you know, check a box. 

Rahul - Great! Great! I think we are way past what we thought we are going to, but it was very, it was great. I think I had a lot of fun.

And then I knew some of these things, like I said, we've never had the opportunity to kind of talk about some of these things. So not just for the people who are listening and seeing this, but for me personally, I think I've enjoyed it. Kind of getting deeper into some of these things that I always want to chat.

So thank you all. Thank you. Once again, Brian, for taking the time to chat with us. I know this has been long planned, but I'm glad, I'm glad we could do this finally. And look forward to kind of catching with you once again, one of these days. 

Brian - Yeah, likewise. And yeah, I'm not sure how long we went there. I hope , I hope it didn't get too long, but now. 

Rahul - No, you're absolutely interesting.  Great conversation. I enjoyed it. And it was great,of course, catching up with you and getting to share some of this finally since we've been working together for a while, but had a chance to sit down like this. So I really enjoyed it and thanks for setting it up and best of luck to you guys.

And we'll talk to you soon. 

Rahul - Thank you so much. Take care. 

Brian - Thank you.