MISP workflows and automation

Each check in a MISP publishing workflow should be classed as either a block, which stops the event from being published, or a warning, which lets it go out and flags it for follow-up. Making that call check by check, before the workflow is built, matters more than the tooling itself. The useful test is simple: would a recipient act differently on this event if the field were missing or wrong? Fields that change how a partner handles the data, such as the TLP marking, distribution level and sharing scope, are strong candidates for blocking. Fields that add analytical depth, such as a threat actor name or a confidence value, often belong in a warning tier. A blocking rule protects recipients, but it also delays sharing. If every event must carry a named threat actor before it can be published, an active phishing domain or a freshly observed exploit indicator can sit in draft while an analyst searches for attribution. The indicator loses value every hour it is held, and the communities that could block it wait with it. A reasonable pattern is to block only on the fields that make an event unsafe to share, and to route attribution gaps to a warning that names the responsible analyst and a deadline for closing the gap. A warning-only rule has the opposite failure. Events with no source, no confidence value or an incomplete context can reach partner instances through synchronization, where the original author cannot follow up with each recipient. Once data has been distributed, retracting it does not guarantee removal from every copy, so the cost of an incomplete event is paid downstream. Ask your sharing partners how they handle retractions and which fields their own intake processes require, because those answers set the minimum your instance should enforce before anything leaves it. Conflicting TLP labels deserve close attention. An event marked at one level while an attribute or tag carries a more permissive marking creates a sharing risk that no amount of later clean-up can reverse. Workflows can normalize tag formatting automatically, but they cannot decide which marking is correct. A sound approach is to block publication on any unresolved conflict and route the event to a named owner with authority over the marking. Confirm which TLP taxonomy and distribution levels your MISP version exposes before writing these rules, since the checks depend on the exact values stored. Before implementation, agree the full rule set with your information sharing owners. For each check, record whether it blocks, warns or escalates, who may override it, how the override is logged, and how long a warning can stay open. Test the rules against sample events that you label as illustrative, including a fast-moving indicator and a deliberately mislabeled event, and confirm the behavior in the workflow documentation for your deployed release. The owners who answer for the data should approve the thresholds, because they carry the consequences of both delay and disclosure.

The cost of MISP workflow automation comes mainly from people's time: the analysts and administrators who decide what a workflow should do, the engineer who builds and tests it, and the person who keeps it correct after the sharing rules change. Hardware and licensing are rarely the deciding factor, because MISP is licensed under the GNU AGPL version 3 and the workflow work happens inside an instance you already run. Separating one-time build work from recurring rule maintenance is the most useful step when you compare your own team with a partner, because the two categories are paid for and staffed in different ways.

Discovery comes first and is often underestimated. Before any workflow is written, someone has to document the publishing rules that exist today, including which events are allowed to publish, which tags must be present, how TLP markings are applied, and which enrichment modules touch sensitive data. In many instances those rules live partly in habit and partly in a few administrators' heads. Expect discovery to take longer where several sharing groups, distribution levels or synchronized communities depend on different conventions, and ask any partner to show how they will capture and confirm that inventory before they quote build work.

Policy decisions are the second cost component and they belong to the sharing owners, not the implementer. Someone with authority must decide what a blocked publish looks like, whether a missing TLP tag is corrected automatically or rejected, which chat channel receives alerts, and who may override a block. Each open decision adds review cycles and delays build and test, so resolve them in writing first. The build and test work then covers each workflow separately: its trigger, its conditions, its action, and the test events that prove it blocks, passes or alters data as intended. Integration with chat or webhook targets adds its own testing, including credentials, rate limits, and what happens when the target is unavailable.

Documentation and handover are one-time costs that are easy to cut and expensive to skip. A handover should explain each workflow's purpose, its owner, the decisions behind it, the test cases, and how to disable it safely. Ongoing review is the recurring cost. Taxonomies, galaxies, warning lists and feeds change over time, and a workflow that normalized tags correctly last year may need new rules when a taxonomy adds or retires values. Ask any quote to state who reviews workflows, how often, and who pays for changes that follow an upstream update, because those answers determine the long-term cost more than the initial build.