HackEdu: Hands-On Security Training with Arthur Hicken & Jared Ablon

Five, four, three, two, one. Drop that. Welcome to the Test Guild Security Podcast. We're all getting together to learn more about security testing with your host, Joe Calantonio.

Hey, it's Joe. And welcome to another episode of the Test Guild Security Podcast. Since my recent blog post on the top nine automation trends for 2020 where I listed security as a quickly growing trend, testers and developers need to know. In the new year I began asked by a bunch of folks what some good resources are to help them get started learning about security. That's why I was really excited to learn about HackedU, an online training platform that was designed to help software developers to develop code more securely. And unlike other training you might have taken, HackedU has a unique hands on training approach to that will keep you engaged in learning actionable security tips you could put into place right away. In this episode we'll be talking with Jared Ablon, co founder and CEO of HackedU and Arthur Hicken, chief evangelist at PowerSoft, all about why security testing is so important for your agile teams. You don't wanna miss this episode. Check it out.

It's no secret that the number and complexity of applications are growing. But what is alarming is that 90% of security incidents result from exploits and against defects in software. The need for better application security has never been higher and Micro Focus Fortify is here to help. Fortify is the recognized market leader in application security and it is the most comprehensive and scalable application security solution that works with your current development tools and processes. With Fortify, you can start security applications in a single day, including custom code, open source or commercial components, components and scale as your needs grow with an on premise as a service or hybrid implementation. Check them out. Head on over to micro focus.com app security. Hey Arthur and Jared. Welcome to the Guild.

All right. Hey, how's it going?

Awesome. Great to have you on the show. So I'm really excited today to talk to you about a new initiative. I heard about that you're partnering with hackedU about security developer training that I think is really needed in the industry. But before we get into it, Arthur, Jared, could you just tell us a little bit more about yourself?

Sure, yeah. My name is Arthur Hicken. I work at Parasoft. I'm the evangelist. I'm also known in the security community as the code Curmudgeon. I run the SQL Injection hall of Shame and the IoT hall of Shame are my probably most known things. Passionate about cybersecurity mostly because I think we're doing the wrong thing and Approaching it completely wrong. So that's the perspective that I take.

Yeah. I'm Jared ablon. I'm the CEO at hack edu. I've been in cybersecurity for 17 years. Starting out in cryptography, moving into application security, and then into management roles. Prior to HackingU, I was a CISO. Application security has always been something I've been focused on trying to improve security and applications. And that's why I started Hack Edu, to help with training developers and focusing on where I thought we can get a lot of ROI in terms of reducing vulnerabilities in code.

So, Jared, what made you really want to go all in on hacker education at hackedu? What really inspired you to get it up and running?

Yeah, when we started hackedu, there weren't many online hands on training platforms. There's a real lack of that in the market. There's, you know, there's some great in person training, but that's really hard to scale. It's also pretty costly as far as online having really good hands on platforms, there wasn't anything really available. And so myself and my co founder, Matt Koskala decided to build out hacky to you and create really good hands on cybersecurity training. Starting out with training software developers to code more securely.

Awesome. Now, Arthur, you've been in this industry for a while. Did you see a gap in education and how does Hack Edu fill that gap?

Yeah, so, you know, it's funny because I definitely see that people don't know what they're doing when it comes to software security. And we see it through a variety of interesting little symptoms. For example, I helped do a simplistic penetration test at a device manufacturer who shall remain nameless, but whose devices you probably use.

We were hacking into their device with some really stupid, simple, automated. We weren't even trying very hard. We just tried to connect the static analysis results to things that can happen at a black box perspective. The response we got from their development team was a standard array of answers that we hear all the time, which is, I don't know why that's important. I don't believe that's important. I don't think this one's important. That can never happen. I don't see why that one would matter. Like a whole bunch of things like that that all relate to, I don't really know how security issues really occur and how they look in the code. Therefore, when you show me something like say, heartbleed, I go, that's no big deal. So I started doing at the various webinars and presentations I do, I started polling and asking people like, what are your big challenges and training actually does people are aware now at the moment that they run a tool. Maybe they're not aware, but when they're in a room thinking objectively, people are aware that we just don't know enough, that we have teams that have software developers that are very, very skilled but have no experience and no training in security. And so they're not writing secure software. That's just how it works.

Now. I definitely see that I've said this a few times, that there always was a separate security team, that as a developer and tester, I always thought they handled it. Why is security developer training needed if we do have these SWAT teams for security testing? Jared, why do you think that's a need?

Yeah. In order to scale application security, you need to bring in developers. They have to be a part of it. When you have organizations that have tens of thousands of developers, maybe 20 application security engineers, the ratio just doesn't work out for the security team to be able to take care of it. Right. There's a real problem in terms of being able to hire enough people. Everyone knows that the real technical security folks are hard to find. They're just not out there. There's no cavalry coming.

Because of that. We really need to shift the focus to developers. That's why there's this huge shift left movement. Right. Let's do things in the secure, you know, in the software development life cycle. Let's do things earlier. Let's try to empower developers so we can scale application security. Otherwise it's. It's a losing battle if you have a separate organization that's concerned and developers really aren't concerned at all.

Now, Arthur, we talked about this before. You said there's, as we shift left, we want to push all as many activities as possible earlier and earlier in the software development lifecycle. And you said there's actually a lot of things that encode as you're coding. If someone ran a scan early, they'd be able to pick up issues. So do you think this is a training issue, why developers don't know this, or is it something else that's holding them back from actually doing some of these basic things?

Yeah. So I use functional safety as a really good example. For example, there's a set of coding standards for the Joint Strike Fighter, the GSF rules, and they were highly influenced by Stur strip. So in theory, they're really good ideas. And it's interesting because if you look at the preamble to the coding standard, which probably isn't something anyone would ever read if they were a rational human being, but it lays out the idea behind it, which is not just to find problems in code. And that's how we view SAST mostly today, and even dast. We're looking for bad things, anti patterns, as it were. But the idea behind the Joint Strike Fighter rules is that you're supposed to produce good code. And so we're using a safer subset of the language. Certain elements of the language might work perfectly well, but they're not necessarily safe or secure or reliable. Certainly in C, there's so many cool things you can do that you just shouldn't. You absolutely should not. That's the issue to me, is that we certainly need testing to make sure that code is secure, but we have to start building code that's secure rather than going, well, I found something that was bad here. I look at static analysis saying, hey, let's take an input method and wrap it in a validation method. That way there are no paths where validation cannot occur. We literally take the number of paths to zero. So it's really great. But if I just toss that at a developer, he says, well, I don't see the problem because there's no bug here. There's no evil piece of code that showed me that it made it in. Instead, I'm saying, do something that can't be hacked that your red team is going to spend all day long trying to beat away at. Again, developers just don't know that. That's what I think is interesting about that hack edu approach that people get to play hands on. Like, you've got these little samples, you can start tweaking the code and poking at it and seeing like, did I do something good? Did I stop the attack? Was I effective? So it's a pretty interesting approach, but to me, the important thing is to recognize if a red Team is finding things, you're not doing a good job constructing your application.

So, Jared, that brings up a good point, I guess. How is the training delivered? It sounds like it's hands on. I haven't seen it yet. So could you just tell us a bit more about it? It sounds like it's a unique approach.

Yeah. So we built a platform, it's all within the browser SaaS platform. And basically the way it works is we start with the offensive side of security. So we'll have a lesson on maybe an OAS top 10 vulnerability, or we even do things with real world Vulnerabilities. So like the Capital one breach that happened last summer, we recreate that whole application with the vulnerabilities and teach how, how to actually find, find the vulnerabilities and fix them. So we start with the offensive side and we do that for two reasons. Number one is it's been shown to be more effective than defensive training alone. There's been some studies on that. It gives the developers the, the fundamentals of the vulnerability so they understand it from an attacker point of view and they can think through, you know, not just this one use case, but how are attackers looking at my applications? What are some gotchas that I need to be looking for? And then the second reason we do offensive is because developers are really engaged by it. Right. Once you say, hey, try to hack this, they get really excited about it. We don't do slides or videos. A lot of times developers will play those while coding and they're not really paying attention. We want to engage developers as quickly as possible. We understand in the era of mobile phones and social applications, you really need to get people's attention immediately. So we try to get hands on as quickly as possible. Then we move to the defensive side and we explain what are best practices in terms of mitigating these vulnerabilities. How should you be coding? What are the secure coding techniques? And we actually expose the source code so that developers can find and fix the vulnerabilities that were part of the application on the offensive. So they find and fix those in whatever programming language you know, they program in, and then they can actually fix the application based on the changes they've made. They can go back and make sure they've actually fixed it correctly. And then we also run tests on the code they submit to make sure that they're doing it correctly as well.

Awesome. So one of my questions was going to be how do you get developers motivated enough to take the training? And it sounds like your unique approach is hands on actual, get your hands dirty, roll up your sleeves and go at it.

Definitely. Definitely, yeah. I mean, if you look at what I call the legacy training, which is mainly slides and videos for developers, most developers who have taken those before, they drag their feet and don't want to take training at all. Right. If they haven't seen our approach, they're not motivated by doing that. Again, it's just not exciting. Developers want problem solving. They want interesting problems and challenges and that's what we're presenting. So, yeah, to get them motivated, it's about getting hands on very Quickly getting them excited about the problems that we're presenting to them.

Very nice. So Arthur, talking about getting people excited, what made powersoft get excited to do a partnership? What is this partnership about?

Yeah, so it's funny because as Jared was just saying for years, my recommendation, when people go, well, my people aren't trained, what do I do? How do I get them trained? How do I make them pay attention to the training? I don't want them to watch the video in the background. It's not their office ethics video. We want them to actually learn something. I've told people, teach people to hack. Every developer wants to learn how to hack. You just don't get any pushback at all. So when I saw that Jared and Matt are doing this training where it's focused first offensive, everybody gets excited, they have fun, they play. And then it's interesting because the defensive side becomes a game right now instead of just saying, okay, I learned a hack. That was fun, that was cool. Now what? It's like you're playing against yourself and you're going, how would I stop that? Now that I know how people are coming in, how would, how would I stop that? Hopefully when they have enough of this training, enough experience, it applies into their everyday code, they start thinking about, oh my gosh, I should have made sure that I did some validation here, or I should make sure I'm checking range of parameters or whatever it is. I thought it was super interesting because developers just hate everything.

I want you to learn this, I want you to learn that, I want you to add this, I want you to add that. And they're just so negative. And here where it's hands on and it's, you know, again, you get to be the bad guy for at least a while. I feel like it sticks better. That's why I was so excited about this. Plus, again, the big problem I see with static analysis adoption is that people don't understand the results they're getting. They literally don't know why these things matter. If they've had experience breaking into an application through cross site scripting or SQL injection, then they understand the importance to make sure that things get validated, that you're using prepared statements, et cetera, all these different strategies. When a tool throws something at them that says, dude, don't be building a SQL query on the fly. That's insane. They'll go, oh yeah, that's right, that's right, don't do that. That's what got me excited. It seems like it's just so needed and static analysis. Just the most awesome way to shift left. DAST gets you that first step left you get from humans. And DAST is really an automation step as much as it is a shift left step. But to really get left before the application's done, I've got to get to sast. And I just don't see SAST being very successful unless the team understands what the tools are telling them and frankly, why it matters.

Jarrett I think one thing developers or anyone in general doing training, they get overwhelmed. So is there a path you lead them on step by step? How does the curriculum work at Hack Edu?

Yeah, we have something like 37 lessons and 12 challenges and ways to further engage with gamification and things like that. It's a lot of content to throw at developers. So what we do is we allow companies to create training plans where they can take a subset of the training, spread it out over time and create a training plan that works best for their organization. Now, we've seen across our customers, we've seen customers that say, we have one week a year, we're going to train, you know, everybody and give them all of the training then. And we've seen other companies that say, look, we're going to spread it out over the course of a year, give a few lessons every month and try that. And so based on all of the training, you know, that we've done with customers, we kind of have started to understand some best practices. And so one of those things is, you know, it definitely works better if you spread out the training over time because then it's not a huge, you know, a time sink for developers. Right? Developers, you know, they have a product roadmap, they need to get stuff done. And taking a huge chunk of time for all of your developers to get it done, that's usually, you know, there's a lot more pushback from both developers and engineering. So what we see, if companies schedule one or two hours every month, then security is on top of mind every month and it builds upon itself. So all those skills are kind of building, you know, throughout the year and then it's not a huge time away from the product roadmap. And developers can kind of take these, you know, our lessons around 20 to 30 minute chunks. They can kind of take those when they have, you know, some time away from their development. So we see that works really well. But, you know, for different reasons, companies, for compliance reasons or things like that, they may have dates where they have to meet, you know, some of the training curriculum requirements and we work with them on that, but. But basically all of our customers, we work with them to create a custom training plan based on their needs, their developer types and those types of things.

So Arthur, have you had the chance to take any of these courses and what do you think of the curriculum?

I've poked at a few of them before we did the partnership. I actually went around and looked at them and they seem pretty good to me. And I know that a few people on our team spread out around the globe, we've had look at them as well and we got like universally positive response. Like the developers love this training. So I'm really excited. I think that people will adopt it well because I feel like our developers are just like everybody else's developers. And like Jared was saying, this, this incremental approach, you know, so that I'm not screwing up everybody's schedule, but also like if I go study something for the next two weeks, six months from now, I don't remember, I don't know, 70%, 80% of it, but if I keep going back and renewing it, then it's going to work pretty well. Plus, like our clients, we have clients that have, you know, 5, 10,000 engineers and they're constantly turning them over. So if I can get this self paced, I can bring people up to speed, I can tell them what I need from them when they come onto my team. I think it works out really well. And again, when I go and try to actually build an initiative to secure my application, it helps it just be that much more effective.

Absolutely. My experience with qa, it always seems like testing and security, usually people don't think about it until after you find a bug or after you've been hacked to think, oh, I should have invest money in this. So I'm sure it's really hard to get companies to invest in training. So you know, roi, is there any ROI and security training that you have any studies to say, you know, is it worth it, what should I pay and what am I getting from that?

Yeah. So actually I think you might, might be surprised that more and more companies are turning to training and understand that it is something they need to be doing, especially this hands on training. So that's very encouraging. So we see a lot of people doing that. We do have a study. So one of our customers, they're a big technology software firm, basically what they did was they took an assessment where developers had to find and fix vulnerabilities in code. They took that assessment, then they took our training and then nine Months later, they took another assessment. And so at the beginning, they took the assessment and they found just 14% of the vulnerability. So they found 14% and fixed them correctly. After the training, they found 81% of vulnerabilities and they found and fixed them correctly. So a huge improvement there. 100. All of the developers who did the assessment, they did better the second time around. So all developers improved their ability to find and fix vulnerabilities and they found and fixed 5.6 times more vulnerabilities after the training. So it goes to show that the training is very effective and we provide the tools to be able to assess before and assess after the training.

So are there any trends you've seen, Jared, based on people have gone through your program and maybe things that people struggle with in the beginning that if they focused on, they automatically have an upshot in their security testing efforts?

Yeah, definitely. I mean, we've seen if you train developers, you can remove whole classes of vulnerability. So simple vulnerabilities like SQL injection, if you just train developers, you can remove those.

A lot of teams, once they train on that, they'll see with their static scans and other ways to find vulnerabilities that they're gone, they're no longer in their code. Obviously, there's always going to be vulnerabilities. Training is just one step in removing them from code. But for some of the simple ones.

It can be.

Very effective to train them.

I was going to say, Joe. In addition to that, what changes is that when a developer gets the output from a security team or from a static analysis tool, they usually push back. They're like, I don't know, I don't get it. When they have training, the tool goes from being a nuisance or a nag to being helpful. And that's what we're looking for.

So it sounds like after they take the train, they have actionable things that they know they need to do as they're developing software to be successful with it, I guess. Arthur, what does powersoft bring in? Are you bringing some studies and research and you help shape the curriculum?

So what happens is that we're helping companies do cybersecurity and the way that we do, it's a little different. We, we don't focus on the red team side, we focus on the build better software side and we actually focus in a very thorough, methodical way. What happened is that as we started looking at various standards like OWASP and cwe, we found out that the major vendors and the open source tools don't do a good job covering these standards. It's not uncommon for a commercial tool to to claim coverage of the CWE top 25, but only do half of them. So we started treating it like functional safety, and we said, okay. To do functional safety, we have to map every requirement to an action that occurs in software development. So we take the CWE top 25, we have static analysis checkers that apply to them. And now we want developers to be very rigorous. We found that to get them to be rigorous, they have to have this understanding of why they're doing it, what they're doing. Because we're not asking them to test, we're not asking them to be testers at all. We're asking them to build better code. The things that we're telling them are going to feel like a nag.

Because it's not, again, showing you a hack. It's showing you a piece of software that could be hacked. If you're an engineer, you don't say, prove it, you say, oh, let me worry about that. Let me do that right. To me, it's a really good marriage because we want to build better software. We don't want to just test security into the software. We want hardening the code in the first place. Getting static analysis out the door with trained people just seems to be the best way to really have some effect.

Nice. Looks like a really cool concept. Jared, who's this for, though? Is it just for developers and companies or individuals? If I went here, do you have a plan for individuals? Is it just for companies? I don't know if that makes any sense, but what's the structure?

Yeah, we do have a plan for individuals, although we really focus on companies. At companies, it's mainly developers who take the training. Some QA people will take the training, and then DevOps and security people take the training. A wide variety of roles.

We mainly sell the organizations, but if an individual wants to increase their knowledge in application security and secure coding, they can definitely sign up themselves as well.

There was a funny article that I didn't mention earlier that maybe you want to include. But in Harbor Business Review last August, and I'll send you the link there, there's an article that says every computer science degree should require a course in cybersecurity. So it's funny because my initial response is, yeah, that makes sense. That totally makes sense. And then my secondary response, as I think about it, is go, wait, they don't.

At this day and age, we have people giving out computer science degrees without and by the way one course, really?

Oh, my gosh, that's a great point. So hopefully Hack Edu is going to address that need, I guess, is one of the main things, right, Jared?

Yeah, definitely. You know, unfortunately, universities are kind of slow to adopt new curriculum. You know, they're kind of set in their ways. But we do see more and more, you know, universities are starting to get involved. They'll take, we do offer some free content. Some of them will give. We've seen some courses, some computer science classes, assign some of our free training to some of their students. So we see more and more. Although even at the top, the top computer science programs don't have set curriculum for secure coding training.

That's not frightening at all.

Before we go, is there any last parting words of wisdom? You want to lead the guild and what's the best way people could find out or learn more about Parasol or Hacked?

Yeah, so at Parasoft, we produce this blog. So blog.parasoft.com you can always find out the latest. We have pretty regular static analysis and security content in there. And again, we take a very strong approach toward building good secure software in the first place. And in a way that is very approachable and manageable so you don't have to spend a lot of time trying to figure out what to do the configurations. We have, like, we have one for OWASP and every checker is labeled like owasp. We have one for CWE and every checker is labeled like cwe. So no translation, great reports and stuff, but just that preventative, effective approach. Parasoft.com Try, you can try stuff out. So it's really cool. We have our own little things, kind of what everybody's doing these days, right? We can stand up a VM and try stuff out in it and see how it works. And it's. It's pretty cool. But I'd encourage that. If you want to get scared, go look at the SQL Injection hall of Shame and see how much SQL Injection is still working. We see your listeners won't see the camera, but Jared's now smiling because I've been on this roll with SQL Injection for a decade, that it's one particular security problem that is ubiquitous and 100% preventable. There are things that are hard. SQL injection isn't one of them.

Yeah, that's right. So, yeah, to learn more about HackedU and our training and even try out some free lessons, your listeners can go to hacked. Com, that's H A C K edu.com.

Thank you Arthur and Jared for your security testing awesomeness. The links to everything of value we covered in this episode. Head on over to testguild.com S09 and while you're there, make sure to click on the Try It Today link under the Exclusive Sponsor section to learn all about Micro Focus Fortify, which is the recognized market leader in application security. You definitely want to check that out. So that's it for this episode of the Test Guild Security Testing Podcast. I'm Joe and my mission is to help you succeed with creating end to end full stack security Testing awesomeness. As always, test everything and keep the good. Cheers. Thanks for listening to the Test Guild Security Podcast. Head on over to testguild.com for full show notes, amazing blog articles, and online testing conferences. Make sure to subscribe to join the Guild and continue your testing journey. This has been a Joe Calantonio production.