best practices for first actor deployment

[jminycricket323]

We just acquired Mandiant Security Validation. We are starting to deploy actors, but we want to be optimal when deploying them to get as much information out of MSV as quickly as possible to show leadership that the investment was a good one. Does anyone have any tips on how to do this?

[chrisproudley]

Hello @jminycricket323 , thanks for your question. There are many factors to consider for optimal actor placement.

Firstly, how many actors did you purchase? You can check this at Settings > License, which will give you a figure of used actors and the total, e.g. 3 of 5. This will obviously influence what kind of actors you install, and where you place them. If you have none available, it is possible to deregister unused actors to bring their licenses back into the total, or purchase additional actor count (your Account Executive can advise on this).

Actor placement is largely driven by the testing that customers wish to prioritise. As a few examples:

1. To effectively test data egress or Command and Control (C2) actions, 1 or more 'internal' actors will be required, and 1 external actor in an untrusted subnet (e.g., in the cloud).
2. To test lateral movement, 2 actors in different 'internal' subnets are needed.
3. Endpoint testing can be performed across all current/mainstream Windows operating systems including Server and also Mac OS and many Linux distributions, so at least one license is deployed for an endpoint actor.

Many customers start with 5 available actors. This gives the potential to install actors covering a wide use of the available use cases and quickly demonstrate value. Typically, I have broken this down along these lines:

• 2 internal network actors in subnets including business-critical applications/data
• 1 DMZ network actor with limited inbound connectivity/strong controls
• 1 endpoint actor (e.g. most common Windows OS in use, with 'best effort' controls (AV/EDR/DLP/FW) and at least one available less-privileged user (e.g. typical domain user/power user, rather than simply using SYSTEM for testing)
• 1 external/cloud actor in a totally untrusted location. This replicates the external attacker/C2 server.

This breakdown of actors will allow the widest spread of use cases, from which earliest value should be seen. With these actors deployed (and, ideally, at least one integration, usually with the primary SIEM), it is possible to set up an evaluation that covers most stages of an attack and will demonstrate where your controls are strongest, and where improvements can be made. This can be repeated to demonstrate iterative improvements to your security posture, and as a secondary benefit, the value of your investment in this platform.

If you have follow-up questions, please post them here and one of us will be able to guide you further.

[James_R]

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. 

[paolocarrara]

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

[ScottieJ]

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.