In this episode of AppSec Builders, Jb is joined by security professional Jim Manico, founder of Manicode Security to discuss Application Security, Developers, and why they should be trained to build Secure Applications .

About Jim:

Linkedin: https://www.linkedin.com/in/jmanico

Twitter: https://twitter.com/manicode

Jim Manico is the founder of Manicode Security where he trains software developers on secure coding and security engineering. He is also the co-founder of the LocoMoco Security Conference and is an investor/advisor for Nucleus Security, BitDiscovery, Secure Circle and Inspectiv. Jim is a frequent speaker on secure software practices and is a member of the JavaOne rockstar speaker community. He is the author of "Iron-Clad Java: Building Secure Web Applications” from McGraw-Hill.

Transcript

Intro / Outro: [00:00:02] Welcome to AppSec Builders, the podcast for Practitioners Building Modern AppSec hosted by JB Aviat.

JB Aviat: [00:00:14] Welcome to this episode of AppSec Builders I am JB Aviat and I am honored to welcome Jim Manico, who, on top of being a famous, opinionated security professional, is also the founder of Many Good Security, where she trains software developers in secure coding and security Engineering he is also an investor advisor for many companies, frequent speaker on secure coding practices and a book writer with Ironclad Java Building Secure Web Applications. Jim, why don't you introduce yourself as well?

Jim Manico: [00:00:50] Jean-baptiste is a pleasure to be on your podcast and your show. And like you said, I'm an opinionated application security professional. I just hope that my opinions are helpful to you and your audience.

JB Aviat: [00:01:04] Opinions are always helpful, especially when they are held by smart people. So, yes, definitely. And I'm looking forward to have you sharing a bit more about that with our listeners. So, Jim, thanks a lot for joining us today. So when we are familiar with your work, we can notice that your primary focus is developers. So you train them, you write books to educate them. You contribute to a lot of OWASP resources around education. Why that focus centered on the developers?

Jim Manico: [00:01:40] I believe that the application security industry traditionally has primarily been about security testing and dev ops and all these different pieces that are about assessment of the security of an application. And I do not believe that you can achieve security through testing. I believe that the only way to truly do application security is to get developers to build secure software and to utilize tools and techniques and processes that will help developers, author, secure software. And I believe that our industry places very little focus on that important specialty because it's hard to sell an idea. The idea that you must change your process, you must change your engineering capabilities and similar. It's not something that sells in the marketplace. It's education, which is not a very big part of our industry. So that's why I focus on that, because it's my specialty and it's also my belief. That's how you really do application security is to enable developers capabilities around security in some way.

JB Aviat: [00:02:54] And a so you've been doing that for a while. What are the big changes that you have witnessed over the past year?

Jim Manico: [00:03:01] I think the acceleration of dev ops is very interesting. Now, Dev Ops has been around for 20 years. This is about automation around the building, testing, deploying in other aspects of the SDLC. And we were doing that in the late 90s through a lot of custom scripts and similar. And I think that today there's extremely modern tool sets like Jenkins', GitHub actions and similar, where I can build a significant security centric dev ops pipeline in a really short amount of time now, especially if I'm using GitHub actions. Click, click, click. And I got dependable that I got static analysis and some grep. I got dynamic testing and similar testing tools really rapidly in terms of setup. And I believe in a few years that when we're using GitHub in similar repositories, advanced security testing that we see today will be natural and automatic in just a few years. Other trends that I have seen are for more intellectual is the migration away from traditional session management and the movement of stateless session management using JSON Web tokens and the OS two and the open IDE Connect protocols and other JSON Web tokens centric standards. This is a very big departure and change around how secure Web and API applications are built. I also see a lot of new changes in HTP response headers, content security policy, the different response headers to delete site data at logout time, ways I can configure referrer policy or very granular now the advancement of cross origin, resource sharing and the capabilities being available in most every browser. I think that all those response headers have changed dramatically in just the last couple of years to give developers more security capability in modern browsers.

JB Aviat: [00:05:07] I definitely agree that don't get me started on JSON Web tokens, but. She already did, and that's a huge fan of the and we took in, because I think that's an interesting evolution in the world of security. It's a bit complex to configure. Right. There are several things you don't want to forget. And to me, that's a tool that has very interesting properties. But that is a bit hard to give, as is to developers like these specifically need the training and education in order not to misuse it. Right.

Jim Manico: [00:05:38] I've got to be honest with you. Using JSON Web tokens is radically more difficult. You now have key management secrets, management, the implementation of log out and idle time out, which was easy. In Session management is a challenge with Jason Web tokens that you can certainly achieve more scale. And if you're using micro services, you kind of need to use adjacent web token because it's difficult in a scalable, performance friendly way to tie sessions together among many small services. So, Jean-Baptiste, I really like the back and front end pattern, the PDF pattern where I have more of a traditional session between my JavaScript client or Web client and the main API that serves as a reverse proxy to a fleet of micro services that is back in my private infrastructure. So that way I can still benefit from the statelessness of micro services and performance, but still have a traditional session between the JavaScript client and either a gateway or a reverse proxy API. So all the mess of JSON, Web tokens and micro services are behind the scenes. So I actually agree with you. I really don't like JSON Web tokens when you push them to the client all the way. I try to avoid high powered access tokens and Jason Web tokens from being in a client in particular. I mean, like a browser web client, because there's no good place to store sensitive data long term in a Web client. It's just not mature enough for that yet. So if you're going to use JS on Web tokens or if you're forced to because of the use of micro services, again, the pattern is called the B F f the back and front end pattern, which basically takes the mess of micro services and Jason Web tokens and pushes it back into your private infrastructure aligned

JB Aviat: [00:07:37] With your line. Yes. Things. So I think that's a very interesting time to be in security today because. Yes. Of things evolving. You mentioned headers, Clinton's security policy. So, yes, we have a lot of new tools that are evolving and changing the security capabilities that are into the hands of the developers. So that's a necessary step in the journey towards being more secure. There is no question about that, though. Those tools and those security primitives are still extremely complex to implement. If you take a look at the latest security headers that are centered around the Specter meltdown, protections like the complexity of those is really insane. And I feel either we need weeks of training for the developers that will have to use that properly. And Fulu is the mess of like its original house brothers, etc. though we need something in between, like a layer that will automatically configure the application. And I think this is where there is a builder between what you can teach the developers. And no one has infinite time to teach developers and what the tools should be responsible of. And so you said one very interesting thing in your introduction, Jim, is that you teach the developers to use the right tools. And I think that's that's a big part of the business, is to help them find the right tools.

Jim Manico: [00:09:07] So let's talk about Spectre and meltdown briefly. Spectre and meltdown is the ability to read data out of a CPU cache. Right. And in my world, this is mostly a problem with the Web browser. Like I'm worried about Chrome and Firefox and similar having an attack with malicious JavaScript cross site scripting primarily, or a malicious third party library that allows malicious JavaScript to read data out of a CPU cache. And we saw a demonstration from Google who provided a JavaScript demo around exactly how this could be done. Now, how is this problem solved? The problem is usually not solved by a web developer building a website or an API. The problem is solved by a browser developer and I do not teach browser develope...