Why an open source threat intelligence platform for energy and utilities is different
An energy or utility security lead has to track threats to operational technology and grid systems while meeting NERC CIP and NIS2 obligations. The platform that answers that need is usually MISP or OpenCTI as the core store, with network sensors and the SIEM as consumers of its indicators, not as the place where intelligence lives. The distinction matters because the indicators that protect a grid are also the ones most likely to reveal it, so every indicator needs a classification and a sharing rule before it leaves the platform.
Classification comes first. Indicators drawn from an incident at a control center, a substation or a vendor remote access path can describe your own assets, topology or access patterns. Before any sharing, define which fields are stripped, which distribution level applies and which sharing group is allowed to receive the event. MISP supports distribution levels and sharing groups down to individual attributes, which lets you keep operational detail inside the utility while exporting only generic network indicators. Confirm with your compliance team how that policy maps to the information protection controls in CIP-011-3 and to any sector arrangements you join under NIS2 Article 29.
Placement is the second constraint. OT networks are segmented by design, and CIP-005-7 requires routable-connected high and medium impact assets to sit inside an Electronic Security Perimeter. The platform itself should sit in the corporate or IT zone, with a one-way or tightly controlled path that pushes exported rules into the sensors on the OT side. Short answer: choose MISP when the priority is sharing with sector communities and exporting to Suricata, Snort, Zeek and RPZ formats; choose OpenCTI when the priority is structured analysis of campaigns and ATT&CK-mapped relationships. Confirm the sensor and SIEM integration path in your own environment before you decide.
Which energy and utility requirements shape the threat intelligence build
This table maps each NERC CIP and NIS2 requirement that touches a threat intelligence build to where the platform sits, which indicators may leave the enclave, and what evidence to keep. Read each row as a design constraint to settle before the first feed is connected. The main takeaway is that the platform itself may fall inside the CIP scope it is meant to support, so its placement and data flows need to be decided with compliance staff, not after deployment.
| Requirement | What it means for the platform | Indicators that may leave the enclave | Evidence to keep |
|---|---|---|---|
| CIP-002-5.1a impact classification | Impact rating of BES Cyber Systems sets which networks the platform may watch and whether it can sit near them. Confirm the rating with the entity's CIP lead before placing any sensor. | Only indicators with no reference to asset names, IP ranges or topology of high or medium impact systems | Written impact categorization of each BES Cyber System and the bright-line reasoning behind it |
| CIP-005-7 Electronic Security Perimeter and Intermediate System | MISP or OpenCTI and their connectors should sit outside the ESP unless the entity assesses them as in scope. Remote access to the platform must pass through an Intermediate System with encryption and multi-factor authentication. | Feed-derived signatures pushed in one direction through an approved boundary, with no inbound sessions to ESP assets | ESP diagrams, access paths to the platform, and MFA logs for remote sessions |
| CIP-013-2 vendor incident notification and vulnerability disclosure | Vendor notices and advisories about OT products should be ingested as tracked intelligence with owners, and the platform needs a route to the supply chain plan review cycle, which runs at least every 15 calendar months. | Vendor advisory IDs and affected product names; avoid sharing internal asset inventories | Vendor notification records, advisory triage tickets, and supply chain plan review dates |
| CIP-011-3 information protection | BES Cyber System Information held in intelligence records must be identified and protected, so events describing grid assets need a handling rule before they are stored or synchronized. | Strip BES Cyber System Information from any shared indicator; share only generic malware or infrastructure markers | Information protection program, classification tags applied to events, and access reviews for the platform |
| CIP-015-1 internal network security monitoring (enforceable from 1 October 2028) | Once enforceable, internal network monitoring of ESP traffic will need sensors inside the perimeter, which means indicators pushed to Suricata or Zeek must be sized for OT protocol traffic. Plan sensor placement and retention now. | Detection rules exported to in-enclave sensors only; sensor telemetry should not leave the enclave by default | Sensor placement records, rule change history, and alert review logs |
| NIS2 Annex I energy scope and Article 29 sharing | Electricity, district heating and cooling, oil, gas and hydrogen operators are listed as high criticality, so their platform design must support voluntary sharing arrangements. Confirm national transposition and the sharing body before connecting. | Anonymized indicators under agreed TLP and sharing group rules, with no personal data | Membership or agreement with the sharing arrangement, TLP labelling rules, and sharing decision logs |
| Delegated Regulation (EU) 2024/1366 cross-border electricity flows | Operators with cross-border electricity exposure should check whether the network code adds sector cybersecurity duties that affect how intelligence is exchanged with neighboring operators. | Only indicators agreed in the cross-border cooperation framework; confirm recipients per exchange | Cross-border contact lists, agreed exchange scope, and records of what was shared with each party |
What data and systems a utility threat intelligence platform touches
A utility threat intelligence platform handles three data classes that need different handling rules, and the first decision is which class each record belongs to before it leaves the organization. The first class is conventional indicators of compromise: IP addresses, domains, file hashes and email artifacts. These are the material most sharing communities expect and can usually be distributed with a standard distribution level in MISP once reviewed. The second class is OT-specific intelligence: observed vendor remote access paths, malware seen on engineering workstations, and unusual traffic patterns against control protocols. This material describes how your control environment is reached and is often more sensitive than a hash. The third class is internal incident context, including affected site names, operator notes, outage timelines and analyst conclusions about your own architecture. This class should stay inside the platform and be shared only in sanitized form. Confirm with your compliance lead which of these classes your organization treats as BES Cyber System Information before the first import.
The systems in scope extend beyond the threat intelligence server itself. Control centers and substations generate the telemetry that feeds detection, but the platform should only receive derived indicators, not raw control traffic. Historians hold process data that can reveal operating conditions and should be kept out of the intelligence data model. Vendor remote access gateways are both a source of indicators and a high-value target, so the connection paths documented in the platform must match what the access team actually runs. The corporate SIEM is the usual consumer of indicators, and the push path from MISP into it is where most exposure decisions are made. Under CIP-011-3, the information protection standard, BES Cyber System Information must be identified and protected, including when it is stored, transmitted or disposed of. Ask your NERC CIP program owner to classify each data field and each integration before any indicator crosses into the platform or out to a community. A short written data map showing source, classification, storage location and recipient is the most useful artifact to prepare first.
Which open source platforms fit energy and utility threat intelligence
Energy and utility teams usually combine a sharing hub, an analyst modeling layer and sensors that watch control system traffic. The cards below cover each component, the decisions it forces and the checks to run before it touches a grid or OT environment.
MISP as the sharing hub
MISP is the most common starting point for a sector sharing arrangement because it handles distribution levels and sharing groups down to individual attributes. Operators can limit a sensitive indicator about a substation to a named group of peers and withhold it from everyone else. Before go-live, confirm which sharing communities your sector body runs, which version your partners use, and how attributes are tagged with TLP markings. The MISP project lists version 2.5.50, published 10 October 2026, as the current release line to plan against.
Correlation with CIDR overlap
MISP's correlation engine matches indicators through exact values and advanced patterns, including CIDR overlaps and fuzzy hashes. For utilities this matters when a published malicious range overlaps an address block used by a remote terminal unit vendor or a field gateway. Teams should decide which correlations raise alerts and which only enrich an event, because broad range matches can flood analysts during a sector campaign. Test correlation settings against a sample of your own asset inventory before enabling them.
Exports to Suricata, Zeek and RPZ
MISP can export indicators as Suricata and Zeek rules and as RPZ zones, which is how intelligence reaches the sensors that watch control system traffic. Export is only useful if the sensor team reviews each rule before deployment, since a poorly scoped rule can block legitimate protocol traffic such as polling from a historian. Confirm which feeds go to passive monitoring sensors and which, if any, reach blocking devices in the OT zone. Those decisions belong in the change control process, not in an automatic sync.
OpenCTI for adversary campaign modeling
OpenCTI Community Edition, licensed under Apache License 2.0, stores intelligence in a knowledge schema based on STIX2 and exposes it through a web application and GraphQL API. Analysts use it to model intrusion sets and campaigns against ICS techniques, which helps a grid operator explain why a threat group matters to its substations and control centers. Its MITRE ATT&CK connector maps behavior to techniques. Confirm the dependencies early: Elasticsearch 8.0 or OpenSearch 2.9 or later, Redis 7.1 or later, RabbitMQ 3.11 or later and S3-compatible storage.
OpenCTI LTS and Enterprise limits
OpenCTI release numbers follow a date-based scheme, and LTS releases require a specific LTS license key even though they ship as container images. LTS builds receive only critical bug and security fixes after a one-month stabilization period, which affects how fast an OT-adjacent team can take changes. Features the operator expects, such as certain connectors or administration functions, may sit in the proprietary Enterprise Edition. Ask the vendor and your partner to list which required features are in the Community Edition before you commit to a design.
Suricata and Zeek as indicator sensors
Suricata and Zeek are the sensors that consume indicators and turn them into detections on control system network traffic. Suricata is an intrusion detection and prevention engine under GPL-2.0, and Zeek is a network analysis framework that records protocol metadata useful for investigating OT events. Passive placement at SPAN or TAP points avoids adding latency to protocol-sensitive traffic. Confirm which industrial protocols each sensor parses in your environment, since protocol coverage varies and determines which indicators can actually match.
Wazuh and Security Onion as the monitoring layer
Wazuh and Security Onion provide the monitoring layer where sensor alerts, host telemetry and MISP-derived context meet analyst workflows. Wazuh is an open source XDR and SIEM platform under GPL version 2, while Security Onion bundles Suricata, Zeek, osquery and the Elastic stack under the Elastic License 2.0. Choose based on whether your team needs a broader endpoint and log focus or a network-centric hunting console. Check that the platform can ingest from OT-zone collectors without crossing the security perimeter defined for your high and medium impact assets.
How deployment constraints change placement in OT environments
The MISP or OpenCTI platform usually belongs in the corporate IT network or a segment of it, because it needs database, cache and message services, outbound access to chosen feeds and sharing partners, and analyst workstations. Keeping it here lets the security team manage curation, sharing groups and enrichment without touching control system segments. It also means the platform inherits the IT network's patching, logging and identity controls, which the team must confirm are documented before go-live.
- Platform placement: Host the MISP instance or the OpenCTI platform, workers and dependencies in a dedicated security segment of the IT network.
- Outbound paths: Allow feed and sharing synchronization only to named endpoints, and record every outbound connection.
- Access: Connect analysts through the organization's identity provider so that curation actions are attributable.
- Data handling: Decide which indicators may leave the organization, since MISP sharing groups and distribution levels control what partners see.
- Sizing and backup: Plan storage and backup for the database and search indexes that hold indicator history.
Confirm with your security architecture team which IT network segment is approved for threat intelligence servers and whether your grid operator's rules restrict where indicator data may be stored.
The DMZ is the controlled boundary where intelligence can cross from the IT side toward OT monitoring without giving OT systems direct access to the internet or to the platform's database. A common pattern places a distribution point or export service in the DMZ that serves finished rule sets to OT-side sensors, while the platform itself stays in the IT network. Traffic rules at this boundary should permit only the specific pull or push flows the design requires.
- Rule staging: Publish exported Suricata and Zeek rule sets from MISP to a staging location in the DMZ rather than sending live indicator data across the boundary.
- One-way or tightly scoped flows: Permit only the protocols and source addresses needed for rule delivery, and deny the reverse path into IT.
- Integrity checks: Verify rule files with checksums or signatures before OT sensors load them.
- Logging: Log every transfer across the DMZ for later review under the operator's monitoring program.
- Failure handling: Define what the sensors keep running on if the DMZ service is unavailable.
Confirm with the OT security team which boundary devices, protocols and logging controls are approved, and whether the design matches the zone and conduit model in your architecture documentation.
Control networks run energy management, substation and generation systems, where availability and safe operation take precedence over routine software change. Threat intelligence platforms should not run here, and OT sensors should not query external feeds or sharing services. Instead, sensors receive reviewed rules and indicators pushed through the DMZ, and every rule that reaches the control side passes through the operator's change control process. Requirements under the NERC CIP standards and the network security monitoring controls that the operator adopts will shape which sensors may be placed and how they report.
- No direct feeds: Keep sensors free of internet-facing feed connections and enrichment calls.
- Change control: Route each new or modified rule through the operator's review, testing and approval steps before deployment.
- Rule scope: Limit rules to indicators that apply to the protocols and assets actually present, to reduce false positives on control traffic.
- Timing: Agree a rule update cadence with operations staff, so that deployments do not coincide with maintenance windows or grid events.
- Air-gapped sites: Where a control center is isolated, move MISP taxonomies and galaxies, which carry separate CC0 or BSD licenses from the AGPL software, and feed updates by controlled transfer, then document each transfer.
Confirm with the operator's compliance and operations leads which change control steps apply to sensor rule updates and how the air-gapped transfer procedure is approved.
How a utility rolls out threat intelligence in phases
This sequence moves a utility from impact classification to a MISP or OpenCTI platform that feeds indicators into OT-facing sensors under change control, with each phase producing a verifiable output before the next begins.
Scope impact classification and asset inventory
The compliance lead and OT engineers confirm which systems fall under the CIP-002 impact classification, separating high, medium and low impact BES Cyber Systems, and build an inventory of the control centers, substations, plants and routable connections that the intelligence program will protect. The output is a signed scope document that states which environments may receive indicators, which may only send data outward, and which are out of bounds. The step is done when the operations and security leads agree the inventory matches the classification record.
Define OT intelligence requirements
The security team works with control system engineers, operations managers and the incident response lead to write intelligence requirements that name the consumers and the decisions each feed supports, such as detecting ransomware touching engineering workstations, spotting known malicious tooling used against industrial protocols, or tracking vendor remote access campaigns. Requirements are mapped to CIP-013 vendor risk concerns where relevant. The output is a short requirements register that tells curators which feeds, sources and object types matter, and it is complete when each requirement has a named owner.
Stand up the platform in IT or DMZ
Platform engineers deploy MISP or OpenCTI in the corporate IT zone or a DMZ segment, never on the OT network itself, with access controls, logging and backups defined before data enters. For OpenCTI, the dependencies (Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage) are sized against the documented minimums and the expected connector load. The output is a hardened instance with tested backup and restore, and the step closes when a restore has been demonstrated in a non-production copy.
Configure sharing groups and join the sector community
The threat intelligence lead sets distribution levels and sharing groups so that operational data about the utility stays within agreed boundaries, then connects to the sector sharing arrangement that the utility's national framework supports under NIS2 Article 29. Membership terms, TLP handling and the rules for what leaves the organization are written down and approved by legal and the sharing community's governance. The output is a configured sharing profile and a documented onboarding record, and the step is done when a test event is exchanged with the community under the agreed rules.
Build export pipelines to OT sensors under change control
Network engineers and the security team design the path that turns curated indicators into formats that OT-facing sensors consume, such as Suricata or Zeek rules and RPZ or list-based blocks, and route them through a one-way or tightly controlled transfer into the monitoring zone. Every pipeline change goes through the utility's change advisory process, with a rollback plan and a record of which sensors receive which rule sets. The output is a documented pipeline with approved change tickets, and the step is complete when the sensor team confirms the rule sets load without disrupting monitoring.
Validate with test indicators
Before live indicators reach any sensor, the team publishes known test indicators that are safe to trigger alerts, confirms that the exports parse correctly, and checks that detections fire at the expected sensors and that alerts reach the right queue. Operations staff verify that no test rule interrupts legitimate control traffic, and the findings are logged against each requirement. The output is a validation record listing each test, its result and any corrective change, and the step closes only when the operations lead signs off on the results.
Operate with curation and periodic review
Analysts curate incoming indicators, age out stale or low-confidence entries so that sensors do not accumulate false positives, and review the sharing configuration and pipelines on a schedule the utility sets in its governance documents. Each change to sensor rules passes through change control, and the team records which indicators were acted on and why. The output is an ongoing curation log and a periodic review report that feeds the requirements register, and the step is sustained rather than finished, with the review cadence confirmed with the compliance function.
Evidence energy auditors and regulators ask for from threat intelligence
This table maps each evidence type to the MISP, OpenCTI, sensor or ticketing component that produces it and to the CIP or NIS2 requirement it supports. Read it as a checklist for what the deployment must retain, since NERC auditors and certification bodies, not DeployOpen, assess whether that evidence is sufficient. There is no CIP certificate, so the goal is to answer audit questions with records you can produce on request.
| Evidence | Where it is produced | Requirement it supports |
|---|---|---|
| Sharing group and distribution configuration | MISP sharing groups, distribution levels and sync settings, exported as configuration snapshots | Control of what OT indicators leave the entity, reviewed alongside the NIS2 Article 29 sharing arrangement |
| Indicator ingestion logs | MISP feed and sync logs, plus OpenCTI connector and worker logs for imports | Shows which feeds and communities supplied indicators, when, and under which sharing terms |
| Export records of rules pushed to Suricata or Zeek | Export history for Suricata, Zeek and other formats from MISP, with rule versions stored with timestamps | Traceability from shared indicator to the sensor rule that watches control system traffic |
| Change tickets for OT-side rule deployment | Ticketing system linked to each sensor rule release, with approver and rollback plan recorded | Change management evidence for monitoring that touches systems in scope of CIP-005-7 and CIP-013-2 controls |
| CIP-013-2 vendor notification records | Intake log of vendor incident and vulnerability notices, routed into MISP events with source and handling notes | Vendor incident notification and vulnerability disclosure items in the supply chain risk management plan |
| Supply chain plan review record | Dated review entries showing the plan was reviewed within the 15 calendar month cycle | CIP-013-2 requirement that the plan is reviewed at least every 15 calendar months |
| Access logs for the threat intelligence platform | Authentication and audit logs from MISP and OpenCTI, plus identity provider records for each analyst account | Confirms who viewed or changed shared intelligence and whether access used multi-factor authentication where required |
| Retention and integrity controls | Backup records, log retention settings and export hashes stored outside the platform | Shows intelligence and logs are retained for the period your compliance program sets and cannot be silently altered |
What utilities ask before deploying threat intelligence
What drives the total cost of a self-hosted OpenCTI or MISP platform for a utility?
MISP is free to download under AGPL-3.0, and OpenCTI has a free Community Edition under Apache-2.0, so the cost sits in the work around the software. The main components are the infrastructure for OpenCTI's dependencies (Elasticsearch or OpenSearch, Redis, RabbitMQ and S3-compatible storage), connector and integration work into your SIEM and sensors, paid feeds, analyst time to curate indicators, and any OpenCTI Enterprise subscription if you need features outside the Community Edition. Infrastructure and curation recur every year, while integration is mostly one-time. Ask any quote to split these lines, name who is paid for each, and state which OpenCTI features require the Enterprise Edition. Documented sizing is available in the OpenCTI deployment overview.
How much time does a deployment take, and how much does the OT team need to be involved?
The timeline depends on how many feeds, sharing relationships and sensor integrations are in scope, and no fixed duration applies to every utility. Your OT team matters most in three places: defining which indicators are relevant to control system traffic, confirming that any rule pushed to network sensors will not disrupt operations, and approving change windows on segments that feed BES Cyber Systems. Plan for OT review of every automated export before it reaches sensors that watch control network traffic, and agree in writing who approves changes. A fixed-scope proposal should show these reviews as separate deliverables with their own sign-off.
Can our own staff operate the platform after go-live?
Yes, many utilities run MISP or OpenCTI with internal staff once the platform is handed over, but this depends on whether you have people who can maintain the database, message queue, search cluster and connectors. Operation includes applying updates, which for OpenCTI includes LTS license handling, and keeping connectors working after upgrades. Ask your partner what the handover includes: runbooks, admin training, backup and restore tests, and a documented upgrade path. Ongoing support, upgrades and continuous testing are available as retainers, so you can choose between internal operation and a support arrangement without changing the platform.
How do NERC CIP audits relate to a threat intelligence platform?
A threat intelligence platform does not produce a CIP certificate, because there is no such thing, and it does not make a utility compliant on its own. NERC CIP standards are mandatory in the United States once FERC approves them, and NERC and the Regional Entities monitor compliance. Relevant standards include CIP-005-7 on Electronic Security Perimeters, CIP-013-2 on supply chain risk management, and CIP-015-1 on internal network security monitoring, which is enforceable from 1 October 2028. Entities registered as a Balancing Authority, Reliability Coordinator or Transmission Operator receive an audit at least once every three years. The platform can supply records of how indicators were received, reviewed and applied, which your auditors may ask to see. DeployOpen prepares systems and evidence for assessments but does not issue audit results.
What is the maximum penalty for NERC CIP violations?
The maximum civil penalty is $1,584,648 per violation per day, as stated in the eCFR provision for civil penalties. FERC Order No. 919 states that about 1,673 unique US entities were identified in the NERC Compliance Registry as of June 2025 as subject to mandatory CIP compliance. The penalty figure applies to violations generally, so the practical risk depends on the nature and duration of any violation and how it is handled. Use this figure to frame the cost of getting controls wrong, not as a prediction of what any one utility would pay.
Does sharing indicators under NIS2 require notifying authorities?
NIS2 Article 29 sets up voluntary cybersecurity information-sharing arrangements, and the Directive itself does not require every shared indicator to be reported to a regulator. Energy is a high-criticality sector under Annex I, covering electricity, district heating and cooling, oil, gas and hydrogen. Membership and any notification duties depend on how your Member State has transposed the Directive, so confirm the requirement with your national competent authority or CSIRT before you join a community. Also confirm how shared indicators are classified, since sharing groups and distribution levels determine who sees each record. Your legal team should check the final arrangement against the NIS2 text on EUR-Lex.
Which parts of the work are fixed scope and which are ongoing?
Most DeployOpen engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Typical fixed items are platform installation, dependency setup, feed and connector configuration, sensor export integration and documentation. Ongoing items, such as upgrades, monitoring of connectors, and continuous testing, are available as retainers. Ask for the written scope to list each deliverable, the OT review gates, the handover materials and any out-of-scope items, such as new feed subscriptions or changes to sensor policies. Quotes follow from this written scope and DeployOpen does not publish a price list.
Does DeployOpen test whether indicators push to sensors safely?
DeployOpen runs security testing, including application, infrastructure and AI testing, but ask specifically whether the engagement includes validation of exported detection rules against OT traffic before they reach production sensors. Your engineers should confirm which sensors receive rules, how rules are tested in a non-production segment, and how a rule can be rolled back. Request a test plan that names the sensors, the rule formats (such as Suricata or Zeek) and the acceptance criteria, and confirm that any change to control network monitoring has been reviewed by the OT team.
Questions to ask an implementation partner for OT threat intelligence
Start with where the platform sits relative to the control network. Ask the partner to show, in writing, which segment hosts the MISP or OpenCTI instance, how it receives indicators from outside the OT zone, and how that path crosses the Electronic Security Perimeter that CIP-005-7 requires for high and medium impact BES Cyber Systems. A partner who proposes placing the threat intelligence server inside the perimeter, or who cannot name the boundary controls on each data path, has not yet mapped the compliance impact. Ask who signs off on that diagram and who at your utility approves changes to it.
Next, ask how indicators are classified before sharing. Indicators derived from your own BES Cyber System Information can reveal system design, so ask the partner to set distribution levels and sharing groups in MISP so that such attributes never leave the community you choose. Ask which sensors receive which exports (Suricata, Zeek, or RPZ) and how each export is generated, since a Suricata rule set pushed to a network sensor is itself a control change. Require that every OT sensor rule change goes through your change control record, with a named approver and a rollback step, and ask the partner to confirm how the change tickets link to the MISP events they came from.
Finally, ask how false positives are aged out and who maintains the connectors. For OpenCTI, confirm with the partner which features and connectors the Community Edition supports and which need the Enterprise Edition, and get that list in the statement of work. Ask who holds the LTS license key if you choose an LTS line, who renews it, and who applies critical fixes within the one-month stabilization window described in the product life cycle. Agree on the owner of each connector and on a review interval for expired indicators, and write both into the operating procedures.
How DeployOpen scopes and supports energy threat intelligence
This sequence turns an energy or utility team's sharing and OT monitoring goals into a written scope, a self-hosted MISP or OpenCTI deployment inside the client's own environment, and evidence that assessors can review. Each step ends with a named output the client can check before the next one starts.
Define intelligence requirements and consumers
DeployOpen meets the operator's security, OT engineering and compliance leads to list who will consume threat intelligence, which systems they protect and which threats matter most, including BES Cyber System impact levels where the organization is in scope of NERC CIP. The output is a short requirements register that names each consumer, the decision each feed supports and the systems that will receive indicators. The step closes when the client signs off the register.
Agree the written scope and boundaries
Before any work starts, DeployOpen and the client agree a written scope covering the platform choice between MISP and OpenCTI, the hosting location, the sharing communities in scope, integrations, deliverables and timelines. Operators should confirm in this step whether the platform sits inside an Electronic Security Perimeter or in the corporate IT zone, because that decision changes the network path for every indicator. The step closes with a signed statement of work.
Map sharing arrangements and data handling rules
The team reviews which sector sharing arrangements the organization may join under NIS2 Article 29 and the national transposition in its member state, along with any contractual limits on what may leave the operator's environment. DeployOpen documents distribution levels, sharing groups, TLP rules and the handling of data that could reveal site or grid topology. The output is a sharing policy that the client's legal and security owners approve before any community synchronization is enabled.
Build the self-hosted platform in the client's infrastructure
DeployOpen installs the chosen platform in the client's own cloud account, data center or isolated network, with dependencies such as the database, cache and storage configured to the documented requirements of that platform. Where OpenCTI is chosen, this includes the search, queue and object storage components. The output is a running instance with a documented build record, administrator accounts held by the client, and backup and restore tested once.
Connect feeds, connectors and detection sensors
DeployOpen configures the feeds, taxonomies and connectors the requirements call for, then exports indicators in formats such as Suricata and Zeek rules to the network sensors that watch control system traffic. Each export is tested in a non-production sensor first, and any rule that could block operational traffic is held for engineering review. The output is a tested indicator flow with a documented owner for each feed and sensor.
Harden access and record the evidence
DeployOpen applies role-based access, identity integration with the client's directory, audit logging of administrative and sharing actions, and change control for the platform. The team also builds the evidence set that assessors commonly ask for, such as configuration baselines, access reviews and sharing records, mapped to the client's own control requirements. DeployOpen prepares this evidence but does not issue audit reports, attestations or certifications. The output is an evidence pack that the client's compliance lead accepts.
Hand over and agree ongoing support
DeployOpen runs a handover with the operators who will curate indicators, maintain connectors and respond to false positives, and documents the runbooks for routine tasks and upgrades. The client then decides whether to keep operations in-house or to add an optional support retainer for upgrades, continuous testing and connector maintenance, with its scope written separately. The step closes when the runbooks are accepted and the support decision is recorded.
