Fuzzing, security testing and tips for a career in AppSec

Chris Sienko: It’s a celebration here in the studio, because the Cyber Work with Infosec Podcast is a winner. thanks to the Cybersecurity Excellence Awards for awarding us a Best Cybersecurity Podcast Gold Medal in our category.

We’re celebrating, we’re giving all of you the gift. We’re once again giving away a free month of our Infosec Skills Platform, which features targeted learning modules, cloud-hosted cyber ranges, hands-on projects, certification practice exams and skills assessments.

To take advantage of this special offer for Cyber Work listeners, head over to infosecinstitute.com/skills or click the link in the description below. Sign up for an individual subscription as you normally would, then in the coupon box, type the word cyberwork. No spaces, no capital letters, and just like magic, you can claim your free month.

Thank you once again for listening to and watching our podcast. We appreciate each and every one of you coming back each week. Enough of that, let's begin the episode.

Welcome to this week's episode of the Cyber Work with Infosec Podcast. Each week I sit down with a different industry thought leader and we discuss the latest cyber security trends. How those trends are affecting the work of infosec professionals while offering tips for those trying to break in or move up the ladder in the cyber security industry.

Today, we have a repeat guest, Dr. Jared DeMott appeared on Cyber Work way back in October 2018 back when we were still called Cyber Speak. He's the CEO and founder of VDA Labs. We spent a lot of time last time talking about IoT security in that episode, but considering that Jared is also the author of Fuzzing for Software Security testing and Quality Assurance, I want to go deeper into CICD fuzzing, dynamic analysis, security testing and other AppSec tools as well as give you some tips and suggestions for entering the field yourself. So we’re looking forward to this talk today.

Dr. Jared DeMott is an information security expert and previously served as a vulnerability analyst with the NSA. He holds a PhD from Michigan State University. He regularly speaks on vulnerabilities at conferences like RSA, DerbyCon, Black Hat, TourCon, ERCon, HITB, etc.

He was a finalist in Microsoft’s Blue Hat Prize Contest, which helped make Microsoft customers more secure. Dr. DeMott has been on three winning DevCon Capture the Flag Teams and has been an invited lecturer at prestigious institutions such as United States Military Academy. Jared is also a Pluralsight Author on the Synack Read Team and a professor at DSU.

Jared, welcome back to the program today.

Jared: Thank, sir. Yeah, great to be here.

Chris: Yeah. Back in October of 2018, I had to go back and look and see when we last talked. We asked you about your security journey and how you got interested in AppSec and related fields. At the risk of repeating ourselves, could you summarize again how you got to where you are now and some of the key events that got you interested in AppSec and security in general?

Jared: Yeah. Sure. Yeah. It’s kind of like anything else in life. Expect some unexpected surprises. Originally, I thought I was always kind of into technology and engineering as a kid and I thought, “Well, maybe I’ll go to the Air Force Academy,” and then that is my folks thought, “Maybe that's not a great idea.” I said, “Well, what if I go to college?” So they thought that was a better idea.

I was all set to take a job at a big company doing Unix IT admin stuff, which would’ve been a great career. But then at the last moment I got a call from an organization I never heard of and they said, “Hey, we’re the NSA. You should fly to Baltimore and we’re going to give you an interview.” I thought, “Hmm, what do you guys do?” He's like, “Well, just talk about it when you get here.”

Chris: That’s exciting.

Jared: Yeah, exciting.

Chris: We need talk to about it when we get there.

Jared: Right. Immediately, they hook me up all these stuff and got engaged in this situation. It was very exciting and a good place to start a career because you’re – Before cyber was really even a word, so this would've been the year 2000 when I graduated college, and there were no cyber degrees. People really weren’t even using that term. It was more like maybe people were talking about IT security even, not so much on that, but a little bit.

Got kind of into a field early and was able to kind of leverage that inside and just the blessings of the people I met and the skills that I gained to go on to get a master degree and write a book and get a PhD and work in various interesting places and ultimately found my own company, Vulnerability Discovery Analysis, VDA Labs.

Chris: Now, did you sort of move into your sort of specialty just because it was like a thing that was interesting at the time or was it just a thing that was needed? Like when you started sort of moving toward AppSec and the sort of tools around that, was it like, “I really, really like this, or is just the company that I'm working with needs this from me, and so I might as well go this way.”

Jared: Yeah. I think any time you're faced with opportunities, you want to capitalize on those, right?

Chris: Oh, yeah.

Jared: So, that’s true. When you're in the workplace and it's like, “Hey, this cyber thing is really important. People have really hard challenges. Can you help with this portion or that portion?” I'm sure we'll talk about many of those different things throughout that.

Yeah, exactly, the passion that I had for the field just continued to grow. I love it. I’ve been in this field 20 years never been bored. There's always something new to learn. Td to me, that's really been a treat.

Chris: That's great. That's always encouraging to hear. The last time you were here, we mostly talked about hacking the Internet of Things. Just to get sort of a catch-up for the last 18 months or whatever, how has IoT security implementation been going since we last spoke? Had there been any major setbacks or advancements or things kind of proceeding at a steady pace? I know that the number of IoT devices is going up exponentially, and I've had a few guests that have said that the security for them is not necessarily been keeping up.

Jared: Yeah. When it comes to the Internet of Things, devices of all kinds. Of course, like everything we see in security, there's a broad spectrum, and that happens because of a lot of kind of broad reasons, right? You might have a company that has no information security program and you might have a company has a very mature information security program. So you see this wide disparity of what we do see out in the industry as we work with clients and things. It's the same with devices. It's the same with applications, rather it’d be web, mobile, whatever. You have this huge disparity of companies that are really doing a great job and others that are not doing a very good job.

I think as we talk through some of these other things today, we’ll probably dive deeper into kind of why that is and what's going. Certainly, one of the big things in IoT is connectivity, and that's happening across the board and technologies. You’ve got all these APIs now that are connecting application program interface that connect a mobile app to your car, or connect a smart camera to your web browser or whatever it is. The connectivity I think is really the bigger story than just the individual device here.

Same thing, you can go now back and listen to our podcast two years ago and hear my thoughts on what's going on with device security. I don’t think all that much has changed there. I think some are doing it well and some aren’t. But kind of the broad connectivity I think is really kind of the new story here.

Chris: Can you – For those who don't necessarily know the distinction. What is the distinction between the security of the device and the security of the connectivity?

Jared: Sure. Yeah. The device, it depends exactly on – It's all about the low-level implementation details, but it could be that you have, say, an embedded Linux system that's running certain types of services or processes. So think of like maybe a camera or a home route, but it could be anything. It could be – Maybe we wouldn't call it IoT, but any kind of connected device, rather it's a military vehicle, or – I don’t know, some kind of system in the school that allows teachers to get notifications if there’s an event. There are so many different types of systems that are all connected now. So the device security would deal mostly with the operating system, embedded system that service these ports. How that system is kind of configured in a standalone. Like if you were going to attack a system, you would have to maybe port scan and figure out what ports are open, and does it use SSH instead of Telnet, and all these different kind of things, kind of more of a traditional operating system, security assessment, versus what's the broader impact when this thing is connected to everything else. How do people use it? How do they login? How do they communicate with it from their mobile? That's kind of the difference between the connectivity and the API that I’m talking about versus just the device.

Chris: Got you. Got you. Okay. We’re going to move on to sort of the main section of what we want to talk about today. As I mentioned at the top of the show, we used to be the Cyber Speak Podcast, and now we’re the Cyber Work Podcast. With that, we’ve move toward emphasizing not just discussion of current cyber security issues or topics in the news, but the ways in which our listeners can use this info to advance their own cyber security careers.

Based on your authorship of the book we mentioned at the top of the show, fuzzing is obviously one of your main points of expertise. For those new to the topic, can you describe fuzzing as a hacking tool or just a tool for vulnerability assessment? How does it work? What does it accomplish and how is the practice and technique of fuzzing changed at all since it was first introduced as a method of revealing vulnerabilities way back when?

Jared: Yeah, sure. One of the things I always like to do is kind of pull back a little bit from the jargon just in case somebody doesn't get lost. Maybe they’re not real familiar with fuzzing or whatever. But really, what we’re talking about generally speaking either from a defensive and application security standpoint or perhaps from offensive attackers trying to find vulnerabilities in your systems, there are different ways you can do that. There are different testing techniques.

There’s static analysis, where you're just looking at the code or the binary kind of in a standalone fashion. With tools, kind of scanning through and looking for certain patterns that might be indicative of vulnerability, and then there is dynamic, more runtime techniques, and that's what fuzzing falls on, to a runtime technique. Sometimes that’s called DAST or dynamic application security testing versus SAST, static application security testing. There're other kinds too. There’s one called IAST. There is internal testing as something runs. Then of course there is manual penetration testing and code auditing that should happen. There are all these different pieces, and I think what we want to do is, maybe throughout this dialog canister, kind of start to pull that apart and break it apart and really talk about what should be in an AppSec program.

Chris: Please. That’s great. Okay. I guess to start with, my first question was kind of walk me through a sample fuzzing session. How does one initiate the process? What is the process exactly do? I guess most importantly, how do you read the results of a fuzzing session? I’m reading it, and if it's creating thousands or even tens of thousands of these crash browser results, how do you read the results? What actual information can you get from something that's basically just sending chaos into your system?

Jared: Yeah. Again, one of the things, let's take a step back from that and talk about when is fuzzing really even appropriate. The term fuzzing, most often, although it could be used in many different contexts, it's most often used in the context of what we call native code. What I mean by native code is that’s typically something written in either Assembly, C or C++ that's fully compiled and it runs natively on your processor architecture. It’s not interpreted through some other different type of higher level virtual machine or something. Fuzzing is kind of most often used that. In that sense, what you were just talking about is one of the failures that you're looking for, and that's what you need to understand, is what is a fail condition look like for our code? Would be some kind of crash indicative of a memory corruption vulnerability.

Now, pause on that for a second and talk about managed code, because much of the code – Native code and fuzzing is never going away just so you know. People have been talking about maybe C++ or C would go away some day. It’s not going to away. It's going to stay around, but it's also not really growing at the rate that managed code. So you talk about Rust, Go, C#, Python, Java, Ruby, all these different managed languages that run through like the Java Virtual Machine or the .NET framework. Those are different. Just the way they – Because they're not fully compiled.

So what they do and what the point of those languages is to be a little bit safer to develop and they shield the developer from making common memory corruption errors. You'll still have plenty of vulnerabilities in your code, but they'll be more like business logic, and SQL injection, and command injection, at OAuth’s top 10 type vulnerabilities rather than native vulnerabilities.

Chris: Which have their own solutions. Yeah.

Jared: That’s right. You got to step back and figure out, “First of all, is this thing we’re talking about, does it even make sense for me?” I'm sure we’re going to get into that more.

Chris: Okay. Yeah. Fuzzing is a very old technique obviously. In my research, it seems like it goes back to the 80s. But I imagine the actual tools and methods of fuzzing have changed a lot in the meantime, and you said that they aren’t necessarily growing at the rate that other systems are. Are there any new tools or methods that might change the way fuzzing-related vulnerability tests are done in the years to come?

Jared: Well, so let me clarify it. I didn't mean to say that fuzzing is not growing. The importance and the need for fuzzing is actually growing a lot, and there are some very new tools and some very new techniques. What I meant was the type of systems, think about spaceships, helicopters, cars, industrial control systems, Linux, Windows kernel, desktop apps, like Office and things like that. Those are all written in C and C++. So those are going away. It's just that we’re not creating necessarily new kernels every day at the same rate that we’re creating new web apps, mobile apps, APIs, REST APIs and all these different things.

That managed code is growing faster than a native, but it doesn't mean that application security and security testing for both of those, the need for that is rising dramatically, because as we see, there's just so much more code and technology out there that the need to create an application security program is going.

So let me just mention, and then we'll get into that more too about the AppSec. A couple tools that come to mind in terms of since you mentioned fuzzing. We could talk about the other languages and other tools that are appropriate in different contexts. But a couple tools that come to mind, there is open source stuff that Google has made/ A lot of their stuff is great. There are two commercial tools, one by Mayhem, by a company called ForAllSecure, and one called MSRD, Microsoft Security Risk Detection by Microsoft. Both those tools are great fuzzing tools that we use with our clients. I highly recommend those. If you want more information, certainly we can get you that.

Chris: Okay. Yeah. Yeah. Could we sort of go through some of the – I guess, yeah, I do want to sort of pull that apart. You said that obviously the uses of fuzzing are continuing to rise. But I guess what I was trying to get at was that it doesn't sound like necessarily the tools for doing it have changed that much in the last couple decades.

Jared: They have changed, yeah.

Chris: Okay.

Jared: They have changed. Instead of just kind of blasting a local process or a network service or something like that with random data and hoping to watch for it to crash, and then that's going to be a vulnerability. The way that they’ve matured and changed is there is a new technique called feedback fuzzing. Basically, we’re watching the application as it executes so that we can determine new test cases kind of automatically programmatically and drive for a better code coverage, which allows us to find deeper vulnerabilities in the application. Because one of the sort of criticisms of any testing technique at all is, A, none of them are perfect, right? They all have pros and cons. There is a need for kind of overlapping techniques across your AppSec program.

For example, static analysis is great. It works across all your codes. So it gets good breath, but it does have a problem with false positives and might not find everything. None of them do. Dynamic analysis, the issue there was it always more found surface level bugs, but they were real bugs. It didn't find as many false positives. But now assuming the advances in fuzzing, we can go and find deeper bugs that are just more surface level bugs. There definitely have been some advances in the algorithms, genetic algorithms, feedback, fuzzing, all these different type of stuff that's happened.

Chris: Yeah. I mean, based on my limited reading, that seem likely the case, was that you were just getting so many crashes that could be from anything that it would be very hard to sort of like weed- out what are the actual positives and what are the false positives, and that's still something that's being sort of contented with it sounds like.

Jared: For sure, yeah. There's a need to continue to mature to a lane just depending on you hope you’re finding a lot of results in crash. Sometimes you don’t, and sometimes it can actually be difficult to apply these tools in every case, and that's been one of the other criticisms of fuzzing, is that it's been a little bit more difficult to integrate into the CICD, which I’m sure we'll talk about. Where static analysis was a little bit easier to integrate, where fuzzing is sort of like, “Well, we have to wait till the program is ready, and then we have to let the fuzzer run for long time and kind of triage results, and hopefully we got good results.” That's getting better as well. The whole need and readiness for these tools to be able to connect in an ongoing way is something that we need to talk about.

Chris: Yeah. Okay. Some of the topics that we discussed before the show that we would want talk about. I get the sense that they are sort of connected, but not necessarily doing the same thing. So we’re talking about – You mentioned dynamic analysis. Security testing your DAST, but also CICD, continuous integration and continuous delivery, which is more on the on the Dev side it sounds like. Can we talk about some of these individually and how the techniques are sort of used in tandem to strengthen your overall application security practices? Could you sort of design for me like sort of a passel of like which of these tools you would use sort of at different stages to sort of work together to get the best result?

Jared: Yeah, have for sure. One of the things that you want to think about is how do we do this at scale, right? If you’re creating like, say, a mobile video game and maybe you're going to push three updates a day or something. That's a lot. That’s what we call a continuous integration, continuous delivery CICD, or sometimes people call it DevOps. Sometimes people call it DecSecOps for adding security into that, a lot of different acronyms. But regardless of all these sort of –

Chris: I'm glad to hear that I'm not the only one who's confused.

Jared: Right.

Chris: Sometimes I look at DevOps, DevSec. I don't know the distinction. Okay. Yeah. So there’s –

Jared: Yeah. You could call it SecDevOps, like I've seen all those words in different orders. It doesn't really matter. The point is, basically, how do we increase the speed that we can deliver things. How do we decrease the cost? how do we increase the reliability? Part of reliability of course the security. How do we increase the security of everything we’re doing but do it at scale?

For example, we do yearly pen test for companies and code audits, and that's always going to be there. That's always going to be important. There’s a need to have – it’s usually a regulatory need. In fact, compliance need to have an external organization audit your stuff on a regular ongoing basis. That's never going to go away, but you can't audit the way that these things are happening at scale fast enough to make sure that.

What the CICD is, basically, the idea, and without going through every little detail on every tool, the idea is when we commit some code, it's going to get scanned in some way. It's going to create a build, maybe a container, whatever it is, and it’s going to be checked to see if it passes or fails. If it passes, it goes to a staging area and eventually in a production. If it fails, then the developers need to address those vulnerabilities. So that cycle of sort of create, design, test, push, test, release. That has to happen in a very rapid fashion.

Chris: Okay. Is this something that VDA Labs, do you sort of like design this sort of suite of tools for – Or sort of use them in sort of a case-by-case basis with your client?

Jared: Yeah, and that's kind of part of what you want to do, which is you want to start with this whole – We can even do an assessment call, the software security maturity assessment. Basically, what that is, is we can take a look at your program and figure out have you done the right things first? Have you pushed left? What that means in terms of what we call SDLC, or secure development lifecycle, is have you gotten executive approval to do security well? Because if nobody even cares at the top, what are we going? You’re not going to ever get budget. You're not going to get – Have you done the right things on that? Have you trained developers? Have you done the hard work to set up whatever testing and development, infrastructure you need? If you're going to go for a CICD, that's a whole thing, developing, that's a whole process, and then making sure that security is baked into that.

Chris: You’re changing the nature of the way your developers work it sounds like.

Jared: That’s right. Yeah. Kind of considering all these things up front, we’ve kind of developed a whole strategy we call application security as a service, and basically it's not just doing that yearly pen test. It's not just training your developers. It's not just helping you integrate a static or a dynamic analysis tool or doing there the risk assessment upfront. We do all those things, but we do it on an ongoing continuous basis to make sure that you’ve got the whole program properly set up. That's really what companies need to be working toward.

Chris: Now, it sounds like you – Obviously, you do a lot of work for your client upfront, but then part of it is that you're sort of leaving them alone and you're hoping that they're going sort of take on the changes or integrations that you’ve suggested for them in their day-to-day practice. Do you have a pretty decent hit ratio of people who sort of integrate this stuff into their practice and then continue doing it or is it a sort of thing that's kind of hard to take and developers say, “Oh, I don’t want to do all these extra steps or whatever,” and then it sort of falls by the wayside. Is that a common thing?

Jared: Yeah. Like I said at the beginning, is we do see a broad-spectrum, and that's for better or worse. You have some companies doing really great, some doing absolutely terrible. Most are in the middle somewhere, and sometime it’s kind of – We see these shifting priorities. Like right now, I mean, I don’t know how events that I was going to go to Arkansas because of the whole coronavirus thing.

Chris: Of course. Yeah.

Jared: Sometimes security could be a little bit like that where it's like, “Hey, something is hot today. Let's all get in there and do a pen test and do some fuzzing and really hit it.” Then a year later it's like, “Hey, did you guys do with that hole?” It’s like, “Well, it kind of got dropped as a priority. We’re going to get to it real soon again.” That does sometimes happen unfortunately as things kind of go hot and cold. But the better companies are not doing it that way. The better ones are making this part of an ongoing strategy and they have a repeatable, reliable automated process to get as much of this in there as they can.

Chris: Do you have any sort of advice for being one of those better companies? A way you can sort of change the culture or incentivize folks to actually sort of get into there, or does it doesn't really happen just case-by-case?

Jared: Yeah, for sure. I mean, part of it, again, it goes all the way back to approval, leadership. Do they have somebody in the right seat? You'll see this across not just AppSec, but even IT security, right? It's like rather they’re a smaller company, whether they’re director of ITs, managing security, or maybe have CISO at a company. If you've got a great leader in that spot and they've been able to get budget and hire the right people and create the right culture around security and whether they’re their outsourcing their stock or not. You see the same thing on the AppSec side. If you’ve got a great development manager or a senior product security manager, some even have a chief product security officer, depending on the size of the company, and they've been able to create this culture. Again, rather they outsource the AppSec as a service or they do it in-house, it's the same situation. It's building that culture and taking the time to really make sure that you’ve got what's appropriate. You don’t won’t to overspend on security. If you’re spending a billion to protect a million dollars, that doesn’t really make sense, right?

Chris: Good point.

Jared: If somebody sit down and do the risk assessment and kind of come up with the business logic and go, “Okay, this is critical to our business. This is what we do. We protect health records,” or whatever it is that your company protects, we need to think about what does this worth to us? How much we’re going to spend? Let's be serious about this and kind of mature what we’re doing.”

Chris: Okay. Hopefully, if you’ve been listening far enough to this point, you’ve decided if doing this type vulnerability assessment or sort of starting these systems is appealing to you as a career. So let's talk about the careers in these fields, vulnerability discovery and application security. What are some crucial project skills search or other methods of learning that would really be helpful in getting you up to speed in this growing field?

Jared: Yeah. No, that's a great question. I am always a big fan of the fundamentals and. Sometimes there are certs that come and go, and all those things are great. We can talk about those.

Chris: Yeah. You can get too specialized.

Jared: Yeah, and those are fine. Those are good in many cases. But fundamentals like networking. TCP had been around forever around, operating system, knowledge and internals. I mean, Linux, Windows had been around forever. Coding, understanding how to code in a lower level, medium level, high level, something between C and Python and maybe C# or Ruby or whatever.

Chris: Having a lot of languages in your tool belt.

Jared: Knowing something about software development. I mean, this goes all the way back to what should be happening even in K12. I've got two sons. One in middle school and one in high school, and I've been telling their district, “Hey, are we teaching computer science fundamentals?” I get that not everybody wants to be a programmer when they grow up, but even just some of the basic reasoning about logic and things like that is something that many of us should have. Then of course, staying current on technology.

Chris: Yeah. How would someone who is in another area of cyber security who might want to switch over to AppSec go about enhancing or modifying their skillset to be more desirable to potential employees? Because we might have security analysts or pen testers or related fields, but what are some things that they might need to learn or adjust in their skillset accordingly?

Jared: Yeah, I would say continue to dive deep. Most people in the field kind of know what that means, but if you’re not, then you got to figure out, “Okay, what does that really mean?” For example, deeper software analysis and exploitation, learning about that, what we call TTP's, the tools, techniques and procedures in those fields. A couple examples that might be moving from just like a scanning tool, like Nessus, great tool, to Visual Studio. Learning how to look at and read code. That's a big transition between kind of a lighters skillset of, “Hey, I run this and it pops out some results,” versus, “I can actually read this code.”

You could take that same idea to do other things like maybe transitioning from just running a module in Metasploit to actually being able to do some active analysis manually with Burp to inspect web APIs or something. Same thing on kind of a SOC side, just from looking at alerts that come out of your SOC tools to like actually been able to reverse malware. In any of those domains, like what's the next, more complicated tool that I could learn about. rather it's something I haven’t used in there all the time or not, at least I know about it and can find my way around it.

Chris: Okay. Okay. A lot of those things, I imagine you can get the bare basics you need over like a heavy weekend or something like that or a week of concentrated study.

Jared: Yeah, there are a lot of good training. Obviously, you could take training at a conference like Black Hat, we teach a class there called application security for hackers and developers, and we cover a lot of that. A lot of that's on other training platforms, like PluralSight as well. Of course, you could just probably find stuff on YouTube or whatever. There're a lot of different venues if you're invested. Yeah.

Chris: Yeah. A couple of weeks we had a guest who came to security kind of later in his career. He had previously owned his own company and worked as an insurance actuary and had a lot of non-tech job. We like people to know that security either can be a destination or it can take you to other destinations that aren’t necessarily tech. Could you give any advice for people who are looking to make a curse which into AppSec and vulnerability research from other careers or walks of life but might be intimidated by the tech barrier?

Jared: Yeah, and that's a great question, because one of the things we look at when we’re considering candidates and things is really passion. It’s sort of like – I mean, even just this podcast that you’ve put together. You guys do a great job of putting together information and making it available. I mean, if you've never heard of this, why not? Do you know what I mean? What are you doing? Are you taking any time? I was just interviewing a recent college grad the other day and it's like it had a very vanilla resume and he was like, “Well, I went to class and did all my work.” It’s like, “Okay. Well, that's good. I get that. That's great.”

Chris: Yeah, we all do that.

Jared: That's kind of the minimum.

Chris: Yes.

Jared: But in a field like cyber, for whatever reason, we want a lot more than the minimum. We want to see that you actually care about this, that you went out you found these podcasts. You competed in a capture the flag. You’ve got to GitHub repo I can look at. You’ve got some CVEs maybe from vulnerability you found our you went and got that cert. Not that certs are the most important thing, but they are. They do show some exter kind of above and beyond. Maybe you went and got your OSTP. That's a really good one for showing that you have the ability to go slightly deep.

Some kind of passion that tells me I didn't just put in my time. I kind of – I’m actually interested in working with you in this field.

Chris: Okay. Yeah, OSTP is a good example. I was going to ask, and you sort of said it here, but are there certain things that you might see on a resume or in a cover letter that makes you think like this person definitely has gone – Before you get to the interview stage, are there things that sort of will cause you to put the resume on the consider pile?

Jared: Fore sure, yeah, and it's all those things I just mentioned. Any of the exters. Just showing that you got through, you’re a good student, whatever it was. That's all important. I mean, I do think there's something to that. I think some people just say, “Well, grades don't mean anything at all in high school and college.” I disagree with that. I think it shows diligence throughout your life. If you are able to get good grades in high school and college, that shows that you’ve been working hard.

I mean, certainly, that's important, all of that kind of stuff. But showing that you’ve also taken the time to get some real hands-on skills is very important in our industry. In some ways, almost like a trade industry, where if you want to be a pen tester or a code auditor or a SOC analyst or something, you really need to show that you can do the job too.

Again, showing that you went to some of those extra events where you attended GrrCON or the DakotaCon or some conference of kind of on your own time. It was on a weekend. You took time, or maybe you even had to pay for it or whatever. You've invested in yourself to the point where, “Hey, you care about this.”

Chris: Right. Yeah, you’re clearly interested in the subject and not just getting the job.

Jared: That’s right.

Chris: So if you're already doing AppSec at a lower level and you want to move higher up the ladder, what are the skills or leadership moves that you would need to make to sort of climb the ladder of the career? Apart from starting your own company, what are some other top level positions of people working in AppSec should be honing your skills to work toward?

Jared: Yeah. One of the things I love about our field is I do think there's multiple pass there for anybody just depending on your personality and your skillset and your passion, your drive. A lot of companies have kind of what you would call like a technical track. If you want get a raise or go to the next level, you don't necessarily need to go into management or whatever, because that's not for everybody. You can just continue to hone your trade, be the best, very best at what you do and be excellent at what you do, and you can go probably about as far as you want to go.

On the other hand, if you are interested in leadership, hopefully it’s not just kind of this bland idea of managing people, but this idea of leaving people on kind of organizing the business and caring about the whole organization and have to deal with the financials of who gets to go to training this year? What technologies do we invest in? I mean, it’s a situation that I can tell you. For me, when I switched from more of a technical career, now into handling more the business aspects as well, the skills that brought you to where you were are I not the skills that are going to take you where you're going. I'll tell you that.

Chris: Right. Yeah. We get that some times. We’ll get guests or we’ll have people who will comment and say, “I don't want to advance too high, because I don't get to do the thing that I actually love doing about the thing.” So it's good to hear. What would like a really high-level sort of AppSec person who’d opt not to go into management? What kind of things would they be doing that's different from what they're doing now like on a larger scale?

Jared: Yeah. You might start out, and this could be in any field. You’re kind of a junior engineer and then you go to engineering and then you go to senior engineer, and then usually there's some kind of higher-level roles where you might – Depending on the big company. Rather it's a big company like Microsoft or whatever. There’re all these different companies, there have different titles. They might call it an architect or a principal or a fellow, technical fellow is a term you might have heard. There're all these different kind of where you can quite high up in an organization and make very good money and that kind of stuff, but still be able to apply your technical passion to solving technical challenges, because I do think that that's something that the world needs. I mean, there're too many people that are just like, “I want to be a bland A,B,C business person, and I know ave something about sales or whatever. So I'm just going to go out and make all these money and I’ll let the nerds do the hard work.”

I don’t think that paradigms ever been fair and I think it continues to still slightly be not fair. I do think the world needs to kind of wake up to that a little bit and go, “No, the smart people doing the work need to be taken care of and compensated and be part of what's going on just as much as these so-called business wizards.”

Chris: Okay. We’ve discussed this a bit, but since the technology all around the tools and techniques we’ve discussed are constantly changing, are there certain things that students or other entry-level people trying to break into the field should be learning that will likely – That aren’t now, but might become huge parts of the standard AppSec or vulnerability testing security practice?

Jared: Yeah. I think kind of what we talked about, the whole DevOps thing is really still pretty new for a lot of organizations. I think that's going to continue to accelerate over the next 5+ years. What's interesting is they’ve traditionally been very separate pieces of the organization. So you have developers over here. You had IT operations over here and they didn’t really play together so much, or if they did, it was only like, “Hey, once you get your code ready, I'll put it on my server and I'll tend my server and you don't touch it.”

Chris: It’s almost kind of protective too. It’s like we do our thing. You do your thing.

Jared: Yeah. It's kind of like – But now they really need to work together. The importance of both couldn't be more so in terms of how the – Because now we have things like infrastructure as code and all this thing, where the whole thing, the whole network, it’s all getting rolled out basically by some automation and the CICD as some kind of scripts or code or workflow and it's being continually pushed and updated as it's being containerized and change and all those kind of stuff. Having the skillsets – On the development side, it’s coding, its tooling, it’s being able to dive deep in that. In the ops side, again, it's networking, pen testing, IT, logging, SOC, all those things. We really need people that can work together, blend all those skillsets and help companies come up with the right package, and that's kind of why this whole idea of application AppSec as a service, where if you’ve got a team like ours that kind of has people on both and all of the sides of that, we can help companies kind of with each part of that.

Chris: Okay. I mean, that also sounds like a lot of the sort of difficulties right now is that people have been doing it one way for so long and they're reticent to change. Is this something else – I imagine that managers will want to kind of interview for and say, “Hey, if you're going to be a developer, be aware. You’re going to be working with the IT team. You’re going to be working with security,” and sort of get the idea of collaboration sort of upfront with new members of the group so that it's not so surprising when they get there.

Jared: Yeah. I mean, one thing you can always do if you’re ever wondering like what field is growing the fastest or whatever you can go to some job board. Maybe like in data – There are probably lots of other ones too. You can just look like what type of listing has been growing the fastest? You'll find things in the CICD, DevOps, REST engineers, API engineers, this kind of stuff like growing faster than like traditional IT listings and that kind of stuff. That's indicative of the change that we do see coming. So, for sure.

Chris: Start looking at all the requirements of those sorts of things and then start learning that stuff.

Yeah. So as we wrap up today, tell me a bit about – You mentioned before about VDA Labs. Tell me some of the projects and services you're currently working on, things you're excited about and so forth.

Jared: Sure. Yeah. We kind of have four pillars that we take care of. We have government clients. We've got kind of commercial enterprise organizations or nongovernment companies that we take care of in different ways. Td then we've got what we call makers, which are basically software type companies, rather it's a gaming company or an automobile, whatever it could. Make something either software, physical, whatever. Then we’ve got training that we offer as well across all those.

What we do in pretty much all those domains, although it's different for each customer set exactly. What you do and how that works and the language you talk and the mission that they're involved in. A lot of the skillsets actually end up being pretty similar. So it's all blue team, red team type. It could be more training, setting up this AppSec situation I was telling you about. It could be more red team pen testing. It could be you any kind of operational SOC, malware analysis. It could be a lot of different things across this whole set of compliance governance. There's a lot of different things that we could be setting up your sim tool. We could be doing a phish the operation front. I could go through every list of what we do, but that might take too long.

Chris: Yeah. It gives us a good start there, for sure. Do you have any sort of final tips or suggestions for people who are trying to break into this field?

Jared: Well, I you say, again, kind of apply your passion. Show that you're really interested. I mean, if you're just trying to make a bot, maybe – I don't know, go work on Wall Street or something else. But like if you really want to get into infosec, I think it takes a certain set of passion and be really – Weather you’re in love with the blue team, kind of protecting and building and growing or rather you're more in love with testing, code auditing, red teaming where you kind of like sort of poke holes and find the bugs and things that were missed. We need all of that right now. There's never been a more pressing need for people that are kind of passionate about information security.

Chris: Yes. If you’re really excited about the sort of problem solving aspect of it, there's got to be a ton of that here.

Jared: Absolutely.

Chris: If people want to know more about Dr. Jared DeMott and/or VDA Labs, where they can go online?

Jared: I’m pretty easy to find on LinkedIn. Twitter @JaredDeMott, and of course our website, vdalabs.com is a great place to find us all.

Chris: All right. Jared, thank you so much for your time and insights today.

Jared: Thanks for having me.

Chris: Thank you all for listening and watching. If you enjoyed today's video, you can find many more on our YouTube page. Just go to youtube.com and type in Cyber Work with Infosec to check out our collection of tutorials, interviews and past webinars. You'd rather have us in your ears during your workday. All our videos are also available as audio podcasts. Just search Cyber Work with Infosec in your podcast catcher of choice. As you saw, there was a little promo at the top of the show for a free month of the Infosec Skills Platform. Just go to infosecinstitute.com/skills and sign up for an account. In the coupon code, type cyberwork, all one word, all small letters, no spaces to get a free month.

Thank you once again to Dr. Jared DeMott, and thank you all again for watching and listening. We will speak to you next week.