A secure web gateway sits on staff egress. Leadership asks which clerk visited a phishing lure URL. Why do proxy or Web logs beat raw NetFlow alone?
Select an answer to reveal the explanation.
Short Explanation
NetFlow is the highway sensor: who talked to which IP on which port. The proxy is the street-address book—it saw the actual lure URL and often the clerk's identity.
Full Explanation
When leadership asks which clerk visited a phishing lure URL, proxy or secure web gateway logs beat raw NetFlow because they carry the URL and often the authenticated user, while NetFlow typically retains only connection five-tuples such as addresses, ports, protocol, and bytes. On staff egress behind a secure web gateway, the proxy is purpose-built to answer browsing-identity questions that flow metadata cannot resolve for a municipal investigation.
Claiming NetFlow always stores the full URL and mailbox UPN fails by capability—classic flow records lack URL and usually lack user identity, so the proxy cannot be ignored for this question. Saying proxy logs cannot be CIM-mapped so only NetFlow can answer browsing questions fails factually; Web and proxy data are routinely CIM-mapped and feed the Web data model. Asserting lure URLs appear only in SCADA historian tags invents an OT source for an IT web-phishing question and abandons the gateway that actually saw the click.
Exam caveat: URL-and-user questions point to proxy or Web logs; five-tuple questions point to firewall or NetFlow. Do not invert their strengths on the exam.
Operational check: search proxy or Web logs for the lure URL and clerk identity, confirm time and allow-or-block action, then use NetFlow only to validate volume or secondary paths that may have bypassed the gateway.