Watch to learn about penetration testing basics and segmentation check best practices.
Having issues accessing the video above? Watch the video here.
In this webinar, SecurityMetrics' Chad Horton, CISSP, QSA, Penetration Test Manager, covers:
Learn more about SecurityMetrics Penetration Testing.
This webinar was hosted on September 28th, 2016.
Okay. We're gonna go ahead and get started.
Again, I wanted to say thanks to everyone for their attendance today for coming out. We're really excited to talk to you today about PCI DSS three dot two penetration testing updates.
Our pet our pre presentation today will be Chad Horton, who is a CISSP QSA and our penetration tested manager here at Security Metrics. Chad's been working at Security Metrics for eleven years and was on the penetration test guidance special interest group for the PCI Security Standards Council. So a lot of great experience that, hopefully, all of our attendees can glean some knowledge from today.
Before we get started, a little bit about security metrics.
We've been helping organizations comply with mandates, avoid security breaches, and recover from data theft since two thousand. Been in the industry a long time since the inception of PCI, and we've been involved in a lot of the special interest groups and helping to find the standard and and the evolving standard that, you know, we see every day with PCI. We've been involved with and understand well, and we're excited to talk to you a little about today.
Now that, you know, a few more people have joined now that we're a few minutes late, just a few housekeeping items.
The question we get most common is can we get a recording? Where can we get a recording? Where can we get the slide deck? We will be sending a recording of the presentation as well as the slide deck out in the next few days. We'll be sending it to whatever email address you register for the webinar using. So watch your email. Like I said, that'll go out in the next few days, and you can watch the recording, share it with other people in your organization, your customers, whoever you think could benefit from it.
Another question we get often is, will there be time for q and a? What if my questions don't get answered? We will have a good amount of time for q and a today. That's what we're hoping for.
Go ahead and use the chat function on your GoToWebinar control panel to send in your questions throughout the webinar. And at the end of the webinar, we'll address as many as possible. If we aren't able to get to your question, we will reach out on an individual basis. We wanna make sure that everyone gets their questions answered.
So with that, we're gonna go ahead and get into the presentation. I'm gonna turn the time over to Chad.
Excellent. Thank you very much.
When we originally set out to do this webinar, we had the ambitious goal to be able to talk about each part of the standard PCI penetration test. However, as we quickly realized, the amount of content was well beyond what we believed we could fit into a single webinar. And we also wanted to be able to do an initial webinar and get feedback from the audience on topics that they would like to see discussed on future presentations.
So what we're hoping to do today is to start off a series of presentations or webinars that we'll do over the next year or so, about penetration testing. So, again, those questions that you can send in will help drive the content for these future webinars that we'll be performing.
This presentation will focus on, segmentation checks. That's the main topic we're gonna discuss today. Although this requirement has been in effect over a year, we continue to get frequent questions about them. Hopefully, we can address those questions, those concerns that you as the participants have and are dealing with today. This agenda will start off by talking or the agenda for today, we'll start off talking about penetration test basics.
We'll move on to talk about the new PCI DSS three dot two penetration testing requirements, and then we'll finish off talking about segmentation check best practices.
Let's go ahead and get started.
Penetration testing basics. What exactly is a penetration test? The easiest way I've found to introduce people to penetration testing is to relate the relate it to physical security. Thanks to movies such as Mission Impossible and James Bond, the average person has a strong concept of what physical security entails.
Imagine you were put in charge of securing top secret files.
How would you secure them? I would imagine you'd put them in a safe in a room protected by a badge reader, which has which limits who can access the room, in a building surrounded by guards and big electric fences, potentially guards carrying machine guns. All of this in the effort to limit who can access the facility and to limit the impact a rogue employee could have with access could have on on the data.
Now the facility is built, the security system is in place and installed, and everything is ready to go, what confidence level do you have that this system is secure?
While I have confidence in the engineers I hire to build systems, their jobs are ultimately to build and configure the facility or the network I hire them for. Without independent verification, I have no certainty as the effectiveness of the security systems.
Oftentimes, engineers are very effective at designing systems that work effectively but aren't always secure.
Now it's, now it's time to test the facility. So we we've identified we need to test it. How should we test it? If we simply test the outside perimeter, then we can have a degree of confidence that the average external attacker will not be able to penetrate very far. However, like any other facility, frequent repairs and upgrades will be necessary. Third party repairmen, such as HVAC repairmen, will often be allowed within the perimeter gate, while inside these repairmen may not always be supervised. Additionally, offices, networks, they frequently have, varying degree varying number of individuals connected to the environment, whether they be guests or they be on tours, things of that nature.
So if we approach an internal test and we have an HVAC service repairman that was malicious, the natural question to ask ask is what could they do? By performing internal pen tests from from different areas in the areas in the facility, we can evaluate this threat. If the HVAC systems are on the opposite side of the facility from the secured room with their top secret files, should the temporary guest badge we provide to the HVAC repairman be able to access this secured room?
This is ultimately what we try and determine inside of different security assessments.
Penetration testing. So let let's step back from the scenario, and let's talk about how this applies to the digital world. I would imagine that each of our participants in this webinar work for or own an organization that transmits and or stores data that must remain confidential.
We have protected both the data and our networks using encryption, firewalls, security appliance, and other measures.
Each of these protections was configured and installed by employees that we trust on an individual basis. But are they experts in security? Do they ever frequently try and break into other environments so that they can advance their own knowledge and understanding of how to keep individuals out? How do you know your network is secure unless you're regularly testing it?
This is why we typically when we talk about penetration testing, we talk about it's being required.
You know, if you if you're put in charge of protecting a nuclear facility, you're gonna be mandated by government standards, to protect that data in a specific manner. If you store, process, or transmit cardholder data, similarly, the payment brands are gonna mandate that you secure that data and those networks connected to it in a specific manner.
This also applies for HIPAA, for, for banking institutions, and we've also seen similar requirements on higher education companies as organizations as well.
So let's talk about the new PCI DSS three dot two pen test requirement. PCI requirement. PCI DSS the biggest change we saw in PCI DSS was in revision three dot o with the introduction of segmentation checks. In version three dot two of the DSS, two additional requirements were added.
The first one being segmentation checks must be performed by an organizationally independent resource. This requirement had already existed for other penetration testing activities, so it simply brings it in line. For clarification, this does not require it to be a third party performing the test. It simply states that it cannot be performed by employees managing, maintaining, or design designing the environments.
This is, of course, assuming that they have documented experience penetration testing.
Starting in February of two thousand eighteen, service providers will also be required to perform segmentation checks once every six months, up from the previous once a year that it was in the previous standard. Leading up to and following the enforcement of the original requirement for seg checks, this was the single most commonly asked question to our salesman. It is clear to us that much confusion on the subject still exists in the industry and that conversation needs to be had surrounding this topic.
Another common question people have on PCI DSS three dot two is, how did that affect what pen test requirements each individual essay cue has?
For this reason, we created this just this simple slide. I'm gonna go through it rather quickly, but you can reference it offline and see what requirements you have for each given SAQ.
Let's go ahead and jump in to talking about The common question I get is, is segmentation testing worth it?
Even in two thousand sixteen, a year after the initial requirements were implemented by PCI, the majority of first time segmentation checks performed by security metrics still receive a failing status.
Organizations who believe that less secure zones, such as their guest Wi Fi, were isolated from the CDE were actually incorrect. Their high security networks, their CDE were exposed.
There are many reasons for this that organizations fail their for them failing their first segmentation check, whether it be a misconfigured firewall rule, legacy, rules that were not removed, third party management services were incorrectly, added and retained inside of the rules. Regardless of the reason, we continue to see unnecessary risk exposed to the CDE.
So what is a segmentation check? A segmentation check verifies that a given network segment is isolated from another. In the physical security scenario we covered earlier, this would be the equivalent of testing the guest badge provided to the HVAC repairman and verifying that he did not have access to the secure storage room. The repairman did not have a repairman did not have a need, so he should not have access.
The intent of this assessment is to provide evidence that the segmentation check method being used, whether it be a firewall ACL or a routing restriction, is in place and effective.
The most common scenario we encounter is the use of guest Wi Fi networks. I believe all of us can agree that individuals visiting our office location should not have access to our secure files or the servers that host them.
This is a typical network diagram that we receive from organizations. It has three basic, basic environments.
A CDE network segment where our credit card processing occurs on our web servers.
We have some corporate file servers, which are just storing non CDE or cardholder data associated files. And we have a guest wireless network that's on our corporate office And we have a guest wireless network that's on our corporate office network.
This is where we're putting the majority of our servers. This is a common scenario we see in organizations that we're assessing.
Having a logical diagram like this can really assist organizations in identifying what segmentation segments should have access to the CDE and what segments shouldn't. Until you know everything that is on a given segment, it's difficult to identify whether or not it should have access.
As we discussed on the previous slide, it is imperative that open networks, such as the guest Wi Fi or possibly even the corporate office network, should not have access to the CDE.
This would be a prime example of where a segmentation check should be performed and what it should target.
So as I kinda talked about in the previous slide, when preparing for a segmentation check, the first thing that you need to do is identify the CDE boundaries.
From the external network, it's obvious. We are all connected to the Internet and typically have some exposure there. Internally, it can get a little bit more difficult. There are typically multiple zones that are gonna comprise our boundary.
We'll have a secure database zone where credit cards are typically stored, or long term storage occurs with those systems that are in the CDE. We'll have a DMZ that is publicly facing that houses our ecommerce website or other such devices that are connected to the Internet. And then we have devices or servers that are recording our, calls in our call center. And oftentimes, in these devices as well, we'll have recordings of the actual credit card number.
For each of these internal zones that have a boundary, inventory, we need to perform an inventory of the active hosts in that zone. This will help us when we're actually performing the pentests, and you'll see why on the next slide.
The second thing you need to do is list the segments that should not have access to the CDE.
Guest Wi Fi, HR, marketing, the executive teams, these are all prime examples of environments that contain mission critical, systems, but not necessarily need hosting or managing them.
The last thing that we need to do is generate a test matrix.
Ultimately, we enumerate the services of internal networks that should not have access and those systems that are the CDE. And we're gonna have to test from each one of those to are the CDE, and we're gonna have to test from each one of those to the systems that are CDE.
So, for example, looking at this network diagram, we have two generically labeled cardholder data environment zones, and we also have two networks which should not have access to those zones. We have the marketing and the HR, which we talked about on the previous slide. From this, we can determine that a segmentation check needs to be performed from the marketing zone targeting both the CDE networks and another test from the HR zone testing both of those zones as well. We wanna make sure that we test all unique exposures, and each network may have different firewall rules or routing restrictions in place, and those segmentation methods need to be tested.
So let's talk about how you conduct a a segmentation check. Using the data that we just gathered while preparing for the seg check, we are now ready to perform the assessment. For the assessment, we will come from these segmented zones and target all the active hosts inside the CDE.
We are looking for the ability to communicate with these hosts. This includes IP traffic, ICMP traffic, or any other protocol that allows us to communicate with those active hosts in the CDE.
Sampling is typically not allowed.
However, in situations where a large number of identical rules have been deployed, a test can be performed against a sample of those instances.
This is commonly how we approach retail, restaurants, and other other cookie cutter style organizations.
Because each restaurant or storefront location has identical networks that were built with the same configurations, we can have a degree of confidence that all of them are effective if we conduct a sampling test against a handful of them and we get identical results among each of those.
Performing segmentation checks are not always straightforward. There are complexities such as bandwidth limitation, time restrictions, or legacy firewalls that cannot support numerous small packets. In each of these scenarios, the analyst performing the assessment must be equipped and ready to adapt to these challenges. We have seen segmentation checks span eight weeks, potentially even sometimes up to three months because the analyst performing the assessment did not understand how to adapt these type of scenarios.
In fact, over the years, we've developed multiple relationships with other pen testing firms. And even today, we are still getting escalations from these other firms requesting assistance from us in assisting, in completing their scans. They can't identify how to adapt to a given scenario to complete the segmentation check, so they reach out to us.
So anytime an organization takes these on internally, we typically give them the advice to make sure that the analysts have a strong understanding of networking, that they have access to the firewalls, and that they're evaluating, where the firewall CPU level is, where the bandwidth level is, to make sure that the segmentation checks are not negatively impacting the environment in any way.
So how do you know when a segmentation check fails? Well, as we mentioned earlier, any communication from the CDE sorry, from hosts into the CDE is considered a failure.
The most common situation that catches network administrators by surprise is even ICMP or pings, are considered a failure. Any traffic is not allowed from isolated environments into the CDE.
So in situations where access is identified, remediation is usually pretty straightforward. You either close the port or block the protocol.
However, in some instances, companies discover that what was initially considered a zone zone that does not need access to the CDE actually does need access.
In these situations, there are two options that they can explore.
The first is to access if is to determine if the access is necessary.
If it was, update the documentation and assess the p which PCI requirements now apply to that zone that has access to the CDE.
If the company does not want to apply PCI requirements to that new zone, then processes can be changed or should be changed to remove, to remove that access or the need for that access, or resources can be moved to new zones that are already in scope so that that access can be restricted from the zone in which the segmentation check was performed.
So let's talk about takeaways. Like, what is the if you were to walk away from this presentation, what were the main things that we want you to understand as a merchant? And the first thing is security metrics can attest to the importance of this requirement. Segmentation checks do provide value.
They are here for a reason. I have been amazed to see just how many low security networks had access to servers within with sensitive data. We continuously continually see guest Wi Fi networks with direct access to the database zone or dentist office locations, where from the guest Wi Fi, we're able to access their back end systems reason. However, even after doing this simple exercise, many it is sorry.
Even after doing this exercise, it's important to continue on performing this exercise on a regular basis after any change or yearly to make sure that additional changes that occur to the network don't introduce the vulnerabilities again. After going through this exercise, these one vulnerabilities again.
After going through this exercise, these once exposed networks are now locked down in a way that the network administrators had originally intended. That's ultimately what you need to know about, segmentation checks. If you want more guidance, there's a great council publication If you want more guidance, there's a great council publication called the PCI DSS, penetration test special, sorry, information supplement on penetration testing guidance.
I was actually had the opportunity to be on the committee for this publication. I think there's a lot of great data in there, not only on segmentation checks, but on network penetration tests and application penetration tests alike. There are case studies and scoping examples, has a lot of relevant data for even version three dot two. So we definitely recommend that as a resource.
So we're gonna go ahead and jump over to questions. So I'll hand it back over to Colin. But just as a reminder, your questions that you pose, even if you wanna post questions outside of segmentation checks, we'd be glad to field those. And if we're not able to get to them today, we'll add it to the content of our subsequent webinars that will be performed.
Great. Thanks, Chad. We appreciate your time. And as we said, we'll move into question and answer. We have quite a bit of time, so we should be able to address quite a few, and then we'll get you out a little early since we're gonna move more into a series. Like Chad said, we definitely wanna give penetration testing in it all of its different forms, the adequate time and details. So we appreciate you joining us today and discussing segmentation checks.
We've received a lot of good questions, so I'm gonna dive right into them. Chad, someone asked, does a PCI VLAN qualify as a segmentation control?
I would need a little bit more of a clarification. So if that VLAN is restricted access, either on, like, a layer three switch that you've restricted the access or on a firewall ACL, then, yes, that would be a segmentation method that you're using to restrict access from an out of scope system to an in scope system. So, if you want to actually reach out to us with additional information on that question, I'd be glad to follow-up on that.
Great.
And you discussed a few different diagrams. You had a segmentation check diagram, and someone asked, does does that diagram differ from the network diagram that is already required for PCI compliance?
Typically, no. We can actually use the exact same network diagram.
Many of our assessments that we're performing are associated with, either service provider audits or regular level one or level two, merchant audits. And so during those, we'll actually use the same diagrams that our auditors are using.
Great.
You also discussed on one slide that sampling was generally not allowed unless there are you know many zones with the same firewall rules. Can you explain a little more? You know what you mean by sampling? What does that mean exactly?
Yes. So using the example where we talked about the restaurant location where we have a hundred locations, a good sampling size that we'll see is anywhere between five and fifteen of those stores. We'll connect to those stores and test from the guest Wi Fi, for example, into the POS network at each one of those stores. So what we're doing is we're sampling the store locations and testing the ACL controls that are providing that isolation.
And going back to some of the diagrams is testing you talked about testing from marketing and HR into the CDE network zones Is testing also needed from the CDE zones to network zones?
To other CDE zones. Is that the question?
I think to other non CDE zones. So going from CDE one to marketing or HR, for example.
Okay. Yeah. So, typically, it's not needed the opposite way. What we're doing is we're testing from low security networks. We assume that anything that is out of scope for PCI or doesn't have the PCI controls in place should be considered a low security network. So we're gonna come from those networks to the high security network. We typically don't worry about the other way around.
Great.
So we've gotten a few different questions about, you know, the nature of segmentation checks being required to be PCI compliant. How often are segmentation checks required? Who's required to do them? Do you mind just going over again a little bit over the, you know, general PCI terms when it comes to segmentation checks?
Yes. Definitely.
So all merchants that have a CDE environment locally, which is like s a q a e p, s a q c, and s a q d are gonna be required to do a segmentation check.
Typically, what we're doing is we're targeting from systems outside the CDE towards the CDE, systems that should not have access. They need to be performed once a year if you are a merchant and twice a year if you're a merchant service provider. And just to reiterate, they need to be performed by either an in house qualified individual that is organizationally separate from managing those systems, or they need to be performed by a qualified third party either one.
And then can you also talk about you know the slide before you mentioned the supplement guide where you can find more information on segmentation checks and and pen tests in general.
Can you explain you know where that can be found and you know the best way to access it and use it?
Yes. That can come from the PCI Security Council's website. If you type in PCI security standards, penetration test supplement into Google, you'll that'll actually be the first hit that you should see. And I believe the website is something like PCI security standard standards is the website that has a library of all these documents. That is one of the documents they have.
Great.
And you you discussed that it can be performed by a third party or someone within the organization that has the expertise that is organizationally disconnected from those environments.
So what what tools are needed for penetration testing?
You know, that's actually a great question. Something I probably should have spent more time in on the presentation.
So here at Security Metrics, we use what we call the Swiss army knife of pen testing tools, also called nmap.
That tool has the ability to to manipulate packets on an individual basis, to be able to test all the types of different protocols. So that's actually the tool we rely on most heavily. We will use other tools when it comes to we do a step called profiling the network where we'll try and determine how the firewall is configured to respond to packets, how much bandwidth is acceptable across the network without, you know, interfering with normal business operations. So we'll use some other tools such as iPerf is what we use for our VPN tunnels, and we'll use, HPING, sorry, HPING ping three to manipulate specific types of packets for heartbeat.
If you want more information on that, please send us specific questions, and I'd be glad to respond to an email form. Maybe a little bit easier in that than actually talking about it.
Great. And then kinda going back to one of the diagrams and one of the questions we already went after, is it required to test between CDE zones if there are multiple CDE zones?
Yes. It's not required to test between CDE zones. The assumption that the council has made and and my understanding, especially from the, going through the committee for the PCI supplement, was that once you're into a CDE, the assumption is you already are there. You've you've owned the environment.
Our goal with penetration testing is to make sure that people who are outside of the environment can't get into that environment. And so, ultimately, that's the assessment. So we're not trying to test from CDE one to CDE two or CDE three, anything like that.
Great.
Before we get to the next question, I'm just gonna say again to make sure that there's clarity we will be sending a recording as well as the slide deck and the recording will include this q and a. So, hopefully, that's helpful as, you know, a lot of the questions that you may have listening to the recording. Hopefully, we cover them in this q and a to make it a better resource for you. So I just wanted to, again, clarify that.
And, Jack, can you can you repeat a couple of the tools again? We had a few that I'm sure we're trying to write those tools down for penetration testing.
So n map, is the most common tool that we're using. We occasionally will use HPING.
Sorry. HPING three, sorry, is the tool that I typically use. And then we also use, for us to determine how much bandwidth we can send, we'll use something called iPerf.
That one may not be required. That's sorry. I p e r f as in Frank.
That tool may not be required in all instances. That's something that we use internally to make sure that our access to their environment doesn't affect them. But mainly, HP three and NMAP are the two tools that you're gonna be looking at.
Great.
So, Chad, we talked a lot about, you know, the CDEs and the other networks. So how would a website fit into your penetration testing framework?
That's a great question. A website falls into, an application pen test, which is one of the other requirements. That's the next webinar we would like to perform is either on is gonna be on application testing. So, we'll be talking about that significantly.
To give you a high level overview, an application test requires totally different tools and methodologies for testing than a segmentation check. So we're actually gonna be at connecting to the web application and and sending requests, logging into it, trying to evaluate what functionality it has. All that type of stuff is, functionality that we don't need to test inside of a segmentation check. So it's a lot of content and substance that could talk about, but I think the next webinar will be will provide some great information on that.
Great.
And a few questions have come in regarding p to p solutions.
We obviously don't wanna dive into specifics as, you know, everyone has different environments. But do you have, like, a general what kind of penetration tests are required for someone using p two p solutions, or are they required to do penetration tests?
You know, that's a a great question, and I would actually feel a little bit more comfortable if our director of our QSAs were actually to respond to that one. So we'll send out an email to the individual who asked it.
I am not as well versed on p two p e, so he would be the individual I'd refer to on that one.
Great and as I said we've had a large amount of questions sent in we probably won't be able to get to all of them so we will reach out on an individual basis to anyone that sent in a question that we didn't feel we are able to address fully or that was more about their specific environment.
So you mentioned the supplemental guide are there other resources for people that are new to penetration testing? Maybe PCI in general, but technical requirements like penetration testing?
Yes. So there's in regards to segmentation checks, that is, from our experience, a PCI specific type of test. And so the supplement is actually gonna be the best location to go and gather data for segmentation checks. When we start to talk about network penetration tests and application penetration tests, these each have different resources that we will provide on slides on the future ones.
If you're looking at application pen testing just real quickly, I would recommend, OWASP. That's our main resource that we look at. We look at the testing guide. We've really been a fan of the work that they've been doing over there.
It's an open source project, and we would strongly recommend people not only reference it but also contribute to the development of that project.
On the network side, I actually don't have a strong reference off the top of my head outside of the methodologies that are provided inside of the PCI DSS, such as the NIST eight hundred one ten or one fifteen. I'm having a hard time recalling which one. But if you look inside the PCI DSS, section eleven dot three, it'll actually mention the NIST document as one of them.
I will try and come up with some, better ones or additional ones, for our other webinars that we'll be conducting.
Great.
We've gotten a few questions asking about, you know, other webinars that we're that we do offer.
Offer. We usually do webinars, you know, about every quarter.
And if you've registered for this one, then we'll keep you on the list to invite you to further ones. As Chad has mentioned, we're gonna plan on doing a series of some of these shorter webinars with more q and a time to cover penetration testing as it is a large topic and has a lot of detail and brings a lot of questions, especially with its technical nature. So we don't necessarily offer a schedule that we adhere to besides we do webinars about quarterly, and we send invites out, you know, the month before and a few weeks before. So keep your eyes open, and we'll keep sending them. We also post them on our website when they're upcoming.
So just we've had a few So the So the questions come in a few times asking about you know who would be a qualified person to do a penetration test and you know who how can they know or what is is there a threshold?
Is there a certification for someone being able to perform the penetration test or segmentation check?
You know, that's a fantastic question. We had a lot of great, discussions in regards to that when we went through the, PCI committee.
When we're talking about a qualified penetration test or ultimately or a qualified individual, few things. You can look for a certifications, although that's not always a guarantee. Many certifications are question based. And so just because you know the theory behind penetration testing, doesn't mean they can translate that to actually perform it effectively.
So certifications you can look at, not always a foolproof.
Schooling is another thing that you can look at if they have a degree in, network, network administration or, c computer science, degree that can also assist them when performing, like, application penetration test. But, again, it's not a foolproof method for doing that. Ultimately, what I recommend to our QSAs is that they get on the phone and they talk with the individual who's gonna be performing that, whether that's in house or a third party, and they talk about what their experience is with different technologies. So, for example, if we're talking about an application penetration test, web application design and API design and implementation.
Has he ever gone through secure coding training, such as OWASP, for example?
If he has all of those things, then I can start to develop a degree of comfort that he knows what he's doing and he knows what he's talking about. However, if he starts answering that he's never built a website or he's never designed one, not that that's a prereq, but that he doesn't have any experience with HTTP, I can now start to feel like there's gaps in what he's assessing.
Similarly, on a network layer assessment, one of the things that we try and do is cater our analysts to the environment. If we're testing a mainframe, I have one individual that I feel comfortable actually putting against an IBM mainframe. I just don't feel comfortable. My other analysts don't have any experience and I don't believe would be able to adapt to the task. So similarly, on a network layer assessment, you wanna look at what technologies you're gonna be, you're asking them to test. If you're asking them to test Microsoft devices and they're a Linux only guy, then he's probably not as equipped as equipped to actually perform that given assessment.
So when I'm looking to qualify a penetration tester, I'm looking at what is their knowledge base, what is their experience, assess the security of this device?
Great. Thank you.
Another question, whether the segmentation pen test is or check is conducted themselves or by a third party is that the same as the internal penetration test that is required by PCI or those two different tests and the internal test is a little more detailed.
I'm sorry. What was the first part of the question? I missed that.
So is a segmentation check the same as an internal penetration test that's required in PCI and just a new name for it, or are they two different things?
Great question. So a segmentation check actually entails the first steps of an internal penetration test. The reason why it was given a unique name is because we're now testing from locations that were previously ignored. If the system was isolated from the CDE and considered out of scope for PCI, then during pen test prior to, to PCI DSS three dot o, we would not even consider them in our scope for the pen test. Now that they now the segment shade sorry. Segmentation check requirement is around, we'll actually test from those additional networks where before they were ignored.
Great. Thank you for that clarification.
I know we've you've discussed tools a couple of times. Someone asked, are any of those tools and you may have specified, are they open source? Or if if not any of those tools, are you aware of any open source tools that you would recommend?
Ironically, each tool that we use for our segmentation checks is open source, and so we use those.
We happen to have a license, though, with NMAP so that we we wanna support the foundation so we have a license through them, but that's not required that is open source software great.
And someone asked him, obviously this would vary by size of environment. So just you know some kind of general typical term. What What would a time frame be for a penetration test or specifically a segmentation check?
Okay. So specifically about segmentation checks, the the main factor there is gonna be the number of source networks we're testing from. So earlier, we talked about HR and marketing and the number of environments we're targeting.
So as the number of environments I'm targeting increases, say, it goes up to ten, I now have twenty unique segmentation checks I'm performing.
On those in on that scale, you're typically looking about one to actual testing time, you're probably looking at about four to five business days is how long it takes us, but these tests often have to be scheduled on different days for different reasons.
So, that's typically the time frame you're looking. On a one perspective or a one source network to one target network segmentation check, you're typically looking a handful of hours, is it? They usually don't take that long. It's when you get these complex matrices where you're targeting from many source to many target environments that the time starts to go up because you don't wanna be targeting the same network from all ten source networks. Otherwise, you could result, you could in unintentionally denial of service that environment.
For a normal penetration test, like looking at a application pen test, we typically see between two to five business days as our short, I would say, five to eight business days is our average. And for a network penetration test externally, typically, one to four business days is where we're looking at those and internally as well.
Great.
So we've had a few questions about whether automated scans being run internally are sufficient for segmentation checks so if someone was setting up scans from you know these networks to the CDE by using automated tools instead of manually doing a penetration test. Can that be used as a segmentation check?
Yeah. If you notice, all the tools that we recommended are automated in nature. However, there's there's some things you need to keep in mind when you when we talk about that. And that's I I'm glad you brought this up.
We run a good route run against many firewalls that have a port scanning rule. When they detect port scanning, they're automatically gonna drop those packets and deny them. And so people will run these scans. They'll last a week, and then they'll be like, nothing no access was there. So unless you're manually monitoring the situation, you may not realize that there actually is a firewall that's been blocking all of your testing. That entire week's worth of data is actually inaccurate because you were blocked the whole time. So while, yes, you can automate a segmentation check, due diligence needs to be, had or made to make sure that you aren't getting blocked, there isn't interference, anything of that nature that would invalidate the results.
Great. Thank you.
And just to hammer home, I know we've touched on this a couple times, but there there's nothing required as far as using an ASV or QSA in order to perform a PCI penetration test and count it towards your compliance. Is that correct?
Yeah. That's correct.
There's no requirements and in fact the QSA Cannot perform the penetration test for the one that he's actually assessing so no requirement for an ASV QSA anything like that great.
Well, we want to thank everyone for their time. We had a lot of great questions and again we had a few others that we weren't able to get to that will reach out on an individual basis and some that were a little more specific to your environment that will better benefit from a conversation with you individually.
We had multiple notes that people ask for more P to P information, so we'll make a note of that and reach out to those asking about where P to P falls with penetration testing and segmentation checks again we plan on doing a series of these penetration test webinars so be on the lookout for those as we advertise them and we'll cover the application tests and internal tests and other things that Chad discussed and that should help clarify some of your. Questions as well as far as being compliant with the PCI standard. Again, we appreciate everyone coming out. We will be sending out the recording and the slide deck in the next few days. So be on the lookout for that, and we appreciate everyone's time. Have a good day.
Thank you.
.svg)
