Network and syslog ingestion

This article explains how network and syslog data is ingested into Kaseya MDR, how log‑based telemetry is associated with organizations, and what to expect in the platform once ingestion is working.

Use this article to understand how network and infrastructure logs contribute to managed detection and investigation in MDR, not how firewall devices or network equipment are configured.

This article explains:

  • What network and syslog ingestion means in Kaseya MDR

  • Common types of sources that provide syslog‑based telemetry

  • How ingested data is associated with an organization

  • Where network and infrastructure activity appears in MDR

  • What visible outcomes indicate that ingestion is working

Network and syslog ingestion in Kaseya MDR

In Kaseya MDR, network and syslog ingestion refers to the collection of log‑based telemetry from network devices, firewalls, and infrastructure systems that emit security‑relevant logs.

Unlike endpoint telemetry:

  • Network and syslog sources do not generate host‑based events

  • There is no agent installed on the source device

  • Devices send logs externally using standard formats such as syslog

Once received, this telemetry is evaluated as supporting evidence and detection signals within MDR investigations, alongside endpoint and identity activity.

Network and syslog ingestion extends MDR visibility beyond individual hosts, providing infrastructure‑level context used by the managed SOC.

Common network and syslog data sources

Network and syslog ingestion is typically used for infrastructure systems that generate security‑relevant logs, including:

  • Firewalls and network security appliances

  • VPN and remote access systems

  • Network infrastructure (routers, switches, load balancers)

  • Authentication or access systems that emit syslog events

  • Other infrastructure devices that generate operational or security logs

These sources forward log data using supported syslog formats to an MDR‑managed ingestion endpoint.

Components involved in ingestion

Network and syslog ingestion in Kaseya MDR relies on platform‑managed ingestion components that receive and process incoming logs.

These components include:

  • Syslog collectors, which receive incoming log data over supported protocols

  • Log analyzers, which normalize and interpret incoming telemetry

These components define how data is received and interpreted within MDR. They do not configure or manage the source devices themselves.

Configuration of firewalls and network equipment is always performed externally on those systems.

How network and syslog data is associated with organizations

Network and syslog telemetry must be associated with an organization to be evaluated in the correct MDR context.

Depending on the ingestion configuration:

  • Logs may be explicitly routed to a specific organization

  • Organization association may be determined by the selected ingestion configuration or assigned receiver

Once associated:

  • Network activity contributes to alerts and investigations within that organization

  • Telemetry can be correlated with endpoint, identity, and other sources

  • Organization association determines where alerts appear, not how detections are evaluated.

Where network and syslog activity appears in Kaseya MDR

Network and syslog sources do not appear as endpoints, devices, or configurable applications.

Instead, their presence is reflected through alert context and investigation evidence.

You will see network and syslog activity in:

  • Alert details: Alerts may include firewall, network, or infrastructure log evidence when relevant to detection.

  • Analysis > Investigations: Network and syslog telemetry is correlated with endpoint and identity activity to validate scope and impact.

Visibility is alert‑driven, not log‑browser–driven.

How network and syslog sources differ from other MDR data sources

Different MDR data sources contribute in different ways:

  • Endpoint and infrastructure sources provide host‑based process and behavior data

  • Identity and cloud activity provides authentication and account context

  • Network and syslog sources provide infrastructure‑level signals and supporting evidence

  • Network and syslog sources do not establish device inventory or continuous activity views. They contribute specific signals used to validate detections and investigations.

What you will see when network and syslog ingestion is working

When network and syslog ingestion is functioning correctly:

  • Network or firewall‑related evidence appears in relevant alerts

  • Infrastructure log data is visible in investigations

  • Network activity can be correlated with endpoint or identity behavior

There may be no standalone “connected” indicator. Successful ingestion is confirmed through alert and investigation context, not through raw log listings.

Validating network and syslog ingestion

Typical validation involves confirming that:

  • Logs are being received by the MDR ingestion components

  • Network or firewall activity appears in alerts or investigations

  • Data is associated with the correct organization

If expected activity is not visible, review:

  • Ingestion configuration and destination values

  • Organization association

  • Source device log forwarding configuration

Fine‑tuning ingestion behavior is handled through ingestion‑specific configuration articles.

Integration‑specific network ingestion

Network and syslog ingestion describes the general model for how infrastructure logs enter Kaseya MDR.

Some sources, such as firewall telemetry, are configured using application‑specific ingestion workflows.

For step‑by‑step guidance, see Configuring Firewall Log Analyzer (Firewall log ingestion). That article builds on the concepts described here and explains how firewall logs are received, processed, and validated for MDR investigations.

Key takeaway

Network and syslog ingestion enables infrastructure‑level visibility in Kaseya MDR. Log‑based telemetry from firewalls and network devices is received, associated with an organization, and used by the managed SOC as supporting evidence during detection and investigation—without exposing raw log streams or device inventories.