Unknown Log Source After Firewall HA Cutover
Your QRadar 7.5.0 deployment ingests about 3,900 events per second (EPS) against a 5,000 EPS license. A new FortiGate HA pair at the perimeter sends syslog to a Linux relay, which forwards to two Event Collectors. After cutover, 28% of the firewall events appear under the Unknown log source type, and the Firewall Deny rule generates roughly 900 offenses per day. The relay adds a hostname field, and the FortiGate sends both traffic logs and event logs over UDP 514. You have a four-hour change window tonight, cannot restart the Event Processors, and must preserve raw events for 30 days. The network team can change the FortiGate syslog destination but not the log format. Analysts already muted the noisiest rule once, and it re-fired within an hour.
1. Rank the likely causes of the Unknown classification and list the first three checks you would run, with the reasoning for the order.
Read the worked answer
The order should follow blast radius and reversibility. First, check log source identity, because a relay commonly rewrites the apparent sender: QRadar may see the relay IP or hostname instead of the FortiGate, so events arrive but do not match the FortiGate DSM entry. Confirm by filtering Log Activity for the Unknown source and inspecting the payload, then compare the configured Log Source Identifier with the actual sender. Second, check whether only traffic logs or only event logs are unparsed; the FortiGate can emit different syslog formats for each, and a DSM may parse one but not the other. Third, check for duplicate or conflicting log source entries created during cutover, especially one entry per collector, which splits traffic and makes the failure look partial. Do not start by editing the custom rule: 28% unknown means the parser/identity layer is suspect, and rule changes would hide the real defect while consuming the change window.
2. Propose a fix that remains correct after an HA failover, and explain why you rejected the simpler options.
Read the worked answer
The durable fix is to give the syslog path a stable identity that does not change when the FortiGate fails over. Either send directly from the FortiGate to both collectors using a dedicated management address that floats with the HA pair, or keep the relay but front it with a fixed VIP and define the log source against that VIP. Then verify the DSM parses both traffic and event logs and that the identifier matches on both collectors. I would reject defining the log source by the physical HA node address because failover changes the sender and reintroduces Unknown events. I would also reject widening the identifier to a subnet or accepting all unknown events: that would map unrelated devices into the FortiGate DSM and corrupt offense attribution. A relay without a stable VIP is the same failure deferred, not fixed. Test by forcing a failover during the window and confirming events still land under the correct log source.
3. Define acceptance criteria for tonight's change, including at least one criterion that is not simply 'offenses go down'.
Read the worked answer
Acceptance should cover parsing, identity stability, capacity, and retention, not just offense count. Proposed criteria: Unknown log source events from the firewall fall below 1% of that log source's volume for 30 consecutive minutes; both traffic and event logs show parsed fields such as source and destination address, action, and policy; a forced HA failover produces no more than a 60-second gap and no reversion to Unknown; collector EPS remains below 80% of tested capacity; and a raw-event search for a known test event returns within the 30-day retention window. Offense volume is a secondary signal: I would expect Firewall Deny offenses to fall sharply, but that could also happen if events are being dropped, so it cannot stand alone. Record the pre-change baseline and compare the same hour the next day to avoid mistaking normal diurnal traffic for success.