DevSec For Scale Podcast Ep 7: Proactively Building Secure Software

Security is often an afterthought when it comes to designing and developing applications. Josh Grossman, CTO at Bounce Security and OWASP Israel Board member, talked to me about practical ways to build security into applications and the software development lifecycle.

In this interview, we talk about OWASP and the open resources it provides for software security, we delve into some of the OWASP projects that encourage software developers to proactively think about security considerations before and during development, and we explore the role of automated testing tools in your application security program.

Watch the full episode below.

Transcript

Jeremy Hess: Welcome to the DevSec for Scale podcast. The show that makes security a first-class citizen for growing companies. My name is Jeremy Hess, Head of Developer Relations at Akeyless, the Secrets Management SaaS Platform. This interview podcast brings security experts and practitioners together to offer practical and actionable ways for small and growing companies to implement security best practices, using shift left principles, without interrupting developer life cycles.

Welcome back everybody to the DevSec for Scale Podcast. I’m Jeremy Hess from Akeyless.io. And with me today is a fantastic guest and a friend of mine, Josh Grossman. He’s the CTO at Bounce Security, and he is an OWASP Israel board member. Now Josh, before we talk a little bit more about you and your background, can you give us a brief introduction to OWASP in case people are unaware, which I’m sure they’re not, and we’ll get into a little more about your involvement as well?

Josh Grossman: Yeah, no problem at all. Really great to be on with you today. Great to speak to you. Yeah, so OWASP. I don’t know how many people have heard of OWASP already. I hope lots, but I guess there’s no guarantees, right? So OWASP is the Open Web Application Security Project®. It was started in the early 2000s, and really, the idea is to provide free and open resources for software security. The idea is to have all sorts of different sorts of knowledge bases and projects and tools that people can use to build more secure software, that for the most part is something that’s freely available and freely usable without licensing concerns or big costs.

So, practically speaking, OWASP has two key main aspects. It has chapters all around the world. We’ve got one here in Israel. We’ve got many other cities around the world. So, hundreds and hundreds of cities have OWASP chapters that meet up a few times a year and have talks on various different topics. And there are also the OWASP projects. There are also about, probably more than 200 projects now that OWASP oversees. And these can be tools to assess security or help build security in. These can be documentation to how to build secure software, but everything is built around this idea of we want to build more secure applications.

Jeremy Hess: Perfect. So, now that we have that out of the way, tell us a little bit about yourself, your background, and how you’re involved in OWASP today.

Josh Grossman: Sure, so like you said my name’s Josh Grossman, and I don’t know, I guess I’ve always been excited about security, doing things on the school network back in secondary school days. But I started off as a more general IT consultant and I’ve gradually specialized slowly, more firstly in security, and then in application security. I spent many years doing application penetration testing. Going in, breaking applications, feeling happy, yeah, I’ve done it again. But I guess gradually, I spent more time and more thought about, okay, well it’s all very well coming in and breaking stuff and putting out reports saying here are your problems. But I spent more time on projects that are actually helping organizations beforehand saying, okay, well how can we build security into applications? How can we put this into the process so that when we get to the breaking stage there are a lot less findings and a lot less hassle?

So, that was a sort of gradual process, and it’s culminated in my current position that I started a few months ago, working as CTO for Bounce Security, where we specialize in providing value-driven application security guidance and support. Now, the idea being that we want to work with development teams to actually say well, let’s build this in as part of your day-to-day in a way that you’re going to feel value from, and feel that works for you.

Jeremy Hess: Awesome. So actually, going back to mentioning about breaking applications. It was really interesting. I’ve listened to some podcasts. Darknet Diaries is one of the ones that I listened to; really interesting. It was always amazing to me how the same hack could work on so many programs and applications. That you just do the same thing over and over, and it just seems that most developers seem to miss pretty much the same thing. So, I wonder why that is? I don’t know if there’s an answer for that. It’s just something that in my mind comes up, and I’m like well why is it that everybody seems to miss these same issues. So, maybe OWASP actually has ways of dealing with those specific risks, but it was just a point that I had to mention. Because, yeah really interesting to me.

Josh Grossman: I mean yeah, Darknet Diaries is a great podcast and so many great stories on there. A really interesting story is Jack Rhysider, I think. He’s a really great storyteller and brings it out really nicely. But yeah, this is not a new industry and I think that, certainly in my own bio that I’d send to conferences and stuff, for a long time I included dreams of not finding cross site scripting in every application. Because it’s pretty much the reality. Like you say, you go to pretty much every single application and then that’s one particular finding you find in so many different applications. I was like, why can’t we fix this?

And on the one hand, fixing things is difficult. It’s a difficult problem. There’s lots of different ways in which it can come about. Every framework works slightly differently. Everyone exposes a different way in which a similar thing can manifest. I think there’s also a historical problem, that it’s always the hacks and the hacking and the breaking that gets the attention and gets revered, and  that’s considered exciting. And you ask someone getting into security oh yeah, I want to be a penetration tester, because that’s what sounds cool and that’s what sounds fun. And people gradually realize that actually, for the most part you’re writing long reports, and the reports are the important part because the reports are actually the deliverable. The breaking is, okay, it’s fun, but the report is the valuable part.

I think that one of the key, I mean this is a key move that I made. But the key move in general needs to be we cannot hack ourselves secure. There’s been lots of thought pieces about this, but the idea being, we can’t just keep breaking things and expect things to get better. We have to find ways of okay, how are we going to bring this into normal development processes? And certainly, OWASP is a big part of that. It’s about saying, well here are the resources that we need to do that.

I personally am involved in a couple of projects related to OWASP. Most of my primary involvement is a project leader on the Application Security Verification Standard (ASVS). This is quite a big document that aims to be a list of requirements for a secure application. These are the requirements you need to take into account when you want to build a secure application. And there’s quite a lot there because application security is, there’s a lot going on. It’s a big area, but it’s very much about building things in and thinking about it. We talk about shift left, but it should really be spread left. Because we can’t just move all the security to the left and not leave any on the right. We need to have it spread across the whole process, and ASVS, that project is very much part of having those ideas up front and new requirements up front.

Jeremy Hess: Oh, that’s great. So, talking more about some of the other projects of OWASP, because of course that’s the main overarching theme here. So, talking about risks, there’s a project called OWASP Top 10 Risks. Probably something more people have heard of. I mean the truth is those risks are probably things that are just noted by many researchers and writers and hackers. But one of the interesting projects that I saw, and that was interesting to me, was the Top 10 Proactive Controls Project. And I think this is very relevant especially for application security specifically. And so, what could you tell us, what’s that project generally about, and how can developers, younger companies, learn to already bake in those types of controls?

Josh Grossman: Yeah, I mentioned ASVS, and ASVS is designed to be the standard, the comprehensive way of building a secure application. But there’s a lot going on there. ASVS has currently somewhere between 200 and 300 requirements. Okay, that’s a lot to think about. That’s a lot to do, and we don’t necessarily expect that’s going to be the first thing you do, because that’s not practical. We’re here today primarily to talk about software security for startups and DevSec for startups, and 200, 300 controls for a startup isn’t practical. I think that’s well understood.

Now if someone’s heard of OWASP, a lot of times what they’ve heard of is the OWASP Top 10 Risks. That’s the most famous project, that’s the one that gets the most attention, and it’s a really great project, it’s a really important project. But its primary goal is awareness. It’s more about saying application security is a problem. This is a problem we need to think about, here are various, a list of the top 10 aspects of that problem that maybe you need to think about. But it’s very much designed as an awareness, as a marketing document. That’s not a controversial thing to say, that’s well understood by everyone including the project leaders.

So, that’s the purpose. The purpose is to push application security because it does need awareness at the highest levels. But once you dig in to the top ten risks, everyone’s like, oh you need to know the OWASP Top 10. What are the OWASP Top 10? I mean, I’m not going to go through every single one, but just for example, number three on the most recent OWASP Top 10 is injection. Okay injection, oh, we have to think about injection. What does that mean? Well, injection actually means SQL injection, no SQL injection, HQL injection, code injection, X-path injection, LDAP, yeah. This is a bottomless pit of how we, you know different issues when you think about it.

Certainly, if I’m working with developers, I don’t want to bring this straight in and say here are bunch of problems, go and have fun. Like, what are they going to do? Developers want requirements, they want, okay we need to build something, what do we need to build, and to look from that perspective. They don’t just want to receive a bunch of problems in an area they are less familiar with.

Jeremy Hess: They probably want as few requirements as possible.

Josh Grossman: Exactly, startups want to build the minimum viable product, right? They want to build want they need to build and not spend extraneous time, because they do not have extraneous time. And trying to just digest the top 10 and say, well what does that actually mean, the top ten risks? It’s not practical. So, that brings us to the proactive controls. It’s also an OWASP Top 10 Project, but it’s the OWASP Top 10 Proactive Controls. And this is already a little bit more practical. This is a little bit more developer focused. Because it’s saying, look here are things you need to take into account when you’re building an application. Here are design considerations. Here are security philosophies or security ideas that you need to have in place.

So, it defines 10 items. It’s obviously not everything. If you want everything you have to go to ASVS. But we don’t want everything. We want, okay, let’s focus on the key aspects. Let’s focus on the key areas. And it basically says, here are things that you can take into account when you’re building. Think about security already at the requirement stage. Think about the security frameworks or libraries that are relevant for your particular development language. Think about how you’re going to access the database that you’re using securely. Think about how you’re going to handle data. Whether that’s encoding it or escaping it before it goes into some sensitive context, whether that’s validating it as you receive it.

These are already much more practical aspects that we want developers to think about. Ultimately, we want security to be another aspect of software. We don’t want it to be some magical extra function that sits on the side and, I don’t know, runs tools and spits out results. Security is part of the application development process. You wouldn’t say, okay we’ve built the application but it’s completely unusable. We haven’t thought about usability. You know, we built the application but it’s slow as a dog. We didn’t think about performance. In the same way, we wouldn’t want to build an application and say we didn’t think about security, so there’s no security considerations.

You just need it to be another consideration when a developer is building an application, and the top 10 proactive controls is designed to provide that initial gateway into security. It’s written as a document. It’s not just a list of controls. It’s written as a narrative document. It’s written in a way that’s a little bit easier to consume and easier to work through, and it’s designed to be understandable. It’s designed to be an initial overview of, okay, here’s how you build secure software.

Jeremy Hess: Great. Now I have an interesting one for you. Is there anything, can you give us an interesting story probably, potentially, about something that you may be found when you were, you know doing a bit of the hacking back in the day? And how you turned that into something that today you’re actually more proactive in working on helping developers and companies to change, to fix on their side?

Josh Grossman: I think one of the big things that I, I think one of the big moments for me was really when I was working as a breaker and working as a hacker. I suddenly realized, why am I spending all this time on the outside just like throwing attacks at an application and seeing what sticks, not really knowing what’s going on behind the scenes. There was one project I worked on as a penetration tester, where we actually asked them for the code. Like they said, oh, do you want the code? I was like okay, they added this as read-only so they could give us access to the code. So, we’re attacking the application. We can also see what’s going on behind the scenes.

That way I immediately knew what database they’re using. I knew how their application flowed. And I could see that I was trying SQL injection payloads to try and get a valid SQL injection and it wasn’t working. I looked in the code I could see that for the most part they were doing some  validation. It wasn’t a great version of validation, it was checking that they didn’t have any dodgy characters in the input. Which isn’t a great fix for SQL injection. For SQL injection, you want to parameterize all your queries. You want to make sure that you are using parameters and you’re building the query in a specific way. Where the data that’s being input gets put into the query in a secure way and not just string concatenated on one thing after the other. Which is a not secure way of doing it.

But they were saying, okay, we’re going to do the string concatenation, but we’ll block certain characters that we think are dangerous. Which as we’ll see, isn’t ideal because I went through the code, I did some searching. And sure enough, I found the place they’d forgotten to do that. I could see the code, so I knew exactly what SQL injection payload was going to work there. I used that payload and yeah, sure enough I had their database sat on my desk in a short amount of time. Better me than a real malicious actor let’s say.

But I think that was a big moment for me where I said, well, penetration testing traditionally has been a very outside activity. It’s been very much about if someone comes in from outside, doesn’t really know what’s going on, just throws a load of attacks at an application and sees what happens. And a much more collaborative and open box approach gives you far more value. Because the tester knows exactly what their target is. They know exactly what technologies they’re targeting. They know exactly how they need to tailor attacks to work. The less time they spend having to tailor an attack, the more time they’ve got to test other things. It’s about that collaboration between, say penetration testing as an example and development. But it brought home that again, security doesn’t come from outside. It’s not something that’s just an outside consideration that bothers us once a year. It needs to be something that day in day out the developers are thinking about. That when security comes in, the developers are like oh yeah, come have a look at this, or we think this might be a bit concerning, focus your attention here. About having a much more collaborative approach.

And again, developers still thinking about that as part of their day-to-day. That it’s one of the things that they think about when they’re building a feature, when they’re designing a new area of the application.

Jeremy Hess: Got it. So, a question that I like to ask all my guests. Can you give us, from your experience, doesn’t have to be the basic answers that everyone gives, it can be your take. But what are one or two ideas, one or two things that developers at younger companies, scaling, growing companies can already put into practice today from a security standpoint that won’t really put too much burden on their cycles? Because obviously, like we talked about, they’re trying to get their minimum viable product out, and they don’t necessarily have as much time for security. But what are one or two things that you think they could put, controls they could put in place already at the beginning that would help make sure their applications are secure, but at the same time won’t take too much of their time?

Josh Grossman: So, maybe what’s like a slightly controversial answer on this. I think, many years ago when people thought about, do you know application security? Have you got an application security program? People were like yeah, we do penetration testing once a year, that’s our application security program. I think nowadays, when people say, oh, do have an application security program and they’re like yeah, we’ve got this tool, we’ve got that tool. We do SAST. We do DAST. We do SCA. We do IAST. Like, they’re like yeah, we’ve got a whole bunch of tools.

And I think that tools are very tempting because everyone’s like, oh you’ll just automate this, or it will go in the CI/CD. It’s almost like the old Honda commercials where one thing rolling knocks the next thing knocks the next thing. It’s all going to be a very nicely flowing process, and everything’s going to work nicely and automated and we’re going to be magically secure. The reality of what happens is that you have a lot of automated tasks that run, and then give you a load of manual work to do. Like, well what is this, what is that, what does that mean? This is a real finding, this is not a real finding. And a lot of what I’ve been working on recently is saying, well, this is actually a problem. This is actually a real issue.

I think that when you’re in the startup scale it may be slightly easier, but I think there’s still a very real, you know situation, that automated tools bring you manual work as well. Whether that’s putting them into place in the first place, caring and feeding for them, or getting the findings out afterwards. So, I’d certainly say don’t just put in a bunch of tools and expect that everything’s going to be magically secure. Be ready for those processes as well. Actually, that’s something I’m working on building a training course for at the moment. Because I just see it as such a big issue and a big gap in the market at the moment. About, okay, we’ve got these tools, how do we deal with them? That’s a training course I’m going to be delivering at the OWASP Global Conference which is running virtually in June. Because it’s a real issue. I think people have just run to tools as a way of trying to get secure easily, and then they discover that they have converted one set of problems into another set of problems.

The other thing I would say is, I think there’s a guy called Jim Manico who’s very prominent in application security, and specifically in the training and education space. He says that in his experience, all developers are security engineers nowadays. I’m not sure that’s quite the case in terms of whether they actually are, but I think they certainly need to be thinking that way, in the same way that performance and usability are a part of development, security needs to be part of that as well.

I think a developer, especially a developer at startup, isn’t going to learn everything about security upfront. But having that interest, and having that awareness, and using something like the proactive controls as a gateway into that. As a basic overview of here are things that I want to be thinking about in my day-to-day job as I’m building this software, I think is going to be a big benefit. Even when a startup eventually recruits a security person, they still can’t do everything. They still can’t be everywhere at once. And having developers that are engaged and interested in security, and  understand the key concepts, and most of all aren’t burnt out from dealing with tool problems, I think is going to be a very valuable short- to mid-term way of getting better security within the product.

Jeremy Hess: Yeah, that’s wonderful. Alright, well I don’t think it was that controversial, your first point. But definitely, we hope that our developers are thinking at least somewhat about security on some level, and hopefully there’s a feedback loop there back into the product overall. So, Josh thank you so much for your time. It was a really fun episode. Got a lot of great information and everyone should go definitely check out OWASP’s sites and their events. So, do you want to give us another couple of points, or a couple of events and things happening in the near future that people can join, and where people can find the different projects?

Josh Grossman: So, yeah OWASP’s website is “owasp.org”. They run, OWASP runs global conferences in different regions at different times of the year. So, the EU focused virtual conference is coming up in June. I think there may well be one for the APAC region a little bit later on in the year, and everything is already planned out for the US in San Francisco towards November time. So, that’s a good way, and that’s hopefully going to be in person as well. So, that’s a really great way of getting more information. But also, check out your local OWASP chapter. Find out where your local OWASP chapter is, and find out what they’re doing, what events they’re putting on, gradually going back to in-person events. It’s a great way to get engaged and find out more information. So, I’d certainly advise you to look out. Look on “owasp.org” and yeah, feel free to be in touch with me if anyone’s got questions as well. I’m on Twitter. I’m on LinkedIn. Contact details will show in the notes or something.

Jeremy Hess: Yup, absolutely. Well, you can also tell us your Twitter handle.

Josh Grossman: Yeah, my Twitter handle is JoshCGrossman. So, G-R-O-S-S-M-A-N.

Jeremy Hess: Easy enough. Simple enough. Well, thanks again Josh so much for your time. We had a really great one. And hope you have a great rest of your day.

Josh Grossman: Thanks so much. You too. Have a good one.

See the Akeyless Secrets Orchestration in Action