From network engineer to pentester: Tips for moving into cybersecurity

[00:00] Chris Sienko: It’s celebration here in the studio, because the Cyber Work with Infosec podcast is a winner. Thanks to the Cybersecurity Excellence Awards for awarding us a Best Cybersecurity Podcast Gold Medal in our category. We’re celebrating, but we’re giving all of you the gift. We’re once again giving away a free month of our Infosec Skills platform, which features targeted learning modules, cloud-hosted cyber ranges, hands-on projects, certification practice exams and skills assessments.

To take advantage of this special offer for Cyber Work listeners, head over to infosecinstitute.com/skills or click the link in the description below. Sign up for an individual subscription as you normally would. Then in the coupon box, type the word cyberwork, c-y-b-e-r-w-o-r-k, no spaces, no capital letters, and just like magic, you can claim your free month. Thank you once again for listening to and watching our podcast. We appreciate each and every one of you coming back each week.

Enough of that, let's begin the episode.

[01:03] CS: Welcome to this week’s episode of the Cyber Work With Infosec podcast. Each week, I sit down with a different industry thought leader and discuss the latest cybersecurity trends, how those trends are affecting the work of infosec professionals while offering tips for those trying to break in or move up the ladder in the cybersecurity industry.

A big part of the Cyber Work agenda as you know is to help people get into an progress upward in cybersecurity as I just said. Some of our guests were born with pen testing and cybersecurity skills in their blood, but other came to it from other directions. Today’s guest, Brad Pierce, started his career in network engineering. So it’s maybe not the most surprising to go from creating networks to protecting them, but it’s worth noting again and again that cybersecurity is something that anyone with passion and analytical mind can pick up. So we’re going to talk with our guest toady about his journey into cybersecurity and some of the things he learned in transitioning out from network engineering and into his new career direction.

With 15 years of experience in IT and cybersecurity, Brad Pierce, director of network security for HORNE Cyber, focuses on collaborating with executive leadership teams to strengthen their security posture. He was experienced in working with organizations in various industries to uncover and remediate vulnerabilities and develop and implement security programs.

Brad manages HORNE Cyber’s cybersecurity operations center where he along with a team of cyber analysts, monitor live threat network traffic for clients in search of active threats. Brad creates information security awareness programs and guides clients on how best to address cyber risks and remediate vulnerabilities.

Brad, thank you for joining us today.

[02:36] Brad Pierce: Absolutely. Thanks for having me.

[02:38] CS: So we like to start each episode by getting a sense of your background and your personal story. So let’s begin with how did you get first interested in computers and tech. Is that something that was always with you?

[02:49] BP: Yeah. I was kind of one of those kids that – Yeah, I grew up in the 80s. So I was a kid that set everybody’s VCR clocks when all the kind of digital stuff was hitting the scene. And my grandfather dealt a lot with electronics and CD radios. So I was around that a good bit and he introduced me to one of the early 80s, mid-80s desktop computer that I loaded up MS-DOS and GW basic and did various things and played games and stuff like that. So that’s kind of where I first started playing around with computers.

And then fast-forward 15 years, I spent some time in the Marine Corps and one of my last duty stations, I got tasked with doing some pretty heavy lifting with regard to network infrastructure. And so I’ve been around software and application and things like that. But I really cut my teeth in the Marine Corps and I got to swap-out some switches and get into command line configuration type tools and things like that, and that’s really when I started taking an interest in networking and how networks work and things like that.

[04:07] CS: When would that have been roughly, like year-wise?

[04:10] BP: That would have been ’97, ’96, ’97 timeframe.

[04:14] CS: Okay.

[04:16] BP: Late 90s is when I first got exposed to what I would consider enterprise class networking if you will.

[04:24] CS: Okay. So as I mentioned at the top of the show, a big focus of our show is to talk about different aspects of the industry, but also the way they got to where they are. And one of the things that we’re always interested in is and why I was so excited to speak with you today is to talk to people who got either into security from something related or have moved out a big. In some cases, we have people who are cybersecurity people that moved into cyber law and things like that.

Today, especially obviously, being a director of network security at HORNE Cyber, that’s a pretty big jump here. I wanted to sort of talk about like how did you – What was the sort of mechanism that moved you away from network engineering into network security? What got you interested in making the switch?

[05:10] BP: Yeah. Well, I’ll talk about in the segment. I had a unique opportunity arise. But in my role, I was actually the network engineer for a couple places, and then I landed in HORNE LLP, the accounting firm. And so I was their network engineer for about 10 years there. And I started off on the help desk and special projects and kind of just moved my way through the ranks there to where I was managing the network and designing new implementations on the network. So you quickly – I would say any network engineer and network administrator has their hands in some flavor of cybersecurity, what we would call blue team really. So, protecting the network.

So that’s really – I started getting more and more into that, because I saw the need. And what was interesting about it is in a lot of organizations, the person that’s responsible for cybersecurity or network threats may also wear other hats, right? They’re a network administrator with some function in security. But that’s not that their sole responsibility. The more that I dealt with security, dealt with looking for threats, remediating threats and things like that, it just kind of took me in the direction of I think this is really something that I would like to do all day, every day, versus just part of the day or part of the time.

So I had a unique opportunity arise at HORNE, because the accounting firm bought a small boutique cybersecurity firm, which has now become HORNEY Cyber. But what was interesting about the acquisition was that one of the things that they did was they did a penetration test on my network. And I had had penetration tests done before. And I was used to a certain way of things being done and the way that this group carried out the penetration test was drastically different. I would say the biggest difference is, and I’m sure this will come up later and we’ll talk more about it. But it was focused around unknown vulnerabilities. So zero day type vulnerabilities. Vulnerabilities that were specific to my network and no one else’s.

So, traditionally, the services that I had procured for cyber services revolved around publicly-known vulnerabilities, right? So what I didn’t realize is I was paying for penetration testing, but getting a Nessus vulnerability scan packaged in a way that there was some sampling of that and some manual testing done, but it really didn’t encompass what I experienced with the group that we had just brought on.

So that was really the first thing that piqued my interest, because I thought, “Wow! These guys do it really different.” And I’m interested in that. So the more we talked, there was actually a fit for me there. And one of the things I brought to the table was years of experience in corporate networks. So understand how IT departments work. Understand the mentality. I’ve been an operations manager, a helpdesk manager. And a lot of pen testers out there, they are what I would consider the top tier pen testers or computer scientists, but prior network administrators and network engineers.

While someone like me brings a very unique perspective to the group, and I think it’s very valuable, a lot of these guys, they’ve never worked inside of an IT shop. When it comes to interpreting what a finding may mean and the business impact of it, and then further on into the remediation piece, what’s a feasible remediation for this vulnerability that we’ve discovered. My background allows some dialogue there about, “Okay. We need to take these things into consideration.” And so it’s just a unique perspective of being inside, because what I found is a lot of pen testers that started their careers as pen testers and never been inside of an IT shop. So don’t really understand that dynamic.

[09:36] CS: So you said something before I wanted to get back to, because my first thought when sort of preparing the questions for this was that, well, you’re going to be good at network security because you know the ins and outs of building corporate networks, like you said. But I was interested to hear that you said that one of your advantages is that you know the sort of IT mindset and that you know the sort of the way that these sort of like network engineers think. Can you talk a little more about that aspect of the job and how sort of understanding the sort of network engineer mindset sort of prepared you for network security?

[10:12] BP: Yeah. It’s a great question. So I guess I would say there are two avenues on that. The first avenue would be, a lot of times, engineers and network administrators, as I mentioned earlier, wear multiple hats within an organization. So there are a lot of times they’re strapped for time, and in some cases strapped for resources. And one of the things that I feel like I’m really good at leveraging is keying in on systems that have been put into place and never been checked before. Because there’s ‘some basic things out there, and you can tell when you find them that, “Okay. They’re just trying to make this work. The security aspect wasn’t in mind. This was a project that had to be made work and had to get deployed.”

That’s one of my favorite things to do is sit down with systems like that and I feel like it just – Having been there before. Having been in that position to push things out under a strict timeline, there are stones left to turnover. There are some vulnerabilities there, misconfigurations and things like that. So I’ve been in that position before. I think it’s important.

The other side of that, it comes to client communication, right? When we communicate with our clients, for example, I was talking with a perspective client last week and they were telling me what they didn’t want in a pen test. And things they said we don’t want is we don’t want what we had happened last time when the penetration testing team, the cybersecurity firm in their report basically summed up and lay blame on vulnerabilities that they found and more or less kind of tore down the IT department in their findings.

To me, that’s not what a company hires us for. They’re not hiring us to tell them how valid relevant their staff is. They’re hiring us to find vulnerabilities. So I feel like that having been inside of an IT shop, and I’ve said this before in blogs and stuff like that. I mean, IT administrators and engineers, they take a fierce ownership of infrastructure that they manage to the point you’ll often hear them say my firewall or my servers, but technically theirs. I mean, it’s their baby. They spent countless hours on –

[12:48] CS: Yeah, they built it.

[12:50] BP: Yeah, exactly. They built it. And so when you go in and you find a vulnerability, and it very well could mean that that person lacks sophistication, but that’s not what we’re pointing out. We’re pointing out vulnerability. It’s on the receiving end of how they interpret that and what to do with it. But ultimately, I feel like there’s a delicate balance on how reports are structured and written and how information and vulnerabilities are presented to a client. So that it is a – So that it’s complementary to what they do. It’s realistic. And I think a lot of times, what you see is reports and things like that that could be hundreds of pages long. It’s a hodge-podge or Nessus scans and various automated tools that have hundreds, sometimes event thousands of vulnerabilities that may or may not even be applicable inside the network.

[13:50] CS: Right. Right.

[13:51] BP: I think part of being a prior engineer is you can sit down and go through these things and say, “These are things that are just super low-end. It's more of a hygiene thing. Certainly needs to be addressed, but it is not how a hacker is going to get inside of the network.”

[14:11] CS: Yes. Yeah, totally.  Yeah, like when we bought a house a couple years ago, you get that book that the inspector says – Filing 117 things are wrong with your house. It’s like, realistically, you need to fix about 20 of those. The other ones, it’s like – Yeah.

[14:27] BP: That’s a perfect example.

[14:28] CS: Put a light bulb up in the basement if you want or something. Yeah, I guess in comparing, that was really great in terms of talking about the sort of mindset, security side versus networking side. But like how surprised or not were you by how much you already knew from being an engineer for so long when you transitioned in cybersecurity? Was there a lot of sort of overlap in terms of the skills or did you still need to ramp up a lot of sort of different skills once you moved over to security?

[14:58] BP: Yeah. First, it was wildly fun to go from protecting networks to attacking networks.

[15:07] CS: Yeah, I can imagine.

[15:09] BP: That's a 180. So that in and of itself was just very exciting, a lot of fun. But I will say that I quickly realized how much I didn’t know. It was really interesting to watch and learn the anatomy of an attack and how attacks are carried out on networks, and a lot of the things that I used to look for as an engineer technically didn't even matter once I realized how the attack actually occurred, right?

It made me feel good because there was a lot of things that I brought to the table that other people on the team didn’t know. But then quickly realized that there was tons on the other side that I didn’t know. So in some of those things really would be one thing that I've never really dabbled in or have much exposure or the need for was being well-versed in various programming languages. I would say the fundamental language and penetration testing being Python.

So I quickly realized that I had some catching up to do, because a lot of the people that I was working with and was around, they had mastered that and became well-versed in it during college. And so they were in the job market and they were well-versed in these various languages. I think knowing that and having that knowledge, it makes you better, quicker. If you think about you’ve got a wall with 100 screws with a screwdriver versus a power drill, right? You can get there. It’s just going to take you a lot longer to get there if you can't build out a script to do some of the things you need done. So doing them in batches and things like that.

I quickly realized, “Hey, there's a lot you got to get up to speed to even keep up with this pace,” because it's a very rapid pace. It’s a very competitive area. But the one thing I will point out to anyone that’s interested in this it really depends on what level you want to be involved, right? Because there are cybersecurity firms that really operate off of vulnerability scanning and like PCI compliance where they’re basically doing vulnerability scanning, right? There's not the technical detail of knowing metasploit. You’re not exploiting vulnerabilities and looking for vulnerabilities in code.

So there's definitely different levels, and different organizations have – Some organizations have all the levels and some just focus on one. So I thinking it's important to have exposure to both sides of it. The vulnerability scanning side, that's a lot of reporting, and things like that, versus actual what I would consider real penetration testing where you’re working through looking for vulnerabilities externally. You’re coming through manually looking for vulnerabilities internally and how those vulnerabilities could be leveraged and pitted it upon into another area of the networker. Privilege escalation and things like that. I mean, those are the things that the hackers are doing. And you’ve got this other realm that's cybersecurity, but it's not the technical side of it. It's more of the, “Hey, here's all the patches that you're missing, and your password controls aren’t in place,” and things like that.

[18:45] CS: Now, you had maybe kind of a different situation than some people do, and that you went from HORNE legal to HORNE Cyber. It was also part of the same company, but in terms of, you were saying, you had a lot to catch up with regarding learning Python and learning some of these languages and so forth. Was that something that your job helped you with on the job or were you expected to sort of cram on the nights and the weekends to sort of get up to speed and what you are doing now?

[19:13] BP: My situation is been that I’m surrounded by a lot of people that didn’t know this already. And so I've got kind of a built-in resources. And I would say in a 8/10 times, most folks are going to land in that position where they have some internal resources or team members that can help them. But there’re tons of resources out there, and I don't think it's anything – I mean, unless you’re just super sharp and pick things up really quickly, I think it requires some extra investment of your time, maybe even personal time to really excel in that area.

[19:50] CS: Okay. What advice would you give for people who might want to make the type of switch that you did who are currently doing kind of more networking things and wanting to get to security now. Are there – Or even for people who don't have a huge tech background but are interested in getting cybersecurity. Do you have any sort of tips or advice for sort of fast-tracking that sort of thing?

[20:13] BP: Yeah. I mean, there are a lot of resources out there, and I would say that if you really want to get into what I’ve described as real penetration testing, and that's manually testing infrastructure without automated tools. I would say that – For example, offense security. They have some great training. I would say that's probably as close to real penetration testing that you’ll get in a training environment. Looking at things like offense security, looking at resources around red teaming and things like that. Metasploit I think is a very important tool, and there are others, Cobalt Strike and things like that. But I would say that coming very familiar with Kali Linux and Metasploit and how those tools are used inside a network. One of the things that I've been most impressed with with a lot of my teammates is their ability, finding SQL injection vulnerabilities and authentication bypass vulnerabilities in web websites.

So there is a popular training platform in the pen test world called Damn Vulnerable Web App. So it’s a server that you can turn up, and it's riddled with vulnerabilities, and you can really give it a go and practice at these types of things. And I didn't really realize it in the beginning, but I had a lot of the guys that I work with tell me, “Hey, you’re really lucky, because we were out at Devcon one year and they said a lot of the people here have never even really done a real penetration test. They just practiced.”

I guess I took for granted a bit that what I was able to do was jump right in on real live environment, start testing –

[22:05] CS: Yeah. Yeah, you learned right on the ground there. Yeah.

[22:08] BP: Yeah, exactly. So I would say that was fairly unique in my situation. But I think some of the most important things to consider if you want to make that move is where are you going to make that move to? What is your plan? Do you have any companies or organizations in your sides that you would like to be affiliated with or apply to? And really do your homework around how they operate? What their deliverables look like? What the expectations are? And then really try to take that direction and focus on – Look at their job postings. See what their skills are required in those job postings and then start doing some research on good resources around that.

I mean, I would say that the certified ethical hacking certification is – While it might be good on a resume, and a lot of companies require it just for the credentials, credibility, which that is one thing that it could help with. But I would say not to focus on that as much from a learning standpoint. I mean, it certainly cover some of the basics. But I personally haven't worked with a CH since I've been in the business.

I mean, it's one of those things to where – There's a lot of training out there that I think is misleading. So for me, if I were doing this again – And I didn't have the opportunity that I had with HORNE Cyber. I certainly would've invested time in determining even some companies that I was interested in working for. Looking at what they were hiring for, the skillsets, things like that. And then really doing some research and looking at reputable sources for information around those skillsets.

[24:05] CS: Now, something you mentioned before kind of – I bookmarked it for later here to ask you about, but you mentioned that when you go to Expos, saying like you did real pen testing back in the day, and a lot of these people have only ever done it via simulators and things like this. Can you sort of talk a little bit about what's being lost if that's the only way you've done pen tests is to do them on the Damn Vulnerable network or whatever.

[24:31] BP: Web app? Yeah.

[24:33] CS: What do you sort of get from that next step when you're actually doing it with some real stakes? What are some of the skillsets that changed in that case?

[24:43] BP: Yeah. I think probably the number one skill that changed is just adaptability. What I found is you can have a cyber range or a live-fire type range where you can test your skills and things like that. And a lot of those are kind of like capture the flag type scenarios. I thinking when you get into a real corporate environment, you’re just presented with so many different variables. And some of the clients that we work with are old. Their infrastructure has been around for a long time. And so what you start to see are these just pockets of infrastructure, different management systems, different authentication systems and things like that. I think in the real world environment, you're just presented with a lot more. And one of the big kickers I think that pops up in the real world when you're penetration testing is fact that systems can be brought down and systems can be halted if you don't understand what you’re doing, and a lot of legacy systems that happens too. But we've had a couple of clients that have legacy systems that we’re in-mapping and doing a host discovery and then just fell over, because they didn’t know how to respond.

Not often does that happen, but I would say – So one of the things that we encounter a lot, and one of the things that shocked me the most, and one of the things that shows you really have to understand the tools and the impact, right? I mean, you may be able to get password out of a system. But what's happening there? What’s the impact to that system? We’ve come in behind some pretty big names that we’re running 5, 6, 7 person teams, penetration testing, and we would find, for example, port 4444 open on a server on the public Internet, which is a commonly known Metasploit shell port.

So we thought, “Well, someone is already gotten into this network and for further investigation, reaching out to the client, we determined that it was their previous penetration tester that had left that port open.

[26:58] CS: Oh. Okay. Interesting.

[26:59] BP: I think it’s really important, and it’s almost like walking around with a loaded gun. You got to respect the tools. You got to respect the environment you’re in. It can’t be rambunctious. You got to know the impact of the trigger before you pull it. Always, in my opinion, one thing that carried over from network engineering and the penetration testing is I always have a plan B. Know what the undo button. If there's not an undo, then you need to think about what you're about.

Really, just being very meticulous, good at documentation, good at turning what you've done technically through a keyboard and mouse to a well-written document that gets the point across. It explains the impact to that organization specific.

[27:51] CS: Yeah. I actually was just got done recording another episode here, and you’re sort of saying the same thing, but he mentioned almost having like need to have sort of like a doctor's bedside demeanor the way you do reports, and that you said, you can't be apportioning blame or saying this person completely dropped the ball or whatever. You're screwing with people's careers at this point.

[28:14] BP: Exactly. Exactly. Yeah. Most of the time when an organization – And unless they otherwise specify, “Hey, we would like to evaluate – Like you to evaluate our team’s performance,” which I haven't had come up yet, but certainly if that was in the agreement and that was the expectation, but I don't think most people were expecting to get a litmus check on their actual IT department. They want to know where they stand from a cybersecurity posture as it is.

[28:41] CS: Yeah. They just don’t want to get breached.

[28:44] BP: Right. Exactly.

[28:45] CS: So you really laid out it well in terms of like the way the stakes get raised between you're working in a fake lab at home or a cyber range or something like that, versus having it on the job. But there's naturally also a little bit of – Like I got a little bit of fear in my stomach. Now you’re doing it without a net, but you’re doing it for a client. What are some sort of like the fails safes that you would sort of recommend for people who are sort of doing their first pen tests for like an actual client? Like you said, knowing the importance of the undo function and things like. But like what would you recommend while you're in that sort of like learning and possibly making mistakes phase?

[29:27] BP: Yeah. I think probably the one safety net I feel like that can be cast would be around. The client communication, right? So setting the implementations, have clear – And if you’re not the one that’s communicating with a client, communicating with the person that does talk to the client and really understanding what the tolerance is. A lot of the things that I would say – First and foremost, one of the first things I came across that really stuck out to me was I came across this vulnerability. I wanted to attempt to exploit the vulnerability. I didn't really know what the overall impact is going to be.

In that scenario, my opinion and my suggestion would be stop what you're doing and start the communication chain of, “Hey, found this likely exploitable. How do we want to proceed? Do we want to exploit it? If we do, I recommend we do it after hours and you have one of your engineers kind of watching that system as we carry out the attack. If things do go down, they’re there to bring it right back up.”

Again, it’s – And a lot of it is, I think it's an inherent ability to smell that risk, right? I mean, is this something you’ve done 50 times and you know that the risk is very low or your colleagues have – It's one of the lower end things that you do? For example, you’re going to test-out some default passwords on the web interface. Well, that’s low risk, right?

But if you think you’ve got a reverse shell to one of the file servers that they’ve explained that every user in the firm connects to, then is that something you should consider doing off-hours? I like what the client say, “Hey, found this. Let’s talk about how to proceed.”

I think – Because there's nothing worse from being on the inside, right? I had a person come in and do some vulnerability scanning and they pointed Nessus at a subnet that I told them to exclude, which is an iSCSI SAN network, and it – Oh! My SAN crashed. The controller is freaked out, because they got the the support scan Nessus going.”

That was communicated in the planning phase, which is my second point would be a lot of the things that can really bite you can be ruled out in the planning phase, right? We always ask for legacy or fragile system. Tells us about – Let’s talk about what they are. What you need to be aware of to not compromise your operational functionality during this testing, right?

[32:13] CS: Yeah. Okay. Now, do you have sort of a different system in place for more kind of robust systems that you're working with where you might be more emphasizing kind of a red teaming aspect where you're really sort of like going on the attack versus the sort of more fragile ones where you're not looking to break anything like that? Do you sort of have different sort of intensities for different clients?

[32:35] BP: We do. For example, when we do external versus internal penetration testing, there're really no rules on the external. I mean, go hard and fast and scan for all 65,000+ ports across the attack surface. And take it to the point at what we wouldn't do is exploit a vulnerability on the public Internet. We’re going to take it to the point to where we know it's there. But we don’t want to compromise the integrity of their data by exploiting vulnerability and copying data across the public network. So we definitely shy away from that.

But I would say there's always room for extra precaution internally, right? How we do things is we have a device we put on the network. It represents a compromise node, right? Because we don’t care about your firewalls and things like that. You have to assume that somebody at some point could land inside fo your network. So what happens when they do?

I would say that there’s – You may come across a mature organization that is been going through red team and very sophisticated penetration testing for several cycles, and that's something that's going to come out in those preparation talks. And I will say that those are probably organizations that are well-equipped to handle a pretty intense internal attack, whereas if it’s a client and it's the first time having a real enhanced red team penetration test done, advanced penetration test, I would say that there probably needs to be some kid gloves throughout that process simply because there are unknowns. They haven't had this type of testing conducted against their network before.

I would say that really boils down to the maturity of the organization and what they had dealt with in the past. A lot of them already know what their limitations are. Those that don't I would say are the ones that require some caution.

[34:44] CS: What are some common mistakes that like young sort of penetration testers make? You’re giving us lots of sort of precautionary ways of dealing with it and stuff, but what are some sort of rookie mistakes that would be good to avoid?

[34:58] BP: Yeah. So one that I brought up a little a while ago and we’ve seen it several times is we’ve seen where penetration testers have come through. They’ve gotten a reverse shell on a server, but they forgot to shut that reverse shell down. We’ve seen a lot of – I would say you there a lot of penetration testers. There're some penetration testers out there that may operate on – They find a new methodology that they're going to try out and they're going to try it out on a client, which is probably not a great idea.

Some pretty common mistakes I've seen around, R spoofing and things like that. Not having a graceful shutdown or a graceful unplug from the R spoofing operation in cripple network until things refresh. So I would say that I've seen a lot of mistakes made with some of the tools inside of Metasploit, some of the penetration testing tools, like SQL Map, NMap, and things like that. Going in on a T5 NMap, which is very aggressive scan inside of the network that you don't really understand what the subnets are what's represented in their subnet.

We had an instance where we – Actually, our settings were as they usually were, but we conducted some work with a bank that had some old legacy money counting machine, and so where they were hooked up via a land converter. So they even have a nick on them. They just had to port it. They have these things out there. We’re going to runs some NMaps and things on that and all of those now, right? We didn't really understand that that's what they had on the network. That never really came out. But lesson learned, right? And we ask those question moving forward.

But really, I'll go back to – it’s understanding what the tool that you're using is actually getting technically, right? You know what you want the outcome to be. You know what you’re checking. But what is that tool? could you do it without the tool? And if you – And understand what it’s doing, right?

I found this cool new tool, and you download it and you point it at a system. You may not understand the technical details of how it’s interrogating that system to get you that information you’re looking for. And I would say that's a huge fallacy. You got understand technically behind-the-scenes at a coding level what's this tool actually doing.

[37:34] CS: I think that sort of speaks to to what you said about before about not necessarily needing a lot of certs to do the job, but you need the work. You can study towards getting this knowledge or having this thing. But unless you know the sort of theory behind it from doing it, it's not necessarily going to do you a lot of good.

[37:53] BP: Exactly. Yeah.

[37:55] CS: Yeah. You’ve moved pretty far in your security career and you know your stuff and whatever. Are there things that you're still trying to learn or do or progress in this particular position? What are some like five-year goals for you doing this type of work or doing something at another level yeah?

[38:15] BP: Yeah. I think, as I mentioned before, having been inside of an IT department, I found myself doing a lot of relationship management and client management from the aspect of talking with them, and even some sales work as well, right? So understanding the IT department really allows me to speed to those bodies confidently and answer their questions in a way that they understand what I'm talking about him.

But for me, and part of my role on Cyber is on the cybersecurity operations center. Coming full circle, coming from an environment where I tried to protect where I was protecting against attacks. I’m kind of back over in that realm now from a client/server standpoint. Really, for me, I think staying ahead of the curve on vulnerabilities and how those vulnerabilities are exploited and how do they appear inside of a network? How do you find those things if you’re threat hunting, if you will, which is what we do a lot of in the seesaw.

Really, for me, I'm spending a lot of time looking at emerging threats, intelligence feeds, things like that, looking at how particular attacks and how particular exploits are carried out on a network, and those would appear inside of the network traffic. One of the things that helped me out tremendously, and it's come up several times throughout the cyber career for me so far is understanding networking at a basic level, right?

I mean, not only do we spend time penetration testing, but we also spend time working on the connectivity to the client and making our devices function properly across VPNs and things like that. Understanding networks as a whole and staying on top of that never changes. I mean, with every new Linux release of Windows release and server release and things like that, things are changing. There're new technologies. And so it’s really a never-ending process of staying up staying up to speed with what the new technologies are coming that’s out.

From the penetration testing standpoint, what are the new – The new threat prevention and detection systems and how are you getting around those or using those to your advantage? Because a lot of times, what we find is that the first thing that we breach is some type of security device that has the keys to the kingdom.

So it's really important. There're a lot of resources and a lot of government agencies that publish a lot of good material, research type material that can then be parlayed into real-life penetration testing and security work.

[41:21] CS: Okay. So this has been great, and I’m really enjoying the conversation, and I really appreciate your time. So as we wrap up today a little bit, do you have any advice for people who might be feeling stuck in their current position? Maybe they’re still doing help desk or whatever that might want to make a switch into sort of a higher level of cybersecurity?

[41:38] BP: Yeah. I would say – I mean, it’s not an easy transition simply because you're going up against a lot of folks that have been in the profession for awhile. A lot of the more sophisticated penetration testers, as I said before, computer scientists, computer programmers, they understand operating systems at a very granular level, and applications at a very granular level, and networking at a very granular level.

I would say if you’re wanting to break into the penetration testing world, I would become familiar with some of the offensive security training. I think going to tell you really quickly if you feel like you’ve got a leg up. If you want to proceed in that direction. But then also I think a lot of self-study. And looking for opportunities inside of your current role, right?

I mean, even when I was on the help desk, I had an interest in security and how the network cured. For me, I would see things that stuck out to me and I would take them to the person responsible for those. So forming good relationships with people that are already in those roles. If you have that opportunity, I think it’s good. Looking for a mentor that can gain some knowledge from and gain some direction from I think is very important.

I had the opportunity to work with Dr. Wesley McGraw who’s on our staff.

[43:18] CS: Former guest of the show.

[43:20] BP: Yeah. So, West, as you know – I mean, he has his Ph.D. in computer science and has done a lot of research and has seen a lot of things. It’s a good person to have around to just talk to and ask questions and things like that. Finding somebody that you can communicate with I think is really important. There a lot of people out there that are open and willing to talk about their experiences and things like that. But I would say if you're in a spot and you’re ready to make a move, you need to really understand what the expectations are, because there are some lackluster type cybersecurity roles out there that I think a lot of people get into expecting a dark room and command line stuff and they’ve given a laptop and an address and say, “Go run Nessus on this network. Bring us back to port.”

I would say really know what you want to do. Have a good idea of that, and then get some target companies that are doing those things and start looking at their job postings and look at the skills that they’re asking for and then be real with yourself around whether or not you you’re capable and have the mindset to really take hold of some of these concepts and learn them to the extent that you're going to have to learn them.

[44:48] CS: That's awesome advice. So as we wrap up today, tell me a bit about your work with HORNE Cyber and some of your current projects and initiatives that you're excited about at the time.

[44:58] BP: Yeah. I’ve been fortunate enough to – So I started out in penetration testing piece, and I’ve kind of transitioned into several different roles throughout the five years I've been here. And so now part of what I do is on the cybersecurity operations center. So we have a handful of clients that we go in and we deploy sensors for their network and various agents on strategic machines throughout the network. And then we ingest all of that data and we’d analyze it for potential threats. So whether it’d be a machine that’s got some and nasty viruses and it’s trying talk out to command-and-control server, or you it could be someone that's trying to gain persistence from an external app.

So that's really exciting. It's ever-changing, and it brings a lot of things to life, especially when I do – One of my other duties is dealing with clients from a presell standpoint, and even getting calls from current clients. You just need to talk about a business email compromising and what do they need to do. Where do they need to go? What do they need to check? Things like that.

That part of it, it’s stressful, but it's exciting. It's certainly a good service and it's always very appreciated by our clients. They have someone to call and talk to. Outside of that, from the penetration's testing standpoint, I’m very fortunate to be involved with those and manage several penetration tests supporter and work with those teams. So all that’s very exciting with the COVID situation that we've been faced with lately. It's really changed a lot of organizations’ mindset on – They realize that they quickly had to make some transitions for capabilities.

And so that's been very exciting, because we’ve had a lot of just really quick calls that says, “Hey, we need you guys check in this external infrastructure for us. We made some changes and we’re a little uncomfortable with it. Tell us what someone could do if they tried to target us.” Right? Like kind of ad hoc, “Okay. We got to go do this right now,” kind of stuff versus these longer planned-out processes. To me, that's always exciting, because I love to get the deliverable out the door and move on to the next. So the faster the pace, the more exciting, the more opportunity there is for discovering things. That’s really what I’ve been most excited about over the past couple months, is just the tempo has really picked up. The work has become more demanding and it's fun to see the team adapt and carry out the deliverable.

[47:45] CS: All right. One last question, and this is for all the marbles. If our listeners want to know more about Brad Pierce or HORNE Cyber, where they can go online?

[47:51] BP: Yeah, hornecyber.com.

[47:55] CS: HORNE is H-O-R-N-E? Is that right?

[47:57] BP: Yeah. H-O-R-N-E. That’s correct. So all of our bios, the team bios, description over our services. Brad.pierce@hornecyber.com, my email. Yeah, we’re fairly easy to get in contact with. We got a web form, but then also everyone’s individual contact information on the site. That's how you could find us.

[48:21] CS: That's great. Brad, thank you so much for joining us today. This was a lot of fun.

[48:24] BP: Thank you, Chris. Yeah, absolutely.

[48:25] CS: And thank you all again for listening and watching. If you enjoyed today's video, you can find many more on our You Tube page. Just go to youtube.com and type in Cyber Work With Info Sec. Check out our collection of tutorials, interviews and past webinars. If you’d rather have us in your ears during your workday, all of our videos are also available as audio podcasts. Just search Cyber Work With Info Sec in your podcast capture of choice. And to those of you who have been giving us five stars and nice rating and nice reviews, we really appreciate it, and it has been helping. So please, if you haven't done it yet, consider taking a few minutes and tell us what you think.

For a free month of the Info Sec skills platform that we discussed in the promo before today’s show, just go to infosecinstitute.com/skills and sign up for an account. And in the coupon code, type in cyberwork, all one word, all small letters, no spaces, and you'll get a free month.

Thank you once again to Brad Pierce and HORNE Cyber, and thank you all for watching and listening. We will speak to you next week.