skip to content

How do you turn a priority intelligence requirement into a collection plan when an MSSP runs part of your SOC?

level: middleimportance: should knowfreq 44%

answer

  1. requirement, sub-question, task
  2. four columns per line
  3. who collects it, by name
  4. the provider does only what is contracted
  5. gaps are written down, not skipped

basics

~20 s

Decompose the requirement into answerable sub-questions, then give each one a source, a named collector, a cadence and a definition of answered. With an MSSP, every line has to say who collects it - you or them - and lines nobody can collect are recorded as collection gaps.

solid answer

~50 s

Start from the requirement's decision, then break it into specific information requirements that a source could actually answer. For a requirement about contractor credential exposure that is: do our contractor domains appear in the stealer-log listings our broker sells; for any hit, does the account exist in the identity provider and when did it last authenticate successfully; does it hold remote-access entitlement. Each line then gets four columns - source, named collector, cadence, and what counts as answered. In a co-managed SOC the collector column is the one that fails silently: the MSSP collects only what their contract scopes, so 'the MSSP will check the sign-in logs' is a hope unless it is a tasked, dated line they have accepted. Anything no source can answer goes into a gaps list to be bought, tasked internally, or acknowledged as a limit on the answer you will give.

go deeper

for a junior

Know that a requirement is broken into smaller answerable questions, and that each one needs a source and someone responsible for getting it. Be able to sketch that as a simple table.

for a middle

Explain the decomposition mechanics: sub-question, source, collector, cadence, answered-when, and why answer criteria are agreed before the reporting arrives.

for a senior

Demonstrate handling a co-managed estate: what the provider is contracted to collect, what silently does not get done, and how gaps bound the confidence in the answer you hand the consumer.

for a principal

Own the economics - collection costs money and contracted hours. Be ready to explain how you cancel standing collection that no live requirement justifies and redirect it.

## From requirement to plan A priority intelligence requirement is written at the decision level and is deliberately not collectable as written. The collection plan is where it becomes work. The standard decomposition is: **requirement** (the consumer's question) into **specific information requirements** (sub-questions a source could answer) into **collection tasks** (who does what, against which source, by when). ### Worked example Requirement: *do contractor accounts appear in criminal-market stealer-log listings, and could any of that exposure still be used against us - for the head of plant operations, deciding by quarter-end whether to force re-enrolment for the whole contractor population.* Sub-questions: | Sub-question | Source | Collector | Cadence | Answered when | |---|---|---|---|---| | Do our mail domains appear in listings the broker sells? | Broker feed | Intel vendor, via us | Weekly | Named accounts returned, or a clean sweep for the period | | Do those accounts exist and are they enabled? | Identity provider directory | In-house identity team | On hit | Each account resolved to enabled, disabled or unknown | | When did each last authenticate successfully, and from where? | Identity provider sign-in records | MSSP (contracted query) | On hit, 24h SLA | Sign-in history returned for the exposure window | | Do those accounts carry remote-access entitlement? | Entitlement review export | In-house identity team | On hit | Entitlement listed per account | ## The four columns, and why each exists - **Source.** Names the record set, not a tool. 'Sign-in records for the affected accounts' beats 'the SIEM'. - **Named collector.** A team or a person, and in a co-managed SOC, explicitly one side of the line. This is the column that quietly fails: work assumed to sit with the provider that their contract never scoped simply never happens, and the requirement comes back to the consumer half-answered with no one at fault. - **Cadence.** Standing weekly sweep, or triggered on a hit. Cadence is what stops a plan degenerating into a one-off report. - **Answered when.** Written before collection begins, because after the reporting arrives everyone's definition of enough shifts to match what they happened to get. ## The gaps ledger Some sub-questions have no source. The contractor laptops belong to the contractor firms, so there is no endpoint telemetry to ask what the infostealer took, and the identity provider will not tell you whether a given session was replayed from a stolen cookie or typed by the person. Writing those down as gaps does three things: it bounds the confidence of the answer you eventually give the consumer, it creates a shopping list (buy the feed, extend the MSSP contract, require contractor devices to enrol), and it stops the same discovery being re-made every quarter. ## Interpreting what comes back The plan must not promise more than the sources can give. A successful sign-in record proves a credential was accepted, not that the account holder was present - which is exactly why stolen session cookies are hard here. A listing proves a seller's claim. Together, though, they support a decision: contractor accounts appearing in listings *and* showing successful authentication from unfamiliar sources in the same window is enough to argue for forced re-enrolment, and the requirement can be closed with a stated confidence and its gaps. ## Keeping the plan alive The plan is reviewed with the requirement. When the decision date passes, unfinished lines are either dropped or re-tasked against the next requirement, and standing collection that no live requirement justifies is cancelled - in a co-managed arrangement that also means telling the provider to stop, because a collection task nobody needs still consumes contracted hours you would rather spend on a requirement someone owes a decision on. ## Common failure modes - A plan that lists tools instead of questions, so nobody can tell whether it was executed. - Every line assigned to 'the SOC', which in a co-managed estate is not a collector. - No answered-when column, so the requirement is declared satisfied by the arrival of a report. - Gaps quietly omitted, so the consumer is given a confident answer built on collection that never existed.

  • What do you do with a sub-question no available source can answer?
    Record it as a collection gap rather than dropping it. Then choose: buy or task new collection, substitute a weaker proxy and say so, or accept the gap and lower the confidence you attach to the final judgement. The one unacceptable option is presenting the answer as if the gap were not there.
  • How do you stop a collection plan turning into a standing report subscription?
    Tie every standing line to a live requirement with a decision date, and cancel the line when the requirement closes. Review the plan alongside the requirements each quarter and ask which decision each recurring collection task fed. Tasks that cannot name one are cancelled, including contracted ones.

saying these in an interview costs you the question

  • Assigns every line to 'the SOC' with no named collector
  • Lists tools rather than the questions to answer
  • Assumes the provider collects anything not in their contract
  • Omits gaps and answers with unearned confidence
  • Has no definition of answered before collection starts

context

resolving links…