Real-Time Cyber Threat Intelligence Sharing Without Blockchain Bottlenecks

Why DDS might be the missing middleware for scalable, secure, and actionable CTI

Cyberattacks no longer unfold over days or even hours — they propagate in seconds. Yet, much of today’s Cyber Threat Intelligence (CTI) sharing infrastructure still relies on centralized servers or blockchain-based platforms that struggle with latency, scalability, and operational overhead.

In our recent work, *An Efficient Framework for Automated Cyber Threat Intelligence Sharing*, we revisit a fundamental question:

What if CTI sharing were treated as a real-time distributed systems problem instead of a ledger or web-API problem?

The result is a DDS-based CTI sharing framework that delivers sub-millisecond latency, linear throughput scaling, 100% delivery success, and strong security guarantees—without the drawbacks of centralized hubs or blockchain consensus

The Core Problem with Existing CTI Sharing Platforms

CTI sharing is widely acknowledged as critical for modern cybersecurity operations, yet practical deployment faces persistent challenges:

• Timeliness: Indicators of compromise (IOCs) often lose value within minutes.
• Scalability: Centralized TAXII servers become bottlenecks at scale.
• Reliability: Packet loss or delayed delivery can translate into missed attacks.
• Privacy: Raw security logs often contain sensitive organizational data.
• Automation: Manual STIX creation and triage slow down response cycles.

Blockchain-based CTI platforms promise decentralization, but experimental evaluations consistently show multi-second latency, poor throughput, and high resource overhead, making them unsuitable for real-time defense scenarios

Rethinking CTI Sharing as a Real-Time Data Distribution Problem

Our key insight is simple but powerful:

CTI sharing is fundamentally a publish–subscribe problem with strict real-time and reliability constraints.

To address this, we design a framework built on Data Distribution Service (DDS) — a middleware standard widely used in safety-critical systems such as aerospace, autonomous vehicles, and industrial control.

DDS brings several properties that align naturally with CTI requirements:

• Decentralized, peer-to-peer communication
• Fine-grained Quality of Service (QoS) control
• Built-in reliability and durability
• Low-latency, high-throughput data dissemination
• Native support for secure, policy-driven access control

Yet, prior to our work, DDS had not been applied to CTI sharing.

Architecture Overview: From Raw Alerts to Actionable CTI

Our framework integrates four tightly coupled components:

1. Automated Data Sanitization
2. Automated STIX Generation
3. Secure DDS-Based Dissemination
4. Decentralized, Peer-to-Peer Collaboration

Automated Data Sanitization

Raw alerts from IDS, firewalls, and malware detectors often contain:

• Internal IP addresses
• Email addresses
• Usernames
• Personally identifiable information (PII)

We introduce a multithreaded sanitization pipeline that automatically:

• Extracts threat indicators
• Classifies data as IOC, ambiguous, or sensitive
• Removes or flags sensitive elements
• Preserves privacy without discarding valuable intelligence

This step ensures GDPR-aligned data minimization before sharing.

Automated STIX Generation

Instead of manual STIX authoring, the framework:

• Converts sanitized IOCs directly into STIX 2.x objects
• Produces machine-consumable and human-readable CTI
• Eliminates analyst overhead in CTI formatting

Automation here is essential — CTI delayed is CTI denied.

Secure DDS-Based Dissemination

Once structured, CTI is published to DDS topics using RTI Connext DDS Secure, enabling:

• Mutual authentication via certificates
• Topic-level access control
• Encryption, integrity, and origin authentication
• Reliable and durable delivery (even for late-joining subscribers)

This ensures CTI is delivered when needed, where needed, and only to authorized parties.

Decentralized, Peer-to-Peer Collaboration

There is no central server and no global ledger.

Organizations:

• Publish CTI when detected
• Subscribe to relevant threat topics
• Automatically receive intelligence in real time
• Scale horizontally as new participants join

Experimental Results: Why DDS Changes the Game

We implemented a full prototype and conducted an extensive evaluation. The results are striking:

Latency

• 0.9–1.0 ms average latency, even with full security enabled
• Three orders of magnitude faster than blockchain-based CTI platforms

Throughput

• Linear scaling up to 125 messages/second
• Sustained delivery across payload sizes up to 8 KB

Reliability

• 100% delivery success rate under all tested scenarios
• Reliable and persistent QoS guarantees message delivery

Efficiency

• < 8% CPU usage
• < 100 MB memory footprint
• Suitable for edge and resource-constrained deployments

Compared to blockchain and TAXII-based solutions, the DDS-based approach consistently outperforms in latency, throughput, success rate, and resource efficiency.

Why This Matters for Researchers and Practitioners

This work opens several new directions:

• CTI sharing without blockchain trade-offs
• Real-time threat dissemination at operational scale
• Reusable DDS QoS configurations for cybersecurity
• Bridging distributed systems and cyber defense research

For researchers, the framework provides:

• A validated alternative to blockchain CTI architectures
• Experimental benchmarks for real-time CTI dissemination
• A foundation for integrating ML-based threat analysis pipelines

For practitioners, it demonstrates:

• How to deploy CTI sharing with predictable latency
• How to preserve privacy without sacrificing automation
• How to build scalable, peer-to-peer cyber defense ecosystems

Citation and Reuse

If you build upon or reference this work, please cite:

Gambo, M. D.; Khan, A. H.; Almulhem, A.; Almadani, B. An Efficient Framework for Automated Cyber Threat Intelligence Sharing. Electronics, 2025, 14, 4045. https://doi.org/10.3390/electronics14204045

Final Thoughts

Cyber Threat Intelligence is only valuable if it arrives before the attack does.

By combining automated sanitization, STIX-compliant structuring, and DDS-based real-time dissemination, this work demonstrates that CTI sharing can finally operate at the speed of modern cyber threats — without centralized bottlenecks or blockchain delays.

If you are working on cybersecurity platforms, distributed systems, real-time middleware, or large-scale threat sharing, this approach is worth exploring — and extending.

How to Reproduce the Experiments: A Practical Guide

One of the key goals of our work is reproducibility. This section outlines how researchers and practitioners can reproduce the functional and performance evaluations reported in our study with minimal setup effort.

The experiments fall into two categories:

1. CTI processing and sanitization validation
2. DDS-based CTI dissemination performance evaluation

All experimental design choices, parameters, and metrics directly mirror those used in our published evaluation.

Hardware and Network Setup

One can reproduce the experiments using commodity hardware.

Minimum recommended setup

• 2 physical or virtual machines
• Quad-core CPU (Intel i5-class or equivalent)
• ≥ 8 GB RAM per machine
• 1 Gbps Ethernet (or virtual bridged network)

Test topology

• One node acts as CTI Provider (Publisher)
• One or more nodes act as CTI Consumers (Subscribers)
• Nodes connected via a switch or virtual network

The framework does not require specialized hardware, GPUs, or trusted execution environments.

Software Environment

The reference implementation uses Python with RTI Connext DDS Secure.

Operating System

• Windows 10/11 (64-bit) or Linux (Ubuntu 20.04+)

Core dependencies

• Python 3.10+
• RTI Connext DDS Secure (v7.x)
• RTI Connext DDS Python Connector
• [stix2](https://pypi.org/project/stix2/) Python library
• [cryptography](https://pypi.org/project/cryptography/) (Fernet)
• Standard Python libraries (logging, threading, regex)

Note: DDS discovery uses multicast by default. For cloud or WAN setups, RTI Cloud Discovery Service or static peer configuration is required.

Dataset Preparation

IOC Dataset

• Use the publicly available Swift Phishing Campaign dataset (GitHub)
• Contains IPs, domains, URLs, and malware hashes

PII Dataset (for sanitization testing)

• Generate synthetic PII using the [faker](https://pypi.org/project/Faker/0.7.4/) library: Internal IP addresses, Internal email domains, Usernames, Phone numbers, Credit card numbers

Combine IOC and PII data into a single input stream to simulate real operational logs.

Reproducing CTI Sanitization and STIX Generation

Steps

1. Feed raw threat data (logs or text files) into the sanitization pipeline
2. Enable multithreaded extraction and classification
3. Verify: PII is removed, Ambiguous data is flagged for review, Valid IOCs are retained
4. Automatically generate STIX 2.x objects using stix2

Expected results

• Near-perfect precision and recall for IOC extraction
• Zero PII leakage
• Structured STIX output ready for machine consumption

These results correspond to the functional evaluation metrics reported in the paper.

Reproducing DDS Performance Experiments

DDS Configuration

• Reliability: RELIABLE
• Durability: PERSISTENT
• History: KEEP_ALL
• Resource Limits: LENGTH_UNLIMITED
• Security: enabled incrementally (Integrity → Confidentiality → Origin Authentication)

Workload parameters

• Message rates: 50, 75, 100, 125 messages/sec
• Message count: 1000 samples per run
• Payload sizes: 32 B → 8192 B
• Subscribers: 1 → 10

Metrics to collect

• End-to-end latency (µs)
• Throughput (msg/s and Mbps)
• Delivery success rate (%)
• CPU and memory utilization

Expected outcome

• Sub-millisecond average latency
• Linear throughput scaling
• 100% message delivery
• Minimal CPU and memory overhead

Extending the Experiments

Researchers can extend reproducibility by:

• Adding more DDS participants using containers
• Bridging domains with RTI Routing Service
• Testing WAN/cloud discovery
• Injecting packet loss or jitter
• Comparing against TAXII or Kafka-based pipelines