MISP import and export modules: when they earn their place
Threat intelligence rarely arrives in the form your detection stack expects. It comes as CSV exports from partners, email reports from vendors and sandbox output from analysis tools, and detection teams often need formats that MISP does not produce natively, such as YARA, KQL or CEF. The misp-modules service adds import and export modules that handle these conversions, and this page explains when enabling them is worth the effort. misp-modules runs as a separate service alongside the core MISP platform, so it has its own installation, configuration, service account and upgrade cycle to plan for. Which modules are available depends on the installed version of both components, so confirm the module list on your own instance before you design a workflow around it.
Start with a simple test: does the system receiving your intelligence accept a format MISP already exports? MISP produces MISP JSON, STIX 1 and 2, OpenIOC, CSV, plain text, Suricata, Snort, Zeek and RPZ output, and its API and bundled PyMISP library let scripts pull events on demand. If a firewall, SIEM or DNS filter reads one of those formats, a module adds a moving part without adding capability. The decision changes when the consumer needs a rule language or log schema that MISP does not write, or when a source delivers data in a shape MISP cannot ingest directly. Map each feed and each consumer to a format before you enable anything, and record which ones have no native path. That list is the real scope for the modules.
The import modules cover the inputs that most often need conversion: CSV files, email reports and sandbox output. The export modules named for this topic produce YARA, PDF, KQL and CEF. Each conversion is a mapping between a source schema and MISP attributes, and the mapping is where most of the effort concentrates. Email and sandbox reports vary by vendor and by product version, so a module that parses one template may miss another. Cost falls into three buckets: setup and mapping tests, which are one-time; running and patching the misp-modules service, which recurs; and maintaining mappings when a source changes its output, which also recurs and is easy to underestimate. When you request a quote, ask who owns each mapping after handover and how changes to a source are tested.
Import modules parse input you do not control, so treat them as an attack surface. An email attachment or sandbox report can contain crafted content, and a malformed CSV can create attributes with the wrong type or sharing level. Limit who can submit files to import functions, run the service under a restricted account, keep it off networks it does not need, and review imported events before they are published or synchronized to partners. Check the default distribution level applied to imported attributes so that a conversion does not widen sharing beyond what the source allowed. Confirm each control in your own environment before relying on the defaults.
Before enabling modules, run three checks. First, confirm the installed MISP version and the module list that the misp-modules service reports, because available modules differ between versions. MISP 2.5 is the version the project recommends for new deployments, and MISP 2.4 is end of life with security fixes only, so an existing 2.4 instance should be planned for upgrade before new modules are added. Second, run each conversion on sample files from your own sources and compare the attributes created with the source record. Third, assign an owner to each mapping and define the test that runs after every source or module update. Those answers show whether the modules earn their place, or whether a native export and a short script are the better fit.
What the import and export modules do in MISP
The misp-modules service adds import and export modules that sit beside the core platform's own formats. MISP already exports MISP JSON, STIX 1 and 2, OpenIOC, CSV, text, Suricata, Snort, Zeek and RPZ, so modules cover the gaps in that list. The cards below describe each module group and what to confirm before you rely on it.
CSV import into events
The CSV import module takes a spreadsheet or flat file of indicators and maps columns to MISP attribute types, categories and tags. It saves analysts from re-keying lists from vendor reports or internal trackers. Before you run it, confirm which columns the module expects in your misp-modules version, how it handles header rows, malformed lines and duplicate values, and whether imported attributes keep the distribution level you set.
Email import for phishing reports
The email import module parses a reported message and extracts artifacts such as sender addresses, URLs, domains and attachment hashes as candidate attributes for review. Analysts then decide which values become indicators. Confirm which headers and body parts the module reads, how it treats attachments and encoded content, and whether the original message is kept with the case record.
Sandbox report import
Sandbox report import modules read output from automated analysis platforms and convert observed network indicators, dropped file hashes and behavioral tags into attributes on an event. Confirm which report formats and sandbox versions your module supports, and whether it links the original report as an object or only copies values. Review imported values before sharing, because sandbox output can include benign infrastructure.
YARA export for detection content
The YARA export module produces rule text from file-based indicators and related metadata so detection teams can test samples in their own pipelines. The output is only as good as the attributes behind it. Confirm which attribute types it converts, how it names rules, and how it handles strings that are too generic. Validate every generated rule in your own test environment before deployment.
PDF export for briefings
The PDF export module renders an event into a formatted document for briefings, incident records and stakeholders who do not log in to MISP. It supports distribution outside the platform, which also takes that data outside your sharing controls. Confirm the template and fields included, whether sharing restrictions carry into the PDF, and how the document is archived alongside the event.
KQL and CEF export for SIEM use
The KQL and CEF export modules shape indicators into query and event formats that KQL-based hunting and CEF-consuming collectors can ingest. Confirm the table and field names your KQL environment expects, the CEF version and field mapping your SIEM parses, and how often exported content is refreshed so stale indicators do not stay in detections.
How import modules turn files and reports into MISP attributes
An import module does not publish anything. It reads a source file or email, extracts candidate values, and proposes them as attributes on a MISP event that someone must still check. The flow runs in stages: the file or message is handed to the misp-modules service, the module parses it into fields, MISP maps each field to an attribute type, category and set of tags, and the result lands on an event in an unpublished state. Each stage can change what the reader eventually sees, so the team should know where each decision is made before it relies on the output.
The mapping step carries most of the risk. A CSV module, for example, needs to know which column holds IP addresses, which holds file hashes and which holds free-text comments. An illustrative case: a column of sandbox-reported domains might map to a network type in the wrong direction, or a comment field might be imported as an indicator. Email parsing has similar pitfalls around headers, embedded links and attachments. Ask the team that owns each module to document its mapping for the MISP version you run, and check whether the to_ids flag, which tells detection exports to use an attribute, is set by default or by the analyst.
Review matters because a parsing error becomes a detection error once an attribute reaches a peer or a blocklist. A sandbox report may list a content delivery domain that is shared with legitimate services, and an email import may capture a signature-provider link. Analysts should confirm each attribute against the source, remove what does not belong, and only then publish. Once an event has synchronized to other instances, retracting it depends on those partners acting, so the review gate is the cheapest control you have. Assign reviewers explicitly and keep import and publication under separate roles where your model allows it.
Distribution levels and sharing groups decide who sees the result. An event can be limited to your organization, to a community, to connected communities or to a named sharing group, and individual attributes can carry their own distribution setting, which can narrow what the event-level choice exposes. Confirm how the installed version resolves these combinations before you rely on them. Test each module with your own sample files, including malformed, oversized, non-English and benign-looking examples, and check the result as a user from each intended audience. Record what each module produced, what you changed and why, so the mapping can be reviewed when a module is upgraded.
Which module or built-in format fits each data source
This table maps each data source or output need to the MISP option that handles it. Read the rows by direction (inbound or outbound) and check the last column against your consuming tool. The choice depends on whether that tool already reads the format, since STIX, Suricata, Snort, Zeek and RPZ are built-in exports that need no module.
| Data source or output need | Option to use | When it fits |
|---|---|---|
| CSV intel lists (inbound) | misp-modules import module | Use when columns must be mapped to attribute types before the list becomes an event. |
| Sandbox reports (inbound) | misp-modules import module | Use when report output must be parsed into indicators and objects rather than entered by hand. |
| Email reports (inbound) | misp-modules import module | Use when analysts forward phishing or threat emails and headers, URLs and attachments must be extracted. |
| YARA rule output (outbound) | misp-modules export module | Use when detection engineers need YARA rules generated from file and malware attributes in an event. |
| PDF briefings (outbound) | misp-modules export module | Use when stakeholders need a readable summary of an event alongside its indicators. |
| KQL for Microsoft-based detection (outbound) | misp-modules export module | Use when Microsoft hunting queries must be built from indicators. Confirm the output schema with your analysts. |
| CEF for SIEM ingestion (outbound) | misp-modules export module | Use when the SIEM expects Common Event Format. Confirm field mapping with the SIEM team before enabling it. |
| STIX, Suricata, Snort, Zeek and RPZ (outbound) | Built-in MISP export format | Use when the consuming tool already reads the format. No module is needed. |
| Other sources or outputs with no module | Custom script through the API with PyMISP | Use when the source or output is specific to your environment and no existing module covers it. |
Running misp-modules alongside the core MISP platform
misp-modules is a separate service that the MISP core platform calls when a workflow needs import, export, expansion or action work. It is not built into the MISP web application, so it has its own process, its own host or container, its own configuration and its own update cycle. Import modules parse files such as CSV, email and sandbox reports, which means the service may handle content that originated outside your organization. That separation creates three decisions before you enable any module: where the service runs, how it is updated alongside the core platform, and how far its network reach extends. Enrichment modules and their API keys are covered in the sibling topic on expansion modules, so this section does not repeat that setup.
Placement is the first choice. Running misp-modules on the MISP host keeps the call path short and makes version pairing simpler to manage. A separate host or container isolates the parsing work for untrusted attachments and sandbox output from the core database and its secrets, at the cost of another system to patch, monitor and back up. Confirm which installation method you plan to use before deciding. The MISP download page lists an installer for Ubuntu 24.04, along with Docker images, Ansible roles, Puppet and RPM packages, and your method affects how misp-modules is installed, started and upgraded. Ask your deployment team to confirm how the service is configured to reach the core instance in that method.
Version pairing is the decision with the most upgrade risk. MISP 2.5 is the recommended version for new deployments, and MISP 2.4 is end of life with security fixes only, so new installations should start on 2.5. The 2.5 release notes for version 2.5.47, released on 17 September 2026, introduced a new database migration system with PostgreSQL support. For your plan, the migration path, the database engine you choose and the module set are linked decisions. Read the release notes for the exact release you will deploy and for each release you will move through. Confirm that every misp-modules version you intend to run is compatible with that exact MISP release before you upgrade either component, and keep a tested rollback for both.
Reachability should be limited to the MISP instance. Configure the service to accept connections only from the MISP host or its network segment, and block access from analyst workstations and other general networks. Import and enrichment tasks may make outbound requests to external services, so decide whether those calls go direct or through an approved egress path, and record the destinations your policy allows. Test both directions: a connection from the MISP host should succeed, and the same request from another host should fail. Repeat the test after each upgrade, because a rebuilt container or a changed firewall rule can quietly reopen the path.
How a MISP module rollout runs, step by step
This sequence takes a MISP import or export module from a confirmed platform version to a documented production service, with a checkpoint at each stage so the team can see what is finished before the next stage starts.
Confirm the MISP version and installation method
The team confirms the MISP version to be deployed and how it will be installed. The project recommends MISP 2.5 for new deployments and advises against new 2.4 instances, and it lists the Ubuntu 24.04 installer, Docker images, Ansible roles, Puppet and RPM packages as options. Confirm the chosen method with your platform team and confirm which misp-modules service version pairs with it. Done when the version, installation method and host layout are written into the change record.
Inventory source formats and target exports
List every source that must enter MISP, such as CSV files, email reports or sandbox output, and every consumer that must receive data, such as YARA, PDF, KQL or CEF tooling. For each pair, record the sample files available, the fields that matter and whether a built-in MISP import or export format already covers it. Output is a single table mapping each source and target to a built-in format or a named module, with owners for each row.
Choose modules or built-in formats per source
Decide, row by row, whether the built-in MISP formats are enough or whether an import or export module is needed. Built-in exports include MISP JSON, STIX 1 and 2, OpenIOC, CSV, text, Suricata, Snort, Zeek and RPZ, so a module is only justified where those do not match the target. Record the reason for each module choice and confirm that each module's license and maintenance status fit your policy. Output is an approved module list that the team signs off before any build work starts.
Build and test with sample files in a non-production instance
Install misp-modules and the chosen modules on a non-production MISP instance, then run each import with representative sample files, including malformed and edge-case records. Check that attributes land with the expected types, categories, comments and tags, and that each export produces output the downstream tool accepts. Keep a log of inputs, outputs and failures. Done when every sample passes or has a documented, accepted exception.
Review mapping and distribution rules with the threat intelligence team
Walk the threat intelligence team through each mapping, including how imported attributes are categorized, which tags apply and what default distribution level and sharing group new events receive. Distribution determines who can see an indicator, so this review should be explicit and recorded. Confirm which exports are allowed to carry which distribution levels. Output is a signed mapping and distribution record that the rollout will follow.
Enable the modules in production
Deploy the approved configuration to the production instance using the same installation method verified in the non-production build, so the two environments differ only in data and secrets. Enable only the approved modules, restrict access to the modules service to the MISP host, and run one controlled import and one controlled export with known content. Done when the test records appear with the agreed distribution and the export reaches its consumer.
Hand over runbooks and confirm ownership
Write runbooks covering how each module is started, how a failed import is retried, how to update or roll back a module and how to check the modules service after a MISP upgrade. Name an owner for each module and each mapping rule. Hand over the runbooks, the sample test set and the mapping record to the operating team, and confirm the upgrade path with the vendor documentation before the next MISP release. Done when the operating team has run one retry from the runbook without help.
What drives the effort and cost of module work
This table lists the factors that change how much work a misp-modules import or export project takes, why each one matters, and what to do to keep it contained. Read it before asking for a quote, because most of the variation comes from the inputs you can control before work starts.
| Driver | Why it changes the effort | How to keep it down |
|---|---|---|
| Number of source formats | Each import format needs its own parser, field mapping and edge-case handling, and CSV, email and sandbox reports vary widely between senders. | Limit the first release to the formats you receive most often and add others later as separate, scoped items. |
| Variability within each source format | A CSV from one tool can differ in headers, encodings, delimiters and nested fields from the same tool's next version, which widens parser testing. | Ask for representative sample files from each producer and agree which versions are in scope. |
| Number of target exports and consuming systems | Each export format, such as YARA, KQL, CEF or PDF, has its own syntax rules, and each consuming system may expect a different dialect or field set. | Name the consuming system and its version for every export, and confirm the exact syntax it accepts. |
| Real versus synthetic sample data | Real samples expose the messy values that break parsers, but they may contain sensitive content that needs handling rules. Synthetic samples are safer to share but can miss edge cases. | Use sanitized real samples where possible, and keep a small synthetic set for cases that cannot leave the source system. |
| Analysts who must approve mappings | Each approver adds review rounds, and disagreements about how a field maps to a MISP attribute type or category can reopen work. | Name one accountable approver per format and agree the mapping rules in writing before development begins. |
| MISP version and installation method | Module behavior, API responses and packaging differ across MISP releases and installation methods, so the work depends on the target build. MISP 2.5 is the recommended version for new deployments. | Confirm the MISP version and installation method before scoping, and avoid starting new work on 2.4, which is end of life for feature work. |
| Testing against a non-production instance | A separate instance with production-like data is needed to test imports and exports without touching live events or feeds, and building one adds setup effort. | Decide early whether a non-production MISP instance already exists, and reuse it rather than building a new one for each module. |
| Existing custom PyMISP scripts | Teams that already maintain PyMISP automation can reuse authentication, error handling and deployment patterns, which shortens the build. Teams without it need that foundation built first. | Inventory existing scripts and their owners, and identify which ones the new modules should reuse or replace. |
How module output reaches SIEMs, detection and other MISP tools
Module output is only useful once a downstream tool can read it. The connections below cover SIEM ingestion, Microsoft hunting, endpoint and sandbox rules, leadership briefings, automation and analyst sign-in. For documented partner connections, check the MISP integrations content group and the partner product's own documentation.
CEF output for SIEM ingestion
The CEF export module turns MISP attributes into Common Event Format lines that a SIEM can parse as events. Map the CEF fields to your SIEM's parser and decide which attributes, tags and distribution levels are allowed to leave MISP before a feed is connected. Confirm the CEF dialect, field names and version your SIEM accepts in its own documentation, then test with a small event set before enabling a scheduled export.
KQL for Microsoft-based hunting
KQL export output gives hunters queries they can run in Microsoft's query-based tools against telemetry the organization already collects. Indicators from an event become search conditions, so each query is only as precise as the attribute types and the tables it targets. Confirm the table names, column schema and query language version in the Microsoft product you use, and review each generated query for broad matches before scheduling it.
YARA rules for endpoint and sandbox tools
The YARA export module packages file-based indicators as rules that endpoint scanners and sandbox platforms can load. Generated rules inherit the quality of the source attributes, so review hashes, strings and conditions for overly generic matches before they reach production. Confirm which YARA syntax version and modules your endpoint or sandbox product supports, and keep rule sets versioned so a rollback is possible.
PDF briefings for leadership
The PDF export module produces a readable summary of an event for executives, board members and partner teams who work outside MISP. Decide the template, the classification marking and which attributes are removed before distribution, because a PDF leaves the platform's sharing controls behind. Confirm the layout options and rendering behavior in your deployed module version, and have a reviewer check each briefing before it is sent.
restSearch and PyMISP automation
The MISP API exposes restSearch for querying events and attributes, and the bundled PyMISP library wraps those calls for scripts and pipelines. Automation runs under an API key tied to a user role, so that role defines what a pipeline can read and publish. Confirm the endpoint parameters and PyMISP version against your MISP release, then document key rotation and the query filters each pipeline uses.
OidcAuth single sign-on for analysts
The OidcAuth plugin lets analysts sign in through an OpenID Connect provider instead of local MISP passwords. It maps identity provider roles to MISP roles and assigns the first matching role by priority, so role claims and priority order decide what each analyst can do. Confirm the provider's claim names and your priority list in the plugin README for your MISP version before rollout, and test a sign-in for each role.
What do teams ask before adding MISP import and export modules?
How much do MISP import and export modules cost to add?
Cost follows from the written scope, and DeployOpen does not publish a price list. The main components are format analysis, field mapping design for each format, building or configuring each module in misp-modules, testing against your own MISP instance, deployment, and handover documentation. Most of that work is one-time. Recurring costs appear when you add a format, change a source, or update modules after a MISP upgrade, and those are usually scoped separately. Cost rises with the number of formats, the variety in sample files, the complexity of the target system (for example, a SIEM schema with many custom fields), and the number of review cycles your mapping owners need. Ask for a quote that lists each format as its own line with build, test and handover tasks, plus any retainer for upkeep.
How long does a MISP import or export module rollout take?
The timeline is set by a few factors, and the duration should come from the written scope. The biggest variables are how many formats are in scope, how quickly your team supplies representative sample files, how many rounds of mapping review your owners need, and how soon DeployOpen receives access to a test MISP instance and the misp-modules host. Target-side details also matter. For KQL, CEF or YARA outputs, the receiving team's table names, field conventions and rule standards set the review load. A common sequence builds one format end to end, then repeats the pattern for the rest. Ask for milestones tied to client inputs, so delays in sample files or access are visible in the schedule.
What must our team provide before a module build starts?
Sample files: representative, redacted examples for each import format, including malformed or edge-case files, plus examples of the expected output for each export target. Mapping owners: a named person per format who can approve field mappings and decide how ambiguous values are handled. Target system details: for exports, the schema, table or field names, CEF vendor and product fields, and any YARA rule conventions your team uses. Access: a test MISP instance, the misp-modules host or container, service accounts, and network paths to any sandbox or SIEM used in testing. Decisions: which environment will host the modules and who approves production changes. Ask that each item has an owner and a due date in the written scope.
Can an internal team build MISP import and export modules alone?
It can be, if the team has the right mix of skills and time. The work needs Python development against the misp-modules structure, working knowledge of MISP objects, attributes and events, and enough format knowledge to map fields correctly for CSV, email, sandbox reports, YARA, PDF, KQL and CEF. It also needs test discipline, including a regression set of sample files and a staging instance that mirrors production. The main risks are dependence on one person, unclear mapping ownership and no plan for upgrades. A practical pattern is to build one format internally or with a partner, document the pattern, and then decide which remaining formats to take on. Weigh that against your team's current workload and the cost of a partner's written scope.
How do MISP modules keep working after a MISP upgrade?
Modules stay current through a repeatable test cycle that runs before every MISP upgrade. The target version matters first. MISP 2.5 is the recommended line for new deployments, and MISP 2.4 is end of life with security fixes only. MISP 2.5.47 introduced a new database migration system with PostgreSQL support, so any database-related change should be checked in staging before production. Practical steps include pinning module versions, running the sample-file regression set against a staging instance on the target release, reviewing misp-modules changes in the release notes, and keeping a rollback plan. Confirm the target version during scoping. Ongoing upgrade work can be covered under a retainer.
Does MISP module data leave our environment during import or export?
It depends on each module, so confirm it module by module during scoping. Modules that parse files into MISP attributes, or that write local output such as YARA, PDF, KQL or CEF files, process data inside the misp-modules host you control. A module that calls an external service, such as a hosted sandbox or analysis API, sends the relevant data to that service. Files delivered to a SIEM or detection platform leave your MISP environment through your own pipeline, which your team already governs. Ask for a data flow per module that lists inputs, outputs, network destinations and retention, and check the egress rules on the hosting network. Where a module depends on an external service, ask whether a self-hosted option exists before approving it.
When are MISP's built-in export formats enough without modules?
The built-in formats cover many sharing needs, so add modules only when a required input or output is missing. MISP exports MISP JSON, STIX 1 and 2, OpenIOC, CSV, text, Suricata, Snort, Zeek and RPZ, and provides an API with restSearch and the PyMISP library. If your consumers read one of these formats, the built-in options may be enough, and the work becomes configuration, export filters and a scheduled pull. Modules become worth scoping when a consumer needs YARA, PDF, KQL or CEF output, or when a report format must be imported. Confirm the exact format versions and field requirements with each consumer first, because a format that looks covered may omit a field your detection content depends on.
How DeployOpen works on this
DeployOpen plans, builds, documents and supports self-hosted MISP deployments inside infrastructure you control, including the misp-modules service that runs import and export modules alongside the core platform. Each module engagement starts from a written scope that names the data sources, formats and consumers involved.
How we scope
- Inventory the input sources such as CSV files, email reports and sandbox outputs that should reach MISP events.
- Agree which export targets such as YARA, PDF, KQL or CEF are required, and which built-in MISP formats already meet the need.
- Record the written scope, deliverables and timeline before work starts, since most engagements are fixed-scope.
How we build
- Deploy and configure misp-modules, then validate each import and export module against representative sample data.
- Map source fields to MISP attributes and objects, and confirm distribution levels and sharing groups for imported data.
- Test outputs in the consuming tools, such as detection or reporting platforms, before enabling them for analysts.
How we hand over
- Document module versions, configuration, data mappings, known limitations and the steps to add a new module.
- Run a handover session with the teams who will trigger imports and exports and maintain the configuration.
- Deliver test records and rollback steps so your team can repeat checks after each MISP or module upgrade.
How we support
- Offer ongoing support, upgrades and module updates as a retainer, scoped in writing to your environment.
- Plan module reviews alongside MISP release upgrades, such as the move from MISP 2.4 to 2.5 where it applies.
- Confirm with your team which module and parser changes need re-testing before each change reaches production.
