Enricher - MISP API enricher


This article describes the specific configuration options to set up the enricher.
To configure the general options for the enricher, see Configure the general options.

Specifications

Enricher name

MISP API

Input

Actor-id, bank-account, card, country, domain, email, email-subject, file, hashes (hash-md5, hash-sha1, hash-sha256, and hash-sha512), IP addresses (ipv4 and ipv6), malware, name, netname, organization, person, port, registrar, telephone, uri, and yara.

Output

Enriches supported observables and entities with information on indicators of compromise.
Searches a source MISP instance for MISP events containing the values of the selected observable types.
Generates enrichment observables, entities, and relationships based on the retrieved data.

API endpoint

http://${misp_instance_url}/

Description

The MISP API enricher retrieves data from a source MISP instance. It returns enrichment information on indicators of compromise.
Based on the enricher criteria and the retrieved content, ingested data is stored to the platform as enrichment observables, entities, and relationships.

Requirements

Users need a MISP API URL and a MISP API key for their own configuration. Sign up and subscribe to the service to obtain the required credentials.

Configure the enricher parameters

  1. Edit the enricher.

  2. From the Observable types drop-down menu, select one or more observable types you want to enrich with data retrieved through the enricher.

  3. In the MISP API URL field, enter the URL pointing to the API endpoint exposing the service that grants access to the source MISP instance.

  4. In the MISP API key field, enter your API key.

  5. To store your changes, click Save; to discard them, click Cancel.

Additional information

The native ingestion of MISP events is a significant improvement with respect to STIX-based MISP object ingestion.
The current approach provides more context, and it produces a proper data hierarchy in the platform.

Keep in mind that there is a likely risk of not receiving all information, or of missing updates, due to limitations in this integration.
Future platform releases will address these constraints. It is very likely that upon installing an upgraded release of the MISP integration, it will be necessary to recreate the data feed.

The following list includes all known limitations related to the current implementation.

  • Not all MISP properties and objects have been mapped to corresponding entity and observable data types in the platform.
    At the moment, and after consulting with MISP Project team members, we implemented the most commonly used constructs.

  • It is not yet possible to share MISP data to other MISP instances. MISP allows data sharing across MISP instances, where events can evolve independently of the original source.
    When evolved events with same parent events are ingested from more than one source, the platform deduplicates them, and it ingests only the latest version, without performing any data merging.

  • It is not yet possible to configure multiple MISP data sources.

  • No special handling in place for proposals.

See also