EP#19 – Jim Manico – Why Application Security is a Team Sport and How Your Team Will Win

If you’re a business leader, especially at a SaaS firm or if you’re a developer at a SaaS firm, this episode with Jim Manico will provide a ton of value. 

You’ll hear practical advice on how to approach application security that even the most technically un-savvy listeners can understand.

Jim Manico is an application security powerhouse. He is the Founder of an application security training company, Manicode Security, is a major contributor to a number of OWASP projects, and he has a really great passionate approach to his work. 

What we talked about:

• ASVS 101
• Where should you start when addressing your security needs?
• Comprehensive tips and advice for application security business leaders

To hear this episode, and many more like it, you can subscribe to The Virtual CISO Podcast here.

If you don’t use Apple Podcasts, you can find all our episodes here.

Time-Stamped Transcript

This transcript was generated primarily by an automated voice recognition tool. Although the accuracy of the tool is 99% effective you may find some small discrepancies between the written content and the native audio file.

John Verry:                        Hey there. And welcome to another episode of The Virtual CISO Podcast. I’m your host, John Verry, [00:00:30] and with me as always the Hutch to my Starsky, Jeremy Sporn. Hey Jeremy.

Jeremy Sporn:                   Hey there a partner.

John Verry:                        So one thing you probably don’t know is that Hutch had a number one hit single, David Soul had a number one hit single at one point, called Don’t Give Up on Us Baby. So maybe that’s appropriate to the people listening to this podcast.

Jeremy Sporn:                   Thank you. This has been John and his useless factoid moment of the episode.

John Verry:                        [00:01:00] Well, I will tell you they better not give up on us on this podcast because this one was great. What did you think about my conversation with Jim?

Jeremy Sporn:                   I’ll be honest. I was impressed with you. I don’t like to give you too many compliments, because it just goes right to your head, as we all know, but you kept up with Jim and he is a big personality with a crazy accomplished resume. I was nervous for you, but you held up your end on this one.

John Verry:                        I was a little bit nervous myself. I’ve seen Jim speak publicly and [00:01:30] I’ve heard him on someone else’s podcast where he wrecked a couple of people that challenged him on something. So yeah, it was a lot of fun. People say that I get excited when I talk about security. I don’t hold a candle to Jim.

Jeremy Sporn:                   Not even a little. He is an application security powerhouse, which is so cool about him. He’s got this great business sense. He founded and runs his own application security training company, Manicode and is a major contributor to a number of OWASP projects. We [00:02:00] love OWASP here. His understanding of how to bring application security concepts to developers and in a way they can appreciate and at the same time, bring application security concepts to business leaders in a way they can understand is what makes him special. Application security is both a technical and business risk. Jim really, really gets how this works.

John Verry:                        Yeah. I thought getting his perspective on how to optimally build staff and educate a team to develop [00:02:30] applications that are secure, it was a blast, a lot of fun for me.

Jeremy Sporn:                   Very cool. So if you are a business leader, especially at a SaaS firm or a developer at a SaaS firm, this conversation will just bring a ton of value. You’ll hear practical advice on how to approach application security that even the most technically un-savvy savvy listeners like myself can understand.

John Verry:                        Enjoy the show. This one’s a doozy. Jim, thank you for joining me. How are you today?

Jim Manico:                       I’m doing good. How are you [00:03:00] doing Mr. Verry?

John Verry:                        I am doing excellent. So we always like to get people up on a good foot start, super simple. So give us a… Tell us a little bit about who you are and what is it that you do.

Jim Manico:                       Thank you, sir. John, I’m Jim Monaco. I’m the founder of Manicode security. Our primary focus is secure coding education. We teach developers to write secure code. I’m also an OWASP volunteer. I’m a real big fan of OWASP and a member of OWASP for over a decade and participate [00:03:30] in several projects. So application security education is my thing, sir.

John Verry:                        Yeah. I think Jim, for the record, under-promoted his involvement at OWASP. He does the ASVS. He does number of the cheat sheets. He does the top 10 proactive controls. So Jim is a heavyweight and the application security world. You guys who have listened to the podcast, know how much I love OWASP. So I’m excited to have Jim onboard today. Jim, we always like to personalize things, get to know you a little bit, kind of get everyone to know a little bit about you. So we have [00:04:00] a tradition. What’s your drink of choice?

Jim Manico:                       You know what? I think that the taste of almost every alcoholic beverage is foul and disgusting, but John, sometimes I feel the desire to get a little inebriated. So I prefer a couple of shots of vodka to get the disgusting taste of alcohol out of my mouth. What I prefer to drink is fresh fruit juices, maybe occasional diet Coke, some really good Mountain Valley, spring water, high quality water in glass, John. Not this aluminum crap, John. Glass bottled water [00:04:30] is what I like to drink. I drink liquids all day long. So anyways.

John Verry:                        So it sounds to me like you and I could probably have another conversation because I’m a junky health fanatic and health podcast. It sounds to me like from the fact that you’re limiting stuff to glass bottles and the way that you eat and drink, it sounds like you’re in the same boat.

Jim Manico:                       Yeah. I’m with you. I can taste aluminum in my aluminum drinks. I like the glass myself.

John Verry:                        Yeah. And that probably will save you from getting Alzheimer’s some day, right?

Jim Manico:                       Exactly. I’ve seen the research on that. It’s debatable. But I don’t want to risk it. I [00:05:00] like my brain.

John Verry:                        I hear you. Yeah. That’s your moneymaker, right?

Jim Manico:                       That’s the moneymaker.

John Verry:                        And now for me, you can see the moneymaker, anyway. Face made for radio, for audio podcasting. The reason why we wanted to have you on, Jim is that a lot of the folks that are governing application security efforts, scrum masters, software engineering managers, small business owners, I think they’re increasingly aware of all the great forms of guidance that are out there, but I [00:05:30] don’t know that they know how to stitch all those pieces together effectively. So I was hoping based on your deep expertise, across multiple languages and multiple OWASP efforts and things of that nature, that you’d be able to give us some guidance. So I’ll start with a simple question is, you and I are both huge fans of the Application Security Verification Standard. We use it a lot on the assessment side.

                                             I know that you promote its use on the development side. You’ve got a lot of great, but what I’ll call deep or really nuanced requirements in there, what does [00:06:00] it take for a developer to really leverage the guidance that you’re providing?

Jim Manico:                       That’s a really good question. I want to start by answering it real surgically and then pop out and get back to that answer. It’s an odd answer. If you look at the Automotive Linux Group studies on secure coding, they said that the single most important factor regarding whether or not your project will be successful from a security point of view, it’s one factor. Whether or not you have a skilled expert in secure coding, embedded with your team. [00:06:30] Without that, security is just not going to happen. And with that, you have a good chance of getting there.

                                             So my answer is ASVS is really a pointer to deeper knowledge, right? It’s a brief requirement that points to something that’s much more complex and nuance. So your best bet is, in the team you’re working with have a security leader, security champion, working with developers to help explain these requirements and how they apply. I’m going to give you a couple other answers to this. This is a complex question, even though it’s simple. [00:07:00] The other thing is, before you give requirements to developers, hopefully your company and team forks the standard.

                                             I rarely think you should use the standard out of the box. So the standard is like a template to fork it with your team, to make it more relevant to the work that you’re doing. For example, I don’t build authentication systems anymore, John. I use identity providers. So I drop all those identity provider quest, all those authentication quest requirements and I convert those to a couple of requirements on how to implement the identity [00:07:30] provider. I’m going to answer it in a different way. If you’re on your own as a developer, then I would read the OWASP cheat sheet series, which is like a living encyclopedia on secure coding knowledge.

                                             So the ASVS is like a one sentence or two sentence requirement. The OWASP cheat sheet series is a detailed explanation of how to handle those requirements from a secure coding point of view. One last one, John, then you could look at the OWASP testing guide, which will help [00:08:00] explain how to test for these security issues that you see in the ASVS. ASVS by itself is not effective. You need that support system around it. Absolutely.

John Verry:                        Right. How do you think that ties into… And again, this is exactly what I wanted you on is that there are so many of these great components, but I think I literally had a software engineering manager. We were having a conversation on OWASP and frankly, I didn’t even blend in the cheat sheets because I’m embarrassed to admit, I don’t know much about them. So you just gave me some homework to do. Thank you. But he said, his quote to me was, “So now I [00:08:30] have a pretty good idea of all the pieces I need to consider. Just not sure how I’d put them all together into a cohesive whole.” Now you also have the other process. If you don’t have a… In my opinion, at least, you might feel different, but if you don’t have a solid systems development, security development life cycle methodology, I also don’t think you have what you need. Right? So how do the pieces that you’re talking about dovetail into there? And again, your expertise is in education. Where does education fit into those pieces and how you would prioritize putting [00:09:00] them together?

Jim Manico:                       The question is… I’m not sure I got the question right. The question is, how do we take all these varied components and pieces of an application security program and start implementing them as a whole effectively and where do I start and-

John Verry:                        Exactly. How would you… So if you showed up somewhere where a 50 person, whether we’re insourcing or outsourcing it, fundamental agile shop, now you’re like, okay. And you say, “Well, how do you guys develop code?” We don’t have a process. All right. I got to put a process in place. [00:09:30] How would you manage that? How would you kind of begin to architect what that would look like, what guidance you would give the developers, what training you would or wouldn’t? How you would implement the… What tools you might use as part of that process. Talk about building that security program for secure application development.

Jim Manico:                       The first thing I would do is work with the main stake holder and take a look at OpenSAMM and BSIMM. OpenSAMM is a high level view of all the different components that you should be delivering in an application security program. For each [00:10:00] thing you should do static analysis or design review. They’ll have several different suggestions of how to mature that capability. Also, how to measure that capability and be same as… Frankly, as a much more detailed version of that.

John Verry:                        Yeah, that’s the fork. That’s a fork of SAMM. Right? From Gary McGraw. In a different direction.

Jim Manico:                       That’s an early… OpenSAMM and BSIMM, and I think they’re both very good relevant projects.

John Verry:                        Okay.

Jim Manico:                       They do slightly different things, but it’s a way to measure how an organization does application security. [00:10:30] So I would look all these ideas and say, “Hey, stakeholder, here’s all the things you should be doing, which of these are you doing?” And we get a baseline of what they are and aren’t doing and start working on increasing those little by little. Now let’s get more detailed. If I was beginning a program that was just not doing anything, I want to get a real basic idea of what’s going on.

                                             So I actually may start with something like a pen test, primarily not to identify the bugs, just to bring awareness to the leadership and stakeholders, “We have critical bugs [00:11:00] in our software. Yes, we should go fix them.” But for folks who are, who don’t really have a program, we got to show them that there really are programs, do proof of concepts to show them, exploiting your software and prove that this is not a game and this is really… It’s not a game, but it’s not a theoretical issue, but there are real issues in your software.

                                             Also, some companies have incidents where they are compromised in some way that forces them to care about this. So I either want to demonstrate that it’s real or help [00:11:30] them handle a post compromise event. Now they’re ready to take this seriously. A good first few things to do. I think again, a pen test is a good idea to-

John Verry:                        Yeah. Just real quick for you there. Because, I like what you said. I know this is going to sound funny, but in the internal auditors handbook, right? I come from an audit realm. They actually refer to one of the good use of a pen test is to “shock management to action”. So I love the way that you’re looking at that. Because you move it from the esoteric like, “Oh, you might have vulnerabilities.” [00:12:00] To, “This is what could happen to you if we don’t take an appropriate action.” Right. You could have a breach notification for 50,000 identities add $200 per name. Suddenly you’ve got management’s attention, right? You have the money and the support that you need to affect change. Correct?

Jim Manico:                       You hit the nail on the head. I go back over a decade. I know there’s one organization, a big, very big multi-billion dollar company. That’s a bit primarily a web app. And I was like, “Hey, there’s reflective X assess in your login page.” This is many years ago. And they were like, “Who cares?” I’m like, “Well, [00:12:30] pay for my ticket and I’ll show you how to compromise your sizzles password.” They’re like, “All right, you got our interest. We’ll give you a ticket.” So they sent this, flew me out. I sent the link to the… In a contrived situation. I put my laptop up on screens, see my server logs, tailing. I sent a leak link to the sizzle and said, “Go ahead, log in. Don’t get me a real password though.”

                                             So he liked it. So I sent him a link. He pops it. It’s his login page with the reflective excesses key logger on it. So he starts logging in and live on my screen. I [00:13:00] go, “Add a J-J-J-J. Yeah, keep going.” He starts typing as he’s typing in live it’s showing up on my screen. And I’m like, “Go ahead, give us your password. Don’t give me the real one though.” Then he starts writing his password, “Okay, Jim. You bastard, I believe.” I’m like, “All right.” So it’s like, once again, theory is nice, but early stage, I want to show a proof of concept. By the way, John, if I’m late stage AppSec, and I still have to prove proof of concepts to get to take action, we have a major problem. This is only… [00:13:30] The whole proof of concept, live examples of hacking pen testing, where I’m doing really, really broad pen testing. So I can demonstrate vulnerabilities. I shouldn’t have to do that as my program matures. This is the other-

John Verry:                        That should be certification accreditation of the system and operation at the end, perhaps, but it has no other place in there. One last question, when you were doing that pen test, in your mind, would that be an ASVS level one? Would that be just a full dynamic application following OWASP top [00:14:00] 10? What would be your flavor there?

Jim Manico:                       I would do a light pen test. Just do initial-

John Verry:                        Just enough to know.

Jim Manico:                       But based on the size of the app, I would do a modest level scope based on the size of the app, just so I can get some initial, real critical bugs, see how big the problem is.

John Verry:                        Got you.

Jim Manico:                       Management’s now bought into some degree. Probably the first tool I get in place is a mature static analysis tool. I’d probably go commercial. Like Ruby on Rails, I’ll go break them in and hit for specialty stuff. There are a few open-source, but for [00:14:30] the most part, I got to go commercial for static analysis. That’s the earliest tool I get into place. I really try to find a static analysis engine that was specific to my language and framework. So I go through a bake off with different vendors and vendors don’t want to play, wouldn’t consider them, and go through a bake off, so I can find a static analysis engine that I can use on a day-to-day basis. That’s really effective for my particular language and framework. That’s the flirts tool, I-

John Verry:                        Right. That’s the key, right? Because [00:15:00] the different tools work very well for certain languages and not for others.

Jim Manico:                       Absolutely. There’s giant lack of overlap between application security tools. So I’d find the right and I’d meet even put a few static analysis tools in place over time. The other thing to do is I want-

John Verry:                        Can I ask you one quick question on the static analysis tools? Do you favor those that you’re looking at the raw source or there are some that are looking at the binaries. So Vericode, obviously being the most famous of the [00:15:30] compiled code analysis. What’s your recommendation there? Would seem to me that the ones that are looking at the direct source or better, but you’d know better than me.

Jim Manico:                       I’m going back to my… There’s a lot of vendors, right? There’s Vericode, there’s Fortify, there’s open-source like Brakeman. There’s Brakeman Pro, there’s Coverity and there’s a lot of new-

John Verry:                        Check marks.

Jim Manico:                       There’s check marks. There’s a lot of new vendors in this space as well. I think they’re all valid to some degree. So what I recommend [00:16:00] is, do a bake-off for your particular situation, right? I think it’s compelling that their code does binary analysis, but I really want to get to the source code, so I use the binary analysis type of technologies, really, for things that I don’t own the source-

John Verry:                        That you don’t own the source, right. Yeah. A DLL that allows you to analyze what’s in there a little-

Jim Manico:                       There’s a wired magazine article that talked about, “Up and new technology. We review source code.” And Chris Weiser Paul jumps in like, “Yeah, we’ve been doing binary analysis for [00:16:30] like 20 years, this wired up magazine article talks about it like it’s this new thing.” But I gave Weiser Paul credit. He’s been doing it for two decades. I salute you, sir. It’s a long time to be schilling AppSec analysis and he’s still enthusiastic about it. But again, I think all the vendors out there, because there’s a lot of reasons why you’d want to use static analysis and how you would implement it. You may want to do an integrated into GitHub.

                                             You may want to be able to hand it to a third. There’s so many [00:17:00] different use cases. I go through a vetting process and a lot of different bake-offs and get something in place that’s running on a daily basis. That’s a really good use of time and resources for early stage AppSec, I would dare say. One more thing too. I also want to get developers educated. I preferred live training. I’m so certain that’s what I do for a living, but there’s a lot of other vendors besides me. Having an effective educator, teach developers about the basics of web or application security [00:17:30] as narrow to their framework and language as possible is very useful to facilitate other conversations. But it’s going to start but keep in mind as management, when you don’t have process in place, you don’t have standards in place and you don’t have like an AppSec SDLC in place, and you bring a trainer in, that’s like the wild wild West. It now becomes like security is a grassroots effort that really doesn’t work.

                                             So you have to train developers, but alongside [00:18:00] of that should be an analysis and polishing of a lot of other processes. Like, how do you do bug triage? What are your SLAs to fix bugs? What additional security testing are you going to put in place? What kind of design review should happen? What kind of programming languages are you using? Can we condense some of that? There’s so many-

John Verry:                        Third party library usage.

Jim Manico:                       Third party.

John Verry:                        Put the integrations. Yeah. I mean, because there’s nothing that’s not integrating with an API anymore, right?

Jim Manico:                       [00:18:30] Here’s another weird thing. One of the big eCommerce players, I want to mention their name, but a big eCommerce player. They were kind of lazy under third party library world. They got it working. They did security testing, but they were very lax in updating to third party libraries. Then they realized the scope of the problem is really big now and they were actually able to have their testers more and more find real-world security bugs because of old third party libraries they were using. Because they were like, “They’re not really exploitable.” As they spent [00:19:00] years not doing it, it became exploitable. So they made a decision, “We’re going to fix this problem.” And for a year, half of their developers were just doing third-party library updating.

                                             The point I’m trying to make is John, sometimes a legacy dead, there’s no cheap way to fix it. You’re like, “Well, what’s the quick solution.?” The answer is, there is none. You either rebuild it or you sweat blood and tears, retrofit security. It’s just massively expensive. Good luck with that. [00:19:30] It’ a [crosstalk 00:19:31] answer but that’s the answer.

John Verry:                        But I actually think it’s a good answer. Years ago and I think I mentioned to an email, I got up at a programming full time when my last project was active server pages in the beta version of [crosstalk 00:19:46]. So it tells you, it was a while ago. But I was kind of a believer, even in the short time, I was a programmer that after five years of coding applications are so much different than they originally [00:20:00] started. You’d almost be better off starting with a fresh code. I mean, start fresh, right? Re-looking at the application and kind of putting it back together. As security changes, you kind of have the same ideas. Are you an advocate of every periodic period of time? Re-looking at the application architecture and saying, “Should we be recoding pieces of this?”

Jim Manico:                       I’ll take it up a further notch. I was talking to an application architect of a large bank, one of the top 20 banks in the world. [00:20:30] I’m like, “What is the architecture of the software robotization?” He’s like, ” Yeah. I’ve been studying that for 10 years.” What architecture do we use at this bank? That’s a great question, Jim. I’m like, “Well, what is it?” And he’s like, “I have no idea.” I’m like, “Wait a second. You spent the last 10 years saying you’ve been studying the bank’s architecture. If there’s other critical software, you have no idea what it is.” He’s like, “That’s exactly what my answer is.” I’m like, “Why? Why don’t I send your answer?” He’s like, “Well, the architecture of our software is in flux at all times. There’s no way for me [00:21:00] to analyze it. “

                                             So the more complicated your software is, the more that architecture should be, was going to be in flux at all times. If you have… I think the real question you’re asking is, “What about legacy software, Jim?” Once you’re using a framework that is no longer updatable or doesn’t have like a lot of active maintenance on it, or it’s just, even though it has very little updates, it’s known to be a legacy framework. Should you consider rewriting big portions of that software? [00:21:30] John, that’s a big money question, right? You’re growing the dice now with sometimes millions of dollars. And the reality is, I don’t have an answer for you. There’s not a good answer, but here’s a-

John Verry:                        No, that’s actually a perfect answer, right? What you’re basically saying, look at the end of the day application security is business security. Is application security risk is business risk. If the risk associated with… If the business risk is greater than or equal to the cost [00:22:00] of redeveloping the application, then the answer is it makes sense to do, right? But I mean, that’s not purely a developer’s decision, obviously. Right.

Jim Manico:                       Exactly. I would say this. When you have legacy software, I want to onboard them into my automated security testing mechanism. So if you have legacy software and you’re checking it with dynamic analysis, static analysis and third party library scanning on a daily basis, as new rules are into those tools. And we start seeing bugs and legacy software, let’s start addressing it. But if we [00:22:30] have remediated bugs and legacy software and we keep maintaining it and updating libraries, I mean, that’s a compelling argument not to lessen the need, but if you’re onboarding legacy software with security testing and it starting to light up with problems, there’s a good indication to handle that in some way.

John Verry:                        Got you. All right. So going back to the… You were architecting for me, you were in this fictional company that you were kind of putting things together. So we got that SDLC [00:23:00] in there, the static source code analysis tool is definitely one of the early things you’re doing. As you start to bring in other forms of good guidance, are you doing that… Are you using the SDLC as the mechanism to find other forms of guidance that plug into that? So, as an example, where does that ASVS plug into that process? Where do the cheat sheets plug into that process, from your perspective?

Jim Manico:                       I’m a big fan of security touch points and not SDLC. It’s a nuanced answer, but a lot of people claim to do agile. They’re not [00:23:30] agile at all. Claim to do waterfall, but they’re actually doing spiral. And so I’ve rarely seen folks do a real SDLC of any kind. And I don’t mind. So what I’d rather do is take what I think are key SDLC things that must be done and integrates keys in some way. I want standards and requirements super early on. I want to publish at least what my basic SDLC requirements are early on. I want to do threat modeling and design analysis early [00:24:00] on. I want to be able to as early as I can, have a prep phase before developers start coding, right?

                                             The point is that without like the dev ops CICD, without knowing my security frameworks and libraries, without having my developers with at least basic security training and without preparing to do security testing, like being aware, we’re going to start doing third party library testing as soon as you start writing code. We’re going to start doing static analysis as soon as you start writing code. The moment [00:24:30] we have a dev server up, we’re going to do a pen test every six months on top of the automated testing and service level agreements to fix those bugs as they’re discovered. John, you fix bugs, or you don’t fix security bugs, John.

                                             I’m sick and tired of all these conversations about why we shouldn’t fix bugs, stop it, fix your security bugs, fix them everybody. So we should establish that in the culture early on that we got sequel injection SLA 24 [00:25:00] hours, get your act together. That’s hard. So without that, I’m going to struggle to get developers to care about it. So the point is I want to have developers prepared for a security world before they write code. Security automation testing, SLAs to handle testing, my at least the basic training and the understanding of the libraries and frameworks they should use around security. For example, if we have to do key management as part of our crypto solution, let’s not [00:25:30] ad hoc slap that together in the project, let’s build a solution for it that developers can leverage well.

John Verry:                        It makes total sense. One of the things that was interesting is I’ve heard you actually speak negatively prior on threat modeling, I thought. But yet you just put threat modeling into the early part of that. So where do you stand on threat modeling? Because I know I’ve heard you say some things about it either not being effective or most people don’t do it well, or I remember listening to you speak somewhere and I remember thinking to myself, “If I ever got a chance to talk to [00:26:00] Jim, I got to ask him about threat modeling.”

Jim Manico:                       If you’re threat modeling low level technical bugs, you’re wasting everybody’s time. That’s the point I’m trying to make. I want to reserve threat modeling for design issues, business logic and tiered architecture interaction, microservice interaction, complicated workflows, things that a static analysis engine is not going to pick up. The point I’m trying to make. As soon as the static analysis picks up a technical bug that is reasonable in terms of time to fix and your threat [00:26:30] modeling that, you’re missing the point of threat modeling. So technical bugs should be fixed and threat modeling should be reserved for design and more complicated issues that can’t beat, that are not common to everyone software and can’t be discovered by technical analysis tools.

John Verry:                        Got you. Yeah. So the bigger stuff are architectural. The way things are plugged together, the way things are segmented, the way we authenticate third party services, things of that nature?

Jim Manico:                       Exactly. I said this on Twitter a couple [00:27:00] of years ago, I was saying if you’re threat modeling sequel injection, you’re wasting everyone’s time. One of my good friends, Tony UV, he was in a threat modeling meeting, discussing sequel injection as that came out and went viral. So I just want to give you the other side of that coin from Tony UV. He’s like, “Hey Jim, if this company is really new at application security, they don’t really understand sequel injection doing a couple threat models on sequel injection helps me educate.” So I don’t call that real threat modeling, though I’d [00:27:30] call it-

John Verry:                        That’s education.

Jim Manico:                       Education at that point.

John Verry:                        I love Andrew van der Stock said to me when I was trying to understand how he viewed the difference, because he participates on ASPSN top 10. Said, “How do you differentiate the two?” His comment was, “The ASVs has a list of things to do. The top 10 is a list of things you should be aware of not doing.” Right. It’s an awareness piece. So if they’re not aware of the concept of sequel, first, I would say they shouldn’t be coding, but if they still are coding, I would argue Tony’s concept [00:28:00] is right, right? If they don’t know that much yet, start pretty basic.

Jim Manico:                       If you’re coding where coders are pushing insecure code lives and that’s not the coders problem, that’s your business problem. It’s not like you fire the code or because they’re writing sequel injection, no, it’s the C levels who sign off on risk who get penalized for this. So as soon as I see a developer checking in sequel injection that goes live, that’s the CTO and the CISOs fault, 100%. That’s a harsh thing to say, but we need to take responsibility [00:28:30] at the higher level to get this stuff done. Right?

John Verry:                        You couldn’t have mentioned that at a better time. Because the next question that I had for you was, you’ve talked about training developers, but I know that you actually offer courses on training for I’ll call it security managers or a software engineer or whatever. How does the education and how does the tool set that a manager, someone who’s responsible, a CISO, someone who’s an application security lead, whatever it might be, how is their training and the tools that they’re going to use out of that tool set a little bit different?

Jim Manico:                       [00:29:00] Well, first of all, John, the reason I teach is I just love to talk. I love the melodious sound of my own voice, right? So that-

John Verry:                        I share that same thought. This podcast may never end.

Jim Manico:                       Yeah, exactly.

John Verry:                        Just to let you know.

Jim Manico:                       Managers never let me talk. I’ll say like two sentences then 20 managers debate those two sentences. Then I’ll say a paragraph, and 20 managers debate my paragraph. So the thing that I learned about teaching managers is they just love to talk. And if I interrupt them, they get really mad [00:29:30] and if I… I remember one class, I swear this pack of lawyers from a big software company hired me to discuss legal issues and contracts and advocates security. This is my favorite engagement, was a four hour management talk.

                                             They made me wear a suit. I charged them double for that. So big, big money for four hour talk. I show up and I talk a little bit and they start talking for two hours. Every few minutes, “Are you okay, Jim?” I’m like, “No, it’s an important conversation.” I keep nodding. So I literally set up there talking heads, had a few things, had a few move into the conversation, [00:30:00] listen to them talk for three and a half hours, got a few words in. They were like, “That was the best advisory ever.” I walked out, I [inaudible 00:30:07] and I was like, “You guys are nuts.” So anyways.

John Verry:                        We probably have 60 major law firms as clients, so I spent a lot of time. So yeah, I’ve been in those meetings where you start to debate just how you’re going to define a particular data classification and four hours later, 23 lawyers are… They’re off doing research [00:30:30] before you can get the policy written.

Jim Manico:                       But honestly, the thing I want to do is in manager classes, get the managers talking, seriously. So I will set up labs to get them debating how to handle these things. I usually teach to software development managers, I teach them secure SDLC and just walk through what an ideal secure process would look like. So they can critique their own processes along the way. That usually is very effective, right? I like to do some demo. Managers love demos. So I show them… [00:31:00] Talking about SQL injection, technically I’ll lose a lot of the audience if I carefully demonstrate stealing or other attacks with sequel injection and show them that in a good way that they get excited.

                                             I’ll even set up labs where I’ll hack with the managers just a little bit and they feel real empowered and excited. So a little bit of demonstration for those who are new at this, and then a discussion less of the technical issues and more of the secure SDLC, so we can debate their own process [00:31:30] decisions. I’ll usually end up with end up with one small technical topic just so we can go deep on one thing that’s relevant to the audience. And I’m usually out. The SDLC talk when I give it to developers, it’s usually a one hour talk and they rarely ask questions. Developers don’t care about process. I give that same talk to a manager, same exact one hour talk and it always stretches out for like four hours, which is more than enough for managers.

                                             That’s the other thing I don’t want to do like a multi-day training for managers, they got work to do. So I try to make it brief [00:32:00] to the point, no BS, demo SDLC, one technical deep dive and then make myself available for further questions. And they’re usually very happy with that kind of manager class for AppSec.

John Verry:                        Got you. Do you give any guidance or advice, if you will? One of the things that I see is that developers are so… The information asymmetry about the development process is so high that I think it can be hard sometimes if you’re not a former developer or even a [00:32:30] recent former developer to have a conversation these days, right? Because especially as we’ve gone to agile and CICD and pipelines and Kubernetes, and 58 functions from Amazon that you can’t keep track of, I think it’s harder for a manager now to go and have a conversation with the development team, any tricks of the trade there to kind of help them manage people when they’re talking a language that very often is one that the manager might not quite be fully familiar with?

Jim Manico:                       This is a hard question for me and my answer may not be satisfactory. [00:33:00] But my take on it is what I have a big organization, and I need to manage software development teams and application security efforts, I need managers who have… Or software development managers, right? If I take a CISO or a CTO with a primarily infrastructure background, it’s really hard for them to be effective at managing software development efforts. So as a CISO, suppose I was a traditional security CISO, well known, good at my job, have some experience [00:33:30] hiring for AppSec and I know the first thing I would do is hire my internal CISO to handle all my AppSec efforts, who actually has a background in software development. Because honestly, without a background in software development, it’s hard to be effective.

                                             I don’t mean that to be mean, or to alienate any CISO out there who don’t have a software development background. But part of our job as a CISO is not to do everything, but to hire a team, to help handle these issues, especially if it’s a much larger [00:34:00] company. Now, if it’s a smaller company, John, without-

John Verry:                        That’s where you see it a lot, right? You get these companies that are 20 people, they have this great idea, they’re outsourcing development to Romania or Philippines or wherever and the guy that’s leading the development is a guy like me, maybe did some software development in the background. He’s got a good security background, but I mean, he’s challenged to actually have these meaningful conversations and ensure that he knows that they’re doing the right thing. I mean, it might be an unfixable problem, but if someone had [00:34:30] an answer, it would probably be you.

Jim Manico:                       The big question is how do you do low-resourced AppSec, right? How do you do AppSec… So first of all, I’d be real precise about what framework I’m picking. So if I have a small team and I’m trying to build a web app or API, right? And I want to do security with modest resources, then I’d try to pick probably one of the more turnkey frameworks out there. Anyone that knows me and what I think of programming languages, it’s going to hurt me to say this, but if I had a small [00:35:00] team and I’m doing web or API development, and I don’t have a lot of resources for security, I’d probably pick a new version of Ruby on Rails use Brakeman for my static analysis engine, which is open-source and I’m off and running.

                                             Those of you… And I hate Ruby on Rails, it’s horrific, but from a developer point of view, it’s pretty rigorous from a security point of view. As long as I have third party library scanning and have the framework update on a regular basis, guys a lot of really built in controls [00:35:30] done, right? Where if I took a really old Java framework, building security on top that, is a significant effort. That’s my best answer is, be really precise in what framework you have.

                                             Now, if you have a small team with a giant piece of software legacy, with tons of bugs and no budget to fix it, yeah you’re starting to get in the area of intractable problems, right. Or really expensive problems to handle. [00:36:00] But if you’re a small team and you can pick a greenfield framework, I go for something like rails with a lot of built-in security and try to do my best to keep it up to date as best I can.

John Verry:                        What if we on top of that, also gave the person. Look, I’m a big believer in kind of beginning with the end in mind. What if I gave someone ASVS level one guidance, ASVS level two guidance and said, “Look, I don’t know enough to manage you, but at the end of the process, I’m going to test you using this criteria. So I want [00:36:30] you to pass this test at the end of this, or I’m not going to pay you or you’re going to get fired, or we’re going to have to come to [inaudible 00:36:35].” Is that part of that conversation maybe? A way to cheat?

Jim Manico:                       Absolutely, absolutely. Here’s what I would do to augment that. Let’s go back to my original conjecture in this podcast was you want to have an AppSec expert embedded with your team. So if you hire an AppSec expert, that’s super expensive. But if you hand ASVs you do a little forking with [00:37:00] them, let them modify some of it and they understand some of it. Go hire a consultant to be a mentor, say, “Hey AppSec, smart guy. Can I hire you for like 15 hours a month as a retainer? And can you answer emails from my guy to help mentor him on understanding ASVS items?” Now you’ve got a consultant for a real, for just a-

John Verry:                        That’s actually a good idea. Sort of like we’re getting into the virtual CISO world, the virtual data privacy officer world. Yeah. Virtual security, software security lead.

Jim Manico:                       Exactly. Get a virtual software security [00:37:30] lead, so you have that technical expert embedded. Offer them retainers, are really nice for contractors. Contractors often don’t want to have that loosey-goosey mentor role. But if it’s a retainer, that means you’re not messing around. You really want their support. They’ll be a lot more inclined to do that mentorship well, take it seriously. You find the right AppSec and maybe a high rate, but it’s only for X number of hours.

John Verry:                        That’s exact right. It’s the same idea as a virtual CISO. You need that expertise, but you only [00:38:00] need it for such short amounts of time-

Jim Manico:                       Exactly.

John Verry:                        Yeah. So pay for it, by the job. So I only expect a 10% finder’s fee on all of the future revenue you generate from your virtual software security lead company, going forward, Jim. Just letting you know that now.

Jim Manico:                       10, everyone heard it. Verbal contract. 10 point.

John Verry:                        I should have bargained for more. You’re telling me that.

Jim Manico:                       That’s what I do. I do a lot of like reselling of other expert’s trainings and services these days. And it’s like, it’s a good part of my business now. I make sure I vet. These are people [00:38:30] I know have known for a decade, but I usually ask for 10 points. I think businesses important. Everybody wants to make money, a 10% finder’s fee for a turnkey, for turnkey gig is a gift.

John Verry:                        Yeah.

Jim Manico:                       It’s not greedy. 10% is not greedy. I like that.

John Verry:                        No. And having a guy like you available to people, I mean, you’re talking about for a critical business application. I mean, it’s millions of dollars worth of the risk that solved for hundreds of dollars. To [00:39:00] me, it’s a no brainer.

Jim Manico:                       Honestly John, I’m not selling, I’m not trying to sell my services. I’d rather you find an AppSec expert in your region specific to your framework, a little digging and you can find that person. And so I’m not sure… Because I’m a generalist educator, getting old going into managing big teams of trainers is more and more my bag these days. So this is not… So just find the right AppSec expert close to your language and framework, retainer as a consultant, [00:39:30] remote. Very powerful technique, if you find the right consultant to help you out.

John Verry:                        All right. So you just led… It’s almost as if you knew my script here, Jim. I was just going to ask you, how much does the guidance and the things that we’ve been discussing to his point change based on let’s start with a different methodology? Whether you talked about waterfall or spiral, talk about agile. Even if we go to Continuous Implementation Continuous Development CICD, continuous deployment, excuse me. Does your guidance at all [00:40:00] change or is it just that it will be extended a little bit to fit the different uniquenesses of those models?

Jim Manico:                       Trying to tell someone how to do SDLC is a very personal thing and it upsets people. So I don’t play that game. I don’t. What I do is I say, I like Gary McGraw’s idea of touchpoints. I’m like, “Here’s a bunch of AppSec activities you really should be doing. Here’s my suggestion of how I would integrate it into traditional SDLC. It’s all you now.” Right? So just by explaining the… Because everyone’s going to integrate [00:40:30] it, a slightly different way. Ask me your question one more time. I want to add a little more nuance to that. Let’s go with that question one more time.

John Verry:                        Sure. So what I wanted to ask you was how does the guidance that we’ve spoken to, to this point changed based on different software development methodology, someone could be using waterfall, spiral, agile, agile CICD?

Jim Manico:                       In the SDLC, the biggest things that I’m concerned with are only really two things. Remember that prep phase we talked about. I want to make sure we understand the major components we’re going to do for [00:41:00] authentication access control, key storage for cryptography. How do we build secure user interfaces? I want that methodology of how upfront as soon as possible for newer projects or if it’s a legacy project, I want to figure out how to fix one problem and do a security sprint for that problem and fix it across the whole app. But number one, I want some security testing put in early on, but I will also want to look for automated security testing.

                                             So let me take a step back, John. Again, I want, I want developers to have [00:41:30] basic understanding of security issues and all the other prep phase stuff before they write code. And second, I want to have automated security testing as much as possible. Now, the how to integrate security testing into an automated pipeline, I think that should be standard for every project, including legacy software. So I tend to hammer in on, are you doing that or not? The question is, how often do you do security testing? [00:42:00] The answer should be a thousand times a day, through automated CICD. When someone’s just doing, “Oh, we do a pen test once every few months.” Or, “We run a scanner, every month or two.” Then I’m going to focus in on that to make it more closer to automated security testing with everything they do on a daily basis. And how to implement automated security testing and the CIC-

John Verry:                        That’s another whole story.

Jim Manico:                       That’s a whole story by itself. That’s not easy to do and it requires lots of experimentation. [00:42:30] So, that’s it. Do you have your prep phase where you write code and do you have automated security testing in place? The rest is usually easy to roll in, but those are the two things I want to hammer on.

John Verry:                        Got you. In terms of that automated security testing, that’s unique to the CICD correct. That’s what you’re referring to it in that frame. So would that imply that you believe that if you can get to a well implemented CICD that, that inherently assuming you do the security [00:43:00] integration, that conceptually is a better approach to creating secure applications than a non-CICD approach.

Jim Manico:                       I think it’s foolish not to do automated security testing every day, it’s just such an easy win. For some things it’s open source, right? Let’s go back to rails. I can get Jenkins up and running, get brakeman as a static analysis engine and have that running every day in a really short amount of time, without a lot of expense. How I tune that static analysis [00:43:30] engine to work inside of a CICD pipeline, that’s something I like to focus in on the team, focus in on really early. And here’s why. So I want every time, especially if it’s a new project, I want the developer to do some kind of static analysis whenever they build code, whenever they are checking code into a repository and pushing it live are the three areas to consider security testing.

                                             Now, if I buy an expensive tool. For other non rails frameworks, I often have to buy a tool, right? And they’re freaking expensive as you know. [00:44:00] When I buy this expensive tool, I put it in a CID’s pipeline, developer tries it out. Then the scan starts running and the scan’s running for a couple hours. Whoa, that doesn’t really work.

John Verry:                        Exactly.

Jim Manico:                       That one is to tune your static analysis engine to run in just a matter of a minute or two. I usually turn off everything, put a few criticals on and then experiment with what I can get away with in under a 62nd window for scan time, maybe I’ll push my build environment to cloud service. So I put a lot of horsepower [00:44:30] behind it, do a much, much more elaborate scan using cloud resources in a short amount of time.

                                             The point is when developer is building, want to build fast. When they’re checking code in, I don’t want them to wait an hour. And when they’re pushing code live, I don’t want to wait an hour. So the CICD pipeline security testing that I usually encourage people to set up is, what can we get away with in under 60 seconds?

John Verry:                        Got you.

Jim Manico:                       A combination of static analysis tuned, maybe running Zack or a similar dynamics tool in a reduced mode and running a [00:45:00] third party library, scanner like Dependency-Check. I want to get those three things running. Somehow every day at one of these three touchpoints of build, check it and deploy. That’s an early activity I’m going to do. Now, John, keep in mind if I’m buying an expense static analysis tool and I just turned off all the rules to make it run fast, well, what’s the point? Well, I’m going to have two pipelines running. I have one running that interacts with developers when they do things and another pipeline [00:45:30] that runs-

John Verry:                        For the security team.

Jim Manico:                       Nights on a daily basis.

John Verry:                        Right.

Jim Manico:                       So those two cycles for good testing automation. I’m encouraging companies to do this in the rest, you’ll see really early on, because a big win with a modest amount of effort, if done right.

John Verry:                        Yeah. I heard a young lady talking about exactly the same issue you’re talking about. She couldn’t agree with you more. One thing that I thought was interesting, she referred to the fact that she encourages her developers to… She used the term fork their [00:46:00] code into almost functional units. So that way, the security testing that’s being run is unique to the code that’s within their control. It’s not impacting. A, it sped up the process. B, in the event that they found something, it was very quick to identify it. They knew it was their problem to fix not somebody else’s. She said that was very effective. And she was an advocate of tuning these tools. So that way it would be very easy for that test result to end up directly in Jira.

Jim Manico:                       [00:46:30] Absolutely. So there’s tuning at the tool level. And sometimes if you’re trying to retrofit legacy app, big legacy apps into CIDC pipelines, sometimes that scan time is super long. So, if I’m working, if I have to actively work on legacy software and I need to keep maintaining that for many years, I may want to break it up into different levels of redesign in part so static analysis is more effective or point static [00:47:00] analysis at limited parts of the code base. So it runs better. This is all part of the tuning process to get under that 62nd or couple minute window of a static analysis engine running on a day in, day in basis.

John Verry:                        Got you.

Jim Manico:                       Sometimes you’ll never get that done effectively. So with big, bulky, giant legacy software, that’s hard to componentize or hard to scan a small part of the app at a time, because it’s so messy, spaghetti code. I’ll do that the full bore scan once a day and third party library [00:47:30] scan once a day for legacy and call it a day.

John Verry:                        Okay. I got you.

Jim Manico:                       Getting these pieces into play are super valuable because it’s reusable it’s not just some pen tests that scared a manager…

John Verry:                        It’s not once a year. It’s not a once a year we check on our app and we’re vulnerable for the 364 days between that. Our field of vulnerability is quite small if it’s done well. Cheers. All right, so you talked about how you would… We talked about languages change things, right? The tools that we select and things of that nature. We talked about the fact that development methodologies [00:48:00] change things a little bit. Does guidance change based on the technology? So if we’re using containers like Kubernetes, if we’re doing a serverless computing with something like Lambda, EC2 how much does the uniqueness of the extended tool-set being used, the deployment methodology, if you will, the deployment location change this, if at all?

Jim Manico:                       No, it’s funny. When mobile [00:48:30] applications began becoming in bogue, I expected a big need for mobile application classes and it never popped. There was never a big, big ass for people… Actually, I’ve probably seen the biggest ass for mobile classes in the last year.

John Verry:                        You know why?

Jim Manico:                       Why is that?

John Verry:                        IOT. That’s what’s going on. Because we’re getting a lot of business right now, because you’ve got this California State Bill 327, that’s got to do with… And Oregon has an equivalent bill [00:49:00] and we’re starting to see guidance. You’ve gotten this guidance. Yeah. So that’s why you’re seeing it. Because if you think about it, IOT pen tests you’ve got, you’ve got the API endpoints, you’ve got the web infrastructure, you’ve got the hosting systems underneath, you’ve got the devices themselves and you’ve got the mobile app that’s being used to configure and manage. So yeah. Those are fun projects because you’re using mobile ASVS, you’re using ASVS, you’re using [CRAST 00:49:26], you’re using a lot of fun stuff.

Jim Manico:                       Absolutely.

John Verry:                        So yeah, [00:49:30] I cut you off, but that’s why you see in the mobile. So you were talking about the mobile.

Jim Manico:                       So the question, oh yeah. What classes have been selling? Kubernetes is very unique in that it went from being very unpopular to being something almost everyone used in a short amount of time. So one of my good friends, Jimmy [Maystar 00:49:47], a couple of years ago. He was like, “Jim, Kubernetes is going to be big next year.” He’s someone who has been into that tech for many years and I’m saying, “Hey, Jimmy, let’s build the course now.” And I’m like, “Look, I’ll guide you [00:50:00] to build it or I’ll encourage you to build it. And as soon as it’s built, I’ll go sell it for you.” He’s like, “This is going to be big.”

                                             So Jimmy at the time made a risk. He made a gamble that he thought Kubernetes is going to be really big. He’s been a security pro for many years. So he spent a year developing Kubernetes course. And last year it’s sold as much of Kubernetes sold as I sold my own classes. It was so sought after and popular. Now, when we built out a mobile class a few years ago, that never [00:50:30] sold. So it’s a gamble. Because it’s hard to build content and you never know what people are going to want. So the point I’m trying to make is that Kubernetes specifically has exploded so much that, even though basic security principles are helpful, Kubernetes is really specific arcane, sometimes nonsensical stuff. So it’s a really specific unique framework, but it’s kind of raw from a security point of view and it’s globally [00:51:00] ultra popular and solve some big problems.

                                             People who move from non-Kubernetes to Kubernetes and can retrofit microservices into this pod architecture, oh, the auto scaling and… It saves dramatic amounts of money for deployment of these kinds of services. So it’s a big, big moneymaker, a money saver to move to this tech. If you move to certain kind of architecture like primarily microservices and the guidance to lock that down is ultra specific and requires specialized knowledge. [00:51:30] Something like-

John Verry:                        Is that developer knowledge or is that security configuration… It’s really weird. Let me ask you a question. Okay. So let’s go there for a second. Because one, it begs a question I didn’t think to ask you. This might sound ignorant, because I’m no longer in the development game, but I look now at development and to me, there’s two forms of development, there’s developers that are doing conventional code development and then there’s the developers that are responsible for the continuous [00:52:00] integration, continuous deployment. It’s a different kind of programming, right? They’re programming tools, scripting things, things of that nature. But to me it’s still development. Do you differentiate those and are there different skill sets and are there different things you apply to, if you’re chatting with the people that fit into those two different buckets?

Jim Manico:                       Well, it’s usually two different classes, right? When I’m teaching a general web security and API security intro class, every developer usually is can benefit from attending [00:52:30] that no matter what your framework is, because you got to understand basic web principles like origin policy cores, outputting codings, parametrization, these are universal concepts for any language. So having a good entry level course that everyone benefits from is great. That’s why we moved to Kubernetes. I usually see the same people from the main developer class, but a much smaller group who are more of the senior people, who are going to be in charge of configuring Kubernetes and [00:53:00] passing that knowledge down to other developers. Because, Kubernetes is a developer. Infrastructure at the service level and rarely do developers write code and toss their code over the fence and have someone configure the Kubernetes cluster. It’s so integrated into how they’re writing code that I see developers getting their hands dirty with Kubernetes configuration a lot more than other kinds of application frameworks. This is really like a very minutiae, detailed level framework.

John Verry:                        Does that hold true if they’re using [00:53:30] another container technology like Docker or is that something unique to Kubernetes?

Jim Manico:                       I think it’s unique to Kubernetes. With Docker, it depends on your app architecture as well, right? If I’m doing microservices using traditional deployment technologies, I’m not getting the big benefits out. So if I have like a big monolith in a Docker container, I can get one security pro to lock it down a bit without too much effort. So it depends on the kind [00:54:00] of architecture that you’re building in terms of [crosstalk 00:54:03] technology is better, I would dare say.

John Verry:                        Okay, good. That’s another thing which you need to account for, as you’re making sure you folks have the knowledge, training awareness tools, technologies that they need.

Jim Manico:                       I think you could save a mammoth amount of money by having even just a two days hands-on Kubernetes class before you start using that technology. That’s the ideal. A lot of really smart people who teach Kubernetes [00:54:30] security classes now, I do. Many of my… Others do, that I would still recommend. But the goal is that, if you just start using Kubernetes in your end production, guess what? You see what happened in is great. What was the news about Azure earlier today? And this is hilarious, Jimmy and I are actually… Jimmy [Maystar 00:54:48] my Kubernetes expert, good friend. He was like, “Do you realize Jim, people leave these administration port in Kubernetes wide open.” I’m like, “What can you do?” He’s like, “Jim, you could just administer the whole [00:55:00] cluster.” And this is in the cloud. I’m like, “Wow, we can go. Let’s go bitcoin…”-

John Verry:                        It’s like even the admin panel open.

Jim Manico:                       So I’d spread back a year ago. It was like, “Jim, we could scan for it now and start loading pods and start mining Bitcoin.” I’m like, “That’s a felony.” He’s like, “We could, we’re [inaudible 00:55:17].” And so today there was a message out of Azure that they had to shut down a lot of clusters, because guess what? Someone’s found all the open ended boards across the Azure and popped through [00:55:30] one of the Kubernetes technologies, was able to pop the clusters that were doing AI computation and convert them all to Bitcoin miners. Yeah. We were talking about this theoretically a year ago and to see this hit the news today, I woke up, saw it, texted Jimmy. He’s like, “Yay.”

John Verry:                        “Told you so.”

Jim Manico:                       “I told you so.” So yeah, taking a Kubernetes security class just a couple days before you start betting the [00:56:00] farm on this technology is a wise use of training dollars. Absolutely.

John Verry:                        Cool stuff. Well, you’ve exhausted the list of questions that I had for you. Any last thoughts, anything we didn’t cover that you think based on the persona that we were trying to target for today’s call that you want to add?

Jim Manico:                       If you’re a CISO without development experience and you want to start learning about this topic, there’s actually a guided OWASP, the OWASP CISO guide. It’s a little bit older [00:56:30] and dated, but it helps explain the core concepts needed to make AppSec decisions from a manager point of view. I think that’s great. If you’re a CISO for a very, very big company, you probably already hired someone to help you manage AppSec efforts. Right?

John Verry:                        Mm-hmm (affirmative).

Jim Manico:                       There’s no shame in not having developer background, but I would be wary of a technical CISO with an administration background, trying to worm their way into development shops without knowing how to speak the language. I’ve seen that [00:57:00] happen a lot and it usually adds friction. So I just politely warn you about that.

John Verry:                        We see it, we go in to do… We’ll do an OWASP ASVS level two or level… Not level three, usually level two assessment. And we’re in with the developers and yet developers don’t like to have third parties looking over their shoulders, right? Whether it’s an internal resource, like the CISO or whether it’s a third party like us. So yeah, finding, getting to a point where you are able to effectively communicate with the developer. [00:57:30] I love something you said in a podcast, and I wonder if it’s something that we could use as assessors or even as CISOs, use it… And I’m paraphrasing. So, correct me if I captured this wrong. You said that you want your coders to move from being unaware to security aware, which moves them from being an independent coder or a lone-wolf coder to a software engineer. Right?

                                             Talk about that for a second. Is there a way that a CISO [00:58:00] or a software engineering manager or somebody in that role can help somebody make that transition? Because I thought it was very powerful when you said it.

Jim Manico:                       Absolutely. Again, I go back to the Automotive Linux Group and the idea of a security champion and having an embedded resource with development teams and figuring out that in some way. So you have some developer kind of a lone wolf. You want to bring him into the world of security engineering. You bring them requirements, work with developer to create those requirements, give them access, give them access to mentorship [00:58:30] because software engineering is a team sport. It really is. They’re going to have to interact with security assessors. They’re going to have to interact with some business security requirements. They’re going to have to interact with the mentor and having a junior developer or someone new at development and give them proper security mentorship, I think that’s the secret to bringing a lone-wolf coder into the fold as a security engineer, or at least a security-aware engineer.

                                             And last, one more addition to that. I don’t want [00:59:00] the developer to figure out all the security. That’s not possible. What I’m trying to accomplish is give a developer enough awareness of the critical, of the widespread categories of issues that can happen. So when they’re working on something security sensitive, especially early in their career, they know enough to go ask questions to that security mentor that you hopefully give them access to. It’s usually that process that converts developers from a good coder to an engineer. When I began developing for [00:59:30] GE back in like the late ’90s Java 1.02 Applets over sat phones and Netscape 3. I had the gift of having a mentor named David Reed, who was a Six Sigma champion developer lead at GE power system. And David was a… He was a non-compromising boss about strict policy and SDLC and doc.

                                             He really shook me. I was coding like for 10 years before I went and took my first job. I was coding. So I was a little kid, but as a professional [01:00:00] coder, I had a really strict SDLC manager and he was a genius and brilliant. I think back in my career, 24 years as a PRos IT professional and the things Dave Reed taught me decades ago still help me. So I can’t… Again I’m not going to make you spend money CISOs, I’m trying to make you spend a little money because this is the core of raising people up the stack-

John Verry:                        You’re not spending money. You’re making [01:00:30] an investment.

Jim Manico:                       Yeah.

John Verry:                        And I think you really need to understand that. So, I always like to end on a, on a fun question, hopefully we told you about it, right? What fictional character or real person do you think would make an amazing or horrible… I usually use the term CISO, but you could do software engineering manager or CISO, whatever is better for you and why?

Jim Manico:                       I think this is a great question. So here’s my business idea, John. I want to do a new company called Scapegoat [01:01:00] as a Service. I want to take all these retired CISOs, great names, great industry names and I want to hire all the retired, a great CISO of the world to take CISO jobs of other big companies just to serve as a scapegoat. So when an incident happens and the CISO who’s there actually doing the work, you don’t want to fire them, keep them in there to help fix the problems. You have another CISO who’s retired and a figurehead, fire that CISO, so the actual people who work at… And then bring in another scapegoat CISO. [01:01:30] I’m retired. So hey, you can fire me. Don’t make you do any work. It’s just a figurehead. That’s my awkward answer to your question. Scapegoat as a Service, hire my retired CISOs. So if you get hacked and there’s a big incident and somebody wants blood, go ahead, fire your CISO.

John Verry:                        Jim, I think there’s a flaw in your business plan.

Jim Manico:                       What’s that?

John Verry:                        The flaw is that how many customers have you ever met that believed they’re actually going to get compromised before they do? I mean, so you’d never be [01:02:00] able to sell it, right? I mean, everybody  themselves, right? And think they’re bullet-proof, right? Until shit hits the fan, then suddenly… The only way you could sell that service is to people that have already been compromised once, because they know it’s going to happen again, it’s those bastards that haven’t been compromised before that just don’t realize it. It’s eventually going to happen unless you do a lot of stuff, right?

Jim Manico:                       Yeah, exactly. Not a good business model, but good for comedic purposes.

John Verry:                        There you go. So, [01:02:30] last question, you chat every day, all day with people about information security, mostly about application security and knowing this is a podcast listened to by people in this space, any ideas for something interesting that you think would be a good future podcast topic.

Jim Manico:                       Again, I think that how we communicate as leaders is going through rapid change in the world right now. So if I wanted to influence the CISOs and C levels that I know I’d want to take things like psychology classes and emotional intelligence classes [01:03:00] to raise their ability to communicate like adults. This is not a political statement in any way. This is the need to communicate online, because a lot of our work is online, now. The need to communicate online in a professional, psychologically healthy way is more important than ever. This is a great way to be effective as a C level, the technical things and similar, we can always learn that, but I almost want to have a psychologist on a podcast and talk about [01:03:30] what effective leadership is in high stress environments. That’s what interests me as a leader. I’m just going out-

John Verry:                        No, that’s actually… Yeah. And it’s funny. I wonder how much your perspective is influenced by the fact that you deal with developers and developers are often unique bot. Right? A lot of them are more introverted. A lot of them are more internally focused, right? And internally driven, which is a different persona to deal with. That’s really interesting. I wonder how much of what… [01:04:00] The fact that you’ve managed developers or trained developers your whole life, how much your perspective is actually influenced by that because it is a unique, it’s a different group of people.

Jim Manico:                       Yeah. I want to raise people up and inspire them to care about security and feel good about their jobs. I want to be in… It’s a big leadership position to do this training, right? So, I’m telling people how to engineer and how to change their culture. In my mind doing AppSec training is a very big deal that I take seriously. I’ve had customers tell me, “Can you please take this a little less seriously?” And I’m [01:04:30] like, “No, I’m not. Sorry. But no.” I just think when I have technical employees, I have said things that have hurt people’s feelings and I’ve lost developers. And I’m like, I know it’s a soft skill, but it’s like I want to be able to communicate and influence a technical team of independent cats and get them to shift processes and shift how they do engineering and be open to critiquing their own [01:05:00] work and doing things different and to communicate that effectively and to demand that effectively as a leader, you’ve got to have a high EQ.

                                             You got to really understand how to communicate this effectively without being a jerk. I know a lot of C levels who are starting to raise the hammer or make inappropriate demands or communicate things ineffectively, you’re going to get more of what you want with the mastery of these soft skills as a leader, when trying to influence change.

John Verry:                        That’s actually really interesting because if you think about it, most of the people ended up in [01:05:30] CISOs roles, although we’re starting to see this change a little bit, but traditionally they’ve come up through the technical side. So they’re in that same class of having that unique personality style, where they’ve been praised for effectiveness and efficiency of operations and knowledge, but not necessarily for their human skills. That’s actually a really interesting… This idea of leadership requiring that skillset is actually a really cool idea. Yeah. I like that idea. Thank you. [01:06:00] Cool. So, awesome job. Thank you. Having watched your presentations. Probably. I had no doubt that it would be. So I just wanted to say thank you. Before we go, how can folks get in touch with you if they would like to?

Jim Manico:                       I’m easy to find. I have a catch all domain. You can send me email at [email protected]. That’s M-A-N-I-C-O-D-E .com. It’s a catchall domain, so you can send me email at… Anything you want @ [01:06:30] manicode.com.

John Verry:                        So including the Jim and or equals one.

Jim Manico:                       What my email address… It’s jim’or’1′!=’@manicode.com is a live, active sequel, injection payload and illegal email address. I will [inaudible 01:06:53], if you want to.

John Verry:                        I saw that. I was like, “Well, that’s clever.” All right man, listen, [01:07:00] I wanted to say thank you a lot for coming on today. Appreciate it,

Jim Manico:                       John Verry, I had a great time. Thanks for inviting me. Hey, stay secure out there. Thank you.

John Verry:                        Got it.