Missing Logs After a Suspected Rogue AP
A branch office reports that a laptop briefly connected to an SSID named like the corporate SSID near the building. The Aruba controller logs client associations and authentication events to a local buffer and forwards to a syslog server. The SOC pulls logs and finds: (a) no rogue AP detection events for the branch in the last 7 days, (b) client association logs only going back 18 hours, and (c) the syslog server shows gaps of 2–4 hours each day around midday. The controller's local log buffer is small and configured to overwrite. Rogue AP detection is enabled on the controller but the branch APs are in a remote site behind a WAN link that has had intermittent outages. The suspected event occurred about 30 hours ago.
1. Assess what can and cannot be concluded from the available evidence, and identify the logging gaps that limit the investigation.
Read the worked answer
What cannot be concluded:
- We cannot confirm or rule out a rogue AP at the branch. The absence of rogue AP detection events is not evidence of absence - detection depends on APs scanning, and the branch APs sit behind an intermittent WAN link, so scan results may never have reached the controller.
- We cannot reconstruct the client association from 30 hours ago: the controller's local buffer holds only ~18 hours and overwrites, so the relevant window is already gone locally.
What the gaps tell us:
- 18-hour local retention is far too short for a 30-hour-old event; the controller is not a reliable forensic source.
- 2–4 hour midday syslog gaps align with the WAN outages - logs generated during outages were likely dropped rather than buffered and forwarded, so the syslog server has holes exactly where branch activity is least visible.
- No rogue AP events in 7 days at a site with active scanning enabled is itself suspicious and suggests scan/telemetry is not reaching the controller.
Conclusion: the evidence is insufficient to determine whether the laptop connected to a rogue AP; the investigation is blocked by retention and transport gaps, not by a lack of an event.
2. Recommend logging and monitoring changes so a similar event is investigable next time, prioritizing the highest-impact fixes.
Read the worked answer
Priority 1 - close the transport gap (highest impact):
- Configure the branch to buffer and retry syslog during WAN outages, or deploy a local collector at the branch that forwards when the link recovers. Logs lost in transit cannot be recovered later.
- Alert on syslog gaps (expected heartbeat missing for N minutes) so outages are visible in real time rather than discovered during an investigation.
Priority 2 - fix retention:
- Increase the controller's local buffer and/or ensure the syslog server retains at least 30–90 days (policy-dependent) so a 30-hour-old event is always recoverable.
- Confirm which event categories are forwarded (client association, authentication, rogue/IDS, config changes) and that none are local-only.
Priority 3 - restore rogue/IDS visibility:
- Verify APs at the branch are actually scanning and reporting (IDS/rogue detection enabled per AP, and results reaching the controller). Test by introducing a known test AP and confirming an alert.
- Enable WIDS/WIPS signatures and alerting for spoofed SSID names matching corporate.
Priority 4 - detection & response:
- Alert on SSID name similarity to corporate (evil-twin pattern) and on client associations to non-corporate BSSIDs.
- Add a runbook: on suspected rogue, capture local controller logs immediately, check branch collector, and survey the area - do not wait for the WAN to recover.
Residual: even with fixes, a determined attacker can operate during an outage; local collection at the branch is the key mitigation.