A small city's Splunk Security Essentials data-source checklist shows rich firewall syslog but no DNS. Command-and-control content is marked weak. What should the analyst conclude?
Select an answer to reveal the explanation.
Short Explanation
Firewall logs see connections; DNS logs see the names those connections asked for. If SSE says DNS is missing, C2 hunts that key on resolver data are flying half-blind. Add DNS—do not unplug the firewall to silence the checklist.
Full Explanation
When a small city's Splunk Security Essentials data-source checklist shows rich firewall syslog but no DNS, and command-and-control content is marked weak, the analyst should conclude that missing DNS is a high-value coverage gap. Many C2 detections depend on resolver or passive-DNS fields that firewall allow/deny syslog does not reliably provide. Firewall logs see connections; DNS logs see the names those connections asked for. Until DNS is onboarded, C2 content that needs resolver telemetry stays weak—and that gap should be treated as a collection priority.
Claiming firewall logs alone satisfy every DNS and C2 detection in Security Essentials fails by concept: SSE marks weakness precisely when DNS prerequisites are absent. Claiming C2 content automatically synthesizes DNS queries from Palo Alto deny logs invents a capability the product does not promise. Disabling the firewall sourcetype so Security Essentials stops warning about DNS reduces coverage further instead of closing the DNS gap.
Exam caveat: SSE checklist items that pair strong firewall with weak C2 usually signal missing DNS—do not silence the warning by unplugging firewall telemetry.
Operational check: review the SSE data-source view for C2/DNS prerequisites, plan DNS resolver or passive-DNS onboarding for the city, keep firewall collection online, and re-check C2 content strength only after DNS events are present and mapped.