At a retailer, a tap captured a file transfer, and NetFlow shows the same 5-tuple with byte counts for that transfer. Which source can yield the file itself?
Select an answer to reveal the explanation.
Short Explanation
A shipping label can tell you the weight without showing the contents. You need the tap's saved packets to recover the file, because the flow record kept the summary and the byte counts. The trap is expecting a flow record, a severity rating, or an inventory row to hold the file.
Full Explanation
A tap copies frames, so an unencrypted transfer can still be read from the saved packets. NetFlow for the same 5-tuple can confirm the two addresses, the ports, the protocol, and how many bytes moved, and it does not store the payload. The source that yields the file is The tap's packet capture, where the transferred file still sits in the payload. The NetFlow record that lists the same 5-tuple and byte counts but holds no file body is useful for scope and size, and it cannot be carved into the downloaded object. The alert severity value, treated as if that rating stored the downloaded file confuses a judgment score with content, and a rating is not the file. The asset inventory row for the register, treated as if that row stored the file names an asset and does not contain the transfer. Exam caveat: byte counts in a flow record describe volume, and they are not a substitute for the payload when the question is the file itself. Operational check: open the tap's capture, limit the view to that 5-tuple, and confirm the file bytes are present before you tell anyone the object was recovered.