The security operations center gladly ingested the appliance into its SIEM, then reported a problem: appliance events arrive but cannot be distinguished from firewall noise, and several fail to parse entirely. What configuration thinking was skipped at the forwarding stage?

A SIEM is an attribution machine: an event it cannot place - by source, schema or format - is noise, and a stream of noise is indistinguishable from an unapproved attack surface. Configuring forwarding therefore means three decisions, not one destination: messages must carry an unmistakable source identity consistent with the asset inventory; transport and format must match what the collector expects - protocol, facility, timestamp conventions; and the forwarded event classes should be the ones the SOC will actually use. With those in place, events arrive parsed, routed and attributable, and 'invisible among firewall logs' becomes a filter query. 'Destination is the whole job' abdicates the rest of the contract: correct IP and port still yield unparseable, unattributable messages - exactly the failure the SOC reported. Forwarding literally every event class is the opposite error: volume without schema discipline adds to the very noise the SOC complained about, and a wider firehose never helps the parser. Pull-based copies to a shared folder sacrifice timeliness, ordering and integrity - batch files are a forensic archive, not a monitoring feed, and each copy raises provenance questions. Exam caveat: time synchronization between appliance and collector decides whether events correlate at all - verify NTP on both ends first. Operational check: from the SOC side, filter for a fresh appliance login event and confirm it is attributed to this host and parsed cleanly end to end.