Stress, Certification, and Pen Testing

Intro:

We wrote a quick Python script to do every single possible possibility, started running it, went to lunch. Three, four hours later, we had every single password in the system, including system admins who had a backend SQL access and all the different users. We got on the phone because it was an externally available web portal. We got on the phone and security teams said, guys, this is when it’s actually a problem. They said, oh my goodness, We’ve been fighting with development over this web app portal for so long, but we didn’t know how it could be broken. Thank you guys. We can finally get them to change it.

You found an issue. Now you didn’t wait for the two or three weeks later. Hey. Here’s the report of findings and things.

This was so critical. You’re like, wait. Stop the presses. We need to let you know this is a find, and this is not just a find. This is a critical find. This is something that needs to be addressed ASAP.

Yeah. That’s pretty standard practice. Certainly, if I do that, but I’ve not heard of anybody else not doing that if it’s a truly critical issue. It’s definitely from a penetration testing perspective. If there is a critical find, the industry lets you know as soon as possible.

Conversation:

Hello, and welcome to Secrets of AppSec Champions. My name is Chris Lindsey, and today we’re talking with Nathaniel Shere. Today’s conversation is going to be around penetration testing. Nathaniel is the Technical Services Director at Craft Compliance. Nathaniel, please introduce yourself.

Thanks, Chris. Really excited to be here. I’ve been working in penetration testing for a little over ten years. I’ve worked both as a consultant doing the penetration tests for various clients, but I’ve also worked directly with developers as a security engineer, which has given me a really interesting perspective from both sides of the penetration testing process, both doing it and writing the reports, but then also being on the other side and getting the reports and now having to do something with them. So really excited to talk about it.

Our conversation today is going to focus on penetration testing. We’re going to talk about all aspects of penetration testing. Let’s get started. Nat, how did you get started in pen testing? What was that initial moment for you that said, hey, pen testing is really kind of fun and enjoyable.

I got my master’s in cybersecurity. That gave me kind of a broad, knowledge of the entire field.

And then I started out as a consultant with Rook Security. At the time, I was just a general consultant doing all different kinds of projects, whether that was security tool implementation.

There was some policy writing, all kinds of stuff and penetration testing as well. The team continued to grow to the point that my manager came to us and said, alright, let’s specialize you guys a little bit more. Instead of having you all focus on every project, we’re going to let you guys focus a little bit on specific projects and get better and better on those specific skills. Now where do you want to be?

And at this point, I’d been able to do a couple of different projects and it was a no brainer. Pen testing was absolutely the best projects that I’ve worked on. They were the most fun. They were the most exciting.

Definitely the reason that I came to work every day going, man, I hope I get another one of those kinds of projects. It was an easy decision for me.

The Thrill of Ethical Hacking

It for me, the moment was I love breaking things. I love attacking things as an ethical hacker, and it really is just kind of exciting when you have a find. You know, somebody comes out and they said, alright, we feel this is really nice and secure, have at it. And when you have that chance to go see what you can find, it’s really interesting, the things that you can find, in the different categories, is really deep. And so it brings a lot of value into penetration testing. Do you have any fun stories that you can share of some fines that were just like, wow, this is huge?

Oh, absolutely. So for the value of penetration testing, I usually look at it from the two sides. The one side is detecting and identifying where we’re vulnerable, and the other side is responding from it. So maybe we know our environment, we’re pretty good, but we’re not very good at identifying an attack and responding to it. So that’s your two sides of the value there. And different times, you get value in the different areas. So one time, for example, in the first part of not even knowing what was available, I worked with a client where it was an external network penetration test. The entire environment was fantastic. We were looking at potentially a report that was almost blank, and we were really starting to get nervous as consultants. There’s a I mean, it’s good for the client when that happens, but of course, as a consultant, we’re thinking, well, where what value are we bringing in here?

But towards the end of the project, we actually found they had their SMTP email service open externally. So that would be a finding in and of itself. That’s probably not, it’s an administrative portal, it’s probably not the best thing to have open externally. But on a whim, I looked up, I said, let me just try it, standard practice anyway, but none of us expected it to work. Let me try to find the default credentials for this particular email service. Took me about 15 minutes of research, found them. We went and tried them. Turned out that they worked. And not only was this the email service for the company, all of the emails funneled into this particular service from anybody within the company. So we were able to review all of the different emails and from there, basically pivot into, oh, so your users are submitting help desk tickets whenever they go on vacation with their username and password so that I think IT can do some scrubbing, can do some maintenance on the machine or something that. That gave us nearly a dozen user passwords, and from there it was open season on everything that was externally available.

I’ll be honest with you, you’re gonna find so many of those. And think about how much time did it take you? It didn’t take you all that much. You had this within less than a day. And when you start looking at what seems to be a small issue, a small find, hey, it’s just an SMTP server, what could go wrong? Right? Now what we’re talking about is we’re not just talking about a small FTP or SMTP server. We’re now talking about the fact that, hey, we are able to get the credentials. Now we’re able to find people’s credentials. We now figured out how the help desk system works. So now you could, as a hacker, go, okay, we know that somebody’s on vacation, and they’re having trouble. And it’s credentials that you want access to, but you don’t have. So you just put a help desk ticket in. Hey, I’m on vacation, I’m having connectivity issues. Could you please change my password? I have it on my password manager back home. Please change it and send me a link to the email here or please change it to this temporarily, I promise I’ll change it when I get in. And all of a sudden now you’re gaining access to things. Or you could say, hey, my VPN is down. I’m having VPN issues. And now they’re giving you the information to log in as a VPN user, to you, not the right person. And you start thinking about how this can snowball into something very serious. And this is just part of a day.

And that is why from the value of the pen test, I think it’s very important also to look at your detection and your monitoring. So that entire scenario, we were able to work with the client and say, okay, here’s the dozen or so steps that you probably should have caught, either from alerting or from a monitoring perspective. This default account, nobody should be logging in with this account. That’s an alert right there. Number two, it’s coming from an external source that’s never logged into your email service. Then number three, now we’re snooping around your email service doing searches for emails with a password or secret or anything that. Again, what IT user, who in your internal users is doing those types of searches? So another opportunity to detect a potentially malicious insider now that we were in your systems.

You know, you bring up a good point, as an ethical pen tester, as an ethical company helping other companies understand where they’re vulnerable, not only were you able to provide them, hey, this is what we’re able to do and the steps that we are able to do it, but you also provided some experience. Hey, here are multiple steps that you should have caught along the path. So if you’re running a SIEM or if you’re running some kind of tool that’s in the background, a Splunk that’s running, here are some things that you should be considering as far as your security profile goes to make sure that if this happens, this should be a never event. You should never be able to log in as this account. And if you do, somebody should be notified.

Understanding Vulnerabilities

Which now you mentioned is one of the other good values of a penetration test. It’s that thinking a hacker perspective. For a lot of development teams, they’re in their development mindset of, this is how the user is going to use the system. And then a penetration tester comes in and says, sure, or we’ll do it this other way. I had one of my clients, they had this external web app, with the most unique login experience that I’ve ever seen. We initially pulled it up, and it was just a grid of, I think, four by five images. We couldn’t even figure it out at first. But finally, after some experimentation, we figured out if you click on three images, you get a little login failed at the top. Well, using our proxy tools in Burp Suite and figuring out what’s going on, it was a simple login, that’s all it was. No username and password, the password essentially was your three images. But they weren’t even making it complicated and sending the images as your password. In JavaScript, it was translating the images to numbers. So it’s simple one through 20, no repeating, three numbers. At that point again, we’re thinking hackers now. So that’s super easy. There’s very few opportunities, very few options here for your potential password. Within 30 minutes, we wrote a quick Python script to do every single possible possibility, started running it, went to lunch. Three, four hours later, we had every single password in the system, including system admins who had back end SQL access and all the different users. And we got on the phone because it was an externally available web portal. So we got on the phone, security teams said, this one’s actually a problem. And they said it was so funny. They said, we’ve been fighting with development over this web app portal for so long, but we didn’t know how it could be broken. So thank you, guys, we can finally get them to change it.

Well, you bring up a good point. You found an issue. Now you didn’t wait for the two or three weeks later. Hey, here’s the report of findings and things. This was so critical. You’re, wait, stop the presses, we need to let you know this is a find, and this is not just a find, this is a critical find. This is something that needs to be addressed ASAP.

Yeah, that’s pretty standard practice. Certainly, if I do that, but I’ve not heard of anybody else not doing that if it’s a truly critical issue. It is definitely from a penetration testing perspective, if there is a critical find, the industry lets you know as soon as possible. Phone call, email, sometimes skywriting, we try to tell you. Smoke signals in the wind, blowing down. Yes. So one of my favorite things with pen testing is related to, again, authentication. And so many companies feel, we have the authentication figured out, we’re in good shape. And realistically, if you’re not doing a multifactor authentication or some other thing a YubiKey, now you’re really kind of opening yourself up to bigger problems.

And one of my favorite stories was I was at AWS re:Invent, and I had this guy come up to me and he was we were just chatting about security. And he goes, you know, who’s Imen? Yeah. And I explained who we were, what we did, and he said, I don’t need tools. I’m a great programmer. I have you heard that before? I’m a great programmer, I don’t need security tools. I don’t need security, I’m good. My clean code is good enough. Not as explicit as that. I think sometimes it’s been the undertone of something said, but that’s pretty out there. Right. So he came over and I said, let me show you my laptop. I had Burp Suite. Burp Suite, for those who are listening, is a penetration testing tool, and it does a fabulous job. There’s lots of plugins and things that you can do. So if you wanna have some fun, that’s a great way to get involved is through the community edition and so on. So I created two accounts on his system, and then I proceeded to steal data from one account to the other. Looking at the data, I was able to look at the request and response, and I knew based off the request and response how he was doing things under the covers. And just the look on his face when I stole data from one account to another that I created and then my comment to him describing the fact that I can now enumerate all his data because of how he did it, he was just in shock. And these are some of the just the beginning things that you can think about, from a security standpoint that penetration testing does for you. The value that you get out of this is the ability to say, we feel we have something solid, please go test it and see what you can find. And these are simple finds. This is not an advanced level find that I had. This is really almost a beginner level, an entry level. And so when you come and tell me that you would write clean code, that’s great. I’m glad you can read it at three AM if you have to wake up in the middle of the night and make changes or fix something. But the reality is if you’re not writing secure code, and that’s where, again, the multifactor authentication really pays dividends, is because now not only can I break in, well, I can’t because I may have the right stuff? And you learn from working with your penetration tester. A 24 expiration on a JWT token is not wise. Consider something a little bit smarter and rotating keys and things of that nature. So there’s so much value that comes out of penetration testing.

Developer Awareness and Security

On that note, it is a common problem in the industry that we talk about all these sorts of issues. We tell these stories about, this developer made this mistake and this developer made that mistake, and it very often comes off as we’re putting down the developers. And that’s never, well, it’s rarely the case, I should say, because I’ve done little scripts. Python little script helped me to do some different exploits and different attacks. I’m not a developer in the slightest. I can read source code. I could not write a large program. I’ve worked with the developers, they’re far beyond me. A lot of their technical skills are just very impressive. They understand development. They understand how to build the application. They understand how to make all of the different pieces work. What they’re not always as aware of, which because they don’t have because we all have a finite amount of time, we can only learn so many things. What they’re not aware of is those security issues, especially some of the common ones. Either they’re relying on the framework, they’re relying on other security tools, they think it’s taken care of, they don’t have to worry about it. And again, they’re in that kind of mindset of this is how the user uses it. They’re not thinking, how can it be abused if somebody were to take advantage of some of the kind of inherent trust things that you’re assuming, between your users and those sorts of things. The enumerating data is a very common one. The put, a developer will put an ID or something in the URL and not ever think about, oh, what if the user comes in and changes that ID to the next number or to the 100 numbers or just sequence them. One, two, three, four, five, six, seven. They don’t think that because they think, well, you click on the link. I gave you the link. You click the link, and that’s it. That’s all you’re doing. The number is in the link. I know I have talked to a number of developers who say, we handle that in JavaScript under the hood. You the user never sees it. Is it true, but it’s in the user’s browser. So if the user wanted to see it, they could. And that is where, as you mentioned, Burp Suite, that’s a fantastic tool, mostly for web applications, but it does come in and makes all of that stuff very visible, so that you can test it kind of outside of those JavaScript controls and all that sort of stuff. So right. Right.

You know, another favorite thing I enjoy doing with penetration testing is going in there and if you have a field that takes 15 characters, let’s say it’s a phone number, it’s a first name that’s 20 characters, and you just go blast it with 4,000 characters. It’s always fun to see how forward thinking is your development team? Are they putting the correct error handling in place? And if you do error handling in place, what are you returning back to the user? Because sometimes you return back stack traces without realizing it which then gives the penetration tester, hey guess what? They’re using this library. They’re doing these things and they have so much visibility. One additional thing that I think is really that I wanna bring up related to penetration testing is the fact that some of the tools Burp Suite have plugins that show you what libraries you’re actually utilizing for your web. And not only what libraries, but it also gives you the details that you need behind it to go attack it. And so it’s important to have, stay current on your dependencies. If you’re staying current on the dependencies, that helps negate any of those fines and so it’s just really easy to find those.

Optimal Environments for Penetration Testing

Let’s pivot a little bit and let’s talk about what kind of things make it easier for you to do your job, when penetration testing. For example, what kind of environment should they set up? Should you go against their production? Should you go against the mimicked production pseudo production environment? Should they give you, what kind of access levels and what kind of details should they give you for you to be successful in helping them?

So the environment is definitely a big question. I prefer personally staging environments, test environments because it makes me a lot less concerned about causing any data problems. I can run tools and scanners at max speed without worrying about taking the whole environment down, those sorts of things. Now that being said, the environment does have to match production. I have definitely had a couple of cases where either I will make a finding or I will miss a finding and we’ll huddle together afterwards with the client and say, why was this found or why wasn’t it found? It turns out, oh, the staging environment was different than the production environment. So if it’s different at all, then you might as well do production because that’s where the real risk is going to be. I caveat that slightly that if your staging environment is open externally to the Internet, which I have also seen a few times, then you might as well test both and then verify as much as you can that they are the same. But generally, yes, the you wanna test the production risk. And if you’re so if you’re able to have an environment that exactly mimics production that you can test without affecting production, that is ideal. But otherwise, I would recommend testing production.

In terms of access, fortunately, I think the trend here is moving in the right direction where companies are starting to trust pen testers a lot more. There are the different boxes. You’ve probably heard of these concepts, white box versus black box versus gray box. That’s the level of access that you’re given. So black box is truly, I don’t have credentials, I don’t know the software, I’m essentially given a URL and told go. Whereas white box, you’re more as an internal employee. You’re given potentially source code, application architecture, certainly credentials to the applications. You can log in as a user and all those sorts of things, and go from there. And your testing methodology is going to be different. So if you have white box access, of course, then you are able to skip a lot of those enumeration attacks. I don’t need to enumerate the different libraries that you have if I can just go check the source code and see, oh, it lists. Right? So that saves some time. And then, as a result, I think white box testing is the trend. I think we’re moving in that direction for pen testing. It gives you a lot more focused efficient testing.

For example, with white box, if I trigger a potential SQL injection by triggering a SQL error, or if I think I’m seeing the patterns of this might be triggering something in the back end, but it’s not returning that stack trace. It’s not returning enough information to me in the browser to really determine what’s going on. Well, I can just start SQL map or SQL injection tool and hope, or I can do my manual testing and hope. Or if I have that source code access, I can go to the source code, find the relevant section, and just look at the code. I had this actually with a client one point. They did give me source code access, and so I was able to find SQL injection. I found, there’s definitely I was getting the errors. It’s definitely vulnerable. I was doing the different, putting in a single quote and it triggers an error. I put in two single quotes, the error goes away. All the classic signs of SQL injection, but nothing I did worked. I could not exfiltrate any data. I couldn’t insert any commands. Nothing was working. So I was able to go to the source code and find the SQL query that was affected. As it turned out, it was a, I think, nearly 300 line SQL query with the user inputs being inputted in several different places to the point that, and I’m I said, developers, very technical. There are areas where I’m not as technical as them. I was looking at this and going, I would have to be a DBA to understand what in the world is going on here. I was completely lost in the query. Looking even at the query sections that I was injecting, it was an absolute mess. I finally called them up and said, hey, there’s SQL injection here, but I will be fully transparent with you. I am not nearly technical enough on SQL query syntax to understand how to explain this. I’m putting medium risk in the report because, yes, it’s SQL injection, but the complexity of trying to exploit this to do anything meaningful, I think, would take insider knowledge and potentially a PhD in databases.

What you’re bringing up is a good point too. And that is as a pen tester, in creating the reports, you know their environment, you know where things are running. If you have command injection at a command prompt or terminal execution where you have to be at the terminal, it doesn’t mean anything because you’re already compromised. You’re already on the box. You’re already doing something at that point. So that’s part of how it should run versus if it’s web based, then that’s absolutely a lot more critical and more serious of a problem. And you bring up a lot of great information talking about the black box, the gray box, the white box, methodologies around penetration testing. I wanna share a fun story that I did over the summer for interns. So I had interns, when I ran my program, and they would come in. And instead of giving them, hey, go do the reports, go sit in the corner and have a good summer. What I did is I ran my SAS tool, and I created a report. And so we took it and we asked the question, can I do something with the source code? You know, looking at source code, is there something that I can do? Then the next thing was, let’s go pen test it. Can I actually go actually exploit this? Again, this is a lot of the benefits that penetration testing gives, and it’s very helpful.

Effective Communication of Findings to Developers

Let’s talk about sharing the findings with developers. You kind of started alluding to sharing this. One of the benefits of penetration testing is, when you send something over to a developer, should you record the actual attack so that they could look at it, know exactly what you did, and try to reproduce it themselves to fix it?

Hundred percent. I think, having worked with developers for a few years, one of their biggest struggles is getting just sent a vulnerability scan report, hundreds of pages, a lot of technical security details and syntax that they’re not necessarily familiar with offhand. And sure, developers are very smart technical people. Could they sit down for a day or two and figure it all out? One hundred percent. Do they have time? Do they have time for that? Not in the slightest. Right? And developer managers, even less so. So as a pen test, what you’re able to do is take that huge list of just raw vulnerabilities and say, okay, here’s the priorities. Here are the ones that actually get access to something. Here’s the ones that can exfiltrate data. Here’s the ones that you can jump from one client to another client or something that. And then here are the other ones that, yeah, if you have time, this will mitigate some risk as well. But we understand if you prioritize those a little bit lower. Maybe you fix these things, you work on those features that your biggest client wanted, or they were pulling out of their contract, and then you come back to some of the lower risk items and those sorts of things. So developers, developer managers, they want to know this is a huge priority. This needs to get worked on even before all of these features and my own bug reports and support tickets, all those sorts of things, before I work on some of those. So you’re right. It absolutely helps you with prioritization and making sure because if it’s something critical that can be exploited with an unauthenticated, at the login page, absolutely critical. You need to do something about it. And as you go deeper in the application and if you require authentication and you do have role based access implemented properly in your application, then all of a sudden, it really just takes certain aspects and certain things, and you have to really almost stack different things on each other to be able to get to the point of exploration. So I’ve had numerous clients where I’ve done the same pen test year after year. And very often, 70, 80% of the findings are repeats year to year. But I don’t think I’ve ever had a client where I called them up and said, hey, this is a critical issue that needs to get fixed, that it wasn’t fixed by the end of the project.

The Importance of External Penetration Testing

It’s the value that pen testing brings. Because really, it’s about securing your application, making sure data is not stolen or able to be taken, to be able to protect your inside your network, your east, west, north, south, all of that. The value is massive. So another question, I’m a strong believer that everybody should always have an external pen test no matter what. And the reason why is because when you’re coming in, you have no skin in the game. Your job is truly to come in and see what you can find and what you can do. You’re not worried about the political environment. You’re not worried about the developer relationship with the project management, with the executives, the board of directors. You’re not worried about that. You’re really worried about, can I find something? And here it is. One thing you should probably consider, larger companies absolutely should probably have somebody on staff that is a pen tester because you have so many applications that are going on internally. You have different things and really you’re going to be able to know, hey, this is an external web, this is external facing, this should be looked at versus something that’s internal. So you as a pen tester can prioritize your own internals. But the other thing too is as a pen tester internal, you’re limited to the scope of what you guys have within your environment. Whereas an external pen tester is exposed to so many different applications, and they’re always staying current. And having that external resource come in will help the internal pen tester, hey, internal guy, you missed x, y, and z. Here’s how I exploited it. Here’s what I have. Or vice versa as an internal, hey, I had access to the source code. I have had a lot more time to review this. Here’s something that was missed. And really, it’s an iron sharpens iron approach.

For sure. It’s industry standard, at least the way I’ve always done it, to issue a draft report when we finish a penetration test. We have to work with certain clients, say, “This is a draft. Let us know if you have any questions, any clarifications.” And they come back with, “This is a false positive. You can just take those out.” I’m like, “One sec. That’s not how it works.”

What we want to do is, it might come back with, “We found SQL injection. It’s a high risk.” We put it in the report as a high risk. They come back and the client says, “We appreciate you finding this, but you would have to be an admin to even get to this endpoint. We only have three admins, and they’re all our IT managers. All of the accounts have MFA, and that database doesn’t even have that much interesting data. It’s all public information.”

So we might come in and say, “Okay. From a raw vulnerability perspective, it is a high risk. But there are mitigating controls in place. So for the report, it comes down to a medium or even a low risk, potentially.” Usually not SQL injection down to a low, but that’s the point. That’s the sort of “iron sharpens iron” feedback. We’re able to work with the client to understand their true risk, not just, “This is the industry standard CVSS score. Good luck with prioritization.” We want to have those conversations to get to the true prioritization. So what needs to be fixed?

Yeah. Is that also where you go, hey, by the way, your SMTP server was exposed, so I already have all your usernames and passwords. Here you go. I was able to get in there. Let me ask you this, “What is the best advice that somebody has ever given you?”

Lessons from a Critical Security Incident

Honestly, the best advice I ever got was after a client install was going horribly wrong. Just before a holiday break, four o’clock on a Friday, I was trying to get out to catch the bus. I needed to get out by five. Four o’clock, I’m doing this huge install of security controls and security software. The one I was currently on was a process whitelisting tool, which is great for catching malware. If you have a fairly standard, non-changing environment, you can put that sort of tool on. Any new process would get stopped and potentially alerted. What I was told by our development team was that the tool was in watch mode. It should just collect the information of what processes are running.

Unfortunately, that was not right. It was actually in block mode, but the database was empty. So as I installed it on all of our clients’ critical servers, it shut down every single process, and I was getting blue screened left and right. It was an hour before I wanted to go home for a holiday weekend, and I was absolutely panicking. I was trying to email, trying to get ahold of our development team, trying to get ahold of the client. My manager came around, could see that I was just completely white faced and panicking, and he said, “Buddy, relax. It’s just a job.”

Which to me, that was the best advice I’d ever gotten. Because in security, there’s so much you have to learn. There’s so much advice that’s constantly being thrown around, whether certifications, whether it’s this one, that one, go for this job, go for this field, all this sort of stuff. There’s a lot of stress, because it’s your client’s data, there’s this constant feeling of I need to stay up to date on every single piece of information. I need to stay ahead of attackers. I need to fix everything right away, otherwise somebody’s gonna hack it. And sometimes when you just take a step back and go relax, you’ll do what you can. There’s only 24 hours in a day. You also need to sleep and eat. You also need to see your family. And at the end of the day, it is just a job. So as much as we love security, as much as we love securing, and learning and hacking and all those sorts of things, sometimes you do need a break.

The Value and Pitfalls of Certifications

Absolutely. And what’s the worst advice you’ve been given?

I don’t think I’ve ever been given horrible, horrible advice. What I’m thinking of for this is less something specific that was said and more of the culture, I think, around certifications. I think certifications are a wonderful thing in their time and place. But as an industry, I think we’ve almost gone, we exploded on certifications where if you don’t have ten certifications by the time you turn thirty, you’re considered a wash, which seems very silly. I’ve actually had a number of students reach out to me on LinkedIn saying, “What certification should I be going for right now?” And I said, “You’re in school. You’re literally studying this stuff anyway. Go do well in your classes. Go get your bachelor’s. Go get your master’s if that’s what you’re going for. You don’t need to worry about certifications. You’re studying the material. This is what you should be doing.”

Exactly. I am in full agreement. Certifications are blown out of proportion, and especially, unfortunately, I hate to say the CISSP, because in the old days, you had to be on the job for five years before you could even sit to take it. And now they’re telling people, you were in college four years, that qualifies. You just need one year. And the experience you get, it just watered it down. But the thing that I like about certifications, my biggest takeaway that I love is the fact that a certification will expose you to different aspects of security that you may not normally be in. Your lane may be, a CISSP. It gives you visibility into a lot of things that you’ll never probably need to know or be in again. But to your point, when you’re in college, that’s what you’re already doing. You’re being exposed to all that stuff.

And as a developer certification, I have multiple. It was funny because I was taking one of my Microsoft certified professional ones, and I was studying and I’m, why do I keep missing this? And the funny part was, I was doing the same thing, but I learned how to do it the advanced way and not the entry level way. And the certification was just looking for the entry level way, and I’m, what? I would never do that. But on the flip side, it was there, and it helped me grow. This has been an amazing conversation. I appreciate the time that you were able to take away and talk to me about this, and I appreciate it.

Thanks so much, Chris.

Alright. Thank you so much. And for everybody watching, you have a good rest of the day. Thank you so much for joining us today on Secrets of AppSec Champions. If you found today’s information valuable, hit that subscribe button on your Apple podcast, your Spotify, or wherever you’re listening today’s episode. Ratings and reviews are like gold for us. So if you’re feeling generous, please leave us a kind word as it helps others find our show. Until next time, take care.