How to Set Up Syslog Forwarding to ThreatHawk SIEM

Prerequisites for Syslog Forwarding to ThreatHawk SIEM

Before configuring any source device, confirm that your ThreatHawk SIEM deployment is ready to receive Syslog traffic. The following components must be in place.

ThreatHawk SIEM supports both unencrypted Syslog (suitable for segmented internal networks) and encrypted transport via TLS. For production deployments, especially those subject to compliance standards automation frameworks like PCI DSS or HIPAA, TLS-encrypted Syslog forwarding is strongly recommended.

Syslog Transport Protocols: UDP, TCP, and TLS

Choosing the right transport protocol affects reliability, security, and performance. ThreatHawk SIEM supports all three options, but each has trade-offs relevant to enterprise SOC engineering.

Syslog over UDP (Port 514)

UDP is the original Syslog transport and remains the most widely supported option. It is connectionless, meaning there is no handshake or acknowledgment. This makes it fast and low-overhead, but also inherently unreliable—packets can be dropped without notification. Use UDP only for low-priority logs on trusted, low-latency networks where packet loss is minimal.

Syslog over TCP (Port 1468 or 601)

TCP provides delivery guarantees through acknowledgments and retransmission. This eliminates the packet loss problem of UDP. However, TCP can introduce backpressure: if the collector slows down, sources may queue or drop logs. ThreatHawk SIEM handles TCP backpressure gracefully with configurable buffer limits, but you should size your collector throughput accordingly.

Syslog over TLS (Port 6514)

For encrypted Syslog forwarding, TLS is the enterprise standard. It wraps TCP Syslog in a TLS tunnel, ensuring confidentiality and integrity of log data in transit. ThreatHawk SIEM supports mutual TLS (mTLS) for authenticating both the source and the collector. This is the recommended transport for compliance-driven environments and for any logs traversing untrusted network segments.

ThreatHawk SIEM can be configured to listen on multiple ports simultaneously, allowing you to mix transports per source type. For example, you could receive UDP from internal switches and enforce TLS from cloud-based firewalls.

Configuring Syslog Forwarding on Common Source Types

The following sections provide step-by-step Syslog forwarding configuration for the most common enterprise log sources. Each example targets the ThreatHawk collector IP and port.

Linux Servers (rsyslog)

rsyslog is the default Syslog daemon on most Linux distributions. To forward logs to ThreatHawk SIEM, add a configuration file in /etc/rsyslog.d/.

*.* @@192.168.1.100:6514;RSYSLOG_SyslogProtocol23Format

global(DefaultNetstreamDriver="gtls")
$ActionSendStreamDriverMode="1" 
$ActionSendStreamDriverAuthMode="x509/name" 
$ActionSendStreamDriverPermittedPeer="threathawk-collector.yourdomain.com" 
*.* @@192.168.1.100:6514

Windows Servers (Windows Event Forwarding via Syslog)

Windows does not natively support Syslog. To forward Windows Event Logs to ThreatHawk SIEM, install a Windows Syslog agent or use a log shipper. ThreatHawk SIEM integrates with the ThreatHawk SIEM + SOAR agent, which handles native Windows Event Log collection and forwards it to the SIEM in Syslog format.

Network Devices (Cisco, Palo Alto, Fortinet)

Network security appliances are among the most important Syslog sources for a SIEM. ThreatHawk SIEM includes pre-built parsers for major vendors.

logging host 192.168.1.100 transport tcp port 6514
logging trap informational
logging facility syslog
logging source-interface GigabitEthernet0/1

config log syslogd setting
    set status enable
    set server "192.168.1.100"
    set port 6514
    set mode reliable
    set facility local0
    set source-ip "10.0.0.1"
end

Cloud and SaaS Sources (AWS, Azure, GCP)

Cloud platforms do not send native Syslog, but you can forward cloud logs to ThreatHawk SIEM via Syslog proxy or log shipper. The recommended approach uses a lightweight forwarder such as rsyslog or syslog-ng running on a cloud instance that tails cloud API logs.

For AWS CloudTrail and VPC Flow Logs, configure the ThreatHawk SIEM connector to pull logs via API, or set up a CloudWatch Logs subscription that delivers logs to a Lambda function which forwards them as Syslog to the collector. The same pattern applies to Azure Monitor and GCP Cloud Logging.

Syslog Message Format and Normalization in ThreatHawk SIEM

Raw Syslog messages arrive in different formats depending on the sending device. ThreatHawk SIEM applies automatic parsing and normalization to map fields to a consistent schema for correlation and search.

Key Syslog Fields Parsed by ThreatHawk

ThreatHawk SIEM extracts the following fields from every Syslog message:

• Timestamp – Normalized to UTC, with timezone offset handled automatically
• Hostname / Source IP – Identifies the sending device
• Facility and Severity – Mapped to standardized levels (0-7)
• Message Content – The raw log line, retained for forensic review
• Structured Data (RFC 5424) – Key-value pairs parsed as separate fields
• Process ID and Application Name – Extracted from Syslog header

Handling Malformed or Non-Standard Syslog

Not all devices produce RFC-compliant Syslog. ThreatHawk SIEM includes a flexible parser chain that attempts to extract meaning from malformed messages before falling back to a default schema. You can also write custom parsing rules using the ThreatHawk parsing language for proprietary appliances.

For devices that truncate long messages (a common issue with legacy Syslog implementations), ThreatHawk SIEM supports message reassembly for TCP-based streams, ensuring that complete log entries are stored and correlated.

Securing the Syslog Pipeline to ThreatHawk SIEM

Log data often contains sensitive information, including user identities, network topologies, and application activity. Securing the forwarding pipeline is a compliance requirement under PCI DSS requirement 10.2, HIPAA §164.312(b), and SOC 2 common criteria.

TLS Certificate Management

When using Syslog over TLS, each source must trust the ThreatHawk collector's certificate. For enterprise-scale deployments, use an internal Certificate Authority (CA) to issue certificates to the collector. Distribute the CA certificate to all Syslog sources. ThreatHawk SIEM supports certificate rotation without dropping active connections.

Network Segmentation and Access Control

Place the ThreatHawk Syslog collector in a dedicated logging segment, accessible only from authorized source subnets. Use ACLs or security group rules to restrict inbound Syslog traffic to known source IP ranges. ThreatHawk SIEM can also label messages by source subnet for correlation with network context.

Rate Limiting and Log Volume Management

A misconfigured device or a denial-of-service attack can flood the Syslog collector. Configure rate limiting at both the source and collector levels. ThreatHawk SIEM provides per-source rate limiting with alerting when a source exceeds its baseline. This is particularly important when onboarding large legacy environments that may generate unexpected log volumes.

Verifying Syslog Forwarding to ThreatHawk SIEM

After configuring your sources, verify that ThreatHawk SIEM is receiving and parsing logs correctly.

Using the ThreatHawk Data Source Dashboard

Navigate to Administration > Data Sources in the ThreatHawk SIEM interface. Each configured source type (Linux Syslog, Windows Agent, Cisco, etc.) shows a live ingestion rate in events per second (EPS). A non-zero EPS confirms that messages are reaching the collector.

Testing with the logger Command

From any Linux source, send a test Syslog message:

logger -n 192.168.1.100 -P 6514 -T "ThreatHawk SIEM test message from $(hostname)"

The -T flag sends over TCP. For UDP, omit it. Then search for "ThreatHawk SIEM test message" in the ThreatHawk SIEM search interface. If it appears with the correct hostname, your pipeline is operational.

Troubleshooting Common Issues

• No logs appearing: Check firewall rules, confirm the collector process is running, and verify the Syslog service is active on the source.
• Malformed timestamps: Ensure all sources and the ThreatHawk appliance are synchronized via NTP. Timestamp drift is one of the most common issues in enterprise SIEM deployments.
• Partial log delivery (TCP only): Check if the collector is experiencing backpressure. Increase the ThreatHawk collector worker threads or add horizontal scaling.
• TLS handshake failures: Verify that the source has the correct CA certificate and that the collector's certificate Common Name matches the hostname used by the source.

Scaling Syslog Forwarding for Enterprise Deployments

Large enterprises often generate millions of Syslog messages per second from thousands of sources. ThreatHawk SIEM is designed to scale horizontally, but you must plan the Syslog forwarding architecture accordingly.

Using Syslog Aggregators and Load Balancers

For environments exceeding 50,000 EPS, deploy Syslog aggregators (such as syslog-ng with high-performance mode) in front of the ThreatHawk collector farm. Aggregators can deduplicate, filter, and compress Syslog messages before forwarding to the SIEM, reducing both bandwidth and storage costs.

Load balancers with Syslog awareness can distribute incoming Syslog streams across multiple ThreatHawk collectors based on source subnet or facility. This avoids single points of failure and enables maintenance windows without data loss.

Filtering Noisy or Redundant Logs

Not all Syslog messages carry security value. Infrastructure health checks, periodic status messages, and debug-level logs can consume significant collector capacity without contributing to detection. Configure source-side filtering via rsyslog property-based filters or ThreatHawk SIEM's ingestion rules to drop low-value messages before they reach the correlation engine.

Syslog Forwarding for Compliance Frameworks

Syslog forwarding is not just a technical exercise—it is a core compliance control. ThreatHawk SIEM maps incoming Syslog data directly to compliance requirements, automating evidence collection and audit reporting.

PCI DSS Requirements for Log Forwarding

PCI DSS requirement 10.2 mandates that all access to cardholder data environments is logged. Syslog forwarding to a centralized SIEM like ThreatHawk satisfies this requirement when you configure sources to send authentication logs, firewall denies, and database access events. ThreatHawk SIEM marks these events with PCI DSS tags for automated reporting.

HIPAA Audit Controls

Under HIPAA §164.312(b), covered entities must implement hardware, software, and procedural mechanisms to record and examine activity. Forwarding Syslog from all systems that access ePHI to a centralized SIEM satisfies the audit control standard. ThreatHawk SIEM provides pre-built HIPAA reports that map Syslog events to the required audit controls.

NIST 800-53 and FedRAMP Logging Requirements

For federal and government environments, NIST 800-53 control AU-3 requires that log records contain specific fields including event type, date/time, source, and outcome. ThreatHawk SIEM enforces this schema at ingestion, ensuring that all forwarded Syslog messages meet the standard before storage.

ThreatHawk SIEM's compliance automation capabilities extend beyond simple log storage. The platform correlates forwarded Syslog with user identity data from Active Directory or LDAP, enabling full audit trails for access reviews, account management, and privileged session monitoring across the Compliance Standards Automation framework.

Best Practices for Enterprise Syslog Forwarding

The following practices, drawn from real-world ThreatHawk SIEM deployments, will help you maintain a stable, secure, and high-performance Syslog pipeline.

Implement Redundant Forwarding Paths

Configure each source to forward Syslog to a primary and secondary ThreatHawk collector. Use separate network paths for redundancy. If your Syslog source supports it (rsyslog and syslog-ng both do), enable failover with queue-on-failure to buffer logs during network interruptions.

Design a Dedicated Logging Network

Separate log traffic from production data. A dedicated VLAN or VRF for Syslog traffic reduces packet loss, simplifies firewall rules, and prevents log delivery from competing with business traffic. ThreatHawk SIEM can apply metadata tags based on the VLAN ID of the incoming connection.

Monitor the Syslog Pipeline Itself

Treat the Syslog forwarding infrastructure as a critical security control that requires monitoring. ThreatHawk SIEM includes dashboard widgets that display ingestion rates, per-source volume, and error counts. Configure alerts for zero EPS from any previously active source—silent sources often indicate a configuration change or device failure that can create a blind spot.

Plan Retention with Forwarded Logs in Mind

Syslog messages can consume storage rapidly. ThreatHawk SIEM supports tiered storage policies: hot storage for real-time correlation and investigation, warm storage for 90-day compliance retention, and cold storage for 1-7 year archival. Plan your retention periods based on your compliance obligations, not just storage budget.

Advanced Syslog Forwarding Topologies with ThreatHawk SIEM

For complex enterprises, the simple "device sends Syslog to collector" model may not suffice. ThreatHawk SIEM supports several advanced topologies.

Multi-Tenant Syslog Forwarding for MSSPs

MSSPs managing multiple customers need to segregate Syslog streams while maintaining a single SIEM platform. The ThreatHawk MSSP SIEM architecture uses tenant-aware collectors that tag incoming Syslog messages with customer identifiers. Configure each customer's devices to forward to a dedicated port or IP, and the collector automatically routes logs to the correct tenant workspace.

Syslog Proxy and Aggregation for Remote Sites

For branch offices or remote manufacturing sites with limited bandwidth, deploy a local Syslog proxy that caches and compresses logs before forwarding to the central ThreatHawk collector. The proxy can filter out informational messages, send only security-relevant events in real time, and batch the rest during off-peak hours.

Integrating Syslog Forwarding with SOAR Workflows

When ThreatHawk SIEM detects a correlation rule trigger from forwarded Syslog, it can automatically initiate a SOAR playbook. For example, repeated authentication failures from a single IP across multiple Syslog sources can trigger an automated IP block via a firewall API call. This closed-loop response is built into the ThreatHawk SIEM + SOAR solution.