Skip to content

VIDEO

Runbooks Module

Today’s episode covers PlexTrac’s new and improved Runbooks module, and showcases the module functionality when it comes to purple teaming, tabletop exercises, and adversarial simulation/emulation activities.

Series: PlexTrac MiniDemo Series

Category: Product Features, Purple Teaming, Runbooks

   BACK TO VIDEOS

Transcript

The Runbooks module within the PlexTrac platform is meant to be used when organizations want to perform collaborative testing, typically across teams. The types of engagement may be classified as threat emulation or threat simulation, also at times known as Purple. Teaming test plans within the Runbooks module are also useful when a set of procedures needs to be established that can be reused for testing activity. I’ll showcase using existing test plans as well as creating custom procedures, techniques and tactics that can also be used to create other test plans within Runbooks. Here we’re looking at a test plan that I’ve already created. Let’s take a look at it.

We see here the coverage of the techniques that the procedures within this test plan. We see 13 procedures here are going to cover. These procedures are within the PlexTrac platform already. The platform ships with all of the atomics from the atomic red team, which are procedures that are available on GitHub that map back to Apt activity and are also already mapped to Mitre attack. So when I created this test plan, I had selected these procedures. I’m going to start an engagement. From this existing test plan I’ll choose a client and we will begin.

When you begin an engagement from a test plan, you also have the opportunity to not only give it description and tags and change the title of the engagement, but you can also choose which procedures that you want to use in the test plan. Now when I created this test plan, like I said before, there are already 13 procedures. But I could also search by different procedures filtering by a specific methodology, a tactic or a technique, or by the tagging or the specific repository to find more procedures to add in an ad hoc fashion for this specific engagement. I’m not going to add anything in this case, but you do have the opportunity.

Now I’m going to create this engagement.

We drop right into the engagement view of the test plan. From within the Runbooks module we see the different procedures apart of the test plan listed out here. Now we can begin executing. Of course we always have the opportunity to edit any of the engagement details or ad hoc add procedures if we need to during this run of the test plan.

Once we hop in, we see the dashboard for the test plan and we see the ability to determine the status of the procedure. So I’ve begun this. I’m going to say that it’s in progress.

We can see the different techniques and tactics that this maps to and we can also decide to add operators. We could add red team operators or Blue team operators if we’re so inclined. The steps in this procedure are going to be displayed below, but here we have some metadata, the title and the specific description of the procedure. And here we have an execution step. Now procedures may have multiple execution steps with success criteria in this example, this is activity that would be performed to emulate a certain type of threat. We would go to a computer and run these commands and from a red team perspective we can detail the fact that this was successful or not based on our perspective and we can say this is something that we did. We can also decide to add assets to this.

Perhaps we want to add from existing assets in the project.

Once these assets have been added individually, we can determine whether the procedure from a red team perspective in this case was successful or not. So in this case we’ll say it was successful on this host and it was failed on this one. We can decide here if we want the outcome from individual assets to show up on the report by toggling the slider. We also have the opportunity to enter log information here, time and date stamp.

When we observe the activity, we could attach files as well as add general notes. Similarly, in a collaborative fashion, the other team, perhaps it’s the blue team, can come in and just say this was detected and blocked. And from the blue team perspective on this host, we can say it was detected and alerted, but it wasn’t blocked. And perhaps for this one we can say it was detected and blocked. We can similarly add logs, attachments and notes. As we progress through each of these different procedures, we can add in information. So for this one I’m going to change the status to complete and perhaps the outcome of this procedure we want to include as a finding in our report.

You’ll see the difference between a procedure and a finding in a bit from an operational view, we can go back to the engagement section of the Runbooks module to see the different test plans and engagements that are running. So in this case I can see that the title of the engagement is Purple Team Test plan. The test plan in use is the same because I didn’t change it. The client is against the date that the last update occurred and the progress. So we can see that this engagement is 8% done. Once we click to the view, we can get an overarching view of the procedures and their status. So as you work through these procedures, you can see the status here.

Now, when you are completed with the activity of the test plan, you can submit this engagement from the Runbooks module and it becomes a report in plex tract’s core functionality. Let’s do that now.

Now, this test plan has become a report underneath this client. We noticed that in the user interface we have a new menu option and that’s procedures, all of the procedures that were in the test plan are listed out within the report. We can see the one that I had included as a finding notes as such here and all of these procedures can be edited after the fact to add in more information, change the attack outcome from a red or blue perspective, add different operators, add assets affected, et cetera, et cetera. If we look at the findings for this report, we’ll notice that we only see one finding. That’s because the outcome of that procedure was the only one that I had added as a finding. So we can interact with the finding as you would normal findings within the PlexTrac platform, edit the details, add in your information, et cetera, determine the host affected after the fact. We also have the opportunity to decide the outcome of this procedure.

We would like to add this as a finding as well so we can choose to add to the report findings. And now it has become a finding in this report. If we go back to Runbooks, I also wanted to mention the capability in creating your own test plans. Now you can import test plans from miter the community threats as well as the Side community threats to take in test plans that have already been created. However, you can create your own test plans and choose from a selection of techniques, tactics, and procedures. Before we look at creating a test plan, I want to also showcase creating your own procedures. Here we have repositories within our Runbooks database.

The Runbooks database is part of our content library within PlexTrac. The repository structure allows you to create repositories of different permissions.

We can have Open manager, private and also assign different users to these repositories. And these repositories can be where we create our own custom procedures. You also can create your own techniques and tactics. You could even create your own methodology, which allows you to create a mapping if you have an organizational specific framework. Or you don’t have to have a methodology or framework, nor custom techniques and tactics. You could simply create your own procedures. I’m going to create a procedure now to showcase that capability.

We’ll call this procedure title custom recon. We’ll give it an ID and we’ll determine the repository that we want to save this custom step here, we do have the capability to add in techniques if you want. We could search for techniques that already exist in the platform, or we could also earlier have created a technique in a custom fashion. We can also give execution steps. We can decide to add success criteria if we’re so inclined, and we can also add multiple steps. We’ll now save this procedure. We get a warning that says we have not associated a technique with this procedure.

Associating techniques is valuable for metrics later when you’re looking at the analytics. For the sake of this demo, I’m not going to add a technique.

Now. We can create a test plan within the PlexTrac platform.

I can choose an existing test plan to act as a base, or I can start from scratch here. We can choose the different procedures that we want to add into this test plan. I could search for specific techniques or tactics. As I said before, we could also filter based on the repository, I’ve created a custom test plan and similarly, I could execute an engagement from this test plan. We’ll just take a look at what that looks like.

If we look at the custom procedure that I created earlier, we’ll notice there’s no mapping information. I don’t have any techniques or tactics mapped here, but we see we have a similar experience before. Here we have multiple execution steps for one procedure. Market is successful, a test to completing these steps, et cetera. Test plans within the runbooks module PlexTrac really allows organizations to collaborate effectively and create reports on collaborative engagements like Purple teaming and threat emulation campaigns.

Key Points.