Integrations

The Integrations section of the Administration page connects MetaDefender NDR to external services. These services extend detection and response beyond the sensor and the Manager's own UI (user interface). This chapter documents four Minimum Viable Product (MVP) integrations. They are MetaDefender Core, MetaDefender Cloud, Syslog to Security Information and Event Management (SIEM) platforms, and threat intelligence. For each integration, it gives the necessary configuration. It also gives health verification steps, credential rotation procedures, and connectivity tests.

This chapter is 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 and an administrator account. It also assumes familiarity with the Administration page layout in the Administration overview. See the Manager-global settings in Manager Configuration.

This chapter expands each abbreviation at first use. The full list follows:

• 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. Configure the MetaDefender NDR enrichment service to use one deployment or the other, not both. Syslog supports multiple concurrent destinations.

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

All four integrations respect tenant isolation. The Manager scopes each tenant's integration configuration, credentials, syslog destinations, and per-destination filter rules to that tenant alone. Users, Groups, and RBAC documents the enforcement model.

MetaDefender Core

MetaDefender Core is the on-premises OPSWAT file-analysis product. MetaDefender NDR's MetaDefender Core enrichment submits files from Suricata's file-store to the MetaDefender Core Application Programming Interface (API). The enrichment retrieves multi-AV scan results. It attaches the results as enrichments on the related fileinfo event. Enriched file verdicts drive downstream alerts. They appear on the Hunt page when analysts pivot from a file event.

Purpose

The AV engines licensed on the MetaDefender Core deployment analyze every file that the enrichment submits in parallel. The enrichment attaches the verdict to the network event. Verdicts include Clean, Infected, Suspicious, and the per-engine signature detail that supports the verdict. The Manager stores the verdict with the flow, session, and file metadata that triggered the extraction.

The enrichment checks the MetaDefender hash cache before it submits any file bytes. Files with a recent cached result usually resolve without re-upload. This conserves scan 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 polls, retries, and timeout records behind the scenes.

MVP scope

MVP covers hash lookups, file submission, polls for scan completion, and result enrichment of the fileinfo event that triggered it. MetaDefender NDR does not connect the following MetaDefender Core capabilities in MVP. They are PostMVP targets:

• YARA-based pre-scan on the sensor

• Content Disarm and Reconstruction (CDR) retrieval of sanitized files

• Data Loss Prevention (DLP) scan

• Vulnerability / Common Vulnerabilities and Exposures (CVE) assessment

• A persistent failed-file retry queue with Manager UI backlog exposure

Configuration

Configure the MetaDefender integration from Administration -> Configuration -> Integrations -> MetaDefender Core. Key parameters:

Credentials reload through the configuration-broadcast channel after rotation. No pod restart is necessary.

How file events reach the enrichment

Files from the sensor's Suricata file-store produce a fileinfo event. The enrichment consumes the event and extracts the SHA-256. If SHA-256 is unavailable, it extracts the MD5. The enrichment filters events that fail the MIME or size checks. It opens the carved file from the sensor's file-store or from object storage. The sensor never transfers the carved file directly to MetaDefender. The Manager-side enrichment reads the file and submits it 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 probes the configured endpoint.

   • It uses /apikey/info for Cloud and /version for Core.

   • The form displays success or a detailed error.

   • The Manager saves the integration only after probe success.

2. Enrichment statuses on merged events.

   • The enrichment reports status=enriched when files produce a scan result.

   • It reports status=enabled when filters exclude files.

   • Filter causes include too large, skipped MIME type, and hash-lookup-only mode.

   • A timeout status means the enrichment did not return a result before the aggregator's time-to-live (TTL) expired.

   • Investigate timeout status.

3. Scan counters.

   • The enrichment's /api/metrics admin endpoint exposes mdcore.scan.{submitted,completed,failed,timeout} and mdcore.cache.{hit,miss}.

   • A healthy integration shows convergence between submitted and completed.

   • Healthy values do not show elevated failed or timeout.

MetaDefender Cloud

MetaDefender Cloud is the hosted alternative to MetaDefender Core. Configuration and operational behavior match 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; Cloud does not support session-based authentication.

• 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 limit. Cloud enforces stricter per-key rate limits than a typical Core deployment. Keep the Maximum concurrent scans value at its default until you confirm the subscription's quota headroom.

• Network path. The Manager must reach api.metadefender.com outbound. Deployments that route all outbound traffic through a proxy must populate the Upstream HTTP Proxy value.

Deployments typically choose MetaDefender Cloud when they do not operate a Core instance. They also must accept the data-share implications of file sample submission 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 that sends MetaDefender NDR events to customer pipelines. These pipelines provide long-term retention, cross-source correlation, and compliance reports.

What the Manager sends

The Manager forwards seven categories of logs. The Manager sends each category in real time. It preserves full context: community identifier, sensor identifier, tenant identifier, and group identifier. Thus, a SIEM can correlate across sources without loss of MetaDefender NDR-specific provenance.

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

Transport and properties

MVP ships UDP port 514 standard Syslog only. Each destination uses 514 by default. To use a non-standard port, override the destination port. The integration supports multiple concurrent destinations. Each destination has its own filter rules, facility and severity mapping, and optional structured-format override. RFC 5424 is the default. CEF and LEEF are selectable for destinations whose SIEM expects those formats. Administrators scope destinations to one or more sensor groups. For example, they can restrict a destination to alerts and enrichment for a specific site's sensor group.

The integration enforces tenant isolation. No log record crosses a tenant boundary. It buffers outbound logs during transient SIEM unavailability. It replays them when the destination recovers. It 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 PostMVP targets. The integration's architecture supports a migration path with minimal configuration. Administrators re-use the same destination records. They 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 these REST endpoints. All endpoints have the /api/server prefix:

OPSWAT plans a graphical Administration surface for the same configuration in 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 does these actions:

1. Sends a probe syslog message to the destination.

2. Reports success or failure with detailed diagnostics. Diagnostics include unreachable host, port blocked, invalid response, and TLS handshake failure.

3. Runs against a prospective destination and does not change the persistent configuration.

Administrators run the connectivity test at initial configuration. They run it after any change to the destination. They also run it when a SIEM stops message receipt.

Status and observability

Every destination has a real-time status indicator. It shows connection health, recent transmission rate, and the age of the last successful delivery. The audit log and Manager health view show a destination in a Failed state. The Health and status chapter describes the specific metrics.

The audit log captures the Manager's own syslog send activity with full attribution. This includes destination changes, buffer high-water events, and connectivity-test outcomes.

Common procedures

Add a new SIEM destination and run the connectivity test

1. Prepare the destination parameters.

   • Set the hostname or IP address.

   • Set the UDP port (514 unless the SIEM expects otherwise).

   • Set the facility and severity mapping.

   • Select CEF or LEEF structured format if the SIEM needs it.

2. Issue POST /api/server/syslog-forward/test with the prospective destination fields.

   • The Manager sends a probe message.

   • It returns success or a detailed error.

3. If the test succeeds, issue POST /api/server/syslog-forward with the complete destination and its filter rules.

   • The Manager validates the configuration.

   • It saves the configuration.

   • It broadcasts the change.

   • It writes an audit entry.

4. Run the connectivity test again against the saved destination record. This step confirms the Manager's Syslog path.

5. Watch the destination's status indicator on the Manager's health view.

   • Confirm that log messages flow on the SIEM side.

   • Recent audit entries are the simplest confirmation.

6. If the destination scope applies only to specific sensor groups, trigger a representative event on a sensor in scope.

   • For example, send a low-criticality test alert.

   • Confirm that only the expected destinations receive the message.

Rotate the MetaDefender API key

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

1. Obtain the new API key from the MetaDefender administration console. For MetaDefender Cloud, use the OPSWAT portal.

2. Open Administration -> Configuration -> Integrations -> MetaDefender Core.

   • Update the API key field.

   • The Manager runs a connectivity probe with the new credential before it saves the change.

   • A probe failure keeps the previous credential and returns the error.

3. On probe success, the Manager saves the change.

   • It broadcasts the new credential to the active enrichment service.

   • No restart is necessary.

4. Confirm that the rotation landed.

   • Watch mdcore.scan.submitted advance on the enrichment's /api/metrics admin endpoint.

   • Or select a recent fileinfo event on the Hunt page.

   • Confirm that MetaDefender Core enrichment data attaches to later events.

5. After the new credential is in service, revoke the old credential on the MetaDefender side.

6. Confirm that the audit log records the credential rotation.

   • It records the actor, the integration, and the outcome.

   • The Manager never writes the credential value to the audit log.

Rotate an integration credential used across a fleet

The MetaDefender Core integration runs Manager-side. Thus, credential rotation is a single-location change regardless of the number of sensors in the deployment. The same rule applies to the Upstream HTTP Proxy credential. Both changes propagate through the configuration-broadcast mechanism in Manager Configuration. No per-sensor intervention is necessary.

Quick-start checklist: verify 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 control 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 send (Syslog send does not reduce local retention obligations).

• Health and status -- metrics and status indicators for each integration.