Integrations

The Integrations section of the Administration page wires MetaDefender NDR to the external services that extend its detection and response reach beyond the sensor and the Manager's own UI (user interface). This chapter documents the four Minimum Viable Product (MVP) integrations — MetaDefender Core, MetaDefender Cloud, Syslog forwarding to Security Information and Event Management (SIEM) platforms, and threat intelligence — along with the configuration each one needs, the verification steps administrators use to confirm a healthy integration, and the common procedures for rotating credentials and testing connectivity.

This chapter is written for system administrators and Site Reliability Engineers (SREs) who own the Manager's outbound connections to third-party services. It assumes an installed Manager with at least one adopted sensor, an administrator account, and familiarity with the Administration page layout described in the Administration overview and the Manager-global settings documented in Manager Configuration.

First-use acronym expansions in this chapter: MVP (Minimum Viable Product), UI (user interface), SRE (Site Reliability Engineer), SIEM (Security Information and Event Management), API (Application Programming Interface), REST (Representational State Transfer), HTTP (Hypertext Transfer Protocol), HTTPS (Hypertext Transfer Protocol Secure), TLS (Transport Layer Security), UDP (User Datagram Protocol), TCP (Transmission Control Protocol), IP (Internet Protocol), URL (Uniform Resource Locator), TI (threat intelligence), OSINT (open-source intelligence), IOC (indicator of compromise), C2 (command-and-control), CEF (Common Event Format), LEEF (Log Event Extended Format), MIME (Multipurpose Internet Mail Extensions), SHA-256 (Secure Hash Algorithm 256-bit), MD5 (Message Digest 5), AV (antivirus), CDR (Content Disarm and Reconstruction), DLP (Data Loss Prevention), RFC (Request for Comments), CVE (Common Vulnerabilities and Exposures), TTL (time-to-live), DNS (Domain Name System).

Overview of Available Integrations

MetaDefender NDR ships four MVP integrations, each of which addresses a distinct operational need:

MetaDefender Core and MetaDefender Cloud are mutually exclusive per deployment — the MetaDefender NDR enrichment service is configured to talk to one deployment or the other, not both. Syslog forwarding supports multiple concurrent destinations.

Every integration runs on the Manager side. Sensors do not hold integration credentials or open outbound connections to third-party services directly — all outbound traffic to MetaDefender Core, MetaDefender Cloud, or a SIEM originates from the Manager, or from the MetaDefender Core enrichment microservice that runs alongside the Manager.

All four integrations respect tenant isolation: each tenant's integration configuration, credentials, syslog destinations, and per-destination filter rules are scoped to that tenant alone. The enforcement model is documented in Users, Groups, and RBAC.

MetaDefender Core

MetaDefender Core is the on-premises OPSWAT file-analysis product. MetaDefender NDR's MetaDefender Core enrichment submits files carved from network traffic by Suricata's file-store to the MetaDefender Core Application Programming Interface (API), retrieves multi-AV scan results, and attaches the results as enrichments on the corresponding fileinfo event. Enriched file verdicts drive downstream alerting and surface on the Hunt page when analysts pivot from a file event.

Purpose

Every file the enrichment submits is analyzed in parallel by the AV engines licensed on the MetaDefender Core deployment. The resulting verdict (Clean, Infected, Suspicious, and the per-engine signature detail that backs it) is attached to the network event and stored with the flow, session, and file metadata that triggered the extraction.

The enrichment checks the MetaDefender hash cache before submitting any file bytes. Files with a recent cached result — typically the vast majority in a mature deployment — resolve without re-upload, which conserves scanning capacity and API quota. The cache-lookup threshold is tunable (default three days); older cached results trigger a fresh scan.

Although the scan workflow is asynchronous (submit, poll, result), analysts see a single enriched event with the scan verdict inline — the enrichment pipeline handles polling, retries, and timeout bookkeeping behind the scenes.

MVP scope

MVP covers hash lookups, file submission, polling for scan completion, and result enrichment of the triggering fileinfo event. The following MetaDefender Core capabilities are not wired into MetaDefender NDR in MVP and are explicitly targeted for PostMVP: YARA-based pre-screening on the sensor, Content Disarm and Reconstruction (CDR) retrieval of sanitized files, Data Loss Prevention (DLP) scanning, Vulnerability / Common Vulnerabilities and Exposures (CVE) assessment, and a persistent failed-file retry queue with Manager UI backlog exposure.

Configuration

The MetaDefender integration is configured from Administration → Configuration → Integrations → MetaDefender Core. Key parameters:

Credentials reload through the configuration-broadcast channel when rotated — no pod restart is required.

How file events reach the enrichment

Files carved from network traffic by the sensor's Suricata file-store produce a fileinfo event. The enrichment consumes the event, extracts the SHA-256 (or MD5 if SHA-256 is unavailable), filters events that fail the MIME or size checks, and opens the carved file from the sensor's file-store or from object storage. The carved file is never transferred directly from sensor to MetaDefender — it is read by the Manager-side enrichment and submitted over the Manager's outbound connection.

Verification

A healthy MetaDefender Core integration produces three observable signals:

1. Connectivity probe on save. When administrators save the integration form, the Manager runs a connectivity probe against the configured endpoint (/apikey/info for Cloud, /version for Core). The form displays success or a detailed error; the integration is not persisted until the probe succeeds.
2. Enrichment statuses on merged events. The enrichment reports status=enriched on events whose files produce a scan result and status=enabled on events whose files were filtered out (too large, skipped MIME type, hash-lookup-only mode). A timeout status indicates the enrichment did not return a result before the aggregator's time-to-live (TTL) expired and warrants investigation.
3. Scan counters. The enrichment's /api/metrics admin endpoint exposes mdcore.scan.{submitted,completed,failed,timeout} and mdcore.cache.{hit,miss}. Convergence between submitted and completed, absent elevated failed or timeout, indicates a healthy integration.

MetaDefender Cloud

MetaDefender Cloud is the hosted alternative to MetaDefender Core. Configuration and operational behavior are identical to MetaDefender Core with these differences:

• Endpoint. Base URL is https://api.metadefender.com/v4, owned by OPSWAT. Administrators do not override it except for regional endpoints published by OPSWAT.
• Authentication. API-key only; session-based authentication is not supported.
• Connectivity probe. The integration probes /apikey/info (Cloud does not expose /apiversion), which both validates the API key and returns account and license metadata.
• Rate limiting. Cloud enforces stricter per-key rate limits than a typical Core deployment. The Maximum concurrent scans setting should be kept at its default until the subscription's quota headroom is confirmed.
• Network path. The Manager must reach api.metadefender.com outbound. Deployments routing all outbound traffic through a proxy must populate the Upstream HTTP Proxy setting.

Deployments typically choose MetaDefender Cloud when they do not operate a Core instance and accept the data-sharing implications of submitting file samples to a hosted multi-AV service. Air-gapped and regulated deployments use MetaDefender Core exclusively.

SIEM Integration via Syslog

The Manager forwards logs to one or more external SIEM platforms over Syslog. SIEM integration is the primary mechanism by which MetaDefender NDR events reach a customer's long-term retention, cross-source correlation, and compliance-reporting pipelines.

What gets forwarded

The Manager forwards seven categories of logs. Each category is forwarded in real time, with full context preserved (community identifier, sensor identifier, tenant and group identifiers) so that a SIEM can correlate across sources without losing MetaDefender NDR-specific provenance.

Administrators filter what each destination receives using per-destination and per-group rules. A typical deployment pattern forwards Audit, Alert, and Enrichment to a compliance-tier SIEM with long retention and forwards the higher-volume Session and File info categories to a separate analytics-tier SIEM or omits them entirely.

Transport and properties

MVP ships UDP port 514 standard Syslog only. Each destination uses 514 by default; a non-standard port is supported by overriding the destination port. The integration supports multiple concurrent destinations, each with its own filter rules, facility and severity mapping, and optional structured-format override (RFC 5424 default, CEF and LEEF selectable for destinations whose SIEM expects those formats). Administrators scope destinations to one or more sensor groups — a destination can be restricted to, for example, alerts and enrichment for a specific site's sensor group.

The integration enforces tenant isolation (no log record crosses a tenant boundary), buffers outbound logs during transient SIEM unavailability and replays them when the destination recovers, and sanitizes every outbound message against log-injection attacks before it leaves the Manager.

TLS-encrypted Syslog (RFC 5425) and Syslog over Transmission Control Protocol (TCP) with TLS are targeted for PostMVP. The integration's architecture supports a minimal-configuration migration path: administrators re-use the same destination records and supply TLS credentials through the syslog-forward certificate store, which ships in MVP.

UI and REST surfaces

In MVP the SIEM integration is API-first. The Manager exposes the surface through the following REST endpoints (all prefixed with /api/server):

A graphical Administration surface for the same configuration is planned for a subsequent release; the REST surface above is the MVP-supported mechanism.

Built-in connectivity test

Every destination supports a SIEM Connectivity Test through POST /api/server/syslog-forward/test. The test:

1. Sends a probe syslog message to the destination.
2. Reports success or failure with detailed diagnostics — unreachable host, port blocked, invalid response, TLS handshake failure (when the PostMVP TLS transport is in use).
3. Runs against a prospective destination without altering the persistent configuration.

Administrators run the connectivity test at initial configuration, after any change to the destination, and during troubleshooting when a SIEM stops receiving messages.

Status and observability

Every destination carries a real-time status indicator: connection health, recent transmission rate, and the age of the last successful delivery. A destination in a Failed state is surfaced in the audit log and in the Manager's health monitoring; the Health and Monitoring chapter describes the specific metrics.

The Manager's own syslog forwarding activity — destination changes, buffer high-water events, connectivity-test outcomes — is captured in the audit log with full attribution.

Common Procedures

Adding a new SIEM destination and running the connectivity test

1. An administrator prepares the destination parameters — hostname or IP address, UDP port (514 unless the SIEM expects otherwise), facility and severity mapping, and (optionally) CEF or LEEF structured format.
2. The administrator issues POST /api/server/syslog-forward/test with the prospective destination fields. The Manager sends a probe message and returns a success or detailed-error response.
3. On a successful test, the administrator issues POST /api/server/syslog-forward with the complete destination and its filter rules. The Manager validates the configuration, persists it through the central configuration pipeline, broadcasts the change, and writes an audit entry.
4. The administrator re-runs the connectivity test against the persisted destination record to confirm the Manager's forwarding path.
5. The administrator monitors the destination's status indicator on the Manager's health view and confirms that log messages are flowing on the SIEM side — audit entries for recent administrative actions are the simplest confirmation.
6. If the destination scope is restricted to particular sensor groups, the administrator triggers a representative event (for example, a low-criticality test alert) on a sensor in scope and confirms that only the expected destinations receive the message.

Rotating the MetaDefender API key

Credential rotation for MetaDefender Cloud or MetaDefender Core is designed to be a single-operator change with no service impact.

1. An administrator obtains the new API key from the MetaDefender administration console (or, for MetaDefender Cloud, the OPSWAT portal).
2. The administrator opens Administration → Configuration → Integrations → MetaDefender Core and updates the API key field. The Manager runs a connectivity probe with the new credential before persisting the change; a probe failure leaves the previous credential in force and returns the error to the administrator.
3. On probe success, the Manager persists the change. The new credential is broadcast to the running enrichment service through the configuration pipeline — no restart is required.
4. The administrator confirms the rotation has landed by observing mdcore.scan.submitted advancing on the enrichment's /api/metrics admin endpoint, or by selecting a recent fileinfo event on the Hunt page and confirming that MetaDefender Core enrichment data is attached to subsequent events.
5. Once the new credential is confirmed in service, the administrator revokes the old credential on the MetaDefender side.
6. The audit log records the credential rotation (actor, integration, outcome); the credential value itself is never written to the audit log.

Rotating an integration credential used across a fleet

The MetaDefender Core integration runs Manager-side, so a credential rotation is a single-location change regardless of how many sensors the deployment runs. The same applies to the Upstream HTTP Proxy credential — both changes propagate through the configuration-broadcast mechanism documented in Manager Configuration without per-sensor intervention.

Quick-Start Checklist: Verifying Integrations

See Also

• Administration overview — the Administration page structure, access control, audit trail, and chapter map.
• Manager Configuration — the Integration Settings, Syslog Configuration, Upstream HTTP Proxy, and SSL Certificate surfaces that govern integration behavior.
• Sensor Management — Policy assignment, per-sensor configuration, and fleet-level operations that interact with integration scope.
• Users, Groups, and RBAC — tenant isolation of integration credentials and syslog destinations; audit-log retention.
• Updates Management — the InSights feed distribution pipeline.
• Data Retention — how local retention policy interacts with Syslog forwarding (forwarding does not reduce local retention obligations).
• Health and Monitoring — metrics and status indicators for each integration.