James Ransome and Brook Schoenfield -- trust and verify: Building in Security at Agile Speed

0:00Chris RomeoDr. James Ransome is the Chief Scientist for CyberPhos, an early-stage cybersecurity startup. He's also a member of the Board of Directors for the Bay Area Chief Security Officer Council and serves as an advisor to For All Secure and Resilient Software Security. Dr. Ransome's career includes leadership positions in the private and public sector. He served as CISO, Chief Security Officer, and Chief Product Security Officer across a number of different organizations. During this time, he's been building and enhancing developer-centric, self-sustaining, and scalable software security programs programs that are holistic, cost-effective, and operationally relevant. Brook Schunfeld is the author of Secrets of a Cybersecurity Architect and Securing Systems: Applied Security Architecture and Threat Models, and Building in Security at Agile Speed that he authored with Dr. Ransome, which that book focuses on software security for continuous development practices and DevOps. Brook helps clients with their software security and secure design practices. He mentors technical leaders to effectively deliver security strategy, and he consults as a technical leader for TruePower Positives LLC and SEC Consult America's Holistic Security Architecture Services. These gentlemen join us today to talk about this book that they've just written called Building in Security at Agile Speed. We're going to ask them a number of questions about the book, but also questions about how they've been successful in maturing software security programs. So you don't want to miss this conversation with Dr. James Ransome and Brook Schoenfield.

1:29You're about to listen to AppSec Podcast. When you're done with this, be sure to check out our other Show high five.

1:36Chris RomeoHey folks, welcome to this episode of the Application Security Podcast. This is Chris Romeo, CEO of Security Journey and co-host of the podcast. I'm also joined today by my good friend Robert. Robert, how are you this fine day?

1:54Hey Chris, doing well. Yeah, Robert Hurlbut, Threat Modeling Architect, and really excited, as we always are, about our topic today.

2:03Chris RomeoMost definitely. And so, we are joined today by Brook Schoenfield and James Ransome. And Brook has been a guest of the podcast a number of different times. And I'm just going to recount the story because we just talked about it a second ago as we were preparing about one of the recordings we did with Brook at the RSA conference a number of years ago. And we were sitting outside the bathrooms because it was so busy. And so, there was a little bit of a—

2:28Yeah.

2:28Chris Romeokind of a flush noise behind, but a great conversation. So I'll put that link in the show notes too, so you can go back and find those other episodes we've done with Brook. But Brook, glad to have you back on the AppSec Podcast.

2:39Thank you very much for having me. I mean, I love doing this, and you're both, you know, among my dear friends anyway. So yeah, all good.

2:49Chris RomeoThank you so much. Okay, Dr. Ransome, we're going to come to you for your security origin story. So Brook has already provided his in a previous episode, but we like our listeners to be be able to get a perspective about how did you get into security? What drew you into this thing that we do?

3:06Well, I think it's, I've always strived for positions related to jobs where I thought I could help people, organizations, and actually the country at large. I spent 23 years in various roles in the US government. I was a US Marine sergeant and retired as a US Navy commander and intelligence officer, as well as I had an early retirement from Department of Energy Lawrence Livermore National Lab. As a national security scientist and geospatial intelligence analyst, and I was also on the nuclear emergency search team there as a senior leader and weapons technology intelligence analyst. And in between all this, I was also a U.S. special agent specializing in foreign counterintelligence for 3 years with NCIS. But I gradually developed new skills while I was still in the government in cybersecurity so I could transition to the government world, because especially when I was getting closer to retirement. My first corporate job was as a CISO role for Applied Materials back in 1997, so I've been on this side for quite a while now. And since that time, I've served in 7 CISO roles, a couple of technology senior executive roles related to security, and over the last few years, I've been focused on chief product security officer type roles. Obviously those titles aren't really in vogue yet, but that's what they're calling them. Very similar to the, back in the CISO days in the '90s, people had CISO roles but not everybody had that title. But that's what I've been focused on over the last few years and been working very closely during that time with Brook. And early on in my corporate career, I also completed a PhD in information systems, specializing in information security. And I just recently completed my 12th cybersecurity-related book, of which Brook was the co-author. And that's about it. That's, that's kind of what my journey has been over the last— God, it's almost 46 years doing security-related work now.

5:11Chris RomeoWow, that's incredible. And before we even jump in, you know, I just want to mention that the book that we're talking about, Building in Security at Agile Speed, I've got my copy right here. So I am an owner of this book and they didn't even send it to me. It's my own copy because I wanted to— I wanted to read this and I wanted to learn. I know these, these gentlemen have decades and decades of experience and I look up to both of you as people that I can always learn new stuff from. And so that's why I'm super excited about this, because I legitimately have lots of questions for you. So, but I'm gonna let Robert ask the first question for this interview. Yeah, and same.

5:45Just enjoy your books as well. I mean, that's how I actually became acquainted with Brook is reading your book, Dr. a number of years ago and then going from there. So really, really great pleasure to have you on the podcast today.

6:00Dr.

6:00Ransome, my first question is, why do you focus more emphasis on the importance of people and process in secure code development rather than technology or over technology? I'll start. I'll do it more from a DevOps perspective. And I think DevOps is more of an engineering cultural change than a process change as it prioritizes people over process and process over tooling. Building a culture of trust, collaboration, and continuous improvement, of course, enables the acceleration of the software development lifecycle. And as you've already seen over the last few years, actually a couple decades, the Agile movement led to a cultural shift from command and control to team empowerment. And DevOps moves that shift forward and beyond. And that's something that both Brook and I have a really big passion on. We kind of go at it a different way, but we also go at it collaboratively. and it's worked out very successful for us. And DevOps also is more of an engineering cultural change than a process change, as it prioritizes people over process and tooling. And building a culture of trust, which is the most important thing, collaboration, and continuous improvement enables the acceleration of the— not only the software development cycle, but also the— it provides the ability to have a robust security development lifecycle within that SDLC. You can also, as you've also seen over the last, I guess, probably just over 2 decades also, is the agile movement led to a cultural shift from command control to team empowerment. I talked about from command and control what it did there, but also team empowerment. Again, a specialty of Brook and I when we're teamed up together. And basically DevOps moves that shift forward and beyond coding to a holistic view of software development and operations. And basically, you know, from that standpoint, from an architecture standpoint, that's what our book's about. It emphasizes not only the people part, but also process and technology, but people come first to make your program successful, particularly in a DevOps situation.

8:08Chris RomeoSo, is that kind of why— like, I was just thinking to myself, like, you know, I've read the book, I've spent a lot of time kind of understanding what went in here, but why this book? Why and why now? And, Brook, maybe you can give me your take on that one. And then, James, I'd love to hear yours as well on this one because, like, a lot of people write books and I know why I think it is, but I want to get your perspective on why now.

8:32Well, first off, because my dear friend, James Ransome asked me to do it. That's one of the most important things here. And I pretty much followed James into the pits of hell if I had to. So, you know, there's a lot of that. There's a piece of that that's personal, I think. But I think the book now— we wrote Core Software Security, or I contributed to it. James and Anmol wrote it, a lot of it.

9:01Yeah.

9:02But I did my fair share, about 30,000 words. That's a pretty good addition. And it was based on our agile understanding. And I mean, I've been working with agile for a while as a security person. So, I'm pretty agilized, not a word in English, but still, it's the best way I can say it. I'm really into it. I work my own projects in an agile way. And so, you know, We had as much as we could learn and do. And at that point, we had maybe one of the first, maybe the first truly agile security development lifecycles out there. And we developed that really specifically. But we've learned a lot and the world's changed. So, DevOps was some teams were experimenting with it. at that time, let's say 2013, 2014. There were DevOps teams. There were CI/CD chains. That wasn't like that common. And mostly, it was in startups. And people were experimenting or just getting going elsewhere with that. Cloud use, people were going into the cloud. There was a lot of concern about cloud and, you know, where you run. Roll forward to 2020. when we're busy cranking this book out. And these are commonplace. You don't write— you do something, you write firmware for your local piece of hardware or whatever. But when you're doing major things, and even a lot of like application coding and testing is done in the cloud because you can get a whole bunch of machines that are all different versions and do your testing or whatever. So the cloud is now normal. I love to see the, you know, marketing materials that still come up and say, are you worried about going to the cloud? And I'm thinking, who isn't in the cloud? Who isn't using major clouds? I haven't run into that for years now, right? And who doesn't have some, doesn't make use of some, like, agile thinking in their development? Very few. Few places. And I work with a lot of clients and I have to assess their security, software security practices a lot of the times and figure that out. And trust me, completely non-agile with nothing taken from the agile movement is very rare now and very specific. People who maybe write firmware or working on hardware interfaces and stuff like that where it's very the compile cycle, the build cycle is very torturous. You really want to get it right before you go through that, right? But for most development, there's at least some nod to Agile. So that's normal. And then, you know, wherever really fast tools for deploying and releasing can be used, whether it's continuous or not, is, you know, a function of the context. But all of that's normal. And we really wanted to update to how people build software today, not how people build software 10 years ago, but how do they do it today and show that security is not in the way, it's part of what you do. It's part of what you do. And I don't think— there were some things we said in Core Software Security, or I said, I'll tell you that, that are a little embarrassing considering how software is built. So, getting a chance to correct that and say, no, this is how you should think about it. Like, we were still thinking about threat modeling as more or less point in time. And, you know, Chris, you and Robert and I have talked just gobs about iterative, keeping the threat model as just part of what you do in order to do design well, right? Yeah. It's not a thing you do. It's something, it's a foundation, and you just do it, you know, and it goes along, and it's never perfect. Well, we wanted to say that, and we didn't say that in Core Software Security. So, there was a lot of updating in technique and learning since then that really was, once I got into it, was very important to me personally to get up to date with my thinking today. And that's the problem with the book. It's a point in time. You say the best thing you can in that moment. You know, in 5 years, I hope I'm not too embarrassed about what I said in building security at agile speed. I'll just leave it at that. James, do you have anything to jump in here with?

13:51Well, yeah, I think—

13:53Chris Romeoyeah, I do.

13:54Thanks for that. That was great. The one thing I'd add is getting back to the people part again and why we wrote that. The people part's even more important now as people have said, we're going to automate everything. So if we do dev— I hate the word DevSecOps, but if you're going into DevOps where security is actually built into it, it's not just automation because the key element of the talent that you have to have in a DevOps organization, and hopefully they're reporting into engineering, they're not an overlay from the CISO, which we may talk about later, is that the software security engineer, evangelist, mentor, whatever you want to call them, we call them product security champions. Sometimes they're called software security champions. There's even some other words for them, but they need to be developers first and security experts second as part of each product or application development team. And that gives them ability to grow software security architects over time. And that's what we talk about because ultimately these folks that are in, in these teams should strive to be— that should be their pipeline to be architects over time. Sure, they start out as a security engineer, or they may even be a prospective security engineer that came over, you know, as a junior developer or something. But again, they should be developers first, security second. It's much easier, as I say in most of my talks, to train a developer how to do security than it is an IT person that's never coded before. In many cases, there's some exceptions, but to train them into doing development. It just usually isn't going to happen. In fact, a lot of the CISOs and CSOs I know nowadays, they're going back— the younger ones are going back to learn how to program because this role has become so important in today's world. So that's another reason. First, you know, the first one that Brook already said is that we needed to update everything. You know, it's been out— that other book, the other book, Core Software Security, has been out there, what, 10 years, 12 years, something like that. And then, and we had to update not only that, but just to remind people that there's something more than just automation to all this.

15:59Chris RomeoYeah, that makes sense. And I just— one of my recent articles that I published on TechBeacon was Why Everyone in Cybersecurity Needs to Learn How to Code. And I called out CISO, GRC, threat analyst, and of course, you know, AppSec. That was the easy section to write. But yeah, I think that's so crucial for folks now. Like, if you want to have any impact in security, You just have to have that foundational understanding of how to code. And I was literally having a conversation with somebody that I was mentoring 2 hours ago, and that's what I told her. I said, you're not going to write production code, right? Like, you don't want my code in production. Robert's heard this before. You know, my code is dangerous.

16:39All of our code is dangerous.

16:41Chris RomeoBut the fact that I understand the mechanics, all of ours, yeah. I mean, could you imagine all the 4 of us building a web app, what would happen? It'd be like, OWASP Top 10 nightmare probably at the end of the day. But I think it'd actually be really secure. It would just be like 10,000, 20,000 lines of code to return one response or something. But yeah, I mean, that's the— my code's not in production. It's the fact that all of us, we have an understanding of how object orientation works. And that's what allows us to talk to developers because developers can sniff out if we don't know what object-oriented programming is. You know, to your point about, you know, there's a lot of stuff in your book now about the people and the culture side, right? Developers can tell if we don't know what we're talking about, if we don't understand them.

17:29If I could say, the thing is that there aren't enough security people to make the software secure even in a modest environment. But when you have 50,000 developers, You're not going to hire one security person to be looking at code for every 10 of those. It's not going to happen. There aren't that many security people. And, you know, I realized this a long time ago. What's interesting is James and I didn't know each other at the time when I realized this, and we were both doing the same thing. We were both pointing our way to what I eventually call developer-centric security. We were both saying, No, the developers are going to have to do this. And how do we empower and help them? And we were both tending— this is back in the aughts, you know, and then we kind of found each other in the universe, or actually, Jon Stewart found us for each other. That's the actual truth. But, you know, and then we could link up in our thinking. But I realized we weren't going to scale. There was no way. And when you consider there are 28 million— this is Evan's data estimate— 28 million programmers on planet Earth today, that's our problem space. And no way are you going to— you can't keep control of that. It's already— we're way past that point. So, I'm going to quote James. He says this when we're working together actually at roles and employed by the same company or on the same client or whatever.

19:07Yeah.

19:08James is always saying, you do say this, if you can't trust developers with the code, they already have it. That's ridiculous.

19:16Yeah.

19:17And I think it's a kind of a mind shift to realize that it's not— it's a people problem and it's a security trust problem. So I like to point out that it's not trust but verify because that but says I don't really trust you, I'm going to check up on you like I'm the cops. It's trust and verify. How can we all verify? Because we're all going to make mistakes and stuff's going to happen. How can we give you the tools and the processes and the training and the— I mean, you're so dedicated to this, both of you are, Robert and Chris, to training and imparting knowledge and everything. How can we do that most effectively so that you can do it? Because ultimately I can't do it for you, even though I can have written hundreds of thousands of lines of commercial code, by the way, in a past life. So, you know, I did at one time, was actually at least reasonably competent at this game. Not anymore. The languages have all moved on. But nevertheless, you know, I have written a lot of really interesting code. in my time. That was a long time ago. But we can't do it. I can't do it. There's no way. Instead, what you're going to ask me is, look at this piece of code. Notice that there's actually no issue with it, and this static analyzer is telling me I have a problem. What do I do? That I can do. But I can't go and, you know, that's the real problem. 28 million programmers on planet Earth.

20:56I think another thing to add to that, Brook, you just reminded me, is that the other thing we wanted to do is have something that was generic enough that fit as many organizations as possible. Because we were pretty proud of a couple of programs we developed together, but then we realized that they were cultural-centric for the cultures we were working with, the corporate cultures, that is. And so one of the things, not only that we wanted a generic SDL, but we wanted things that could be applicable to everybody no matter whether they were in application security or product security, if you differentiate between the two, and if you were a large, small, or medium-sized company.

21:36Chris RomeoSo the next specific question that we wanted to ask is You know, about when a program reaches self-sufficiency and maturity. What examples can you share? Because I know both of you have built many programs, worked and consulted on many programs. And so, we've got a lot of people that are listening that are in the midst of building programs or maybe they're early people. And maybe let's even just pretend they're maybe a little bit discouraged like we've all been at different points in building programs. What's success for them? What is self-sufficiency? What is maturity? What should they be looking forward to in the future to say, wow, this is when I'll know that our program has kind of arrived?

22:23Go ahead, James.

22:24You want me to start with that one, Brook?

22:26Yeah.

22:28Yeah, because Brook, I know, has a whole bunch to tag on to this particular one, the example I'm going to use. So, this is Brook and I both working on building a program for a few years. And we had dedicated product security champions for each product and actually each product group. It was, it was really nice. And to have the support from the VPs and the head of engineering— actually, the head of engineering hired me. I said I did not want to do that from a CISO perspective. I actually wanted to do it in engineering. So that was a plus. And so, you know, once we had everything approved through the VPs of each development organization, because we had quite a few at this particular company, it made it a lot easier to push things in the future. So we developed together a robust training program. We had a mature PSIRT over time, product security incident response team. We had a satisfactory budget because this had been baked in beforehand, and we even had developed a quantifiable product security maturity program, which is now publicly available. It was, it was really cool. We did all— it was very painful, Talk about going to the, as Brook put it, the depths of hell a few times, I think, as we went through that. Those are some things that happened. But it was at this one moment when the group of senior architects, actually a small group, and product security champions basically said, told both of us, I think they might have done it, but particularly myself because I ran the program, said, go away, we got this. We don't need weekly meetings anymore. We could do monthly, but continue your oversight. and support when needed, that's when I felt that, man, we've really arrived. And these guys were competent too. They were developing their own training programs because some of the ones weren't. They were doing the TED-type talks. They were doing all— they'd been mature enough and they were growing their own, all their own product security champions within their own organization. So it was self-sufficient and so forth. Brook's got a tagline for that that I think sounds much better, but Brook, maybe you can talk about some of the things we did when we developed that one. 'Cause I don't know if you, I can't remember the individual or individuals that said that, but I've kind of, I drew back a bit and said, wow, what is that? And I said, oh, this means we've arrived. We don't need, 'cause we didn't do it with a large program. We trained the trainer. Yeah.

24:48There's a virality, an organic, you know, viral nature of things that begins to show itself. And it'll manifest since we require everybody, not require, but encourage everyone to share their skills. That's how you build, you know, and the people who are moving to the upper echelons must, they're required to train skills. And it's a mark of your, and that was part of their distinguished engineer what they call principal engineer, but distinguished engineer program anyway. You got to be mentoring people and sharing what you know. So if you wanted to go that route in your career, you had to do it anyway. But we were encouraging people anyway. And when you start to see that teaching and it's several generations so that the people you originally taught have been teaching and their students are teaching, and their descendant students are teaching, then that's one sign. So you're looking for this, that people care, because that shows motivation. I care about this. You've done the cultural change that says security is important. I don't have to talk about that anymore. Everybody's got it, right? And that it's starting to have its own life, as you will. So teaching is one. ability to say, building their programs. So eventually, if you first start with maybe a senior person who's the head for a group, but they then, you know, start teaching and training and working with a whole crew of people who are carrying out stuff, and those people become your security architects or engineers or whatever. And they start flowing into the program so that that virality, that nature of organic building is taking place without you doing anything anymore. That's number one. As the number of threat models— now imagine I'm the most— I'm in charge or I'm leading, that's my title, product security architecture. So threat modeling is my baby, right? When I'm looking at a lot less threat models and only the most difficult ones are only the ones that are getting escalated because people can't agree or it's beyond their capability and they're looking for help or whatever, right? Or when I'm only looking at those and I'm not looking at any of the project or product threat models because they're all there and all being taken care of, and I only get a few questions. When the senior person is no longer being dragged into every threat model or even only a few, that's another sign that people are doing it, right? When you get, you know, I'd get a report, well, this team isn't doing static analysis. When that's only one, of several hundred, you know you're there. So, there are all these signs that you're doing that. I'm going to talk about a couple more, though, because they're interesting to me. We also were watching carefully not only the numbers of things being reported from the outside. Now, we're working— at that point, we were working at a security company. So, of course, we're going to get external reports because you're always a target. Everybody's after you, right? But, you know, most companies get external reports. We were watching that data like hawks. But the interesting thing is the simple things disappeared. The number of cross-site scripting, we get a couple a year as opposed to one a week when we first started, right? And that— those simple things that you can catch yourself with with common tooling and due diligence, they disappeared. And ever more difficult to set up and exploit things were showing up. That's another really good clue that your program has been working. It's a real definite metric to watch. What are people reporting from the outside? When the reporting simple stuff that you could catch with a common DAST, dynamic assessment tool, or with a good combination of static and dynamic or a combined tool or whatever you're using, when you can catch that stuff and it no longer shows up very often, but what you're seeing is this really difficult to find stuff, I had to turn my head sideways and do all this configuration stuff. And then I found that I could muck with your driver. That kind of depth, right? That's the kind of metric to watch because it tells you that you're actually effective. And you want to find that hard-to-find stuff, but you want people who are good at finding that stuff not to be telling you about some simple, you know, OWASP top 10 thing. You want them to really be working hard, and maybe even have to do artificial things that will never show up in the real world, because then that lowers the risk a lot. You know, and, and that's what you want them to hunt, really hunt and work hard. And we saw that, we definitely saw that. And we were like, yeah, okay, we have an effective program.

30:36How's that for a couple of things you can watch and actually measure And look, if I could add to that too, the other part of it that people, you know, to be a good leader in an organization, you have to understand the business side. You can't just develop code. You have to, if you want to keep going up in your levels, you have to have the business side. You have to know how to do operational management, which is much different than IT management in many cases. especially in a development side. You also need to, you know, know how to deal with pieces. There's a variety of things and also politics. You know, nobody likes to bring that up, but politics will be there forever. It doesn't matter what type of organization. Hopefully, you get it down to a minimum. So, when these— the same thing as Brook— when these things stopped escalating to me because I had special mentorship programs where I would mentor them in those 3 primary areas, and all of a sudden, the business side, they're taking care of with their own VPs. they're taking care with their directors. They're doing the same thing with— I get less and less political escalations where they don't use me as a crutch. Well, we'll just— if we— if it's not what we like, we'll just escalate it to James. You know, I got very few of those. And so all these things that Brook and I both talked about, those— that was a culmination. And when these people said this, because otherwise, you know, somebody could say, oh, we're ready, um, but we knew it because all these things had happened and we knew from watching it for, what was it, 5 years, it had matured to the, to the right place where they were basically a self-developing program.

32:11Can I just say one, one, one little addition? There is one point at which I do step in, and I'm happy to. I'm, we are all, I'm all about empowering people to just do it because, you know, people are going to make mistakes. That's okay. You just try to cover that.

32:30Right?

32:30But, and, you know, we all make mistakes. We all get it wrong sometimes. But there is one place. When one of my security architects runs into their own manager, I never want to put a security architect or a security— any security person trying to fight for security in conflict with their own management.

32:53Right.

32:54You know, if it's all good and they're escalating, just as James said, that's great, fantastic. But if they come to me and say they told me to not work on this anymore and they don't agree, then we pick that up because I don't ever want to put somebody in conflict with their management. Their bonus, their, their, their, their promotions are all in the hands of that person. And you never want to put somebody— so that is one place where we would just grab it and say, we got it. And we would go over that person's head and go to, you know, more senior management. And we'll take the flak. We own it ultimately. And that's, that's actually one way that, that you really tell people you're in their corner for them completely and you got them covered, which is an important part of this. Again, we're back to people. If people feel like that they're just being asked to be spies on their, on their teammates, Forget it. That's a kiss of death. You want them to be partners always and carrying some specialized knowledge that everybody needs and showing value. And the moment you put them in conflict with people, that's something I'm watching for constantly. So, that's another metric. The less of those you do, the more your program's actually working. But you will have a few of those.

34:13Yeah. Yeah. All of them.

34:19Chris RomeoIt's interesting how we end up kind of coming back to the people, right? We keep coming back. It's a lot of the people. It's people, process, and tools. But the process and tools, if the people aren't doing their thing and executing and empowered and they're feeling like you're going to stand up for them, you can spend $100 million on tools. You're never going to get any better.

34:40It's all about building that trust, especially.

34:41Yeah.

34:45Chris RomeoSo I think that was— yeah, that was some— that was just a lot of really good guidance. I am literally going to go back and listen to this interview when we post it because I want to hear that again. I wish I could rewind, but I agree. It was—

35:01that's just—

35:02Chris Romeothere's so many good things like Brook, right when you started off, I was thinking I had this picture in my mind of like this family tree. of you started teaching somebody, you know, and then it kind of like, it's almost like we have security great-grandchildren and security great-great-grandchildren that are, you know, people we have taught have begun teaching other people. And that's, I mean, I know you guys are, everybody on this interview together, we all, that's what gets us out of bed in the morning. Like, at the end of the day, we want to empower customers.

35:29I'm going to name a couple of people here. They were my dedication in this book. So, you've already read these names, and I don't mind saying them because they're fantastic people. But when you look at someone like Sandeep Kumar Singh, who's a very quiet man, and today he's a really well-thought-of security leader in India. I mean, like, speaking at conferences regularly, and people were turning to him years ago at our job. But, you know, when I see that, I'm so thrilled. I'm so blown away that maybe I could have had just the smallest little piece in helping that along. It is the payoff, or one of the big payoffs in my life, is that, you know, many people, grandchildren, our great-grandchildren who are who are out there being incredible. Oh, one of my interns, I just noticed she's the CISO of some bank in the Middle East. Yeah.

36:42Oh, that's so cool.

36:49Chris RomeoSo cool to have that legacy. You know, it's about a legacy. Like, we like getting paid our salaries and stuff like that, but truly empowering people like this, this just makes you feel good about doing something to make the world a better place.

37:06Absolutely.

37:07Chris RomeoI love that about— and a lot of people, it's funny how we all kind of tend to congregate to people that think like this. We tend to connect with each other because this is what we love to do. But before we run out of time, we want to make sure we ask a couple of questions from the book. And so, Robert, I'm going to let you go first and ask one of your questions specifically from the book, and then I've got one as well. But Robert, what do you think? What's one question from the book you'd like to ask these guys?

37:31Yeah, I think I'll start with chapter 1, actually, that progression from Waterfall to Agile to Scrum. And the question we have is, is Agile dead? You know, some people have all kinds of thoughts on that, but that's the question. Is Agile dead?

37:47Chris RomeoSure.

37:49You want me to go ahead and start that one?

37:53Brook?

37:53Yeah, Dr. Johnson, why don't you go ahead, please. Well, I think despite the many articles, and we've seen a ton of them, that have proclaimed Agile is dead, I think it's barely taken a glancing blow, and I believe rumors of the death of Agile have been greatly exaggerated. 2 decades later since it started, the movement, of course, has already succeeded. Project methodologies don't— but they don't die quickly. There will be Agile projects for a long time for the foreseeable future, and I think Agile will reduce in popularity. Nothing really ever disappears in software development. For example, Waterfall is still being used, COBOL is still being written, and Agile's underlying principles and values are now pretty much table stakes for any organization. The degree to which an organization is applying Agile is now a matter of small increments of productivity rather than the revolutionary game changer. It's just not as sexy as it used to be because now you've got to do these smaller increments of improvements. However, I believe the challenge and opportunity for the industry is to move past the misuse of agile and focus on underlying principles. I can't tell you how many times I've seen agile being misused, not only within the development side but within other areas of IT, and it just— it's set up for failure. Although there's some new project methodologies coming up that fill in the gap for that. The opportunity is to look for competitive advantages and new ways of working like the disciplines of project management that can bring the advantages that agile has, but you just want to enhance it for the shortcomings that it has. New languages, tools, project methodologies will become more popular and reach bubble phase, but eventually people realize that there's really no magic formula or tool to create projects on time. I think that's why people say it's dead because they thought it was going to be this magic tool and nothing else would ever be needed. People are the reason— getting back to people— people are the reason for success or failure, while project methodology, technology, and programming language are the tools used to create software. There will always be lots of different project methodologies. There'll be others, and there are some now, whether in Agile, and people saying that the new methodologies are great and the old ones are dead. That's just going to continue to happen. So from my perspective, I don't think it's dead. There's a lot of things that are out there that are potentially— I wouldn't say replacing it, but more enhancing it. Brook, what are your thoughts on that? We probably have a little disagreement on that one.

40:31I will note that some people do love to fight about something, vi or Emacs. And all the old programmers are going to laugh at that, vi or Emacs. And the number of arguments over what editor you use, use what works for you. I don't know. Why do I care if you like Emacs unless you screw up the tabbing and I'm doing tabbing in a different way and it screws up all the structuring of the code, then no, I won't like that. But I can just run a script and fix it. So, you know, these are kind of silly arguments. I will point out that to me, that Scrum is an expression of Agile and it's not opposed to Agile. It is an expression of Agile, at least in my understanding.

41:22Yeah.

41:22And I've been through the training. I've worked with it a lot. It's one expression with a whole bunch of rituals and other things that are an expression, but there's other agile things. It seems to me that agile has become part of the woodwork, and I wonder if people are a little bit upset because their precious baby is now used in semi-rigorous fashion that huge, you know, global corporations and somehow my baby isn't as pure anymore. I personally don't care. You know, the core tenets of agile thinking, that it's better to iterate than it is to try and get it all at once. I mean, most of all of us have all read The Mythical Man-Month, and I'll just put that out there. I know it's an old, really old book, but If you're in development, you should understand that throwing more people at a project just by itself will just slow it down. And Agile addresses that problem by turning it into a team. And to me, DevOps just goes another step. It says, hey, this is working for us. Why don't you ops people who run this stuff come in and we'll do even better communication and more feedback? and will really, really think through how this whole chain is going to work together and how we can use these tenets of iteration and, you know, small work bits that we can control, keeping our work in process really, you know, down, thinking at the end, did we do a good job? What held us up? How can we improve? You know, all of these various things that that Scrum uses as part of its expression of Agile have now been offered to the ops community and they can improve. And besides, we're all working together. So, you know, it— to me, that's just another step to say, yeah, come on in, this is great, the water's warm, it's, it's really great, and, and we'll have a great time swimming together instead of, instead of you being in your pool and I'm in my pool and, and I toss you the application ball over there and Do something. You know, that had a lot of problems that DevOps solves. But I just see it as one train of thinking. And, you know, here's the thing. When I was a programmer for a living, I did a lot of really cool things. But one of the things I had to do repeatedly was write device drivers for every operating system known at that time, real-time, you know, communications device drivers. And I thought to myself sort of at the end of that, if I write another device driver, I will absolutely go crazy. I'm really tired of writing device drivers. And what Agile does, and DevOps, is get us off the train of a factory floor and turn what is essentially a creative activity back into a creative activity.

44:30Yeah.

44:30activity that's joyful, where you can take pride in work. And you do take pride in work because at the end of every sprint, you look around and you say, what could we have done better? And what was in our way? Let's find that one thing that was in our way this sprint and address it in the next sprint. And then, we'll be better at what we do. And that just calls people. One of the things that I've discovered in my career is When I'm excited, yeah, it puts some people off. It does. But most people go, wow, he's excited. I wonder if I can join that and be excited too. And that's better. That's more interesting. I enjoy my work more. And the other thing is when people start to see that things are changing and being more effective, that calls everybody who likes that to you. And so, To me, Agile, Scrum, and DevOps are all in that same category. Again, we're back at people and culture here. It's calling the people who care to do a great job and have some empowerment and responsibility for that. And that's very powerful. So I don't think that way of thinking— it may get new expressions and there'll be fashions in VI or Emacs, You know, take your choice. You know, religious wars about editors are just really— there are better things to think about to me. But nevertheless, you're always going to have some people who are, you know, want to make noise. Okay, whatever. Yep.

46:06Chris RomeoNo, it's good. It's funny, I'm in the next hour or two heading into a sprint retrospective.

46:11I'm about to do.

46:12Chris RomeoSome of the things that you're talking about here. But my final question, I have about 100 questions from the book, but I'm going to catch you guys in different places to ask this in the future. But I do want to ask one, but we're going to do a lightning round.

46:24Okay?

46:25Chris RomeoSo, I'm going to give— I literally have a timer in front of me. I'm going to give you each 60 seconds. Dr. Ransome, I'm going to give this question to you first and I'll set it up. I won't hit the— I'm not running in your time right now. I'll set it up and then I'll hit go. And then, but in chapter 3, you talk about penetration testing. And so penetration testing for me is a bit of a soapbox. I think as an industry we put too much focus on it, but you guys talked about it a number of times in the book. You ingrained it here. And so I want to get your take on what's the value of pen testing in your eyes. And Dr. Ransome, I'm coming to you starting.

46:58Okay. Well, I think in order to ensure that security is cohesively blended into DevOps, pen testing should be performed on an ongoing basis to keep up with it. continuous developments. Realistically, manually performing penetration tests can be tedious tasks as it might slow down the development process, and if that happens, following DevOps principles will yield no benefits. That said, there's a critical need to conduct automated security tests to identify flaws, vulnerabilities, data leakage, and loopholes in a timely manner, but they must be done appropriately for DevOps environment in order to provide value. These tests also need to be conducted at a frequency such that they do not hamper the development speed while at the same time enhancing security. And to start with, a properly defined plan for security in DevOps must be laid down to be successful.

47:51Chris RomeoNice, 55 seconds. You had 5 extra seconds, but it was good. Good answer. All right, Brook, what's your take on that in a 60-second answer on pentesting?

48:03Is a unique combination of tester skill, tester tools, and tester understanding— that is, the tester's threat model of the target system. So that already limits its scope. Okay, I'm not saying we don't need pen tests. I think I made it abundantly clear it's a key component. We're making up with human knowledge and skill for the lack in what we can do with tools. So it's just another layer of defense in depth because it's another screen because it'll be a different set. But I don't want my pen testers to be trying to do what my tools have already done well. I want them to be doing more complicated things, more difficult things that require a little human analysis and go beyond what the tools will do. So, no tool jockeys. I want real pentesters. So, that's the first thing is they're unique. Second, the pentest or the whole testing regime, but especially pentest, is the proof of my threat model. So, I need to have my threat model proven. It's a guess. It's a really deeply educated, if you're doing it well, guess, but it's a guess. So, you get the pentest to come out there and say, Yeah, you missed this one. Right on here. Those defenses are really good. Yeah, that works. These are a little weak, and here's why, but you got something there. You know, it's your proving ground. And so there's a really important feedback loop between threat modeling analysis and pen testing. Finally, I don't ever want to hear, they should have pen tested their code. Because there aren't enough pen testers on planet Earth. They're very expensive. And if we were to cover all 28 million programmers with pen testing, we would put 90% of the businesses out of— software businesses out of business because they wouldn't be able to do it. So, it's a scalpel. We want to use it like a scalpel. It's surgery and use it that way.

50:12Yep.

50:18Chris RomeoAnd I mean, proving the threat model. I guess I've never— you probably said that a bunch of times and I just never heard that. I'm going to think about that a lot.

50:26It isn't my idea.

50:27Chris RomeoI never thought of pen testing as proving my threat model. I forgot who told me that. I'm sorry to say.

50:32I normally credit people with their work. As you know, I'm really rigorous about that, but I forgot who told it to me. And the moment they said it, you could see the light bulb go on over my head.

50:44Chris RomeoRight.

50:45And so, yeah, it's become part of my song.

50:47Yeah.

50:53Chris RomeoNo, that's good. I'm going to think about that some more into the future. And so, I'm going to share the key takeaway here and Building Insecurity at Agile Speed. I'm holding up my copy right here so people can see. The link will be in the show notes for where you can get this. All the depth that you just heard in this interview, it's in the— it's on those pages. It's in the book, their experience, how they do it. I mean, I had other questions even about security GRC and development of architecture talent. There's a lot of different things that even someone like me, I've been doing this for a while and I had, I had questions based on things that they've done in their experience that I've never even heard of. So highly recommend get a copy of the book, read it, you know, take it in, think about it and apply it in your programs. And Dr. Ransome, Brook, thank you for being here with us today.

51:39Thank you for having me.

51:40Chris RomeoAnd thank you for all that you do for the community.

51:41Thank you.

51:42I have quoted Robert's past presentations in my presentations. So, you know, you two are, you know, you talk about us being deep, but, you know, you two are among my not only just favorite people in the industry, but I also learn a lot from you and have over the years. So, you know, it's not— it's a two-way street. I'm a big fanboy of you two.

52:06Yep.

52:06Likewise.

52:07Thank you.

52:07Chris RomeoThanks for listening to the Application Security Podcast. You'll find the show on Twitter @AppSecPodcast and on the web at www.securityjourney.com/resources/podcast. You can also find Chris on Twitter @edgeroute and Robert @RobertHurlbut. Remember, with application security, there are many paths, but only one destination.