Watch to learn why and when you need to perform an internal penetration test and how to improve your internal network security.
Watch James Farnsworth (Senior Penetration Tester) and Garrett Adler (Senior Penetration Tester) discuss:
This webinar was held on August 25, 2023.
Hello, and welcome to the webinar today. I'm James Farnsworth. I'm senior pen tester at at SecurityMetrics.
I'm joined by Garrett Adler, who's also a senior pen tester at Security Metrics. Just as a reminder to everybody, this webinar is being recorded. So if you have questions, you can still submit them, and we will be sending out, a a recording of it so that you can view it whenever you'd like to so you can go back and look at the content and find pieces that are important to you and applicable to you. Today, we'll be talking about internal penetration tests. There are several different types of tests that we talk about.
We won't be talking about those ones specifically, but we will be talking about internal penetration tests, why they're important, how we help you with them, some tips about how you can prepare for those, and then also just some general security advice for if you're not doing a pen test, how you can still harden your internal network to make sure that you're secure. Garrett, thanks for joining, and, let's just get started. So I think a really good place to start when we talk about internals in general is basically, like, what's the impact. And, obviously, there's, like, pretty big deal with a lot of things happening in the industry that lead to ransomware. Like, almost anytime you have ransomware, you're gonna have somebody with internal access to your network. So when I say, like, impact, like, what are some some really big industry things that have happened when you think of internals that have impacted businesses?
Yeah. I mean, if you just look at, like, recent news about breaches or ransomware operations, you see a lot of big names. And all of them come from an attacker who breached the internal network and then escalated privileges, which is exactly what we do on an internal pentest. We just skip that breach the perimeter part and aid you in showing up your internal defenses.
Yeah. Like and it and it's when I think about, like, internals especially, and I think about, like, ransomware and, like, impact, like, what does that do to, like, my business? I think about, like, the really, really, really big ones, like the Colonial Pipeline where it was, like, all of a sudden, something that we needed for, like, gas and, like, making sure that our physical infrastructure working didn't work. And I know that's, like, kind of older.
WannaCry also is, like, one that, like, everybody, like, beats their drum about. But, like, that one for me, especially when it's, like, why is it why are internals important? It's because, like, for your business, it hurts reputation or it hurts, like, your bottom line because you can't deliver services, so you're out or, like, any of these other things, loss of, like, personal information for your customers, loss of, like, your proprietary information, or even, like, if you're in a sector where you would deal with, like, hospital or, like, infrastructure, like, that type of stuff also is something I think about.
Yeah. Totally. I mean, you mentioned a lot of, like, operational technology environments and the the devastation that that can cause. I mean, if if a gate that controls the flow of water stopped controlling the flow of water, that's a environmental disaster.
Yeah. Yeah.
And the thing that I think is funny is, like, you kinda hit on it as well where it's like, how what's, like, the general flow where we get initial access? We move around laterally, and then we escalate our privileges, those kinds of things. And I think that, like, obviously, like, in our pen tests, we're not gonna be doing any of that stuff where it's like, hey. Like, we shut down or, like, we leaked information.
And so when I think about it, it's good to know that that stuff happens, like, in the news, but I'm also interested, like because when you started talking about it, you started talking about this is a procedure we would go through. And so I'm also interested where it's like, if I'm somebody listening or, like, I hear news, I'm like, that's great. That's not me. How is it applicable to me? And so I'm pretty interested in, like, what are some things that you've actually done on tests where, like, that impact has happened or where, like, you've provided value to a customer based off of, like, an internal?
And so yeah. I mean, when we look at, like, pen tests that we've done in the past, like, when we're considering how do we add value to these maybe smaller businesses, not the ones that you're seeing in the news every day, but the ones that are potentially listening to this this webinar, we can definitely add value by finding vulnerabilities, say, you know, an insider threat or just a a insider attacker or not even an insider attacker, but just a person in your organization that's just looking around. It's often that we find, you know, sensitive information just in places it shouldn't be, And that's easy to stumble upon and could have very large implications if the wrong person were to stumble upon it. Or take it a step farther and you actually have a malicious user or an attacker who has breached your perimeter, we will identify routes to go from an unauthenticated user on your network to total domain compromise. They own everything that is inside your internal network.
Just an example is we did a phishing engagement recently and harvested a bunch of credentials. And once we logged in their VPN, we found no multifactor. That's that's an issue that a lot of people who aren't security minded are probably not that concerned about. Even though you hear in the news, like, enable multifactor.
Maybe you don't. And then because there's no multifactor, we're able to find a very quick escalation vector that took us from an unauthenticated person sending an email to the admin over every machine in their entire organization. That's it's really easy. It's really bad, and it's really easy to find value in what we did there.
Yeah. And one thing that I like that you talked about was also you're, like, things that just, like, shouldn't be there. And one thing that I thought of while you're talking about was literally just browsing to, like, an internal application and then seeing clear text username passwords for a SQL instance, authenticating to the SQL instance, and then leaking credentials out so that you could get access to pretty much the entire network. So when you were like, that wasn't even complex.
We didn't fish anybody. We didn't interact with anybody, and it was just something really, really simple that we found that had huge impact. Right? And so I think you hit on one of the the things that's really cool where it's like, how does this apply to me?
Where sometimes on the internal network, because they can be really, really big, and you may have, like, reduced manpower or maybe not enough, like, budget to, like, justify spend or different things like that that it's it's just good to know what's going on. And as you do internals, like, that helps you understand, like, what's going on. Other than that, like, you had mentioned fishing. We had found those credentials.
Like, is there another standout? Like, man, like, I really enjoyed that internal, and why did you enjoy it?
Yeah. Well, I'm sort of thinking about, like we gave, like, a really, like, easy example. There's probably people listening to this right now who are like, well, that's insane. Like, we have multifactor.
We must be good. And so, like, another example is, like, we were doing a test for a customer who had you know, they were doing a really good job that we were having a really hard time escalating, like, even getting our foothold. And then we found one overprivileged account, which is logging into a Linux machine on a timed basis and leaving Kerberos or, yeah, Kerberos tickets there and reuse them and escalate our privileges. And it was, like, really great because it was still a viable attack vector.
And it just you know, it it took us time because they were following best practices on the really easy stuff that you identify in your first name first year of penetration testing. And it took, like, another year of improving their security and testing. Improving their security and testing, repeating that process to really flush out all of these attack vectors.
Yeah. It and I think that's really cool because the one of the cool things is all of it applies to your environment. Because when you hear those stories in the news, you're like, well, how does that apply to my environment? And so even when that one you were talking about where it was, like, super locked down, we're doing all the right things, there's still things that you may not be aware of that could lead to that.
And then you'll notice that, like, a lot of the conversation we've had has been very, very, like, Windows heavy. And so as I'm thinking about that, internals in a Linux environment or, like, maybe you're a dev shop and you're doing like, you're not using, like, active directory as heavily, so pivoting in your environment isn't as easy.
I think of one of the one of the internals that I really enjoyed in, like, an in internal was they had an app that everybody was using and doing discovery on that to figure out that they had unauthenticated endpoints that you could use, just those requests, and then injecting and doing SQL injection and then dumping their entire database and being able to exfiltrate that information and all of the sensitive information that was in that because it was, like, one of their main internal tools. So even if it's just Linux and it's not Windows, it still is super, super important. I know we have, like, a lot of Windows stories, but it's because when you get domain administrator, it's it's pretty exciting. But also in a Linux environment, if you do that, you get access. You can also escalate privileges and and dump those hashes from, like, Etsy password, Etsy shadow, crack them, and still relay and still do a bunch of stuff through SSH. So you're just using different protocols.
So I just wanted to point that out that it's not just Windows environments that are that it's good to do them in. It's also, like, these development environments where maybe we're using SSH or different things like that and interacting with the cloud more and using API keys. Like, the lateral movement still works there. The escalation of privileges still works there. The remote code execution, all of that stuff is still very applicable. It just renders a little differently.
Yeah. I'm glad you mentioned that because, like, you know, like you said, getting domain administrator, it is awesome. It feels great. But often, it's not the biggest concern for a customer. Biggest concern might be a data breach or, you know, these crown whatever they consider their crown jewels being compromised. And just like you said, like, if we're able to get SQL injection on your main internal application and retrieve all of this stuff out of it, like, that could be your crown jewels. That could be the thing that provides value to you as an organization.
Yeah. And that and that, like, that's super true because, like, also, like, if you think about it, you're getting access onto that internal node that has, like, a cloud environment, like, all that metadata that's kept in, like, environment variables and everything like that. So I like how you tied that in. So as you think about what brings, like, value, like, if you had to suggest, like, something to prepare for an internal or if you had to just be like, okay. Like, here's some, like, five valuable things that you can do.
What would they be?
So, yeah, five takeaways for securing your internal network. I'd say communicate, the job roles that are in charge of managing that internal network.
Make sure that you know of all the assets that are included inside your your internal network. Make sure you know what's exposed, what access, people have, what what roles should and should not be able to access, what your assets.
Make sure you actually understand your network topology and what systems are talking to what other systems and whether or not they should be or, what, you know, should be segmented, where your crown jewels are. Make sure that access to those is really limited.
And, you know, just on that, access topic, make sure you know, like, what your roles are within your organization and that you on you have an access control matrix in place that is doing, like, resource based access control and is enforcing their, the least privileged policy so that employees and users within your organization have the least amount of privileges necessary to perform their job.
And then this is sort of a a repeatable process, but verify and test your biases and make sure that, you know, frequently, you are looking at what's inside your network, looking at resources and roles and assets and make sure that you're consistently validating that, nothing is overprivileged or overexposed.
Cool. So I'm just gonna restate to you because it's it can be easy to get lost in some stuff because, obviously, there's a lot of really good content there. So, basically, the first one is just communicate with the people who are in charge of or accountable for, like, the systems in your network and your network.
Second one is, like, have an asset inventory. Basically, knowing what computers are in there, what their purposes are, how old they are, that type of stuff. Then the next thing is actually know how they talk to each other with, like, a network diagram. What subnets do you have?
What control rules should you have for, like, firewalls, what computers should be able to talk to other con computers. So, basically, understanding how it's networked.
The next one is basically knowing what job roles are accessing your assets and your network, and then basically knowing what those job roles should have access to. And then the last one being, like, actually make sure that that stuff is happening. Because, like, if you're not actually making sure that's happening and it's on a diagram somewhere and you're not actively like, hey. Can this person actually talk to this?
And verifying those rules, it's really hard to know what's going on. When I think about that, one of the things that I thought was interesting is if you would loop back to the stories that we talked about, we had talked about, like, most of the ways that we got in there was because somebody didn't verify or test of bias, where it was, like, with the SQL injection that we did. They didn't know that you could discover unauthenticated endpoints. Or even if you like the SQL credentials that we found, they didn't know that that web app had those credentials out there.
So when you think about those five internal suggestions that we have where it's like you can harden your network by doing those, How can we help with that when we do internal security testing?
Yeah. I think that when we are tasked with doing an internal penetration test, we're there to validate that all of those tips for securing your internal network are in place and that they're in place throughout.
You know, like we mentioned in our stories, we we have customers where we do pen test year after year after year. We we give them advice on how to secure their internal network. They make the changes.
And then maybe the next year, we come back in and the network technology has changed. And they're like, oh, yeah. We followed your best practice from last year. Well, we're there to validate that.
And often, something fell through the cracks. Interals are our networks are large and complicated, and it's often more than one person involved in that in in setting up that infrastructure. And, you know, we're humans. We make mistakes.
Things happen. We're just there to make sure that an attacker doesn't find that and exploit it.
Yeah. And I really like that because, like, as you were talking as well, I think it's not just, like, testing and validating those biases, but a lot of it is also discovery. Like, a very big part of what we do is just figuring out what's going on, understanding how things work, understanding why they look the way they look. And when you were talking about that, I thought of one of the other tests that we were doing where you had hit a host, and we were talk and you compromised the host.
And the guy was like, like, oh, I didn't even know that that thing was on my network, and it was, like, the foothold to start doing stuff. And so it's really cool because, like, that's that's, like, some of the value that comes there. And as I think about that, like like, a lot of what we've been talking about is very, like, exploitation heavy. Like, we were able to do this or we were able to do that.
But a lot of, like, verifying testing biases as well means that, like, they're true positives as well where you think your network is doing something, you've segmented it, or, like, you only have these types of assets on there.
But, like, it's a good thing when we don't find anything. And so just to be clear, like, when we do pen tests, we're not always, like, a successful pen test isn't based off of, like, oh, man, we were able to own that system, or we were able to do this. Like, it is so comforting to being able to tell people, like, no, you did a good job. You're like, what you thought was actually happening is what was actually happening.
And some of my favorite tests are actually when I get to talk to people who are, like, super engaged in what they're doing, and they go, yeah, this is what I think. And I get to talk to them and say, okay, this is what I saw, and it totally matches. And just be like, hey, good job. Because people get pen tests sometimes just to, like, either show, like, hey.
I'm doing it or to get clout to be like, we need to be doing this.
So really cool. I I like that. I like what you had to say.
Yeah. Success does not come from, like, owning an organization. Like, success comes from finding value and give like, providing that value to the customer to make sure that they are secure. And I really agree with what you said. Like, a success is when a customer is happy and whether that means that there was no vulnerabilities and that they've done a really good job, that's awesome. Or if it means that they've found a bunch of vulnerabilities that they were worried about, and they can now secure those.
Like Yeah.
And and I like I I like that. And the reason I like that is because, like, one of the things that when we're doing pen tests, like, a big question is, like, how do I get the most out of my pen test? And I think going along with what you're saying, it's not a one size fits all where, like, some people get different value from what's going on. And some people, like, there are commonalities through them, but, like, it's a very individual process.
It should be very tailored to what your internal network looks like. So I think that's one really cool thing that you said where I'm like, you know what? That is really true because the customers where I'm like, that customer, I really feel like we provided a lot of value. I really feel like we did a good job was because the customer knew what they were coming into.
And and when I say coming into, like, they knew what they wanted out of it. Right? And so when we go along, one of the things that is a real focus for us is, like, objectives and having an objective when you do internal testing.
Can you talk to me a little bit about some common objectives or why you feel that's, like, important?
Yeah. I I love, like, when we're talking about scoping a pen test, asking the customer, what keeps you up at night? Like, what are you worried about? Because that gives us just a starting point.
You know? Obviously, with our pandas, we have our methodology. We have the things that we are going to look for every single time. But if you give us, like, I'm really worried about an attacker from whatever, a corporate network getting into our operational technology network.
I'm really worried about that because that would cause a ecological disaster if they could get in there and mess with stuff. Whatever.
That gives us perspective. We'd say, like, okay. We don't really care as much about getting domain admin anymore. We're not gonna try and escalate our privileges unless it means we can cross the the segmentation into this other environment. And it gives us, like, an end goal that's not just like, we're gonna find a bunch of vulnerabilities and potentially exploit them. It's like, we are going to either confirm or deny that you are losing sleep over a a realistic scenario.
Yep. And can you talk to me a little bit about, like, if if somebody's new, they've never done a pen test before, and they're really they know they need one either because of, like, compliance or regulation, governance risk, those types of things, and they just know they need one. And they may not have, like, very specific things. Can you talk to me about, like, how we help people with objectives or what we do in that scenario?
Yeah. I I think the situation you described where a person just they know they have a big internal network. They know that it's probably got vulnerabilities, and they just they they don't really know where to start, but they know that it should be secured.
I think an objective just helps sort of narrow it down because, like I said earlier, networks are huge, and there there's a lot of moving pieces. And if you're just like, hey. I just want you to find vulnerabilities. Like, it's gonna be overwhelming when we come back with this hundred page pen test report that's like, hey.
You said find vulnerabilities. Here's like Yep. Any but if we get them, you know, a set of objectives, like, you know, an attacker's probably gonna try to fish their way in and then escalate privileges. Like, if you want, we could look for, like like, ways to mitigate that privilege escalation vector that that's gonna stop people from accessing resources they shouldn't.
Or look for credentials in easy to access places. We're gonna try to harvest credentials anywhere we can or you know, just give them a way to, like, narrow their focus so that's a little less overwhelming.
Yeah. Like, very, very, very applicable.
And then also, since we're talking about, like, governance risk compliance, that type of stuff, obviously, like, we work for a PCI vendor, and so it's not uncommon to have PCI tests. And so when we do those ones specifically, like, we look for what you would have in, like, PCI. So if you're coming and you're like, man, I know I need to do it for PCI, and I and I'm I wanna be security focused, and I want, like, all this information, but I don't quite know how to phrase that. Generally, if we're doing like, if that's what's bringing you to come and take a pen test, like, we'll look at that and do it based off the data security standards.
So if we see something that isn't in line with the data security standards, we'll say, hey. Like, here's something to help help you. And that's coming back to, like, verifying tests and biases, those kinds of things. We also really focus on, like, can you find credit card information on those?
Because, obviously, with PCI, that's very, very, very huge thing. And then the last one, obviously, is your customer's PII.
Anytime you have that personally identifiable information out there, like, it's gonna be a big deal, and that's also something that those security standards focus on.
So just kind of like to wrap that up, like, it's good to come with an objective in mind even if you're coming because of compliance. Like, you're going to get out of it what you put into it. And the most satisfying the the test where I feel like we get the most out of it and our customers get the most out of it are the ones where we engage. We have an open discourse, and people are responsible and responsive and available. So if I'm a customer, and I'm like, okay. Now I've decided I I need a pen test for whatever's driving me, whatever, like, my objective is for doing that or whatever the primer was, whatever was keeping me up at night, What can people expect?
Like, what's the general process if somebody starts engaging with us to have a pen test?
Yeah.
So I think we're gonna get on a call Someone from our organization, maybe not James and I, but someone We handle all of them.
We do all of them.
Yep. I'm not promising you're gonna get us. Someone from our organization is gonna hop on a call, and we're gonna talk with you about, you know, what your concerns are, what you wanna get out of this, and then talk about what your network infrastructure looks like.
How big is your network? How many hosts do you expect? What kind of services? What kind of you know, what what architecture are you using? Is it a Windows Active Directory? Is it, like you mentioned earlier, a a dev shop that just uses Linux?
And we're gonna, you know, tailor our approach based on the answers to those questions.
I'm missing something. James, what am I missing?
Yeah. No. You've you're you're exactly right. And just to make it, like, a little more enumerated, you can base or, like, codify. I don't know. Basically state it a little more directly. You we'll have a call to define the scope, see what you need.
After we decide we know what you need, we're gonna send you some questionnaires that basically get that information about what kind of shop are you, you Linux, you Windows, those kinds of things. What are you concerned about? What are your objectives? That type of stuff.
Then you're gonna have the actual test where it's like we've moved now that we've gotten those questionnaires back. We've set up everything we need in order to do those tests. We've shipped you a beacon to get on the inside of your network so that we can test from that perspective in a safe way that's not gonna open up any problems for you. We'll actually do that test.
And during that test, we may have questions for you. So we may either get on a call with you or we may email you those kinds of things. Basically, the point of contact, the person we've been dealing with is the person we're gonna ask those questions for.
Then we're gonna send you a report after we finish that. And then after you've had time to review the report, we're gonna actually go through you're gonna fix them. You're gonna send back, hey. Like, I've fixed the issues in the report, and then we're gonna retest them. And, again, make sure that what we think is happening is actually happening. So there are those five steps.
That's the bulk of the content that we had to go through today. We still have some questions that we'd like to go through. Keep in mind, like, we are taking questions, so make sure that, like, you're engaging with us. Ask those questions.
We wanna know what you have to say. We wanna know what you're concerned about. The more you interact with us, the more we can tailor our service to help you get what you want out of it. And, again, coming back to pretty much everything that we've talked about today, the best way to to have an effective test, the best way to make sure that you get the most from our service is to interact with us so that we can speak to your concerns and to your needs.
While we'll be going through these questions, please ask your questions. We may not be able to get to everybody's question, but someone will reach out to you and answer those questions because it is important for us to be able to know what you want and how to speak to your needs. So please reach out to us, and we'll engage with you. Someone will reach out.
Okay. I'm just gonna start reading through these questions now. The first question that we have that I'm asking to you, Garrett, is why would I get a pen test compared to a vulnerability scan? And the statement that goes along with that is, like, don't they provide similar information?
Yeah. They provide similar information. A vulnerability scan is going to passively enumerate your network and attempt to fingerprint known vulnerabilities.
So it's not gonna do it's not gonna look for any unknown vulnerability that might be, say, you know, a flaw in code that you have written in house or something along those lines. It's it's not going to do any manual enumeration of those services. It's just going to look at the headers, look at the version numbers, and attempt to figure out, is there a vulnerability that is associated with that software?
Yeah.
Yeah.
No. Really good. And then I just one point of clarification, use the word passive, which I think what you're going for is basically, like, it's not gonna be, like, very clear about, like, your custom software. But it is an active scan in that we are gonna be interacting with, obviously, the devices on your network.
So, yes, correct. Exactly what you're saying. I just wanna make sure that, like, that can have a certain connotation of passive being. I'm not interacting with what's on your network, but we are gonna interact with what's on your network.
And Garrett's exactly right where it is very it's just gonna check versions a lot and look up known vulnerabilities and send information that way. The second question that we got is, will performing a penetration test open us to more security risks, or will or you or will your testing impact our day to day business operations?
So our our goal when doing a test is to never degrade the security of your infrastructure.
We are never opening additional ports. We are never modifying rules within your environment to make it more vulnerable.
We're never, you know, modifying your firewall. We're never doing anything like that that might cause a degradation to your security. And, James, I feel like you mentioned it earlier, but to that point, we we're actually gonna ship you a device that you'll plug in that will phone home to us so that you don't have to open up more ports on your network for us to connect into your internal network.
And regarding the question of whether or not our testing is going to impact your day to day operations, you know, we strive to not impact your operations.
I'm not going to say that a hundred percent you're not gonna notice us. Like, you will potentially notice us, but we're gonna do our best to never lock accounts. We're not gonna bring services down. We're not gonna restart servers. We're not gonna do anything like that that might stop you from being able to do your business because that's the most important thing.
Right. And one thing that I like you said is just, like, strive because, obviously, it's a valid concern. Like, those concerns are very valid. And I think it's important to realize, like, we are doing this because we care about security.
We're doing this because we care about enabling people who have a passion for their business, for their service offering to help them to, like, offload some stuff from them so they don't have to worry as much about security so that we can help them with that. Because not everybody's gonna be thinking about, like, I live and breathe security. It's what I'm super interested in. Chances are if you have a company, you're probably very passionate about something else.
Or if you work at a company or an industry, you're very passionate about something else. So I I like when you said we're gonna work towards that. And it is valid, and you should be aware about you should tell us your concerns when it's like, I am worried about this service. We have lots of customers who go like, I know that, like, we've interacted with pen testing firms, and, like, we we've we've had a bad experience, and we're concerned about this service going down.
Tell us what you're concerned about. Tell your why tell us why you're concerned about it. Something that we do as well is, like, off hours testing for automatic scans where we would where we do that, where the load isn't gonna affect your business hours, those types of things, where we're willing to work with you. We wanna make sure that you get what you need out of our test.
And, also, like, we realize, like, you have a business to run, and we definitely don't wanna interrupt it. So I really I really liked how you handled that.
The next question I have is, what is your favorite or unique discovery we've made during a pen test? So one of your favorite questions, I'm sure.
This is actually not even mine, but it is a a great a debt or a great vulnerability that a coworker found recently, which was, actually a known vulnerability in a printer.
And for whatever reason, the printer just disclosed to any user that wanted it a list of all the logged in users and their clear text passwords. And so coworker found this printer, found this vulnerability, and found a domain administrator that had connected to this printer and had his password. And that was like a thirty minute pen test. It was just we log in. We find the printer. We RDA.
Good.
I saved the third pen test. We weren't done. We just start over. We just go for another route to DA. But it's just like, you never think about printers as an attack vector, and they are so beautifully misconfigured all of the time.
Yeah. And that's that's a super good story. And you actually said something that I wanted to highlight that I actually thought was really cool where you come back to, like, oh, we're done, but just kidding. Like, we're gonna find as many paths. And that speaks again to the objective where I think sometimes when there's a question of, like, okay. If that's objective the objective and you have achieved that objective, what can we expect?
And you can expect us to try as many paths to achieve that objective as possible.
So when you hit on it, it's like, maybe we maybe your goal was that we get domain administrator, and maybe we got it that way, but we're also gonna be looking for more ways to do that. So even though that was your favorite story, I just had to highlight that because sometime, like, pull back the curtain a little. You know? The next question that we're gonna go through is how quickly can we get someone to perform a penetration test?
So, obviously, there's a lot of factors at play here, that all come down to size of your environments, which goes back to scoping. How long is it gonna take us to scope and get those questions answered in that conversation we had between our department and your department?
But on average, we can usually see a kickoff call scheduled about seven to ten days after the contracts are signed.
And then if you have time restraints or deadlines, we can do that require, after our assessment, we can do that very quickly, and our standard schedule is about four to eight weeks of lead time.
Okay.
And that's, like, you know, on average. That's not if if you come and you you sign the contract and you say we're doing a pen test, I I don't wanna just set the expectation that that's what it's gonna be, but that's what we strive for.
Yeah. I love that word strive. There it is again.
Also keeping in mind, like, when like, there are busy seasons like any other time. So keeping in mind that, like, the time of year also affects, like, how quickly we can do it because sometimes when people get budgets, like, that's when they'll start doing it. Also, like, towards the end of the year, like, if you like, it's not uncommon for people to rush and try and get things done. Like, the entire industry is very, very busy at that time. So just keep in mind, the more forethought you have, obviously, the better. And, obviously, like, we know that in a perfect world. Right?
The other thing to keep in mind is we do offer the ability to do, like, extra contracts is what we call them. So if you really, really, really need to have something done really, really quickly, we talk to our testers and say, hey. Does anybody else have any extra cycles to where they'd like to interact with, like, this extra contract so that we can get this done quicker for a customer? And there are different qualifiers around that, but just keep in mind, like, if it really, really needs to be done, again, we like working with you. We wanna work with you and make sure that you get what you need out of it, and that's also an option.
So I have some background on this next question.
When a lot of, like, what we've been talking about is successful penetration tests are dictated by people having and coming to us with objectives.
And when we send out those questionnaires, one thing that happens is peep we're asking about their entire network and not necessarily, like, a server they want us to get access to or something that they're really concerned about. So with that qualifier in mind, why would we wanna test different assets other than what their objective is pointing towards?
Yeah. So oftentimes, when you come with an objective in mind, you want us to potentially compromise the crown jewels of your network. Well, those are probably the ones that you focus on securing the most and are probably, in reality, gonna have the least vulnerabilities.
And so it's important when we are having the conversation of scoping your penetration test to place us in a realistic environment where an attacker or a threat would realistically be originating from and allow us to test all accessible devices from from within that network perspective with the intention of achieving our objective. And so we're not just going to test these the small number of assets that go hand in hand with your objective. We are going to test whatever we can to provide the most value and to achieve that objective that we've agreed upon.
Nice.
And and I like this idea of value. Like, I think you said that a couple times while you're answering and realistic Because it comes back to our statement of, like, if that objective is very security focused or has, like, a legitimate like, something that keeps you up at night, if you stick us in an unrealistic situation or you talk with us and we say, hey. Maybe this would help us to evaluate this in a more holistic way, and we get stuck in an unrealistic situation, we're not gonna be able to provide as much value because it won't be as realistic.
And it's also important that, like, part of the thing that we talked about at the beginning of this webinar was essentially we are there to test biases. So it's not uncommon for people to try and be worried about, like, oh, man. I'm where they're gonna find something.
We're there to test biases. We're there to be helpful to you there. We're help you we're there to help you have wins within your organization. I think it can be easy to look at us as a threat because, obviously, we're attacking what's going on.
But to keep in mind that it's a really, really, really big thing in our department and with the testers that we have that we wanna celebrate successes and that we also realize, like, we're gonna find stuff, and that's that's a good thing. And especially, like, we're not coming after anybody. We're not trying to drag anybody through the mud. But if we don't have these conversations and you're and and if we don't have these conversations, it can be very hard to actually improve.
And, again, we do this because we like it because it helps you be more secure and enables you to perform your business functions in a safe way for your customers.
So, Garrett, the million dollar question, the one that everybody wonders about because you're an expert, how much do penetration tests actually cost?
Yeah. And that is a difficult question to answer. Right? Because there's a lot of moving pieces. There's a lot of aspects to what can change the price of a penetration test. But on average, in our experiences, the and this is gonna be or an average pen test is between five and fifteen thousand dollars.
Obviously, that is just average based on an average size network. It's gonna change, like I said, based on any number of factors. So reach out to us.
We'll have someone get you a more personalized price, based on what you need.
I like that phrase personalized price. And the reason I like that is because this entire time we've been talking about tailor fitting what we do to people's environments or their concerns or their objectives.
And, obviously, like, we live in a reality where money can be a prohibitor. And even if you're concerned about money, like, we wanna hear from you. Right? Like, we want people to reach out to us.
We wanna be approachable. We wanna talk to people. And I think that's one of the important things because people do have budgets, and they do have, like, this is as much as I can spend or this is what, like, we've been approved for, and we work within those as much as is possible. And that's just that is another reason why our objectives are super important.
And it's also really important to realize, like, we realize that security is not a moment.
Right? Like, it's it's something you do over and over again. It's a journey. It's something that's iterative.
It's something that we come back to over and over again. And what's what's funny is, like, when we start talking about that because it is a concern, people are worried about money because it's like, well, how do I like, from people that I've talked with, at least, it can be like, well, I just don't have the budget for that. And it is one of the reasons why people come and work with us and say, okay. I know you work with me.
This is what I have this year. But if you give me something, I can increase my ask internally. And I'm not saying, like, you should increase your ask always, but, like, we're here to help, I guess, is what I'm trying to say. And it's not always about part of the fun of security is working within constraints and money as a constraint, and that's probably why people are really interested.
So we'll work with you. Reach out. We'll talk to you about it. It's tailor fit to you.
That's all we had time for today. Those are all the questions that we're gonna go over. But, again, if you submitted a question, we are gonna be sending out a recording and someone will reach out to you to address those questions that you have or those needs. And please keep in mind that we also do have areas where you can call in.
So if you do have questions, please feel free not only just to, like, send questions through the box on the website, but also please call in to our support department. We have great people working. We care about what you're, again, your needs, your concerns. We wanna be a partner with you in making sure that your security gets taken care of.
And, again, this is Garrett Adler and James Farnsworth signing off. We hope to see you again.
.svg)
