Developers vs. Security Training with Jim Manico

AppSec Builders

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 developers. I teach the masses of Web and API developers how to build secure web and API applications. But the defenses that really stop spectre and meltdown with my understanding. Traumatised is like site isolation and similar that is built into browser technology, also the use of an HTTP only cookie will also help in stopping these class of attacks. And I do agree to teach a browser developer how to be more resistant to CPU attacks like Spectre and Meltdown. That is extremely sophisticated knowledge. But as long as Web developers and API developers are using basic security principles, they're doing OK. And the other thing is, if someone is using a very old browser, there's very little a developer can do to stop these classes of attacks. So I also recommend that developers as much as they can, they use JavaScript detection to understand what browser is being used by their customers and as best as they can do not allow older browsers to use their sites and APIs. So luckily, it depends on which developer you're trying to influence for Spectre and Meltdown. I need to influence the browser developer and for web for the standard web API developer. I'd like them to use HTP only and other cookie protections and to also make sure that they're only allowing as modern of a suite of browsers as they can possibly get away with.

JB Aviat: [00:11:38] Yeah, I would even say we have to influence you designers and of the browser vendors. But I think one of the flaws here was that no matter how safe your browser getting JavaScript execution in one page, which is not so hard, if you think about server kind of attacks on Fatty's, for instance, would allow you to read any part of the memory. And that's something that doesn't depend on the browser, actually, because it's like just running JavaScript. And I think that was the big demonstration of the Google demonstration making you like a Specter expedition mainstream. So one of the way to counter that was that Scerri a very complex idea such as Skouras, etc. And I think that is the same story for about any kind of interface for API that is very complex from a security standpoint. And you have examples, for instance, of tools that made the life of security protocols easier. And so one example that I like is in the ACL, for instance, the crypto library that took a very opinionated stance that what kind of helper's it will offer to the developers. So it's much less flexible than a regular crypto API, but you don't need to be a security expert in order to use it. What do you think about those initiatives?

Jim Manico: [00:12:58] First of all, you mentioned NaCl. So this is a cryptographic library conventionally known as Lib's sodium. I believe that does correct. Yes, it does. Good crypto in a library and I think that is a great idea. They are very opinionated in decisions they made there that have stood the test of time that are very good. I believe similar libraries for crypto like Google. Google has a library called Google Tenke, which is also exceptional in the very opinionated decisions they made. And so I like that idea because Salib Sodium and Google Tenke are really usable utilities, even though they're opinionated, they're not so opinionated, where they're not usable, they're very usable and very straightforward to use. So if you're being very opinionated but still providing usability for developers to author software, I do like that idea as well. And I do not think that the suggested defenses around stopping Spectre and meltdown are reasonable. And I don't think that's the way the problem is solved. I think that, again, I believe the problem is solved in the browser itself and Firefox and the Google team and other teams we're building browsers are actively working on making those protections automatic by doing various types of browser isolation and other types of defenses. But to your point, if I do get JavaScript execution in a website, yes, I can likely read the CPU, but I can also do request forgery.

Jim Manico: [00:14:29] I got cross-link scripting. I could modify content. The point I'm trying to make Zapatistas any kind of cross site scripting event is game over if the attack executes. Yes. And to your point, I don't think the real issue is spectre and meltdown. I think the real issue is that cross site scripting defense, otherwise a better name would be content. Injection defense in a web application is madly destructive and there's no simple way to stop that. The common developer who's using backbone and angular and 30 other JavaScript libraries, it struggles to keep them up to date. Massive amounts of JavaScript code. They're almost always. Going to have cross site scripting, and even if you're using the latest version of react with best practices, it is still easy to make a mistake in a variety of different ways that will bypass Riak security. And so I think that's the bigger problem. Zhovtis, not Specter meltdown or how to approach it, but just how to build a secure user interface on the Web period. And we see that content security policy three, which allows for dynamic. I'd also say that a trusted type standard is helping a lot in providing that capability. The only problem with content security policy, three, it's not supported and e 11 or even worse, it's not supported at all in Safari and ie eleven support.

Jim Manico: [00:16:03] Only some of my customers need that. Most of my customers don't use ie 11 anymore. But according to the W3 C browser statistics i.e. elevons, global use is statistically zero percent at this point as of last month. So we see I 11 finally starting to go away. But content security policy three. I was looking at the Safari Technical preview and within the last couple of weeks I see players that are building content security policy three support into Safari. So now now if we can get developers to implement CSP three, I like Anon's Pastrick, dynamic policy perspective, YOLO and Weichselbaum from Google's research and I limit what browsers I allow my customers to use. I can build some extremely rigorous security today. And I think that when we go ahead a year or two year, two or three and I have CP three everywhere and techniques to limit browsers and a little more awareness about third party libraries, that the capability of developers to build a secure application without excess is going to be more realistic. That's my hope job. At least all we have is hope. But I do agree with your conjecture. The cross site scripting and complicated Web applications is really hard to avoid, even with talented, security centric developers. And that's a problem with web development in a big way.

JB Aviat: [00:17:40] I agree it's still easier to avoid today than I think 20 years ago when you weren't using, like, templating engine server side. Yeah, the things were on one hand. Come on. And on the other hand, pretty neglected even at the beginning by security people. And so, yeah, I think things move to a very, very positive way. And we can only think Google here, who is really moving for a while, w3 C and leading implement this implementations we sickroom and I trusted. Stipe's was born from an initiative to solve the excesses problem at the Google scale internally. And so that's insane to see how well they managed to solve it internally. It's not like 100 percent solved with breathtaking. It's like 90 percent solved. And sharing that to the broader audience is amazing, as you said. Yes, it's not trivial to implement that shit within your customers. What are the strategies that you see to actually implement this kind of initiatives? It's complex at the scale of a company at scale.

Jim Manico: [00:18:46] It's extremely difficult. It requires at least today, it does require educating developers, which is not a very scalable activity. I realize that's difficult. So my goal is usually to educate the lead security champions of each developer team around content security policy using the Spagnuolo YSL bomb methodologies on top of libraries that use trust types. So who are these rock stars we're talking about? Chris Cristoff from Google is the author of Trusted Types, and Michelle Spagnolo and Lucas Shubham have been giving talks about how they roll out content security policy, which uses XP Level three on the conference circuit. I'm a big fan of their methodologies dramatised in any hero's journey you have helper's. I'm on a journey to learn about secure coding. Even though I am a teacher by trade, my real profession is being a student so I can learn these technologies enough so I may teach them properly and on my own journey of learning about this, these three individuals have helped me the most. Again, I want you to look these people up and look at their work. Michelle Spagnuolo, Lucas Shubham and Chris Cristoff. Those are the three top defenders of excess on the planet with the kind of. Knowledge and work that they are doing, and I'll credit Michael West as well from the W3 C, who has done a lot of work with content security policy at the standard level. Google is no perfect company. No one is. But a lot of the engineers at Google have led the charge in providing good security standards so we can build secure web applications.

Jim Manico: [00:20:34] And the way that I work with companies to achieve this knowledge at scale is not to influence every developer. I can't do that realistically in training, but I can influence the main security champions that reside in each team who are dedicated and responsible for secure software. So I try to influence those leaders so the knowledge trickles down to other members of the team. And that, of course, assumes that a company even has security champions embedded with their developers in the first place. But that's the best way I think, that this kind of knowledge will trickle into large companies, because as a side