Mark Willis -- I Just Like Static Analysis. Static Analysis is My Favorite

0:05Mark WillisThe Application Security Podcast. Here we go.

0:09Chris RomeoHey, everybody. We're back with another episode of the Application Security Podcast. This time, we talk to Mark Willis about many facets of static analysis and how it affects the DevOps world.

0:38Enjoy.

0:38Mark WillisHey, folks. Welcome back to the Application Security Podcast, and we are joined today— I should say Robert and I are joined today by Mark Willis. Mark, how's it going today?

0:54Chris RomeoVery good, guys. Chris and Robert, thank you for having me on the show. Doing great.

0:58Mark WillisYeah, we're glad, glad to have you here. And so, Mark, the first thing that we ask all of our, our guests here is, what is your security superhero origin story? So how did you get into security and what did that path look like?

1:12Chris RomeoSure. So I definitely wouldn't call myself a superhero. I think it's important to be humble in this field. because there's always somebody who knows more than you, and normally you don't have to go too far to find somebody at a conference or somewhere. But for my background, I guess you could say that I'm a former developer who ended up moving into the field. But to kind of lead you to how I got there, I would say it probably started in the late to mid— mid to late '90s when I was a counterintelligence agent in the Army. over in Germany. We were working on a program in between 2 deployments to Bosnia in '97. We were working on a thing called Digital Tradecraft, and that was where we were trying to make the Army and the DOD civilians aware of when spies meet the handlers, that the most dangerous time for a spy to meet a handler is face-to-face. That's when you can catch them, and that's the most dangerous time. So We were saying, hey, there's all these things called anonymous remailers, steganography, and PGP, for example. And those 3 things together was where I really started to think about computer security in this type of field. And that got my interest going about, wow, there's all these things going on in and out of counterintelligence. And at the same time, I was working on my master's degree in information systems management, and I started programming on my own in Java and C++. building some programs to get through the course and just kind of experimenting and having fun with it and finding out that I like to do this. From there, when I came back to the States in '99, I started working as a DoD contractor at US Army INSCOM, Intelligence Security Command, down in Virginia. I ended up becoming the IT liaison between the US Army INSCOM and the NSA personnel divisions, doing a lot of data transformation, SQL Server packages, really fun stuff, making data talk to each other from different systems and things like that. Then around in 2002, we started converting client-server applications to web apps using .NET, specifically using VB.NET. Then once we got that running, we started discussing and learning more about— I'm making quotations with my fingers— security. At that time, you're developing code and you're just getting things to work. Working in that environment, you're insulated and you maybe have a false sense of security because anybody who's on the network should be on the network and you really shouldn't be on there. We started to look at security stories about dynamic SQL versus stored procedures versus parameterized queries and things like that. We're like, wow, parameterized queries are far more secure to write than dynamic SQL. So let's go ahead and start fooling around with this. A lot of it was just self-learning. We started to develop things more and more secure. Then around 2007, 2008, I had a buddy who had a security company that I talked to quite a bit, and he says, listen, you got to try making that transition from developer to security tester/pentester/network pentester, etc., because I think you'll find it's a lot of fun. I think you'd be good at it. So he kind of bugged me about it. I finally started, again, with written permission, and I think it's very important for anybody who starts off in this field to make sure you get written permission from any place, any company that allows you to take a look at their code or their applications. I found that it was a lot of fun, and after my first brute force hack into the account of a vice president of a company that we were testing, I was hooked. I was like, wow, this is really cool. Then I started to find more and more things because coming in with the mindset of a developer, I was spotting things that other testers maybe weren't. Think about back at that time, Chris and Robert, it was like shooting fish in a barrel in some of these companies that we were testing. Things are far more secure out there today, but you think back in that time, it was pretty easy to pick up a lot of low-hanging fruit and then go deeper. I found that there were 3 things that drove me into this field. That was, one, you get to protect people's assets, you get to solve problems, and you ultimately get to help people become more secure. Those were the 3 driving forces that led me to finally cut the cord with being a developer and move over to being a full-time software security tester/pentester, depending on the type of engagement that we were doing at code review or web application, etc. Then around 2009, in late 2009, I was offered the opportunity to stand up a new software security team, work with a team at Aetna. I couldn't pass up the opportunity, guys, because Aetna, just to make a long story short, they literally saved my son's life. He just turned 18 yesterday. When he was born, he wasn't going to make it. He had an Apgar score of 2. Every time my wife picked up the phone and called Aetna, They took care of everything. It was a chance for me to give back, and I've been working there ever since. I've worked with lots of developers and security professionals since then. It's been a great journey to see how we're making software more and more secure all the time. That developer to application security professional, it's really helped when I have to sit down with developers and talk to them about code reviews and different types of security testing we're doing. I find that that experience and being able to speak their language and have that empathy, having a kind heart and sitting down with them and saying, hey, listen, it's okay. We've all written bad code and here's how you're going to fix it. So to make a long story short, that's kind of how I got here.

7:19Mark WillisYeah, I know. And that's— the empathy thing is so huge. I know that's something that Robert and I have talked with many other people in the industry about. It's really the piece that's missing. And, you know, we see it with the latest data breaches, the latest worms and ransomware things that are going around. There's so many people that still want to just point the finger at somebody versus saying, this is a team effort and we got to get together and figure out how do we solve this problem versus pointing the finger. So, that's really cool to hear that that's kind of your approach as well is sit in the developer's shoes because you've already been there before.

7:54Yeah.

7:55Chris RomeoAnd like I tell my kids, there's no I in team. You know, we used to say that in the Army all the time, but it really is true. that you really have to have that empathy for developers because they're on the front lines. They're on the front lines writing the code, and they're the ones that ultimately deploy this stuff. They're working very hard, and they're very busy. You don't want to waste their time with false positives. You want to be able to sit down with them and say, hey, listen, this is really what we need to focus on right now. This is a critical area that we need to make sure this is Make sure this is tight before it goes out to production. Those are the types of things that we can all do together as a team. They learn from us and we learn from them. Then you take that to the larger application AppSec community and listening to your podcast and your speeches, etc., I learn from you, you learn maybe something from me today. We all share because we're all in this together. That's the way I look at it. We're all in this together. all trying to do the right thing, sometimes at a very general level and sometimes at a very granular specific level. That's the cool thing about this work is that we can be doing this until the day we die, whether we're in our 80s, 90s, that we get to 100, and there's still things that we'll learn every single day. Those things that you learn, you can share with your developer buddies and back and forth, and it's a great time to be doing this. I'm just really glad I made that transition. I would encourage other developers who might hear this podcast to sit down and think about that if they're thinking about making that transition. Take it seriously because there is a need. There definitely is a need in this field for developers who have made that transition to security because you're really in a unique position, I guess, to have that skill set that's very, very much in demand.

9:53Mark WillisYeah, and it's one of those things that you think about it, even if we are working into our 80s and 90s as application security professionals, the problem— the need for us is not going to go away because there's always going to be bad people trying to do bad things in any media or forum that you give them. So there's always going to be a need for more AppSec people to be kind of part of this. So I want to poke a little bit here at your— so your focus is on testing then from a day-to-day, quarter-to-quarter perspective. Now, does that mean that you're actually testing individual web apps, or are you kind of more responsible for a testing program that fits into the bigger SDLC?

10:42Chris RomeoYeah, so that's a good question. So the larger SDLC is what we're is what we're involved with. And that is everything from, you know, once you get past— so if you're looking at the SDLC from like a left-to-right perspective, you know, you've got your typical requirements analysis on the left, and then, you know, there's things like threat modeling and, you know, brainstorming and things like that. And then you start getting into things like static code analysis, right, where developers are using standalone or IDE plugins to automate the static code analysis testing of their code. That is where the developers have that from their position, the automated tools to do that and to help them make their code more secure, weed out false positives, identify the findings that are critical and high, medium, low, and triage and all those types of things. Then Once that code is secure, then as it starts to move out to, you know, more of a dev and QA environment, then the, you know, things like dynamic analysis would take place. You know, this is pretty typical, right? And then where those automated tools come in, different types of tools that would be dynamically testing that. And that would be more where my team or other partners would be doing that. And then farther down the road, more afterwards, the software security testing as far as being out in production or from what would be considered an ethical hacking point of view, we would also supply our team to do those types of things. We are looking at our software on all of our web applications from a holistic point of view and starting from the code all the way out to production. There's really the chances for things to slip through are getting smaller and smaller. Those windows are getting smaller and smaller, especially compared to what things were like 10 years ago. It's just amazing how you can look at a process now from hands on the keyboard, what I always called the point of impact programming, where if your hands are on the keyboard and you're scanning your code with a tool to identify those the static analysis and analytic issues right then and there, then that's the place you want to do it. It's the most cost-effective, it's the most efficient. That's really where the action's at. Hopefully, our developers and developers in general will be able to catch the most serious vulnerabilities at that point before things move out eventually to production.

13:25Mark WillisYeah. Let's start with the world of static analysis. I've got a couple of different questions here, but the first one is, I'm going to I'm going to kind of take the devil's advocate approach here. The opinions I'm about to share are not really how I believe, but this is kind of what I— some of the— we get some common complaints about static analysis tools, and I get a chance to work with different industries and different size companies, and I hear a lot of these same problems everywhere. So I kind of want to get your take on how you— what you would recommend to those out there who are potentially going to be starting static analysis or they're doing it and it's not working well. And so one of the first ones we hear about all the time when someone rolls out these tools is there's so many false positives that this thing is not usable at all. What do you recommend to somebody that's hearing that as a complaint from their developers?

14:23Chris RomeoYeah, that's a common issue, right? And so Maybe it could be different things. It could be maybe you're just not using the right tool that's right for your environment, for your language. Maybe there's other options. Maybe you haven't chosen the right tool. If you're just using a tool right out of the box and the tool is not being tuned, then there's also that possibility that maybe with working with the company and documentation and what have you, maybe there's a way for for you to tune the tool to weed out those types of false positives. If you're seeing those types of things over and over again, you know, you can create rules that will exclude those if those are things that you want to minimize. There's different things you can do, but it does— anybody who just wants to take a tool and install it and then point, click, and go, your chances are you're heading for some frustration and you're not leveraging the tool most likely as it was designed to be used. I mean, there are reasons why tools have the ability for people to create rules and custom types of testing features within it because no 2 environments are the same. So I would say those 2 areas are what people should look at as far as their static tools. They're probably not getting everything out of it. If they're just installing, point-click, off you go, you really need to go through the documentation, work with the company, figure out a way to tune that tool for your environment. And I think that's probably a good place to start.

16:07Mark WillisYeah, I think there's a certain level of effort to tuning those tools, and a lot of folks forget about that. when they make the purchase and the installation, they don't set aside the correct headcount to actually monitor the tool and also do the tuning for that tool.

16:27Chris RomeoYeah, and maybe they haven't done, I would say, you know, before you spend the money on a tool like that, make sure you do the research. Have the people that, you know, that you trust the most, have them do the research and do the bake-off, you know, and do a, you know, an evaluation and say, you know, hey, before we pull this thing in-house, You know, can we evaluate this thing first? You know, can we run it for X amount of days against a code— a particular code base, a perhaps deliberately insecure code base, you know, depending on, you know, how they— how you have things set up? And maybe, you know, you can do that to— and then with research and reviews and things like that, find the tool that's right for you. And, you know, depending on— again, depending on the type of shop you are, what languages you're using. I think that all drives the decision-making process of picking the right tool. So one tool for, you know, one language shop, great, may not be the right tool for the other, and that's okay.

17:27Yeah.

17:28Chris RomeoYou know, you just have to— but if you don't do those types of things going in and you just say, hey, so someone says we need a static tool, so we're going to pull this in and run it, I think you're setting yourself up for some frustration.

17:40Mark WillisYeah. One of the things that I've recommended to people is, especially for those getting started with something like static analysis, is pick one thing in the policy and turn that on in the beginning and turn everything else off. So look at your historical record and let's say that SQL injection is the biggest problem that's been plaguing your web apps when you do— when you have external penetration testing companies look at them. When you first roll out static analysis, turn on the SQL injection rules and turn everything else off in the beginning. Because in my experience with developers, if they feel like something's going to be a hindrance and is really not providing the value that they're— they're not getting value for their time invested, they'll just— they'll try to put up a wall and try and figure out how they can say, you know, this is just— it's causing too many problems.

18:33Chris RomeoFor us.

18:34Mark WillisSo that's—

18:35Chris RomeoNo, I agree. I agree. I think that goes back to, you know, when I was talking about, you know, we talked about, you know, tuning it. I think that's exactly, you know, and to get to know your tool. And maybe with that, you know, when I mentioned have an eval period, if you can do an eval and like you said, turn it off and then just turn on 1 or 2 things, yeah, the frustration level will be a lot less. Especially if you know, hey, yeah, we are prone to SQL injection attacks or cross-site scripting, or those are the big ones that we care about. Well, yeah, turn everything else off and tune that thing to give you some decent results that developers might say, okay, cool, this is something we can work with. Yeah, I totally agree. I totally agree.

19:20Mark WillisYeah. So, what do you think about static analysis in a DevOps world, though? where you don't have necessarily the time to run a full scan of an entire codebase for each time that you— if you're pushing 20 new versions of software per day in a full-on DevOps build pipeline, what do you think about static analysis in that world, or what do you think companies should do to use static analysis in that type of an environment?

19:50Chris RomeoYeah, again, it depends on your cadence, right? Often, you're building and going. I mean, but you're right. I mean, there comes a point you just can't sit down and, you know, do the full, you know, traditional static analysis in that type of environment. You have to be selective, and you have to be targeted, and you have to be willing to— in that type of environment, I think you have to say, you know, we're going after the criticals and highs. We have to know that.

20:22Right.

20:23Chris RomeoRight, we have to know that, but maybe the mediums and lows we can, you know, we can triage and pick up at a later time. And that's one option, right? I mean, you just— in that type of environment, it's so rapid that you have to really say, if we run this tool, you know, once a day or once every other— I mean, what are we going to get out of it? How are we going to— how much time do we have to interpret the results?

20:50Yep.

20:51Chris Romeoand actually turn this code around. We may identify an issue today, and then by the time we fix it, we're already 3 builds later. Those are things how this stuff goes. Again, that's where the management and the developers and security all have to sit down and say, okay, here's the acceptable risk behavior of our static program. We have to think about how this is going to to be able to identify issues without killing our developers and our development cadence. Because like you said, we don't want our developers to be frustrated, but we need our software secure. It's a little harder for that balance within DevOps. You've got to be able to— but at the same time, you do need to identify anything that's being introduced that's going to be devastating to your application, you can't— realistically, you can't let that out into production with something significant. It has to get fixed.

21:53Mark WillisYeah, and I don't— you know, I've heard of some people, what they do is they'll break the build if they have a critical or a high finding. And just depending— some of it, I think, depends on the languages that you're using. You know, like if you happen to program in Ruby on Rails for your apps, Then there's an open-source static analysis tool that runs in like 15 or 30 seconds over an entire Rails app. So you can fit that into a build pipeline without causing too much hangup. But I know from past experience that if you're using some of these tools, they take a lot longer than seconds to run. And so yeah, you got to find the right cadence to connect so that everybody's happy. So so that the developers are happy, the operational running of the system's happy, and you're still getting that right level of security protection.

22:48Chris RomeoMm-hmm. Absolutely.

22:50Mark WillisSo, Robert, what's been your experience if we transition into the dynamic space or dynamic tools? Have you used any of the tools out there in dynamic world?

23:02Chris RomeoJust a few. Mostly, it's been on the static side. In fact, I was going to ask that same question just to get an idea of, Mark, what's your experience as well with the dynamic tools? Yeah, so, you know, not to— again, not to name, you know, particular tools, but using dynamic tools, I think dynamic tools— I've always said dynamic tools get you to the ballpark, right? They get you to the big game. They get you to the ballpark. They get you on the field. You still have to know how to swing the bat and catch the ball and throw the ball, right? So the dynamic tool will get you in the ballpark, it'll get you on the field, it'll show you potentially what is wrong with a web application that has made it through the static and now it's in the dev or QA area. Now you're dynamically testing it, but you still have to have the techniques and the skill set and the right people on the field to be able to plow through those findings and again weed out the false positives because there's inevitably going to be false positives and to be able to retest the ones and say, aha, confirmed. Yes, we, you know, we have X amount of cross-site scripting or X amount of SQL injection or improper error handling or URL redirects, whatever the tool is telling you. It saves you a lot of time from the sense of, okay, it's giving us a bucket of findings, but we've got to— now we've got to reach in that bucket and pull them out one by one and test them because you just can't throw it over the wall and say, hey, developers, here you go. You want to weed out the false positives. The worst thing you could do was just give them a dynamic report over the wall and say, go fix it, and they come back and say, these weren't issues at all. That's how it used to be a long time ago. We would see that. You can't get away with that anymore, and that's not fair to your developers. So you have to have the right people and the right techniques to be able to get in and get out. And I'm really big on being able to get in and get out and plow through findings and get the results back to the developers in a reasonable timeframe without wasting anyone's time.

25:14Mark WillisHow do folks scale this idea? So this— so I get what you're talking about as far as you're going to— you need a certain skill set and whatnot to be able to truly use these tools and interpret the results. But how do you handle that when you have 10,000 developers that are part of this? Do you like the central model where you have security experts that are together or more of a distributed model, or how do we scale this thing?

25:44Chris RomeoYeah, again, it depends on the organization and If you can have a dedicated team that is, you know, when an application is going from, you know, getting ready to go to prod, but they're now there in the QA, and they've made the security testing team aware that this latest build is out there, and it's, you know, it's a build with actual code changes. If it's just a build with maybe a GUI change or something insignificant, you don't want to have to waste your time on that, perhaps.

26:18Mark WillisRight.

26:18Chris Romeothere are significant code changes and that dynamic review needs to take place, then you have a team in place already that is available to accept that incoming request and perform the necessary dynamic assessment and then get those results back to the developers again in a reasonable timeframe. This is different than DevOps for sure. It does take more time, but you definitely have to have that dedicated team in place to be able to handle that. Because when an application team says, okay, you know, we're done with our, you know, X amount of months release schedule, we're ready to go to QA, this is our latest build, you know, they don't want to have to sit around and wait for some team to get their act together to test it. They want to have a team there that can take that application and perform the necessary security testing, dynamic testing on that. and return those results again in a reasonable amount of time. I think that's very successful. How a company does that, you know, depends on, again, on the size. How many applications do you have? How many developers? How large of a security team do you need? You know, those are all things that have to be kind of hammered out, you know, long before you get to that point of, okay, we're application X, we're now going to dev or QA, it's time for us to be dynamically scanned. All those things have to be hammered out long before that. But once you hammer those out, and you get that built in as part of the accepted process, then you should be successful.

27:49Mark WillisSo what, from your perspective then, what's the right amount of time for a test like a dynamic analysis style test to last to still keep the developers moving at the right clip and not being upset because you're slowing them down?

28:05Chris RomeoYeah, that's a good question. So one thing you also want to keep in mind too with that timeframe is How long are the developers also doing other types of testing in the QA environment? For example, they might deploy to QA and there might be other types of testing going on besides security, right? So that might be, you know, it could be a 1-week, 2-week, 3-week window depending on— that's important to know too, you know, how long is our QA window? So, you know, if it's a short window, then you've got to hopefully get those results back, you know, sooner. If it's over a week, it depends. I would say normally you're probably talking around 10 days, maybe a week depending on accelerated timelines. Again, this is where security and developers have to work to manage those timelines together. If the dev team says, hey, we've only got a week, man, we've got to get this thing returned to us, then you crank it up and you have to get things done faster. If it's more Okay, we have a couple weeks and we're willing to give you guys 10 days to bring in the team and do a full-blown dynamic type of ethical hack, then cool, you can do that.

29:14Mark WillisOkay, so that raises another question for me then. So you just mentioned dynamic and ethical hack together. So do you think of those 2 as being complementary and working together? Or is there a separate phase in the SDLC or the secure SDLC, dynamic being one phase and then penetration testing being something that happens later?

29:40Chris RomeoYeah, so the ethical hack or pen test, in my opinion, would come after the dynamic assessment. So whatever the dynamic assessment does not pick up, you would want the ethical hack to come in kind of right at the end of that and try to find something or some issues that did not get picked up with the dynamic assessment. So that is something that may not always be able to happen due to timeframes, but for a high-risk app or for an app that's new or, you know, whatever the reasons are, hey, we definitely need, you know, the ethical hack on this after the dynamic assessment, then that would be a logical follow-up. So you would, you know, You'd want to have the ethical team look at the dynamic assessment and say, okay, fine, where there's smoke, there's fire. Maybe there's some other things going on in these areas, but we definitely don't want to waste our time reporting the same things that were picked up in the dynamic. We have to go deeper and use our tools and techniques to do that. So that's how I kind of see things playing out with that regard.

30:43Mark WillisSo how do you choose? So do you think the right model is a one-to-one? Meaning that there's an ethical hack that happens for every application release, or is there some type of threat modeling or some other type of integration that can come into that decision to decide that one can go ahead to production without being tested, but this one over here has got way too many security-relevant changes that are happening within?

31:13Chris RomeoYeah, good question. So that would be something that we would want to think about as far as the overall risk of the application, right? The overall risk. If it's something that has been ethically hacked recently, and this is just another build and a dynamic, you most likely, you cannot, you will not have the luxury of time to ethically hack every application that's dynamically assessed. So you have to pick and choose your targets carefully. There are a lot of factors that can roll into that. Is this a brand new application that has never seen the light of day? What kind of data does it handle? Is it PII, PHI, personal identifiable information, personal health information? Is it PCI? Is it restricted, confidential? Is it a significant application that If it were somehow, you know, if somehow there was a breach, you know, would it be significant? Those are all things that you need to take into consideration. And if you're— if this particular application is starting to, you know, you're checking off yes, yes, yes, you know, hey, this is the one that we need to consider ethically hacking for sure. It depends. You have limited time and resources. You have to pick and choose your targets carefully. a brand new app, an app with sensitive information, something that really needs the full-court press, and management, everyone's on board with it, you know, and you've been given the heads up to schedule this accordingly, then, you know, then that's all great. You know, so it really— there's a risk assessment that goes into it as to who's going to get ethically hacked or who isn't. You know, from my experience, based upon overall risk, anything that, you know, is in the high risk is going to get an ethical hack, you know, before rolling out to production, if at all possible. And that's just, you know, that's the world you live in, and that's what you aim to do.

33:33Mark WillisOkay, that makes sense. I have one last question, but Robert, I wanted to check and see, do you have any questions you want to ask for Mark?

33:43Chris RomeoWell, yeah, I do. In terms of switching from developer to a security person, in your own teams that you're working with, how do you find somebody who might be interested in doing the same kind of switch? Do you look for that in particular? Yeah, so it's always good to find developers who are interested in learning about security. There's always going to be some that are within a given application team who want to go a little further and learn more about security. And you can find that out from working with the teams, the ones that are, you know, the ones who want to perform the static analysis, the ones who want to learn more on their own, who come to us. and ask questions, you start to find out after a while which ones want to step up and perform those types of security testing, and those are the ones that you'd like to focus on. So I think developers in general, whether you're a security expert or not, every developer today in 2017 needs to understand that It's no longer an option to just write code and maybe it's secure, maybe it's not. It's in everybody's interest now as a developer to write secure code. And I think really just saying, well, there's somebody else on the team that can handle this and do this. I think everybody needs to understand for the most part that you are not only a developer, but you are also on the front lines, as I said before in the beginning of the show, writing the code that, you know, everything that we use is software-based, right? Everything we use in this world today has software in it. And depending on, you know, what mobile app or web app you're using, you know, you want to know that the folks that wrote that code did everything they could to make it as secure as possible. So you don't want to hang it necessarily on one person, but normally you will find that there is one person, you know, on an application team that wants to go a little bit above and beyond, and that's your primary security expert within the development community who can go back and share that security information with the rest of the developers. So in the Army, we called it train the trainer, and that's kind of how I see things, you know, progressing today.

36:19Mark WillisYeah, I think that makes, uh, I think that's, that's consistent with some of the things that I've seen as well. My final question for you, Mark, is what is one resource that you would point somebody to who's— we may have some people listening today and they're hearing static analysis, dynamic analysis, ethical hacking. These may be things that they want to learn more about. Anything you can think of that you would send them to if you could only say send them to one place for more information about these ideas?

36:51Chris RomeoYeah, I mean, I would recommend, you know, start at the OWASP site, right, at owasp.org. I mean, I think OWASP is a fantastic, you know, collaborative, you know, open source, as you know. I mean, it's fantastic for people to— you can spend, you know, hours and days going through all the material. with OWASP. I recommend to anybody who's interested in learning more about this and maybe making that transition to go and download the OWASP testing guide and go through it because that's going to give you some great Java and .NET examples, and it's going to get you into that mindset of, hey, is this really something that I want to do? It's going to walk you through a lot of the steps that you would be going through if you were doing a real application security assessment. Those same things that you see in that document are the same things that security testers will be doing. If you like what you read and if you think you can do it and you want to learn more about it, I think that's a great place to start. I'm a member of OWASP. I think it's a great place for people to go to. It's all free, it's collaborative, and again, that's the place I would recommend people go to if they've never really started to dip their toe into this field. I think that's a very safe place to go to, to learn more.

38:16Mark WillisYeah, cool. Thank you. Thanks for that suggestion there. With that, Mark, thank you very much for your time today. We really appreciate the discussion of static, dynamic ethical hacking. We really are happy that you were able to take the time today. Thank you so much for contributing.

38:36Chris RomeoThank you both for having me on the show. And I look forward to catching you sometime at a conference somewhere in the future.

38:44Mark WillisSounds good. Thank you so much.

38:45Chris RomeoThank you.

38:47Thanks for listening to the Application Security Podcast. Our intro music is 8-Bit Kung Fu by Born and Teaching, and the outro is Southern Delight by Stefan Cartenberg. You can find us on Twitter @appsecpodcast or on the web at www.appsecpodcast.com. Podcast.org.