Watch to learn how a network penetration test can strengthen your organization's network security.
Having issues accessing the video above? Watch the video here.
Is your network prepared to withstand attacks? In this webinar, SecurityMetrics' Chad Horton, Penetration Test Analyst (CISSP, QSA), discusses how a network penetration test can strengthen your organization's network security. Watch this recorded webinar to learn:
Learn more about SecurityMetrics Penetration Testing
This webinar was hosted on July 19th, 2019.
0:00 Thanks for your attendance! We’re excited to talk to you today about Network penetration testing. Our presenter will be Chad Horton who is a CISSP, QSA and the senior director of our penetration testing team here at SecurityMetrics.
0:16 Chad has been here at SecurityMetrics for 11 years, and he was on the Penetration Testing Guidance Special Interest group for the PCI security standards Council. So he was part of the group that helped define the penetration test standards and the updates that recently came out. So a wealth of knowledge, lots of experience and hopefully you can learn a lot from him today. I'm going to turn it over to Chad and he will let you know what the webinar will cover today. Go ahead Chad.
0:59 Thank you very much. I appreciate that. Today we're trying to help the audience understand the basics of network penetration testing. Often times this is a hurdle that organizations we work with have. They are told they need to get a penetration test done but they don't understand what it is and they don't know how to speak intelligently with management or pentest providers to evaluate what's being done or what they're paying for. And so what we're trying to do is educate our audience on what network penetration testing is. So today we're going to start off by talking about the basics of a network penetration test. This is a 101 presentation so we're going to be focusing mainly around basics. We'll do a brief overview of network penetration testing, how they're performed and then we'll go into some best practices and general recommendations that will help you prepare to enter the world of penetration testing and to talk about penetration.
1:59 So let's go ahead and Dive Right In.
2:03 A network penetration test is an assessment that focuses on the design implementation and maintenance of a network and the services hosted on it. So let's translate that into something meaningful. A network penetration test is going to help identify misconfigured software, firewalls or operating systems, outdated software and operating systems, insecure protocols, unnecessary exposures, things of that nature. These are the categories of security issues that a network assessment is really going to focus on. It's important to note that the software and security issues are in software that was not written by the organization.
2:46 A few years back, around 2007, the PCI industry introduced this concept of a network pen test and an application pen test. It’s crossed industries by this point and so oftentimes there's confusion between the two. We want to talk about the difference between a network pen test and an application pen test. An application pen test is going to focus on the security of the custom code and the supporting software while a network pen test is going to focus on software that wasn't written for the organization. We're talking about Microsoft, Apache and Linux. We're talking about software that's generic and available for all users. So if you were to compare the two directly, this is how I would boil it down. A network pen test is going to focus on the network services on a given IP host or network, while an application pen test is going to focus on coding flaws that introduce vulnerabilities into an application they've written. On a network pentest, to fix issues from it, you're going to install a patch, reconfigure the software or remove a legacy protocol.
4:00 On an application pentest you're going to have to recode the application. You're going to have to either get your developers to do this or hire a developer to come and fix the issue inside of the actual code itself. So why get a network pen test? This answer is very similar to the answer we gave during the application webinar. Ultimately organizations are trying to hire IT professionals to build their environments, to build a network, to maintain their wireless networks and to provide support to their end users workstations. These IT professionals are not security experts. That's typically not a requirement on the job description. So a network pen test can assist them in their efforts to provide these services in a secure manner.
4:48 It also helps you avoid a compromising loss of sensitive data, but most likely you're looking for a pen test for a compliance standard, either PCI DSS, HIPAA, or some other standard that's driving you to become compliant.
5:04 So what should be tested is the perimeter of any environment that stores sensitive information. While the concept of ‘store, process, and transmit’ is PCI terminology it can be applied to any standard. Anything that is storing, processing or transmitting personal identifiable information (PII) could be applied to the same definition and it’s a good way to approach security in general. While this definition is definitely not foolproof, it's a great place to start if you're looking to start a security program within your organization.
5:41 In addition to just testing the perimeter, it's important to identify this concept of critical systems. In the PCI realm they've introduced this and we've seen a huge improvement in our customer’s security as a result of it. Ultimately what we're looking at is services that support the servers that store, process and transmit data. So we're talking about DNS, we're talking about domain controllers, we're talking about JavaScript libraries, things of that nature. Anything that provides support to the CDE or a secure server that if compromised, it could affect the security of it, you would want to include that in a pen test. So we're going to look at a quick topographical view of a network and this is targeting mainly a PCI realm, but again, these principles could be applied anywhere.
In the top right corner of the slide here we have the CDE. Here are the servers that store, process and transmit the data that we're interested in securing. On the top left corner we have shared services. These are servers that are providing support for our secure environment. Directory services is up there, we've got a logging server and we've also got an admin workstation, which is allowed to connect into the CDE and manage those servers.
7:07 And the bottom we've got a corporate LAN where all the employee devices are. And the nature of having our directory services or domain controller up there is that the corporate LAN is also able to dial into that shared services zone. However, the corporate LAN is not able to access our cardholder data environment or our secure zone. In this situation the network penetration test would need to target two different perspectives. From the shared services environment we would want to attack all the exposures into the CDE. So, from shared services to CDE, we would want to perform a pen test and also from the corporate LAN we would want to do an assessment into the shared services zone.
The theory of that second part is that if an employee device compromised the directory services, could they then pivot and access the CDE? Or could they then escalate their privileges in a manner that ultimately allows them to compromise sensitive data? So those are the two network penetration tests that would need to be performed here. For those of you who participated in our segmentation check webinar that we did last December, from the corporate LAN to the CDE, we would also perform a seg check just to verify that, “Hey that network is not supposed to hit the secure zone.”
8:32 Let's verify that they're not able to. So when we talk about perimeters, there are two perimeters that were typically looking for, the external perimeter or the part of your network that's exposed to the internet and the internal perimeter. In that previous slide we just went over the internal perimeter. That's the equivalent of coming from the shared services zone into the CDE and also from the corporate zone into the shared network zone.
9:00 So those are the two perimeters that we would be testing. When should pentesting be performed? If you're in the PCI realm they recommend after any major network change or annually. This is sort of self-evident. You perform the annual assessment to verify that you're maintaining a security posture at a level that you feel comfortable with and then when you change your network layout or architecture you want to make sure that those changes haven't lowered that security level, that you're not exposing anything additional. So we typically recommend that guidance as well. Even if you're not in the PCI realm, so for HIPAA, for banking industries that we've dealt with, we recommend the same timeline.
9:45 So we're going to go ahead and pause for a minute and see if there are any questions that have come in and then we'll continue on with the rest of the webinar.
10:05 Okay, great. So we've gotten some good questions. “Does PCI require only the network level penetration test or also application penetration testing? Great question. So they require three types of pentesting, network layer pen testing, application pen testing and segmentation checks. So this is the third of those that we're covering and we're just wrapping that up.
10:30 So they require all three of those. Next question, “What would you define as a major network change as far as needing a penetration test outside of the regular schedule?” Yeah, so the types that we typically run into are restaurant chains when they're introducing a new store or a new series of stores that are going to be using a new technology. Maybe you're switching from a brocade firewall over to Cisco or vice versa. You want to make sure that those rules get ported accurately. Also when we see people change technologies, going from an open VPN or an SSL VPN tunnel over to IPSec and we want to make sure that we've done that in a secure manner. Or if you're introducing new network zones, you created a new department and you want to make sure that that department has the correct access to all the other zones and that it doesn't introduce new risk to the organization.
11:31 We've received similar questions so hopefully we answer yours as we try to combine some of these. “As far as the annual penetration testing, would you say best practice would be to do it more often than annual? Is that just the PCI requirement? What would be your view, whether it's for PCI, general data security, even for HIPAA or another mandate, as far as scheduling them?” Great question. So for me personally, I view the annual as what you would want to do for the network application and seg checks AKA you're doing it from an external or an internal perspective of a compromised machine. However, there are different types of assessments that could also be considered that could be performed and I would recommend they be performed at different times during the year.
12:15 Social engineering is a common one that people aren't educated on and it can be a direct attack vector into the cardholder data environment. Wireless penetration testing, not technically required by the PCI DSS and some of these other standards, is another one you could consider. So I wouldn't necessarily recommend increasing the frequency. I would recommend exploring different types of penetration test. One that we got introduced to about two years ago, which is a very fun one to perform. An organization will give us the laptop of an employee that recently got terminated or left the company, and they'll give us their authentication tokens or credentials and ask us, “What could this employee have done to our internal Network?” They don't necessarily suspect the employee of anything, they're just curious to know what rogue attack would an employee be able to perform or do against their network. So there are different types of penetration tests that I would explore rather than just increasing the frequency of the penetration test.
13:23 Next question.
13:28 “Is a penetration test defined as automated, manual, a combination? Does it need to be manual to be considered a penetration test?” You know, we're actually going to put a lot of effort into answering that question here in a few slides. So I'm going to postpone that one until the end and after I've covered that topic if there are any additional questions feel free to send them back in and we'll answer them. Perfect. So we do have a handful of other questions. At the end of the webinar we're going to try to get to as many as possible. If we aren't able to get to your question today because we have had so many come in, we will reach out on an individual basis to make sure that everyone feels like their questions were answered and we can dive into more specifics to your situation.
14:13 Okay, let's go ahead and move on.
14:18 So let's talk about performing a network penetration test. The objective is to identify and exploit issues that could allow an attacker to access systems or resources that they should not be able to. An example that we commonly provide to people is, “Have you updated to the latest patch to fix the latest zero day?” We are all intimately familiar with Heartbleed and numerous other vulnerabilities that were covered by the mass media. This is a common one that we're looking for, “Are you up to date and patching correctly? Have services been properly configured to prevent insecure configurations?” A lot of emphasis is placed on removing default credentials or default configurations, but companies are often surprised when they find out that their configuration above and beyond the default can introduce or expose issues.
15:16 So we want to make sure that you're using that software in a secure manner. Last but not least, “Are you using insecure protocols or services in general?”
15:27 So before we dive in too deep, let me just do this call out real quick. This is a common problem in any type of penetration test but especially with network layers. The most common issue that we encounter while performing these is that many modern firewalls have a configuration option enabled. By default, it will attempt to inhibit the ability of port scanning to identify available services. It does this by returning responses or packets that are usually restricted ports that are left open but the firewall will just report that on all ports. While the intent is a noble one, to try and thwart attackers, this mainly inhibits penetration testers and other white hat hackers that are trying to help the organization. It does not necessarily impact the attackers in the way that they believe it is, from my perspective. Attackers have a much longer time frame in which to retrieve their information. So once this behavior is identified there are many strategies that they can deploy to bypass this layer of protection.
16:37 It's also important when engaging a penetration test provider to ensure that any options that could inhibit the analysts ability to assess the environment are disabled. Not doing so will simply water down the results obtained by the analyst, directly costing the organization money and a lost opportunity. The second most common issue we face is with intrusion protection systems. This is similar to what we just described with firewalls. Many firewalls have IPS software or functionality built into them. However with an IPS it is not black or white, turn it on or turn it off. You usually have the ability to whitelist a given analyst’s IP address essentially telling the firewall or IPS software not to block that traffic even though it may look malicious. This is very important because it will improve the accuracy of the results that you're going to get back from a penetration test.
17:36 Penetration testing tools. In the limited time that we have, I can’t provide a comprehensive list so I will provide some of my go-to scanners that I use during a penetration test. There's the host discovery and port scanning phase, so NMAP is my go to. There are plenty of other ones out there. If you simply google them you'll be able to find them. During a pen test when I come across a specific port or service that I'm not familiar with, and we'll talk more about this in a minute, one of my go-tos is to look for service specific scanners. There are also general-purpose VA scanners we should all be familiar with like Nessus and OpenVast. They basically scan a wide array of services and can identify a myriad of vulnerabilities or configuration issues associated with them. Last but not least, exploitation tools. Metasploit is by far the most popular in the industry, but there are other alternatives available as well.
18:34 So let's talk about the stages of manual testing. One of the questions asked was about the difference between an automated and manual pentest. I'm not going to cover that in super detail here because we'll cover that in the towards the end but I'm going to mention that there are different levels of a penetration test and I’ll tell you how they differ. We have five steps typically associated with our assessments. We do a high-level overview after the automated scans have been completed. We look at the environment. This is the equivalent of a 10,000 foot view, looking down so that you get familiar with what you're going to be assessing. The second step we do is validate the automated scan results. We want to make sure that the IPS didn't block us, that the scan results were accurate, things of that nature. We're going to identify issues. We're going to step into exploitation and then we're going to document our findings.
19:30 So an automated only pen test typically just performs the automated scans. There is a different type, I call it the semi-manual or the automated assisted penetration test. They'll just validate the automated scans. This is roughly the equivalent of signing up with an ASV, an approved scanning vendor, through PCI and having them scan your network and then calling their tech support and asking them to verify the findings. While some call that a penetration test by their standards. I personally don't find that to be a penetration test.
20:11 So again, as we talked about that high level overview, you're really just trying to understand the environment that's to be tested. Am I dealing with a Microsoft shop, people who deploy mainly Microsoft services? Or am I mainly dealing with an open source Linux Apache LAMP stack? This helps me target my efforts towards the technologies that are involved in the given environment.
20:36 I'm going to validate the automated results by looking for indications of scan interference. It's surprising how frequently we run into scan interference. And then I want to eliminate false positives. I want to make sure that I don't pass those on to the customer because as a penetration tester, I only want to provide my customer with actionable items. False positives can ultimately lead to a time drain and don't provide the service that we want to give our customers. Next. We want to identify issues. Is the protocol secure? On a given service, is the service well-maintained? What are the recommended steps for securing the service? Once I know a lot about that service, then I'm going to apply these questions to the service I'm looking at. This often includes a lot of research. We're spending time in manuals for the given technology.
21:30 We're spending time on forums associated with the technology to look for common issues or common misconfiguration trends. And last but not least, I'm going to spend a lot of time within the security industry and see if I can find any service specific scanners or scripts that could assist me in both identifying and exploiting the issues. And then once I identify a vulnerability we're going to step in and try and identify what the actual impact of the issue is. Once I get access to a server, I'm going to see how I can use that access. How can I move within their environment from there? If I get access onto a web server can I now start hitting the other web servers within that environment? Can I then pivot and further my attacks beyond what I already have?
22:19 So it's important to note that if an environment is relatively clean there may not be any any issues to exploit. This is common around PCI because people focus very heavily on segmenting their CDE or cardholder data environment from their other servers to de-scope them and so we're only targeting these really hardened services.
22:47 So it is common to see that you'll get a cleaner pen test report that didn't have a lot of exploitation on it. For organizations that decide to go above and beyond rather than just targeting what's prescribed on the scope, when we target everything, you're going to see a lot more exploitation on your reports and a lot more findings and recommendations on how to improve. Last but not least and often under-appreciated is the need for documentation. In the Penetration Test Supplement, which we will include a link to at the end of this presentation, we went over five basic things that should be included in a penetration test report. They seem very self evident from a security perspective. A description of the issue. What's affected by it. How could an exploit affect the organization? What risk would they apply to it? And then references to industry standard bodies like CVEs, bids things of that nature. However, it's alarming to me when I receive, almost on a daily basis, a pentest from other pentest vendors or internal pen tests where they haven't even provided the targets that were affected by the issue. And the organization that received the pen test report is left in a situation where they need to to try and determine what's affected.
24:10 How do I remediate this? If you're coming away from a pen test with those questions, I would assert that the pen tester has failed to properly document their findings.
24:21 So we're going to do another quick break here while we go over any questions that came over on that last section.
24:29 “Can you revisit the three different types of penetration test for PCI and give a quick summary of each of them?” Yes, definitely, in fact, that's on our roadmap for a follow-up webinar now that we've gone over all three of these. We’ll give a high level overview of the landscape and we want to talk a little bit more in general terms. To do a quick overview, a segmentation check occurs when you have an environment like a guest wireless network that should not have access to any other network. For example, if I walk into Starbucks, they don’t want me to connect to their wireless and be able to hit their internal database servers. So a segmentation check is the equivalent of stepping onto the network and trying to gain access or hit that other environment. You are verifying that the segmentation is in place and effective.
25:26 In an application pentest, people most commonly associate this with web applications, we're going to be hitting that web application and looking for coding flaws. If you've heard the terms SQL injection, cross-site scripting, privilege escalation, all of these things are typically associated with a web application assessment that is that is performed. But the application doesn't have to be a web application, it could be a web API or it could be a custom protocol or a custom application that they've written. Last but not least is the network pen test, what we're talking about here today. This is more of a general purpose pen test where your targeting the network services exposed on a network, secure shell, SSH, remote desktop protocol, RDP, file transfer protocol, FTP.
26:19 We're targeting the use of all of these different services and we want to validate that your securely implementing those, maintaining them and using them on a day-to-day basis.
26:30 Great and really quick before the next question. We will be sending out a recording of the webinar and it'll include these question sections. We'll send that out in the next few days and include the slide deck for your review. You can share the slide deck and the recording with people internally or externally in your organization that might be interested in understanding it better. When we send out the recording we will also include a link to our other two recordings where we discussed segmentation checks and web application penetration testing. We’ll also include a link to the supplement that Chad referenced that can probably give you a lot of answers when it comes to penetration test guidance in the PCI realm.
We will ask one or two more questions and keep going to make sure we get everything covered. “Do you have any general tips for defining the scope of a network pen test for PCI? Where should they start when trying to understand what the scope is?” Yes. One of the requirements in the PCI DSS is that you need to maintain a list of all the hosts that are in the CDE.
27:50 And so what I recommend first is creating that inventory because once you have that inventory, if these hosts either store, process, or transmit cardholder data, in the PCI realm, that ultimately expands to the network. And so that says if I have a web server in a network with 100 other web servers that don't touch card data, all 101 web servers are in scope, so that the entire network is in scope. That allows you to take it from the host to the networks that are in scope. Once you have that inventory of networks that are in scope, you want to create an inventory of the inverse of it, of anything that is not in scope for PCI. And then ultimately it's just a matter of drawing the lines between the two. Does network A which is out of scope have access into network B. Oftentimes this is internal Wiki's or logging or domain controllers things of that nature that have access into it.
28:50 There's also the element of critical systems, which we briefly touched upon, where you want to identify services that may not touch cardholder data but they impact the security of it. If the domain controller is shared across both the CDE and non CDE you want to make sure that you're testing against that as well. So that's how I would recommend approaching it. Start with inventories of hosts, move to inventories of networks and from their define the perimeter around the CDE then identify avenues into it. And that's your network pentest.
Great. One last question before Chad continues. And just to give the caveat that obviously these things change depending on your organization and your scope but Chad, “Can you give a general feel for how long a penetration test typically takes, how long that project would take?” Yeah, this is a difficult one to answer because there isn't a one size fits all. It really depends on the number of hosts within the environment and the number of services that are exposed.
30:02 The average level 4 merchant that we run into is typically looking at around two to three days for a network pen test. But when we're dealing with level 1 merchants, people who are processing millions of credit cards annually, you're looking at potentially a week or two weeks or more. It's also important to note that not only is it the host and IPs, but it's also the number of perspectives that you have. If you've got 5 zones that are in your CDE and you've got 50 zones that are outside your CDE and each of those 50 zones have unique exposures into the CDE then that's a lot of juggling that needs to be done to make sure that we're testing from each of those zones effectively. So the complexity of the network and the complexity of the number of services will play on that. In general, I think those estimates are fairly accurate.
We will continue on to make sure we can get through the rest of the presentation and we will address more questions at the end. Again, if you have questions that are more particular to your organization, we will reach out to you on an individual basis and that way we can hopefully give you a more accurate answer when it comes to things like how long things are going to take and how much things could cost. Back to Chad.
So moving on, let's talk about network penetration testing best practices. When shopping for a network pen test there are four main things that I would recommend talking about. Automated versus manual, comprehensive versus targeted, evaluating pentest providers and then evaluating deliverables. So automated is typically cheaper, there are some very rare exceptions, but automated is faster and manual will yield more accurate results. If I had to summarize in three bolt points, that's how I would do it. I apologize for anyone who participated in our previous webinars, but I'm going to repeat a story that I told on a previous one just because it applies the network pen testing as it does to everything else. Before I share this story, let me emphasize that no, there is no industry-wide accepted standard for how penetration tests are to be performed. So between vendors, you'll get different interpretations and different implementations of a penetration test. Within this last year, I was asked by a bank rep who came to talk to us about some potential services. He asked, “What defines a manual penetration test? Does pushing a button manually to launch an automated tool define a manual penetration test?” This is a common argument that we see among many pentesting firms.
32:47 I responded that it doesn't and I'll go into detail about why on this next slide. Manual penetration tests have the ability to identify key elements of a penetration test that automated tools have limited capability to. Identifying false positives is one of them. But more importantly, is identifying interference from security appliances. We did a penetration test a year ago against an organization that had a regular scan penetration test from another vendor and those scans came back with zero ports open and one of them came back with a single web server open and it was always a clean report. While it showed the port open, it didn't show any data about the port services that were listening, what type of software it was running or anything about it. When we tried to perform our assessment. We saw similar behavior, except our manual analyst flagged it and said, “That's not correct. I know there's a web server there.” So he went in and found out that their firewall had been configured to block port scanning.
33:59 And so when the port scans would stop it would automatically respond with all closed ports on everything. The automated-tool-only solution was not able to identify that and ultimately led to a false sense of security for the organization. While the manual pen test was able to quickly identify that within 30 minutes or an hour and they were able to move towards, “How do we fix this? How do we accurately assess the environment?” and then we were able to provide the value that the customer was ultimately after. There are other things like the ability to assess non-standard protocols or services. General-purpose VA scanners are targeting the most common software out there on the internet, but with the prevalence of GitHub and other open source projects or even just small organizations in general, there are a lot of non standard protocols and services out there.
These general-purpose VA scanners can't effectively evaluate the security of them. That requires a manual perspective, manual time spent with the vendor or manual documentation to look for issues associated with that protocol or that service. Other things that are kind of obvious, they can't translate risk from generic CVSS scores to organizational risk. They can’t even provide customer specific remediation recommendations. Automated scans are sort of one-dimensional. While there has been some interesting work towards introducing AI on some advanced scanning engines or introducing a subsequent scanner, a series of automated tools based on different conditions that exist in the environment, I personally adhere towards a purist view which is, you need a manual analyst. The industry isn't mature enough to have only an automated tool.
That is my perspective on that. So hopefully that answers your question about the difference between a manual pen test and an automated one. From the PCI realm, there is no clear definition inside of the DSS itself that says it has to be manual, except for the fact that it says it has to use industry standard methodologies. And I'm not familiar with any industry standard methodologies like the NIST 115 that include that it can be all automated. In the supplement that we were a part of, that was one of the first topics we discussed as a group and one of the first things that we wrote into that document, the difference between the two. And in the supplement, it does recommend and require a manual penetration test to be performed.
36:39 So hopefully that answers the question. If not, feel free to send in more.
36:44 Comprehensive versus targeted. The most accurate assessment of a security environment can only be obtained while performing a comprehensive test. Earlier I was asked the question, “Is it more valuable to perform pen tests more frequently than annually?” This is my follow up on that. I would recommend you test more of your exposures, test more of your environment, step out of the PCI centric perspective and start testing your other servers. At the end of the day, it's not just cardholder data that we need to protect. We need to protect our organization's reputation. We've seen organizations that have simply been defaced and a hacker leaves their trademark on where their homepage used to be, or we've seen situations with the most recent malware that's been released, I Wanna Cry, where it's not just about the sensitivity of data, it's about the availability of data and it's about the Integrity of the data that you house. And that's not just limited to cardholder data or for HIPAA, personal identifiable information. There is other information that you're interested in protecting.
37:54 So when you're looking for a pen test provider, these are the guidelines I typically give and this aligns very closely to what's in the supplement. You want to evaluate what questions they ask about your environment. Earlier the audience asked about how long a network pen test takes to perform. Well, it's associated with the complexity of the environment and the number of services exposed. If an organization that is quoting you for an assessment doesn't ask you any questions associated with those two points, then what confidence do you have that they have sufficient time or capability to perform your assessment? What type of experience do they have that will help them with your environment? If you've asked someone to come and pen test your IBM Mainframe, there's not a lot of pen testers that I'm aware of that have familiarity with old IBM mainframes and would be able to effectively pen test that. So you want to pick out someone who has that specialty or experience doing that in the past.
38:54 Certifications are not foolproof. Don't be fooled by people who just have a long list of alphabet soup behind their signature. It really is about what those certifications provide. We get a lot of applicants to be a pen tester here at SecurityMetrics who have more certifications and I have letters in my name and yet when we asked them to apply the skills that they've learned in those certifications they're unable to do so, they're unable to translate theory into application. And so from my perspective certifications can be beneficial but they are not the not the end-all, solve all. How long has the analyst been performing pentest? Do you want someone who's relatively new in the industry or do you want a seasoned vet targeting your environment? And last but not least, what experience does the organization have with your security standard? if they're not a PCI shop and you're trying to get a PCI pen test that your QSA will accept, make sure that you're talking to your QSA and saying, “Will you accept this report, these deliverables? Do they meet your criteria for the penetration test?”
40:02 You can definitely use internal resources for a pen test. For PCI there are two requirements. I think this applies to all organizations regardless of if you're in PCI or not. Are they organizationally separate from the environment? Pen testing your own stuff is really difficult because you have a list of assumptions in your head about the environment. You built it, you configured it. While that can provide you an advantage it also provides some blind spots that analysts aren't often aware of. And so they need to be organizationally separate from what they're assessing. In this situation, I wouldn't want the system administrator that built the environment to do a network pen test against the environment.
40:48 I mentioned this before, evaluating the deliverable. Make sure that when you're looking at a pen test provider that you request a sample report. Could your organization take action with the information provided in the report? I've mentioned this a few times during this webinar today. We see quite frequently in pen test reports that there are security issues listed and the pen tester or the analyst has not included which servers or services are affected by it. It's impossible to take action on that. Some organizations take the Viewpoint, “I want to review my entire environment and see where that issue could be prevalent,” and that's all right, but your developers and IT administrators are going to have a much harder time and you're going to have a lot more back and forth with the pen test provider than you would if they provided you with those in the beginning.
41:45 And most importantly, if you're doing an audit, whether it be PCI, HIPAA, SOC or whatever audit, make sure that your auditor will approve of the report and they'll accept it at the end. We've had many instances where people have gone for the $500 glorified VA scan and they've gotten it to their QSA and found out that they wouldn't accept it. That puts you in a bad situation because you're out the $500 but more importantly you're out the week's worth of preparation time and you are now in a rush to find a provider that can meet your deadline. Avoid that time crunch by making sure you are communicating effectively with your QSA or your auditor.
So takeaways. Our main objective in providing this webinar series has been to help you understand the basics of penetration testing and to enable you to have more effective conversations with management and pentest providers to allow you to evaluate them and to pitch to management and get the security budget that you need to effectively do your job. So we're going to stop here and do another round of questions.
42:55 Great. Thank you all for the questions. We're trying to sift through them as quickly as possible to address as many as we can. First question, “Can you review the two requirements for using an internal resource for PCI pen tests as far as being organizationally separate?” Yes, so you need to be organizationally separate, that means that in their job responsibilities, if they are maintaining, building or designing an environment that needs to be tested, they are not organizationally separate. They're tied to that environment, they're familiar with it and so they should not be performing the assessment. So they need to be organizationally separate. You should also ask, are they experienced? Do they have any certifications? How long have they performed pen tests? Are they going to be able to effectively evaluate the environment you're asking them to?
44:09 In the past we've had salesmen interested in performing pen tests. They didn’t meet any of the criteria and so I would never put them on any of our pen test because ultimately I wouldn't say that they're qualified to perform that. You as the organization need to make that ultimate call. Are they effective? Are they going to be able to effectively evaluate it and do they meet that criteria?
44:37 Next question, “You talked about some of the less expensive penetration tests and that often times they are just glorified VA scans. So if someone's looking for a pen test that is cheaper, maybe it's done overseas or maybe it's more automated than manual, what are some of the tips to make sure that it's going to be adequate? And would you recommend or do most QSAs allow using pen testers that are overseas or less expensive?” That's one of the hurdles that QSAs have is how to accurately assess the effectiveness of a penetration test. Overseas providers can be effective and we've seen organizations that can do this, however, I have probably seen more providers overseas that have difficulty, especially in specific regions of the world, that have struggled to provide high-quality penetration test consistently.
So when it comes to evaluating overseas providers or providers in general the questions that I gave are a great start. In the Pen Test Supplement there are more questions that we've included. What I would recommend doing is evaluating how many hours they are going to provide on the environment. What are they quoting? Are they going to be spending five manual hours to assess a thousand hosts? On your other quotes, are they doing 10 or 30 hours to assess the same environment? Get a baseline, that's where getting multiple quotes can help you. But also talk to them and call them out and say, “Hey, look I'm really afraid I'm getting a glorified vulnerability scan or a verified automated scan for my penetration test. What is your perspective on that? What's your perspective on doing a comprehensive pentest.” Really engage with that provider and ask them these questions. That's the best tool that I can offer for you. It’s your best strategy for identifying those types of providers. And before we get to the last few questions that we have time for. We just have one more reminder. We will send out the recording and the slide deck for your review. So be watching for that. Hopefully that will help you to digest some of the more technical information that is in the slides.
Next question. “Chad, you mentioned some different ransomware including ‘I Wanna Cry’. How would you say pen testing helps you to avoid ransomware? What is your overall view of the importance of a penetration test when it comes to protecting against ransomware and other types of attacks?” That is a great question. Directly, it does not protect against ransomware or some of these other attacks. Ultimately though, people who have bad security practices in general, who have consistently left their systems unpatched. They're leaving themselves very open to these ransomware attacks because we all know that the Script Kiddie Ransomwares are exploiting known vulnerabilities that have already been patched. If you have an immature security program where you're leaving unpatched systems, then it's a fairly accurate conclusion that your workstations are probably in a similar state. A penetration test can give you a holistic view of what your security program really looks like and you can start to apply that across the board. Other pen tests where you include non PCI targets, where you're going to target everything within your environment, are going to directly target those work stations. So now instead of concluding based on inductive reasoning that your systems are potentially outdated, you'll directly be able to see outdated workstations and be able to call that out.
48:41 For zero day vulnerabilities there's very little protection. That's where it comes down to user training. Social engineering training can provide value in that area.
48:52 One last question, “What would you say are some recommendations you would give as far as certifications to look into or ways to get experience if people want to be able to become a penetration tester and be the internal resource for their company?” Look for a certification that has a manual or an application side to it. I would personally recommend staying away from theory-based certifications. There is a trend among a lot of them that they're moving towards application-based which I'm really excited for it because it's long overdue. Certifications like the OSCP has a lab where you're going to have to target it and you're going to have to attack it. You have to compromise X number of servers. That type of practice is very effective.
49:52 I'm not necessarily saying that the OSCP is the certification, because we've seen OSCP certified analyst that still struggle, but it's a great introduction into the environment, into the industry of pen testing because it allows you to get experience with older servers and known exploits. It gets you familiar with the process that we went through earlier. You have to get this thousand foot view. You're going to have to identify what servers are there, you're going to run automated tools and validate the findings. Then you're going to have to go and do your research. You're going to have to go through the manuals. You are going to have to go through a lot of these different websites to try and find vulnerabilities or misconfigurations so that ultimately you can identify issues and exploit them. The hands-on certification is what I would recommend. OSCP is just the one that comes to my mind. For network pen testing I know there are other ones out there, but unfortunately, on the spot, that's the only one that's coming into my head.
50:47 It looks like we're out of time. We went a couple minutes past. Thanks again for everyone's patience today and for all the questions. We will send out the recording and the slide deck as well as some of the other resources and links that Chad referenced so that you can get more educated. If you have questions in the future, please feel free to reach out to us. We'll be reaching out in the next few days with individual questions as we weren't able to get to all of them today. So thanks again for everyone's participation this morning, and we look forward to talking to you again.
.svg)
