Your EDR says clean, the proxy allowed it and identity flags medium risk; your MSSP closed it — how do you decide?
answer
- verdicts are not votes
- claim, basis, window, surface
- could this control have seen it if true
- two abstentions are not a majority
- argue the basis, not the conclusion
basics
~20 sDo not count verdicts as votes. Restate each as a claim, its basis and the surface it observed, then keep only the verdicts whose surface covers the hypothesis. Two controls that never watched the behaviour are silent, not corroborating.
solid answer
~40 sI convert each console's output into claim, basis, window and observed surface. The endpoint verdict means no rule matched host telemetry — it never saw the request bodies. The proxy verdict is a policy decision about a destination category, not an opinion about maliciousness at all. The identity signal is a probabilistic claim about one sign-in and says nothing about what happened after it. Against a hypothesis of tasking carried inside a trusted platform's API, only one of the three observed anything relevant, so the majority is correlated silence and the minority verdict stands. With a co-managed estate I ask the provider for the basis and the data their console held rather than arguing the conclusion, then build one joint timeline. Here that path escalated on the minority verdict and the intrusion was confirmed.
code
json · 18 lines{
"event": "outbound API session, build-agent-07 to a collaboration SaaS domain",
"verdicts": [
{ "control": "EDR",
"verdict": "clean",
"basis": "no rule matched process, module and file telemetry",
"observed": "host activity only; not request bodies" },
{ "control": "web gateway",
"verdict": "allowed",
"basis": "destination category 'collaboration' permitted by policy",
"observed": "server name and byte counts; TLS not intercepted" },
{ "control": "identity protection",
"verdict": "medium risk sign-in",
"basis": "risk signal on one authentication",
"observed": "the sign-in; nothing after it" }
],
"...": "provider closed as benign on the first two"
}go deeper
Know that different products watch different things, and that a permitted destination or an absent alert is not the same as a finding that the activity was safe.
Practise restating a verdict as claim, basis, window and surface, and explain why a control that cannot observe the hypothesised behaviour contributes silence rather than evidence.
Show the adjudication method end to end: state the hypothesis, test each control's surface against it, escalate on the surface-covering verdict, and record non-observations explicitly so the case survives a handover.
Own the co-managed relationship: agree in advance what each party's console can see, what a closure means, and that disagreements are resolved on a joint timeline rather than by whichever team holds the ticket.
## The failure mode this question is testing When several products return verdicts on one event, the instinctive move is to tally them. Two say benign, one says risky, so it is probably benign — especially when one of the two belongs to a managed provider who has already closed the ticket. That instinct is wrong for a structural reason: **verdicts are not votes, because the voters did not all observe the same thing.** ## Step one: restate every verdict as a bounded claim Before comparing anything, rewrite each console's output as *claim + basis + window + surface*: - **Endpoint product — `clean`.** Claim: no rule or model matched the process, module and file telemetry the agent produced on that host in that window. Surface: host activity. It did not observe the contents of any encrypted request. - **Web gateway — `allowed`.** Claim: the destination's category is permitted by policy. This is a *policy decision about a destination*, not an assessment of maliciousness. A permitted category is not a finding of innocence; the control was never asked the question. - **Identity protection — `medium risk sign-in`.** Claim: a probabilistic judgment about one authentication event. It says a credential was accepted under conditions the platform found somewhat unusual. It says nothing about what the session did afterwards. Written this way, the tally collapses. Only one of the three made any claim that touches the hypothesis, and one of them — the gateway — never expressed an opinion about maliciousness at all. ## Step two: match surfaces to the hypothesis State the hypothesis explicitly: *an adversary is carrying tasking and results inside a legitimate collaboration platform's own API, from a host in our estate.* Then ask, of each control, **could it have observed this if it were true?** - Endpoint: only if the client were unusual, injected into, or spawning children. Under this hypothesis it is not. **Cannot falsify.** - Gateway: only if the destination were disallowed or the payload inspected. It is neither. **Cannot falsify.** - Identity: partially — it sees authentications to your tenant, which is why it produced the one non-benign signal. A verdict from a control that cannot observe the behaviour is **silence**. Silence does not corroborate; it does not raise or lower your confidence. So the majority here is not a majority of evidence, it is two abstentions, and the minority verdict is the only evidence in the room. ## Step three: handle the co-managed disagreement on evidence, not authority When a provider owns one of the consoles and reaches the opposite conclusion, the productive question is never "why did you close it". It is: - **What data did your console hold?** Which log sources, which window, which retention. - **What was the basis of the verdict?** Which rule, which fields, what did the analyst check. - **What could you not see?** Estate coverage gaps are the usual explanation for an honest disagreement — a host class not onboarded to their tooling, a SaaS audit trail not fed to them at all. Often both parties are right about their own data and the disagreement is entirely a visibility difference. The fix is one **joint timeline** across all three consoles plus the platform's own audit trail, with each entry carrying its source, so the two teams argue about the same object. ## Step four: decide, and record why On this event the decision was to escalate on the minority verdict. Investigation of the platform's own audit trail — which account, which authorised application, from which address — confirmed the intrusion. The console that two others contradicted was the one that had looked. Record the reasoning in the case, not just the outcome: *"escalated despite two benign verdicts; both were from controls whose surface cannot observe API-borne tasking, and are recorded as non-observations rather than clearances."* That sentence is what stops the next analyst tallying votes, and it is what you show the provider afterwards. ## When the minority is simply wrong The rule is not "always believe the outlier". It is "weight verdicts by observed surface". If the outlier is a control that also could not observe the hypothesis — a risk score fired by an unrelated condition, say — then it is noise, and the honest verdict is that **no control in the estate observed the relevant surface at all**. That is a different and more uncomfortable conclusion than benign, and it is the one that should be written down, because it names a visibility gap rather than closing a ticket.
- What do you ask the managed provider first when they have already closed the ticket?What data their console held and what the verdict was based on — sources, window, retention, and which rule or check produced it. Most honest disagreements in a co-managed estate turn out to be visibility differences rather than judgment differences, and asking for the basis surfaces that in one exchange. Arguing the conclusion first produces a defence, not information.
- When is the minority verdict simply wrong rather than right?When the outlier's surface also fails to cover the hypothesis. The rule is to weight verdicts by observed surface, not to favour outliers. If no control in the estate could have observed the behaviour, the correct finding is a visibility gap, not a clearance — and that is what belongs in the case notes.
- How do you stop the next analyst from re-running this tally?Record the two benign outputs as non-observations rather than clearances, with the surface each one covered, and put the reasoning line in the case: escalated despite two benign verdicts because neither control can observe API-borne tasking. Verdict provenance in the case note is what survives a shift change; a resolution code is not.
saying these in an interview costs you the question
- Treats the verdicts as a two-to-one vote
- Reads a permitted destination category as a finding of innocence
- Assumes a sign-in risk score covers post-authentication activity
- Escalates the disagreement with the provider before asking for their basis
- Closes the case without recording which surfaces were never observed