A 4.2 GB Upload Alert With Gaps in the Underlying Telemetry
A security operations team of four analysts covers 5,000 endpoints and 120 servers. The SIEM keeps proxy logs for 7 days, firewall logs for 30 days, and does not ingest DNS at all. Endpoint telemetry arrives through a management console that reports agent health, and 380 endpoints currently show agent health as degraded or reporting more than 72 hours ago. At 08:05 on a Monday, an alert fires: 4.2 GB uploaded from a single internal host to an unfamiliar cloud storage domain between 02:20 and 02:44. The host is a build server used by a contractor team, and its endpoint agent last reported 9 days earlier. There is a business-critical deployment scheduled on that server at 15:00, and the application owner says the upload was probably a routine artifact sync. Data-loss-prevention generates about 200 alerts per day, of which roughly 180 are closed as noise after review.
1. Assess how much confidence you can place in this alert and identify the next three pieces of evidence you would obtain, with the reasoning for each.
Read the worked answer
Confidence: moderate on the network behaviour, low on the context. The proxy record showing 4.2 GB to an unfamiliar domain is a real observation. What is missing is any endpoint-side view of what process moved the data and whether it read anything sensitive, because the agent has been silent for 9 days. An unverified business explanation from the application owner is not evidence, especially at 08:05 on the Monday after the event.
Evidence one - the domain. Resolve and categorize it: registration age, hosting provider, whether other hosts in the estate contacted it, and whether it appears in threat intelligence. A newly registered domain contacted by one build server is a different finding from an established artifact repository contacted by forty servers.
Evidence two - the host itself, live. Check running processes, open connections, scheduled tasks and recent service creation on the build server before anything is rebooted or cleaned. This is time-critical because the 15:00 deployment will otherwise overwrite the state.
Evidence three - what data was reachable. Determine which repositories and file paths the build server's service accounts can read. Volume alone means little; 4.2 GB of source code is a different conversation from 4.2 GB of compressed build artifacts.
Also: check whether the other 379 degraded agents cluster on the same subnet or management path, which would suggest a collection failure rather than 379 independent faults.
2. Do you isolate the build server before 15:00, knowing the deployment will be blocked? Justify the decision and the alternative if you choose not to isolate.
Read the worked answer
Decision: Isolate, and do it now, but define what isolation means rather than pulling the plug on the host.
Reasoning: the cost of a delayed deployment is measurable and recoverable; the cost of an active exfiltration channel remaining open on a server with contractor access is neither. The endpoint agent on that host is blind, so I have no way to observe whether the channel is still open or whether a second stage is resident. Waiting four hours to protect a schedule is a decision to accept unknown risk for known convenience.
Isolation done properly: block the host's egress at the firewall while allowing the specific internal dependencies the deployment needs, or move it to a quarantine VLAN, and preserve the ability to take a memory image before any remediation. If the application owner insists the deployment must proceed, the compromise is to run it from an alternate build node after confirming that node is clean and that its credentials are not shared with the affected server.
What makes the decision defensible either way: documenting the trade-off at the time. If the business overrides the isolation, record who accepted the risk, what compensating monitoring was put in place - full packet capture on that host, for instance - and when the decision will be revisited.
3. Given a four-analyst team and a fixed budget, which logging gap would you close first and how would you argue the case?
Read the worked answer
First gap to close: DNS logging. Second: raise proxy retention beyond 7 days. Third: fix agent-health coverage.
Reasoning for DNS: almost every intrusion and exfiltration path resolves a name before it moves data. In this incident, DNS would have given a timeline of when the build server first looked up the destination and whether other hosts did the same - scope information that neither the proxy nor a blind endpoint can supply. It is also comparatively cheap: existing resolvers, a flow-record export, and a retention policy, rather than a new appliance.
Reasoning for retention: seven days of proxy logs means the investigation window closes faster than most detections open. Thirty days matches the firewall data already held and removes the current asymmetry where one dataset outlives the other by three weeks.
Reasoning for agent health: nine days of blindness on a server is the single condition that turned a routine network observation into an ambiguous one. Health monitoring is not a new capability, only a monitored one.
How to argue it: not as a wish list but as the specific reason the current alert could not be adjudicated. Frame the cost against the analyst hours already spent on 200 daily DLP alerts, and propose tuning that noise down in the same budget conversation so the team gains capacity rather than only obligations.