Mike Landeck -- Security Must Meet the Needs of the Business

0:05Chris RomeoThe Application Security Podcast. Here we go. Hi folks, Chris here. Robert and I are joined by Mike Landeck. Mike is a cybersecurity evangelist, AppSec junkie, and Docker security geek, and can be found on Twitter @MikeLandeck. We interviewed Mike in person at the ISC² Security Congress event in Orlando, Florida. We discussed his latest talk on breach fatigue, the need to reach outside the echo chamber of security, Twitter as a news source for security, secure coding, and a bunch of other things. Please enjoy and search for something that you can apply directly from this podcast into your day-to-day life.

1:02Robert HurlbutHi, this is Robert Hurlbut, and I'm here with Chris Romeo, and we're at the ISC² Security Congress in Orlando, Florida. And today we're going to be talking with Mike Landeck, who is a cybersecurity strategist at Hewlett-Packard Enterprise. Welcome, Mike.

1:21Mike LandeckHi, thanks. So I'm here, I'm Mike Landeck. I'm here by myself today. I'm not speaking on behalf of Hewlett-Packard Enterprise, so my views don't necessarily match Hewlett-Packard Enterprise's. I need to get that disclaimer in.

1:32Robert HurlbutAbsolutely, thank you. And just to begin, like we asked several of our folks that we've been interviewing and talking to, give us your, what we call our superhero origin story. Everybody's got a story to tell about how they got into security. What's yours?

1:49Mike LandeckI've got a good one. About 20 years ago, back in the beginning of the dot-com boom, I was a web development manager, so I managed a web team, and we were— back then we were like rock stars because no one could do it. And Microsoft had the realization that if applications weren't secure, people wouldn't be using their products. So they had this big initiative where they took their partners— I was a Microsoft partner— took us to Microsoft's campus for a security talk. And back then, none of us had heard of security or cared about security. It was irrelevant to us. So we're on Microsoft's campus and they introduced the speaker, and it was this kid who probably was about 17, dressed— his hair was dyed black, he was wearing black eyeshadow, black shirt, black socks, black fingernails, all dressed in black. And on Microsoft's campus came out and said, Microsoft sucks, right on campus. And Microsoft didn't kick him out. And they had, I'll never forget it, they had 3 screens. They had the original Internet Explorer, they had the old SQL Server 5 management console, and they had the File Explorer with the C drive open. And this kid says, who here thinks he writes secure web applications? And we all raised our hands. And within 5 minutes, using only the browser, he'd essentially shared out the C drive and gave himself admin access to the database in minutes. And Back then there was no hacking, there was no Mr. Robot on TV, it was new to us, and we all just sank. People ran into the hallways calling their sysadmins, and afterwards I went to him and said, you gotta tell me how I could have prevented that because you could have done that to me. And I ended up having a correspondence with him where he essentially didn't teach me how to hack, he essentially taught me how to prevent hacking. So I really was probably one of the first people doing web application security defense.

3:29Robert HurlbutWow.

3:29Mike LandeckI became a security evangelist at that point, and that was probably about 20 years ago, and I've been educating people on cybersecurity mitigations ever since.

3:38Robert HurlbutOkay, great. So you've been working with developers and helping them understand more and more about security over the years then, it sounds like.

3:45Mike LandeckYeah, most of the work I do is in the application security area where I do a lot of work helping— I do a lot of education on secure coding and software security assurance. My passion is software testing. How do we do security testing on software?

3:58Robert HurlbutOkay, great.

3:59Chris RomeoSo can you say who this unnamed person is or is this a forever anonymous source?

4:03Mike LandeckIt was a young man 20 years ago. I would love to know who he is because I owe my career to him because it was really a true aha moment, but it was the Microsoft campus 20 years ago. I'm not sure they ever actually introduced him. I had an email address from him from a—

4:18Chris RomeoHush mail or something?

4:19Mike LandeckNot quite. Back then, there was a lot of fly-by-night ISPs and it's It's long gone, but I would love to know who it was now because I really owe my career to him. It was a, you know, those Scared Straight shows on TV where they send kids to prison? This was a Scared Straight where they sent web guys to a hacker.

4:35Robert HurlbutWow, that's great. Well, tell us a little bit about your talk. You're here at IC2 talking about application security.

4:44Mike LandeckTell us about it. Yeah, so I have this theory I call breach fatigue, and that we see, even as cybersecurity professionals, we see breaches on TV and the news literally every day. Every day if you read the news closely enough, there's a different breach, and we've gotten numb to it.

5:00Chris RomeoSo what do you mean by breach?

5:02Mike LandeckSome kind of data theft, some kind of data loss. I'm not including DoS attacks. This is really truly an exfiltration of data. But at least daily, somebody's losing some data, and we become numb to it. We become numb. We don't read it. It doesn't make the news. And the sad part of that is it's very rarely is this because the organization did everything perfectly and the bad guys just had some zero-day. That does happen on occasion, but more often than not, there were multiple cascading control failures that allowed the attacker to exfiltrate the data. And if you look at the major breaches, the mitigations are pretty simple. If you come to my talk, you'll hear me say frequently, it would have just been a few lines of code to fix that. So what I'm doing is I'm walking through some of the more famous breaches, like the Panama Papers breach. We had, it was 11.5 million records exfiltrated. 140 politicians were shown to have some kind of offshore banking activity. You know, it's the biggest data leak in history. Didn't make much in the news, and if you ask people what the root cause was, people aren't even sure. And the root cause really was SQL injection, which was originally found and mitigated in 1999. So the biggest data leak in history happened 17 years after there was a mitigation for the vulnerability. So, you know, the Alibaba breach, you know, 21 million user records were exfiltrated due to a brute force attack. You know, brute force has been around since the invention of computing. So ever since there's been passwords, there's been brute force attacks. And I'd have some things that are less common. QR codes, for example. There's a lot, you know, QR codes are a way to market to Gen X and Gen Y.

6:48Chris RomeoYeah.

6:49Mike LandeckAnd there's, it doesn't make the news, but there's been a lot of QRL jacking and people just flat out putting stickers on top of the QR codes. So I'm doing some demonstrations with that.

6:58Robert HurlbutOkay, great. So in terms of like what you mentioned about the Panama Papers and SQL injection, we've talked before about OWASP a little bit, the top 10, that's still number 1.

7:10Mike LandeckStill number 1. And it's funny, my talk, the goal of my talk isn't to get them to learn, to get them to walk away knowing how to mitigate SQL injection. The goal of my talk literally is to get them to go home and read OWASP SQL Injection Cheat Sheet. I've got the link right, pretty much every mitigation I'm showing ends with pointing them to the OWASP cheat sheet on how to mitigate that.

7:31Robert HurlbutOkay, very good. And are you getting some good questions from attendees about that in terms of what do I do, how do I, what am I looking for?

7:40Mike LandeckIt's nice the awareness is working because most people in the audience aren't software developers. They're people that, you know, there's a lot of auditors here, a lot of oversight people. And they're really excited about how to go educate the developers. So that's a different story than the software developer's job. Typically, they make their— get their goodies by writing the most lines of code per hour with the fewest defects. And what happens is, I've never in my career seen a software requirement that simply says, the hackers can't get in. We end up taking software developers and giving them 100 pages of security requirements. We don't explain them, and they're really hard to understand.

8:17Robert HurlbutRight.

8:18Mike LandeckWe don't give them any frameworks, we don't give them cheat sheets, and the blanket, please make it so hackers can't get in, doesn't usually appear there. So, my goal is if you take— when I work with software developers, they really care about security a lot, but they're actually disincentived sometimes. Sometimes there's so much pressure to write code fast, they're being pushed into agile. Agile can be very secure, but if you don't build security into agile, you're going to get exactly what you're asking for. You're going to get a very fast release cycle, that bypasses security. So it's out of the scope of my talk, but you can take things like agile continuous delivery and make them very secure, actually very inexpensively, but you just have to educate the developers on what they need to do and why.

9:01Robert HurlbutOkay, very good. So in terms of, you mentioned about the breach fatigue, and I've seen that as well, where it seems that especially a few years ago, heard about Target, we heard about, you know, some others, and that was the big news. But now they're still there. We hear them, certainly in the security community, we see a lot of those, but I see the same, that it seems like people are more and more numb to it. What are some things that you talked about also in your talk about helping people still be aware of these things?

9:34Mike LandeckWell, to give you a little story, several years ago, I was overseeing a very large software project with the mother lode of sensitive data. A full data exfiltration would have been in the hundreds of millions of dollars of fines and penalties. And when I got there, everything was kind of done. They figured out the schedule, it was funded, it was staffed, it was, you know, there was a project plan, there was a project manager. I thought, this is too good to be true. And I'm looking over the project plan and there is no security testing. None whatsoever.

10:04Robert HurlbutReally?

10:05Mike Landeckwhat would have been a $100 million data breach. And so I put 5 weeks of security testing there, which pushed the due date. And I get this call from the project management office yelling into the phone saying, who do you think you are requiring security testing? And I started to respond, well, I'm the CISO, please leave your badge at the desk and go home. And it occurred to me, maybe she really doesn't know what I'm talking about. So I said, well, do you think security testing is? And she said, well, you know, you know, it's, you know. And she really didn't know. So I brought her to my office, I walked it through, you can tell I'm very passionate about security testing. And by the time we were done talking, she became my biggest ally. So by just educating her, if I'd played bully, policeman, played the FUD card, I probably wouldn't have gotten anywhere. So long story short, we did the security testing, and sure enough, the pen testers were able to exfil some of the data. Worst possible case scenario. So, in the project plan, I added time for the developers to fix it. Now, the same lady who's my biggest ally calls me up and says, who do you think you are? We never said we'd fix it, we just said we'd test it. And again, it was like, leave your badge at the desk. And I said, well, why don't you come to my office? And I brought the pen testers out. I brought them out and said, you're on your best behavior, but you need to show her what you did. And I showed her and it very appropriately freaked her out. And she worked for a company that had contracts all over the place. And before I knew it, this one incident had been prevented. Other companies were coming to us saying, are we vulnerable to SQL injection? And by this one little demonstration, it had this cascading effect where people worried about SQL injection, which, you know, SQL injection is one vulnerability out of hundreds. So what I did is the next time there was a breach in the paper, I had a little party. I had a brown bag lunch where I brought the pen testers out, made them put on clean shirts, and instead demonstrate this. And what happened is instead of me playing the Fed Cognizant, me being a policeman, I became the guy that people would come to and say, are we vulnerable to this? And that was several years ago, and that's what kind of kicked me off on these demos where if it's something you've heard of, something you're aware of, if I can demonstrate it to you and show you how you may be vulnerable and a very inexpensive way to fix it, you're very likely to fix it. If I come to you and say you have to fix that or else, they probably won't. And if I come to them and say you're going to be breached no matter what without explanation, they probably won't fix it.

12:39Robert HurlbutOkay, great.

12:40Chris RomeoYeah, I like that partnership approach that you're describing here, and I think that's the evolution of security over time. We've gone from— so it used to be all about FUD, We're just going to try to scare you into believing that you need to do that. But that doesn't work because schedules are moving so fast these days. They're not afraid of that. And so I think you've hit on something here from exposing them and opening their eyes is really a good way for them to become the advocate. And that project or program manager, from that point forward, probably became a a big security advocate for anything that you were doing because she understood both the cause and the effect and the overall risk. And I think risk is so hard for people to really understand.

13:28Mike LandeckVery much so.

13:28Chris RomeoPeople at this conference that are here, most people here could give you a really good definition of risk. The problem is this is the echo chamber. We're talking to all our friends here. It's the people that are developing code are at their desks somewhere on earth typing away right now. They're not here learning about these lessons. So what do you think about reaching out and what are your, What are your thoughts on how you get to the rest of the bigger community?

13:52Mike LandeckYou know, we've seen in the last few years, we've seen DevOps absolutely explode because DevOps is developer-friendly. DevOps was invented by developers for developers. Before that, we had the 1970s waterfall model where the developers, they loved writing code, but they hated these constraints. With DevOps, the developers figure out how long it will take, how they'll do it. and we empower them. And I really think the next move for security in this software lifecycle is to have developers figure it out. One of the most impactful things I've done is I had a development team that really cared, really wanted to, but had no security training whatsoever. And they were all very proud people. You could go to them and say, you suck at security, and I would have just crushed them. So instead, what I did is I gave them all the OS cheat sheets and I gave them all a license of a dynamic scanner. And I said, I want you to do your unit testing. Before you check in your code, you scan it and make sure it will pass. That way, when it comes to me in the test phase, we know it will pass and no one gets embarrassed. Because what usually happens is they write code, they think they are done, it goes to QA, security finds it, security says, haha, you don't know what you are doing, go back and fix it. Schedule is delayed. They are mad at you, we are mad at them, and it crashes. If you have them do it during the unit testing and say, don't check it in until we know it passes security. By the time it hits test phase, my job is easy. I'm just validating the unit tests. They get to be proud because they have no findings and the schedules don't slip. So, I think security needs to look at the evolution of DevOps and figure out how we can fit into that, where we can empower developers to figure out how to do security in a way that works for them. Software development is not a one-size-fits-all shop. There are still shops that have annual release cycles, where they release one release a year, then you've got places like Twitter that are announcing hourly releases. Now, if you go to a place like Twitter with an hourly release and say you need to spend 2.5 days doing a software test, it's not going to work. So, we have to look at the developers, how do they develop code, and we have to figure out how security fits into that. We have to be flexible.

16:01Robert HurlbutOkay, great. So one thing I was thinking about there, let's say this is some of the things that you've done and how it's been really helpful and successful for you to be able to communicate and build that partnership with developers and QA and other people in the organization. In looking for, let's say for example, breach data or breach information, there's a lot of stories out there, media that overinflates things. How do you separate the hype from the actual— what you really want to know and need to know from the breach and even how it's done? How are you finding that in particular?

16:40Mike LandeckThat's a great— so when I got into cybersecurity, you know, hackers were villainized. The fact I was a pen tester, my first ISC² meeting a long, long time ago, I was told to not mention the fact I had pen testing skills. because it was frowned upon. Nowadays, we've got the candy on the ISC squared board, so the ability to do offensive security is now being embraced, but along with that, the media is now glorifying the attacks. So we went from don't talk about the attacks, having them be very, very FUD-like, to now the attacks are being kind of glamorized.

17:16Chris RomeoWe have a TV show that's focused on it, Mr.

17:19Mike LandeckRobot. Mr. Robot. So when you look at the breaches, there's 2 things happening. One, there's not a lot— sometimes there's not a lot of information because the company that was a target doesn't want to be sued, which is fair enough. Another time, it's very sensationalized, very glamorized. And what you have to do is you have—

17:36Robert Hurlbutwhen you—

17:36Mike Landeckwhat I'd encourage people to do is when they read about these, read for what the control failures were. You talked about the Target breach. What we know from the newspapers was it was a third party that was compromised. That third party had access into a data center. They used access to the data center to put in some memory scraping software. That's what the newspaper said. So instead of saying, I'm not going to use my credit card at Target anymore or Home Depot anymore, wherever it was, read that for what happened and think about your organization. You know, what contracts do you have in place with your vendors? How is their third-party access being managed? If someone were to get in your data center, would you know? If your software in your data center was modified, how would you know?

18:16Robert HurlbutRight.

18:16Mike LandeckSo, when you read these breaches, don't get caught up in the hype, but look at it in terms of what do we have that's similar, because most organizations now have third parties. Most of them have off-premise data centers or cloud services. So, you can look at these things and think to yourself, what does this mean for me and how can I educate my people? So, if you could go— if you had a lot of third-party contracts and as a security manager you were worried that we weren't paying enough attention to those, You can then use one of those breaches to say they had a third-party, you know, third-party access. It didn't appear to be cut off in a timely manner. How often, you know, what's— and get some metrics. We terminate when we end the contract with a third party. It's on average taking us 6 days to turn off that access. Come up with some metrics that match the breach and present those metrics to your executive staff, and you'll get a lot farther than playing the FUD card saying, hey, they were breached, we could be breach too. You know, I say it a lot, but when I'm doing security management, you know, it's do more math because the more metrics you can provide, the less FUD you can provide, the more actual responses you'll get.

19:24Robert HurlbutGreat. Do you have a particular source of places that you find more detailed information about breaches and one over another? Do you have any recommendations?

19:34Mike LandeckYou know, honestly, my evolution was from the newspaper to Slashdot, now to Twitter. I mean, Twitter has become my biggest news source. And if you— there's certain people you can, you know, news sources you can follow that tend to be a little more focused. You know, even Brian Krebs, you know, Brian Krebs is— there's a t-shirt out there that says Brian Krebs is my IDS. You know, there's some truth to that. You know, people like Brian Krebs or Art Technica will have some very detailed information.

20:06Robert HurlbutRight. Okay.

20:06Chris RomeoSo if I was to put on my developer hat and let's pretend— so one of the groups we're trying to reach with this podcast is developers, testers that are not security people. So how would you recommend, or let's pretend I'm the developer here that knows really very little about security, how would you approach me from a data breach just to teach me or to help me to understand why I even need to care about it?

20:35Mike LandeckSo when I work with developers, I don't put on my security manager hat. I just simply put on, you know, we're all in the same organization. If we're breached, you know, if your software is breached, we're all breached. I don't put the FUD coat on. I simply talk about secure coding because developers really do care about secure coding. More often than not, they're not taught. One of the things I do is I provide secure coding. I don't teach it myself, I'm not qualified, but there are vendors I use, there are free resources I use. OWASP is a big one. The other really powerful tool is teach developers to pen test. OWASP has their broken web app. It's wonderful, the Damn Vulnerable Web App. It has clues, it has hints, it has code snippets, let them play with that. They can bring it up in a VM. And the more you let developers see how a vulnerable site is hacked, the more they'll start thinking, you know, I code that way. You have to go back to our SQL injection talk. You know, they'll go, oh, you concatenate user input into a SQL query, that leaves a SQL injection. Oh, it says here to parameterize my query. And it's about 5 extra lines of code, which isn't a lot. And they can even go back to their program management office and say, we need to add an extra day because we need to parameterize our queries. It's a high-level example, but the more you can educate them, the more you can educate developers, the better they'll do. Because in my experience, developers really want to code securely. It's really a lack of resources to train them, and it's a lack of time in the schedule. But I've heard both those things more times than I can count. I really do want to code security securely, but I don't have the time for it. Which is a horrible excuse because the program management office wants them to code securely just as much as they do, and the two aren't talking. So, I can play the bridge and go to the program management office and be the bad guy and say, you need to add more time for this. Another thing is training developers. When you learn to code in school, you often don't learn to code securely. I'm not sure why that is. It's getting better. The kids are—

22:45Chris RomeoYeah, I think it's changing now.

22:47Mike LandeckYeah, the kids I see coming out of school are doing a much better job than they were 5, 10 years ago, so the universities are getting better at it, but we're still not perfect. There seems to be a chasm between the young people learning to code securely and the young people learning to hack. If they could all get together, we'd be in better shape, because I see a lot of hackers coming out of universities and a lot of coders, and there's not a lot of overlap.

23:10Robert HurlbutRight. Going back to talking to the developer and the QA, so let's say the QA. I've spoken to some QA people and I ask them, what are you doing for security testing? And they say, well, what's that?

23:23Mike LandeckYes.

23:24Robert HurlbutSo that's a passion of yours as well. Tell me what you would tell to a QA person who's not familiar with security but definitely interested in testing.

23:32Mike LandeckYeah, believe it or not, that becomes political because the question of where security testing should be organizationally especially with the big budgets coming out for security now, is a political hot potato. QA wants it there because they want the budget. Security often wants it in security, and there's pros and cons to both. You know, there's having security do it, you've got security SMEs doing it, they're trained, they— and, you know, with security testing, it's very holistic. You know, it's pretty much anyone can run a scanner. It doesn't take much. But you have to really— it takes some training and skill to run it well. And there's no one more dangerous than someone running a scanner who doesn't know what they're doing because they'll miss things, they'll do it wrong. So with— I think there's a hybrid approach. I think QA needs to manage it, manage the results, but they need cybersecurity SMEs involved. I'll give you an example of, let's say you have a site like Amazon.com. You could run a scanner, you could, you could take any scanner without any credentials and then just have it crawl amazon.com and scan it. And, but you're going to miss logged-in users, you're going to miss the shopping cart, you're going to miss the payment process, you're going to miss the login. The most, probably the most critical parts of the application will be missing. Then you can have someone else who could run a credential who maybe won't think about shopping cart checkout, you know, and ultimately there's Some sites will be in an admin context, so a lot of data is in admin. So if you don't have someone who understands the application, again, the developers, if you're running the scanner and don't talk to developers and the architects, you're going to miss some of these important contexts. So while the program office or QA may manage the software security testing schedule, you need to involve the developers and/or architects. You need to involve security. It has to be this systemic holistic approach. You can't just tower it off and call it checkbox testing. You know, there's a requirement to do testing, check, we did it. It has to be done with some passion.

25:35Robert HurlbutOkay, so you need some information. I mean, that's what— that's key, is not just running a tool, as you said, and see the results, but actually understanding more about what the application is, how it works, and that you get from a developer to understand that information needed to do Thorough and understandable testing.

25:54Mike LandeckExactly.

25:55Robert HurlbutOkay, very good. All right, so tell me about— we talked about breach, we talked about the different ways of working with developers and QA. What about business? How would you help a business as they're starting to think about these things and they have their developers and they have QA, other people in their staff? How would a business start thinking about, you know, better about security and these kinds of things we've talked about, breaches and so forth?

26:23Mike LandeckWe forget it frequently, but the number one rule of security is it has to meet the needs of the business. That's why we're here. That's why we're funded. So, and we forget that a lot. So, you know, it's a kind of an oversimplified example, but I use it a lot where if you write some software and you release it, you have a potential risk of $1 million in penalties. Okay, nobody wants that. But let's say there's a guaranteed $100 million in profit, and if you don't release it, you won't get that $100 million. So essentially, by releasing it, you're getting $99 million. From a cybersecurity context, we don't like that. We don't want— no one likes releasing vulnerabilities. But if you're the CEO of the company, getting $99 million in profit versus zero is probably a really good business decision. You know, this is a very oversimplified example. No one gets hurt, no one dies, you know, it's overly simplified. But when you work with— when you're in cybersecurity for the business, you have to be prepared for the business to have the final say. I can go in, and if I as a security manager go and say, you can't release that software, I'm doing that without the context of what the $99 million in profit would be. As a security manager, my job is to say, you've got this risk, you've got this vulnerability. That vulnerability, you know, when other organizations similar to ours released it, penalties have come out to about $1 million. Here's the context, here's what happened. My job is to explain the vulnerability, explain the impact, provide some examples, And hopefully, if I'm good at my job, provide here's what the mitigation would be and here's how much mitigation would cost. So my job as security manager is to explain the context, the risk, potential mitigation. It's the business's job to decide to go forward or not. And I see a lot of my peers try to go in and tell the business what they can and can't release. And it's our job is to meet the needs of the business, not to tell the business what to do. So when I approach the business, it's— I usually approach the business trusted advisor. And, you know, the challenge there is they don't usually trust you at first.

28:35Robert HurlbutRight.

28:36Mike LandeckI've done security— I've been hired to do security reviews. I had one where I went in and I got in the call a little bit early. And usually when I show up, people get a little bit of— before they know me, they get a little bit intimidated. So, to put them at ease, I said, do you know what to expect? And it turns out they knew who I was, and the response from developers was, yes, don't tell the security guy anything.

28:57Robert Hurlbutanything.

28:57Mike LandeckAnd at that point, I knew that my challenge there wasn't doing security. My challenge was, how do I gain the trust of the developers? So I had to completely shift my strategy and talk about who I was, my philosophy, what would happen if I found something, how to help them save face. And it adds some time, but by the time I was done, they were being very candid with me. We found things, they got fixed. No one was thrown under the bus. I didn't go to management saying, you're so lucky you hired me because I found all these problems. I was able to go to management and say, you know, here's your 5-week plan for bulletproof software. So, it's that subtle shift that buys you credibility when you work with developers.

29:38Robert HurlbutAnd building that trust. I mean, that's really a big part of it. And it comes back to, we've talked on this podcast about The importance of relationship, about building— and we talked about partnership earlier— about building that trust relationship with developers and staff and business as well, so that as security people, we're there to help, we're there to build better products, more secure products. We can't just say, just do it.

30:08Mike LandeckCan't say just do it, nope.

30:09Robert HurlbutWe've got to be able to build the trust and And, and help them to know how to do it.

30:15Chris RomeoAnd so I got another question. That's so, so what do you see as the evolution of the business response to that? Because you described this balancing of the $1 million penalties and $99 million in profit, and that's an easy business decision. But that's not what I don't think that's what you want that organization to do 5 years from now. 5 years from now, you want some— you want them to have taken some steps to understand and say, We're going to get the $99 million, we're going to get the $100 million profit, and we're going to have a secure solution because that's what our customers need. So what do you think about that?

30:48Mike LandeckSo thanks for catching that. Always, always, always have a remediation plan. And they may choose to do it, not do it, change the timelines, change who does it. But I will never, I will never, ever, ever go to an executive and say, you've got this problem. I'll always say, you've got this problem. Here's how to fix it. Here's a timeline. In my experience, here's what it will cost. And more importantly, here's how to do it better, faster, cheaper. I'm not being paid to tell them they suck. I'm being paid to tell them how to fix it in a way that's better, faster, cheaper than they get by Googling it, because otherwise they'd just Google it and not hire me.

31:23Robert HurlbutSo that's your perspective, is again, not just telling, but how do you do it?

31:28Mike LandeckYou have to provide— I mean, we see it a lot in cybersecurity where cybersecurity practitioners are saying no. You know, there's a lot of slang for us. We're the preventers of forward progress. We're the obstructionists.

31:39Chris RomeoOr the people that take the fun out of the room.

31:42Mike LandeckPeople that take the fun out of the room. Right.

31:43Chris RomeoThey don't know us for real, though.

31:44Mike LandeckWe actually deserve that. I mean, we've got a long history of saying no. I mean, that's true. Those terms, while I don't like them, as a profession, we've probably earned them. And it's because we go and we say no. What we need to do is we need to say not yes or no, but if you do it, here's what will probably happen based on these facts. Here's how to fix it based on these facts, and here's some suggestions on ways to do it that meets your business needs. Because like I said, each business process is unique, so you have to understand the business processes and tell them, here's what it is. I'm a big fan of I Am a Calvary. They're identifying vulnerabilities in medical devices and cars.

32:28Robert HurlbutRight.

32:29Mike LandeckA vulnerability in a medical device is very different than the fact someone can change the background color on your webpage. They're very different impacts. Well, ethically, I'm very concerned about one. As a professional, I would— businesses will ultimately kick that to the bean counters. My job would be to say, here are the vulnerabilities, here's the likelihood of it being exploited. If it was exploited, people would die. You can punctuate your delivery and really bring about past examples. But ultimately, as passionately as I would feel about that, I have no ultimate say over how the business does it. At that point, I'm not the CEO. So it really is the CEO's ultimate decision, and your job is to craft your argument as best you can. And to your point, tell them how to fix it or refer them to someone who can.

33:20Chris RomeoYeah.

33:22Mike LandeckYeah.

33:22Chris RomeoAnd in this day and age, it's not like it used to be where boardrooms are just ignoring security or having no idea what cybersecurity is. The average board gets a cybersecurity briefing, and every time they meet, there's something being discussed from that perspective. So, I think that we're in a better place now because we're not going to experience those major trade-offs because the board understands the risk of If we just ignore this thing, we're potentially going to be the next Target, the next Home Depot, the next big breach that's happened. So, I think we're making progress there, and I think that'll help to better prepare businesses to make the right decision because they're going to have the pressure from above saying, you're not going to put me on the front page of the Wall Street Journal. It's not going to happen.

34:11Mike LandeckWe're not buried in IT anymore. In the early days, we were all buried in IT and had no access to the top.

34:16Chris RomeoYeah, now they're pulling everybody up. They're saying, come on, like, no, I don't want to talk to the board. No, come please, you must speak about cybersecurity.

34:23Robert HurlbutOkay, well, you know, in closing, I was wondering if you could give us just a few minutes call to action. What do we need to do now that we know a few things here? What do we need to do today?

34:36Mike LandeckWe need to really start educating ourselves. It's not about FUD, it's about awareness. So, give your developers time to learn. Send them to a security training. Give them the OWASP cheat sheets. Add a day into your project plan for developers to do some, you know, make a sprint that says they're going to read the OWASP cheat sheet. It's very inexpensive, and it goes a long way. The call to action would be, we're giving a lot of lip service to security, but we We don't have the tools. We all care about it, but we're not giving the developers the time and tools to take action. So, I believe we all care about it. If you're agile, add some sprints. They're going to read the cheat sheets. Give them a few days off to go to an OWASP training. Give them a few days off to watch SecurityTube. The stuff online is free. Have them download OWASP Vulnerable Web App and play with it.

35:34Robert HurlbutIt's great.

35:35Mike LandeckA huge learning experience. So, put your money where your mouth is, train your developers, empower your developers, you'll be a lot more secure.

35:42Chris RomeoAnd you mentioned SecurityTube there. You can get almost any conference talk, especially from the BSides, the more open, the OWASP-style events that are happening. Those are all going to be posted up there. And so, there's so much information available now, and I'll second your I love your idea here of give people time to actually do it because there's so many resources out there. They just need, they need some time to go into them. You need to balance that against customer pressure of getting that next sprint out the door.

36:14Mike LandeckCan you imagine if every day they had a half-hour sprint to watch SecurityTube? Yeah. Let them pick what's most impactful to them, most important to them. Wow.

36:23Robert HurlbutGood advice. Good words. Well, Mike, thank you. Appreciate you for joining us today.

36:28Mike LandeckThank you. Thanks for listening to the Application Security Podcast. Our intro music is 8-Bit Kung Fu by Boring and TJ, and the outro is Southern Delight by Stefan Kartenberg.

36:41Robert HurlbutYou can find us on Twitter @appsecpodcast or on the web at www.appsecpodcast.org.