Loren Kohnfelder -- Designing Secure Software

0:00Chris RomeoLoren Kohnfelder has over 20 years of experience in the security industry. At Microsoft, he was a key contributor to STRIDE, the industry's first formalized proactive security process methodology, and also program managed the .NET platform security effort. At Google, he worked as a software engineer on the security team and as a founding member of the privacy team. Loren joins us to talk about his new book, Designing Secure Software. We start the conversation geeking out a bit about his work to create Stride and digital certificates. We then discuss facets of the book like secure software, security design review, and what he would implement if he could only do one thing to improve software security. We hope you enjoy this conversation with Loren Kohnfelder.

0:43Loren KohnfelderYou're about to listen to AppSec Podcast. When you're done with this, be sure to check out our other show, High Five.

0:52Chris RomeoHey folks, welcome to this episode of the Application Security Podcast. This is Chris Romeo, CEO of Security Journey and co-host of said podcast. I'm also joined by Robert Hurlbut. Hey Robert.

1:05Hey Chris. Yeah, Robert Hurlbut. Good to be here. Threat modeling architect. Looking forward to our topic today.

1:11Chris RomeoYeah, I'm so excited about this topic I could literally almost fall over, but I'm going to try to stand up here because But we'll get into why that is in just a second. But we are joined today by the author of Designing Secure Software from No Starch. And this is Loren Kohnfelder, who's joined us today. Loren, I've heard a lot about you over the years, and I'm so excited, and I'm sure Robert the same way. I'm so excited to get to finally talk to you and ask a whole bunch of different questions. So, thanks for being with us today.

1:40Loren KohnfelderWell, thank you. And thanks for the opportunity to talk about the book just out.

1:45Chris RomeoSo for our listeners, we always start with our guest's security origin story. So we want to give you the opportunity to tell us, how did you get into this world of security?

1:58Loren KohnfelderOkay. Well, I've been programming for a long time, and I think what comes to me as the dawn of the security realization that led to the modern age is, In the '90s, I was at Microsoft working on Internet Explorer. We're still back in version 3. And one day we got told, you know, we have to talk to this journalist. And a bunch of us were sitting around in the conference room on a big speakerphone call, and we found out that internet security was now a thing, right? And Explorer had been developed for years. Nobody thought about what could possibly go wrong. And, you know, to be honest, in hindsight, it was absolutely full of holes. We didn't even have anybody particularly looking at security. And I think, as is well known, there was a series of releases, of whacking of gophers popping out of new holes. And really, you know, the challenge is still with us, although we've learned a lot in the process. So it's interesting to me to think how naive everybody was. You know, we'd had the Morris worm in the late '80s, but still, you know, when Microsoft was pushing the internet, nobody realized this was a problem and we had to start getting serious.

3:24Chris RomeoSo you were at Microsoft, or you left Microsoft before the Gates memo though, right? So you were there in kind of the lead-up to it, or?

3:36Loren KohnfelderI think I was there a few months after that memo and then did leave afterwards. I was working on .NET and I was the security program manager for it. And we were, you know, we— I stayed there through shipping 1.0 and it seemed like it was time for me to take a break at that point, shall we say.

3:59Chris RomeoYeah, Robert's a big .NET And we had Steve Lipner on in a previous episode of the podcast where we did kind of a history of SDL at Microsoft. So, I asked him a bunch of questions about the memo just because I was watching it as an outsider looking in. But that's cool to hear that you were part of that early Internet Explorer team and part of— got to see kind of the foundations of security coming together at Microsoft.

4:27Loren KohnfelderOkay, good. And yeah, I mean, those early days led us to a realization that we had to get systematic about this after we had a little bit of a handle on Internet Explorer. And of course, that led to a bunch of innovation that was kind of a grassroots effort. I think Steve and a number of people kind of pulled everyone together and said, we got to figure this out.

4:54Also, Loren, your name, especially for us in the threat modeling circles, is fairly well known in terms of STRIDE and being associated with STRIDE. Tell us about that, the origin of STRIDE.

5:09Loren KohnfelderYes, thank you for asking. And that's something else again, nobody could have possibly foreseen, you know, that that would be anything we're still talking about here. But as I said, a group of people came together and One of the things that we did was there was a company magazine, I think it was called Interface, and so I teamed up with Prerit Garg and we signed up to write an article to try to tell people how to think about security and proactively, right, begin to understand what you might need to do in their products. And as a result of that, We got into threat modeling. I think, as I recall, he was much more knowledgeable about it from an academic background, and we learned about it, and then we were working on a taxonomy of what sorts of things do we need people to think about, and we, you know, whiteboarded on that for a while. And as I recall, I was in my office thinking, well, gee, people are going to have to think about these things every time they do threat modeling. We're gonna have all kinds of people all over Microsoft. That was our scope at the time, right? And so maybe we could do a mnemonic to make this easy to remember. And so I just fiddled around with the words a little bit and STRIDE popped out. And we put that in the magazine article and it seems to have stuck. But, you know, as you well understand, it's not the end-all of threat modeling. It's just one little aid. And it's a quick, it's a quick, you know, I don't want to say a gimmick, but it's a quick way to get some basics down. And I think interesting things to think about are, you know, what, what do we need to extend to STRIDE in various contexts? You know, what about privacy, etc., etc., right? Those things were way ahead of us at the time. And I don't mean to say we need to get a new acronym, but certainly it does need to evolve and it It's not the end of the work that's necessary.

7:12Chris RomeoYeah, and now we have Linden, which took some of its inspiration from STRIDE, focused on the privacy side. And so, when I think about STRIDE though, it's funny. I have what I'd like to describe as a love-hate-love relationship with STRIDE.

7:28Loren KohnfelderOkay.

7:29Chris RomeoSo, when I first started at Cisco learning about threat modeling and trying to figure out how to roll it out to lots of different people and lots of different engineers, I was like, oh, this STRIDE thing, it's great. It's simple. It gives us a mnemonic and easy way to teach people that don't know a lot about security, the things they can just think about. They're not just— because I saw that same thing I'm sure you saw when you created it, in that people would be sitting there going, okay, threat modeling. What do you want me to do? What should I think about? And so, I went and I was using it like crazy. I was teaching it. And guess what? Then I got too cocky. I was like, this STRIDE thing is just too easy. It's too simple. I'm not going to teach this anymore. And then after about a few months, I made my way back to STRIDE because I was like, you know what? There's really not any better way that I can find to teach the basics of this. And I always tell people like, this is something we want you to graduate from very quickly. Like, you can certainly use it as a reference, but if you're still threat modeling 5 years from now and only considering STRIDE, like, you haven't gone where we want you to go. But once again, I'm back to loving STRIDE, and I have for the last number of years. There was only a short period of time where I didn't because I got too cocky about about, you know, that it was too easy. But so, yeah, I mean, it's something that, it's funny, I use STRIDE at least once a week, like talking about threat modeling or teaching and doing things like that. Like, it's always something that it's just my go-to, you know? And so, it's amazing that something that you created, you know, what, 2 decades ago now?

8:56Loren KohnfelderYeah.

8:57Chris RomeoIs still, it's still floating around and you'll find it in every threat modeling book mentioned in every threat modeling webinar. Now, Loren, here's an idea. What if you got a dollar for every time somebody said strong? Let's see if we can— I'll see if we can work on that deal somewhere. But I wanted to come back around to the book here.

9:16Sure.

9:16Chris RomeoAnd as I was taking a look at the book and I was looking right at one of the quotes that was, I think it was either on the front or the back, maybe on the back jacket of it. And I'm going to read the quote just so our audience has a perspective on what it was. But I was like, Wait a minute, this is the guy that wrote this book that I'm talking to here? As the inventor of digital certificates, Loren has already made extremely important contributions to information security. He continues the path, that path in this book. That's Martin Hellman, professor at Stanford University. So I was like, wait a minute, Loren created the digital certificate? Like, this is a story I must know. So please tell me more about, or tell us more about this idea of how digital certificates came into being.

9:57Loren KohnfelderSure, yeah, I'd be happy to. Well, I was at MIT as an undergrad, And, uh, for the, uh, the Bachelor of Science degree, you're supposed to write a thesis paper. That's, uh, it's something like a light version, I think, of a master's paper. And I was in the computing lab. And, um, 'cause that's where they had terminals, right? That's, that's how we used computers back then. Terminals to a Multics system, I think it was. And right down the hall there was, uh, the offices of Ron Rivest and Len Adleman. Who I think I just found out, you know, had published this paper on RSA. And actually, I somehow got the paper, I think, out of the library and read it. And as it turns out, the original paper had kind of a clunky part of it which was called the reblocking problem. It's a little bit of a technical nuance, but, you know, you're doing prime numbers multiplication, and then you modulo the composite product of the 2 primes, right? And the thing is, when you're doing a 2-way conversation, right, your composite number that we're modulo and my composite number that we're modulo are different. And stop me if I'm too much in the mathematical weeds here, but it's how I got to know those guys. So if your modulo is a little bigger, you might produce a number that doesn't fit in my modulo. Right, because it's a little bit bigger. So therefore they had this clunky, well, then you have to break the message in 2 and blah, blah, blah. So I got up a little gumption after doing a little bit of writing on a piece of paper, and I walked into Ron Rivest's office and said, just reverse the order of your operations and it'll work. Right. And so they said, you're right, quite quickly, actually. And so then they kind of took me under their wing. I ended up doing this thesis with Len Adleman, and who's A, right, of RSA. And they were saying, so we've got this public keys are great. You can tell your public key to the world. And everybody was thinking like, we'll publish a phone book of all the public keys. And we were only thinking really military and banking at that point. Right? No idea that it would be as easy as what we're doing right now. And so they said, we'll publish these phone books and everybody will do that. And it's like, well, but they have to type in the long numbers and that's kind of clunky. And how do you know it's an authentic phone book? So Len suggested I look at the practical applications of crypto based on RSA. So, you know, long story short, I came around to, well, it's got signatures so we can have people sign statements about their keys and their identities, and then if you have a certificate authority who everybody trusts who collects those, that's all you need. You just need one root key to get started and the rest happens. So I wrote that up in my paper. I think I got an award and, you know, $100 or something and got invited to a party. Nobody thought about copyrighting it, or I shouldn't say copyright, I should say patenting, of course, which, you know, might have been a whole nother world. But that was it. That was my contribution. I'm glad that people are using it. You know, I don't need a dollar for every time that's used either, of course.

13:33Chris RomeoYeah. So I mean, you think about where, where certificates are used, though.

13:39Loren KohnfelderYeah.

13:40Chris RomeoLike, this idea that came out of your brain is like, on every personal computer, There's how many hundreds of certificates and CAs and all the browsers and everything. It's just fascinating. Like, you're somebody who can— we can look at you and say, you're one of the foundational blocks of the security of the internet.

14:00Loren KohnfelderYeah.

14:01Chris RomeoIs your contribution there.

14:02Loren KohnfelderThat's incredible. Yeah, I've been in the right place around. Actually, before, when I was at Berkeley, before I transferred to MIT, I knew Ralph Merkle. And he introduced me to Marty Hellman because they were doing a lot of foundational stuff. You know, they had like a knapsack. It was an early public key algorithm, etc. So I got to know Marty Hellman through that. And then when I wrote the book, I mentioned key exchange in it, and I just used Diffie-Hellman as something that the math is relatively straightforward, and let him know. And he wrote back and said, here's a, here's a quote, feel free to use it. So I slipped it on the back of the book at the last review before they finalized it, and that's how you found out about that. And I, of course, do talk about the certs and that stuff in the book as well.

14:48So, Loren, in your mind, what is secure software? I know that's what the book is about, but what does that mean to you?

14:57Loren KohnfelderYes, well, I like the question the way you phrased it because it is in my mind. It's not something that exists in the real world, secure software, I think. As a goal, you know, obviously not counting something trivial. And I mostly on the, on the first cut at that, I would say it's software that is not insecure in the sense that all of the ways that we know of and have chronicled, and a lot of those are listed in the book, that we know of, people have thought about and avoided them. Or mitigated them sufficiently, right? So a little bit you can think, I think, as an analogy as food safety, right? Healthy food is something that's been prepared properly. It's had proper storage. You know, there's a whole chain of custody. You didn't poison it with a contaminant. You didn't let bacteria get, et cetera, right? It's not something you ever perfect, right? It's more complicated than that. So, you know, the first cut, it's like you haven't done all these things wrong that we know happen and people can get it wrong. But then I kind of flip that back around and see that security measures can often get in the way or they can complicate it or they can make the user experience miserable. And so a lot of, you know, the reason for the focus on design and part of why, you know, I'm pushing move left is if you anticipate security problems, sometimes you can design right around those things, right, rather than going in one direction and then having to do a bunch of security slapped on at the end. So this kind of proactive, you know, it's a deft move, right? It's hard to do. If you set up your authorization and your authentication just right, it's really easy to use and it works smoothly and it can be extended nicely. So it can also contribute a lot, and I think security problems are, you know, at the root of a lot of the problems on the web, right? We can't just trust the whole internet to always be truthful and good and all that stuff, right, and identify themselves correctly. So therefore we have to layer on all kinds of mechanisms, and often that makes it clunky and has terrible side effects. So. Okay.

17:19Chris RomeoSo as I was reading through the book and looking at the chapter on security design review, I know you spent a good number of pages kind of going through that and talking about the steps and the process and everything. It just, it made me think about, you know, from your perspective, what's the difference then between a security design review and a threat model?

17:40Loren KohnfelderOkay, good question. The security design review, I should explain, I think is one of the unique things in the book that I couldn't find a lot written about it anywhere. And just, I think I should explain precisely what it is to answer your question. So when there's a design that's fully formed, maybe just short of final, it's great to review it. Right, and so the security design review happens at a particular point in the design of a piece of software or of an iteration. Threat modeling is a tool that you use in security design and in the review, but it can be used for all kinds of things and it should be used throughout the lifecycle and many different places in the process. You know, to expand on that, in the book I know there's a lot of great methodologies that have been developed subsequent to our early stuff at Microsoft. And I think those are great, and people for various reasons are going to use different ones, but I didn't want to get into that. I wanted to stay very broad and general and work on the concept. So I use Adam Shostak's 4 questions as my grounding and kind of a first principles approach. And then what I want to show how you use threat modeling to explore the space of possibilities in design, to see the impact of your requirements, all these things like that. And then at the design review, you've got this design which is written down and you're at a fixed point in the cycle. So you can say, okay, now I can, I can see it, it's in black and white, and now let's make sure that they've got it right. And that's— then threat modeling is really your main tool to look at it at that point. And then when it passes the review and necessary changes get made, then you move on. But again, implementers are gonna do threat modeling in their choices of various aspects of the architecture and the implementation and libraries they use, et cetera. SecOps people are gonna use threat modeling. In the book, I even described you could use threat modeling. We used it to childproof our room when we had a visitor with small children. You know, what are we here for? Right? What could go wrong? Right? Did we take care of it? How did we do? Right? So—

20:10Chris RomeoGood old retrospective at the end of that.

20:12Loren KohnfelderYeah.

20:13Chris RomeoDid we do a good enough job to deal with this?

20:16Loren KohnfelderAbsolutely.

20:19Chris RomeoOne of the things you said about the security design review in regards to SecOps or DevSecOps just made me think about how do you— what's your recommendation for folks? I mean, everybody's moving towards a DevOps world, or some people are even in a DevOps world. Some people think they're in a DevOps world, they probably never will be. But we're in different stages of adopting DevOps. And when I think about a security design review, Yeah. It seems like a more heavy thing. And when I think DevOps, I think speed. I think, hey, I'm pushing 50 times a day. Like, what are your thoughts on how DevOps and security design reviews kind of meet in the middle and security design review doesn't slow everything down to the point where nobody wants to do it because they're like, hey, we gotta go fast, fast, fast, and you're making us go slow, slow, slow?

21:07Loren KohnfelderOkay, excellent question. Let me say that operations in a sense is outside of my main experience, and in the book I don't go into a lot of operations things, but I do talk about it just to make sure that implementers are putting the product on a path so that the operations people will be able to do their thing correctly, right? They shouldn't, you know, ship the product out and like, I have no idea what happens to it from there. Right. You need to have some awareness of what's coming, but the actual decision. But to get back to your question, I was doing design reviews in an environment, and this, this is, you know, I've been doing them for 20 years, right? And in that environment, you know, like a new product or a big version change would get a design review. And other than that, people were just doing incremental stuff and it didn't get a lot of attention, which which is unfortunate, right? That's holes for it to drop through. And obviously I would like it to be more granular and get reviews plugged in there along the way. However, even if you're in an environment where stuff is pushing out very rapidly, I think then the design review really shrinks to fit the pace, right? And let me say, even like at Google, I was doing large systems. you know, big storage systems. I did Maps once. Think about Google. It was an older version of Maps, but, you know, it has a lot of stuff in it. And I did not, you know, look at the whole thing. The design documents I had were pretty high level, but still I think it was a valuable exercise. So it's, it's just a tiny fraction of the work that goes into the design and architecture. It's really just bouncing it off somebody who's got the security mindset Thinking in that direction, you know, asking you some questions to make sure you're not missing something. And as I said, it is on a written document or a facsimile thereof at a certain point in time. So I was able to reduce it to 6 steps and say, here's a little process for you. And it's a nice little gate, but those could be, you know, you send me a delta and I look at the red lines. You know, I just run it through my, my security mindset and I say, looks good to me. Right. You could reduce it that much if you need to move fast.

23:32Chris RomeoYou've worked a lot of interesting places too, Loren, by the way.

23:35Loren KohnfelderYes.

23:36Chris RomeoYou're just like, oh yeah, at Google, I did a design review of Google Maps. Yeah. Microsoft. Yeah. So I'm just, I'm, you know, once again, I'm just, I'm just taking it all in.

23:45Loren KohnfelderOh yeah.

23:45Chris RomeoAt RSI or at, you know, MIT where I was hanging out with, you know, RS&A. Yeah. Just kind of hanging out with those guys.

23:51Loren KohnfelderYeah. I never met Adi Shamir, but, but like someday we can talk about when I worked in Japan, 2 different SNIPs.

23:57Chris RomeoBut yeah, we're gonna have to do that another time. We have to get back to the book. I know, Robert, you had a question about implementation items.

24:04Yeah, you mentioned about implement— uh, implementing different items, but, uh, if at all possible, if you could narrow it down to one, uh, that you would say this is what you must do, uh, what is that and why?

24:19Loren KohnfelderYes, um, generally Those, those questions, when I hear them in interview, I think, oh boy, you know, how could you possibly, you know, what's your favorite movie or whatever. But for this one, actually, I have an idea, which is input validation, right, or the flip side, untrusted inputs, if you want to look at what's the problem, just because that's so pervasive, right. You know, inputs, everything has inputs, right, unless it's doing some sort of static calculation. And whenever you have an input that is not what you expect it to be, right, there's a chance that your code isn't going to— you know, I think probably everybody knows this, but not only do inputs insert problematic cases into code, but the other thing is that often attackers can drive them and they can control the inputs and do what they want. Now, of course, you can say, well, my code anticipates all possible sizes and formats and everything, right? And then you've got a huge testing matrix ahead of you. And probably, you know, if you don't set a gigabyte limit on the input, probably you're going to blow up and have a denial of service problem, right? So it's just not a problem. You can say we're going to write a little framework and then we're done. Okay. So yeah, I wrote a lot about it. I've got a number of examples and I think it's a super important topic that everybody needs to really get square in their mind because, you know, we deal with stuff like that every day. It's an input or it's indirectly an input from somewhere else being passed to you, right? And you don't know if you can trust what's coming. And, you know, if they always sent you JPEGs but then tomorrow they start sending you PNGs, you know, are you ready for that, right? It's a really hard problem because those interfaces is exactly where systems and components and developers point fingers at each other and say, I thought you were responsible for making sure that was reliable or whatever, right? So I think that's a huge area.

26:25Chris RomeoAnd so as we're coming towards the kind of the conclusion of our interview, from your perspective as the author, why should our listeners go get this book? right now? Like, what's your, what's your pitch for them as far as why they should go get it?

26:44Loren KohnfelderI thought a lot about that in the process of writing. And one thing that writing the book did, um, just to set this up a little bit, is at first I thought a book like this must exist. Fairly short, gives you a broad overview of the field, because we want to get a lot of, uh, people connected to software, working on it, not just developers, but all the people around them, user interface managers, We want them to have some intuition about what these problems are and what— how we have to deal with them and what they mean in the long run to the product. So I wanted to write a really approachable book. And in the process, I found that it's really hard to write that book because you want to stay very general. You don't want to go too geeky. On the other hand, programmers like to have code in the book. And so I've got part 3 has code in the implementation section. And so I was just balancing all those things in the process. So there are 2 points that I just drive into the book as hard as I could, and I had the editor, you know, checking me to make sure it wasn't going to absolutely be, be too much. One is let's get more people to better understand security, and whether that's somebody who's new to it or has been daunted by it, you know, get your toes wet, you know, this will get you started. You can learn a lot. Maybe it's somebody who knows something about security, they're not real confident. This can fill in gaps, you know, maybe you, you just read certain chapters and others you go, okay, yeah, I got that. And then I think even for security professionals who really know this stuff and, and live and breathe it, I think the way we talk about security and the way we interact with the people who aren't like that is really important. So I've tried to not just bridge that gap, but also help people understand ways I found that were successful at talking to people about security, you know, not be absolutist, you know, be flexible, embrace any little change you can get. So for all those reasons, right, I think the industry clearly, you know, we need to do something better. And more knowledge, more people involved earlier, All that is good. That's what's behind the book.

28:57Chris RomeoYeah, we definitely agree with you on that. Like, we wanna see more people get into application security, software security. You know, we wanna see more people coming out of university systems that have the knowledge that's in this book. And so, that's what's gonna get us all to that future where we imagine SQL injection doesn't exist anymore, things like that. Like, buffer overflows are a thing of the past. Like, we're all aiming in that direction. And yeah, I think this book is gonna help to, to get that knowledge base out there for people to be able to understand it. So, normally, we would ask you for key takeaways and a call to action, but I'm going to ask you for something else as far as what options do our listeners have to get the book right now? And, what are you and No Starch able to offer to our listeners right now to get the book in their hands?

29:53Loren KohnfelderOkay. Thank you, Chris. You may be reading in the newspaper about supply chain issues, and I don't know what that is, but the book was originally supposed to come out in October. And then it got pushed to January, and then they pulled it back. So the printing industry, the book distribution industry right now is really struggling. And of course, I'm going up against, you know, Stephen King and all the bestsellers coming out at this time of year as well. So No Starks has made heroic efforts. uh, to get this book printed as soon as they have. And what they did is they have the first copies of the book, uh, right now. They are shipping as of, I think, a week ago. And for this podcast, they set up a discount code that people can use, which is SECURITY25. That's all uppercase if it matters. There's an input validation issue for you. And that will get you 25% off. I'm not sure if it's just my book, I'm guessing it's just my book, but who knows. And then in addition to that, I will— somebody pointed out to me, No Starch is selling every— No Starch is selling the ebook now. And someone said it's a little more expensive. And the reason that is, is because it's without DRM. So they just send you a PDF and a MOBI and EPUB, I think. And they trust you to do the right thing with those. So those are available now. And I do believe if you buy it other places, it'll be locked into whatever your book reader is, you know, so you do have that choice also with no starch. December is the norm, is the big release when it would be available from all kinds of booksellers.

31:38Chris RomeoVery cool. Well, Loren, thank you for, first of all, writing the book. I enjoyed reading it and learned a few things along the way and wrote some questions based on some of the things that I saw in the book here as well.

31:50Loren KohnfelderGood.

31:50Chris RomeoBut thank you for sharing some of your stories with us. And you are one of the most interesting people in security that I can say that I've met. I didn't know most of the stories you told. I was like, oh, I didn't even know that. I just was asking a question. So, thanks for sharing your expertise. Thanks for writing the book. And we want to encourage our listeners to Use that discount code, SECURITY25, buy a copy of this book, buy a couple of copies. And here's my challenge now. I'm going to throw it to my— here's my call to action for the listeners. I don't usually get to do this. So, buy a copy for yourself and buy a couple of copies for the computer science students in your life.

32:29Loren KohnfelderHmm.

32:30Chris RomeoLet's put this in the hands of some of the computer science students out there because To Lauren's point earlier, like, that's how we're going to change the world here is by the next generation of developers getting this knowledge into their hands. And so, that's my challenge. Buy one for yourself. Buy a couple for some CS students. If you don't know any, I don't know, go to the local college and hand them out to people. Say, do you work with computers? Here, you need to learn this. Lauren, once again, thanks for writing the book. Thanks for being a part of the show. We look forward to a future episode where we learn about your life in Japan and the 25 other interesting stories I know that you have that I have to find out.

33:05Loren KohnfelderYeah.

33:05Chris Romeoa way to extract from your memory. So once again, thank you very much.

33:09Loren KohnfelderThat's great. Thank you so much for having me.

33:11Chris 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.