Lab 02 Security Alert Triage & Prioritization

Mission Overview

Welcome to Lab 02 — Security Alert Triage & Prioritization.

In Lab 01, you built the SOC environment, validated telemetry, created case-management structures, normalized timestamps, and prepared your evidence process.

Now you begin the first real SOC analyst workflow:

Triage.

A SOC analyst may receive dozens or hundreds of alerts in a shift.

The goal is not to investigate every alert equally.

The goal is to determine:

• which alerts are benign

• which alerts are false positives

• which alerts are duplicates

• which alerts require deeper investigation

• which alerts involve critical assets

• which alerts involve privileged accounts

• which alerts require escalation

• which alerts can be safely closed

Mission Goal: Review a realistic SOC alert queue, enrich each alert with asset and identity context, validate supporting telemetry, assign priority and confidence, determine disposition, and document clear escalation decisions.

Mission Information

Item	Details
Difficulty	Beginner–Intermediate
Estimated Time	90–120 minutes
Primary Skill	Security Alert Triage
Secondary Skill	Alert Prioritization
Environment	GoHackersCloud SOC Analyst Lab
Input	Alert queue + supporting training logs
Primary Outcome	Alert Triage & Prioritization Register
Safety Level	Authorized Training Evidence Only

Learning Objectives

By completing this lab, you will be able to:

• understand alert triage

• interpret alert metadata

• enrich alerts with asset context

• enrich alerts with identity context

• distinguish severity from priority

• distinguish confidence from severity

• identify duplicate alerts

• identify false positives

• identify expected activity

• identify suspicious activity

• recognize potentially serious incidents

• validate an alert using supporting telemetry

• determine when deeper investigation is required

• determine when escalation is required

• document triage decisions

• create a consistent alert disposition

• communicate analyst reasoning clearly

SOC Triage Methodology

Use:

Alert → Context → Validate → Prioritize → Investigate / Close / Escalate

Conceptually:

Incoming Alert
      │
      ▼
Review Metadata
      │
      ▼
Asset Context
      │
      ▼
Identity Context
      │
      ▼
Supporting Evidence
      │
      ▼
Is Alert Valid?
   ┌──┼─────────────┐
   │  │             │
   ▼  ▼             ▼
False Expected    Suspicious
Positive Activity    │
   │     │           ▼
 Close  Close    Prioritize
                     │
              ┌──────┴──────┐
              ▼             ▼
         Investigate     Escalate

The core principle is:

An alert is a signal that something deserves attention—not proof that an incident occurred.

Part 1 — Understand Alert Triage

Alert triage answers three immediate questions:

1. Is the alert valid?

2. How important is it?

3. What should happen next?

A weak analyst asks:

“Is this alert High severity?”

A stronger analyst asks:

“Does this alert represent meaningful risk in this specific environment?”

Part 2 — Review the Alert Queue

For this lab, assume the SOC receives the following simulated queue:

Alert ID	Alert	Initial Severity	Asset
ALT-001	Multiple Failed Logins	Medium	WIN01
ALT-002	Malware Detection	High	WIN02
ALT-003	DNS Query to Suspicious Domain	Medium	WIN01
ALT-004	Administrative Login	Medium	SRV01
ALT-005	Port Scan Detected	Low	FW01
ALT-006	Multiple Failed Logins	Medium	WIN01
ALT-007	PowerShell Execution	High	WIN03
ALT-008	SMB Access to File Share	Low	FILE01

Your job is not to assume any of these are malicious.

Part 3 — Create the Lab Workspace

Create:

SOC-Labs/
└── Lab-02/
    ├── 01-Scope/
    ├── 02-Alert-Queue/
    ├── 03-Asset-Context/
    ├── 04-Identity-Context/
    ├── 05-Supporting-Evidence/
    ├── 06-Triage/
    ├── 07-Duplicates/
    ├── 08-False-Positives/
    ├── 09-Escalations/
    ├── 10-Screenshots/
    ├── 11-Case-Notes/
    └── 12-Report/

Create:

Lab-02-Security-Alert-Triage-Prioritization.md

Part 4 — Create the Triage Register

Use:

Alert ID	Severity	Asset Criticality	Confidence	Priority	Disposition
ALT-001	Medium	Medium
ALT-002	High	High
ALT-003	Medium	Medium

This becomes the central artifact for the lab.

Part 5 — Understand Alert Metadata

For each alert, identify:

Alert ID

Alert Name

Timestamp

Source Tool

Source Host

Destination Host

User

IP Address

Severity

Rule / Detection Name

Raw Event Reference

If a field is missing, document:

Unknown

Do not invent values.

Part 6 — Review Alert Severity

Initial alert severity may be:

Critical
High
Medium
Low
Informational

Severity usually reflects the detection rule.

It does not necessarily reflect the actual business risk.

For example:

High-Severity Malware Alert

on an isolated test workstation may be less important than:

Medium-Severity Privileged Login Alert

on a domain controller.

Part 7 — Understand Alert Priority

Priority should consider:

Alert Severity + Asset Criticality + Identity Privilege + Evidence Confidence + Potential Impact

Use:

P1 — Immediate
P2 — High
P3 — Medium
P4 — Low

Part 8 — Distinguish Severity from Priority

Example:

Alert Severity:
Medium

Asset:
Critical database server

User:
Privileged administrator

Priority:
P1 / P2

Another:

Alert Severity:
High

Asset:
Disposable test endpoint

Evidence:
Known approved software

Priority:
P4

Always distinguish:

Severity
   ≠
Priority

Part 9 — Review Asset Context

Import the Asset Register from Lab 01.

For each alert ask:

What system is involved?

What is its role?

How critical is it?

Is it user-facing?

Is it administrative?

Does it store sensitive data?

Build:

Alert	Asset	Role	Criticality
ALT-001	WIN01	User workstation	Medium
ALT-002	WIN02	Finance workstation	High
ALT-004	SRV01	Production server	High

Part 10 — Review Identity Context

For user-related alerts ask:

Which account?

Is it privileged?

Is it a service account?

Is it a normal employee account?

Is the account expected on this host?

Does the login time match normal activity?

Build:

Alert	User	Type	Privileged	Expected
ALT-001	jdoe	Standard	No	Yes
ALT-004	admin01	Admin	Yes	Review
ALT-008	svc-file	Service	Limited	Yes

Part 11 — Understand Baseline Context

An activity can be suspicious only relative to expected behavior.

Ask:

Does this user normally access this system?

Does this service normally run here?

Does this host normally generate this traffic?

Is this event expected at this time?

Example:

PowerShell on administrator workstation

may be normal.

But:

PowerShell on kiosk endpoint

may deserve more attention.

Part 12 — Review ALT-001 — Multiple Failed Logins

Alert:

ALT-001

Multiple Failed Logins

User:
jdoe

Asset:
WIN01

Source:
10.10.20.15

Attempts:
5

Severity:
Medium

Initial question:

Why did authentication fail?

Do not immediately conclude password attack.

Part 13 — Correlate Authentication Evidence

Search supporting authentication logs around the alert timestamp.

Look for:

• number of failures

• source host

• username

• successful login afterward

• account lockout

• other targeted accounts

• unusual source

Example evidence:

09:10:01 Failed login — jdoe
09:10:04 Failed login — jdoe
09:10:08 Failed login — jdoe
09:10:12 Failed login — jdoe
09:10:16 Failed login — jdoe
09:10:40 Successful login — jdoe

Part 14 — Interpret the Pattern

Possible explanations include:

• user mistyped password

• cached credentials

• application using old password

• automated process

• password spraying

• brute-force activity

Do not choose one without supporting evidence.

Part 15 — Triage ALT-001

Example:

Alert:
ALT-001

Observation:
Five failed logins from the user's normal workstation followed by
a successful login.

Asset:
Standard workstation

User:
Standard account

Other Accounts Targeted:
No

Source:
Expected workstation

Confidence:
High

Disposition:
Expected User Authentication Error

Priority:
P4

Escalation:
No

Part 16 — Review ALT-002 — Malware Detection

Alert:

ALT-002

Malware Detection

Asset:
WIN02

User:
finance-user

Severity:
High

Action:
Quarantined

Do not conclude:

Finance computer compromised

First validate:

• what file was detected

• did it execute

• was it blocked

• was it quarantined

• did the process run

• did the host connect externally

• are other alerts present

Part 17 — Review Supporting Endpoint Evidence

Example:

File:
invoice_viewer.exe

Hash:
[training hash]

Detection:
Malicious test sample

Action:
Blocked before execution

Process Created:
No

Outbound Connection:
No

Part 18 — Triage ALT-002

Example:

Disposition:
Security Event — Prevention Successful

Priority:
P3

Escalation:
No immediate incident escalation

Recommended Action:
Review source of downloaded file and verify no related activity.

Confidence:
High

Important:

Malware Detected
     ≠
Malware Executed

Part 19 — Review ALT-003 — Suspicious DNS Query

Alert:

ALT-003

Suspicious Domain Query

Client:
WIN01

Domain:
update-training.example

Severity:
Medium

Investigate:

• which process initiated the request if available

• how many queries occurred

• whether other hosts queried it

• whether domain is part of approved training

• whether web connection followed

• threat-intelligence context

Part 20 — Avoid Over-Reliance on IOC Reputation

If a reputation source marks a domain suspicious:

IOC Match

does not prove:

Compromise

Local evidence remains critical.

Part 21 — Review ALT-004 — Administrative Login

Example:

Alert:
Privileged Authentication

User:
admin01

Host:
SRV01

Time:
02:15

Severity:
Medium

This could be much more important than its initial severity suggests.

Ask:

• was activity expected?

• was there a maintenance window?

• is admin01 authorized for SRV01?

• where did login originate?

• was MFA used if available?

• what occurred after login?

Part 22 — Enrich with Change/Maintenance Context

Suppose the lab provides:

Maintenance Window:
02:00–03:00

Engineer:
admin01

Target:
SRV01

Then the alert likely represents expected activity.

Disposition:

Expected Administrative Activity

Part 23 — When the Same Alert Becomes High Priority

If:

No maintenance window
Unknown source IP
Privileged user
Critical server
02:15

then priority may become:

P1 / P2

The alert itself did not change.

The context changed.

Part 24 — Review ALT-005 — Port Scan Detected

Alert:

Source:
SOC01

Destination:
Lab Servers

Alert:
Port Scan

Severity:
Low

Check:

• is SOC01 the authorized security-testing system?

• did a lab activity occur?

• was the traffic expected?

If yes:

Disposition:
Expected Security Testing Activity

This is a classic false-positive/expected-activity scenario.

Part 25 — Distinguish False Positive from Expected Activity

These are related but not identical.

False Positive

Detection logic incorrectly interpreted benign activity as malicious.

Expected Activity

Detection correctly identified an activity, but that activity was authorized.

Example:

Port scan detected during approved security test

The detection is accurate.

The activity is simply authorized.

Part 26 — Review ALT-006 — Duplicate Failed Login Alert

Suppose ALT-006 contains the same:

• user

• source

• host

• time window

• detection sequence

as ALT-001.

Classify:

Duplicate Alert

Link it to:

Primary Alert:
ALT-001

Part 27 — Create the Duplicate Register

Duplicate	Primary Alert	Reason
ALT-006	ALT-001	Same user/source/time sequence

Do not investigate duplicates as independent incidents unless they contain new evidence.

Part 28 — Review ALT-007 — PowerShell Execution

Alert:

Host:
WIN03

User:
helpdesk01

Process:
powershell.exe

Severity:
High

Do not conclude malicious PowerShell usage.

PowerShell is commonly used by:

• administrators

• support teams

• automation

• software-management systems

Part 29 — Validate Process Context

Look for:

Parent process

Command line

User

Host role

Time

Network connection

Child processes

Signed script / approved path if supplied

Example:

User:
helpdesk01

Command:
Approved inventory collection script

Parent:
Management agent

Network:
Internal management server

Change Ticket:
CHG-2026-124

Disposition:

Expected Administrative Automation

Part 30 — Review ALT-008 — SMB Access

Alert:

User:
finance-user

Destination:
FILE01

Share:
Finance

Severity:
Low

Ask:

• is the user in Finance?

• is access expected?

• was the user authenticated?

• did the user access unusual content?

• was this outside normal hours?

If normal:

Expected Activity

Part 31 — Build an Alert Context Worksheet

For every alert complete:

ALERT ID:

Alert Name:

Initial Severity:

Timestamp:

Asset:

Asset Criticality:

User:

User Privilege:

Source IP:

Destination IP:

Expected Behavior:

Supporting Evidence:

Related Alerts:

Duplicate:
Yes / No

Known Change / Maintenance:
Yes / No

Threat Intelligence Relevant:
Yes / No

Evidence Confidence:

Priority:

Disposition:

Escalation:
Yes / No

Analyst Notes:

Part 32 — Understand Triage Evidence Depth

Triage is not a complete incident investigation.

The goal is to gather enough evidence to make the next decision.

Use:

Minimum Evidence
      ↓
Confident Decision

Do not spend 90 minutes proving that an obviously authorized backup job is legitimate.

Part 33 — Use Time-Bounded Triage

In a real SOC, triage is time-sensitive.

A practical training goal:

Simple Alert:
5–10 minutes

Moderate Alert:
10–20 minutes

Complex / High-Priority:
Escalate for full investigation

Triage should prevent the queue from becoming a backlog.

Part 34 — Identify Related Alerts

Alerts may belong to the same activity.

Example:

ALT-011 Failed Login
ALT-012 Successful Login
ALT-013 PowerShell
ALT-014 DNS Query

They may form one investigation.

Create:

Alert	Related Case
ALT-011	CASE-005
ALT-012	CASE-005
ALT-013	CASE-005

Part 35 — Build the Alert Correlation Register

Alert	User	Host	Time	Related

Look for common:

• user

• host

• source IP

• destination

• time range

• IOC

Part 36 — Understand Alert Clustering

Multiple alerts may describe one story.

Failed Login
     ↓
Successful Login
     ↓
PowerShell
     ↓
Suspicious DNS

This is much more significant than four isolated alert cards.

Part 37 — Establish Triage Dispositions

Use consistent dispositions:

Expected Activity

Benign

False Positive

Duplicate

Suspicious — Investigate

Potential Incident

Confirmed Incident

Escalated

Inconclusive

Do not create vague statuses like:

Looks okay

Part 38 — Expected Activity

Use when:

• activity occurred

• detection is technically accurate

• activity is authorized and expected

Example:

Approved administrator login

Part 39 — Benign

Use when activity is harmless and does not represent a relevant security concern.

Example:

Normal employee file access

Part 40 — False Positive

Use when alert logic incorrectly flags benign data.

Example:

Known signed business application incorrectly classified by rule

Part 41 — Suspicious — Investigate

Use when evidence is insufficient for an incident decision but activity deserves deeper analysis.

Example:

Admin login from unexpected source

Part 42 — Potential Incident

Use when multiple pieces of evidence indicate possible security impact but confirmation remains incomplete.

Part 43 — Confirmed Incident

Use only when evidence supports malicious or policy-violating activity.

Do not use:

Confirmed Incident

simply because the alert is High severity.

Part 44 — Inconclusive

Use when:

• telemetry is missing

• context is unavailable

• evidence conflicts

• required logs are delayed

Document exactly what is missing.

Part 45 — Determine Confidence

Use:

High Confidence

Multiple reliable evidence sources agree.

Medium Confidence

Strong evidence exists but some uncertainty remains.

Low Confidence

Evidence is limited or indirect.

Part 46 — Build the Priority Model

Use four levels:

P1 — Immediate

Examples:

• confirmed malicious activity on critical system

• privileged identity compromise indicators

• multiple systems affected

• active high-impact security incident

P2 — High

Examples:

• strong suspicious activity

• privileged account anomaly

• high-value asset involvement

• possible malware execution

P3 — Medium

Examples:

• suspicious but limited event

• no confirmed impact

• standard asset

• further investigation warranted

P4 — Low

Examples:

• expected activity

• false positive

• duplicate

• low-risk observation

Part 47 — Priority Decision Matrix

Condition	P1	P2	P3	P4
Critical asset	✓	✓
Privileged account	✓	✓
Confirmed malicious activity	✓
Suspicious, unconfirmed		✓	✓
Authorized activity				✓
Duplicate				✓

This is a guide, not an absolute formula.

Part 48 — Consider Asset Criticality

A medium alert involving:

Payment Database

may outrank a high alert involving:

Disposable Training Workstation

Context controls prioritization.

Part 49 — Consider Identity Privilege

Escalate priority when:

• domain administrator

• server administrator

• cloud administrator

• privileged service account

• sensitive application administrator

is involved unexpectedly.

Part 50 — Consider Scope

Ask:

One host?

Multiple hosts?

One user?

Multiple users?

Single event?

Repeated behavior?

Broader scope generally increases urgency.

Part 51 — Consider Persistence of Activity

An alert that stops after one blocked event may be different from:

Alert
 ↓
Repeated Activity
 ↓
Additional Hosts
 ↓
Continued Connections

Persistence may increase priority.

Part 52 — Consider Security-Control Outcome

Example:

Malicious File
   ↓
Blocked
   ↓
No Execution
   ↓
No Network Activity

may require less urgency than:

Malicious File
   ↓
Executed
   ↓
Outbound Connection

Part 53 — Build the Priority Scoring Worksheet

For each alert rate:

Alert Severity:
Low / Medium / High

Asset Criticality:
Low / Medium / High

Identity Privilege:
Low / Medium / High

Evidence Confidence:
Low / Medium / High

Potential Impact:
Low / Medium / High

Scope:
Single / Multiple

Security Control Outcome:
Blocked / Allowed / Unknown

Then assign the analyst priority.

Part 54 — Escalation Criteria

Escalate when one or more of these are present:

• confirmed malicious activity

• privileged account involved unexpectedly

• critical asset involved

• multiple systems affected

• malware execution suspected

• suspicious outbound communication

• persistence indicators

• possible sensitive-data impact

• containment decision required

• analyst cannot confidently close the alert

Part 55 — Create the Escalation Register

Alert	Escalation Reason	Priority	Destination
ALT-004	Privileged anomaly	P2	Tier 2
ALT-002	Endpoint follow-up	P3	Endpoint team

Part 56 — Write an Escalation Summary

Use:

ALERT:
ALT-004

PRIORITY:
P2

REASON:
Unexpected privileged authentication to critical server.

EVIDENCE:
Login originated from an unrecognized source and no approved
maintenance activity was identified.

CURRENT SCOPE:
One account, one server.

KNOWN IMPACT:
No confirmed impact.

RECOMMENDED NEXT STEP:
Perform detailed authentication and host activity investigation.

EVIDENCE REFERENCES:
EV-014
EV-015

This allows the next analyst to continue immediately.

Part 57 — Closing an Alert

Before closing, ensure you can answer:

Why did the alert fire?

What evidence explains it?

Why is deeper investigation unnecessary?

What disposition applies?

What evidence supports closure?

Part 58 — Create a Closure Note

Example:

ALERT:
ALT-005

DISPOSITION:
Expected Activity

ANALYSIS:
The alert correctly identified network scanning originating from
the authorized SOC training assessment workstation during a
documented lab exercise.

IMPACT:
None.

ESCALATION:
Not required.

CLOSURE:
Alert closed as authorized security-testing activity.

Part 59 — Avoid Weak Closure Notes

Do not write:

Looks fine.

or:

Probably false positive.

Use evidence.

Part 60 — Detect Duplicate Alerts

Duplicate indicators include:

• same detection rule

• same host

• same user

• same source/destination

• same event

• close timestamps

But do not merge alerts automatically if they represent distinct events.

Part 61 — Build the Duplicate Alert Matrix

Alert A	Alert B	Same Event	Action
ALT-001	ALT-006	Yes	Merge
ALT-002	ALT-007	No	Separate

Part 62 — Detect Alert Storms

An alert storm occurs when one event generates many notifications.

Example:

One failing application
       ↓
100 authentication alerts

The analyst should identify:

One root event, many alert symptoms.

Part 63 — Root Cause vs Alert Volume

Twenty alerts do not automatically mean twenty incidents.

Ask:

How many unique users?

How many unique hosts?

How many unique behaviors?

How many unique root causes?

Part 64 — Build the Root Cause Register

Root Cause	Related Alerts	Status
Stale application password	ALT-001, ALT-006	Benign
Approved scan	ALT-005	Expected

Part 65 — Recognize False-Negative Risk

Triage also involves not closing too quickly.

If evidence is missing:

Do not force:
False Positive

Use:

Inconclusive

or:

Suspicious — Investigate

Part 66 — Avoid Confirmation Bias

If an alert title says:

Credential Attack

do not search only for evidence supporting a credential attack.

Ask:

Could this be user error?

Could this be an expired password?

Could this be a service account?

Could this be automation?

Could this be malicious?

Part 67 — Build a Hypothesis Register

Example:

ALERT:
ALT-001

HYPOTHESIS 1:
User entered incorrect password.

Supporting Evidence:

Contradicting Evidence:


HYPOTHESIS 2:
Automated credential attack.

Supporting Evidence:

Contradicting Evidence:


CURRENT ASSESSMENT:

CONFIDENCE:

Part 68 — Build the Final Alert Triage Register

Alert	Context	Priority	Confidence	Disposition	Action
ALT-001	Normal user failures	P4	High	Expected	Close
ALT-002	Malware blocked	P3	High	Security Event	Review
ALT-003	Suspicious DNS	P3	Medium	Investigate	Escalate
ALT-004	Approved admin login	P4	High	Expected	Close
ALT-005	Approved scan	P4	High	Expected	Close
ALT-006	ALT-001 duplicate	P4	High	Duplicate	Merge
ALT-007	Approved PowerShell	P4	High	Expected	Close
ALT-008	Normal SMB access	P4	High	Benign	Close

Use your own evidence rather than copying these outcomes blindly.

Part 69 — Create the Alert Queue Summary

TOTAL ALERTS:

P1:

P2:

P3:

P4:

EXPECTED ACTIVITY:

BENIGN:

FALSE POSITIVE:

DUPLICATE:

SUSPICIOUS:

POTENTIAL INCIDENT:

CONFIRMED INCIDENT:

INCONCLUSIVE:

ESCALATED:

Part 70 — Build Analyst Performance Metrics

For this lab record:

Alerts Reviewed:

Alerts Closed:

Alerts Escalated:

Duplicates Removed:

False Positives Identified:

Average Triage Time:

Cases Created:

Do not optimize for closing the most alerts.

Optimize for correct decisions.

Part 71 — Mission Challenge

Complete:

LAB INFORMATION

Lab:
Security Alert Triage & Prioritization

Case ID:

Analyst:

Date:

Shift:


ALERT QUEUE

Total Alerts:

Critical:

High:

Medium:

Low:


ALERT 01

Alert ID:

Alert Name:

Timestamp:

Initial Severity:

Asset:

Asset Criticality:

User:

Privilege:

Source:

Expected Activity:

Supporting Evidence:

Related Alerts:

Duplicate:
Yes / No

Priority:

Confidence:

Disposition:

Escalate:
Yes / No

Reason:


ALERT 02

Alert ID:

Alert Name:

Initial Severity:

Asset:

Asset Criticality:

User:

Supporting Evidence:

Priority:

Confidence:

Disposition:

Escalation:

Reason:


DUPLICATES

Duplicate Alerts:

Primary Alert:

Evidence:


FALSE POSITIVES

Alert:

Reason:

Evidence:


EXPECTED ACTIVITY

Alert:

Authorized Activity:

Evidence:


ESCALATIONS

Alert:

Priority:

Escalation Reason:

Current Scope:

Known Impact:

Next Investigation Step:


TRIAGE SUMMARY

P1:

P2:

P3:

P4:

Closed Alerts:

Escalated Alerts:

Duplicate Alerts:

False Positives:

Inconclusive Alerts:


FINAL ANALYSIS

Highest-Priority Alert:

Most Important Asset:

Most Important Identity:

Most Significant Escalation:

Most Useful Supporting Evidence:

Most Difficult Alert to Classify:

Ready for Suspicious Authentication Investigation:
Yes / No

Part 72 — What Not to Do

Do not:

Treat every alert as an incident

Automatically trust alert severity

Automatically trust alert titles

Close alerts without evidence

Escalate every high-severity alert

Ignore asset criticality

Ignore identity privilege

Ignore maintenance windows

Ignore duplicate alerts

Count duplicate alerts as separate incidents

Assume malware detection means execution

Assume failed login means credential attack

Assume PowerShell means malicious activity

Assume IOC match proves compromise

Search unrelated user information

Use unrelated production data

Modify logs

Delete original evidence

Guess missing evidence

Call something a false positive simply because you cannot explain it

The professional rule is:

Triage should reduce uncertainty—not hide it.

Troubleshooting

Alert Has No Asset Context

Check the Asset Register.

If still unknown:

Asset Criticality:
Unknown

Increase uncertainty rather than inventing a value.

User Is Unknown

Check identity context.

If unavailable:

Identity Context:
Missing

This may justify additional investigation.

Logs Are Delayed

Do not close the alert prematurely.

Mark:

Disposition:
Pending / Inconclusive

until relevant telemetry becomes available.

Duplicate Status Is Unclear

Compare:

• timestamps

• rule

• source

• destination

• user

• underlying event ID

Keep alerts separate if unsure.

Initial Severity Seems Wrong

That is acceptable.

Document your analyst priority separately.

Threat Intelligence Says Malicious but Local Evidence Is Clean

Document both.

Do not let external reputation override local evidence automatically.

Evidence Requirements

Capture:

Evidence 01

Lab scope.

Evidence 02

Original alert queue.

Evidence 03

Asset Context Register.

Evidence 04

Identity Context Register.

Evidence 05

Alert Metadata Register.

Evidence 06

ALT-001 supporting authentication evidence.

Evidence 07

ALT-002 endpoint evidence.

Evidence 08

ALT-003 DNS evidence.

Evidence 09

ALT-004 administrative context.

Evidence 10

ALT-005 authorized activity evidence.

Evidence 11

Duplicate Alert Register.

Evidence 12

False Positive Register.

Evidence 13

Alert Correlation Register.

Evidence 14

Priority Scoring Worksheets.

Evidence 15

Escalation Register.

Evidence 16

Closure Notes.

Evidence 17

Root Cause Register.

Evidence 18

Hypothesis Register.

Evidence 19

Final Alert Triage Register.

Evidence 20

Alert Queue Summary.

Evidence 21

Mission Challenge worksheet.

Mission Deliverables

Complete:

• alert queue imported

• alert metadata reviewed

• Asset Register correlated

• Identity Register correlated

• severity reviewed

• analyst priority assigned

• confidence assigned

• supporting evidence checked

• duplicate alerts identified

• expected activity identified

• false positives documented

• suspicious alerts identified

• related alerts correlated

• root causes considered

• escalation decisions documented

• closure decisions documented

• hypothesis testing used where needed

• asset criticality incorporated

• identity privilege incorporated

• security-control outcome considered

• alert dispositions standardized

• Final Alert Triage Register completed

• Alert Queue Summary completed

• Mission Challenge completed

Lab Report Template

# Lab 02 — Security Alert Triage & Prioritization

## Executive Summary

## Mission Objective

## Lab Scope

## Alert Queue

## Triage Methodology

## Asset Context

## Identity Context

## Alert Severity Review

## Alert Priority Model

## Alert Analysis

### ALT-001
### ALT-002
### ALT-003
### ALT-004
### ALT-005
### ALT-006
### ALT-007
### ALT-008

## Duplicate Alerts

## False Positives

## Expected Activity

## Suspicious Alerts

## Escalations

## Closure Decisions

## Alert Correlation

## Root Cause Analysis

## Confidence Assessment

## Final Alert Triage Register

## Alert Queue Summary

## Analyst Observations

## Limitations

## Conclusion

Knowledge Check

Question 1 — Is alert severity the same as analyst priority?

No.

Alert severity comes from the detection logic. Priority incorporates asset criticality, identity privilege, confidence, potential impact, and scope.

Question 2 — Does a malware alert prove malware executed?

No.

It may have been blocked before execution.

Question 3 — What is the difference between expected activity and a false positive?

Expected activity means the detection accurately identified an authorized action. A false positive means the detection incorrectly interpreted benign activity.

Question 4 — Why is asset context important?

Because an alert involving a critical server may deserve more attention than the same alert involving a low-value test system.

Question 5 — Why is identity privilege important?

Unexpected activity involving privileged accounts can carry significantly greater potential impact.

Question 6 — Should duplicate alerts be investigated as separate incidents?

Usually not if they refer to the same underlying activity, but they should be linked and preserved.

Question 7 — What should you do when evidence is insufficient?

Classify the alert as inconclusive or escalate it for further investigation rather than forcing a benign or malicious conclusion.

Question 8 — Does an IOC reputation match prove compromise?

No.

Local telemetry must support the conclusion.

Question 9 — What is the purpose of triage?

To determine whether an alert is valid, how important it is, and what the SOC should do next.

Question 10 — What is the central question of this lab?

“Does this alert represent meaningful security risk, and what should the SOC do with it next?”

Skills Achieved

After completing this lab, you should understand:

• SOC alert triage

• alert metadata

• asset enrichment

• identity enrichment

• severity vs priority

• severity vs confidence

• alert validation

• expected activity

• benign activity

• false positives

• duplicate alerts

• alert correlation

• alert clustering

• root-cause thinking

• priority assignment

• escalation decisions

• closure decisions

• analyst hypothesis testing

• evidence-based triage

• SOC queue management

Professional Takeaway

A weak SOC triage process looks like:

Alert
  ↓
High Severity
  ↓
Escalate

A professional triage process looks like:

Alert
  ↓
Understand Detection
  ↓
Asset Context
  ↓
Identity Context
  ↓
Supporting Telemetry
  ↓
Related Alerts
  ↓
Confidence
  ↓
Potential Impact
  ↓
Priority
  ↓
Close / Investigate / Escalate

Always distinguish:

Alert
  ≠
Incident

High Severity
  ≠
High Priority

Malware Detected
  ≠
Malware Executed

Failed Login
  ≠
Credential Attack

PowerShell Executed
  ≠
Malicious PowerShell

IOC Match
  ≠
Compromise

Duplicate Alert
  ≠
Separate Incident

Missing Evidence
  ≠
Benign Activity

The most important triage skill is not simply deciding whether something is “good” or “bad.”

It is being able to explain:

What happened, what evidence supports your interpretation, how confident you are, and exactly what should happen next.

What’s Next?

➡️ Lab 03 — Suspicious Authentication Investigation

In the next lab, you will move from basic alert triage into a complete identity-focused investigation.

You will investigate:

• failed authentication

• successful login after failures

• unusual source systems

• login timestamps

• privileged accounts

• account lockouts

• authentication methods

• source IP correlation

• host correlation

• identity baselines

• related endpoint/network evidence

• account-compromise indicators

• incident timelines

The methodology becomes:

Identity → Authentication Event → Source → Timeline → Baseline → Correlate → Scope → Conclusion

The central question will be:

“Does the suspicious authentication activity represent normal user behavior, an operational problem, or evidence that an account may have been misused?”