Conclusion: Season 4 Finale

0:00Chris RomeoHey folks, season 4, episode 27, the one everyone looks forward to. This is our season 4 wrap-up. Robert and I look back through the season and share some of our most memorable clips, so we hope you enjoy. The Application Security Podcast, here we go. Starting off from episode 3, Julian Vahent joins to talk about AppSec and DevOps and this whole alphabet soup thing. Julian also shares the details about the book he wrote about DevOps and security.

0:59Robert HurlbutWell, it's always an interesting discussion to have. I mean, the old joke is still true here. There are 2 hard problems in computer science, cache invalidation, naming things, and off-by-one errors. And that's really what we're focusing on when we debate DevSecOps versus SecDevOps versus whatnot. There is an interesting— so the sarcastic answer is that I think security people felt left out and really wanted to integrate security in the middle of DevOps. That's a DevSecOps thing. Yeah. So there was a bit of a knee-jerk reaction by security people, but there's probably a deeper problem here that we had to address a few years ago. And that was also part of the motivation for me to write the book, which is that security people were very, very slow at changing the way they approach integrating security into complex DevOps infrastructure. I've had a lot of discussions with security engineers who were still stuck on technology that were very popular in the early-mid-2000s but don't play well once you're in a full DevOps environment or you're running your infrastructure in the cloud or things like that. A lot of people who had adopted DevOps and started thinking about how to do this right needed kind of a marketing term to change the mindset of the rest of the security community. That's why the DevSecOps, SecDevOps, and everything took over. I actually don't use any of those names in the book, kind of on purpose, because I didn't want to make it about this. I think part of the problem with these names is that they focus— when people say DevSecOps or SecDevOps, they focus mostly on testing automation. And that's only a small part of what DevOps security is about. There's a whole lot more to it.

2:51Chris RomeoYeah.

2:53Robert HurlbutSo that's also why I don't like to use the term because I feel like it's often misused and it covers only a very, very small part of the problem.

2:59Chris RomeoIn episode 5, Matt Tessaro joins to speak about AppSec Pipeline Project.

3:05Robert HurlbutSure. It started out with myself and my co-lead, Aaron Weaver, realizing— well, it started out really with us realizing there's a lot of good stuff at OWASP, but if you're running an AppSec program, There's not like a nice place to find those kind of things. You know, there's— I know because I've been in the business for a while that I can use A, B, C, and D and they're useful, but maybe if you're new to it or you've just, you know, suddenly been given the, hey, by the way, you're doing AppSec badge, you don't know what is useful and what isn't of the suite of things that OWASP has.

3:38Chris RomeoGot it.

3:38Robert HurlbutSo it really started with that idea initially, but what it sort of morphed into was an idea— at the time Aaron and I were working together at the same employer, and we did some interesting automation around security. And it was really to make— well, to be— well, at that employer at the time, it was a very large company. They had combined multiple divisions, and they were centralizing a lot of the security. And so we had this very diverse global org that had thousands of applications and a very small team. And the very small team was sort of glued together from all these different pieces.

4:13Chris RomeoRight.

4:13Robert HurlbutAnd it was just kind of chaos. And so we kind of took a deep breath and said, how, what is the fundamental workflow of an AppSec team? And we defined that and added automation to it and called that the sort of the first gen, if you want to call it, of an AppSec pipeline. And it was really inner-focused. It was like, how do I make the AppSec team go faster?

4:33Chris RomeoJessie and Vandana from the Women in AppSec program within OWASP join in episode 10. to give us a briefing on what is this program and how can we become involved.

4:46Robert HurlbutOkay, so when we talk about Women in AppSec, it's more about getting more women in application security and helping them in growing their career in application security. We are targeting the women that are already there in the market. They are developers and from the other background, but they want to come here and join and be part of application security. Alongside, we are also targeting the college students because they are super amazing. They have a zeal to learn security and they know they are day in and day out as part of engineering, they are working on the coding. It's just that we are going to the colleges and helping them out and be part of a bigger community.

5:31Chris RomeoNow we hear in episode 11 from Aaron Reinhardt, where he defines chaos engineering and some of the ways that companies are using it.

5:41Robert HurlbutSure. Well, just, just, uh, so I'll lead it with, uh, if you go to principlesofchaos.org, it's sort of the marquee seminal, uh, sort of doctrine when it comes to chaos engineering that everyone sticks to. It's the principles laid out by Netflix, the Netflix team led by Casey Rosenthal. But the definition of chaos engineering is the discipline of experimenting on a distributed system in order to build confidence in the system's capability to withstand turbulent conditions in production. All those words in that definition are very important. We can actually get into it at some point in the discussion about what some of the differences between security practices like red teaming, purple teaming, and chaos engineering, and there are major differences. But the idea of chaos engineering sort of was born out of a particular need from Netflix. So there are actually roots of chaos engineering that began at Google in the SRE program at Google, as well as Amazon.com. Netflix, as many folks may know, consumes about almost 30%— I don't know the exact numbers today, but they consume about 30% of all North American internet. On top of that, they consume about the same percentage of Amazon Web Services. When you're that heavy from an engineering perspective, stuff starts breaking. What Netflix decided to do is that they decided that they weren't that their business heavily depended upon their services being available for people. You can't watch a movie if it's not there. They decided they're going to build their system to be resilient to failures from Amazon and network traffic type of failure modes. They went forth and they built to the best of their capability circuit breaker patterns and resilient types of engineering approaches to combat the problem, but they ran into a scenario where, okay, now that we— okay, now that we have done this, how do we prove it? So they went to Amazon and they said, hey, will you break your system for us? Well, no. Amazon was like, well, you know, that kind of violates our agreement with you. You know, you want us to what? And but Amazon said, you know what, you can— you know what, you can go ahead and break it yourself, right? Have at it, right? And so out of that was born Chaos Monkey, which is still considered the sort of the first tool, the seminal tool in the space. Most people, if they've ever heard of chaos engineering, sometimes they've heard of Chaos Monkey just because it's kind of a crazy name.

8:33Chris RomeoEpisode 14, Erlend from the OWASP Norway chapter joins to discuss the basics of retire.js And how you can use it. So the idea of retire.js was that we need some way of figuring out what JavaScript libraries we're using, and if those versions of the JavaScript libraries that we're using have any known vulnerabilities in them. So this basically started with— I actually checked today, and it's exactly 5 years since the first commit on retire.js. It was in August 2013. It started out with me working as a developer on a project where we were looking into Java, the Java libraries that we were using and which ones had vulnerabilities in them. And we were looking into finding solutions for automated scans. And then I started thinking, hey, we're also using a lot of JavaScript libraries, but there aren't really any scanners available for this. And I was talking to one of my colleagues and he said, yeah, I think most websites, they have the jQuery version that was available at the time the website was first built. Which is probably quite right, I must have to say. So I decided to build this tool and it was intended as a command line utility that you could use to scan your source code folders, just looking for JavaScript files and then trying to identify them by looking at comments, by looking at the code, by looking at the name of the file and things like that. Eventually, it also— we made a Chrome extension for it, and someone contributed a Firefox plugin as well. And then later, someone also created a Burp plugin, a SAP plugin, and a Maven plugin. So there are quite a lot of versions of it right now. So what we have is basically a central repository a set of JavaScript libraries that we're monitoring, where we have a list of vulnerabilities connected to them, and we have some ways of identifying each library and each version. From episode 17, Bjorn Kimmenich joins, who is the project lead for the OWASP Juice Shop. Bjorn shares with us some of the basics of Juice Shop.

11:01Robert HurlbutSo that means it's If you just use it in a nice and normal way, then it looks like a regular e-commerce application. So it's an actual working web shop where you can buy juice, obviously, and related products. So you can register, you can log in, you can put stuff into your shopping basket, everything that you would expect. And everything works except for the part where I send you the actual products. That is the only thing that doesn't happen.

11:32Chris RomeoWow.

11:32Robert HurlbutBut everything else actually works. behind the scenes, it's a complete disaster from a security perspective. That's a—

11:42Chris RomeoI think that's a great way to describe a broken web application, just a complete disaster. So, how much of this is based in real life? Like, you know, sometimes they have that made-for-TV movie that says it was influenced by, you know, a true story. Like, where is that? Is that how Juice Shop is? Is it based on things you've seen in the past that are like really bad?

12:03Robert HurlbutYes, it definitely is. So, um, I mean, it has the obvious things that you would expect, so some, some classical cross-site scripting, SQL injection, that kind of stuff. But it also has a lot of, uh, more complex problems, uh, authorization issues and, and, and other things, um, business logic flaws, which you, which you really cannot make up. So you really have to steal those from real experience or from things you saw on, on the So, that's also something I like to do when some new nice vulnerability is being published, then I try to integrate it somehow also into the Juice Shop.

12:44Chris RomeoThen episode 21, we hear from Travis McPeak, where he explains what he means when he says SecOps is my specialty. Gives us a little more perspective on the whole SecOps movement. The way I see it is basically how do we operationalize a security model that allows us to get certain assurances and controls that we need to have to feel comfortable with the product. And then at the same time allow developers to do what they need to do. And that whole operational flow is kind of what I mean with SecOps. So some of the things that we'll do is, I have a project called RepoKid that uses data about our AWS services, what's being used, and will, if you haven't used a certain permission, in a given time, it will remove that permission and we can operationalize it. So instead of doing these policy reviews like you'd have to do in an old-school model, we can actually just use data and make those changes automatically at scale. And so that's automated? It automatically goes through and just checks, it waits, you know, a certain amount of time, and then— so there's no manual kickoff of that? Completely automated.

13:52Robert HurlbutOkay, wow.

13:53Chris RomeoAnd then so you have more of a manual process when you add permissions back in? Yes, and there's some tooling for that as well. The idea is to get all of that down to either no touch or very little touch so that if we have something that takes us an hour to do, then obviously if 1,000 people need it, we're going to be doing not much else except for this thing over and over again. So anytime we see friction points like that, we see automation opportunities. So can you do— so can something be manual and still be SecOps? Sure, totally. Yeah, we have a lot of manual processes as well. So the more operational nature of, you know, hey, we have a high-value application and we need to make sure that it's dialed in with the right permissions. We'll still do architecture reviews. That kind of like falls under the SecOps umbrella for us as well. Finally, last but not least, Daniel Meissler joins to discuss the IoT Top 10 that he's working on with some other folks from OWASP.

14:57Robert HurlbutYeah, so the idea is basically to have a general list, a basic list. I got some pretty strong philosophical feelings around these OWASP projects and the lists. I think it's easy to go too deep into these things and not really be as functional anymore, especially since the OWASP advice that's out there right now, it's like really adding up. There's like 20 different groups.

15:25Chris RomeoYeah.

15:27Robert HurlbutProbably 50 if you really looked, but there's like 20 pretty dominant groups out there from government organizations to corporations or whatever that are putting out guidance. And some of them have a quick 5 pages or 10 pages and other people are putting out like 200-page documents.

15:49Chris RomeoYep.

15:49Robert HurlbutAnd they're putting so much work into it and they're doing actually great work, But if you bury your work inside of 200 pages, my opinion, my cynical opinion is that effectively you might not have done anything and no one will know the difference because people are— people could barely read a one-page infographic, let alone parse 200 pages and do what's talked about in there. So we basically We pulled everything back into simplicity. And the philosophy around the project overall is help as many people as possible with a single list, with very concise, very clear description of what to avoid. We also didn't focus on, is it a vuln? Is it a threat? Is it a risk? Because each one of those is like, a separate religious combat situation. So we basically said, these are things you shouldn't do. I mean, because I've been in security for like, I guess, 20 years, right? So I used to really care about all these things and just be so eager to fight with people about these definitions. And now I'm just over that. And it's all about, okay, How quickly can we explain this? Doesn't matter what we call it. It's 10 things that you should avoid doing. And here's the other critical thing about it. It's a combination of manufacturer, developer, and implementer for the enterprise and consumer, right? So it's like, it's a combination of all those different use cases wrapped into one list.

17:42Chris RomeoThat wraps up season 4, episode 27, our finale for this season. Robert and I want to take this opportunity to thank each and every one of you, our listeners. We couldn't do this without you. We wouldn't do this without you. And so we want to ask, hey, if there's somebody we should interview for season 5, whether it's you or whether it's somebody you're aware of in the industry, would you reach out to us on Twitter @AppSecPodcast? and let us know who that is. We've already got a number of episodes recorded for season 5. The season 5 episodes will start to drop in about a month. Stay secure, you wild and crazy internet.

18:19Robert HurlbutThanks for listening to the Application Security Podcast. If you enjoy the podcast, please do us a favor and visit the iTunes Store and give us a 5-star rating. Our intro music is 8-Bit Kung Fu by Born and TJ, and the outro is Southern Delight by Stefan Kartenberg. You can find us on Twitter @AppSecPodcast or on the web at www.appsecpodcast.org.