Best Practices

The following page hosts some best practices for the usage of the MISP platform. For generic threat intelligence practices, please refer to MISP project - best practices in threat intelligence.

Tagging

Tagging at event level versus tagging at attribute level

You can add tags to an entire event. For a more fine-grained specification tags can also be placed at attribute level. This allows the user to put a more detailed and selective view on each attribute. If a tag applies to all or most attributes in the event, the best practice is to only include a specific tag for the attributes when they are an exception from the tag set at event level. In the below screenshot you see an example of the best practice, the tlp:white tag is only set at the event level.

Screenshot of event tagged with tlp:white, no tlp:white tag set at attribute level

In the next screenshot you see a bad practice example. The tlp:white tag is added to both the event and all the attributes.

Minimal subset of tags to use for each event

Traffic Light Protocol

TLP-Tags: TLP utilizes a simple four color schema for indicating how intelligence can be shared.

Confidence

There are huge differences in the quality of data and in how well it was vetted before sharing. Communicate your confidence explicitly so recipients can weight the intelligence accordingly. Common vocabularies are the estimative-language taxonomy (confidence in an analytic judgement) and the admiralty-scale taxonomy (source reliability and information credibility).

Origin

information-origin: Describes where the information came from — for example whether it was produced in an automated fashion or through manual investigation. This gives an impression of how much the intelligence should be trusted, as manual investigation generally supersedes automatically generated data.

Permissible Actions Protocol

PAP-Tags: An even more advanced approach of data classification is using the Permissible Actions Protocol. It indicates how the received data can be used to search for compromises within the individual company or constituency.

Setting distribution

Similar to tagging, inheritance should be used wherever possible. This is especially important when using sharing groups due to limit the impact of sharing group usage on performance. Note that for distribution, the event or object distribution of the attribute should be the same or less restrictive than the attribute distribution. Below are two good practice examples, the first using community distribution and the second using sharing groups. Note that a combination of the two can be used as well.

Screenshot of good practice event with this community distribution at event level and only one attribute set to your organisation only distribution

Screenshot of good practice event example with sharing group usage - inheritance is used where possible and only one attribute is set to a more restrictive sharing group

In the next to screenshots, you can see the equivalent bad practice examples.

Screenshot of bad practice event example - distribution inheritance is not used

Screenshot of bad practice event example using sharing groups - Instead of using inheritance the same sharing group as the one set at event level is also specifically set for most attributes

Use objects instead of combined attributes

Some attributes like filename|sha512 and ip-dst|port now have equivalent objects such as file and ip-port. Using the object equivalent of attributes is recommended. It gives flexibility to add more context later and groups all the relevant attributes related to one concept, for example a file, together.

Use proposals when possible to request author to make changes to an event

If possible, use proposals when you want to inform the original analyst/author (e.g. a security vendor or a CSIRT) about a specific mistake or error which needs to be corrected. The advantages of using the proposal system include the lack of a need to create a new event as well as the process itself being very simple and fast.

Make use of the 2.5 collaboration and lifecycle features

MISP 2.5 adds several capabilities that materially improve the quality and longevity of shared intelligence. Build them into your day-to-day workflow.

• Report sightings. When you observe an indicator (or confirm it is a false positive), record a sighting. Sightings keep indicators current, feed reputation back to the author, and are the raw signal that decaying models consume. This is far more valuable than silently consuming a feed.
• Prefer decaying models over manual to_ids toggling. Rather than flipping the IDS flag by hand as indicators age, let decaying models score them over time and filter your exports on the decay score. This keeps detection content fresh automatically and consistently.
• Add context with Analyst Data instead of altering others’ events. Use Notes, Opinions and Relationships to attach your assessment, a second opinion, or a link to related material without needing to own or copy the event. Reserve proposals for correcting factual errors; use an Opinion to express (dis)agreement, and a Note to add analysis.
• Record temporal context with first_seen / last_seen. Where an indicator’s activity window is known, set the first_seen/last_seen fields so downstream consumers can reason about timelines rather than just presence.
• Keep correlations meaningful. Disable correlation on intrinsically noisy attributes, and maintain correlation exclusions for known-benign values (your own infrastructure, popular CDNs, sinkholes). Over-correlating values dilute the value of the correlation graph for everyone.