Watch to learn what to expect from a penetration test and how to get the most out of your penetration test.
Having issues accessing the video above? Watch the video here.
In this webinar, we'll cover everything you need to know about penetration testing basics. Join Gary Glover, VP of Assessments (QSA, PA-QSA, CISA, CISSP), and Terrill Thorn, Manager of Penetration Testing, as we break down this important aspect of data security.
Watch this webinar to learn:
This webinar was hosted on April 29th, 2020.
Good morning.
My name is Sarah Kemple, and I work in the marketing department here at SecurityMetrics.
Thank you for joining us for our penetration testing one zero one webinar.
Gary Glover and Tara Thorn will be presenting.
Gary Glover is the VP of assessments at SecurityMetrics and holds a CISSP and CISA.
He's been working for us in the IT security industry for over fifteen years. Before that, Gary spent ten plus years as a software engineer at Nobel and an aerospace engineer, also known as a rocket scientist, at McDonnell Douglas.
Gary has a master's of science degree in mechanical engineering from Brigham Young University.
Terrell Thorn has been working at SecurityMetrics for three years, managing the production side of our penetration testing team, and has been a technical manager for twelve years.
He has a master's degree in cybersecurity for Utah Valley University.
A question we get quite often is if we'll be sending out a recording of the webinar.
We will send a recording of the webinar to your email address within the next couple of days.
Also, if you have any questions during the webinar, please chat them in on the GoToWebinar panel, and we'll take the last fifteen to twenty minutes of the webinar, and we'll dedicate that time to answering your questions.
If we can't get to your question, we will reach out to you on an individual basis.
Without further ado, I'm going to hand you over to Gary and Terrell.
Thanks, Sarah.
We're gonna cover the agenda real quick here.
We're gonna be first covering penetration testing basics, how to prepare for a pen test, the life cycle of a penetration test, and then we'll talk about any takeaways and answer your questions, at the end of the presentation.
So we're gonna start off, like I said, with penetration testing basics and start off by talking about what is a penetration test. A penetration test is a security assessment that simulates an attack by a malicious individual or group with focus on identifying weaknesses that need to be fixed. Penetration test typically don't attempt to conceal their attack like a real attacker would, and they're coordinated ahead of time with, the company.
And at the end of the penetration test, you're going to have a report delivered with all of the exploits, and everything that were found.
Also, exploits that are found and attempted during the penetration test, are executed with an attempt to not damage the systems that they, are attacking.
Penetration tests differ from other security assessments, and that penetration tests should focus on manual effort with the assistance of specialized tool.
Thanks, Terrell.
I wanted to make sure that everybody understood today kind of the difference between vulnerability scanning and a penetration test. I think a lot of times people are are confused and and wondering why one is is different or why one doesn't count for the other. There's a couple of big differences. A vulnerability scan really is an automated type of a test, while a penetration test includes a, qualified individual that's actually digging into the complexities of your network. And, you know, actively really trying to exploit any vulnerabilities that they may discover.
Again, a vulnerability scan typically only identifies vulnerabilities at a pretty high level. They're not really looking at trying to exploit very much stuff, and and it will give you kind of an indication report. But a pen tester will really just dig deeper and, identify root causes of vulnerabilities, use his brain and creativity to really try to get access, do, things that try to get into databases, getting out sensitive data, etcetera.
So, you know, one way to think about it is vulnerabilities can can offer a great weekly, monthly, or kind of quarterly high level quick insight into your network security while penetration tests are really a deeper level of security testing. Often when I talk to people and try to explain the difference to help them understand, it's it's like, you know, when you go to get an x-ray, if you've got some sort of a a problem, you go to the doctor and they give you an x-ray. And an x-ray kinda ends up with kind of a blurry picture. You can see bone structure and breaks and things like that, but not really good at soft tissue. And so, you know, if you still have problems, you have to go get an MRI scan. Then they can create this cool three d model and look around and slice it and and look at at real structure.
And, it's a a much clearer and a real kind of feeling of what's going on inside a little bit more. So that's similar between the difference between a vulnerability scan, kinda like a fuzzy x-ray and a penetration test, be like a real detailed three d MRI. So if you really wanna find those really big issues with your applications or your network architecture, you need a penetration test. And, you know, a regular penetration test is a great way to ensure continued security as you continue to modify and improve systems and software. Next slide, please.
So a lot of times it's, you know, one of the questions we get is why do you even do a penetration test? What are some of the reasons why you do it? Everybody wants to keep their businesses running and and have a really good reputation for their customers.
And, you know, having a a an opportunity to partner with a security firm then that has the mindset of an attacker that then gives you a report and tells you how you're doing really is, a way for you to improve the security of systems.
You know, a lot of times, and oftentimes, IT, the DevOps, and developers, they're great and they're talented and they're doing the best that that they can can, do. But often the question they ask is, will it work? Not necessarily how can I break it?
So an autonomous, unattached, uninvested security team can really evaluate how something could be broken and what harm could be done or how could things be changed on a website, etcetera, etcetera without those biases of the developers.
So there's lots of, you know, reasons why people get a pen test. Perhaps you just wanna protect your reputation, you know, or protecting your customers.
Great reason. Maybe you wanna prevent any kind of damage downtime or defacement, humiliation, things like that. Perhaps you're changing, your network or doing a new release of software and you want to be able to make sure that that those changes haven't caused any problems that you weren't anticipating.
Providing assurances maybe to third parties that you are secure. Sometimes they want some sort of report or or, you know, indication from you that you have been evaluated for security with a penetration test.
That helps limit liabilities, you know, or things if if things go wrong there.
Often, pet periodic penetration tests are needed just to comply with legal or regulatory requirements like the payment card industry's data security standard or HIPAA or other things, and then we want you to show that you're actually doing those kind of things.
So, regular pen testing then prevents that damage downtime and humiliation by identifying, and then you can go in and fix those problems early on. Next slide.
So we've talked about kind of why. So when do you really get one of these? We've mentioned briefly some of those, but getting a little bit deeper. I think one of the the best things, that that we would urge companies to to get to is really using penetration testing as a business best practice.
It's just a great corporate habit to get into. It's really the best way to check your internal security processes from IT security, development, product design, making sure that those are really working. So then to to test that they're doing their jobs right, you do a automated you do a pen test and automated scanning together to make sure that, your business as usual process is really working.
And as we mentioned just a little bit earlier, if you're making major changes in your networks, if you're installing new hardware like firewalls or routers or new servers are being brought online with new operating systems, They're in critical zones, for example. Maybe you're changing your your whole network around and and re redoing the architecture, adding new zones, etcetera.
Moving to a new data center or maybe it to the cloud.
OS upgrades are are a good time to make sure that you're doing some of those checks. So any systems that are handling a sensitive data is important to be checking periodically with a a penetration type test.
Obviously, if you're changing software, if you're adding new features or refactoring or changing code or or upgrading to new versions of the software that you're generating or writing, it's a good time to do an application penetration test.
As I said earlier, sometimes regulations require you to do those in a regularly scheduled basis like PCI DSS. Next slide.
So let's talk a little bit about, different types of penetration tests.
There is what we call a network penetration test. That's gonna be more what you see in Hollywood where, someone's on the command line tool. They're looking to access your network and exploit services that may be open there, attempt to escalate privileges, get admin user permissions, on a box, and then, try to pivot and access, the more secure parts of your network.
With a web application penetration test, this is using the Internet to attack a web application that you might have online that a user might see.
You're going to be testing anything from just like a simple payment page to a full login administrative console where you manage multiple customers.
And, we're looking for things like being able to escalate privileges and create, an admin user in your web application.
We might also be testing the API calls that are made from the application, to try to see what extra information we can expose, or even, try to do things like, dump the entire customer table, which may contain, you know, names, addresses, email addresses, and potentially even, credit card or other sensitive personal information.
And then finally, we per we also perform what we call a segmentation check.
Oftentimes, you wanna make sure that, different systems don't have access to sensitive, areas on your network.
Think of, like, the Home Depot hack where the attackers got in through, not Home Depot's network directly, but through a contractor that had access to, some internal stuff from, from their side. And then, the attackers were able to pivot into Home Depot's, personal network, from there because they didn't have that properly segmented. And so we run checks to make sure that that that information is kept separate and secure, so the attackers can't access that. Next slide.
Yeah. Thanks, Tara. Good job. Hey.
A lot of times people kinda wonder what kind of a person actually does a penetration test.
And to be clear, I think a lot of times we hear, well, I've done software acceptance testing and and, you know, my humans did that, you know, our developers did that, or I did some automated code analysis using this really cool software, that should count as a penetration test. Right?
You know, and and given there's maybe a lot of techniques and technologies that are used that are really great that are automated, but I think the most important part of a pen test, a penetration test, is that there's a real person. There's a brain involved, and there's somebody who can pivot and think and and look at little clues and decide to go different directions. And and I think that is a really important part of this whole process.
As far as kinda qualities of a penetration tester and the experience that they need, it's not necessarily easy to find that right combination of school of skills and that makes a really good pen tester. There's not not very often are there college courses or college degrees in penetration testing.
People that are really good at it, we found, have been kinda curious and creative, but they really have a technical background that gives them ability to explore networks and apps and, satisfy that curiosity of how things work.
They need to be able to attack wide range of environments that require that creative application of these techniques to exploit weaknesses.
So not everybody not everybody can really be a pen tester, And so we're really lucky to have found some really great guys here that, have these qualities and we continue to try to develop those in others.
But it's a unique kind of person and personality that really enjoys kinda doing this.
And they're not just guys that like to wear hoodies and eat hot pockets either. I mean, these guys are pretty nice guys. Terrell, you're a nice guy. Right?
I'm pretty nice. I like to think so.
He likes pizza. So one thing I think pen testers with a little bit more experience will probably be a little bit more expensive. Remember, you get what you pay for. Beware of a a pen tester or a pen test company that offers prices that just seem to be too good to be true. They probably aren't doing a really thorough job and probably will be doing mostly automated testing and, giving you a report based on that automated testing. So we really suggest looking for penetration testers and partners, you know, that have some credentials behind their name like CISSP, GIAC, certified ethical hacker, OSCP.
You can always talk to them and ask them to give you some of their experiences on where they've been test you know, what kind of things they've tested, etcetera. I think, Terrell, you have a good story about kind of that illustrates the kind of the mindset of the guys on our penetration testing. Why don't you share that with us?
Yeah. So, a while ago, for my team, we did a little, video game competition. We got a really old video game from, I think, the early eighties, and and we had a competition to see if we could get the highest score in that video game. And then once the competition was over, rather than just, like, walk away and and do nothing, the members of my team, took the code for the video game.
They decompiled it. They figured out, different ways and how they can spawn, items and how, they can defeat each level and win, faster and get higher scores and different things like that from looking at the code in the video game, and then went back and continue to play it, and and were able to, just kind of almost make the game, a little bit trivial, because of, all the information that they gained just from looking at, the base code of video games. So, it was it was pretty interesting for me to watch them kinda take this thing that wasn't even intended as part of the competition and just kinda run with it and take it further than I ever thought they would.
Yeah. That's great. It's a good story. And, again, it illustrates the kind of mindset that that the actual human, brings to this whole process.
Next slide, please.
So some of the, different methodologies that you should look for in your penetration testing team, they should be following some kind of industry best practice or industry standard method.
The OWASP is a pretty popular one, for your web application testing.
They have great, ideas and and, great best practices for, your development process as well. So you can kinda use those hand in hand on on your development side. There's the NIST standards, and and other standards that, your penetration testing team should should be following or should line up pretty closely with when they're performing a pen test as far as how they're approaching it.
They should be looking for different types of vulnerabilities within that test. You're gonna be looking, SQL injection to try to get access to the database and get all the information that's stored there. They might be going after some broken authentication stuff on the network, trying to pivot and gain admin access or gain access to other users, credentials.
Or they may be going after, like, some cross site scripting to, potentially redirect customers or, you know, get more information from people using the system, trying to just fingerprint the systems on on what is this actually used for and and how maybe can I, use this dip slightly differently?
So there's a lot of different ways that the pen tester might approach it, but, ultimately, you wanna make sure that they're following one of the industry best practices and and lining up their testing methodology with those. Next slide.
So some of the tools, that you might come across, when you're looking at a penetration test, you could be the, typically, we talked about, like, a VA scanner. These are gonna be, like, your Nessus or OpenBAS or ACME or, the retina scanner.
These are great automated tools that can give you good information about your environment, but they don't really take the place of a penetration tester. For us, oftentimes, we run these scans, before the manual part of your test ever starts to give the tester some basic information. They're not gonna be familiar with the network, so we need, somewhere to kinda jump off and and try to familiarize yourself with your network or, the web application that they're using.
You also might see, a web proxy being used. Typically, you're gonna see either burp or zap or possibly man in the middle proxy. These allow you to intercept the web traffic, before it's actually sent to the server, then you can modify that traffic however you want, and then send it on and then check the response that you're getting.
And it and it gives you more control over what's being sent through your browser.
There's also some specialized software that you use like, Nmap, which many of you may be familiar with, for network scanning.
There's Metasploit, which allows you to craft, payloads to send after, and try to accomplish some of the goals of your penetration test. There's password crackers like Hashcat or maybe John the Ripper. So there's a lot of different things, that pen tester may use, depending on the circumstances they come across. And then for us, we also have specialized appliances that we deploy.
We use a Raspberry Pi or just an Ubuntu virtual machine, to put on the inside of your network if it's an internal penetration test that allows us to securely connect to the internal portions of your network and then test those internal portions without having a a person on-site. So you during your penetration test, you could see any number or any combination of these different tools, being used, to find vulnerabilities and exploit them.
Next slide.
So when you're thinking about doing a penetration test, you also wanna make sure that you have budget set aside for it.
This slide gives you a little idea of, what you can expect for your company if you're looking for a penetration test, whether it be just a small network or a small web application, up to large zones and, multiple large networks.
Maybe, you know, you're a Fortune five hundred or something, you're gonna be paying a lot more because you have a lot more assets, a lot more things in the industry.
So this is, meant to give you just kind of a ballpark idea, of what you should be looking at to budget for the penetration test. Next slide.
So now, we're gonna talk a little bit about how to prepare for your penetration test.
And, Gary, what are some of the things that people need to know when they're getting ready for a pen test?
Yeah. Thanks, Gerald. I think, an important question which is, you know, something that is used to a lot of different places, what's my motivation? You know, what do I really wanna find out? What are my requirements?
This really helps a pen test company, know kind of how to approach the testing.
Do you wanna know just know that you're secure for your own self? Do you wanna improve and evaluate your security posture?
Is there kind of an increased awareness that you need to give to upper management in your company? Perhaps you wanna justify security expenses.
Do you want to identify weaknesses, any kind of controls that you think are in place already and just want to have confidence that those are really there.
Perhaps maybe you're having a lot of security incidents and you wanna reduce the frequency and the impact of those security incidents. Those are all kind of reasons, for just wanting to be secure and helping yourself feel better about it. Often there's third parties that require proof that you can be trusted with their customer data and their sensitive data. And other times it's just, you know, I you need to know that you're you have to comply with some sort of legal and regulatory requirements, PCI, DSS, ISO, HIPAA, FISMA, all all these different kinds of, requirements, security requirements and frameworks often will will need that. So helping us as a penetration company kinda know what your goal is, what you need to, will help us, design the best type of a test, for your situation. Next slide, please.
So some of the things that you could expect from a penetration test, You need to take what your goals are that Gary just talked about, what you're trying to accomplish, and match it up with your expectations. So, are you looking for a really deep dive into your systems? Do you want the attacker to just go after, find a small number of vulnerabilities and go after them and see how far they can take him? Or are you looking for your penetration tester to find a large number of vulnerabilities to improve the overall security of your systems?
A lot of times in the industry, you'll hear these terms like black hat, white hat, maybe even gray hat.
So attackers can wear a lot of different hats there.
So black hat is gonna be your malicious actor who's trying to break in and and cause havoc.
Your white hat is maybe someone on the inside who already works at your company, who has prior knowledge of what the network looks like or what the application, is used for because they've used it themselves, and then they have, permission to perform the test.
And then there's, what's referred to as a gray hat, which is kinda somewhere in the middle. Typically, for us gray hats, you are gonna have permission to test the system.
You're gonna not have any prior knowledge of what the system looks like. So, again, you're gonna use those automated tools for discovery.
But the most important thing is you're trying to simulate an attack that a black hat might use that, without prior knowledge or anything coming from a similar perspective of a black hat.
So you can also have authenticated versus non authenticated testing.
So authenticated testing gives the pen testing firm, greater access to be able to actually test your applications or your network, because the penetration test is limited by time.
Your your budget and your time, you can only afford to do so much whereas a true black hat hacker, has all the time in the world to access your system. So they can bypass your external perimeter, security stuff, and then what happens once they get inside, versus a non authenticated test where you're just, simply trying to bypass that information or checking, their password policies to make sure that you can't easily brute force a password, different things like that.
During your penetration test, you should expect some noise or traffic. Penetration testers, like we mentioned before, they're not trying to hide or mask their attacks in any way like a real attacker might.
They generally wanna try to identify the issues as quickly as possible and then, do whatever they can to exploit those issues, again, as quickly as possible. Keep in mind, again, that they're kind of on a clock. So they're not trying to be sneaky or or hide what they're doing like a real attacker might. And then at the end of the, penetration test, what you should expect is a detailed report with all of the issues and steps to reproduce those issues and the penetration tester should really be able to help you improve your security by identifying those recommendations.
Next slide.
So and often a question that people need to ask themselves is do you have an in house resource to your pen test or do you outsource to a third party to do it?
Both are viable. It really kinda depends on on sometimes what if there's a regulatory requirement that that needs it to be third party. But you can use an internal team, but those skills need to be there that we've talked about earlier. They need profession and testing.
They need understanding of how to, you know, look at networks to, you know, exploit them to get into them. They need some proficiency in in maybe the OWASP standard, to help them understand how to get into applications and how applications work. They probably need to have some development skills a little bit. So it's not just really running an automated tool like Metasploit and saying that's you know, now we've done our internal pen test.
And the team doing a pen test if they're internal needs to be an independent from your implementation team. In other words, you wouldn't want a developer conducting a pen test on his own web application. You would want a third a different, hopefully, disinterested party to be able to give the good feedback there.
And, you know, the the internal team probably needs to have good reporting practices as well. In in the past, as an IT auditor, I got a pen test report from an internal guy that all it was was a one page spreadsheet with some IPs and a few notes on it. And he said, this is my penetration test report, and it just didn't pass muster. And and, we needed them then to go get a different pen test from a third party.
You can use then also an external firm to do the work. And, you know, we talked about some of the things earlier, what things you can look about look at in that kind of a company.
They should have those qualifications we talked about. Maybe they've got past experience. How long have they been doing it? Have they assessed similar networks or companies before? Are they as familiar kind of what the type of work that you do?
What technology experience do they have in OS's, network hardware, web application experience, languages, etcetera? So, how having to go through kind of that some of those questions in your mind really helps you in knowing how to find a good penetration test partner. Next slide.
So so another one of the things you can do, to help prepare for a penetration test is, to have some things, for your company. You should have a network diagram that's up to date and maintained along with, a map on how the data flows through that environment.
You should be able to have a list of active hosts that, again, needs to be as current as possible.
And then you should also know what services should be open, throughout your network or available through your web application.
All these all these information, you don't necessarily need to share with your penetration testing firm, but it will help you be ready in case your penetration tester, has any questions, they need to reach out to you, they need a little bit more information, maybe they're running into some kind of issue.
And a lot of times, they may find, an exposed service that you didn't know was available. So knowing what should be available versus what is available, really helps you as a company to know, how effective that penetration test was and how well it met your needs.
Next slide.
Thanks, Cheryl. And that that knowing about your network really helps with this next step, and that's helping yourselves and your pen test company or the whoever's doing your pen test internal, external, should should be able to know, okay, what is the scope? Where do we want to focus our our our testing on?
It's gonna include, obviously, very critical systems that may impact security of any kind of sensitive data is being stored.
Maybe there's an application that's written specifically for your information that you want to have somebody look at.
In the in the payment card space, there's some real specific, areas that are required to be tested, places where credit card data is is stored, processed, or transmitted, and any systems that may affect the security of that. You would want to make sure that, you're protecting people from pivoting into, the the sensitive cardholder environment from a less sensitive area. So all of those perspectives, both internal and external, then need to be to be tested. External being what's available from the Internet, what kind of things you can see, and then internal being if somebody gets inside, what can they do and how could they move around inside your network.
There's been a lot of a big, compromises, that have occurred, you know, over the past number of years, and we get them all the time through our forensics team where people get into a pair a part of the network they're not supposed to be in and then pivot over into a more sensitive area of the network. So understanding the exposure internally in your corporation is almost as as as important as that which goes on from outside.
And again, you know, remembering that you wanna test is it you wanna are you focusing on the network controls? Do you have a lot of applications you wanna test? Communicating those to the penetration test company will help us scope out the amount of work and give you a good estimate of how much time that would take and and give you the kind of information that would we would require to make that an effective and an efficient test. Next slide.
So now I think we're gonna come come coming up next, Charles is gonna talk a little bit about the life cycle of penetration testing so that you can kinda see what to expect while you're going through this process. Next slide.
Yeah. Thanks, Gary. So at a very high level, you can see here, kind of the process, you should have with the penetration test life cycle. It should be something similar to this where, you're gonna get the penetration sets, test scheduled, first of all, so that everybody involved knows what dates it's gonna occur on.
Then you're gonna wanna make sure that you have everything ready for testing. Is the environment ready on your end, and does the pen testing firm have all the information they need to test that environment on their end? Then they're gonna kick off some automated and manual testing, to further assess the security of that. They're gonna write a report and deliver that report to you as the customer.
And then for you as the customer, you're gonna review the report and then, perform any remediation that needs to be done. And then, it's always the best practice to have some retesting done where you send your fixes back over to the pen testing company who will then verify that those were implemented correctly and that everything, is now secure in your environment. We'll talk a little bit more detail about some of these, coming up. So next slide, please, sir.
So, again, for the test preparation side, we need to make sure that the penetration test has been scheduled. You're gonna wanna coordinate with, the pen testing team, and with individuals within your own company to make sure that they're aware that the penetration testing is gonna be performed. You wouldn't want, like, your sock or something, getting these alerts saying that, like, oh, no. Someone's attacking us without prior knowledge. They may accidentally, like, shut off, access to the test, which just delays, the ability and reduces the time that we have to test the environment.
And then you wanna provide as much information as possible that you can, to the penetration tester, reducing the, time it takes to do reconnaissance or like we mentioned before, bypassing external appliances.
So a lot of times we'll be white listed so that we can actually test what will happen if an attacker makes it past the perimeter.
So there are cases where customers want us to test that perimeter, but most of the time, those, appliances given enough time can be bypassed in one way or another.
Next slide.
Thanks, Gerald. As you remember, we talked about earlier, we do a lot of automated scanning, and these scans occur. So fast automated scanning is really part of a pen test, not the whole thing, but typically it gives us avenues and and ideas of where to go. So be sure to think about how that may affect your systems when you would like this done. Sometimes you pick a time of day or or a time when the load is less.
Perhaps, you know, it's not you don't have that that high traffic to your system and won't really matter.
Anyway, then think about, can the test be completed on full up production systems? Are you wanting to do that, or do you have the pen test team focus on duplicate staging instances that you know have the exact same software and features and in the same kind of location, but won't affect, any active customers or things that are going on. Remember, typically, you don't need to do, have a pen test or check the effectiveness of your automated scan blocking systems. Let them get inside and see the real vulnerabilities that might exist.
So part of this, as I said earlier, this that there's a manual or human part of the test and we need to do our we do our best not to impact your systems negatively, but depending on how code is written, sometimes unexpected things happen. Again, consider where these tests, are taking place and when. Maybe you don't do it during your most busy time of the year. We have a lot of customers say, you know, we can't do anything near the Christmas holidays, for example. So you then consider making sure that you plan enough in advance so that you can go early on that. One thing that really helps, a penetration test company, things that you can do on your side is making sure that you're available and responsive. If if we're starting a test and all of a sudden the passwords or the authentication credentials we've been given aren't working, then we, you know, we want those fixed quickly so that we can continue the testing without wasting time.
If we're doing something that's that's impacting your your production environment or something, we wanna know right away so that we can can modify our our testing platforms or or testing patterns and make sure that you're not changing your environment in the middle of the pen test. Sometimes that happens where we're doing something and then it changes and either something goes away or or something new comes up.
So those things can help us. Next slide, please.
So, after the testing has has gone, Tara mentioned that there'll be a final report and it should really have enough detail and be easy enough to read so that you can go see and understand and fix those issues. There's lots of guidance on what to look for in a pen test report, written in a payment card industry. It's from the from the PCI Security Standards Council.
There's a a informational supplement that was written in twenty I think it was twenty eighteen on penetration testing.
We'll provide a link to that in this presentation if you download it later, but, called Penetrating Penetration Testing Guidance.
Oh, it looks like it was March twenty fifteen is when that was released. So keep you know, think about that. Even though you may not be doing, credit card stuff, that's a really great resource for any kind of penetration test, knowledge.
A lot of times in the report you'd like to we mentioned you wanna know how things can be remediated. Those things will be included, in the final report. You're looking for things in the final report that are like an executive summary, high level stuff, statement of the scope, how they did things, what they were testing, their methodologies they lose, limitations that they ran into. There should be a narrative that tells exactly what kind of things they the steps they went through to find, things. And, anyway, stuff they use to clean up their environment, what tools are used, all those kind of things really should be a part of a pen test. It's not just a one page kind of a quick summary of the IPs that they hit and whether they're okay or not. Next slide.
Yeah. Thanks, Gary.
So now that you have the penetration test completed, you've received your report, it's the client, should be reviewing the report, analyzing those findings that Gary talked about, looking to see if the penetration tester has been able to identify the root cause. Many times they can, but sometimes they're not able to, and they're just looking at the symptom, of a of a bigger issue.
And then as the client, you wanna develop an improvement plan. Okay. The these are the results that we got.
Maybe there is a disconnect in our development life cycle that we need to fix, so that anytime we roll out new software, it's a little bit more secure than it was last time.
So, you wanna make sure that you take a close look at those reports and understand what is available in them. Next slide.
And so after you've reviewed the reports, now you you've given that information and the tasks over to your development team or your network team to make changes to the network to secure them. You wanna make sure that, you know, you're installing patches or reconfiguring software.
You wanna make sure that you're, updating the code for any applications. A lot of times we find, simple issues that are just, you know, old OS or or an application that just, has a more recent version.
You wanna make sure that you're, on your network, you're closing off any ports that don't need to be open, that aren't mission critical for you. You wanna restrict access as much as possible, to allow you to still do business, but you wanna make sure you don't have anything extra open.
Those are all avenues that attackers can gain. So you wanna make sure that you review the report and remediate all those issues that were found.
Next slide, please.
And then once you've remediated all all those things, you can send it back over to the penetration testing team. A lot of times, you know, like Gary mentioned, earlier, your development team is really concerned with how does this work and they're not necessarily security experts. So you can send the test back over to, your penetration testing firm. They'll be able to retest, those, fixes that you've implemented and make sure that they were done correctly and that they're, securing your environment as intended.
Occasionally, you know, they may implement something that it looks like it's working on their end and you send it back over to the penetration testing team and we find out that, yeah, you know what?
We can still access it. The the fix wasn't quite broad enough or it didn't cover all the all the different areas. So retesting is, really valuable as well, to make sure that those fixes were implemented correctly. Next slide, please.
Thanks, Cheryl. So now you take a big sigh of relief in the life cycle of a pen test because it's over. And you go, wow. We've done everything.
We've done the retesting. We've checked. We fixed up the stuff that we've got. So now what do you do?
What are things that you can do as a company to make sure that you have a good experience every time you have a penetration test?
So you're really, you know, hoping to make this process, these policy changes to avoid any kind of future vulnerabilities. As you find things that that happen during the pen test, you go back and say, how could we have have, avoided this? How can we incorporate the security into business as usual? How can we do additional training for our developers, for example, or our network engineers? Are we giving them enough time, and resources to actually be successful in designing applications and systems?
Making sure that you continue to do regular maintenance is critical. You know, stay up on your updates. A lot of times, we we see people that will do a pen test and say, great. We're done. Now we don't have to think about anything for a year, and they go off and do their normal kind of quick response to every kind of request that customers make. And they neglect regular updates or port scannings or any kind of application scanning that can be done on a regular basis.
And I think really importantly too is think about your experience during the, a pen test and think, would I like a little bit more time to work on stuff at the end, especially if there's sort of a regulatory requirement to be done in a specific date where you have to show compliance. You may say, well, let's start the pen test process three months earlier or something, so that you can be prepared for, those cycles. Next slide.
So we're gonna be really talking about the takeaways, about done here.
Next slide.
So just a quick kinda summary.
Number one, find a really good partner who you can work with. You know, we've talked about a lot of things you can see and hopefully been able to see some of the qualities and some of the attributes that you'd like to have in a partner for this kind of testing. You wanna be able to feel comfortable, giving and getting feedback both from both people to improve processes on either side.
In our case, we utilize, communication channel via a pen test coordinator, and that's really important to use that interface more rather than less. You know, it's it's the great way to to interact with the penetration test team. We're often very busy doing the actual stuff. It's good to have this kind of a project management interface where you can, talk to people.
Yeah. You also wanna remember, that preparing for the test, is essential for a successful test. A lot of times we get questions, from, the PenTest and the pen test companies. They wanna, make sure that they're ready, and it just helps things run a lot smoother, if both the the pen testing company and the and the, firm being pen tested are prepared and have kind of all their ducks in a row, for a pen test.
Typically, you know, you're not gonna see a full black box test like we mentioned earlier. It just becomes, really expensive.
So the sharing of info and and like Gary mentioned, really, you wanna partner with your pen testing firm. You they shouldn't be seen as, adversarial of the the ultimate goal for everyone involved is to approve this improve the security of your company. So you wanna make sure that that info is shared in a timely manner, and that there's good open communication on both sides.
Thanks. I think the other thing that's important to remember that we've noticed is that remediation often takes a lot longer than you think it will. Plan accordingly and start earlier than you may think on your pen test cycle.
You know, sometimes that's hard to do, especially if your systems aren't quite completed, but you can always then plan for the next test cycle and and get the schedule right. So go early if possible, and be thinking about any kind of regulatory compliance needs that you have.
Yeah. And then finally, you wanna make sure that you're scheduling penetration tests when they make sense for you as a business.
It's always better to do a little bit more on the penetration testing, making sure that your system, has the extra security versus just trying to scrape by with the bare minimum that's required, for, like, a a industry certification or something.
The the kind of pain points you wanna look out for are, like, big changes in the network, big changes to a product, rolling out a new product, different things like that. You wanna make sure that that those are tested before they go live and that they're not introducing any, unwanted vulnerabilities into your systems.
K. So that about wraps it up. Yeah. Good job, Terrell. We're we're if there are any questions, we're able to take those at this time.
Yes. So, one of the questions was from Rodney. Are these required annually per PCI?
I'll take that one, Taro.
Pen penetration tests, for PCI are required annually or and or after any significant change to the network or applications that are being exposed in turn internally or externally. So it really depends then and what we talked tried to define a little bit earlier what some of those significant changes would be if you move from one data center to another, if you, totally change your network architecture, if you changed your hardware that is exposed to the outside or if you've made some large modifications to an application, those represent examples of significant changes. And then the PCI standard actually requires you to run another penetration test, at that time even though it's in the middle of your annual cycle, for example.
Great. We have a question from Kurt. He says, what's the difference between a penetration test and a security audit?
Daryl, I guess I'll take that one too. Yeah. So a penetration test is typically a part of a security audit. A security IT audit, you know, similar to PCI or a HIPAA or NIST type of an assessment, are there the IT audit looks at a whole bunch of other things, on top of the actual physical network and and its vulnerabilities that may be exposed. So an IT audit would look at your software development processes and hopefully identify whether your your developers are having access to the correct training. For example, to know how to code web applications in a secure manner. And we'd be looking for evidence showing that that training has occurred.
Again, an IT audit is really looking for evidence that your processes and your procedures are in place to have continual security and, business as usual security rather than kind of a once a one in time process, a one in time evaluation security, which is more like a a penetration test as a a one time at this point, here's how my systems are configured and here's the vulnerabilities that they are. They may change the next day as your network engineers work on things or as software developers release other versions of your software.
Hopefully that answers that question.
Yeah. So kinda a key there, I think, that you said, Gary, was, a security audit a security audit is looking kind of at policies and procedures of your company, whereas the penetration test, is just focused on the security of a particular network or application appliance that you might have.
Yeah. Kind of to go along with that, someone wants to know what is the difference between a vulnerability testing and a penetration test.
Joe, you go ahead with them.
Yeah. So, typically, a vulnerability assessment, you're using automated tools.
They they don't have any context. They're just simply, like, scanning the network, and looking at different vulnerabilities. And then you're just gonna get, like, almost like an information dump of, like, here's everything we found. Versus with the penetration tester, they may still run a vulnerability assessment, but then they're gonna examine those results. They're gonna come through those. They're gonna go after the services that are most likely to be exploited, and then they're gonna give you, a better picture of what an attacker might do and what you might see from an external threat.
Where, again, vulnerability scans being automated, they just they lack the context. They lack that, as Gary put it, they lack that, human brain, behind the behind the test. So you're not getting the same, like, reasoning.
A lot of times automated scans aren't able to see, the commonalities between two different applications, and maybe you've you know, they report vulnerability in one thing and not the other.
Whereas a human can see like, oh, the same developers worked on these, so chances are, you know, simpler mistakes may have been made. So let's go over here and see if we can find something that might not have been as obvious, that an automated scan would pick up.
Great. Thanks, Terrell.
Marine is asking, what are the risks of using a third party company to do pen testing for an organization?
Is it recommended Which is recommended? Internal independent pen testers or a third party firm doing it?
I think that really, kinda depends on what your goals are, as a company.
You know, when looking at a third party penetration testing, like we mentioned earlier, you really wanna make sure that you've done at least a little bit of research on the company that you're choosing, and, you know, maybe even have some phone calls with, the folks over at that company.
Potentially even get some, like, sample reports or something, to talk about their process and their approach to penetration testing.
It's important to feel comfortable with the third party if you decide to use a third party.
And if you do go with an in house penetration testing, again, like we mentioned, you wanna make sure that these individuals, are in a separate department potentially and and hopefully even under different management than, like, a development department was.
So that they have kind of the freedom and autonomy to, testings and report things, that are broken without worry about, you know, getting their friend in the next cubicle in trouble for it. And the point of the pen test shouldn't be to get people in trouble. It should be to improve your security. So if you can accomplish that, in house and you have the setup to do that, that's great.
Otherwise, you know, third party companies out there, do a little bit of research on them. And then just be aware that some standards or regulations might require you to have a third party conduct that penetration test as well.
So Yeah.
And let me let me say with this one quick thing, maybe another kind of aspect of the question is that is it safe to use a third party?
Again, I think that's gonna have to be some due diligence as Terrell mentioned on the part of of the company, you know, who wants a pen test. Are there really good and trustworthy people out there who are just trying to help you and and won't release your data? Of course, there are. I mean, that's there has to be.
But, you know, you can ask for references. We we we expect people to to check and call and and check our references. That's not a problem with us. You know, if if if they won't talk to you except by email or some dark web hack chat channel, then maybe those guys aren't the best ones to go with.
But, it should be a a really above the board. Typically, we have, companies like this. We have, liability insurance for all of our pen testers, etcetera. So that, it's a real legitimate type of a relationship rather than and you don't have to feel worried about us releasing your data or anything like that.
But, you know, are there bad actors out there that do that kind of stuff? Maybe there are. I'm not aware of any, but I'm sure that they're I don't have experience talking with any of them, but there might be. But you should feel comfortable going with a business industry standard kind of a pen testing company.
Great. Ricardo here asks, from your experience, how many companies succeed in their penetration test? Meaning that they aren't vulnerable.
Harold, you've got this one.
That's a tough question.
Keep in mind, a penetration test is just a a snapshot in time, and it's also limited by the budget and the amount of time that the, analyst might have to test it. So, for example, you know, if if you have a rather large network and, you're only giving your pen penetration testing from one day to, examine that network, well then likely you're gonna come away with a pretty clean report, if not a totally clean report.
And and, you know, is that success? Well, maybe, maybe not. What it does tell you is that, in one day, an attacker isn't gonna be able to, you know, exploit anything on your network.
So it's not necessarily, a success fail, scale there.
We do see, a fair number of companies that walk away with, a clean test.
But again, being that it's a snapshot in time, just because it was, you know, we didn't find anything this year doesn't mean, that we won't find anything next year. We also, for our company, we try to, spread out the penetration test so you don't have the same analyst working on it year over year. That way, you just get a different perspective because different people, have different specialties as far as their skills go.
And so what one analyst might not uncover one year, another analyst might uncover the next year.
So I mean, it it's still good even if you come away with a clean report. I mean, that that's great. But just keep in mind that that doesn't necessarily mean that there are no vulnerabilities. It just means, you know, given the time we had, we weren't able to find anything exploitable in your environment.
Still a great sign, but, you know, and you should feel proud of that.
But it doesn't it doesn't necessarily mean that there's zero vulnerability in the system.
And I think as far as far as my experiences as an as a an IT, you know, consultant over the years, there's almost always something whether they're minor or major. And and, you know, we we actually our pen testing gets pretty excited when they do find something major and not that that we want to expose that and and point the finger. It's more like, look. We found something that they can really fix and really address.
So those are really exciting for us to to be able to help people with. And, you know, during the the process of looking at these over the years, the past fifteen years, you know, like I said, almost almost all of them find something, but it may not be, you know, the super critical kind of stuff.
Great. So it seems like we've had a few questions about, on-site versus remote. Could you guys cover that real quick?
Yeah. Let let me talk for a second about that.
There's a both perspectives, I think, are are good. Obviously, if you're testing from an external perspective, from the Internet's perspective, remote, you know, doesn't make make a big difference whether you're remote or not.
An on-site penetration test with a a a guy in your network, there can be real advantageous.
You know, you may ask questions and go around and look at printers and all that kind of stuff. It's typically, more expensive.
And, there are remote techniques that can be used to place a, a pen testers tools basically inside your network via, VPN tunnels or or other types of things that can be almost as effective, looking for those vulnerabilities. So, you know, is there a is there a difference? Yes. There is.
And and you really just kinda have to decide what, what you'd like to pay for, you know.
Yeah. And and also, like, think about what your goals are for the penetration test.
Are you looking to just test your internal network and your internal, you know, appliances you have running, then you may not need someone to come on-site. If you are interested in things like, we wanna see if people can gain access to our building, And, can they, you know, can an attacker just, like, walk in and set up shop in a cubicle somewhere and gain access and just plug their computer right into the network and then they have access to whatever information.
You know, are you looking for something like that? Well, then you're gonna want an actual person on-site, so that they can try to bypass those physical security requirements, as well as, whatever network stuff you might have. So I think, you know, think about what your goals are for the penetration test.
Yeah. And that and having sometimes a person on-site actually trying to do those social engineering things, can be slightly dangerous for the penetration test company as well. You know, if if the legal system isn't really aware of what's going on, sometimes confusions are made and and, so that's a little less I mean, people do it. It's pretty expensive. And, it's a little bit less of of you know, we typically don't do that kind of stuff because of the other ramifications that may be there. So there's my perspective on that.
Great. So it looks like we've come to, we're a couple minutes after the hour. Do you guys wanna answer one more question, or should we just wrap things up?
Oh, one more.
Okay. Let's do one more.
So, Matthew here asks, what standard are your recommended remediations based on? Is it on NIST or PCI?
So I'll take that one.
So we try not to only reference one type of remediation.
So we, may direct you to, like, an OWASP, or we might direct you to NIST or we might direct you, just to a common security practice.
And it also kind of depends on what your purpose for the penetration test is. If you're conducting the penetration test for, like, a PCI, assessment, then we're gonna try to reference everything we can within that PCI scope, so that, you can kinda map that back to a requirement in PCI.
If it's just an elective test where you're just trying to improve the overall security, you may get a much broader selection of where that remediation comes from.
My team typically tries to give you, two to three options, two or three different ways to remediate an issue, and we'll, give you references, and and cite different, best practices to do that.
But ultimately, we leave which one of those you choose.
It is kind of up to you as the as the consumer, and as the receiver of that report to figure out which one of these standards make the most sense for us, which one is gonna be easiest for us to implement, and then, go with that one. So yeah. Summarize, we kinda reference, any industry best practice regardless of where it comes from.
Great. Thank you guys so much. I think with that, we'll wrap up the webinar. And for those of you that we didn't answer your questions, we will reach out individually to you. And also a reminder that we will be sending out a recording of this webinar within the next couple of days. So keep your eye on your inbox for that. Thank you, and thanks for joining us.
.svg)
