Introduction

The action of baselining in reference to a security validation program and using a tool like Mandiant Security Validation (MSV), is the process of running a core set of tests to evaluate the effectiveness of the controls in your environment to provide a basis of data.

This data is used to help evaluate how successful (or not) your technical controls & remediation efforts are operating.

Baselining does not have to include every single action in the library, although it could. 

We typically don't recommend throwing “The whole kitchen sink” at a baseline, as it gets more difficult to prioritize and effectively manage any remediation efforts when running hundreds of tests at a single time.  Baselining is generally broken up by three use cases, those being endpoint core controls, network egress testing, and lateral movement.

In the following subsections we will explore the different use cases and how we quickly build baselining for each. We will make use of the MSV action library to build the baselines and store these baselines as evaluations in your director to allow easy access (and modification) over time.

MSV Deployment Requirements for Baselining

To do baselining, we need a subset of the MSV components deployed and configured. The director should be configured and include the latest content packs (either manually downloaded and applied or through the content service). Minimum actor deployment should be completed:

• One endpoint actor
• Two network actors deployed internally
• Externally hosted network actor  

It is highly recommended to have also included the SIEM integration completed, (but there are instances where this may not be possible.) Each use case outlined in the rest of the blog has additional requirements that will be noted in their respective sections.

Use Case 1: Endpoint Core Controls

Endpoint core controls focus upon the security technologies and policies on the workstations in your environment.  This includes AV & EDR products as well as any policies implemented on the workstation.  For the purposes of this blog, we will focus on the Microsoft Windows endpoint as that is the most common platform used by our customers.  Other operating systems can have baselines built following the same methodology, but it is expected that the actions chosen will differ.  Testing endpoint core controls focuses upon Host CLI actions designed for the respective OS.

To start the baseline for Windows endpoints, we filter the action library to a subset that’s directly applicable for testing. Navigate to Library > Actions. 

Figure 1: The MSV Action Library where actions to run are selected from

To begin sorting, we use the dimension filters on the left side of the screen to start filtering the action library (currently at over 4500 actions) and select the following Dimension Filters:

Table 1:  Library filters to set for narrowing down actions to endpoint action types and controls

By default, the results provided here include actions intended to run as SYSTEM, Admin, and regular Users.  Further, this covers all Windows OS versions that MSV provides actions for. For the purposes of this blog, we will assume baselining is occurring on Windows 10 systems.  Therefore, we add a tag search for: ‘OS:Windows:10’.

Endpoint baselining is split at this point based upon user level: SYSTEM, Admin, User.
Here we will work with actions running with SYSTEM privileges, as Admin and User requires an Action User Profile to be built. (The process for building the evaluation is the same, just swapping tags as we see below.)

To build the SYSTEM User Windows 10 Endpoint baseline, we will apply another tag filter using the ‘RunAs:SYSTEM’ tag.

We will select actions from this list (could be all 300+ actions using the Queue button and saying ‘New Evaluation from All’) and add them to the queue for building the evaluation. 

It is highly recommended that the actions in the following table be included in any Windows OS baseline evaluation. However this is a suggestive sample of what to start with. Your organization may want to include additional tests and VIDs (Unique Action IDs) that are important to your team as part of your baseline. 

Table 2:  A sample of recommended actions to include in a endpoint core controls baseline test

Once the actions are added to the queue, select the queue button to be sent to the Action Queue page, or you can access it from the Jobs > Queue menu option.

Figure 2: Accessing the Action Queue after adding several actions to run

Figure 3: Managing the unassigned queue and moving them to current actions

We select the top action and shift click on the bottom action to select them all.  Drag all the selected actions down to the table called “Current Actions” to add them to the evaluation.  

Figure 4: Reviewing the current actions selected to run

In this example, we only have nine actions. It is likely that there are more actions listed in the evaluation you are building. Use the plus (‘+’) symbol to break the actions up into different groups.  As a best practice, no group should have more than 25 actions. Limiting the actions per group helps to ensure that the Windows endpoint can handle the load of having the action package running on the system.

For Test Type, select Evaluation.  It is advised that you DO NOT select sequence as the Test Type. 

Each baseline evaluation built by you should be in the recommended format of “MSV - Baseline - Baseline Type (- OS Version, if applicable) - Quarter Year” to easily allow it to be found in the MSV Evaluation Library.

We will choose to save the test as an evaluation and the name ‘MSV – Baseline – Windows 10 - <<Quarter>> <<Year>>’ following our naming conventions.

Example: MSV - Baseline - EndpointCore - Windows - Q3 - 2024

Once the groups are organized (and labeled as desired), click the ‘Save’ button at the top to go to the “Create Test” page.  

Figure 5: Reviewing the current actions selected to run

Select ‘Save’ to save the evaluation.  Your evaluation is now ready to run against an endpoint actor. 

Before running the evaluation baseline, we strongly suggest that you Tag your evaluation. If you view the evaluation from the Library > Evaluations navigation bar at the top, when looking at the preview window there is a User Tags section which allows you to add custom tagging.  This feature is very useful for when you are developing reporting for your baseline testing, and allows you to focus reporting on just your baseline evaluations. 

Figure 6: Adding User Tags to Evaluations from Preview Screen

Use Case 2: Egress Baseline

Egress baseline testing focuses on network security technologies and policies; and reviews internal to external activity.  Egress testing requires:

•  An internal actor and an external actor (MSV Cloud Service Theater/Cloud Actor or customer build external actor) be deployed.
• Proxies required for external access must also be defined in the MSV director and be accessible by the actors involved for this testing.

As with the Endpoint Baseline example described previously, we start out with setting some default dimension filters on the Action Library page to start trimming the action list to build an evaluation.  Remove all previous filters and tags.  The starting dimension filters are:

Table 3:  Library filters to set for narrowing down actions to endpoint action types and controls

Further, egress testing focuses upon internal assets accessing external untrusted assets.  Search on the tag: Src:Internal:Trusted+Dst:External:Untrusted as shown below:

Figure 7: Adding Tags to Filter Actions

It is highly recommended that the following actions are included in any egress baseline evaluation:

Table 4: A sample of recommended actions to include in a network egress controls baseline test

When building the evaluation, groups of 25 actions maximum are recommended.  This allows both network actors and endpoint actors to be the source for the execution of these actions without applying too much load on the actors. To save this evaluation, we will use the name:

“MSV - Baseline - Network Egress - <<Quarter>> <<Year>>” for this baseline.

Use Case 3: Lateral Movement

Lateral Movement baseline testing focuses on network security technologies and policies associated with segmentation and internal controls.  Lateral baseline testing requires:

• Two internal actors deployed in multiple zones. 
• If the systems need a proxy to communicate internally, these must be defined in the MSV director and both actors should have access to said proxy.

As with the Endpoint Baseline example described previously, we start out with setting some default dimension filters on the Action Library page to start trimming the action list to build an evaluation.  The starting dimension filters are:

Table 5:  Library filters to set for narrowing down actions to endpoint action types and controls

Further, lateral movement focuses upon internal assets accessing other internal trusted assets.  So we will also search on the tag: ‘Src:Internal:Trusted+Dst:Internal:Trusted’ as similarly demonstrated in the previous Figure 7. 

It is highly recommended that the following actions are included in any lateral movement baseline evaluation:

Table 6:  A sample of recommended actions to include in a lateral movement controls baseline test

When building the evaluation, groups of 25 actions maximum are recommended.  This allows both network actors and endpoint actors to be the source for the execution of these actions without applying too much load on the actors. To save this evaluation, we will use our previously used naming convention but update it for the testing type:

“MSV - Baseline - Network Lateral Movement - <<Quarter>> <<Year>>” for this baseline.

Additional Consideration and Next Steps

There are some additional items to consider once you’ve created your baseline evaluations: 

• Understand the source and destinations of traffic within the MSV Actions:
  • With network actions, ensure that you set the correct actors within your source and destinations, as this is crucial for testing results to be correct and accurate. Be sure to check out our documentation page for additional information on how to use the MSV network map when running your sequences and evaluations.
    
    
• Schedule your baselines to recur consistently:
• Using the scheduling functionality, you can set your baselines to re-run on a periodic basis which can help to show how your remediation efforts are performing over time.  This particular page on the documentation site illustrates how to schedule a recurring job once you’ve created your baseline evaluations.

• Use Tagging on actors, actions, sequences, and evaluations helps classify security content, and can assist with reporting in report builder: 
• Using tags can help you organize and sort the security content of the MSV platform, and help to assist in creating reporting builder reports when you perhaps only want to look at data tagged with a specific testing campaign or generate reports for assets only in certain security zones.  We suggest starting on this page and learning more about how you can use Action Tags as well as Sequence and Evaluation Tags.
  
  
• Setup reporting within the report builder functionality to track validation and remediation efforts: 
• We will be covering the details of how to set up report builder templates for this baselining in an upcoming knowledge base or blog release. In the meantime, check out our documentation page for Mandiant Security Validation reporting information. 

Conclusion

Baselining is critical to building a security validation program in your organization using MSV.  As shown, it is relatively easy to build evaluations to start exploring the security readiness of the environment where MSV is deployed.  If these baselines are developed as actors are deployed in the environment, it is easy to test after deployment (with applicable use cases) and then test again later in the deployment to look for differences over time. 

The goal with these baselines isn’t just to find one-off concerns in your environment; in fact, baselining allows you to remediate security concerns, and then test those remediations and fixes in a controlled manner. Effective baselining and retesting establishes the cornerstone of a validation platform, but remember the baselines should also evolve and update over time. New periodic baselines must be developed and tweaked to include actions and validation tests that are relevant to your organization’s risk profile.