Mandiant takes an intelligence-led, multi-vendor approach to XDR, enhancing existing security controls and enabling the SOC to improve efficiency and efficacy in finding malicious security incidents quickly and at scale.
The Mandiant Advantage collector allows users to ingest alerts and create lookups based on Mandiant threat intelligence.
Feature | Details |
---|---|
Allow parallel downloading ( |
|
Running environments |
|
Populated Devo events |
|
Flattening preprocessing |
|
Allowed source events obfuscation |
|
Data source | Description | API endpoint | Collector service name | Devo table | Available from release |
---|---|---|---|---|---|
Mandiant Advantage Digital Threat Monitoring | DTM Alerts |
|
|
| v0.0 |
Mandiant Threat Intelligence | Indicators |
|
| N/A | v0.0 |
For more information on how the events are parsed, visit our page.
Although this collector supports advanced configuration, the fields required to retrieve data with basic configuration are defined below.
This minimum configuration refers exclusively to those specific parameters of this integration. There are more required parameters related to the generic behavior of the collector. Check setting sections for details. |
Setting | Details |
---|---|
| The Mandiant public API key |
| The Mandiant secret API key |
See the Accepted authentication methods section to verify what settings are required based on the desired authentication method. |
Authentication method | API key public / secret |
API key | Required |
Once the data source is configured, you can either send us the required information if you want us to host and manage the collector for you (Cloud collector), or deploy and host the collector in your own machine using a Docker image (On-premise collector).
We use a piece of software called Collector Server to host and manage all our available collectors. If you want us to host this collector for you, get in touch with us and we will guide you through the configuration. This data collector can be run in any machine that has the Docker service available because it should be executed as a docker container. The following sections explain how to prepare all the required setup for having the data collector running. StructureThe following directory structure should be created for being used when running the collector:
Devo credentialsIn Devo, go to Administration → Credentials → X.509 Certificates, download the Certificate, Private key and Chain CA and save them in ![]()
Editing the config.yaml file
Replace the placeholders with your required values following the description table below:
Download the Docker imageThe collector should be deployed as a Docker container. Download the Docker image of the collector as a .tgz file by clicking the link in the following table:
Use the following command to add the Docker image to the system:
The Docker image can be deployed on the following services: DockerExecute the following command on the root directory
Docker ComposeThe following Docker Compose file can be used to execute the Docker container. It must be created in the
To run the container using docker-compose, execute the following command from the
|
This section is intended to explain how to proceed with specific actions for services.
dtm_alertInternal process and deduplication methodAll Mandiant Advantage DTM alert records are continuously pulled subject to the last_updated timestamp property.. A unique hash value is computed for each event and used for deduplication purposes to ensure events are not fetched multiple times in subsequent pulls. Devo categorization and destinationAll events of this service are ingested into the table Setup outputA successful run has the following output messages for the setup module:
Puller output
After a successful collector’s execution (that is, no error logs found), you will see the following log message:
|
This collector is snapshot based (all events are fetched on each pull) and thus does not facilitate persistence management. To send data to a new lookup table, you only need to change the override lookup base table name in the user config; the new tables will be created on the next pull. |
This collector has different security layers that detect both an invalid configuration and abnormal operation. This table will help you detect and resolve the most common errors. Common logic
Custom troubleshooting for indicator serviceThe following errors are related to a specific service.
|
This section is intended to explain how to proceed with specific operations of this collector.
InitializationThe initialization module is in charge of setup and running the input (pulling logic) and output (delivering logic) services and validating the given configuration. A successful run has the following output messages for the initializer module:
Events delivery and Devo ingestionThe event delivery module is in charge of receiving the events from the internal queues where all events are injected by the pullers and delivering them using the selected compatible delivery method. A successful run has the following output messages for the initializer module:
Sender servicesThe Integrations Factory Collector SDK has 3 different senders services depending on the event type to delivery (
Sender statisticsEach service displays its own performance statistics that allow checking how many events have been delivered to Devo by type:
|
To check the memory usage of this collector, look for the following log records in the collector which are displayed every 5 minutes by default, always after running the memory-free process.
|
Release | Released on | Release type | Details | Recommendations |
---|---|---|---|---|
|
| New collector |
|