CSA (312-39) SOC Simulation Lab

Master enterprise log architecture. In this lab, you will design and troubleshoot a distributed syslog infrastructure to optimize SIEM ingestion across global WAN links.

Scenario Context

You are a Tier 3 SIEM Engineer at ABC Corp. The company's Tokyo office is overwhelming the international WAN link by sending raw firewall and router syslogs directly to the central Splunk Indexers in New York via UDP 514.

You are mentoring an L2 analyst who is tasked with deploying a local Linux server in Tokyo. This server will receive the logs locally, batch them, apply basic filtering, encrypt them via TLS, and send them reliably over TCP to the New York HQ. You need to verify the analyst's understanding of this architectural component.

Security Environment

The L2 Analyst provides you with the proposed rsyslog.conf configuration for the new intermediate server in Tokyo:

# TOKYO INTERMEDIATE LOG SERVER CONFIGURATION
# 1. Receive logs locally from Tokyo routers/firewalls (UDP/514)
module(load="imudp")
input(type="imudp" port="514")

# 2. Define disk-assisted queue for WAN resilience
$ActionQueueType LinkedList
$ActionQueueFileName tokyo_fwd_queue
$ActionResumeRetryCount -1
$ActionQueueSaveOnShutdown on

# 3. Forward to NYC Central SIEM (TCP/6514 over TLS)
*.* @@nyc-splunk-vip.abc.corp:6514

ABC is a highly reputed multinational company with multiple offices across the globe and you are working here as an L2 SOC Analyst. You are implementing a centralized logging solution to enhance security monitoring. You are responsible for ensuring that log messages from routers, firewalls, and servers across multiple remote offices are efficiently collected and forwarded to a central syslog server. To streamline this process, an intermediate component is deployed to receive log messages from different devices and forward them to the main syslog server. Which component in the syslog infrastructure performs this function?

Hint: Look at the action being performed. The server receives data and passes it onward (acts as a middleman) rather than storing it permanently.

Expert Insight: Senior SOC Analyst Debrief

What is happening here?

Enterprise networks cannot afford to have thousands of edge devices directly traversing a WAN link to hit a central SIEM. Unencrypted UDP/514 syslogs across the internet drop packets, violate compliance, and saturate bandwidth. By deploying an intermediate node (like an Rsyslog instance, Splunk Heavy Forwarder, or Logstash), we create a local aggregation point. This node collects the noisy local data, queues it, and reliably forwards it to the central SOC.

Why option A is correct

A Syslog Relay (also known as a Forwarder) is specifically designed to receive syslog messages from downstream devices and retransmit them to a higher-level collector or another relay. In this scenario, the Tokyo server acts as the relay, ensuring logs from local firewalls are safely aggregated before making the long haul to New York.

Why the other options are wrong

A Syslog Collector (C) is the final destination where logs are indexed and parsed (e.g., the central SIEM itself). A Syslog Database (B) is simply the storage medium at the collector level. A Syslog Listener (D) is just the daemon process or socket (like UDP 514) open on any node to accept incoming data, not the architectural component responsible for the store-and-forward behavior.

Real-world SOC Application

In modern SOCs, data pipelines like Cribl Stream, Logstash, or Splunk Heavy Forwarders serve as advanced Syslog Relays. As a SOC analyst, you must know where your logs are coming from. If Tokyo logs suddenly stop arriving in Splunk, you don't troubleshoot the Tokyo firewalls first; you SSH into the Tokyo Syslog Relay and check if the disk-assisted queue (shown in the rsyslog.conf above) is full because the WAN link went down.

Mini-Lesson: The Value of Disk-Assisted Queues

Look at the rsyslog.conf snippet provided in the scenario. The lines $ActionQueueType LinkedList and $ActionResumeRetryCount -1 are critical. If the central SIEM in NYC goes offline for patching, the Syslog Relay in Tokyo will not drop the incoming firewall logs. Instead, it temporarily spools them to local disk (tokyo_fwd_queue). Once the SIEM comes back online, the Relay automatically drains the queue, preventing catastrophic data loss during incident response investigations.

Ready to sharpen your SOC skills further?

Explore more realistic L1/L2/L3 scenarios and SIEM engineering labs.

Explore CSA Simulations