FileDNA for Self-Hosted SOC Platforms: Integration with Sekoia and Its Peers

FileDNA can bring local content enforcement and auditable file-processing evidence to self-hosted SOC platforms. Sekoia Self-Hosted is one of several potential integrations. Sekoia launched it on 27 October 2026 for government, defense, critical infrastructure and regulated organizations. We have not contacted Sekoia yet. This article explains why the fit looks promising.

Our role is clear. FileDNA analyzes, disarms and reconstructs files at an enforced entry point. The SOC platform correlates our evidence with endpoint, identity, email and network activity. It then coordinates investigation and response.

We design the integration once and adapt it per platform. Splunk Enterprise, Elastic Security, IBM QRadar, Wazuh, Graylog and LogRhythm all expose an event intake, a parsing layer and an automation layer. FileDNA needs one event design and a thin adapter for each.

We are starting narrow. One controlled file-entry workflow. One working telemetry integration. One joint proof of concept with measured results. Which platform comes first, time will tell.

This article describes a proposed integration. It is not a shipping or certified capability today.

Why we focus on self-hosted SOC platforms

Many of the organizations we serve cannot send security data to a public cloud. Sekoia names the reasons directly: sovereignty, classification, and regulations such as NIS2 and DORA (Sekoia Self-Hosted).

Three constraints drive this market. Security data must stay on infrastructure the customer controls. Restricted, isolated or air-gapped networks cannot depend on cloud services. Defense, government and critical-infrastructure operators want to own deployment, access and update timing.

These networks still receive outside files. Contractors deliver documents. Suppliers send drawings and firmware. Staff carry files across network boundaries on approved media. Every one of those files is a possible entry point.

That is where FileDNA works. A self-hosted SOC sees what happens after a file arrives. FileDNA decides what file content is allowed to arrive. Together we cover prevention and detection inside the same perimeter.

What Sekoia Self-Hosted offers to customers

Sekoia Self-Hosted runs the Sekoia SOC platform in customer infrastructure: private cloud, on-premises, restricted or air-gapped (product page). Sekoia announced it on 27 October 2026 (press release).

The marketing scope is broad. It covers detection, investigation, threat intelligence, response, automation and agentic workflows. The press release adds a caveat: final capabilities depend on the validated release scope and customer conditions.

We built our plan on the release documentation, which is narrower. The GA release is v1.0.1 (docs PR #3343). Its release notes list Defend and Reveal as available. Elevate (AI agents) and Intelligence (CTI) are not available yet (docs PR #3350). Earlier review notes state that 1.0.0 has no AI features (docs PR #3334).

This would shape our plan in two ways. We will build on Defend: intake, detection, investigation and playbooks. We will hold any AI-agent story until a self-hosted release ships Elevate.

Where else FileDNA fits

Sekoia is not the only SOC platform that runs inside the customer perimeter. Every platform below shares three integration surfaces: an event intake, a parsing or schema layer, and an automation layer. We target all three with one event design.

Three facts will shape our design. Every platform accepts structured JSON over HTTPS or through an agent, so one FileDNA event schema could feed all of them. Every platform has its own field model: Sekoia and Elastic use ECS, Splunk uses sourcetypes, QRadar uses QIDs and Wazuh uses decoders. We will publish ECS-aligned fields and ship thin mappings for the rest. Automation differs the most. Sekoia and Splunk SOAR take Python modules, while Wazuh runs local scripts, so we will need one response adapter per platform.

This list is not exhaustive. Inclusion does not imply a partnership, certification or existing FileDNA integration.

How FileDNA and the SOC divide the work

FileDNA acts on the file. The SOC acts on the organization. That split holds for Sekoia and for every platform above.

FileDNA is a Content Analysis, Disarm and Reconstruction (CADR) engine. We position it as a Content Security Layer (CSL). Three of our components matter here. FileDNA Server runs locally as a service. FileDNA Core is our embeddable C/C++ library. FileDNA Connect is our integration layer for security platforms.

Our main value is turning a file-level action into an organization-wide signal. One removed object in one document is a useful fact. The same document type reaching five employees, followed by unusual sign-ins, is an investigation.

Our lead use case: controlled file entry

Restricted networks still need outside files. Sekoia targets the sectors that move them: government, defense and critical infrastructure. We place FileDNA at the approved entry points: upload portals, mail gateways, document exchanges and staging areas for removable media.

Our proposed deployment works in five steps:

1. A file lands in a controlled staging area.
2. FileDNA processes it under the customer’s content policy.
3. The transfer system releases a reconstructed copy only after processing and validation succeed.
4. FileDNA sends a structured processing event to the local SOC instance.
5. The SOC correlates the event and opens an investigation or response workflow when warranted.

The release gate is the control. A report sent to the SOC does not stop anyone from opening the original. Prevention needs the transfer system to hold the file until FileDNA finishes. If FileDNA fails, times out or cannot process a file, that file stays held.

The original is evidence. When retention is required, we route it to restricted evidence storage. Analysts must be able to tell apart three objects: the original, the reconstructed copy and our processing report.

How we may integrate FileDNA with Sekoia

We would integrate in two stages. Stage 1 sends FileDNA telemetry into Sekoia. Stage 2 lets Sekoia playbooks call FileDNA. Stage 1 fits the documented v1.0.1 scope. Stage 2 depends on an open scope question.

Stage 1: FileDNA telemetry into Sekoia

Sekoia documents everything this stage needs. We build a custom format that parses our events into Elastic Common Schema fields (custom format docs). We send events by HTTPS POST to the /jsons endpoint, with the intake key in the X-SEKOIAIO-INTAKE-KEY header (formatting options). Once the format is stable, we can submit it to Sekoia’s public intake-formats repository for homologation (integration guide).

In SaaS, the endpoint is intake.sekoia.io. In a self-hosted instance, the intake host is local. We confirm its exact name per deployment.

Our field mapping. We use ECS fields where they exist. FileDNA-specific facts go under a filedna.* namespace.

We report explicit status values. Our proposed values are sanitized, clean_no_change, blocked, encrypted, unsupported, timeout and failed. Only the first two map to event.outcome: success. An encrypted, unsupported, timed-out or failed file never looks sanitized.

We separate meaning from severity. A macro removed under policy is a routine enforcement record. A confirmed malicious finding is an alert. A processing failure at a gate is a control gap. Each gets its own detection rule and urgency.

An illustrative FileDNA event, before parsing:

{
  "timestamp": "2026-10-27T14:05:12Z",
  "processing_id": "fdna-7f3c21",
  "source_system": "transfer-gw-02",
  "recipient": "j.martin",
  "file": {"name": "supplier_spec.docx", "size": 482113, "declared_type": "docx"},
  "detected_format": "docm",
  "original_sha256": "<64-hex>",
  "reconstructed_sha256": "<64-hex>",
  "findings": ["vba_macro", "external_template_link"],
  "actions": ["macro_removed", "external_link_removed", "document_rebuilt"],
  "status": "sanitized",
  "validation": "passed",
  "policy_version": "restricted-net-1.4",
  "engine_version": "<version>",
  "evidence_ref": "evidence://vault-01/fdna-7f3c21"
}

The send, using Sekoia’s documented header and endpoint (host and key are placeholders):

curl -X POST \
  -H "X-SEKOIAIO-INTAKE-KEY: <INTAKE_KEY>" \
  -H "Content-Type: application/json" \
  --data @filedna_events.json \
  https://<local-intake-host>/jsons

Stage 2: Sekoia playbooks calling FileDNA

We propose four playbook actions. Request analysis of a held file. Retrieve a processing report by processing ID. Reprocess a quarantined file under a stricter policy. Release an approved reconstructed copy.

Retrieval and release need connectors and permissions in the source system. FileDNA cannot release what the transfer system does not let it touch.

Sekoia actions are Python classes built on the sekoia-automation SDK. An action implements run(arguments) and returns a JSON-serializable dict. Our sketch, with a placeholder FileDNA endpoint:

import requests
from sekoia_automation.action import Action

class GetFileDNAReport(Action):
    """Illustrative only. The FileDNA path below is a placeholder."""

    def run(self, arguments):
        cfg = self.module.configuration
        resp = requests.get(
            f"{cfg['filedna_url']}/<report-endpoint>/{arguments['processing_id']}",
            headers={"Authorization": f"Bearer {cfg['api_token']}"},
            timeout=30,
        )
        resp.raise_for_status()
        return resp.json()

Two constraints apply. First, the v1.0.1 release notes list Custom Apps as not available (PR #3350). A private FileDNA module may therefore need a later release or a Sekoia-homologated module. Sekoia’s generic HTTP action may bridge the gap; we will confirm its availability in self-hosted. Second, Sekoia’s playbook runner executes actions on-premises but not triggers (playbooks on-premises). That page describes SaaS with a local relay. We do not treat it as proof of how the full self-hosted platform behaves.

Reusing our design on other platforms

Our event schema, release-gate design and status model carry over. Only the adapter changes.

Wazuh deserves a note. Its documentation already shows file integrity monitoring triggering a YARA scan through active response (Wazuh FIM + YARA). FileDNA can follow the same pattern for file processing.

Our build order is still open. Sekoia may come first because of its sector focus and timing. Splunk and Elastic could follow because of their installed base. Wazuh could be our low-cost proof point for the open-source and MSSP market.

What the partnership offers

For Sekoia customers, FileDNA adds a preventive control and richer content evidence inside existing SOC workflows. For us, Sekoia opens SOC-led deployments, MSSPs and customers already investing in controlled infrastructure.

The target scale shapes the deal. Sekoia reserves Self-Hosted for at least 5,000 assets or 500 GB/day of ingestion, with a dedicated operations team or MSSP (Sekoia blog). We read this as an enterprise and MSSP opportunity, not a small standalone sale. The cost model also differs: Sekoia describes self-hosted as capital expenditure and SaaS as operating expenditure.

The same models apply to the other platforms. Our integration model is identical. Partner programs, certification steps and marketplaces differ by vendor.

What we will validate

A first technical meeting with Sekoia would need to answer five questions.

A joint proof of concept then measures six things.

What we do not claim. We do not claim an existing Sekoia integration. We do not claim certification with any platform listed. We do not claim AI-agent protection. File reconstruction alone does not stop semantic prompt injection, and the documented self-hosted release excludes AI features. We will evaluate AI-agent use cases separately, later.

Our next steps

A self-hosted SOC watches what happens inside a restricted network. FileDNA controls which file content gets in. Together we give customers one auditable chain: file received, file processed, copy released, activity correlated.

We may start with Sekoia. We could build one controlled file-entry workflow. We could ship the telemetry intake and parser. We would then prove the release gate, the failure behavior and the traceability in a proof of concept. After that, we could reuse the same schema for Splunk, Elastic, QRadar, Wazuh, Graylog and LogRhythm.

References

Sekoia

1. Sekoia Self-Hosted product page
2. Sekoia Self-Hosted press release, 27 Oct 2026
3. The best of cloud, built safely inside your own perimeter (Sekoia blog, 23 Jul 2026)
4. Self-hosted v1.0.1 release notes scope, PR #3350
5. Self-hosted v1.0.1 GA documentation, PR #3343
6. Self-hosted 1.0.0 gap analysis, PR #3334
7. Forward logs using HTTPS
8. HTTPS formatting options
9. Custom format
10. How to develop a new integration
11. sekoia-automation SDK
12. Playbooks on-premises

Comparable platforms

13. Splunk HTTP Event Collector
14. Splunk SOAR (On-premises) connector development
15. Elastic Custom HTTP Endpoint Logs
16. Elastic prebuilt rules in air-gapped environments
17. IBM QRadar custom log source types
18. QRadar SOAR on-premises status (D3 Security)
19. Wazuh capabilities
20. Wazuh FIM and YARA active response
21. Graylog GELF inputs
22. Graylog feature list
23. What’s new in LogRhythm SIEM, October 2026