Skip to content

Best Practices

Best Practices

Unique and Specific Procedures

For VECTR to track results of Purple Team activities over time, some way is needed to uniquely identify a specific test procedure. The MITRE Technique or Sub-Technique ID is not specific enough to accomplish this. There may be many unique test procedures for T1047 - Windows Management Instrumentation, for example. It's important to create individual tests, confirming detection and response for each of the different attack scenarios that may be categorized by a specific ATT&CK Technique. To accomplish this, VECTR's Test Cases align to the MITRE Enterprise ATT&CK "Procedure" concept, and VECTR uses Test Case Templates to uniquely identify a test procedure. These templates can be managed in the Administration section of the application described below.

Local vs Template Data

VECTR's Assessments are located in a Database. Each Database represents a logical testing environment where you may track related tests over time. When creating Test Cases and measuring detection, we refer to this as "Local" data in contrast to the templates mentioned in the previous paragraph. A local Test Case in VECTR represents a recorded execution of an attack procedure and its defense response at a specific instance in time.

Local Test Cases

Local data in VECTR is contained in a Database. All Test Cases are performed in a Campaign which in turn is inside an Assessment.

VECTR Local Test Cases

Test Case Templates

Test Case templates are contained in the Administration section of the application. Each of these is a description of a specific attack procedure that you may perform once or multiple times when testing an environment. Heed the note on the importance of naming below. Aim for as much specificity as possible when naming Test Case templates.

VECTR Local Test Cases

You should almost always be creating your local Test Cases from templates or mapping them to existing templates.

Naming

Naming is very important! Test Case templates should have very specific, detailed names that are unique to what they do. There are currently many ways to perform almost each MITRE Enterprise ATT&CK Technique and sub-technique. There will continue to be new Techniques identified in the wild as adversaries evolve, and there will continue to be new Procedures identified that map to each Technique. Name them carefully so you can clearly identify what you're testing and understand where your gaps in detection and prevention exist. Assessments should also be clearly named to describe the activity for easier reporting.

For example:

  • Good Name: Manually call schtasks.exe to create a Scheduled Task
  • Bad Name: Create a Scheduled Task

The reason the 2nd example is a bad name is because there are a lot of ways to create scheduled tasks beyond just running schtasks.exe. There's a footnote in the detection area of the ATT&CK framework for this that says "Remote access tools with built-in features may interact directly with the Windows API to perform these functions outside of typical system utilities. Tasks may also be created through Windows system management tools such as Windows Management Instrumentation and PowerShell, so additional logging may need to be configured to gather the appropriate data."

It may be beneficial to create additional Test Case procedures for those other methods or scheduled task creation to determine if your detection, prevention, and log aggregation measures are properly tuned to catch those as well

Tagging

Tag everything. Use tags for fix priority. Use tags for things you want to retest. Tag anything you want to follow up on. Tag with specific people's names. Tag anything that you had trouble reproducing or want to document.

Tags make reporting and sorting your Test Data a lot easier once you have a lot of it.