---
title: "Brook Schoenfield — Security is a messy problem"
url: https://appsecpodcast.com/brook-schoenfield-security-is-a-messy-problem/
date: 2019-09-15
duration_seconds: 2694
guests: ["Brook S.E. Schoenfield"]
topics: ["Threat Modeling", "Building an AppSec Program", "Security Testing", "DevSecOps and CI/CD"]
audio: https://www.buzzsprout.com/1730684/episodes/8122627-brook-schoenfield-security-is-a-messy-problem.mp3
transcript: true
---

# Brook Schoenfield — Security is a messy problem

*September 15, 2019 · 45 min*

with [Brook S.E. Schoenfield](https://appsecpodcast.com/guests/brook-schoenfield/)

on [Threat Modeling](https://appsecpodcast.com/topics/threat-modeling/), [Building an AppSec Program](https://appsecpodcast.com/topics/appsec-programs/), [Security Testing](https://appsecpodcast.com/topics/security-testing/), [DevSecOps and CI/CD](https://appsecpodcast.com/topics/devsecops/)

[Audio](https://www.buzzsprout.com/1730684/episodes/8122627-brook-schoenfield-security-is-a-messy-problem.mp3)

## Show notes

Why doesn't an executive mandate and a scanning tool add up to a software security program? Brook Schoenfield joins Chris and Robert to unpack security as a human, technical, and organizational problem that crosses the whole development lifecycle. He describes the limits of policy and testing, then explains how noisy tools lose developer trust. His practical alternative is to begin with high-confidence checks developers can use themselves, supported by deeper specialist testing rather than an impossible promise to find everything. The conversation turns to culture hacking: sharing responsibility, helping teams work through the consequences of their own incidents, and using threat modeling to make security tangible. Brook closes by connecting those habits to iterative improvement and the security of the delivery pipeline itself.

The Application Security Podcast is brought to you by [Security Journey](https://www.securityjourney.com/).

About Security Journey  
Security Journey provides application security education for developers and everyone in the software development lifecycle.  
→ [Learn more about Security Journey](https://www.securityjourney.com/)

Connect with Brook S.E. Schoenfield:  
→ [LinkedIn](https://www.linkedin.com/in/brookschoenfield/)  
→ [Brook's website](https://brookschoenfield.com/)

Mentioned in this episode:  
→ [Securing Systems: Applied Security Architecture and Threat Models](https://www.routledge.com/Securing-Systems-Applied-Security-Architecture-and-Threat-Models/Schoenfield/p/book/9781032027401)  
→ [IOActive](https://ioactive.com/)

Chapters:  
00:00 Introduction  
05:03 Why a mandate is not a security program  
08:32 The appeal and limits of simple answers  
09:50 Security crosses every domain  
11:41 Getting engineers to want security  
16:59 Why security tools lose developer trust  
24:10 Layering developer checks and specialist testing  
25:55 Putting useful tools in developers' hands  
29:15 Fast feedback while writing code  
33:00 The program-building lessons so far  
34:43 Culture hacking and shared responsibility  
40:25 Continuous improvement and delivery-chain security  
43:33 What's next in Brook's writing

## Transcript

*7,522 words · assemblyai*

**0:01 Chris Romeo:** Brook Schonefeld is a Master Security Architect at IOActive and author of Securing Systems, as well as an industry leader in security architecture and threat modeling, and a friend. Brook takes us on a journey based on his experience building programs with advice, stories, comments, and quotes. We talk about architecture, security culture, mindset, tools, compilers, and so, so much more. We hope you enjoy this conversation with Brook Schonefeld. I want to take a moment to introduce you to Security Journey. At Security Journey, we believe security is every developer's job. We work with our customers to help them build long-term sustainable security culture amongst all their developers. Our approach is to provide security education that is conversational, quick, hands-on, and fun. We don't do lectures. Instead, we let the experts talk about what's important. The modules are quick, 10 to 20 minutes in length. We believe in hands-on on experiments, builder and breaker style, that allow developers to put what they learned into action. And lastly, fun. Training doesn't have to be boring. We make it engaging and fun for the developers. Visit www.securityjourney.com to sign up for a free trial of the Security Dojo. The Application Security Podcast.

**1:25 Robert Hurlbut:** Here we Hey folks, welcome to another episode of the Application Security Podcast. This is Robert Hurlbut, Threat Modeling Architect, and I'm joined here with Chris.

**1:53 Chris Romeo:** Hey, Robert, this is Chris Romeo, CEO of Security Journey and also co-host of this fine, fabulous— I can't think of another word that starts with F to describe us, but awesome podcast here about application security.

**2:07 Robert Hurlbut:** Excellent. And we also have a special guest here today, Brook Schoenfield. Thanks again for joining us, Brook.

**2:16 Brook Schoenfield:** Thank you for having me. It's always great to talk to both of you, either one of you alone, Or in tandem.

**2:23 Robert Hurlbut:** And Brook, you joined us before on season 2, episode 1. If anyone's interested in going back and listening to that, that was a great conversation. It was a funny one though. We were sitting in a hallway at RSA conference in San Francisco when we did it. A lot of background noise. It was an interesting discussion that we had in an interesting situation there, but good to have you back here. with us today. Thank you.

**2:54 Brook Schoenfield:** I'm surprised that time that somebody didn't come up and ask us for directions to something RSA-ish. That would have been so classic.

**3:03 Chris Romeo:** All I remember, I remember 2 things. I remember lots of things I learned during the interview, but 2 things specifically that just about our surroundings. One was we were sitting right by the bathroom. So, if you listen closely, I think you can hear a flush once or twice in the middle of that interview. And the second thing is, We're sitting there and all of a sudden Brook looks down at his watch and he goes, uh-oh, I'm supposed to be doing a talk right now. He gets up and as he's running down the hallway, he's like, bye, see you guys later.

**3:30 Brook Schoenfield:** Oh, you guys, you make me forget time. You literally make me forget time because we're having so much fun. But yes, I had to go give a talk. Oops. And it's true. I got there just in time. They were running late, luckily. So I got there just in time for them to swoosh me onto the panel and get me in front of everybody before it got embarrassing.

**3:54 Chris Romeo:** Yeah, hey, no time to be nervous though when you run right onto the stage.

**3:58 Robert Hurlbut:** That's true, that is true.

**4:00 Brook Schoenfield:** That's funny. One time I'll tell you, I was speaking at a conference on AppSec, as one does, and the FBI agent who was gonna talk about the current threat landscape had canceled and had a sub coming. And his plane, all the planes from his airport were cut. And so they gave me his slides and said, at 1 o'clock, can you give his talk? And I'm like, I've never seen his slides. Yeah, but, but you're security, go ahead.

**4:34 Robert Hurlbut:** You're qualified, go ahead.

**4:36 Brook Schoenfield:** Yeah, it was, it was really pretty interesting, you know. Um, whenever I came to a slide, I told the audience, I've never seen these slides before. So whenever I come to a slide, I don't know what they were trying to say. And feel free to pitch in anytime. You know, it was a classroom kind of thing. There was maybe 50 people there, so it wasn't too busy. And I said, just feel free to pitch in and we'll do this together. And if we come to a slide we don't know, we'll just go to the next one. And it worked okay.

**5:03 Robert Hurlbut:** Great. Well, today we're gonna be looking at, I think, an interesting topic that you've been focusing on here lately, which is about security programs, How do you get a security program started? And I think this comes out of a lot of your experience, right, in terms of building these at various locations, but also seeing a lot of these being put together as well. So let's get started. So tell us about that topic. I mean, what is it that— the first thing that you can think of that is probably the number one thing that you want to tell people about that topic? Sure.

**5:43 Brook Schoenfield:** Okay, you can't mandate a security architecture or AppSec, that is application security or software security, however you want to talk about it, and different organizations, you know, focus slightly differently. You can't just start it by, by having some exec saying, now we're going to have secure software, and writing a bunch of policies and handing them to everybody and saying, see, now we're secure. That is the biggest mistake that I see over and over again. People think that they can just policy their way into this problem. And I'll bet both of you have seen that problem as well. You know, the policy underlies things. It's not that it isn't important, but nobody does something, especially smart engineers, just because it's written somewhere. And maybe they got it in a once a year in their, in their, you know, did you read the policies test and then forget about it in terms of their work completely. That's the one thing I see a lot of times is that— or, and the other thing is you can't test your way out of this problem. Not that testing isn't also important, but it's not— you can't just turn on one tool I've seen this. Oh my, have I seen this. You turn on one tool and don't we have the problem covered? In fact, that is actually a quote from a very brilliant CTO who looked at my boss, not me, but my boss and said, we have static analysis, why do we need a program?

**7:20 Robert Hurlbut:** Yeah.

**7:26 Brook Schoenfield:** It just doesn't work that way because it's so multilayered and multivariate. and multidimensional, and a lot of it has to do with culture and mindset and willingness and humans. Automation too, but humans. That's the mistake there, is the 2 big mistakes that I see. Then we can talk about how you'd really do it and be successful. Just to put a little flesh on those bones, I've worked for 4 different organizations, where I've built software security programs, um, I've been the technical lead for a software security program, um, and so, you know, I've made lots of mistakes which, uh, then we, you know, have dealt with, hopefully, and, and built, and every one of them has been successful over time. Um, so it's a long journey, it's a long journey thing. You're not going to get it in in 6 months. You got to take a few years. And when you take a few-year view, it really shifts the way you look at the problem.

**8:32 Chris Romeo:** What do you think causes folks to, from an executive perspective, try to solve the security problem with a mandate? What's the root of that? Why are they even going in that direction?

**8:46 Brook Schoenfield:** That's a great question, Chris. And I really think it's because Like that CTO, he had a lot of stuff to worry about. He's trying to drive a strategy, the technical strategy for an entire company, which at that time had this huge 138-product portfolio, huge. He's trying to drive that into something that makes sense as the world is changing around him, and security is just one piece of that. If he could get away with just a mandate and buying a tool and done, that's fantastic. He can check that off his list and get on to other things that he wants to think about, right? I don't want to dismiss the person as being foolish or anything. It's just that in a world of things to do, you're trying to— anything you can do simply and elegantly, that's good. But problem is security is a messy problem.

**9:47 Robert Hurlbut:** Yeah.

**9:50 Brook Schoenfield:** It's a— it's a— this guy named Richard Puckett, um, who I used to work with, uh, and he's gone on to a stellar career since then, um, used to say it's the cross-domain domain. Now he's an IT, you know, came out of IT, so he thinks in terms of domains. But it, you know, I think that's a brilliant statement. Security is the cross-domain domain because it's east-west, front, back, bottom to top, top to bottom. All these places you'll have a little bit of the entire picture.

**10:21 Chris Romeo:** Never able to see everything at the same time.

**10:25 Brook Schoenfield:** Well, right. And not only that, um, some of them are just details, implementation details, and some of them are infrastructure, and some of them are the way you do things, and some of them are, are architecture and the way you plan and, and, and make sure you got the right stuff. And, you know, it sort of costs, and then a lot of it's validation. So it kind of touches the entire development cycle. And there's no one— in my experience, the tooling is so bad, and I'm sorry to the vendors, but the tooling is so bad that you really can't count on one tool or one approach to get all your problems solved, even in the validation area. you really shouldn't put all your eggs in one security basket because you will miss stuff. And there are reasons not to do that too. We'll talk about that in a bit, how you set these tools up for success and gaining developer not just adoption but delight, desire to use them. We should take that up as a topic because I think that's really key, is how you get the developers on your side so they're not, you know, they're wanting to do security. They're thinking, yeah, this is one of the things we do.

**11:41 Robert Hurlbut:** Yeah, I think that's actually one of the challenges, right? I know you said we don't mandate, or that's not what we should be doing, that's not what works. But then the other challenge on the other side is a reason why some want to force a mandate is, well, how are we going to get anybody to do anything? You know, no one wants to do this stuff, so how do you get them to do it? So let's maybe talk about that a little bit.

**12:07 Brook Schoenfield:** Well, I think you just stated one of the myths. When people are being smacked over the head with a security club, no, they don't want to do it. But you remember I posted that little statement from some person who wrote a DevOps article, which was very good in my opinion, although he skipped architecture and I need to talk to him about that. But nevertheless, what he said, I completely agreed with. There was this little quote, that said, in all my years working with developers, I find smart, motivated, high-integrity people by and large. And if you start there, you know, if you get them thinking that part of their integrity is security, they'll want to do it. They want to learn about security. I mean, how many times have you walked in— Chris, you teach, and so do you, Robert, a lot— but how many times have you walked into a room of developers and said, now we're going to have some fun, we're going to learn some security? Does everybody then pick up their phone and start looking at their phone to see their personal email and their Twitterverse?

**13:11 Chris Romeo:** Not normally.

**13:14 Brook Schoenfield:** Text, you know, show me something cool, right? And that's the power. That's what we've got to harness is that people actually want to do it. It's just they don't want to be clubbed over the head. They want to have some fun with it. Why did we go into programming? I assume both of you maybe came out of programming. I certainly had a long development career before I got in security, right?

**13:35 Chris Romeo:** And I've been faking it, so.

**13:36 Brook Schoenfield:** Yeah, well, I don't think so, Chris. But, um, you know, I, I, I, I, I wrote hundreds of thousands of lines of code, some of which is probably still running in the world. Horribly horrible thought. But yeah, and, and, you know, why did I go into tech? Because it was fun, it was interesting. They're discrete problems that are really hard to solve, and they engage you completely. If we make security one of those problems and get that part of our developers on our side, well, they're all in, right? Let me tell you a story, and this is a great story. It's my friend Owen Carroll, who is an absolutely brilliant practitioner on many levels. He's a great security architect, in my opinion. He's also a security researcher for McAfee's Advanced Threat Research team, and that's what he's doing right now. but he was one of my leaders for years in one of my programs. And he just out of— he used to draw the threat models. Now we can go into threat modeling in a minute, what that means, but he used to draw the threat models, really great drawings in Visio. And then he put them up in the standup room. All of his teams were agile. And whenever they took something off the— What he discovered by doing that, made this visual thing that said security. Basically, it was a big sign that said security, think about it. But he didn't put it up for that reason, but that's what happened. People would take things off the backlog, an item to do, and they would say, oh, I wonder if this has any security implications. Nah, okay, cool. Oh yeah, hey, we ought to get Owen in here or one of our security architects and start talking about this before we start make sure we're cool before we start doing it. All organically, just by making it visible and part of the organic work. That one thing gave me— opened up so much for me about how to get developers on my side and help build it. It's not something I thought of, but once I saw that, I mean, I went to town with it. over the whole program. We started including everybody in threat modeling training, at least. We started making our threat models really visible. We started making— we started including people on, you know, you're going to use static analysis, we're going to think about how to use it really effectively, and you're going to have a say about it. And, um, you know, we— and the interesting thing then is you get into a whole cultural shift because security becomes part of the mindset then. And then you're not fighting. You don't need a mandate. What you need is just to solve problems. Doesn't mean we're all going to agree. Of course we're not. But, um, uh, but, uh, you have a basis from which to work. And, and it was magic. It was absolutely magic. That was the 3rd program, and I hadn't thought to, you know, all from before that, always the threat model was something the security architects and the leads did. Uh-uh. You give it to everybody, at least to start, because you never know when that junior person says, oh, and by the way, there's an open SSH port in the underlying operating system. That actually— that's a real thing that happened when we were reviewing a threat model, by the way. I didn't make that up. That actually happened. And if that junior person hadn't been in the room, we would have skipped it.

**16:59 Chris Romeo:** So I want to go back, Brook, to something you said about the tooling. I think a lot of our listeners, and I know I'm curious, when you say the tooling is so bad, I'd love to get a little more detail about kind of what, you know, what the classes of tools kind of get your read and your understanding on the classic AppSec tools as a place to start. So why do you think they're bad?

**17:23 Brook Schoenfield:** Well, because they're noisy and hard to configure and hard to tune to a code base in general. Now, some that are easier and some, I mean, from IOActive in a public thing, I can't recommend any. dual. That's one of our stances, and I love that. But I've worked with a lot of them. And, um, let me tell you a story. 2 of the major products— a friend of mine, Ryan, uh, Ware, who's at Intel, he's a senior director-level technical leader at Intel. And when he was in charge, uh, leading the, uh, their, um, Linux kernel— they have their own Linux kernel, I think it's called Blue or Clear. Yeah, Clear. Um, Intel Clear or something. Um, He really wanted to get static analysis on it and get it running. So he did a head-to-head with 2 or 3 of the major products, and the best fidelity he could get after months of tuning was 15%. Admittedly, the Linux kernel does a lot of strange things, and you have to call what are called unsafe functions. You have to do a lot of stuff. that will look weird to any automation that's not set up for the kernel. And you can do a lot better than that, I know you can. But still, think about that, 15% fidelity. He had 75%, that was the best he had, false positives. 75%. Nobody's going to work with that, especially if you're throwing 3,000 or 4,000 findings a build. Nobody has time to go through those 3,000 or 4,000 to find the 5 that are really important. Right? It's noisy. It's covering up. And that's the state of the art today. And I know the vendors will tell me no, but believe me, I've had experience with every one of them. I can take them down. I can. If, you know, I won't publicly here, but— Of course not. No, of course not. And I'm not, you know, and a lot of these people are my friends. So, you know, I don't want to make enemies, but it's hard. On the other hand, here's the secret that I discovered many years ago at Cisco. when I led their web infrastructure and application security team, technically led, many, many years ago in 2004. We had been cracking our heads for months on how we were going to solve a problem of having 2,800 apps, none of which had ever been scanned, and it was scaring the heck out of us, really. And so, you know, our new head of security, Jon Stewart, very famous now, at the time not quite so famous, said, I want you to solve this problem, Brook. And we cracked our heads and cracked our heads. And finally I said, you know what? The problem is we're asking the tool to do something it isn't really designed to do. How can we make the tool do what we wanted? So we asked them, and it took 5 minutes, by the way. We asked our vendor, our scanning vendor, vulnerability scanning, so more dynamic scanning, DAST for those who are in the know. We asked them what was the suite of high-confidence tests, and it took them a few minutes to think about the answer because it's not the way they thought about the problem, and then they gave it to us. And suddenly we could turn this over to developers and say, run these tests. you won't get many false positives. And when you do, you really need to check it because it may very well be positive. And so that worked. In fact, that program is still running. We're talking 11 years later, successfully, because they can get every developer to run their own basic scanning. So here's what I discovered about that later on. Ron, all these tools have a set of checkers, or, you know, tests, if you will, that's very high confidence. The reason they put all the other stuff in is because they have to sell to security departments who want to see everything. If you reduce to start off, your baseline is your suite of high, high confidence checkers, and you hand those to developers— I've done this a bunch of times now and it really works— hand those to developers and say, here, especially if you can get that on their desktop so while they're coding they can check, you know, then you're using the tool in the way the developer wants to see, like a compiler. That's my basic comparator. Does it work like a compiler so that, yes, compilers have bugs, but I can trust the output 99% of the time, and if I see something weird, I have to write a piece of test code that eliminates everything else in my code to prove there's a bug in that compiler because it's very unlikely. That's the level at which I want to see these tools be run. And if you go for the set of high confidence checkers, you start getting that. And what happens then is developers, you know, they have a lot less findings. Sure, you're not finding anything. There's other ways to deal with that. But you're not finding everything. But what happens is that you get developer confidence. They go, wait, this is great, I'm finding my bugs, man, what else can this tool do? We've seen this time and again. The developers, once they get the confidence in the tool, then they say— if you let them, say, change the aggressiveness upwards, never below the baseline but upwards, and they start playing around, they'll find the tolerable place for their code base and their team's tolerance. what they can handle in terms of qualifying results and some false positives. And they will find a sweet spot. And it's different for every team and every product and every kind of software. So mandating that from on high doesn't work. But letting people find it is fantastic because they'll go above the baseline, most people, and they'll start really finding stuff And that you'll see in your— if you have external vulnerability reports, we actually saw this at McAfee. Our external vulnerability reports went from all the simple stuff, those disappeared or almost disappeared. You always have a few leaks, but almost disappeared in favor of much harder to find stuff, which is the stuff, you know, if I have external researchers who've got the time to play around with my software, I want them not finding some stupid cross-site scripting bug in an admin portal. which we can find just fine on our own.

**24:09 Chris Romeo:** Yep.

**24:10 Brook Schoenfield:** If you set it up right. But I want them to find that legacy mistake that was written for a threat landscape that was totally different, that now in the current thing is vulnerable, but it was cool 10 years ago, but we still have that piece of code in our stuff. I want them to find that because probably all those developers have long since rotated out or gone on to something else at the company. And you want somebody, you know, who's willing to find that and you say, thank you. Thank you, researcher. We needed to find that. Now we can talk about what we can do about it. That's where I want them to, you know, love having external people poking around in my software, not to find the stuff that any tool can find. That you should do yourself, right? And so that's been the secret of my automation success, and it works for static analysis or anything similar. And now there's a lot of things that are changing where they kind of combine static and dynamic and stuff. There's runtimes. products and stuff. So SaaS is changing, as all these things are, but just to talk about static as a category. And then that's because I consider that part of implementation. That's you're helping the developer get their bugs out from coding. And then you do the dynamic stuff. It works there as well. If the developer's going to do it, make it dead simple and make it easy and make it high confidence. And then if you want to apply much more skilled, have a, have a team that are much more highly skilled. And it doesn't have to be as deep as pen testing, although maybe in some products that's really necessary too. But all of these things overlay each other because, you know, they're not— none of them can be counted on to find everything because they're incomplete. Does that make sense?

**25:55 Robert Hurlbut:** It does. So, so it's a— it does sound like a— and I agree with you on the about developers. I mean, that's my background as well is sometimes you look at a developer and say, well, are they going to want to do one more thing? But essentially, I agree that— in fact, that article you mentioned was by Jeff Williams recently on DevOps.

**26:17 Brook Schoenfield:** Thank you.

**26:19 Robert Hurlbut:** Yeah. The developers, they just want to know how to do their job better many times and they want to understand how they can be more effective and by providing tools, helping them do the work that they're doing now, along with what the work they're doing now, rather than something extra, I think makes a difference.

**26:37 Brook Schoenfield:** You know, timing is really important, Robert. Um, and, and Chris, you're a master of this, but timing is really important. When I'm coding, I expect to make mistakes. And so finding my mistakes, you know, in my round of, okay, I think I got this algorithm, I think I got these set of functions or this module completed. Now I'm going to run some unit tests around it, but I also want to check it for security right then and there. It's really cool because I'm in the process of saying I got mistakes, I want to get them out. One of the problems that happens in a classic security program is then they don't do that. They don't focus on desktop and part of the natural process They don't enable that. Instead, they're going to do a major build and a major analysis, and by then I'm pretty convinced I got my code really clean, and you got to prove to me I've got an error. This is a mindset shift for many of us who develop. Not that I've developed anything serious for the last 20 years, or 18 years or something, but nevertheless, there's a mindset that says, I think it's correct. But while I'm working on it, it's full of issues, I'm sure of it. And so the earlier— that's that shift left thing that we see a lot in the DevOps talks, is shifting the testing as far to the left, or at least in parallel in a continuous testing, kind of a continuous delivery kind of process, continuous integration and delivery kind of process, where we get the testing going on even if it's not desktop right at the moment. But I that I'm coding, that's very powerful because there's, you know, you're working with the, with the way coding naturally unfolds. I know I'm going to make mistakes. I know I'm going to go down rat holes that don't produce what I think they are, or they're not as elegant as I'm going to end up with eventually. This is just, you know, crummy code that just sees if I'm in the right direction, and then I'm going to change it. You know, there's all of that experimentation stuff that goes on. And, uh, And you want to catch as much as possible in that process. And then you want to test the whole thing to see if anything's left, and you can be more rigorous and more robust about the test because, especially with static analysis, you have the whole code graph. And with dynamic analysis, you have the running beast. You know, and so those are very powerful too. They all complement each other. And should never be taken as the truth with a capital T.

**29:15 Chris Romeo:** Yeah. And it makes me think on the SaaS side. So, I love the in-IDE versions of the SaaS tools that exist now because when somebody's writing code, I don't want them to— I don't want the classic timeline that we always did in the past where you run the report maybe nightly or weekly and then send them the results And then one week later, they've already moved on. Their brain has moved to the next thing. And I want that—

**29:44 Brook Schoenfield:** Exactly.

**29:44 Chris Romeo:** I want that little buzzer to go off. Like, I want, when I'm writing a line of code and I do something bad, I want it to go, eh, try again.

**29:51 Brook Schoenfield:** Right, exactly.

**29:51 Chris Romeo:** Pop up a little flashy window and go, you might wanna take another look at that line of code right there. Did you really mean to take that data from the untrusted user and put it into a SQL query with a string? Maybe not.

**30:04 Brook Schoenfield:** Or dump it into a stack variable without checking the length or whatever, right?

**30:10 Robert Hurlbut:** Yeah.

**30:10 Brook Schoenfield:** Whatever the mistake is or not escape the input before you send it back to the user in the HTML, whatever the problem is. These are all problems, of course, as you both well know, you have to do, the coder has to do. There's no automation that does that for you. think about it. And so, you know, you're right, you give people the feedback, that buzzer. I love that idea. And that's what your compiler does. I thought I was all semantically correct as I understand the language, and then I get back, oh, compiler doesn't understand this. Okay, what did I do wrong? How did I express this wrong? Right? And did I express what I really expected? How, how, you know, Robert, as someone who's written a lot of code, and I ask this of many developers when I'm in front of developers. I say, how many of you have written a piece of code you were very proud of and it tests fine and it goes out into the field, and then 6 months later there's some wiggly bug that nobody can figure out, and you're looking at that piece of code and you go, oh my gosh. It's a good thing this is never executing or only rarely executing because it's completely wrong.

**31:31 Robert Hurlbut:** Oh yeah.

**31:35 Brook Schoenfield:** Very humbling.

**31:36 Chris Romeo:** Yes.

**31:36 Brook Schoenfield:** Right. It's very humbling. And when I say that to audiences, all— every experienced developer— now maybe the folks who are just new to it, they haven't had this experience yet, but everyone to a person raises their hand and says, yep, that's happened to me. And so you expect your code to have flaws because it's complicated. And besides, they're Turing-complete languages, and audience can look that up if you like. There's a great Wikipedia article on it. Turing-complete— that means you can express things in an infinite number of ways. So even if you think you've expressed it correctly, you might have expressed it wrong because there are so many ways to express a thing. I once looked at a— my first code review was of a piece of code that was written by a poet. He's also a great coder. He's actually in DC now doing stuff for the government around— because he's been a leader of a research lab for many years. Brilliant guy, Andrew Kern. But at the time, he— and he's a poet. He'd written his code as poetry. My young coder brain, I was like, oh my gosh, What do I do with this? I don't even understand it, right? He was a much better coder than I at the time. But nevertheless, there's an infinite way of expressing because it's expressive languages.

**33:00 Chris Romeo:** So, I'd like to just take a second here and kind of summarize where we've been just to see— I think we probably got time for one more kind of big idea. But let me kind of summarize what I've taken away here just help our listeners kind of qualify and classify the lessons that have been brought to us here, which are very priceless, I must say. The first thing that I took away here when I'm kind of summarizing, you know, you can't mandate a program. You can't use an executive mandate to start your program. You can't test your way out of the problem. This is a human— it's human plus automation working together to truly truly have a strong program. And we talked about some of the reasons why tooling is bad and some of the challenges that exist, the fact that the tools are noisy, they're hard to configure, and have high false positive rates. And you also mentioned the importance of asking the tool to do something, to do what it's supposed to do. And that advice about taking these tools and setting them up for the high-confidence tests is something that I think people need to take away from this. Like, Stop trying to get the tool to scan everything because there's a lot more danger happening there. I guess another best practice I took away out of your comments here was on top of preparing every developer to be able to use the tools to scan their own code, there is value in having a team of people who are focused on security testing that are going to be able to take their knowledge and experience to the next level and drive that out. That's kind of what I took away from what we've talked about so far. If there was only one more thing, Brook, that you could add to that summary, what is it going to be?

**34:43 Brook Schoenfield:** Culture hacking. Culture hacking. This is not my phrase. It's Nooper Davis, who's a senior VP now at, I think, a bank. No, she's at Comcast. And she just won a Women in Cybersecurity Award, I think, last year. Brilliant woman. Wonderful person, dear friend, but Nooper calls it culture hacking. One day I was talking about doing something, she said, Brook, that's culture hacking. I went, oh, I love that. So I named one of the chapters in my next book, which should be out either late fall or just start of 2020, Secrets of a Cybersecurity Architect, which will have all this stuff in it, by the way, and lots more. But the one chapter is called Culture Hacking just because I like the phrase. But it really is. You have to— we have to get developers— we security people need to learn how to integrate with what developers do rather than asking developers to come to us. This is, I think, you know, security has kind of been a special thing for a long time and We're the special snowflakes. And because at one time many security folks had the power of no, hopefully that's— yeah, we still do somewhat, but it's changed some because we're risk-based now, hopefully. But, you know, there's— and that due diligence responsibility will make you say no when you're nervous. It will. But one of the tricks in culture hacking that I've found is probably the greatest, along with sharing the design and threat modeling with folks, and I'll come back to that in a minute, is handing responsibility and consequences back. That is really back to developers. What I mean by that is saying, look, if there's a security thing that happens, an incident or whatever, We're not going to save you from that. Your code and your design is going to be under the light, and you are going to be under that light. You're going to feel that pain, and you're going to have to stop all your useful stuff and fix that. So, do you care about that? All the high-integrity people I know, and I know a lot of them, will go, wow, right. Of course, of course it's important. And what do we do? And you get people on your side by handing the responsibility instead of holding it and saying, it's my responsibility and you're going to do what I tell you to do. If we hand back the responsibility and say, this is a shared responsibility. My job is to raise risks and to find them. Your job is to try and build stuff well, and I will help you to the best of my ability and give you as much support as I can in doing that to the best of my ability. You get this shared model And that responsibility, all but the least integrity people will take it seriously. And it shifts the culture to saying, right, of course we are responsible for this. This isn't something I just toss over the wall and some magic happens that's called security. I'm responsible for this, and if something goes wrong, people are going to ask me about it. It's very, very powerful to give the responsibility back, the consequences back. When I say consequences, we kind of learned this at McAfee. What we did is we had all of our teams actually work their incidents, and the central team was just the coordinator and did all the legal-de-beagly stuff and made sure the right things were said, you know, to the public and the right risk was calculated and, and, and stuff like that. But we actually handed it to each team, and interestingly, after about 6 months, it was very bonding. Everybody started taking security really seriously because they were feeling the pain of their issues. Right. And, uh, it was a, you know, consequences, just like with your kids, natural consequences. You do something, you know, that, that's not so constructive, and you're going to feel the pain of that. And then, and then it, you know, your kids learn, hopefully. Um, mine did anyway, and eventually. But, um, you know, that's, that's very powerful. The other thing is to share. And in the sharing riff that I'm on is to share the process. Because what I found after teaching probably more than 1,000 people threat modeling, after running around the world teaching threat modeling to lots of different places and lots of different people, is that when people play at attacking their systems, even if they're not very good at it, they get the entire range of security in a way in their bones that nothing else I've found delivers. And it is a huge culture hack, is if you just, you know, maybe you finish the threat model with the experts, sure, but get everyone started looking at it, or at least train everybody in an introduction to threat modeling. It is the biggest cultural hack to build a culture of security, the fastest accelerator to a culture of security of anything I've ever found, because once people play at attacking their own systems, um, you know, even if they're just the obvious attacks or, or just one or two, they really get— and then try to defend them with something— they really get why security is important. And that's the most important part here.

**40:24 Chris Romeo:** Yeah.

**40:25 Brook Schoenfield:** And which brings me to one other thing that I'll just tag on here, and it's about DevOps, because a lot of times DevOps, everybody just focuses on the automation. DevOps is a another mental attitude paradigm shift about continuous improvement and continuous thinking. That gets missed in the conversations a lot, unfortunately. And it was in that Jeff Williams article, absolutely right there. So it was in dark reading, and I highly recommend the article. People can look at my tweet streams or yours, Robert, or whatever, and see that we were you know, retweeting. One of the things that get lost is the planning part. And not only does the software have to get planned at least to some extent before you start coding, and then more planning as you learn, um, because security improves through iteration. Rather than iteration being the enemy, it's the friend. You actually can improve security through iteration. You've both heard me say this many times before. But more than that, Your actual deployment and build chain needs planning and it needs security because how many breaches have we seen that came through the Kubernetes or the build chain or someone was able to insert their own malicious software into a product because the deployment chain wasn't tight? I mean, this happens. I'm not making this up. You both know this.

**41:54 Chris Romeo:** Yeah.

**41:55 Brook Schoenfield:** And because they didn't pay attention to that side, it was just for the run of the developers. Uh-uh. On the other hand, developers want to play, right? They want to innovate. They want to try the new tools and see if they're better. So, at the same time, it is critical that we give smart people a place to experiment and innovate that doesn't mess up production. That's their own place to really muck. And whatever happens, if it's good, let's work it into production. If it's terrible, let everybody know so nobody else wastes time on it. Right? That's so critical because that's what brings people to the work in the first place is their engineering mind, their desire to play with new stuff. If we don't, if we make everything like a factory, it's like factory work and nobody wants factory work. Well, maybe some people do, but engineers not really.

**42:45 Chris Romeo:** Yeah, they want to build cool software and do cool Well, Brook, it's been great to— I could sit and listen to you literally all day. I'm not lying.

**42:53 Brook Schoenfield:** Oh, you are so kind.

**42:54 Chris Romeo:** There could be an 8-hour version of this podcast and I'll just sit here. I'll just keep listening. You should see my notes I wrote down through here. But, I think for this is— I think we've reached the end. I'm embarrassed now. Certainly, I appreciate you and the ability you have to share your knowledge with others. Your willingness to do that. As always, I always just look forward to any time I get to talk with you and discuss all these things of software security and even things of life as well. So thanks for being with us today, and we'll definitely have a part 3 to this. There's so much more that we have to hear from you, and so we'll get that part 3.

**43:33 Brook Schoenfield:** Well, when the book comes out, maybe we'll do a podcast on top of the book published or something.

**43:38 Chris Romeo:** Yeah, that'd be fun. That sounds great. Folks, just remember, you can go to Amazon and look up Brook. You'll see— we'll put some links in the show notes for some of his other books. You should check those out as well. Take all this stuff in. He is somebody who's been there and done that and gotten the t-shirt a couple of times over, and he's got the experience that you really need to understand.

**43:57 Brook Schoenfield:** So, I get so many t-shirts now that I have to give them away to people who don't have so many t-shirts.

**44:05 Chris Romeo:** Well, Brook, thanks for being here today.

**44:07 Brook Schoenfield:** All right, you take care. It's always great to talk to you folks.

**44:13 Chris Romeo:** Thanks for listening to the Application Security Podcast. Our intro music is 8-Bit Kung Fu by Born and TJ, and our outro music is Southern Delight by Stefan Cartenberg. You'll find the show on Twitter @AppSecPodcast or on the web at www.securityjourney.com/application-security-podcast. security-podcast. You can also find Chris on Twitter @edgeroute and Robert @roberthurlbut. Remember, security is a journey, not a destination.

---

Source: https://appsecpodcast.com/brook-schoenfield-security-is-a-messy-problem/