Penetration Test Phases 1 and 2: Setup and Discovery

Transcript

Welcome to A Cup of Joe. Today I want to talk about the phases of the pen test and how to use the PlexTrac platform to support phases one and two.

If you search for pen test phases, you’re going to come up with five standard phases, typically described as discovery, enumeration, analysis, exploitation, and post exploitation. At its most basic, these are the phases of pen testing and that extends to any sort of pen testing red teaming, physical security, social engineering, the whole lot. But as a practice director, I needed to take a step back and look at the whole picture because I wanted to be sure to categorize phases that required different stakeholders or significant context switching. So after more than a few years of doing this, I came up with ten phases. Now, depending on your practice or internal group, some of these phases may not exist in your process. And I’m not asking you to adopt what doesn’t work, just recognize that there are additional phases that you might want to address discreetly for better practice management and engagement. Efficiencies.

So in my mind, they go a lot like this.

All right, phase one. This is our set up. This is everything from the end of the sale before we begin the engagement. And then our second phase would be discovery. This is actually part of the engagement. This is where we’re going to begin to throw packets at our targets. What we learned in Discovery may force us to have to go back to the setup and reevaluate.

You never know. Enumeration. This phase of pen testing is where we’re then going to determine we’ve identified assets and IPS personnel, what services, what features are running on them. Then we’ll move into the detection phase where based on these services that are running, are there any vulnerabilities? How can we use this information to move along the attack chain? And that’s where we move into Exploitation. Exploitation is our very first initial vector where we’re finally on the network or we’re inside the application, or we’ve completed our initial successful social engineering. Post exploitation is that piece where now we move from persona and perspective to persona and perspective, always looking for slightly better credentials. We’re looking for different views of the network.

We’re looking ways to move towards our ultimate target. And this is where we’re going to put the attack chain together from our initial vector to our final success criteria, whatever that was described during the setup. Then we’ve got the reporting phase. And this isn’t the most fun phase, but this is where we’re going to bring all the information in. We’re going to make sure it’s set up in a cohesive actionable way. We’re not trying to hide how we got there. We’ll have exact syntax.

We’ll give them everything we did so that they can reproduce it themselves. And then we’ll take this information and we’ll have the read out phase. This is where now the customer has an opportunity to give feedback. Maybe this isn’t a regulatory test. If I don’t have any control over whether or not they have to fix it or they have to believe me, then during the readout they may come back to me and say, you know what, we’re not 100% sure that this is true in our particular context. We don’t agree with the severity level that you gave you. That’s fine.

I’ll go back then from the read out, go back to phase seven, modify the reporting, make sure that whatever I finally deliver to the customer engages them enough that they want to move on to remediation. Phase nine, and we’ve all been on a pen test where we looked at the old pen test from last year. We go out to the client and we start to throw packets of the targets and everything is still there. They didn’t fix anything. Well, part of that is how they valued our original report. Was it credible enough? Did it articulate the risks properly? Did it provide them with some motivation or initiative to want to fix any of this? When you’re in a regulatory regime to ask your FedRAMP or your PCI or your FFIEC, they have motivation to fix. With PCI you have to fix it or you just fail that requirement and then you fail the whole standard.

So the motivation to fix things is a little bit higher. But if this is a pen test where we just woke up one day and thought, hey, we really need to focus on security, let’s go get a pen test, I may not be as motivated to fix things, but if I am, then the very last phase would be that final testing. And final testing is always a little bit beyond what you found in the original test because that remediation might have disturbed the environment a bit, it might have introduced new vulnerabilities. So I always try and set expectations with the client that, hey, I’m going to go back and do your final test. After you fixed it, just going to look around a little bit more, make sure you didn’t uncover anything else. And those in my mind, were the phases that I needed to get everybody involved in and document separately so that I could effectively approach each phase. In this Deep longing series, we’ll touch on all of them, but today I just want to focus on the first two.

Phase one, the setup is the most important. I mean, screw this phase up and it all goes south and never gets any better. Now here you’re going to have sales, operations, your operators or pen testers, and maybe your client or your internal customer. All involved communication during this phase is going to be fast and furious and it will include a metric ton of documentation. We start with the NDA. You might have a Master Service Agreement or an Sow client info, the scope, rules of engagement, policies, procedures, and so forth. Now this is also the phase where you’re going to have a ton of meetings, internal and external, pre, kick off meetings, kick off meetings, update meetings, meetings with the client and meetings without the client as the saying goes.

Can some of these meetings be an email? Maybe. If you’ve got a good way of tracking all your information and your documents then you should be able to cut down on some of the face to face meetings. Now the setup phase is also where operations are going to choose the reporting template. Now with some practices and MSSPs having a dozen or more templates, it’s good to get it nailed down now for the operator, so they have to scramble for details of which one they’re supposed to use the end of the project. Now phase two is described as discovery and this is the start of the actual engagement. The results of this step could mean though you may have to go back to phase one and reevaluate the setup phase and discovery can impact the scope and it can even impact the price of the engagement. How can PlexTrac make these phases easier and more effective? Well, let’s start with phase one.

Who’s important in this phase? We’ve got sales, operations, operators, your client and your customers and we need to be able to get all of them on the platform. And with PlexTrac, that’s actually pretty easy to do.

I can go in and add users using the account Admin, Security and User Management Users button. From here I can add individual users or I can import users from a larger CSV file. This way I can set up my engagement or my client with all of the stakeholders that need to be participating in this phase of the test. I can give them specific roles so that they can read only. And then our customer success team can help you set up specific role based access controls for more granular setting of permissions for different parts of the engagement. Now, I’m pretty sure that everyone has all the information and access to all the documents that are necessary. I’ve created questionnaires inside of the assessment module and these questionnaires I can use to capture all the information about the engagement.

For example, I’ve got the rules of Engagement questionnaire, I’ve got the scope, I’ve got a statement of work, I’ve got the original proposal questionnaire. I’ve even got things like policies that I can have that are specific to the customer or specific to the engagement, like the use of personal equipment. In this one I would be able to attach the document and then I can assign these questionnaires with the test or with the clients that I’m about to begin the engagement with. That way all of this information is in one place at the same time. Now, to show you let’s begin the rules of engagement, I’ll choose the client, begin the assessment. This pops me into the rules of engagement. Open this up and I can go about writing the rules of engagement down in a free form text file.

Or if this is a document that was provided, then I can go ahead and attach it to this. When I submit it, it has been attached to that client engagement. I’ll go in and I’ll be able to see it. Each of these assessment questionnaires can be customized for your particular process so you’re not having to kind of reinvent the way you do business in order to use the tool. The other thing that I like about the workflow here is that the operations team can set up that initial report template so the operators have a starting point for their engagement as they start to do the discovery process. So if they’re selecting the reports and have assigned it to a specific report, this is the format they’re going to use. For example, this is a PCI Pen test report.

This is where the operator is going to do all of his reporting activities and data collection activities as we go into the discovery phase. Phase two, we can use the Asset tab to import assets or add additional assets. Nmaps, Nessa scans, whatever. Use that so that we can compare it against the scope, which is in one of the assessment questionnaires. So again, it’s all at our fingertips. It’s all in one place. I don’t have to go anywhere to get it.

I can also use the Artifacts tab to upload screenshots. This is really good for if you’re using run logs. If your team documents everything that they’re doing during the course of the engagement, you can upload your run logs in here. And then this becomes available for the team lead or a specialist to come in later and look and say, okay, did we do everything? Yeah, it looks like we have, because we’ve got all the documents up here. We’ve got all the artifacts from the test. They can go through the run logs. They can see if anything was missed.

So the operations team can also use the artifacts section and the rest of this report building framework to make sure that the test is complete, that it’s ready to go to the customer. And it’s just much easier to keep an eye on the comings and goings of the different aspects of the test during phase one and phase two. Hey, that’s all the time we have for today. Don’t forget to hit the like and the subscribe button to get the latest cup of joke content and ideas. My name is Joe Perrini. I am PlexTrac’s Product Evangelist. Wishing you happy hacking.