Scoping Operational Intelligence Requirements

Scoping Operational Intelligence Requirements

Define consumers, decisions, scope, deadlines, information needs, assumptions, collection boundaries, and review triggers for operational CTI work.

Frame the operational decision and uncertainty

Operational CTI begins with a decision that is still open. The analyst’s first task is not to collect everything associated with an incident, actor, vulnerability, or campaign. It is to identify which uncertainty matters to an accountable decision-maker, how long the decision window remains open, and what evidence could change the available action.

An operational requirement is more time-sensitive and bounded than a broad research topic. Compare:

The last formulation does not promise complete knowledge. It defines the uncertainty that must be reduced enough for a decision.

Identify the operational consumer

The consumer is the person or team that owns or materially influences the choice. During active operations, several consumers may need related but distinct answers:

Do not collapse these decisions into one vague requirement. A common evidence base can support several linked requirements, each with its own authority, deadline, and sufficient level of detail.

Write the decision as a real choice

Use an action verb: contain, search, isolate, restore, revoke, notify, disclose, prioritize, engage, monitor, or defer. Then identify the realistic options.

A decision statement should answer:

• Who owns the choice?
• Which options are actually available?
• When must one be selected?
• What is the cost of acting too broadly, too narrowly, too early, or too late?
• Which part of the choice can be reversed?
• Which evidence would cause the decision owner to choose differently?

For example, “Should we take action?” is not sufficiently defined. A better statement is:

The incident commander must decide by 14:00 whether to maintain isolation of two confirmed hosts, expand containment to related finance identities, or isolate the wider finance segment.

This exposes three options with different disruption, evidence thresholds, and reversibility.

Define the proposition before collecting evidence

A proposition is the statement the analyst will evaluate. It should be specific enough to support or challenge.

Weak proposition:

The organization is under attack.

Stronger proposition:

The archive messages, matching endpoint sequences, and later identity activity observed between 09:00 and 11:30 are parts of one coordinated malicious operation affecting Northbridge’s finance environment.

The stronger proposition identifies the activity, time window, environment, and claimed relationship. It can be compared against alternatives such as:

• an authorized deployment;
• unrelated malicious events;
• benign activity coinciding with a malicious message;
• a security exercise;
• duplicated or misaligned telemetry;
• a mixture of several causes.

The operational requirement should not assume the proposition is true. It asks the analyst to assess it.

Bound the scope explicitly

Operational investigations expand easily because every finding can lead to another system, account, domain, partner, or time period. Define scope along several dimensions:

Scope is a starting boundary, not a permanent wall. Define evidence-based expansion triggers. For example, a matching process sequence on another host may expand endpoint scope, while a merely shared cloud address may not.

Establish the information cutoff

An operational assessment represents evidence available up to a stated time. Record the information cutoff separately from the publication time.

This assessment considers evidence collected and validated through 13:20 UTC. It was published at 13:45 UTC.

The difference matters. Evidence may arrive during drafting or approval. Consumers need to know whether a new event is included in the judgment.

Also define:

• the event period under assessment;
• the next planned update time;
• events that trigger an immediate update;
• the conditions under which the requirement closes or changes.

Set a useful sufficiency threshold

Operational intelligence is often delivered before all evidence is available. Define what “sufficient for decision” means.

Examples:

• enough evidence to distinguish a common cause from unrelated events;
• adequate coverage to state which systems are confirmed, suspected, or unknown;
• a tested behavioral pattern capable of finding related activity;
• a clear alternative explanation and the evidence needed to validate it;
• current implications and proportional options with escalation triggers.

Sufficiency does not mean certainty. It means the consumer can make a defensible choice with remaining uncertainty visible.

Worked scenario: Project Lantern

This course uses a fictional organization, Northbridge Services, and an operational investigation named Project Lantern.

At 09:06 UTC, three finance users receive similarly constructed archive attachments. Two workstations later show an unusual interpreter launching a script from an extracted directory. One host creates a scheduled task and accesses browser credential stores. At 09:31, a payment-support account authenticates from a new device. Endpoint coverage is absent on the third workstation, and an approved administration tool could explain part of the process sequence.

The incident commander asks: “How big is this, and should we isolate finance?”

The analyst reframes the request:

Primary operational requirement: For the incident commander to decide by 14:00 whether to broaden containment beyond two finance workstations, assess whether the observed email, endpoint, and identity activity represents one coordinated malicious operation; estimate confirmed, suspected, and unknown scope; compare authorized activity and telemetry error as alternatives; and identify escalation or narrowing triggers.

Linked requirements include:

• For detection engineering to decide by 12:30 which search to run across finance endpoints, identify the most diagnostic behavioral sequence, required telemetry, and expected benign matches.
• For the identity lead to decide by 13:00 which sessions or accounts require action, assess whether the new-device sign-in is plausibly related to the workstation activity and state the evidence needed for stronger linkage.

The requirements use the same investigation but serve different decisions.

Record initial assumptions and constraints

At acceptance, record assumptions that affect feasibility or interpretation:

• relevant email records are complete for the defined window;
• endpoint clocks are comparable within an acceptable tolerance;
• identity records cover the payment-support service;
• the incident commander can authorize the listed containment options;
• legal and privacy authority exists for the bounded collection;
• software-owner confirmation can be obtained before the decision deadline.

Also record constraints:

• one endpoint lacks telemetry;
• broad finance isolation would interrupt payment processing;
• partner information cannot be redistributed without approval;
• volatile evidence may be lost if hosts are restarted;
• analyst capacity limits how many adjacent leads can be investigated before 14:00.

Constraints are part of the intelligence problem. They shape which answer is possible and which option is proportionate.

Requirement acceptance record

Use a compact record:

Common framing failures

• Artifact-led scope: The investigation follows every related domain, address, or hash without a decision test.
• Actor-led framing: The team asks who did it before establishing what occurred and what decision attribution would change.
• Undefined consumer: Products are written for “leadership” or “the SOC” without an accountable decision owner.
• No deadline: Analysis expands while the decision window closes.
• Confirmation framing: The requirement presumes maliciousness and asks only for supporting evidence.
• Scope by anxiety: Every unknown becomes justification for organization-wide action.
• False completeness: Missing visibility is omitted from the requirement and later mistaken for clean scope.
• Unreachable sufficiency: The requirement demands certainty that available evidence cannot provide.

Key takeaways

• Operational CTI starts with an open decision, not an interesting artifact or actor.
• Name the consumer, options, deadline, proposition, scope, information cutoff, and sufficiency threshold.
• State plausible benign, malicious, telemetry-error, and mixed explanations before collection hardens one story.
• Use linked requirements for different consumers rather than one product that tries to answer every operational question.
• Treat assumptions, constraints, and visibility gaps as part of the requirement.
• Define evidence-based expansion, narrowing, update, and closure triggers.

Analyst habit: Before accepting operational work, complete this sentence: By [time], [consumer] must choose among [options], and this assessment will change that choice by clarifying [specific uncertainty].

Decompose, prioritize, and control the requirement

Once the operational decision is framed, decompose the primary requirement into questions that can guide evidence collection and analysis. The goal is traceability: every task should support a proposition that could affect the consumer’s choice.

For Project Lantern, the primary requirement can be decomposed into four decision-relevant lines of inquiry:

1. Common cause: Do the email, endpoint, and identity events belong to one coordinated operation?
2. Current scope: Which hosts, accounts, services, and users are confirmed, suspected, unaffected within adequate visibility, or unknown?
3. Likely progression: Which behaviors have occurred, which may occur next, and where can defenders intervene?
4. Alternative explanations: Could authorized administration, testing, telemetry error, coincidence, or mixed causes explain some or all observations?

Each line becomes specific questions and information needs.

Create a decision-to-collection chain

Maintain a visible chain:

Decision → requirement → proposition → information need → collection task → evidence → judgment → implication → action or update

A task that cannot be traced upward should be challenged. A judgment that cannot be traced downward to evidence should be weakened, revised, or removed.

For example:

This chain shows why the task matters and how its outcome could change action.

Prioritize by decision value

Operational time is limited. Prioritize information needs using explicit criteria:

• Discriminating power: Would the evidence favor one plausible explanation over another?
• Decision impact: Could it change containment, restoration, notification, or another open choice?
• Urgency: Will the evidence arrive before the decision window closes?
• Feasibility: Is a suitable source available with lawful authority and adequate quality?
• Volatility: Could the evidence disappear or change if collection waits?
• Coverage: Will the source address the relevant entities and time period?
• Risk: Could collection harm systems, people, privacy, investigations, or partner trust?
• Cost: Which other work will be delayed?
• Uniqueness: Does another task already answer the question?

A simple priority table is sufficient:

Priority is not the same as analytic interest. The infrastructure research and attribution questions may become relevant later, but should not displace evidence needed for the open decision.

Write collection tasks precisely

A collection task should specify:

• the proposition or information need it supports;
• the exact source and responsible owner;
• the entities, fields, and time window;
• collection method and authority;
• expected output and format;
• deadline;
• provenance and handling requirements;
• validation criteria;
• stop, revision, and escalation conditions.

Weak task:

Check endpoint logs for anything suspicious.

Stronger task:

Detection engineering will search finance endpoints from 08:30 to 13:00 UTC for an office or archive process spawning the observed interpreter command, followed within ten minutes by script execution or scheduled-task creation. Return host, user, process ancestry, command line, timestamps, raw event references, telemetry coverage, and known benign matches by 13:15. Do not treat partial matches as confirmed related activity.

The stronger task preserves the hypothesis, scope, sequence, owner, output, deadline, evidence references, and interpretation boundary.

Separate collection modes

Operational investigations use several collection modes:

Do not substitute enrichment for direct evidence. A domain’s reputation may add context but cannot establish what occurred on a host.

Define evidence thresholds by action

Different actions require different support. Record the threshold before results arrive.

An indicator received from a trusted partner may justify a search, but not automatic organization-wide blocking. The intended action determines the required support.

Control scope expansion

Define expansion triggers before every weak relationship becomes part of the incident.

Suitable triggers include:

• a full or materially similar behavior sequence on another host;
• a directly related account or session event;
• shared payload lineage with compatible timing and delivery;
• an infrastructure relationship active during the event window and supported by behavior;
• new evidence connecting a service, partner, or business process to the assessed operation.

Weak triggers include:

• one shared cloud address without temporal or behavioral context;
• use of common administration software;
• a generic framework technique shared by many actors;
• an actor label assigned by one external report;
• a partial match expected in normal operations.

Also define narrowing triggers:

• validated authorized activity explains the complete sequence;
• preserved raw evidence shows duplication or parsing error;
• adequate coverage finds no related behavior outside confirmed entities;
• volatile infrastructure has changed ownership and no longer supports current action;
• an initial association cannot be corroborated within the decision window.

Scope should respond to evidence in both directions.

Maintain an operational requirement board

A compact board helps teams coordinate without losing reasoning:

Update the board when evidence changes priority, feasibility, or the decision. Record why a task was added, deferred, revised, or closed.

Plan preliminary and final-enough answers

Operational requirements often need staged delivery:

• Initial notification: Confirm the requirement, current facts, immediate risks, collection underway, and next update time.
• Preliminary assessment: Give the leading explanation, current scope, confidence, alternatives, options, and priority gaps.
• Decision update: Address the open choice with evidence received by the stated cutoff.
• Revised assessment: Incorporate material evidence and explain changes.
• Closure or transition: Record the last operational judgment, remaining gaps, long-term actions, and any new strategic or detection requirements.

“Final” rarely means every question is answered. It means the operational requirement is closed, superseded, or transitioned with remaining uncertainty documented.

Define stopping and transition rules

Close, pause, or transfer a requirement when:

• the decision has been made and no immediate update could change it;
• adequate evidence supports the chosen operational scope;
• the relevant time window has passed;
• the question cannot be answered with available or authorized sources;
• new evidence changes the problem enough to require a revised requirement;
• the work becomes long-term campaign, detection, architecture, legal, or strategic analysis;
• expected value falls below the cost or risk of further collection.

Stopping does not mean deleting the evidence or forgetting the question. Preserve the record, define review triggers, and open a new requirement if another decision emerges.

Project Lantern collection plan

For the 14:00 containment decision, the team prioritizes:

1. Preserve and analyze the extracted script to test malicious versus authorized behavior.
2. Validate authorized deployment status with the software owner and signed-package records.
3. Run a bounded behavioral search across finance endpoints with explicit coverage reporting.
4. Review identity sessions and devices for a defensible connection to the host activity.
5. Validate raw event uniqueness and clock assumptions to reduce telemetry-error risk.

The team defers broad historical infrastructure research and named-actor attribution. Those questions do not currently change containment.

The plan records immediate update triggers:

• matching behavior on another host;
• confirmed credential or token use;
• evidence of critical-service access;
• validated authorized activity explaining the sequence;
• proof that records were duplicated or misparsed.

Requirement quality check

Before collection begins, confirm:

• A named consumer owns a real operational decision.
• The decision options and deadline are explicit.
• The proposition and plausible alternatives are testable.
• Scope and exclusions cover entities, behavior, time, environment, and evidence.
• Information needs trace to the requirement and decision.
• Collection tasks specify owners, sources, fields, windows, outputs, and deadlines.
• Evidence thresholds reflect the intended action.
• Authority, privacy, safety, handling, and preservation constraints are addressed.
• Expansion and narrowing triggers are evidence-based.
• Preliminary delivery, information cutoff, and update cadence are planned.
• Stopping, transition, and closure rules are visible.

Key takeaways

• Decompose operational requirements into propositions, information needs, and tasks that can affect a decision.
• Prioritize discriminating, timely, feasible, volatile, and decision-relevant evidence.
• Write bounded collection tasks rather than generic requests for more data.
• Define evidence thresholds according to the intended operational use.
• Control scope with explicit expansion and narrowing triggers.
• Stage preliminary and revised answers instead of waiting for impossible completeness.
• Close or transition work when further collection no longer serves the current decision.

Analyst habit: For every collection task, write two possible outcomes and how each would change the decision. If neither outcome matters, defer the task.