best practices for first actor deployment

Mandiant Security Validation is a great tool to see how your technologies respond “when something bad happens”.  There is a methodology that we have used on the Customer Success team to great success with both small and large customers.

First, let me outline the methodology at a high level, then we will get into the weeds.  There are a few components necessary to do this methodology, so let’s talk about those first.  You need a director (the brains of the MSV system), a cloud actor (something not on your local network that can be an untrusted asset that we run tests against), and an endpoint actor.  (Think of your Windows 10/11 workstation that is used in a particular zone.) For bonus points, in the same zone as the endpoint actor you can do a Network actor, which will allow us to do more tests later on. 

With these three items (notice I haven’t mentioned integrations yet) you can start testing with MSV! We start off with endpoint controls and in-out network testing. (Endpoint controls would be having things like Mimikatz executed to see what happens.  Network testing would be malicious file transfers like trying to download a Darkside installer.) What we would do is run a series of tests (actions) on the endpoint actor to see what happens, then run network actions using the endpoint actor as the source, and the cloud actor (external actor) as the destination. (Can we download Darkside? What happens if we try to upload PII to an external entity?) Once we get basic test results in that zone, we can deploy another actor (or two!) in another zone to do more testing.  Once there are 1 internal endpoint actor and 1 internal network actor in a different zone, we can do lateral testing.  (That is, what kind of things can we do between two zones like move data or complete scanning activities.) The big game plan is as follows:

1. Deploy an endpoint actor
2. Run endpoint controls tests
3. Run up-down network testing between endpoint actor and the external actor (likely cloud actor)
4. Deploy a network actor in another zone
5. Run lateral testing between windows endpoint actor as the source and the new network actor in another zone
6. Deploy an endpoint actor in new zone (if ‘different’)
7. Goto 2
8. If a network actor is available in two zones, do bi-directional lateral testing

Each one of these tests can become part of an agreed upon report that is generated and stored for comparisons over time.

Now that we have the big picture, let’s talk about specifics.

More than likely you are using our SaaS platform located on Mandiant Advantage (https://app.validation.mandiant.com), so that is your director.  (Check!) If you have a Mandiant-hosted Network Actor, that counts as your cloud actor. (Check!) We can deploy an endpoint agent to generate an endpoint actor. Tada! You are ready to test. (Note: Yes, we do need to work on integrations to our security stack.  Oftentimes we will do blocked/not-blocked testing while integrations are being deployed so we don’t have to wait!)

What kind of actions to run? It depends, but I do have a few “rules of thumb” I like doing.  For endpoint tests, I start out with actions that can run as the SYSTEM user.  This testing will focus primarily on your endpoint security stack excluding things like domain policy.  In the action library, we can use the tag search feature to see what actions we want to run. Select ‘Endpoint’ from Action Types first.  Then, in the tag search box (up in the top left of the screen), we can enter/select the following search terms:

• RunAs:System
• OS:Windows:10

This is, of course, assuming a Windows 10 system. You will see several actions listed there.  You don’t have to run all of them! Take a look at what is listed there and select 20-30 that are “bucket list” checks. (Those are the items that you think are most important to your organization.) Some of what I typically recommend is the following:

• A104-091: Host CLI - User Account Enumeration
• A104-684: Host CLI - EICAR, Download with Powershell
• A104-846: Host CLI - In-Memory Download, Execution with Powershell
• A104-071: Host CLI - Evasion with certutil.exe
• A104-252: Host CLI: EICAR com File Download Via certutil.exe (HTTPS)

For network actions (both lateral and up-down) we also search the library but use different terms. We select the “network” action type (instead of endpoint) and then search for the following tags.

For lateral testing:

• Src:Internal:Trusted+Dst:Internal:Trusted

For up-down testing:

• Src:Internal:Trusted+Dst:External:Untrusted

Again, we only want to do 20-30 (okay 40) actions here to get our feet wet. Some actions I always recommend are listed below.

For lateral testing:

• A100-137: Scanning Activity - Nmap, SMB
• A100-310: Remote Services - Telnet
• A100-357: Scanning Activity - MEDUSA, FTP Brute Force
• A100-210: SSH Brute Force (root) Authentication Attempts

For up-down testing:

• A101-704: Malicious File Transfer - DARKSIDE, Download, Variant #6
• A100-165: FTP-based Exfil/Upload of PII Data (zip x3)
• A105-464: Command and Control - VALEFOR, C2 Beacon
• A150-305: Malicious File Transfer - APT10, BUGJUICE, Download, Variant #5

As you do this testing, you will likely find some surprises.  By the time you got your first two zones tested, you likely will have completed integrations to technologies in your security stack. (Including your SIEM!).  Once integrations are complete, I recommend re-testing everything you have tested thus far to see what the detections look like.

Reporting is important, and we offer the Report Builder functionality.  Even a screen capture of raw test results can convey a lot of information in an easy-to-digest format to describe your current security posture.

As remediations take place for issues found during testing, you also test the same tests again to make sure your remediations were effective.

Test. Remediate. Test Again. 

Hi @jminycricket323,  

following @chrisproudley suggestions with the first 5 actors we deployed:
A) 1 endpoint actor on a standard laptop placed in our "office" network
B) 1 network actor in an external cloud
C) 1 network actor in DMZ
D) 1 network actor in the same subnet of Domain Controllers
E) 1 network actor in the same subnet of an Application Server of a specific application infrastructure

With this deployment you can test a lot of things:
- MFT and C2C with A and B, testing your firewalls/proxy and IPS/IDS/NDR security technologies
- Host CLI actions with A, testing your AV/EDR solutions
- Lateral movement with A and D, or D and E testing your segmentation/segregation and your IPS/IDS/NDR technologies
- Application attack using B and C, testing your firewalls or WAF
- email phishing attacks using B and D (but you need to have the Email Theater licensed)

As @chrisproudley suggested you need at least an integration with your SIEM. Fine tuning the query that the Director runs on the SIEM will take some time.
Try to reduce the amount of logs that your queries capture as much as possible, but include all events necessary to prove that an action has been blocked or detected.

Remember to set your Pass/Fail rule (Settings > Director Settings > Pass/Fail) before starting the tests.

Don't worry if tests fail: this is a great result to show that your security technologies are not effective and this is the first result to show to the management that your investment in MSV is good.

Otherwise, if all your tests are success, don't forget to explain to the leadership the exact position of your actors in your network. An action blocked between point X and Y in your network may not be blocked if you move one of the two actors. This is important to be clear about the results and not to create a false sense of security.

Run the same tests every week/month/quarter and collect results to show improvements in your security technologies or to simply show that your results remain constant over time (and do not worsen).

Finally, if you can, take the MSV Bootcamp course, it includes a lot of interesting information to run tests and MSV platform.

Paolo

Congrats on your investment!  The previous replies have provided excellent technical advice . I would stress greatly before you begin any endeavor in security validation, that you consider developing a "Security Validation Program" that includes People, Processes and the MSV technology. Doing this will ensure that all stakeholders in the security and engineering organizations are identified and willing to cooperate when executing attack simulations. Roles and expectations can be established by developing a policy early on ensuring all parties involved  are onboard. Doing this will greatly expedite the actualized value of MSV.