Both the app audit log and the proxy log name the same support account — how much does that corroborate?
answer
- agreement is not independence
- both inherit one identity assertion
- one witness quoted twice
- they corroborate the act, not the actor
- ask how both could fail together
basics
~20 sTwo artefacts corroborate only if they can fail independently. Both rest on the same identity assertion, so they repeat one unresolved premise: who held the credential. They do jointly support a different claim — records were rendered and bytes left.
solid answer
~50 sAgreement is not corroboration when the artefacts share a premise. The application row and the proxy entry both attribute activity to an identity that came from the same sign-on — the same session or the same agent identity on the same workstation — so a shared credential, a stolen session or an unlocked machine breaks both at once. Stacking them raises confidence in nothing about *who*. What they do add is a second claim: the records were rendered, and roughly that volume of traffic then went to an external host. Note the proxy's own limits — without interception a TLS connection appears as a CONNECT to a host with byte counts, so you get destination and size, not content. Independent corroboration would have to come from somewhere the session cannot reach: an endpoint artefact on an assigned laptop, a physical access record, an MFA approval on a device only that person holds.
go deeper
Be ready to say what a proxy log entry contains — client, destination host, byte counts, allow or block — and that with TLS the content of the traffic is not visible to it.
Explain why two records naming the same account are not two witnesses to who acted, and name the scenarios that break both at once.
Show that you test corroboration by asking what single failure would invalidate both artefacts, and that you go looking for evidence outside the session when the identity claim matters.
Own where the estate has no independent identity evidence at all, and decide whether closing that gap is worth the cost given how often cases turn on who held a credential.
## Corroboration requires independent failure modes The intuition that two agreeing sources are stronger than one is correct only when the two could have disagreed for independent reasons. If both artefacts inherit the same assumption, they are not two witnesses; they are one witness quoted twice. In an intrusion case the assumption that repeats most often is *the identity attached to the record is the human it names*. The application audit row attributes the action to an account because a session presented that account's credential. The proxy entry attributes the traffic to a user because the same sign-on, or an endpoint agent on the same workstation, told it so. Every scenario that breaks the first breaks the second in exactly the same stroke: a shared password, a token stolen from a browser, an unlocked machine, an automation given the account's credentials, an administrator impersonating a user in a support tool. So when you place the two logs side by side, the *who* is no better supported than it was with one. ## What the pair genuinely does add This is not an argument that the second log is worthless — the opposite. It supports a claim the first could not touch. The application log establishes that records were returned to a client; the proxy establishes that traffic of a compatible size went from that client to an external destination shortly afterwards. Neither alone gets near "the data left the environment"; together they make it a supportable inference, with a stated gap. Be exact about the gap. A forward proxy record typically carries the timestamp, client address, a user field if the proxy authenticates, the request method, the destination host (a full URL for plain HTTP, a `CONNECT` host and port for TLS), bytes sent and received, the user agent, and an allow-or-block action. Without TLS interception the payload is never seen, so 42 MB to a file-sharing host is *42 MB to a file-sharing host* — not "the customer records were uploaded". And the proxy only sees traffic that traversed it: a personal device on the guest network, a phone tethered, or a route that bypasses it produce nothing at all, so its silence excludes nothing either. ## What independence would actually look like To strengthen the claim about the person you need an artefact whose identity does not descend from that session: - an endpoint artefact — a file written, an application launched — on a laptop physically assigned to that individual, ideally at a time nobody else could have been at it; - a building access or on-site network record placing the person where the workstation was; - an MFA approval on a device enrolled to them, particularly a fresh one during the window rather than the one that started the session; - material outside the technical stack entirely: a message, a document, the person's own account. Each of these can fail for reasons unrelated to a stolen session, which is precisely what makes agreement between them meaningful. ## Where the error shows up in reports The usual phrasing is "confirmed across multiple sources", and it is doing real damage because it sounds like rigour. The fix is a sentence naming the shared premise: "Both records attribute the activity to the same account; neither is independent of the credential, so both are consistent with any scenario in which someone other than the account holder was using it." That sentence costs nothing, and it is the one that keeps the finding intact when the person named produces a colleague who admits knowing the password. The same test generalises past this case. Two detections firing on the same underlying log source do not corroborate each other about whether the event happened. Two vendor reports citing the same original write-up are one report. Whenever you find yourself saying "and it is confirmed by", ask what would have to be true for both artefacts to be wrong at the same time — and if the answer is a single sentence, you have one piece of evidence.
- What does the proxy entry establish on its own?That a client at that address opened a connection to that destination host and moved roughly that many bytes at that time, and that the proxy allowed it. With TLS and no interception the payload is unseen, so content is inference. The user field is usually inherited from the same sign-on or endpoint agent, so it is not an independent statement about who was at the keyboard.
- Does the proxy showing no upload mean nothing left the environment?No. A proxy sees only what traverses it. Traffic from a personal device, a tethered phone, a route that bypasses the proxy, or a channel it does not inspect leaves no entry. Its silence is evidence about coverage, and the honest statement is "no egress to an external file-sharing service was observed on the corporate proxy path", with the excluded paths named.
- Give a general test for whether two artefacts corroborate each other.Ask what single thing being false would make both wrong. If one sentence — the credential was used by someone else, the clock was wrong, both sources derive from the same upstream log — explains both failing together, they are one piece of evidence for that claim. If no single failure covers both, the agreement carries real weight.
Two newspapers running the same wire story are not two confirmations; they are one source printed twice.
saying these in an interview costs you the question
- Says confirmed across multiple sources without checking independence
- Reads a proxy byte count as evidence of what was sent
- Treats a proxy user field as placing a person at the keyboard
- Takes absence of proxy entries as proof nothing left
- Counts two detections on one log source as two witnesses