Nathaniel Shere [00:00:06]:
We wrote a quick python script to do every single possible possibility. Started running it, went to lunch three, 4 hours later. We had every single password in the system, including system admins who had a backend, 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 with security team, said, guys, this one's actually a problem. It was so funny. 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.
Nathaniel Shere [00:00:34]:
So thank you, guys. We can finally get them to change it.
Chris Lindsey [00:00:37]:
And you bring up a good point, and you found an issue. Now you didn't wait for the two or three weeks later, hey, here's the reported findings and things. This was so critical. You're like, wait, stop the presses. We need to let you know this is a fine. And this is not just a fine, this is a critical fine. This is something that needs to be addressed ASAP.
Nathaniel Shere [00:00:58]:
Yeah, that's pretty standard practice. Certainly 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.
Chris Lindsey [00:01:16]:
Hello, and welcome to Secrets of Appsec Champions. My name is Chris Lindsey, and today we are speaking with Nathaniel "Nat" Shear. Today's conversation is going to be around penetration testing. Nathaniel is the technical services director at Craft Compliance. Nathaniel, please introduce yourself.
Nathaniel Shere [00:01:33]:
Thanks, Chris. Really excited to be here. Yes. 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.
Chris Lindsey [00:02:00]:
Awesome. So our conversation today is going to focus on penetration testing. We're going to talk about all aspects of penetration testing. So let's get started. Nat, how did you get started in pen testing? What was that initial aha moment for you that said, hey, pen testing is really kind of fun and enjoyable?
Nathaniel Shere [00:02:19]:
Yeah. So I first started, I got my masters 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. It was at the time, and I was again 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. Well, the team continued to grow to the point that, you know, my manager actually came to us and said, all right, 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. Nat, where do you want to be at this point? I'd been able to do a couple of different projects, and.
Nathaniel Shere [00:03:03]:
But it was a no brainer. Pen testing was the absolutely the best projects that I've worked on. They were the most fun, they were the most exciting. Definitely the reason that, you know, I came to work every day going, man, I hope I get another one of those kinds of projects. So it was an easy decision for me.
Chris Lindsey [00:03:19]:
That's awesome. It, for me, the aha moment was, I love breaking things, I love attacking things as a ethical hacker. And it's just really kind of exciting when you have a find, somebody comes out and they said, all right, we feel like this is really nice and secure and 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, really deep. And so it brings a lot of value into penetration testing. And so do you have any fun stories that you can share of some finds that were just like, wow, this is huge?
Nathaniel Shere [00:03:56]:
Oh, absolutely. So for the value of penetration testing, I usually look at it kind of 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. That's your two sides of the value there. Different times, you get value in different areas. One time, for example, in the first part, not even knowing what was available, I worked with a client where it was an external network penetration test. The entire environment was fantastic.
Nathaniel Shere [00:04:30]:
We were looking at probably potentially a report that was almost blank. We were really starting to get nervous as consultants. I mean, it's good for the client when that happens. But of course, as a consultant, we're thinking, well, 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, all right, 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, you know what, let me just try.
Nathaniel Shere [00:05:03]:
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 like that. So that gave us nearly a dozen user passwords and from there it was open season on everything that was externally available. So just that one little thing that they didn't even realize that was still active, that one little thing.
Nathaniel Shere [00:05:54]:
Suddenly it went from a blank penetration test report to criticals all across the board.
Chris Lindsey [00:05:59]:
I'll be honest with you, you're going to 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 SMTP server. We're now talking about the fact that, hey, we were able to get the credentials, now we're able to find people's credentials. We now figured out how the helpdesk system works. Now you could, as a hacker go, okay, look, 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 helpdesk ticket in, hey, I'm on vacation.
Chris Lindsey [00:06:46]:
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, look, my VPN is down, I'm having VPN issues, and now they're giving you the information to log in as a, you know, 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.
Nathaniel Shere [00:07:22]:
And that is why, from the value of 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, right? 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. And then number three, now we're snooping around your email service, doing searches for emails with the password or secrete or anything like 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.
Chris Lindsey [00:08:07]:
Your systems, right, so you bring up a good point, is 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 were able to do in the steps that we were 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 sim, or if you're running some kind of tool that's in the background, like 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.
Nathaniel Shere [00:08:52]:
Which now you mentioned it is one of the other good values of a penetration test. It's that thinking like a hacker perspective for a lot of development teams, they're in the development mindset of, well, this is how the user is going to use the system. Then a penetration tester comes in and says, sure, or we'll do it this other way. 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 it was 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, you know, so, all right, so we're using our proxy tools in burp suite and figuring out what's going on.
Nathaniel Shere [00:09:37]:
Well, it was a simple login, that's all it was. No username and 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 one through 20, no repeating three numbers.
Chris Lindsey [00:09:54]:
Right.
Nathaniel Shere [00:09:55]:
At that point we're thinking like hackers now say, well, 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, 4 hours later. We had every single password in the system, including system admins who had a backend, 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 with the security team, said, guys, this is when it's actually a problem. And it was so funny.
Nathaniel Shere [00:10:28]:
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. So thank you, guys. We can finally get them to change it.
Chris Lindsey [00:10:41]:
And you bring up a good point. And I, 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.
Nathaniel Shere [00:11:04]:
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 whether it's phone call, email, sometimes sky writing. We try to tell you smoke signals.
Chris Lindsey [00:11:26]:
In the wind blowing down. Yes, yes. So one of my favorite things with pen testing is related to, and again, authentication. And so many companies feel like we have the authentication figured out, were in good shape. And realistically, if you're not doing a multi factor authentication or some other thing like Yubikey, now, you're really kind of opening yourself up to bigger problems. And one of my favorite stories was I was at AWS reinvent 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 men? Yeah. And I explained who we were what we did. And he said, I don't need tools.
Chris Lindsey [00:12:02]:
I'm a great programmer. 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.
Nathaniel Shere [00:12:12]:
Not as explicit as that. I think sometimes it's kind of been the undertone of something said, but that's pretty out there, right?
Chris Lindsey [00:12:19]:
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 want to have some fun, that's a great way to get involved is through the community edition and so on. 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.
Chris Lindsey [00:12:55]:
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 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, look, we feel like we have something solid. Please go test it and see what you can find. And these are simple finds. This is not a advanced type 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.
Chris Lindsey [00:13:31]:
At 03:00 a.m. 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. Look, 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, out of penetration testing.
Nathaniel Shere [00:14:07]:
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, well, this developer made this mistake and this developer made that mistake, and it very often comes off as a, we're putting down the developers and everything. And that's rarely the case, I should say, because I've done little scripts, right, python little scripts help me to do some attacks, 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, very impressive. They understand development, they understand how to build the application, they understand how to make all of the different pieces work, but they're not always as aware of which, because we all have finite amount of time, we can only learn so many things. What they're not always aware of is those security issues, especially some of the common ones.
Nathaniel Shere [00:14:59]:
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 like how can it be abused? If somebody were to take advantage of some of the inherent trust things that, that you're assuming between your users and those sorts of things. Enumerating data is a very common one. The developer will put an id or something in the URL and not ever think about, oh well, what if the user comes in and changes that id to the next number or to the 100 numbers, or, you know, just sequence them, 123-4567 they don't think like that because they think what 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.
Nathaniel Shere [00:15:46]:
The user never sees 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, very visible so that you can test it kind of outside of those JavaScript controls and all that sort of stuff.
Chris Lindsey [00:16:07]:
Right. And 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 4000 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 want to bring up related to penetration testing is the fact that some of the tools like 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.
Chris Lindsey [00:17:01]:
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 real easy to find those. So 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 a mimicked production pseudo production environment? What kind of access levels and what kind of details should they give you for you to be successful in helping them?
Nathaniel Shere [00:17:32]:
So the environment is definitely a big question. I prefer first, 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 I will make a finding or I will miss a finding and huddle together afterwards with the client and say, well, why was this found or why wasn't it found? It turns out, oh well, the staging environment was different than the production environment. Say well, if it's different at all, then you might as well do production. 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, well then you might as well test both and then verify as much as you can that they are the same.
Nathaniel Shere [00:18:27]:
But generally yes, you want to test the production risk. 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, yeah, 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, lot more because so there's kind of the different boxes. You've probably heard of these concepts, right? White box versus black box versus gray box. That's kind of the level of access that you're given. So Blackbox is truly, I don't have credentials, I don't know the software. I'm essentially given a URL and told go.
Nathaniel Shere [00:19:06]:
Whereas whitebox, you're more as kind of an internal employee, you're given potentially source code application architecture, certainly credentials to the application. So you can log in as a user and all those sorts of things and go from there. Your testing methodology is going to be different. So if you have a 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, here's the list that saves some time. Then as a result, I think white box testing, which is the trend, I think moving in that direction for pen testing, it gives you a lot more focused, efficient testing because that black box, you're hitting your head against the wall trying to see what might be there. And with whitebox you can just go and so for example, with whitebox, 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 backend.
Nathaniel Shere [00:20:01]:
But like you said, 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 could just start SQL map or SQL injection tool and hope where 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 have this actually with a client at one point they did give me source code access and so I was able to find, I found SQL injection, I found definitely, I was getting the errors is 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.
Nathaniel Shere [00:20:46]:
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, like I said, right, 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.
Nathaniel Shere [00:21:27]:
I am not nearly technical enough on SQL query syntax to understand how to exploit this. So I'm putting medium risk in the report because yes, it's SQL injection, but good Lord, the complexity of trying to exploit this to do anything meaningful. Yes, I think would take insider knowledge and potentially a PhD in databases.
Chris Lindsey [00:21:52]:
No, I mean, and really 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 want to 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. So go sit in the corner and have a good summer.
Chris Lindsey [00:22:44]:
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? 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. So 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?
Nathaniel Shere [00:23:26]:
100%. Yeah, 100%. 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, I sure, again, developers are very smart technical people. Could they sit down for a day or two and figure it all out 100%? Do they have time for that? Not in the slightest. 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 one that can exfiltrate data, here's the ones that you can jump from one client to another client or something like that.
Nathaniel Shere [00:24:15]:
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, right. 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 out and then you come back to some of the lower risk items and those sorts of things. So yeah, 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 all those sorts of things that I support tickets, all those sorts of things before I work on some of those.
Chris Lindsey [00:24:52]:
So you're right, it absolutely helps you with prioritization and making sure, because if it's something critical that can be exploited with a unauthenticated like 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 now all of a sudden it really just takes certain aspects and certain things and you have to kind of really almost stack different things on each other to be able to get to the point of exploration.
Nathaniel Shere [00:25:23]:
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.
Chris Lindsey [00:25:39]:
Right. It's the value that pen testing brings. I mean, 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.
Chris Lindsey [00:26:12]:
You're not worried about the political environment, you're not worried about how 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, and 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.
Chris Lindsey [00:27:07]:
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 had a lot more time to review this. Here's something that was missed. And really it's a iron sharpens iron approach.
Nathaniel Shere [00:27:24]:
For sure, for sure. And I think again, it's kind of an industry standard, but at least I think it is, at least the way I've always done it is that when we finish the pen test, we issue what we call a draft report. Then sometimes we have to work with certain clients. We say, well, this is a draft. Let us know if you have any questions, any clarifications that need. And they come back with, well, this invulnerability, that's a false positive. You can just take those out 1 second, that's not how it works. So it might come back with, oh, see, we found SQL injection.
Nathaniel Shere [00:27:52]:
It's a high risk. We put in the report as a high risk. They come back and the client comes back and says, hey, we appreciate you finding this, but as it stands, you would have to be an admin in order to even get to this particular endpoint, we only have three admins and they're all our it managers. All of the accounts have MFA, and that database actually doesn't even have all that much interesting data anyway. It's all public information, for example. So we might come in and say, okay, right. It's at a raw vulnerability perspective. It is a high risk.
Nathaniel Shere [00:28:21]:
There are mitigating controls in place. So for the report perspective, it comes down to a medium or even a low, potentially, usually not physical injection, down to a low. But that's the point, right? That's iron sharpens iron. Like that sort of feedback that we're able to work with the client in order to understand, okay, this is your true risk in your environment, not, this is the industry standard CVSS score. Now, you know, good luck. Go figure out your prioritization. We want to have those conversations to actually get to the true prioritizations of what needs fixed.
Chris Lindsey [00:28:53]:
Yeah. Is that also where you go, hey, by the way, your SMTP server was exposed, I already have all your username and passwords. Here you go. I was able to get in there. So let me ask you this. What is the best advice that somebody has ever given you?
Nathaniel Shere [00:29:05]:
So honestly, the best advice I ever got was after a client install was going horribly wrong. So this was just before a holiday break. This was 04:00. I was trying to get out to catch the bus on a Friday. I needed to get out by 504:00. I'm doing this huge install of security controls and security software. The one that I was currently on was a process whitelisting tool, which is a great thing for catching malware, those sorts of things. If you have a fairly standard non changing environment you can put that sort of tool on.
Nathaniel Shere [00:29:38]:
Any new process would get stopped and potentially alerted and those sorts of things. What I was told by our development team was that the tool was in the 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.
Nathaniel Shere [00:30:18]:
I was trying to email, I was trying to get a hold of our development team, I was trying to get a hold of the client, and 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 flown around you, 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, right. 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.
Nathaniel Shere [00:30:56]:
I need to stay ahead of attackers. I need to fix everything right away, otherwise somebody's going to hack it. And sometimes you need to just take it to step back and go relax. You'll do what you can. There's only 24 hours in the day. You also need to sleep and eat. You also need to see your family.
Chris Lindsey [00:31:13]:
Yes.
Nathaniel Shere [00:31:14]:
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 it does. You do need a break.
Chris Lindsey [00:31:25]:
Absolutely. Absolutely. And on the other side, what's the worst advice you were given?
Nathaniel Shere [00:31:30]:
I don't think I've ever just been given horrible, horrible advice. What I'm thinking of for this is less something specific that was set 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've exploded on certifications where if you don't have ten certifications by the time you turn 30, you're considered a wash, which seems very, very silly. I've actually had 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.
Nathaniel Shere [00:32:14]:
Go get your bachelor's, go get your master's, if that's what you're going for. Right. You don't need to worry about certifications. You're studying the material. This is what you should be doing.
Chris Lindsey [00:32:24]:
Right, exactly. For me, 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 take it. And now they're telling people, look, you were in college four years. That qualifies. You just need one year. And the experience, you get, it just watered it down.
Chris Lindsey [00:32:50]:
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 be normally in your lane, may be like 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 the stuff. And as a developer, certification, and I have multiple there. And it was funny because I was taking one of my Microsoft certified professional ones and I was studying, and I'm like, why do I keep missing this? And the funny part was, is 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 like, what? I would never do that.
Chris Lindsey [00:33:39]:
But on the flip side, it was there and it helped me grow. So anyway, with that, 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. Any last words?
Nathaniel Shere [00:33:53]:
No. Thanks so much, Chris.
Chris Lindsey [00:33:54]:
Alrighty. Thank you so much. And for everybody watching, you have a good rest of the day. Thank you. Thank you so much for joining me on this episode of Secrets of Appsec Champions. If you found this valuable, hit that subscribe button on Apple Podcasts, Spotify, or wherever you get your podcast, ask. And hey, ratings and reviews are like gold force. So if you're feeling generous, please leave a kind word.
Chris Lindsey [00:34:19]:
It helps others discover our show. Until next time, take care.
