MISP taxonomies, galaxies and warning lists: what each adds to your instance
Taxonomies, galaxies and warning lists are the three components that turn a MISP instance receiving indicators into one where teams can read and act on them consistently. Taxonomies form the shared vocabulary, galaxies supply the context, and warning lists provide the filtering layer. If your instance already ingests feeds and partner events, these components decide whether an analyst sees a named threat actor, a MITRE ATT&CK technique and a consistent handling label, or a loose mix of free-text tags and benign values that detection tools then act on. The sections below explain what each one adds and when to enable it.
Taxonomies are tag schemes that let every event and attribute carry the same labels, so searches, sharing rules and downstream filters behave predictably. The MISP features page describes the taxonomies as shareable and bundled with the platform, so a new instance can enable them without designing a tag schema from scratch. Enable them before partners start sending events, because applying consistent tags to events already stored is slower than tagging at ingest. Confirm which taxonomies your sharing communities expect, since a partner that filters on one tag will miss events that use a local variant.
Galaxies add context. The MISP features page lists galaxies covering threat actors, malware, ransomware, tools and MITRE ATT&CK, and these are bundled and shareable as well. Their value appears when an analyst attaches a galaxy cluster to an event or attribute and then pivots to related activity, or when a team needs ATT&CK coverage visible across its events. Teams that run detection engineering or report technique coverage to leadership usually need the ATT&CK galaxy first. Teams that exchange indicators with a narrow group may need only the actor and malware galaxies. Ask your analysts which questions they answer repeatedly before enabling everything.
Warning lists flag values that commonly appear in benign traffic, such as widely used public services, so they are less likely to be mistaken for malicious indicators. Their purpose is to reduce false positives before indicators reach detection tools such as firewalls, SIEMs or DNS filters. Enable them once you export to those tools, and check that the enabled lists fit the sectors and networks you operate in, because a list that suits one organization may hide a value that matters to another. Review warning list matches periodically, since the set of benign services changes over time.
Licensing and what to confirm. The MISP software is licensed under the GNU AGPL version 3. The taxonomy and galaxy data are licensed under CC0 1.0 Universal or the 2-clause BSD license, which is separate from the AGPL. Ask your legal or compliance team which terms apply to the data you redistribute, especially if you publish events built on galaxy content to external communities. Before go-live, confirm which taxonomies, galaxies and warning lists are enabled on your MISP version, which release is installed, and how updates to that data are pulled into your instance.
Which taxonomies, galaxies and warning lists to enable and when each fits
This table compares the MISP components that add context to events and attributes, plus default feeds as a separate decision. Read each row for what it adds, when it fits, and what to confirm in your chosen MISP version before enabling it. Most instances start with taxonomies and warning lists, then add galaxies once analysts need shared threat actor and ATT&CK context.
| Component | What it adds | When to enable it | Main trade-off | What to confirm in the chosen MISP version |
|---|---|---|---|---|
| Taxonomies | Machine-readable tags with a defined structure, so attributes and events carry consistent labels that tools can parse | Early, when you need consistent classification and tagging across teams or partner communities | Tags only help if analysts apply them consistently, so a shared tagging policy is needed | Which taxonomies are listed in the administration menu and how each is enabled or disabled |
| Galaxies | Clusters for threat actors, malware, ransomware, tools and MITRE ATT&CK techniques that can be attached to events | When analysts need shared actor, malware or ATT&CK context to group and search related activity | Clusters add breadth to the tag set, so teams should decide which galaxies they actually query | Which galaxy families are available, how they are attached to events, and whether they update through the galaxy sync process |
| Warning lists | Values flagged as commonly benign, such as well-known domains or services, so they can be warned about before they reach detection tools | When indicators from feeds or partners are producing false positives in your environment | Warning lists reduce noise but need periodic review, since a value that is benign today may change | Where warning lists are managed in the administration menu and how matching warnings appear during event creation |
| Default feeds (separate choice) | Intelligence feed sources that the instance can fetch from, with their own caching and import options | After you have chosen taxonomies, galaxies and warning lists, when you decide which external sources to pull in | Feeds bring volume and their own licensing and quality questions, so each feed needs an explicit decision | Feed list, per-feed caching and import settings, and how feed licenses are shown in the feed configuration |
How MISP galaxies map MITRE ATT&CK to events
A galaxy cluster becomes useful in MISP when it is attached to an event or attribute as a tag. The tag carries the cluster's identifier and name, so an analyst can search for every event tagged with a given ATT&CK technique or threat actor, and a downstream tool can filter the same way. Attaching a galaxy does not change the event's attribute values. It adds a classification layer on top of the data, which is why the decision about which galaxies to use is a design question, not a formatting detail. Default or analyst choice. Decide before go-live which galaxies are attached automatically and which are left to the analyst. A reasonable starting split is to attach broad context (for example, the threat actor or malware family an event is known to relate to) by default, and leave fine-grained technique tagging to analysts who can justify it. Document the split in your sharing guidance so that two analysts tagging the same campaign produce comparable results. Automatic tagging rules, if you use workflows or enrichment, should be reviewed against the same list.
The over-tagging risk. Every extra tag increases the number of events that match a common search. If every indicator in a feed receives a broad set of technique tags, a search for one technique returns a large share of the instance, and analysts stop trusting the results. Tag only where the technique or actor is supported by the event's content, and periodically review tag frequency across the instance. Noisy tags are often a sign that an automated rule is applying a galaxy to every incoming event rather than to the ones that match.
Correlation and exports both read tags, but they treat them differently. The correlation engine works on attribute values, so a galaxy tag does not create a match by itself, yet it helps analysts narrow the candidate events that correlation surfaces. Exports and feeds carry tags in the event data, so a consumer that filters on a technique tag will only receive what was tagged at the time of export. Confirm with your downstream consumers which tag names and galaxy identifiers they expect, and test one export end to end before you rely on it. Confirm the galaxy version. MISP bundles MITRE ATT&CK among its galaxies, along with threat actor, malware, ransomware and tool galaxies. Your instance's galaxy data is updated separately from the MISP software, so the ATT&CK version and cluster set you run may differ from the current upstream release. Confirm which version your instance holds, how often you update it, and who approves updates. Renamed or deprecated clusters can break saved searches and dashboards that depend on old tag names, so plan a review step each time the galaxy data changes.
MISP taxonomies, galaxies and warning lists in the setup sequence
This sequence takes a new MISP instance from a confirmed version to a tested baseline for taxonomies, galaxies and warning lists. Each step ends with a check you can record, so the enrichment and flagging your team depends on are chosen deliberately and verified before indicators reach detection tools.
Confirm the MISP version and release line
The platform team confirms the version before anything is installed. The MISP download page recommends 2.5 for new deployments and states that 2.4 is end of life with security fixes only, so new 2.4 instances should not be built. Confirm the current 2.5 patch release on the project's releases page and record it in the build ticket. Done when the chosen version and patch level are written down and approved by the owner of the instance.
Complete the installation on your standard
The engineering team installs MISP using the method that matches their existing automation. The project lists an installer for Ubuntu 24.04, Docker images, Ansible roles, Puppet and RPM packages, and the download page recommends the provided installer on Ubuntu 24.04 for 2.5. Choose one method and keep it for the whole host. Done when the web interface loads over HTTPS, an administrator can sign in, and the admin settings report the version you recorded in the first step.
Decide which taxonomies and galaxies to enable
The threat intelligence lead reviews the shareable taxonomies and MISP galaxies that ship with the platform, which cover threat actors, malware, ransomware, tools and MITRE ATT&CK. Enable only the ones that match the sectors, technologies and reporting your team handles, and write a short reason beside each entry. Taxonomy and galaxy data is licensed under CC0 1.0 Universal or the 2-clause BSD license, separate from the AGPL software license, so legal review may want that on file. Done when the decision record lists every enabled item, its reason and a named owner for review.
Enable warning lists and test coverage
The detection engineering lead enables the warning lists that fit your environment and compares each entry against the data sources you ingest. Warning lists flag commonly benign values, such as widely used public services, so analysts can see them for what they are. Ask the maintainer of each list which values it contains and how often it changes, and confirm the lists cover your own domains, internal address ranges and key SaaS services. Done when you have a written mapping from each enabled list to the source it protects.
Attach MITRE ATT&CK galaxy to test event
An analyst creates a test event in a clearly labeled test organization, adds a few attributes, and attaches a technique cluster from the MITRE ATT&CK galaxy. Then search for the event using the galaxy tag and open the MISP JSON and STIX exports. Check that the cluster appears in the event view, returns in search results and carries through into the exports your downstream tools use. Done when all three checks pass and the test event ID is recorded for handover.
Test warning list flag with indicator
The detection engineer adds an attribute that matches an entry in an enabled warning list to the test event and observes how MISP flags it. Confirm the warning appears where analysts will see it, and confirm that your publishing and export settings handle the flagged attribute as the design intends before anything reaches a detection tool. Repeat the test with a value on no list to confirm it passes without a warning. Done when both results match the expected behavior in the decision record, and any mismatch is logged for the platform team.
Using MISP warning lists to cut false positives before indicators reach detection tools
Warning lists exist to stop common, benign values from becoming indicators that detection tools act on. Shared hosting addresses, public DNS resolvers and widely used domains are typical examples. If an attribute with one of these values is exported without review, it can reach a firewall rule, a SIEM detection or an RPZ feed and generate noise, or block legitimate traffic. The decision you need to make is which lists to enable, who reviews matches, and at which point in the event lifecycle the check runs.
The check belongs between analyst entry and publication. When an attribute is added or edited, MISP compares its value against the enabled warning lists and flags matches for the analyst in the event view, so the value can be confirmed, removed or documented before the event is published or synchronized. Confirm in your MISP version which warning list matches only warn and which can block publishing, and whether a match affects the to_ids flag that downstream exports depend on. Also confirm how data pulled in by feeds or synchronization is checked, since it may not pass through an analyst's review.
Lists involve a direct trade-off. Broad lists suppress more noise, but a wide range of addresses can also cover infrastructure that an attacker uses. Illustrative example: a list that flags an entire hosting provider's address space could hide a campaign that runs on that same provider. Narrow lists keep more indicators, but analysts then spend time clearing matches that add little value. Decide list by list, record why each list is enabled or disabled, and revisit those decisions when your sector, tools or sharing partners change.
Every change to the lists needs a named review owner, usually someone from threat intelligence or detection engineering, who approves enabling, disabling or editing a list and keeps a record of the change. Before you rely on any list, test it against a sample of your own exports. Pull recent exports, run the enabled lists against them, and review which values are suppressed or flagged. Also check a set of known indicators that should pass, so you can confirm that a list does not hide them. Repeat this test after each list update.
Security and operational considerations for shared taxonomies and galaxies
Shared taxonomies, galaxies and warning lists shape what your MISP instance tags, exports and suppresses, so their configuration is a security decision as well as an operational one. The five controls below cover who can change them, how far tags travel, how single sign-on assigns access, how the data stays current, and how warning lists are checked. Each card names a setting or check you can verify in your own instance.
Control who changes enabled taxonomies and galaxies
Enabling or disabling a taxonomy or galaxy changes which tags users can apply and which tags reach partners, so it is an administrative decision. Limit this permission to a small named group of administrators, separate from general event-publishing roles. Confirm which role can change these settings in your version, and check that each change is recorded in the audit log with the acting user and a timestamp. Test this on a staging instance before you rely on it.
Check how distribution and sharing groups carry tags
Tags travel with events and attributes, so a tag on an item shared at a wide distribution level can reach every connected instance and community that receives it. Sharing groups limit who receives an item, but a tag naming an internal asset, actor or case can still reveal context. Review which galaxy clusters attached to sensitive events are safe to share, and confirm that the distribution settings on each event and attribute match your sharing policy.
Review OidcAuth role mapping and priority
If your instance uses single sign-on through the OidcAuth plugin, the plugin maps identity provider roles to MISP roles and assigns the first matching role by priority. A broad identity provider group ranked higher in that order can give a user more access to taxonomy and galaxy administration than intended. Review the mapping order after every change to identity groups, and sign in with test accounts from each group to confirm the role assigned is the one you intended.
Schedule updates for taxonomies and galaxies
Taxonomy and galaxy data change over time, and stale clusters can leave new tools or threat actors untagged while retired names persist in searches. Assign an owner to a recurring review of available updates and record what was updated and when. Confirm your update method, whether a scheduled task, a manual pull or configuration management, and test each update on staging, because a renamed cluster can break automation or saved searches that depend on it.
Monitor warning lists for suppressed indicators
Warning lists flag values, such as common public domains or resolvers, that should not be treated as indicators. An entry that is too broad or out of date can silently suppress a real indicator before it reaches a SIEM or firewall. Review every addition and change to warning lists, record an owner and reason for each entry, and periodically confirm that indicators from known past incidents still appear in your exports.
What buyers ask before they hire outside help with MISP taxonomies and galaxies
Can our team enable MISP taxonomies and galaxies ourselves?
Yes, a team with MISP administration experience can enable taxonomies and galaxies on a basic setup, since they ship with the platform and are switched on through the administration interface. The work grows with the number of data sources and sharing rules. Each feed, community and distribution rule adds decisions about which tags are exposed, who sees them and how they map to events. Teams without a named MISP owner usually find the first configuration manageable, but ongoing tag mapping and tuning is the harder part. Confirm whether your administrators have time to maintain mappings after go-live, and whether you need a test instance first. DeployOpen can take on configuration, documentation and handover as a fixed-scope piece of work.
What drives the effort of a MISP taxonomy and galaxy setup?
The main drivers are the number of feeds and communities, the tagging policy, warning list tuning and review of exports. Feeds and communities each bring their own tags, quality and duplication, so more sources mean more mapping and checking. The tagging policy defines which taxonomies are required, how TLP is handled and how galaxies are used, and every other decision follows from it. Warning lists need tuning against your known-good assets, such as internal domains, cloud provider ranges and software update hosts. Exports such as STIX, Suricata, Snort, Zeek and RPZ carry tags and indicators into different detection tools, and each output needs its own check. Ask any provider to price these drivers separately in the written scope.
How long does a MISP taxonomy and galaxy engagement take?
Duration depends on the scope and your environment, and it is set in the written scope for each engagement. Enabling a default set of taxonomies and galaxies on an existing instance is a much smaller job than mapping MITRE ATT&CK galaxies across several communities with custom sharing groups and tuned warning lists. Environment matters too. Access to a test instance, change approval windows and the availability of detection tool owners for validation can all set the pace. Ask for a timeline that shows which steps depend on your people and which depend on the provider. Timelines should also state assumptions, so you can see what moves the schedule if an input arrives late.
What do we need to provide before an outside team starts work?
The work needs a named tagging policy owner who can decide which taxonomies, galaxies and tag meanings your organization adopts. Provide access to a test instance where changes can be validated before they reach production. Supply sample indicators from your own incidents or feeds, so warning lists and mappings can be tested against the traffic patterns you actually see. Name the owners of each detection tool that will consume exports, such as SIEM, firewall or DNS resolver administrators, because their confirmation decides whether an export is usable. Agree in advance who approves changes to sharing groups and distribution levels. Without these people in place, the work stalls during review.
Does the CC0 or BSD license of taxonomy data affect how we reuse it?
Taxonomy and galaxy data is licensed under CC0 1.0 Universal or the 2-clause BSD license, which is separate from the GNU AGPL version 3 license that covers the MISP software. In practice, the data can be used and redistributed under the terms of either data license, while the platform code follows the AGPL. The distinction matters if you plan to republish data outside your organization, build a product on it or merge it with proprietary data. Confirm the license terms and any obligations with your legal counsel, since this page does not provide legal advice. Ask your implementation provider to document which license applies to each data set in your deployment and where those source files are kept.
How does DeployOpen price work on MISP taxonomies and galaxies?
DeployOpen does not publish a price list. Each engagement is quoted from a written scope that lists the taxonomies, galaxies, feeds, warning lists and exports covered, the environments involved and the deliverables, such as configuration records, runbooks and handover sessions. Cost follows the people and time needed for design, configuration, testing and review. Ask for a quote that separates one-time setup from recurring work, such as periodic tag review, warning list maintenance and upgrades. Ongoing support and tuning can be arranged as a retainer. Most engagements are fixed-scope, so the scope, deliverables and timeline are agreed in writing before work begins.
How do warning lists cut false positives before indicators reach detection tools?
Warning lists flag values that are usually benign or shared infrastructure, such as public resolvers, major cloud and CDN ranges and common software update domains. When an attribute matches a warning list, MISP highlights the match so an analyst can review it before publishing or exporting. Tuning means adding your internal domains, IP ranges and business applications, then testing the lists against sample indicators to confirm matches are accurate. Confirm which warning lists ship with your MISP version and how they are updated, since list contents change over time. Review tuning after each feed change, and keep a log of exclusions so tool owners and auditors can see why an indicator was held back.
Limits of MISP taxonomies, galaxies and warning lists to confirm in your environment
Taxonomies, galaxies and warning lists are easy to switch on, but how they are enabled, updated, licensed and reviewed depends on your MISP version and data. The cards below list the points to confirm before you rely on them for tagging, enrichment or blocking decisions.
Enablement path and defaults
The steps to enable taxonomies, galaxies and warning lists, and the state they start in, can differ between MISP versions and installation methods. Confirm the exact path in the administration interface of the version you run, and check the release notes for changes to defaults. Record which items are enabled on day one so the baseline is documented.
Automatic galaxy version updates
Galaxy content is updated by the project, but whether your deployment pulls new versions automatically depends on your update and scheduling configuration. Confirm in your instance whether galaxy updates run on a schedule or only when an administrator triggers them. Decide who reviews new galaxy versions before they change tagging or enrichment results.
Separate data and software licenses
MISP software is licensed under the GNU AGPL version 3, while taxonomy and galaxy data are licensed under CC0 1.0 Universal or the 2-clause BSD license. Your legal team should confirm how these terms apply to your internal use, redistribution to partners and any modified content. Keep the license notice for each data set with your configuration records.
Curated warning list review
Warning lists are curated content that flags values such as well-known public services or common benign domains, so they can reduce false positives. They are not a guarantee that a value is safe in your data. Review the entries against your own traffic and business services before enabling a list, and document who approves changes to it.
Support scope from providers
The MISP project offers paid support services, and a number of third-party providers offer commercial support. Ask each provider exactly what they cover, such as content tuning, version upgrades, incident support or custom galaxies, and whether that covers your deployment method. Get the scope in writing before you depend on it.
PostgreSQL option and enablement
MISP 2.5.47 introduced a new database migration system with PostgreSQL support. This does not change how taxonomies, galaxies or warning lists are enabled, but confirm that behavior for the database you choose. Test the enablement steps on your chosen database before you apply them to a production instance.
How DeployOpen works on this
DeployOpen treats taxonomy, galaxy and warning list selection as a design decision tied to your events, sharing groups and detection tools, not a one-time toggle. We plan, implement, document and support MISP inside infrastructure you control, under a written scope agreed before work starts.
How we scope
- Inventory which taxonomies, galaxies and warning lists your teams and sharing communities actually use before enabling anything
- Define which MITRE ATT&CK galaxy mappings apply to your event types, tags and analyst workflow
- Agree in writing which warning lists suppress known benign indicators and which detection tools receive filtered output
How we build
- Enable and configure the selected taxonomies and galaxies, checking tag naming and clusters against your sharing rules
- Tune warning list matching and correlation behavior, then test false-positive reduction against sample events from your environment
- Record licensing notes for taxonomy and galaxy data, which are licensed separately from the MISP software under AGPL version 3
How we hand over
- Document each enabled taxonomy, galaxy and warning list with its purpose, owner, update source and review cadence
- Provide a runbook for updating taxonomy, galaxy and warning list content and for rolling back a faulty change
- Walk your analysts and platform team through tagging conventions and how warning lists affect what reaches detection tools
How we support
- Offer ongoing support and upgrade work as a retainer, covering content updates and changes to your tagging model
- Review warning list hit rates and galaxy mappings periodically so suppressions stay accurate as your environment changes
- Plan MISP version upgrades, including the move to a supported release line, before changing content packages
