Overview
MISP customization means changing how a MISP instance models, enriches, routes and automates threat information so it fits your organization instead of the defaults. The work usually covers five areas: custom object templates for data types that the default set does not describe, taxonomies and galaxies for internal classification, enrichment and expansion modules that pull in internal or third-party context, workflows and automation built on PyMISP and the REST API, and the packaging and testing that keep all of it working when MISP is upgraded.
Several triggers usually start the work. A team may outgrow the default object types and need to record assets, business services or internal case references in a structured way. Another common trigger is a need to feed internal asset inventory or vulnerability data into enrichment so analysts see which indicators touch systems they run. A planned move from MISP 2.4, which is end of life with security fixes only, to MISP 2.5, the recommended version for new deployments, is also a common point to review what has been customized, since each change may need retesting against the new release.
In-house or partner: teams with strong Python skills and MISP administration experience can build much of this themselves, particularly simple object templates and PyMISP scripts. Teams without that skill often outsource the design and the upgrade-safe build, because the hard part is not the first working version but keeping custom code, templates and module settings intact across releases. Before deciding, confirm who on your side will own the code after handover, which MISP version you will run, and how changes will be tested before they reach production.
What the work includes
Each package is defined in a written scope agreed before work starts, with deliverables, acceptance checks and responsibilities listed. The packages below cover the parts of a MISP customization that most often need to be maintained after go-live.
Object template design and creation
Object templates define the fields, attribute types, required values and relations for structured data that MISP does not cover by default, such as an internal asset or a case-specific indicator set. Decide these before building, and confirm that existing feeds and sync partners can handle the new object. Changes to a template affect every event that uses it, so plan versioning from the start.
Taxonomy and galaxy design
Taxonomies tag events and attributes with controlled vocabulary, and galaxies add clusters such as threat actors, tools or internal campaign groupings. Local content can stay inside your instance for classification that partners should not see. Confirm which custom content will be shared, since taxonomy and galaxy data carry their own CC0 or BSD licensing, separate from the AGPL software license.
Enrichment and expansion module integration
Expansion and enrichment modules query external services or local tools to add context to attributes, such as lookups against an internal asset register or sandbox results. Each module needs its own credentials, timeout and error handling, plus a decision on whether results are stored or only displayed. Test how analysts experience a slow or failing lookup before go-live.
Workflow and automation scripts
Scripts built on PyMISP and the restSearch and OpenAPI-described API automate triage, tagging, export to detection tools and scheduled cleanup. Run them under a dedicated automation user with the narrowest role and sharing group that works, store its API key in a secrets manager, and log every write. Review each script on MISP upgrades, because API responses and field names can change.
Documentation and handover
The handover covers the deployed configuration, object and taxonomy definitions, module settings, and each script with its owner, schedule and upgrade test steps. Agree the format and acceptance tests in the written scope. Confirm which items your team must maintain after the engagement ends, so ownership is clear from the first day.
What drives cost and duration
The table lists the factors that most change the effort of a MISP customization engagement, why each one matters and how to keep it under control.
| Driver | Why it matters | How to keep it down |
|---|---|---|
| Number and complexity of custom objects | Each custom object type needs a template, field definitions, validation, correlation behavior, export mapping and tests. Relationships between objects multiply the test cases. | Start from existing MISP object templates where they fit. Limit new objects to fields analysts will fill in, and agree the object list in writing before build. |
| Taxonomies and galaxies kept local or published | Local taxonomies and galaxies need ownership, review and versioning. Publishing them outward adds a review cycle and a reason to keep the content consistent across instances. | Keep local content in a small, named set. Decide up front which items are published, and assign one owner for each taxonomy or galaxy. MISP taxonomy and galaxy data is CC0 or BSD licensed, so the cost is governance, not licensing. |
| Number of external enrichment services and their authentication models | Each enrichment module or service needs its own configuration, error handling, rate limit handling and credential storage. Services using API keys, OAuth or mutual TLS each need a separate secrets path and rotation plan. | Enable only services the analysts use. Confirm the authentication model for each service early, and agree who owns credentials and rotation. Test failure behavior, such as timeouts and quota exhaustion, in the build phase. |
| Number of automation workflows | Each workflow needs triggers, conditions, a test dataset, a rollback path and an owner. Workflows that call external systems inherit the complexity of those systems. | Prioritize workflows by analyst time saved. Build a small set first, document inputs and outputs, and avoid workflows that duplicate built-in MISP features. |
| Number of environments (development, staging, production) | Each environment needs its own installation, configuration sync, data seeding and test runs. Drift between environments is a common source of rework. | Keep configuration as code in version control and deploy the same artifacts to each environment. Agree which environments the engagement covers and who maintains the non-production ones afterward. |
| Number of upgrades expected during the engagement | Customizations depend on MISP internals, so each release can break modules, object templates or PyMISP scripts. MISP 2.4 is end of life with security fixes only, and MISP 2.5 receives frequent releases, so upgrade work may fall inside the engagement. | Confirm the target release at scoping. Plan a regression test suite for custom objects, workflows and integrations. Ask whether one upgrade is included or whether upgrades are handled under a retainer. |
| Compliance and evidence requirements | Assessors may ask for evidence of access control, change records, logging of configuration changes and documented data handling. Each requirement adds documentation and test steps that the team must produce and keep current. | Ask which frameworks and controls apply before scoping. Agree the evidence list in writing, such as change records, test results and access reviews. DeployOpen prepares evidence for assessments, but independent auditors issue any audit outcome. |
Project phases and outputs
This sequence moves a MISP customization from agreed requirements to a tested production instance and a maintenance runbook your team can operate.
Review requirements and data model
DeployOpen reviews your use cases with your threat intelligence and security teams, then maps the event, attribute and object types you need against the standard MISP model. Confirm during scheduling which teams must sign off and who may approve data model changes. Output: a signed requirements record and data model review listing each custom object, its fields and the sharing rules that apply to it.
Design objects, taxonomies and galaxies
DeployOpen drafts object templates, taxonomy definitions and galaxy clusters, and decides which ones are shared with partners and which stay local. Taxonomies and galaxy data carry their own licenses (CC0 1.0 or the 2-clause BSD license), separate from the AGPL software license, so the design records the license for each one. Output: a design document with template definitions and a sharing matrix your team approves before the build starts.
Build in a non-production instance
DeployOpen builds the approved design on a non-production MISP instance on the 2.5 line, which the project recommends for new deployments, and keeps configuration and custom code in version control. Confirm which installation method you want, since the project lists several options. Output: a working staging instance and a configuration repository your team can review.
Test integrations and automation
DeployOpen tests the REST API, PyMISP scripts, feed and sync connections, export formats and any enrichment or workflow automation against the staging build, using test events. Failures are logged, fixed and retested before the sequence moves on. Output: a test report listing each case and its result, with any accepted risk signed off by the owner of each integration.
Rehearse the upgrade to the target 2.5 release
DeployOpen copies production data into a rehearsal environment, upgrades it to the target 2.5 release and checks that custom objects, taxonomies, galaxies, roles and sharing groups survive. The rehearsal covers the database migration system introduced in 2.5.47, and the team records any manual fixes. Output: a rehearsal log and a tested upgrade and rollback procedure.
Roll out to production
DeployOpen applies the tested procedure in your agreed change window, confirms that backups exist before any change, and checks functions and sync partners after cutover. Confirm the window, the rollback trigger and the go-live approver during scheduling. Output: a completed go-live checklist with post-cutover checks and a documented rollback decision point.
Hand over with a maintenance runbook
DeployOpen walks your administrators through the customized instance and delivers a maintenance runbook covering upgrades, feed and sync management, backup restores and an inventory of every custom object and taxonomy. Your team runs a supervised check before the handover closes. Output: a signed handover record and the runbook, which becomes the reference for future MISP upgrades.
What usually goes wrong
Most MISP customization problems surface during upgrades, publication, and handover, long after the build has been accepted. Each card names one risk and the check that prevents it.
Customizations that break on upgrade
Custom database changes, objects, and modules can stop working when MISP moves to a newer release. Version 2.5.47, released on 17 September 2026, introduced a new database migration system and PostgreSQL support, so schema changes made outside the upstream migration path need early testing. Run each planned upgrade against a copy of production data before the production window.
Local object definitions drifting from upstream
Custom object templates that reuse upstream names but change relations or attribute types gradually diverge from the conventions that tools, feeds, and partners expect. Compare every local definition with the current upstream templates at each review, and record the reason for each deviation so future maintainers can judge it.
Enrichment modules tied to external services
Enrichment modules that call third-party lookups depend on services whose terms, rate limits, and API access can change without notice to your team. Before go-live, confirm with each provider that the current terms cover your use and any sharing of results, record who owns each API key, and define what analysts see when a lookup fails.
Automation with hard-coded keys or IDs
PyMISP scripts and workflow automation that embed API keys, organization IDs, or sharing group identifiers break when keys rotate or an instance is rebuilt, and they expose credentials when copied between hosts. Load secrets from a vault or the environment, parameterize organization IDs, and test each change against a staging instance first.
Sharing settings that change on publication
Distribution levels, sharing groups, and sync filters can apply differently once an event is published or synchronized, so an attribute meant to stay internal may reach a partner. Publish sample events that use your custom objects, then confirm the resulting distribution on each sync partner before automation is enabled.
Unclear ownership after handover
Custom objects, taxonomies, galaxies, scripts, and modules often have no named maintainer once the build team leaves. Assign an owner to each item, keep code and configuration in version control, and agree who approves changes to shared content. Taxonomies and galaxies carry CC0 or BSD terms that are separate from the AGPL software license, so record those terms too.
In-house or with a partner
This table compares which MISP customization work teams usually keep in-house and which they often hand to a partner, along with the skills each row requires, so you can decide where to staff gaps.
| Work part | Usually kept in-house | Usually outsourced | Skills required |
|---|---|---|---|
| Requirements and threat intelligence modeling | Yes, with your analysts who know which events, sectors and indicator types matter to you | Facilitation support for workshops and written requirements | Threat intelligence analysis, knowledge of your sharing partners and incident workflows |
| Object and taxonomy design | Shared: your analysts define the meaning of fields and tags, the partner drafts object templates | Template drafting, validation against MISP object definitions and sharing guidance | MISP object model, taxonomy conventions, analyst vocabulary, data modeling |
| PyMISP script development | Ownership of the code once handed over, with at least one engineer who can maintain it | Initial scripts for ingestion, export and bulk updates, plus tests | Python engineering, PyMISP and the REST API, error handling, unit testing |
| Enrichment integration | Access to the enrichment services and decisions on which data may leave your network | Connector build, enrichment module configuration and failure handling | Developer skills for the module or API, security engineering for data handling and credentials |
| Upgrade testing | Platform engineering owns the staging environment, change approval and production rollout | Regression test scripts for custom objects, modules and PyMISP code before each release | Platform engineering, CI practices, MISP release notes review, test data management |
| Documentation and handover | Acceptance of the documentation and operation of the runbooks after handover | Written design records, runbooks, object and script inventories, training sessions | Technical writing, MISP administration knowledge, clear version control of configuration |
How the work differs by situation
A new MISP 2.5 instance lets the team make customization decisions before data accumulates. Design follows the model you intend to keep for years.
- Decide which custom objects, taxonomies and galaxies you need, and record which are local and which come from the shared catalogue.
- Keep local modules, templates and configuration in version control so the baseline can be rebuilt on demand.
- Build test cases for each custom object and workflow on a staging instance before anything reaches production.
- Plan the upgrade path at the start by confirming how each custom component behaves on the 2.5 release line you will track.
Local changes that built up over time are the main risk in an existing 2.5 instance. Cleanup starts with an inventory, not with deletion.
- Inventory edited core files, custom plugins, local taxonomies, galaxies, scheduled tasks and custom scripts.
- Compare each change with the upstream baseline and classify it as keep, move into a module, or retire.
- Identify dependencies such as automation, dashboards and sync partners that rely on a local field, tag or object.
- Test the cleaned instance on a copy of production data, and keep a tested rollback path for the cutover window.
Custom fields from a commercial or other threat intelligence platform rarely map one to one onto MISP. Mapping decisions shape nearly every later step.
- Build a field map that lists each source field, its MISP destination (attribute type, object, tag or galaxy), and any cases the map does not cover.
- Decide how distribution and sharing settings are assigned during import, since source access controls seldom translate directly.
- Load samples first, then validate counts, attribute types and relationships before any bulk import.
- Confirm which custom objects need templates in MISP and who will maintain them after cutover.
Without internet access, every feed, taxonomy update, module dependency and enrichment service must be brought in and hosted internally. Each of these becomes a recurring process.
- List the feeds, galaxy and taxonomy updates, and enrichment services the design needs, and define an approved transfer process for each.
- Mirror software packages and container images through the approved path, and keep checksums with each transferred artifact.
- Host enrichment services inside the enclave and test expansion modules against them, because public lookups will not be reachable.
- Test every upgrade in a staging enclave first, since each release must cross the boundary before reaching production.
A container-based MISP changes how configuration, persistence and upgrades behave. Images and volumes become part of the design, not an implementation detail.
- Build custom modules, configuration and templates from version-controlled sources, and keep them out of running containers.
- Confirm persistence for the database, Redis and file storage, and plan backups for each volume.
- Test pod restarts, worker scaling and rolling upgrades in a non-production cluster before production changes.
- Confirm which container installation option the project supports and verify that each image tag matches a release line you have tested.
What you need to provide
Before any customization work starts, your team has to supply a test instance, administrator access, and written decisions that only your organization can make. Each item below has a named decision owner on your side, and a fixed-scope quote assumes these are in place. Gaps here are the most common reason a customization timeline slips, so confirm the owners before the scope is signed.
First, provide a test instance holding a copy or representative sample of production data, so custom objects, taxonomies, galaxies and modules are built against real event shapes. Your MISP administrator (or the team lead who owns the platform) should approve how much production data is copied, and your data protection or privacy lead should confirm that copying sensitive attributes into a test environment is permitted. Provide administrator access and API keys for the test environment only, issued to named DeployOpen engineers and revoked at the end of the engagement.
Second, supply a written list of intelligence use cases and the data fields each one needs, such as which attribute types, object templates, tags and enrichment results matter to analysts. The threat intelligence or CTI lead owns this list. Name a business owner for each taxonomy and galaxy you plan to maintain locally, and confirm who approves changes to them. Also name a contact for each enrichment service, since those services need credentials, rate limits and vendor terms confirmed by someone who can speak for them.
Third, define the production change window and approval process: who signs off a release, who is told when a module changes, and how a rollback is authorized. The IT operations or change management manager owns this. Finally, decide whether locally created content will ever be shared with partners or trusted communities. The CISO or information sharing owner should make this call, because it determines how custom galaxies and taxonomies are licensed, tagged and exported. Record the decision in writing, since it shapes the sharing configuration covered in the sync and sharing group work.
Frequently asked questions
What does MISP customization cost, and what drives the price?
The cost depends on how many custom objects, taxonomies, galaxies, modules and workflows are in scope, and on how much of that must be built, tested and documented. The main cost components are the design of the data model, development and code review, test environments, deployment to your servers, and handover. Costs rise with the number of integrations, the need for custom sharing rules, and the number of upgrade cycles the work must survive. Ask for a fixed-scope quote that lists each customization, the environments it touches and the handover items. DeployOpen does not publish a price list, so the quote follows from that written scope.
How long does a MISP customization project usually take?
Duration is set by the number of customizations, how fast decisions are made about data models and sharing rules, and how many systems must be integrated and tested. Work that needs a new object template or galaxy usually takes longer than a configuration change, because it needs validation against real events. Schedule is also shaped by your change windows, access to a staging instance and the availability of analysts who can review results. Agree on the timeline in the written scope, and ask for milestones tied to each deliverable rather than a single end date.
Can our internal team customize MISP without outside help?
Yes, many teams extend MISP with their own staff, especially for configuration, taxonomies and PyMISP scripts. The questions to answer first are whether you have engineers comfortable with PHP and CakePHP for custom modules, whether you can run a staging instance that mirrors production, and who will maintain the changes after each MISP release. Internal teams often struggle with upgrade testing and documentation. A partner can cover one of these gaps, or review your design before you build it, depending on what you need.
How do custom objects survive MISP upgrades?
Custom objects survive upgrades when they are kept outside MISP's core code and defined through supported extension points, such as object templates, and when their schemas are versioned and documented. Changes made directly to core files are likely to be overwritten or to conflict during an upgrade. Before each upgrade, the object templates, PyMISP scripts and modules should be run against a staging copy of the database. Confirm with the MISP project which extension mechanisms apply to your target 2.5 release, because the project has changed its database migration system recently.
Can we keep taxonomies and galaxies private within our organization?
Taxonomies and galaxy data are licensed under CC0 1.0 Universal or the 2-clause BSD license, which is separate from the AGPL license of the MISP software. Licensing does not stop you from keeping your own taxonomies and galaxies internal, but you should confirm the license of any third-party data you import before you redistribute it. Privacy is a matter of configuration: decide which taxonomies are enabled on each instance, and which sharing groups and distribution levels apply to events that use them. Ask for this policy to be written into the handover.
What do we need to provide for a customization project?
You need to provide a named decision owner, access to a staging environment that matches production, sample events that represent your data, and a list of the security tools and feeds that will consume the output. Your team should also provide the identity and role model if customizations depend on access rights, and the change windows for testing and deployment. Early input from the analysts who will use the platform shortens review cycles. Ask the partner to list these inputs in the written scope so that delays are visible from the start.
What does the handover include at the end of a customization project?
A handover should include the deployed customizations, their source code or configuration files, a record of design decisions, test results and an upgrade checklist for the next MISP release. It should also cover runbooks for administrators, the list of PyMISP scripts and their owners, and training for the people who will maintain the work. Ask whether the handover includes documentation for taxonomies and galaxies, and how sharing settings were verified. These items should be named in the fixed-scope quote so you can check them at delivery.
How DeployOpen delivers MISP customization
DeployOpen plans, builds, tests, documents and supports MISP customizations inside your own infrastructure, so custom objects, taxonomies, workflows and automation stay under your control. We work from a written scope and keep the changes maintainable across future MISP upgrades.
How we scope
- We agree in writing which custom objects, taxonomies, galaxies, modules and workflows are in scope.
- We map each customization to the events, attributes and sharing groups it must respect.
- We confirm which PyMISP scripts and REST API integrations your teams and tools need.
How we build
- We build custom objects and taxonomies against a documented MISP version you have approved.
- We keep module, workflow and automation code in version control with reviewed changes.
- We test enrichment and expansion modules with sample events before they reach production.
How we hand over
- We deliver documentation covering each customization, its configuration and its dependencies.
- We provide the test cases and a rollback approach for every custom component delivered.
- We walk your administrators through the upgrade checks needed when MISP releases change.
How we support
- Ongoing support and upgrade testing for customizations are available as a retainer.
- We re-test custom modules and scripts against each MISP upgrade before it reaches production.
- Support scope, response expectations and reporting are defined in the written agreement.
