Pen Testing Fundamentals & What MSPs Need to Go To Market

All right. Welcome back. Week 90. Can't believe it. We are coming up on a two year anniversary here at the cyber call. Good to see you back, Gary, Wes, and Ryan, no big news in the industry today, so we won't be talking about it yet. That nor can we. Nothing to see here. Yeah, no, none of those droids. Um, what are we doing? I like that. Sligo, good to see you. Um, welcome back everybody. Okay, so, um, we're gonna be introducing our guests momentarily.

Just a few quick things, announcement wise, take a look at the cyber call calendar coming up. Um, we have got an action packed April next week. Tell I, I'm, I'm telling you right now, you should tell every vendor you're working with to come for the cyber call next week. Um, and, uh, the reason is we're going to have Jim Manco on, um, first off, considered arguably the godfather in the off top 10.

And, um, when it comes to secure coating, um, John Strand is holds this gentleman in high, high regard. Um, his company is called MANA Code. Um, and ideally, I can't promise anything yet, but the second CISO summit, we're gonna get Jim to moderate it, and we are going to do, um, the event around secure coding for the four ciso.

So, but anyway, if you don't know how to do this, you know, see what's coming up, all you need to do in the left hand side of the panel is go to schedule, click it, the menu will drop down. That's also where you can go back and see every one of the past shows, et cetera, et cetera. So our topic today is pen testing and, um, how it can make all of us better. Um, I'm thrilled to have Eric Fisk with us. Let me just set the stage real quick and we'll get right on into it here.

So, if you look at frameworks like a CIS for example, um, you know, they'll call out that, Hey, before you do a pen test, you really should have your vulnerability management in order. There are exceptions to that. We're gonna be talking about some of those exceptions today. Um, and there's some really good reasons why. And a lot of the times, you know, you know, you see things out there, oh, BM before pen test, but pen test is a lot more than just CDEs on devices.

And so we're gonna be talking about those things as well. So, Eric, with that, first off, thanks for your service, um, to our country. Uh, and, um, you know, please share a little bit about that, but share a little bit about yourself, Hackett, um, it's great to have you with us. Awesome. Thanks, Andrew. I appreciate it, and thanks for having me today. Uh, looking forward to the call. Um, so my name's Eric Fisk, uh, co-founder of Hack at Cyber.

Um, as Andrew already mentioned, I was an 11 year vet, so I, uh, spent a couple tours overseas, uh, had some fun in the desert, came back, unfortunately got injured and I could no longer stay that what direction. So, you know, it's like, can't go to war. We don't want you anymore. So they put you back, they send you back. And then at that point, I went back to school and, you know, I got my degree in, uh, network engineering network information and, uh, network administration.

And at that point, that was kind of my, my path to my cybersecurity information, really, the, the, the new love of my life, which is the information security. Um, so father to four girls, you know, so they got me running around all the time. You know, only, only legends can handle four girls like Kobe Bryant, right? So, uh, um, but yeah, uh, ultimately, uh, Hackett Cyber Offensive Security certified suite. We, uh, we offer services that provide penetration testing and ethical hacking.

And really the main goal is to help any organization and customer become more secure, stronger, and develop a stronger security posture for themselves. Yeah, and I'll just as I, as I point the ball over to Gary here, um, you know, I think you and your partner James, uh, with your legacy, you guys have been doing this for a long time, um, and work with a lot of MSPs. So partnering is something that is, uh, you guys have a very good handle on, which I think is really cool.

So, Gary, with that, I know one of the things you're doing in 22, 20 22 is going back for your pen testing degree. And it's very great to know that you'll have those skills available to all MSPs coming out here. A absolutely, uh, as most people know, I'm highly technical, so, uh, I'll be doing that. Uh, first thing, Eric, thank you for your service. Thank you. Yeah, Definitely happy to do it. Um, okay, so let's jump into this.

Look, we're getting tons more comments about Datto and Kaseya in there. So Andrew, can I just say, can Go do it. Anything that I know about this, you can go to the Kaseya website and read the press release and the frequently asked questions, and literally, I don't know any, I don't know anything more than that about it at this point, but, uh, as soon as I do know more and legally can share it, uh, no one's more transparent, uh, than than me. So, uh, we'll, we'll, we'll do that. Good. Okay.

Okay. Awesome. Awesome. Okay. So with that, Eric, let's start like the basics. Can you tell us what is a pen test? Okay. And why would a company use a call, call a pen tester in? Yeah, for sure. Um, so a penetration test essentially is a, an assessment and it overall looks at a network topology. It could be from the internal, the external or wireless. And the goal realistically is to find as many vulnerabilities that exist on that infrastructure to help people find that low line fruit.

So the gaps that may cause any unauthorized access to devices, compensation, someone that could lead and gain unauthorized access to a service and compromise that and gain, you know, sensitive information. So essentially, those look across multiple different platforms, but, um, ideally it's just kind of a come through, give a realist realistic view and approach of what an attacker would do prior to actually, unfortunately having it really happen to you, right?

So that way you can harden the environments. Gary, can I just mention, yeah, I was gonna say, Gary, can you just talk about things like the, from a social aspect that it's more than devices, right? I mean, a lot of times you guys are called in at a user level, right? So, yeah. You know, yeah. From a social engineering standpoint, um, essentially this could become from a spearfishing engagement.

Uh, ideally what happens is nine times outta 10, when you look at a true incident that occurs in the wild, um, either a service has been compromised and gains unauthorized access, our user gave some, gave it away, right? A user clicked a link, gave up their credentials, so on. So we, uh, replicate those kind of, uh, scenarios. So essentially look at the user, see if, how well they're understand what kind of phishing techniques exist.

Call a user up on the phone, you know, how many people have had the IRS call them up and say, you owe back taxes, right? Concepts like that, um, and so on. So we'll look at each one of those aspects, uh, apply it forward so that way we can provide basic, um, best practices and that point, help educate those users as well. 'cause I think probably that's one of the one focus that most people need to rely on. More users are always gonna be the weakest link.

And education on users is probably one, be the most beneficial piece of it. So, Eric, some people on the call may not, you know, or, or they, like, they're not all deep in the cybersecurity, like technically, like I am, like Ryan and Wes, you know. So for those people, um, sometimes talking about vulnerability management, talking about pen testing, some people don't know where one ends and one begins.

So can you just kind of definitively from your perspective, say vulnerability management, pen testing? The role of each? Yeah. So essentially vulnerability management is a, a way for organizations to kind of know exactly what they have prior to start, like deciding to get the, uh, the penetration testing.

So they're actually at this point of the, uh, the game, trying to figure out exactly what gaps they have in their cell, doing their own due diligence, making sure they harden each one of the aspects of the network. Um, when you throw in the pin test, it's like saying, okay, the vulnerability management was my plan, right? I developed a fire drill plan and this is how I wanna follow it. Now the pen test is your fire drill, right?

So I'm actually gonna test the network, I'm gonna see how well it stands up, I'm gonna see what vulnerabilities exist. I'm gonna see how far they lead down the rabbit hole and go from that perspective. Yeah. So, so each One all Go ahead. You had something else? Nope. Nope, that's it. Go Ahead. Okay. So in thinking about that, I know some frameworks, like CIS, they're saying, Hey, get your vulnerability management program in place first, then do pen testing. You probably could chicken or egg it.

Like, do you agree with that or does it depend? Well, I think when you look at security, it's all about layers in defense, right? Essentially understanding like the CIS framework, knowing that people are putting together, um, a practice that follows a specific standard framework that allows individuals to determine, okay, these are best practices I need to follow prior to doing the pen test.

Um, a lot of the times people throw in themselves at a pen test who've never done anything on their network before, and then it's usually the shock and wow act, you know, factor. It's like, oh, man, am I like the worst company you've ever seen? You know? Um, but ideally it's, it's more or less of like a adapting to a standard, accepting that standard and then testing to make sure it works, the validation. So I think both have their place in each one is necessary. Yeah.

And, and I know, go ahead, Andrew. Yeah. Do you mind, Garrett, just, uh, there was a good question that David asked Eric, and before I ask it, by the way, folks, if you could jump into the polls. I mean, I, I'd really love your imp uh, opinion, especially on the first one. Um, just take a quick peek. It'll take you two seconds to say yes or no to each. Okay. So Eric, you know, there's these, you know, more and more, you know, security solutions coming to market, right?

Um, so why not have automated, you know, AI driven, uh, pen testing. Um, so can, can you give us your perspective on that? Are they effective? Would you know, good, bad, indifferent? You know, do you believe, you know, you could actually, you know, do an automated, like in this case e external pen test via something like that?

Um, I think that an automated pen test, essentially what will happen is you'll run into a number of false positive issues where the, maybe the scanner might lose or not understanding exactly how it works. I think that automation comes in places where it is necessary. For example, vulnerability scanning, it's mostly automated. You can scan it, you know, look at the versions of, um, all kinds of software out there and understand exactly what exists.

But then you have to be able to take and understand how an attacker's gonna leverage those and gain access. And, you know, there's not enough if statements in the world to understand through AI that it's gonna come and attack every single one of them, or know exactly how to, uh, you know, implement or control each, uh, vulnerability that may exist out there.

So I think having that manual validation to go through it, make sure that you hit every weakness that could exist, that's the important piece of it. Whereas if the computer's only gonna look for what can actually be told it's gonna look for. Yeah. Really good stuff. Go ahead Gary. Yeah. And kind of staying with that train of thought, but little bit different, um, uh, really what makes a good pen tester? Like obviously they're not all created equal, right?

So what makes a good pen tester and how would I know That's a good question. Um, I think a lot of the time it really comes down to they have to align with a value that each organization is aligned with, right? Um, like for example, Hackett, our company, we align with MSPs all the time, but our one goal is mine is to better the organization that we're working with, right? So as long as everybody has that same alignment in place, then that is gonna go into the right direction.

So me, I would say, in order to find a good pen tester, is somebody who's always able to continue to learn. They want to keep learning. They have their passion and drive to pick up things and go continue to push themselves. Um, but ideally they gotta be able to come through and have some kind of good communication with customers back and forth, right?

You could be the best coder, you could be the best pen tester in the world, but you provide them a report that nobody can digest or understand that at the end of the day you kind of failed that customer 'cause they don't even know where to go from. Yep. Awesome. Alright. So We, we still have a language problem then, don't we? Right? Like, like we, we used these words that mean nothing. I talked about that last week on LinkedIn, but it's a huge problem. Oh, a hundred percent.

I mean, when you look at pin testing, you have, everybody has adapted to a methodology, right? We all have like similar methodologies, but when it comes to the deliverable, it's like very whimsical. Nobody ever sees like the same report or the same understanding or the same concepts. Um, so I, I hack it. We've kind of tried to deliver a little bit up from that and we use like the, um, the Mitre framework.

So essentially we're gonna tie ourselves to that framework so that way whenever we say, Hey listen, I passed the hash today. Well why'd you do that? Oh, you know, 'cause I had a Turkey Ruben and I felt like it. No, it's because Conti ransomware is doing it, you know, and they're getting do it because they're gonna continue to be successful. That's why we're doing it. And we're showing you, you know, the TTPs of who and why. Ooh, that's good. That's interesting.

You know, I, one last thing before I pass it over to Ryan. Uh, I was talking to someone a few weeks ago whose company does pen testing and they do stuff in the enterprise. Um, and they, you know, in the industry you have talked to MSPs and that's one of the biggest gaps. Like, they have to find different ways of explaining things, uh, because they're not the same language used. Interesting. Alright, Ryan, I'm gonna hand it over to you, my friend Ryan.

That was a good segue going threat and formed, uh, pen testing here. I like to hear that. I mean, we could probably spend the entire hour talking about what a pen test should be versus what it is that's being offered in the marketplace.

But I think tying it back to actual testing of tactics and techniques that are used by actual threat actors, rather than just being, uh, oh, I noticed you have this web asset, I'm gonna look at it for, oh, os top 10, or, oh, I'm gonna run a vulnerability scanner and write you a report. Those are not pen tests. Um, and so yeah, the, what is a pen test conversation?

I mean, it kind of delves into this next question I have pretty well, which is, when you work with MSPs, you have to define a pen testing engagement. And I don't, I would, I would imagine that not every MS P comes to you with the same understanding of what the pen test is or what its results will be.

When you get into those conversations around engagements and scoping and deliverables, what tend to, what, you know, talk, walk through, like for the MSPs that have a good engagement versus MSPs that are more challenging. Like, how do those conversations tend to go? What are the expectations around pen testing that they have? Yeah, I mean, that's a great question, Ryan. Thank you. Um, so essentially whenever we talk to most MSPs, there's a lot of pushback in the beginning.

'cause essentially they're a little concerned and scared that they, they're gonna look incompetent. B, their customers are gonna get this information and then they're gonna come out and the, the security assessment's gonna make them look like they don't have the knowledge or lack thereof, right? Um, so a lot of the times we get a lot of pushback from the MSP providers because they want to make sure that the customer understands, Hey, listen, we're doing the best we can.

We bring these guys in as a third party to help scope this assessment to understand that piece, right? Um, the difficult side of that would be that piece, right? The other side is where, uh, MSPs may come up to us and say, we have a customer who has a security concern, um, and they want us to test a certain space, and, uh, but they don't really understand exactly what testing looks like or what they need to look like.

And so our goal at that point is to sit down, explain to 'em the methodologies between, okay, listen, you have an external network. Do you need the external network tested? This is what that methodology looks like internally, the same concept externally wireless. And then let them understand, okay, listen, are you, you know, PCI, are you, uh, you know, hipaa, do you have, um, any kind of like compliance framework that needs to be followed or so on? Then we have to test accordingly to that.

Outside of that, it's more due diligence and understanding, do you need this? Do you want this, is this something you're looking for? Are you willing to make these changes? Because that's ultimately the goal of this. Yeah, for sure. Again, I could, I could sidebar us for, for a day just that answer alone. Um, Sidebar away, Ryan, if you got something.

Yeah, I mean, I think, like, just real quickly, I think as an MSP, when you engage for app pen test, you have to understand what you want out of it. Um, because, and, and you need, and you need that because not every pentest vendor is gonna provide you the same thing that might align with what you want, right? Do I wanna know if someone can get root on, um, uh, a given server? Do I wanna know if my general internet presence is safe?

Do I want a report of all the vulnerabilities that someone can find in a, in, in one week? Like, those are different objectives. And so you can't just go into a pen test. 'cause some people really, their objective is, I want to feel safe, But what is it that actually makes you s safe? Like, you have to peel that back a little bit and you need to be a little bit more clear about what your objective is.

'cause the, a good pen test is gonna be the one that best aligns with the objectives that you're looking for. And so, um, you know, we have an internal pentest team, they can conduct four different types of pen testing engagements based off of what we're looking for. And then we have external pen testers too. So really before you do a pen test, you may be really clear with yourself about what you want because it makes your conversations with a professional.

Um, like Eric, you're, you know, much, much better, uh, because you can make sure that you're aligned in what is ultimately being done and delivered. Um, so yeah. Yeah, Alignment. Alignment alignment's huge, right? I mean, essentially we've had assessments where the alignment wasn't the same as our goal is to find the vulnerabilities and map them back to help them harden an environment.

And the customer's goal was to find as many vulnerabilities, make this thing look like a pile so we can get rid of it. You know, I mean, Ryan, in theory, like, I mean in theory, you know, if, if you get the right group, like Eric's who works with a lot of MSPs and you know, you're this, you know, you've got a client that's maybe been resistant to certain controls.

I mean, what better way to have a third party validate and point out, you know, we, you know, we compromised you based on these lack of controls and your, your MSP has been saying, put these input, these, input these in a good pen test firm's gonna turn back to the client fair, Eric, and go, your MSP's right? You need to build up these in. Yeah, I mean, this goes back, I mean, I'll go back to customer zero, right? The, the talk track we stole from another guest a long time ago.

If you operate yourself the same way you operate your customers, your customer zero, you're using the same tech stack, the same processes, you do a pen test on yourself, that's gonna tell you the security of the solution you're bringing to your SMBs. If you don't treat yourself like customer zero, you need to be doing one a pen test of yourself, and then two, a pen test of an environment that's of your customers.

And so if, depending on how you structure yourself versus your customers, you really need to be doing two different tests because there's two different objectives. Assure the security of the solution that I'm delivering to my customers, assure my safety as an MSP two different objectives might require two different tests. Cool. I agree. I think I agree with that.

And I think that, uh, essentially the way it works in my mind is, um, realistically pen testing, MSPs and companies that work together are all just working to sharpen each other, right? The goal is one, to in, in influence and educate the, the company to develop better practices, which in the turn makes it harder for the, uh, the actual break in, uh, someone, the break into them and gain unauthorized access.

The MSP isn't able to take that information, then apply it across all their platforms, so essentially makes them stronger, and then it makes it harder for us to gain access. So then we gotta get better at what we're doing. So in turn, it all just kind of a vicious cycle. It just makes us all stronger. Yeah, sure. So let's go a level deeper. Um, when you scope a pen test, how, you know, how, how do you do that?

And, you know, that gets back to the being aligned between you and the, the company that's being tested. Like what does a good scoping exercise look like, and why is that so critical to the success of the engagement? Yeah, I mean, it's, it's very important to understand exactly what needs to be in scope and what's not.

I mean, you could be testing multiple networks and you might wanna make sure that you know, that there's like an OT network on one side of this that maybe there's no access or no access control list. And all also, now you're scanning a SCADA environment when you're supposed to be scanning a corporate network, right? Um, you wanna make sure that you understand what scopes are involved, what technologies are supposed to be tested.

You need to know like what data or what devices might be sensitive to vulnerability scanning from the past. Um, the goal really is whenever you're doing a penetration test, yes, be thorough and be effective, but also to make sure you don't hinder any daily operations. Um, you don't want to take the customer offline or, you know, deviate from the plan and make sure they have a rough day because they can't work anymore because your pen test denial service one of their servers or so on.

Hey, uh, Ryan, speaking of scoping, could, maybe we go through this, and again, it's a, it's, it's a tough question, but I'm gonna ask it to Eric. It's like, Ann, ask, you know, can you walk us through a, a typical Eric, 'cause again, this comes back to scope, right? So this is a, we could do a facetious role play here, like you're pen testing true methods Mm-Hmm. And, you know, it's a 10 person accounting firm. In this case it's 10 person accounting firm.

Like what, what, what might that look like? You know, the, the accounting firm calls you up, you know, what, what things are you looking for? How might you scope that? What budget, you know, would, would you probably, you know, small SMB 10, 25 employees? Right? Well, I first start the conversation off with seeing if they've already had any kind of penetration testing done in the past to see if they understand the methodology, understand the approaches that can come from that.

Um, if they have not, then what I do is I can walk through array of our services. So from examples I would say like, we have an external assessment that we can perform for you. Um, essentially looking at the external services to verify that no one from anywhere on the outside can gain unauthorized access to your services, your client data or any information.

Um, then we'll go into the internal assessment to see if that's something they're interested in, give them an understanding of how that looks, what that, you know, how we can deliver that kind of an assessment for them. And then give them an understanding of like what the methodology looks like, exactly how to determine what we're gonna do. So there's no, like under, there's no question in their mind on where the method where we're gonna go with our assessment.

Yeah, I, I gotta imagine, Ryan, I'll turn it back to you, but, you know, a lot of things we've talked about in the cyber cyber call here, you know, like you're gonna look for, you know, first off, you know, again, hey, so your accounting firm, you know, how do you generate revenue? Or we think we know that. What are your line of business apps? Where's the most critical data live? You know, the Ryan, is that fair?

You know, you're gonna, you know, start at those high level things anyway, no matter, regardless. Yeah. I mean, I, I think if you get a really good pen test partner where you're trying to figure out the scope, those are the types of conversations you should be having. Unfortunately, it's usually an intake form that says, tell me the assets you care about. Tell me why you care about them. Gimme some IP addresses, gimme some URLs.

You know, I'll, I'll give you some IP addresses and some hours that I'm gonna be doing the testing. And like, that's it. It's like, that's the scoping exercise. Um, so again, that's why it goes back to, you need to be really clear about what it is you want tested and how you want test it, and for what and why. Yeah. So that you're clear when you go into those conversations because you don't know, maybe there's a better way to approach what you're ultimately after.

Um, and you know, my experience with pen test companies has been, if you give them a really interesting challenge and you say, you know, I'm not looking for your standard cookie cutter, you know, um, run a, run a tool, find some interesting areas and then poke deeper, uh, like I want, you know, I have this objective. They'll often, you know, the, the rate won't change, but they'll come up with a different way of approaching that outcome.

And you actually get, I mean, Eric could speak to this, but they become energized and they become motivated by the fact that they get to do something and they're aligned to the why, and you actually get a much better result for the money as opposed to just filling out the form and submitting it and hoping for the best. And then maybe you are, maybe you're not safer at the end of the day, but, um, yeah, No, for sure. I agree with that a hundred percent.

I think that, um, those out of the box solutions that a lot of people come up with, where they require very significant, uh, specific scenarios are really unique and interesting to always tackle. 'cause it takes a different mentality rate. It's like saying, I was working in the, the factory and I was just making car doors, press, press every day. All of a sudden it's like, here's the keys to bulldozer, go drive it. It's like, what? I'll give it a try. Yeah, Yeah.

I mean, I'll, I'll, I'll share a story. One of my favorite exercises I ever did, um, with a external pen testing company and my internal team is an assessment we called first contact. It's like, Hey, here's all these assets that have never been looked at before. We need to go in and we need to assess every single asset, and we need to do a first contact. Because a lot of times the most critical vulnerabilities you find happen within the early contact with that asset.

Um, there's some exceptions to that. And for the most, I don't have 'em on my assets in line yet, can you hang on a couple weeks? So you definitely need an asset inventory to do this. We need that. Um, but we went down to the pen test company. We said, Hey, here's our, here's a a range of IP addresses. We want you to spend no more than an hour per asset. We're gonna employ you for two months, go and provide us complete coverage.

And they, they be in the Slack channel and they were interacting with my pen test team. And like, the results that came out of that were absolutely phenomenal. And like, that's an interesting way because I'm not limiting the pen tester, right? Go look at all these things for anything that you think is relevant. And it's, it's really interesting. So yeah, you gotta be clear about what you want.

Um, bringing it back, you know, off of the tangent, um, we're assuming that people want to engage in the pen test in this conversation. Talk to us about common resistance or challenges, um, that you may see once you're, you know, once people find out they're undergoing a pen test or, um, you know, just any sort of pushback you get from, from organizations that, that have to undergo or are undergoing pen tests. What are some some things you'd like MSPs to know about?

Yeah, I think that, um, a lot of the times we see the pushback it usually is because the penetration test is coming from the top and not from the IT team. And a lot of the times the IT team look at it like as it's a, a way of making them look bad.

So they're, you're going into there and you're utilizing this team to try to do an assessment and they're looking at you like in the emissary, you know, like, you're not the right guy that you're just gonna, you're just here to make me like get me fired or something like that. But ideally it's the complete opposite. Our goal is to help educate and help, uh, you know, align them to make them stronger, right?

Um, I think that's probably the biggest concept that we usually see where the issues come from for the most part. The other side of it is organizations will come in and maybe it's coming from the lower portion of the upper, uh, the, the, you know, the, the C-suite or so on are resistant to change.

So it's very hard to like make an additional changes and the, uh, IT team is like begging you to pretty much find glaring vulnerabilities on this network so they can walk in and say, see, this is why we need this funding. See, this is why these things need to change because they're not all aligned together. You know, a really strong mature customer has like a support from the top all the way down to the IT team.

And they all aligned to the same goal of protecting their users and protecting their information. So I think that, I think it's interesting though, probably from that perspective, you've probably been put in some very interesting situations where IT team comes and asks for the pen test, you're delivering it, but next thing you know, like they're maybe the MSP owner is showing up to the readout meeting and he is like, you know, what is this like, right. You know?

And so like the, the pen test isn't the curative results. The communication around the, what we're doing and why we're doing it that needs to happen. That the pen test is just an avenue to get like the insight you still need to do the change management around what to do with the results. And it's not the pen test firm's responsibility to, to affect that change for you. No, for sure.

And I think the, the best one we ever did was we had a customer who they were having a hard time getting, uh, permission from the top to do any kind of security assessments. So they got a little bit of funding and they asked us to do some small testing.

So essentially what we did is we did a spearfish engagement against the c-suite, and, uh, at the end of it, we came and did a presentation and presented all of our findings and during the presentations, like, and we were able to get into your inbox and we found your W2 and here it is and blah, you know, just show us from an outside perspective.

And, uh, it was interesting 'cause I was kind of concerned that the IT team wouldn't exist after that, but they all made it through and the, and the c-suites like, Hey, guess what guys? Everybody's gonna get put through the same testing, testing, we're gonna switch this, we're gonna fix it. And that really kind of woke everyone up and made them realize like, yeah, this is a problem that even we at the top are doing, so we gotta fix it. That's a great story.

Um, let's see, We got time Ryan, the bottom of the hour. So you got Some, yeah. Um, so let's say a company comes to you and they don't have a good idea of exactly what they want or why they wanna talk us through how you walk that organization through and understand their needs prior to engaging them. How do you make sure that, you know, if they don't have the best understanding that you're trying to provide them the best service that ultimately meets their needs?

Yeah, no, I think that really kind of drives a conversation, right? Uh, essentially, and not from a form getting on the phone, sitting down and just walking through each one of the topics and methodologies that exist. So it's like saying, okay, listen, you have a network and you want to get it tested, but you don't really know what part of the networks need to be tested.

And we'll walk 'em through and explain like, listen, these are the most essential pieces of the network that you should be testing. For example, the external is obviously your first bet. 'cause that's the, to the public web, anybody can touch it, right? So we wanna make sure it's locked down first. Any web applications you may be hosting, you may have a, a dev team or you have hired from a third party to assess, we want to test that as well.

'cause again, that's publicly available, you know, and then walk them through each piece of those and understand if they exist, if they need that, uh, that risk that assessed or not. And then talk about the internal network, talk about phishing and spearfishing and everything like that, that can exist out there because the user base is always gonna be an issue. So having a baseline of understanding where they exist, giving that educational piece and walking through those.

So ideally from top to bottom we kind of just look at overall topology, what they own, what they have, and try to walk them through what can actually happen, what we can do for them, and then let them decide and choose based upon what services they think is best fit for them. Yeah, that's, that's great.

As, as you were talking and I was listening to you, I was thinking this would've been a great time for, for us to have done a role play where, you know, one of us could have played the MSP, what we're concerned about and actually walk through a mini scoping conversation. Um, maybe if we have time at the end, we can do that. Think of Sure.

I think, I think it's a great exercise, Ryan, and, and Gary, maybe I, if I could just ask this, when you look at the first poll result, you know, our MSP has had a third party pen test, um, you know, 35% Yes. 65. No. Um, any comment on that? You know, and, and as you're coaching, again, bunches of MSPs each and each and every day. Listen for 90 weeks now, right? One, there's been a couple common themes, but the first one is get your house in order, right?

So it's one thing if you're not to the point where you're doing some of these things for all your customers, I get it, man, this is a heavy lift. We gotta, we gotta be moving in the right direction. But if you're not doing some of these things and pen testing's only one of 'em, we put polls up every week and, and Andrew, the percentages are pretty similar, you know, give or take right? On all the topics that we're at. And so, um, yeah, you gotta do all these things for yourself.

You gotta understand what the expense, the time, the effort is in order to get your vulnera vulnerability management in place based on that. Or you'll never be able to help a customer with it or understand how to approach it, how to price it, any of that. Yeah. But you, uh, just maybe closing comment, Gary, on a positive for everybody on the call, you know, you were presenting to a group of MSPs. I I was reading your blog not too long ago in Philly. Yeah.

Uh, can you give the positive side of the MSPs on the cyber call? Yeah. So what I would say is, um, I, you know, I spend so much time here with the people that are, you know, that are in chat and, and, and write a boom. And that's how we kind of gauge the work we have to do, right? And we're hard on people tell 'em they gotta do more, but then I go out into the regular MSP world and I see that most of them, they don't even know what I'm talking about, right? They don't know the basics.

So I think everybody here in our community can, no matter how much work they have to do, can feel really good and see as an opportunity about where you're positioned, right? Relative to most MSPs, the majority, the higher majority out there doesn't bode well. It bode well, it bodes well for the people on this call. Doesn't bode that well for SMBs right now, but hopefully over time we're gonna move it in the right direction. Yeah. Brian, you got any others?

Um, no, I think I'll yield to Wes and let's see if we have some time at the end. Uh, yeah, I, I thought, I thought Joe's um, comment was interesting. Yeah. You're talking About the most recent one that's there. Yeah, it is it in, yeah, it is interesting because, you know, I was thinking about the same thing of like, how do you message through something like that?

And, you know, I, you guys know, I typically been towards medical analogies and I, I think, you know, if I had some kind of like very concerning medical procedure that needed to be done, that it's potentially life threatening or at least debilitating. If it's done wrong, I'm not gonna go to a doctor down the street. I'm gonna find the most qualified best that I can.

But in order to do that there, you really need to paint the picture and help them understand I have stage four cancer or whatever it is that, that causes the need for that, right? And so I think there are things that MSPs need to be working on to like constantly be able to assess and show the need of why a PIN test is important.

Um, that way you don't come in looking like it's snake oil because I could understand a client coming back thinking, well, wait, I've been paying you for years to do this it stuff for me, and now you want me to pay so that I can understand if you've done something wrong that like some bad guy's gonna find a way in, it just doesn't add up for me. I could see, I could see a client thinking that way.

If we're not going down the journey of really communicating a messaging value, Isn't there also a hidden argument in here about customer zero again, right? If you're, if, if you are pen testing yourself and you are treating yourself with the same set of tools and processes and practices as your customers, that pen test has a, a, uh, I call it security assurance. It assures the security of both your MSP and your customers. So Gary said, get your house in order, right?

Because eventually that's the stack you're gonna be delivering to your customers. You know, if, if you're trying to convince them to do a pen test because they have something different than you, then, then you might wanna rethink that. Um, uh, you know, that you might wanna just, yeah, you might wanna rethink that and that thought process and, and how you're ultimately what you're trying to deliver, uh, to them.

Because yeah, I mean, if you, to them, it's like, well, yeah, you should be delivering me a secure service. But again, I think this also goes back to they don't understand always what you're providing them. Like you could say, yes, I might be the Super Bowl, you know, I, I might be in contention for the Super Bowl, but I'm, I play on defense. I don't play on offense. I'm not Tom Brady, right? You need Tom Brady to, to test your defense.

And so like, we're the defense, we're gonna defend you as best we can, but every once in a while we need to go up against the best quarterback in the league in order to determine that our defense is as strong as we actually think it is. And like, I think there's an education piece there about, again, what are you actually providing them and what additional things do they need to do outside of that core service to provide that, that safety there. I'm sure someone's gonna take Gary.

I, I, I got Gary. I was gonna say, that's a great analogy and it's much kinder than the one that I was gonna use, which is, Hey, Mr. Customer, we're barely a good MSP. You expect us to be a great pen tester too. Yeah. Go Ryan, I'm gonna go with yours in the future. Even one of my favorite movies. Um, that's a great analogy of that, right? Uh, catch me if you can. Frank Agna is such a good physical example of that, right?

I mean, FBI's trying to understand how ke uh, check fronting and cashing and kiting works. Yeah. Go hire somebody that's done this right, that understands how we get past all of this. I think there's value in, in, there's a lot of analogies we can point to. Um, and on the hills of that, uh, I got Eric, I got a question for You last thing on that before you move on. Yeah, please. We have time. Um, with this, this is important.

Like we have to get our talk track down so that when we're presented with these, they're not objections. We turn them around to educate customers more about their security journey and the shared risk. So view them as opportunities. They might not seem that way until you have the right perspective and talk track on them, but once you do, they're positives. Yep. That's good. Alright, so here's my deal with pin testers in PIN testing firms. We've hinted at this through the conversation.

You know, we have a word problem. The vernacular that we use is not always the same. Um, there, so John Strand, like 10 years ago, I wanna paste two links here. One's from like way back in 2013. So this is like now a decade old. They're getting ready to be, uh, coined to my knowledge. He coined the term PIN test puppy mill. Um, and I've seen these, uh, at the bank. We had a PIN test, puppy mill that came in. They, they wanted us to drop their black box into the network.

They wanted all shields down. Um, and then they just ran a bunch of automated tools and we were using Splunk at the time. We're just sitting there watching the logs, just watching what they're doing and they're running like their in map. Then they switched, like they were just doing basic things. It wasn't special. The results that came back, nothing was really actually tested. They, they pivoted off nothing that they found as far as results.

And I'm like, guys, this is not what you pitched to us and we never used them again. We had a real problem with that, right? And, um, I think we have a real problem as a whole with like pin test puppy meals. And so I guess my question for you, Eric, if you're sitting on my side of the fence or an MSP side of the fence, what questions are you gonna ask to really understand the quality and capability of this potential, um, firm and the engagement itself? Yeah, so those are really good questions.

'cause I mean, everyone's probably tired of getting a vulnerability scan as a report, right? Um, which really doesn't mean anything to anybody. Um, 90% of it's false positives or, uh, there's no proof of concepts that can need be taken advantage of. So ideally on our side of the fence, what we look at is we want to understand what's your real methodology? What do you plan to do when you're on the inside of the network?

How do you plan to test for said things such as, you know, do have SMB shares that are unauthorized. Do I have users with excess permissions that they should not? Can you move, move laterally? Can you scrape credentials from memory? Can you steal and harvest the information from our users? Things like that, right? Um, so one of the ways that I usually test this out is I ask for deliverable.

I wanna see what you're gonna produce to me in the beginning, gimme a sample document so I can kind of root this out. Are you a CPA firm that just decided to buy tenable and decided to run it through, right? Or are you somebody that actually knows how to do these assessments? What's your background? Gimme a few different, uh, gimme a few different references of people that you've tested through.

So I can ask them to see, you know, follow up with those individuals and how well you perform this assessment. You know, give me, um, an understanding so I can do my own due diligence on yours. Like kind of like you're doing a background check for an employee, right? You're kind of doing the same thing with the pen tester because essentially you're giving them a lot more control than you would give a normal employee on your network.

Um, and the goal realistically is to provide back proof that, hey, listen, these are the problems you have, these are the gaps and the issues that exist and these are how we're gonna fix them together. Okay. So, so you feel like, um, one of the things I wanted to call out from what you said you feel like looking at sample reports and like sample output that they produced in the past is a good indicator of like the quality of what they can do.

You can definitely see from a manual perspective, like are they actually giving artifacts of the actual attack vectors they're going through? Are they labeling the kill chain of how they gained from A to B, right? Are they providing you reference intelligence of, hey, I was able to compromise that device, I gained unauthorized access, I scraped the credentials from it, I found a user's account which led me to a curb roast account or led me to using a bloodhound or active directory or so on.

And it explains from top to bottom what you can do with those assessments. So if that is missing inside of there, then you assume that that person might not have as good of a manual approach as the others, and then that might take the real pin test away and it looks more automated. So obviously a pin test is as much, um, science as it is art. I mean, there is an art to this for sure, for sure.

Do you guys though have, like if I were engaging with you guys, Eric, do you have like a SOP that you could send me? I'm not asking for, but do you have like a, like this is the science that we use, these are like you, you mentioned bloodhound, kose, these are the tools that we typically use and the SOP that we have as we go through a standardized test and then we pivot off of course, depending on what we're finding and seeing.

Do you guys have like documentation on that that you could send to a client too? Is that common by a good PIN testing firm? Yeah, I mean, it's pretty laid out in our statement of work that we provide individuals. It walks through all the assessments, it actually ties everything back to the MITRE framework, to each attack vector that we're gonna perform from the internal.

It talks about how we do our assessments from three different perspectives, from a blind not having any information from a user perspective, and then from a domain administrative perspective to provide patch audit. Um, essentially it gives a list of, uh, the attack vectors, the things that are gonna be looked at, the ttts that are gonna exist and that we're gonna go against. So it already kind of explains it all within our statement of work through the policies.

But obviously every pen test, like you said, is an art form, but it's always, it can go astray, right? You don't always know what you're gonna come across. So you always have to have that open mind to wanna continue to breach further or go farther, you know, oh, I found that I found that device that was wide open and oh look, it's providing updates to computers. Maybe I can compromise that update and then compromise the other computers from that perspective, right? So Yeah. Okay.

You Know, uh, I was gonna say, good comment by Keith saying we're talking a lot of tech here. Um, and why would a client care about that? No, an MSP would, it's our job to decide with each of our clients how to translate that. In some cases it's a little more technical and in other cases, many cases it's not technical at all. That's what we get paid to do. Like that's the job, right?

Is to be able to take that and have them understand it in a way so they can make business decisions No different that you're not gonna wesh you were not having, uh, this conversation with the board at the bank, right? You had to translate it Ab Yeah, ab absolutely. And I was curious, Eric, if you could do that for us.

Can you, and you may not typically do it, so this may be outta your wheelhouse a little bit, but can you do an explain like, I'm five, like using non-technical terms of the value of what a PIN test provides? Like pretend I'm not technical at all And can say something, Eric, real quick, because Wes, when you were at perched, I think you guys did a masterful job on the home alarm analogy.

For example, Eric, I'll just give you like, you know, like what's sim Well, you know, it's a like, hey, do you have a DVR? Do you have a video camera so that if some bad guy got in, I could go back and look at it. So that, that is it. I just wanted to kind of translate like mm-Hmm, what Gary was saying, what Keith mentioned back over to you. Uh, if that makes some sense. No, it makes complete sense. And I usually try to use some analogy that would help, uh, speak to a customer and so on.

So for example, I would talk to 'em as if I was using a house as my analogy, right? And I'm saying if I wanna do an external assessment for you, imagine that your house is locked from all the doors, you have all the windows, these are all your, your ips are services that are open. Each window represents a service, each door represents a service. And if it's not locked accordingly, if it's left open, that allows someone inside the house and that inside house is now your internal network, right?

Um, the goal there is then to test if someone gets into the internal network, do I have doors that prevent them continuing to go into the dining room? Do I have doors to continue to prevent them to go to the living room? The segmentation is where that exists. So we wanna make sure that if an attacker was unfortunately able to compromise the network and gain unauthorized access, that they would only be able to land in one room and not be able to pivot and go into any other room.

So then at that point, we look at the external, we look at the services that exist there, we make sure they're strong, they're secure, make sure that someone can't gain access to them. And then we come on the inside of your house, we look at each one of those rooms and make sure they're all locked down so that way they can't continue to find the safe or any other jewels that might exist. Good stuff. I like it. Yeah, really good. Yeah. We all love a good art heist movie, right? Oh Yeah.

And everyone, everyone can relate to it, right? Yeah. I mean, the best one I ever saw was, I think it was on, uh, HDTV where the guy actually broke into people's homes. I don't know if that was a while back or not, but the individual was hired, he was actually like a thief and he was hired by these company, these people that said, you can never break into my house. And they disappear. He'd bring a moving truck in, he'd climbed the window, he'd smashed the house, he smashed everything.

And people would walk in like shock and awe, like, you just destroyed everything I own. He's like, I had to do that to make you feel this awareness, so that way you'll fix it. Interesting. I like it. Uh, okay, so let's shift gears a little bit and, um, the MSP space as a whole is not ready for red teaming in terms of like supporting and building out a crew of people that are gonna be doing red teaming.

Um, but they do expect, um, their vendors are doing this and they expect that, um, at some point they may have to get engaged in this and even understand at what point do regulations force us into even like red team as a service, uh, that we offer clients, that sort of thing. So can you sort of like describe what that Venn diagram is between PIN testing and red team and even like, if you wanna get into purple team, you can too.

Like is it, are all pen testers, red teamers are all red teamers pen testing? What's the dichotomy here between the, the two? I wouldn't say that every pen tester is a red teamer and every pen test, uh, every red teamer is a pen tester. I think essentially it goes into a methodology and a way of performing assessments. Um, a red team assessment realistically is, uh, object based, right? I'm trying to get in. Um, that's the goal here.

And really it's a testing, a network or, uh, organization that they're cybersecurity posture is very mature. They have, uh, you know, implementation in place that it helps prevent them against, uh, Onfi access. They have a, you know, possibly, um, any kind of monitoring solutions that can help them detect these attacks and traffics. They might have advanced endpoint protection, things like that. So now they want to know, okay, hey, we have everything in place.

How do we stand up if an attacker really did it? So here we are not, we're not gonna give you any information. You're gonna just go out, you're gonna heavily recon our environments. You're gonna heavily recon our, you know, information. You're gonna see if you can attack us and gain unauthorized access, and then show us the weaknesses that allowed that. And then also, did we capture those? Are we able to see that? How did our team stand up when it actually came out?

And what, what processes did we follow? So that's where the red team comes in place. When it comes from a, a purple team perspective, that's where you take the red team and the blue team and you put 'em together, right? The purple teams, um, to develop a, uh, pretty much a very commutative, uh, assessment. And the goal is to, I'm gonna perform an attack such as, say, just even do our ransomware simulation.

And as I unfold my attack at that time, the, uh, blue team's gonna be monitoring their controls. And I'm saying, I don't see that, or I do see that it's working like it's supposed to. Let's move on. And we're gonna continue to document each one of those controls that should be working correctly and allow them to adjust so that way they can fix each one along along the way on the path. Okay. Okay.

Yeah, that, that's helpful on the, the difference, because I still think we're gonna see a lot of confusion there. Um, last question before you, before we turn over to, um, some role play is Joe asked this question in chat is, is let's talk about cloud environments, right? As we've moved completely as many organizations, you know, are, are completely dumping all things OnPrem, obviously that changes the mechanics and it forces you to learn the world of A-P-I-A-P-I security.

Um, but, but you know, even the nature of infrastructure and platform as a service, you know, how do you test against those things? How do things pivot and change there in those kinds of engagements? And where do you see that world going, um, from the cloud perspective? Yeah, it's, it's interesting. You know, probably like three years ago, you couldn't really test infrastructure in the cloud without being the actual, you know, written permissions in the beginning, right?

So Azure, AWS, these, uh, these infrastructures that they set up, you, you purchase a server and everything else, and then you had to get written permission to do penetration testing, but now they've pretty much ruled all that out. You don't need any permission at all. So that really, the reside, it's a lot of people may be confused and understanding of, okay, I've just uploaded a bunch of stuff to the cloud.

Now I've shored that risk to the cloud provider, but it's actually my environment still. I have to manage the security zones, I have to manage multifactor authentication and make sure people stay out of it, restrict the access to those IP addresses so individuals can't gain access to my sensitive information. And, uh, you know, the problem is, I think when it comes down to it, people have to understand, okay, what do you have in the cloud that you're offering? Is it an application product?

Do I have multiple backends? Do I have APIs, soap based or rest based? Um, what kind of application are we testing? Is it a server, is it infrastructure that's just tied back there? Are we just looking for purely, uh, software? Right? And then that is where those, um, you know, those, uh, I guess those lines of operation reside, right? To make sure that everybody follows the necessary protocols and best practices in order to make sure each piece is secure. Okay.

And I posted a couple links in chat on these shared responsibility models. Um, all good cloud organizations need to have these, they they very good way to properly disclose exactly what the requirements are between you as the vendor and the client. Um, so that's good. You need to check those things out and ask anyone, um, for access to those if you don't see them. All right. So let's jump into role play. Andrew. I don't know how you wanna handle this. Yeah. Well, I'm gonna come back to Ryan.

Ryan, do you have any, uh, any thoughts on how we might wanna structure this and or How, I mean, so I was in my head, it's like a, it's a volley rate. So what I was thinking is, you know, as an MSP, assuming I was an MSP, there's probably a few things I'm concerned about. I'm concerned about my tech stack being weaponized against me and my customers.

I'm concerned that there might be vulnerabilities that are, um, that exist in my tech stack that I'm unaware of, that are attractive to current threat actors that are targeting MSPs. Um, and I'm concerned about the effectiveness of my existing controls, and I want a pen test, and I want the pen test to make me be able to sleep better at night for all three of those things. What are you gonna be able to do for me? Let's, let's say I wanna pay you for a week.

What can you do for me in a week to help me become comfortable with those three things that I want, that I want to be more comfortable with? Okay, so, um, when we talk about time-based and everything else, the goal really is to review each one of the top apologies. So my, my recommendation is we start off with the most secure, uh, the most sensitive platform.

So we're look at your external network and depending on the size, um, of how big it is and how much, you know, how much information you have available out there, that's really can drive the conversation how long it takes, right? Um, good pen testing company understands exactly, you know, each level of service has to be vetted, viewed. You may come across a, an IP address that has like a 4 0 4 error or something else, but there's another service may just not mapped correctly, hidden to it.

And you can't just move on. You gotta keep on looking, keep on digging deeper, right? Um, so the goal is to look at each one of those, determine exactly what exists publicly, make sure we bring it forward so that way you understand exactly what unnecessary services are available so we can close those down and clean it up. So that helps protect you from the outside person looking in, right?

Do we have unauthorized remote access portal with our remote services that allow like RDP access into the network? Are we utilizing multifactor authentication to help protect ourselves from our users? Um, those are the biggest threats that keep everybody awake at night, right? Because our users are our worst nightmare. Um, so we need to educate against them. Unfortunately, it is what it is. And if we don't educate them, we're just waiting for a fall.

You can put millions of dollars in place in cybersecurity, in anything in, and they're, and it's not gonna help stop the user from obviously defeating the perimeter, defeating the security controls. Um, I have people who call me up all the time, say, Hey, listen, well, we got two factor in place. We're good. No you're not. Watch, I'll set up an online portal.

I'll call that user up and say, Hey listen, I need you to log into my portal and give me the credentials to do so now I have them log into theirs and they push me through the multifactor. Now I just came to access to the account, right? And it happens all the time. You know, it's just when there's a will, there's a way. So we give that education to the user and make sure that they're aware, we walk them through best practices, how to be smart.

You're not gonna throw your 12-year-old the keys to the car and say, Hey, go to the gas store and get me a gallon of milk, right? Because they're driving down the road. They're not only danger to themselves, but everybody out there. Um, so we wanna make sure, Just to recap, I'm hearing you say we're gonna assess your external attack surface. Yep.

Um, determine if there's any, you know, major issues, well known vulnerabilities, um, you know, anything that might, might, might give a foothold into your environment. There's, sounds like there's a social engineering aspect of this too. How do you go about addressing the, I'm worried about my tech stack being weaponized against me. Question. Um, well that's, that's a really tough one because essentially the goal is to examine the service overall.

Um, making sure that it's solid locked down, making sure there's no author unauthorized access allowed to it. Um, we're gonna review the service, making sure that there's no vulnerabilities that exists, not only from that, but also from the actual hosting device, right? 'cause if I can gain on there access to it and admin, I can do whatever I want to it.

And then from there, we're gonna continue to keep reviewing, uh, from an outside perspective, what could be the, the island hopper that allows us to jump in? Can we find information on the network that can allow us to compromise that device lateral move and compromise further device and then laterally move and compromise all device, right? So the goal is to literally give you the understanding of each attack vector that exists on the network.

Make sure you understand how they exist, how they occur, how far they can pivot into the network, and how to lock down each one of the kill chains. Okay. This is really good, Andrew. Hey, well Ryan, I think I appreciate you coming up with the role play. I appreciate Eric, Eric kind of chiming in there. I think, you know, Ryan, any kind of closing thoughts there? You know, it's, it's a living, the RMM is like a living off the land kind, uh, very deadly device that the MSP possesses.

So, um, anything you'd wanna add, Ryan, if you were the pen test firm? Yeah. Like what would you I mean, I Think, yeah, to that end, like a pen test company might shy away from wanting to pen test specific technologies that you use. Um, you know, there's, there's some, there's some challenges that can come up with that, but what they can do is, you know, they can look at whether or not the configuration that you have of those tools in your environment opens you to risk. Hmm.

And I think that that's where the value of a pen test is because I, you know, outside of kind of, you know, the, the well-known supply chain attacks, a lot of the issues have around MSP technology being misused has been configuration. Yeah. And so the pen test can uncover a lot of that stuff. And a lot of that has to do with identity and access management and like all that stuff, you know, would, would, would be covered under a pen test that is scoped appropriately to consider those things.

Um, so you definitely need to make sure that, again, you have those, what do I wanna get outta that? You know, if you have those three things like I brought up, that's gonna facilitate a better conversation than like, I'm worried that I'm gonna get hacked.

Okay, well, we'll do a pen test for you and we'll, we'll tell you, you know, we'll tell if you, we will tell you if we can, can hack you, but again, it's only a week long and what did they do and why did they do it and how did they orient that towards your actual risk? You need to have a broader conversation That, that's awesome.

And, and, um, boy, I I, I'll put the link out there, but man, if you haven't seen the latest, this is, they're on their second version now, CI s's community defense model. Ryan, I'm so glad you brought up secure configuration because it, you know, if you, that is the number one thing to defend against most, uh, if you look at Mitre and which they map to, um, that is going to mitigate the largest number of sub attacks out there. So, um, really good stuff.

Gary, any closing comments before we thank Eric for, uh, his time and, and coming on? No, just that, um, what's great is every week I think we're all building more perspective as MSPs of what we need to do, where we need, what we need to aspire to. And as we do that and start to make more progress, um, again, you always hear me say this is not only the right thing security wise, but if you understand how to show customers value, it's a great business decision. Yeah, good stuff.

Wes, closing thoughts? I put you on mute, huh? Okay, you're on mute there. Alright, no worries. Ryan, any thoughts from you as we close out here? I'm good, thanks as always. Looking forward to week 91. Yeah, absolutely. And, uh, in terms of week 91, again, I will iterate, tell your vendors to show up to the cyber call next week. You, they will not be disappointed. Uh, Jim Manco, tell him to look 'em up. Um, Eric, um, closing comments from you. Thank you so much for coming on. Thank James.

Uh, I put your URL in the bottom there if anybody wants to learn more about hack at cyber. Uh, Eric, thoughts? No. Awesome. I really appreciate the opportunity, uh, the platform to speak about penetration testing, kind of bust through some of these myths that organizations have and the, you know, the terminology. I, I think that we constantly are gonna continue to run into, like Wes said, these, uh, these issues with language barriers and understanding exactly what individuals need and want.

Um, so hopefully with a good pen testing company, you know, if you guys ever need anything, let us know. But we're happy to definitely sit down and walk through and try to, you know, spell outside the box and break it down, you know, that fifth grade style to make sure everybody knows exactly what they need, what they want, and to get the best value, as Gary said, uh, out of the assessment, right?

Because as long as the alignment's all the same, everybody aligns to that one goal of helping sharpen each other and make a better network for each person. That's, that's really the main goal of this assessment, keeping people out of the news. Excellent point. Alright, so we'll look forward to seeing everybody next week for week 91. Until then, make it a great day. Thanks Everyone. Thank you.