MISP enrichment and expansion modules setup

Enrichment in MISP is always run against a specific attribute type, and each expansion module decides which attribute types it accepts. Before any analyst relies on a lookup, the platform team should check the accepted attribute list for each enabled module in the release in use, because module definitions change between versions and between module releases. Do not assume that a module which handles domains will also handle IP addresses, file hashes or URLs. Treat the module's own documentation and its input definition in the deployed misp-modules service as the source of truth, and record the list in your runbook so analysts see the same scope.

In general terms, an analyst opens an event, selects a single attribute, and launches an enrichment action from the attribute's context menu. MISP sends the attribute value and the chosen module to misp-modules, which runs the lookup against the external service configured with the module's API key. The results come back as new attributes or objects attached to the event, or as a result view that the analyst can review before accepting anything into the event. The analyst should confirm, during setup testing, whether results are added automatically or only shown for review in the release you deploy, since that decision affects how much unverified data enters shared events.

The manual path is an analyst choosing the action on one attribute at a time. It keeps a person in control of which values leave the organization for a third-party service, which matters when an attribute is sensitive, belongs to an active investigation, or is tied to a victim. An automated path runs enrichment without a click, typically through a background job, an import workflow or an API call. Automation scales better but multiplies outbound lookups, so you should decide which attribute types and which events are eligible before turning it on. Note that an automated path still depends on the same module scope, so an attribute type outside a module's accepted list will not be enriched by that module in either path.

Confirm with the platform team which roles can run lookups. In MISP, permissions are set through roles, and enrichment should be limited to roles that have a documented reason to send indicators to external services. Also confirm whether each lookup is written to the audit log, what fields are recorded (user, time, module, attribute, result), and where those logs are retained and reviewed. Ask whether lookups against sensitive or non-public attributes are logged differently, and whether the external service's own logs or terms could retain submitted values. These answers shape your data-handling statement and should be settled before analysts are trained.

Finally, document the attribute scope and trigger rules as operating guidance, not as an assumption carried over from another deployment. Give analysts a short table that lists each enabled module, the attribute types it accepts in your release, whether it is manual or automated, and who may run it. Re-check that table after every misp-modules update and after any change to module settings. An illustrative example: if a module accepts only hash and domain values in your version, a URL-only event will show no enrichment results, and that is the expected outcome rather than a fault to troubleshoot.

Treat provider API keys, quota limits and stored enrichment results as three separate controls, and settle each one before analysts depend on bulk lookups. The module configuration decides which keys misp-modules uses, so keys should not sit in plain text in MISP settings, in the database or in files that are copied into backups and support bundles. Where your platform allows it, inject keys from a secrets store at service start, restrict read access to the account that runs misp-modules, and record which key belongs to which module. Ask each provider whether keys can be scoped to a single purpose and whether separate keys can be issued per environment, so that a leaked test key cannot reach production quota.

Plan rotation as an operational task with an owner, not as an ad hoc reaction. Give each module key a named service account, document the rotation interval your policy requires, and test the procedure in a non-production instance: update the secret, restart the modules service, confirm a known lookup succeeds, then revoke the old key. Check whether your current MISP release reloads module settings without a full restart, because this changes how long a rotation window stays open. Keep the revocation record with the change ticket so reviewers can see when each credential changed hands.

Rate limits are a design input, not a footnote. Before you enable bulk enrichment, confirm each provider's quota for your subscription tier, including daily and per-minute limits, whether quota is shared across all keys on an account, and what the provider returns when a limit is hit. Then test how misp-modules and MISP behave under those conditions: whether a failed call is retried, whether the error is surfaced to the analyst or silently dropped, and whether a batch job stops or continues. Quota figures change with provider plans, so take them from the provider's current terms and record the date you checked.

Enrichment results are data you hold, and they inherit the sharing rules of the event they attach to. Confirm how the attribute distribution and sharing group on the parent event apply to enriched attributes and tags, because a result pulled from a third-party service may be more sensitive than the indicator itself, and a passive DNS or domain intelligence response may carry restrictions in the provider's terms that prohibit redistribution. Decide how long enrichment outputs are retained, whether they are pruned with the event, and whether you will re-query instead of storing provider responses. Check the export and synchronization behavior too, so that enriched data does not leave your organization by a path the provider's licence does not allow.

For audit or data-handling review, document each module, its provider, the account and key owner, the data sent to the provider, the quota tier, the retention period for stored results, the distribution rules that apply, and the rotation and revocation log. Record which analyst roles can trigger enrichment and whether those actions are logged. Ask your privacy or legal team to confirm whether any provider receives personal data from your events and whether that transfer needs a contract or assessment. Note that DeployOpen prepares these records and controls as evidence for your assessors, but the independent auditor or certification body makes the determination.