MISP for energy and industrial control systems

The first decision is the direction of travel. Indicators can reach OT monitoring by pull, where a host inside the segment fetches an export from MISP, or by push, where a host on the corporate side places an export somewhere the monitoring side can read. MISP exports Suricata, Snort, Zeek and RPZ formats, so the export format is rarely the hard constraint. The boundary is. Under CIP-005-7, routable-connected assets of high and medium impact BES Cyber Systems must sit inside an Electronic Security Perimeter, and all Interactive Remote Access must pass through an Intermediate System. Draw every indicator path against that boundary before anyone chooses a tool or a schedule.

A staging host is the component that makes either direction workable. It is a dedicated system placed on the correct side of the Electronic Security Perimeter, configured to hold only the export files and the minimum credentials needed to move them. Its role is narrow: it receives or fetches a defined set of formats from MISP, validates them, and hands them to the sensor. Keep it out of general administrative use, log every transfer, and give it no route back into the corporate network that the design does not require. Confirm with your network and compliance teams which zone the staging host belongs to, which firewall rules open each flow, and whether your monitoring platform can read the file formats from that location at all.

The review step is the control that stops operational detail from flowing outward. Indicator records shared from OT sites can carry more than a hash or a domain. Event descriptions, attribute comments, asset names, process network addresses and galaxy tags can reveal topology or process information. Before anything leaves the sharing side, a named reviewer should check attributes against a written rule set that states which fields are stripped, which distribution level applies and which tags are permitted. MISP distribution levels and sharing groups help enforce this, but they cannot replace a human check on each export template. Record the reviewer role, the rule set and the evidence of each review, because an assessor will ask how the boundary was tested.

Feasibility is not something this page can settle for you. Whether a pull or push path works depends on your segmentation design, the firewall or one-way transfer options your architecture allows, and what your monitoring vendor accepts as input. Ask the vendor which of the Suricata, Snort, Zeek or RPZ formats its sensors ingest, whether it supports a scheduled file drop or only a live feed, and which parser version it runs. Then test one indicator end to end in a non-production segment and record each hop. The result is a documented path your team can defend, and one you can revise when the monitoring product or the network architecture changes.

Set the boundary between what your operator shares with a sector community such as ICS-CSIRT.io and what stays internal before the first event is created. In MISP, distribution levels and sharing groups decide who can see each event and attribute once it leaves your instance, and the platform supports custom sharing groups down to individual attributes. That granularity lets you publish a file hash or a domain while keeping the surrounding context private, but it also multiplies the places where a setting can go wrong. Write down three categories before you configure anything: indicators you publish to the community, indicators you only consume, and material that never leaves your environment. Map each category to one distribution setting and name one owner who approves changes to it.

Design sharing groups around purpose and audience. A single broad group reused for everything makes it hard to revoke one partner's access without affecting the others. Keep a community-facing group, an internal group for your own analysts, and any trusted peer organizations in separate groups, and document who belongs to each. Treat synchronization as part of the same boundary. Review which instances your instance pushes to and pulls from, which organizations are members of each group, and whether any event can flow onward without your approval. Test the design by checking what a user from each organization can actually see, and do not rely on the configuration screen alone.

The main risk in indicators is that they reveal more than the malicious artifact. An IP address, a domain or a comment can disclose asset names, internal address ranges or site details, which tells a reader where your operations are and how they are addressed. For illustrative purposes, an attribute comment that names a substation or a control room exposes location even when the indicator itself is public infrastructure. MISP's correlation engine matches exact values and CIDR overlaps, so a range you publish can be matched against other data. Exports to Suricata, Snort, Zeek and RPZ also carry indicator values into monitoring systems. Before publishing, strip internal context from comments, tags and object fields, share the observed indicator and keep your addressing plan out of it, and check the fields each export format includes.

Confirm with the community before you publish anything. Ask ICS-CSIRT.io, in writing, what it accepts from member operators, whether it expects indicators with internal references removed, how it applies TLP-style handling, and whether it redistributes received material to other members or partners. Also ask how long it retains data and who can see it. Do not assume that a TLP label in your instance maps to a specific MISP distribution level, or that the community will read the label the same way you do. Record the answers in your sharing policy and revisit them when the community changes its rules or when your instance moves to a newer MISP release, since features and export options change between versions.

Check NERC CIP-011-3, Cyber Security: Information Protection, with compliance counsel before any operational data is placed in MISP. That standard governs how information about BES Cyber Systems is protected. Whether a given indicator, event note or log excerpt falls within its scope is a legal and compliance question for counsel to answer. Get a written position on which data types may be shared, under what conditions, and who approves exceptions. DeployOpen does not provide legal advice, and nothing in this section should be read as an interpretation of CIP-011-3 or any other requirement. Once counsel has answered, build those rules into your distribution settings and your onboarding checklist for analysts.

The most serious failure is an MISP instance placed on the corporate network with a route into operational technology. Teams often do this because they want feeds to reach OT monitoring directly. The design decision is to keep the MISP instance outside the OT zone and move indicators across through a controlled export path. A host in a monitoring or DMZ-style zone can pull exports such as Suricata, Snort, Zeek or RPZ files from MISP, and nothing in OT initiates a connection back. Where the utility is subject to NERC CIP, check this path against CIP-005-7, which requires routable connections to high and medium impact BES Cyber Systems to sit inside an Electronic Security Perimeter. Ask your compliance lead to confirm whether any MISP flow crosses that perimeter before the design is approved.

The second failure is sharing indicators without a sharing-group review. MISP supports distribution levels and custom sharing groups down to individual attributes, and it can synchronize events automatically with other instances and trusted communities. The risk is a default distribution that sends an event to a whole community, carrying an internal address range, a vendor name tied to a specific substation, or a note about a plant's configuration. Define sharing groups for each community before the first event is created, set the default distribution to organization-only, and keep automatic synchronization disabled until a named reviewer has approved each group. Under CIP-011-3, confirm whether any exported content qualifies as BES Cyber System Information.

The third failure is feed noise reaching OT monitoring. Default intelligence feeds, warning lists and correlation through CIDR overlaps or fuzzy hashes can produce many matches against common IP ranges and domains. In an OT network, a flood of false positives trains operators to ignore alerts, which is the outcome the team was trying to prevent. Enable feeds selectively, filter exports to indicators that carry ICS-relevant context such as MITRE ATT&CK for ICS galaxy tags, and run new exports in monitor-only mode before any blocking rule is enforced. Keep a documented tuning review with the OT security vendor, and confirm which export formats its sensors ingest, since that list varies by product.

The fourth failure is an unmanaged MISP 2.4 installation. MISP 2.4 is end of life and receives security fixes only, and the project strongly advises against new 2.4 instances. Problems appear when a pilot is built on 2.4, or when an older instance is inherited and never added to the asset inventory. Build new deployments on MISP 2.5, record the exact version and patch level in the inventory, and plan any move from 2.4 with the upgrade script for Ubuntu. Treat the database migration introduced in 2.5.47, which adds PostgreSQL support, as a change that needs its own test cycle. Confirm the current patch level at build time, because the project publishes releases frequently.

The fifth failure is access that is not tied to the identity provider. Accounts created locally, shared administrator logins and leavers who keep access are common findings in new security tools. The OidcAuth plugin lets users sign in through an OpenID Connect provider and maps identity provider roles to MISP roles, assigning the first matching role by priority. Set the role priority deliberately, because a broad group listed first can grant more access than intended. Disable local password login for ordinary users, keep one documented break-glass administrator account with its own controls, and confirm that removing a user at the identity provider removes their MISP access in the same review cycle.