How a U.S. restaurant group replaced its legacy log shippers with one telemetry pipeline
With NXLog Platform, the Group collects logs from Windows, Linux, macOS and network appliances, processes them at the source, and forwards structured telemetry to Google SecOps — without running a separate shipper for every platform.
Business Demand
Improve security posture across roughly 2,200 locations and support regulatory compliance, without adding operational overhead.
Key Challenges
Collect from Windows, Linux, macOS and network appliances, handle a wide spread of log types, and deliver all of it into Google SecOps through one integration.
Results
One collection pipeline across the estate, faster incident response, and audit-ready log trails.
The Challenge
The Group runs around 2,200 restaurant locations in the United States, and its IT estate covers roughly 20,000 endpoints — Windows and Linux servers, macOS machines and a range of network appliances. Its legacy log shipping tools could not scale to a footprint that size, and they could not cover every platform inside it.
In quick-service and fast-casual dining, the systems that matter most to security are the same systems that keep the business trading: payment terminals, ordering and marketplace apps, customer data stores, and integrations with suppliers and delivery partners. High transaction volumes and a wide third-party surface give an attacker plenty of places to look, and security stops being a back-office function.
So the team needed to aggregate logs from Active Directory, DNS, DHCP, IIS and PowerShell on the Windows side, journald and flat files on Linux, unified logging on macOS, and syslog over UDP from firewalls and appliances — then land all of it in Google SecOps in a format the platform could parse. Running a different collector for each of those sources was the problem they wanted to remove, not repeat.
The Solution
The Group deployed NXLog Platform, with NXLog Agent as the collection layer, giving the team one deployment process and one configuration language across every operating system in the estate. On Windows, im_msvistalog subscribes to the Security, Application, System, PowerShell, WinRM, Remote Desktop, SMB and WMI event log channels, and im_file reads IIS and DHCP audit logs from file. On Linux, im_file and im_systemd cover flat files and journald, macOS uses Apple's native unified logging, and firewalls and appliances send syslog over UDP to a central agent running im_udp.
Processing happens before anything leaves the endpoint: built-in support for IETF syslog and JSON produces structured output, and the agent enriches records on the fly with hostnames, timestamps and context-aware tags. Filtering runs at the source too, so low-value events do not cross the network and do not reach the SIEM. Underneath, a multi-threaded core, log queues, buffering with save-to-disk and built-in flow control keep delivery intact when a destination slows down or drops off: rather than discarding events, the agent pauses the input until the route clears.
Agent management runs over TLS, and the Remote Management module (xm_admin) adds mutual X.509 certificate authentication with directory-scoped access control lists, so only authorized agents connect and only the intended directories can be read or written. Deployments and updates are automated from NXLog Platform, and centralized credential handling plus audit trail logging support the Group's compliance work.
Delivery into Google SecOps runs through a Google SecOps forwarder, with NXLog Agent sending structured records to it over TCP, a path that Google's own SecOps ingestion documentation describes for Windows Event Log, Active Directory and DNS. If the Group later wants to drop the forwarder hop, NXLog Agent's Google SecOps output module (om_chronicle) sends records straight to the Ingestion API over HTTPS.
Why it Worked
One agent for Windows, Linux, macOS and network appliances
Processing and filtering at the source, before data reaches the SIEM
TLS-secured agent management with mutual certificate authentication
A documented delivery path into Google SecOps
Results
Security monitoring improved first. With every source landing in Google SecOps in a consistent format, alert quality went up and the Group moved close to real-time threat detection. Analysts now open an investigation against centralized log data instead of chasing individual hosts, which has cut the time between detection and remediation.
Compliance work got easier for the same reason. The pipeline gives the Group a transparent audit trail, and it can show that the logs it needs are collected, stored, retrievable and disposed of on schedule.
Filtering at the source also changed the SIEM arithmetic. By dropping low-value events before they leave the endpoint, the Group raised the share of useful signal reaching Google SecOps while staying inside its existing licensing tier.
And because one pipeline now feeds everything, reporting is consistent across teams that used to work from different collectors and different formats.
Full visibility
One collection pipeline across roughly 20,000 endpoints
SIEM integration
Structured security telemetry delivered into Google SecOps
Compliance support
Encrypted in transit, with audit-ready log trails
Room to grow
New sources and formats added without adding a new collector
About the customer
The customer is a fast-casual restaurant group operating around 2,200 locations across the United States, headquartered in California. It asked to remain anonymous. Its IT estate covers roughly 20,000 endpoints spanning Windows, Linux, macOS and network infrastructure.
Follow us
© Copyright NXLog Ltd.