# SOC alert triage and incident scope Enter Harbor-17 through its first alert. Verify origin, assess service impact and separate observed facts from explanations not yet established. Original AI-assisted SecNet educational content. Fictional local examples; not a standards provider publication, endorsement or compliance evidence. Page exercises do not create account progress. Sources checked: 2026-10-21 ## Alert, finding and incident An alert is a tool-condition match, not a confirmed breach. Record source, event ID, raw-record location and ingestion time. When working from a screenshot or forwarded message, identify missing fields. “A successful sign-in was logged” is an observation; account compromise is a hypothesis; session ownership and device context are gaps. This distinction reduces both premature closure and unnecessary disruption. ## Priority and ownership Review a vendor critical label alongside business impact. Asset criticality, ongoing behavior, affected identities and reversibility affect priority. Assign case ownership and decision authority; hand over open questions and the next check time. Keep preparation and learning in view: NIST 800-61 Rev.3 is the final 2025 publication connecting incident response to CSF2.0 risk management; do not label Rev.2 current. ## Scope and visibility gaps Even if the first host appears clean, review the identity’s mail, SaaS and other-device access. Define search windows, source coverage and retention. Do not treat sensor blind spots as clean. Maintain scope as a versioned working assumption, recording rationale and new sources when it expands. Collect records for the investigation purpose without indiscriminate personal-data gathering. ## Harbor-17 first decision card The user reports a helpdesk message at09:00+03:00; the identity record shows08:05+02:00. These are06:00 and06:05UTC. Comparing local clock digits would incorrectly place sign-in before the message. The evidence desk sorts them without establishing causation. An initial decision may be to continue and obtain identity/device context, not identify an attacker. Assign ownership and a return time for missing records. ## Working sequence 1. Preserve origin and raw records. 2. Separate facts, hypotheses and gaps. 3. Prioritize against impact and ownership. 4. Map identity, device and time scope. 5. Record next evidence and handover plan. ## 1. Where is the raw source? An alert does not establish source trust or scope. Flag missing raw records in forwarded screenshots; require origin, preservation and scope evidence together. This code is a local policy model; it does not replace target/cluster testing. ### Weak implementation ```js s=>s.alertExists ``` ### Corrected implementation ```js s=>s.alertExists&&s.originVerified&&s.rawPreserved&&s.scopeKnown ``` ### Synthetic input and actual model output ```json { "before": [ { "name": "supported-case", "input": { "alertExists": true, "originVerified": true, "rawPreserved": true, "scopeKnown": true }, "expected": true, "observed": true, "matched": true }, { "name": "forward-only", "input": { "alertExists": true, "originVerified": false, "rawPreserved": false, "scopeKnown": true }, "expected": false, "observed": true, "matched": false }, { "name": "unknown-scope", "input": { "alertExists": true, "originVerified": true, "rawPreserved": true, "scopeKnown": false }, "expected": false, "observed": true, "matched": false } ], "after": [ { "name": "supported-case", "input": { "alertExists": true, "originVerified": true, "rawPreserved": true, "scopeKnown": true }, "expected": true, "observed": true, "matched": true }, { "name": "forward-only", "input": { "alertExists": true, "originVerified": false, "rawPreserved": false, "scopeKnown": true }, "expected": false, "observed": false, "matched": true }, { "name": "unknown-scope", "input": { "alertExists": true, "originVerified": true, "rawPreserved": true, "scopeKnown": false }, "expected": false, "observed": false, "matched": true } ] } ``` ## 2. The critical label A vendor label alone is not business impact. For this critical-labelled case the model requires asset impact, corroboration and ownership; actual priority policy is organization-specific. This code is a local policy model; it does not replace target/cluster testing. ### Weak implementation ```js s=>s.vendorCritical ``` ### Corrected implementation ```js s=>s.vendorCritical&&s.assetCritical&&s.impactCorroborated&&s.ownerAssigned ``` ### Synthetic input and actual model output ```json { "before": [ { "name": "supported-case", "input": { "vendorCritical": true, "assetCritical": true, "impactCorroborated": true, "ownerAssigned": true }, "expected": true, "observed": true, "matched": true }, { "name": "label-only", "input": { "vendorCritical": true, "assetCritical": false, "impactCorroborated": false, "ownerAssigned": false }, "expected": false, "observed": true, "matched": false }, { "name": "no-owner", "input": { "vendorCritical": true, "assetCritical": true, "impactCorroborated": true, "ownerAssigned": false }, "expected": false, "observed": true, "matched": false } ], "after": [ { "name": "supported-case", "input": { "vendorCritical": true, "assetCritical": true, "impactCorroborated": true, "ownerAssigned": true }, "expected": true, "observed": true, "matched": true }, { "name": "label-only", "input": { "vendorCritical": true, "assetCritical": false, "impactCorroborated": false, "ownerAssigned": false }, "expected": false, "observed": false, "matched": true }, { "name": "no-owner", "input": { "vendorCritical": true, "assetCritical": true, "impactCorroborated": true, "ownerAssigned": false }, "expected": false, "observed": false, "matched": true } ] } ``` ## 3. Beyond the first device A clean-looking first device does not close identity and related-device scope. Known coverage gaps cannot support marking the whole incident clean. This code is a local policy model; it does not replace target/cluster testing. ### Weak implementation ```js s=>s.firstHostClean ``` ### Corrected implementation ```js s=>s.firstHostClean&&s.identityReviewed&&s.relatedHostsReviewed&&s.coverageKnown ``` ### Synthetic input and actual model output ```json { "before": [ { "name": "supported-case", "input": { "firstHostClean": true, "identityReviewed": true, "relatedHostsReviewed": true, "coverageKnown": true }, "expected": true, "observed": true, "matched": true }, { "name": "one-host-only", "input": { "firstHostClean": true, "identityReviewed": false, "relatedHostsReviewed": false, "coverageKnown": true }, "expected": false, "observed": true, "matched": false }, { "name": "coverage-gap", "input": { "firstHostClean": true, "identityReviewed": true, "relatedHostsReviewed": true, "coverageKnown": false }, "expected": false, "observed": true, "matched": false } ], "after": [ { "name": "supported-case", "input": { "firstHostClean": true, "identityReviewed": true, "relatedHostsReviewed": true, "coverageKnown": true }, "expected": true, "observed": true, "matched": true }, { "name": "one-host-only", "input": { "firstHostClean": true, "identityReviewed": false, "relatedHostsReviewed": false, "coverageKnown": true }, "expected": false, "observed": false, "matched": true }, { "name": "coverage-gap", "input": { "firstHostClean": true, "identityReviewed": true, "relatedHostsReviewed": true, "coverageKnown": false }, "expected": false, "observed": false, "matched": true } ] } ``` ## Exit evidence - Versioned fact/hypothesis/gap card - Priority/handover record with source and scope ## References - [NIST SP 800-61 Rev.3 · Final April 2025](https://csrc.nist.gov/pubs/sp/800/61/r3/final) - [NIST SP 800-86 · IT forensics foundation (2006)](https://csrc.nist.gov/pubs/sp/800/86/final)