Lab 01 Build Your SOC Analyst Lab

Mission Overview

Welcome to Lab 01 — Build Your SOC Analyst Lab.

This is the foundation lab for the entire SOC track.

Before investigating suspicious authentication, phishing, malware, endpoint alerts, DNS activity, or SIEM events, you need a controlled environment where logs can be collected, reviewed, correlated, preserved, and documented consistently.

A professional SOC investigation does not begin with:

“Open the SIEM and start clicking.”

It begins with:

Environment → Data Sources → Time → Evidence → Case Structure → Investigation Readiness

Your objective in this lab is to build a reusable SOC analyst workspace that supports every investigation in Labs 02–15.

Mission Goal: Build an organized SOC investigation environment, establish the core log sources, create a consistent case-management and evidence structure, validate timestamps and telemetry, and prepare a repeatable workflow for future security investigations.

Mission Information

Item	Details
Difficulty	Beginner
Estimated Time	90–120 minutes
Primary Skill	SOC Environment Setup
Secondary Skill	Evidence & Log Organization
Environment	GoHackersCloud SOC Analyst Lab
Primary Outcome	Reusable SOC Investigation Workspace
Safety Level	Authorized Training Environment Only

Learning Objectives

By completing this lab, you will be able to:

understand the basic SOC analyst environment
identify common security log sources
distinguish endpoint, network, identity, and application telemetry
create a repeatable investigation folder structure
create case IDs
create an investigation journal
normalize timestamps
understand UTC and local time
build an evidence register
preserve original evidence
distinguish raw evidence from analyst notes
create an asset register
create an identity register
validate Windows and Linux log availability
organize DNS, firewall, proxy, email, and endpoint telemetry
understand SIEM data-source concepts
build a SOC readiness checklist
prepare the environment for alert triage

SOC Investigation Methodology

Throughout this track, use:

Alert → Validate → Investigate → Correlate → Scope → Contain → Escalate → Report

This lab prepares the environment required to execute that methodology.

Conceptually:

Security Data Sources
        │
        ├── Identity
        ├── Endpoint
        ├── Windows
        ├── Linux
        ├── DNS
        ├── Network
        ├── Email
        └── Application
        │
        ▼
       SIEM
        │
        ▼
      Alert
        │
        ▼
  SOC Investigation
        │
        ▼
 Evidence + Timeline
        │
        ▼
    Case Report

The core principle is:

Good investigations depend on good data, good timestamps, and good evidence discipline.

Part 1 — Understand the SOC Analyst Workspace

A SOC analyst normally works with several components:

SOC Workstation
      │
      ├── SIEM
      ├── Endpoint Telemetry
      ├── Identity Logs
      ├── Network Logs
      ├── Email Evidence
      ├── Threat Intelligence
      ├── Investigation Notes
      └── Case Management

Your lab does not need every enterprise product.

The goal is to reproduce the investigation workflow, not the vendor stack.

Part 2 — Recommended Lab Architecture

A basic training environment may look like:

                    SOC Analyst Workstation
                             │
                             ▼
                          SIEM / Logs
                       /      |       \
                      /       |        \
                     ▼        ▼         ▼
                 Windows    Linux    Network
                 Endpoint   Server    Evidence
                     │        │
                     └───┬────┘
                         ▼
                  Simulated Events

A more complete environment:

                         SOC Analyst
                              │
                              ▼
                            SIEM
                ┌─────────────┼─────────────┐
                │             │             │
                ▼             ▼             ▼
           Windows Logs   Linux Logs    Network Logs
                │             │             │
                ├─────────────┼─────────────┤
                │             │             │
                ▼             ▼             ▼
             Endpoint        DNS          Email
             Telemetry      Proxy         Evidence

Part 3 — Define the Lab Scope

Document your lab environment.

Example:

SOC LAB SCOPE

Environment:
GoHackersCloud SOC Analyst Training Lab

SOC Workstation:
SOC01

Windows Endpoint:
WIN01

Linux Server:
LINUX01

Infrastructure:
DNS01

Log Platform:
Training SIEM / Log Repository

Assessment Type:
Security Monitoring and Investigation

Authorized Data:
Training-generated logs only

Production Data:
Not Authorized

Part 4 — Create Your SOC Workspace

Create:

SOC-Labs/
└── Lab-01/
    ├── 01-Scope/
    ├── 02-Assets/
    ├── 03-Identities/
    ├── 04-Log-Sources/
    │   ├── Windows/
    │   ├── Linux/
    │   ├── Identity/
    │   ├── Endpoint/
    │   ├── DNS/
    │   ├── Firewall/
    │   ├── Proxy/
    │   ├── Email/
    │   └── Application/
    ├── 05-Evidence/
    │   ├── Original/
    │   ├── Working/
    │   └── Redacted/
    ├── 06-Timelines/
    ├── 07-Queries/
    ├── 08-Screenshots/
    ├── 09-Case-Notes/
    ├── 10-Findings/
    └── 11-Reports/

The same structure can be reused for future SOC cases.

Part 5 — Create a Case Numbering Standard

A SOC case needs a unique identifier.

Example:

GHC-SOC-2026-001

Structure:

GHC
SOC
2026
001

Meaning:

Organization
Team
Year
Sequential Case Number

For this lab:

CASE ID:
GHC-SOC-LAB01-001

Part 6 — Create the Case Header

Create:

09-Case-Notes/GHC-SOC-LAB01-001.md

Use:

# SOC Investigation Case

## Case Information

Case ID:
GHC-SOC-LAB01-001

Case Title:
SOC Environment Validation

Analyst:

Date Opened:

Status:
Open

Priority:
Training

Source:
GoHackersCloud SOC Lab

## Scope

## Assets

## Identities

## Data Sources

## Investigation Journal

## Evidence Register

## Timeline

## Findings

## Conclusions

Part 7 — Create the Asset Register

SOC investigation depends heavily on asset context.

Create:

Asset ID	Hostname	OS	Role	Criticality
A-001	SOC01	Linux/Windows	Analyst Workstation	Medium
A-002	WIN01	Windows	User Endpoint	Medium
A-003	LINUX01	Linux	Server	High
A-004	DNS01	Linux/Appliance	DNS	High

Add:

owner
department
environment
location
business function

where provided.

Part 8 — Why Asset Context Matters

An alert involving:

DEV-LAPTOP-15

may have very different significance from:

PAYROLL-DB-01

Even if the same alert fires.

SOC prioritization often depends on:

Alert Severity + Asset Criticality + User Context + Evidence Confidence

Part 9 — Create the Identity Register

Create:

Identity	Type	Role	Privileged	Department
lab-user	User	Standard User	No	Training
lab-admin	User	Administrator	Yes	IT
svc-web	Service	Web Service	Limited	IT

Document identities only from the training environment.

Part 10 — Understand Identity Types

Common types include:

Human User

Example:

jsmith

Privileged User

Example:

admin-jsmith

Service Account

Example:

svc-backup

Machine Identity

Example:

WIN01$

Application Identity

Example:

app-service

Identity context becomes critical in Lab 03.

Part 11 — Create the Log Source Inventory

Build:

Log Source	System	Purpose
Windows Security	WIN01	Authentication
Windows System	WIN01	OS events
Linux Auth	LINUX01	Authentication
DNS	DNS01	Name resolution
Firewall	Gateway	Network flows
Endpoint	WIN01	Process/security
Email	Mail Lab	Phishing
Proxy/Web	Proxy	Web traffic

Part 12 — Understand the Major SOC Data Categories

Think of SOC telemetry in these groups:

Identity
Endpoint
Host
Network
Infrastructure
Application
Email
Cloud

For this track, the main emphasis will be:

Identity
Windows
Linux
Endpoint
DNS
Network
Email
SIEM

Part 13 — Windows Security Logs

Windows Security logs may contain evidence relating to:

successful authentication
failed authentication
account changes
group changes
privilege activity
process activity where auditing is configured
system access

You do not need to memorize every Event ID in this lab.

The important question is:

Can you locate the event, understand its source, and place it in context?

Part 14 — Locate Windows Logs

On an authorized Windows training system, use:

Event Viewer

Typical location:

Windows Logs
    ├── Application
    ├── Security
    ├── Setup
    └── System

Record:

Host:

Security Log Available:
Yes / No

System Log Available:
Yes / No

Application Log Available:
Yes / No

Part 15 — Validate Windows Security Telemetry

Generate only benign lab activity such as:

normal test login
normal logout
approved application start

Then verify that the expected event appears.

The goal is not to create malicious events.

It is to prove:

Activity
   ↓
Telemetry
   ↓
Analyst Visibility

Part 16 — Linux Log Sources

Common locations may include:

/var/log/auth.log

or:

/var/log/secure

Depending on distribution.

Systemd-based systems may use:

journalctl

Part 17 — Validate Linux Logs

On the authorized Linux training system:

journalctl --since "10 minutes ago"

Where applicable:

sudo tail /var/log/auth.log

or:

sudo tail /var/log/secure

Use only read-only investigation commands.

Part 18 — Build the Linux Log Profile

LINUX LOG PROFILE

Host:

Distribution:

Authentication Log:

System Journal:

SSH Events Available:
Yes / No

Sudo Events Available:
Yes / No / Not Tested

Service Events Available:
Yes / No

Timestamp Format:

Timezone:

Part 19 — DNS Logs

DNS telemetry can reveal:

Client
   ↓
Query
   ↓
Domain
   ↓
Response

Potential investigation value:

suspicious domains
repeated queries
newly observed domains
command-and-control indicators
phishing infrastructure
internal hostname activity

For this lab, identify whether DNS data is available.

Do not begin threat hunting yet.

Part 20 — Firewall Logs

Firewall or network-security logs may include:

Timestamp
Source IP
Destination IP
Source Port
Destination Port
Protocol
Action

Common actions:

ALLOW
DENY
DROP
RESET

Build:

Field	Available
Timestamp
Source
Destination
Port
Protocol
Action

Part 21 — Proxy/Web Logs

Web or proxy telemetry may provide:

source user
source IP
destination domain
URL
method
status code
user agent
bytes transferred
category

These become important in phishing and web-traffic investigations.

Part 22 — Email Evidence

Email investigations may require:

sender
recipient
subject
date
message ID
received headers
reply-to
SPF results
DKIM results
DMARC results
attachments
URLs

For this lab, simply confirm that a training email sample or evidence source exists.

Part 23 — Endpoint Telemetry

Endpoint detection tools may provide:

Process Name
Parent Process
Command Line
File Hash
User
Host
Network Connection
Alert

Your SOC lab may use:

exported JSON
CSV
sample EDR alerts
SIEM events
generated training telemetry

The exact platform is less important than understanding the evidence.

Part 24 — Create the Endpoint Data Profile

ENDPOINT DATA PROFILE

Host:

User:

Process Information Available:
Yes / No

Parent Process:
Yes / No

Command Line:
Yes / No

File Hash:
Yes / No

Network Connections:
Yes / No

Detection Alerts:
Yes / No

Part 25 — Understand SIEM Purpose

A SIEM helps centralize and correlate events.

Conceptually:

Windows ─┐
Linux ───┤
DNS ─────┤
Firewall ├────► SIEM
Endpoint ┤        │
Email ───┤        ▼
Proxy ───┘      Alerts

A SIEM usually supports:

search
filtering
correlation
dashboards
alerts
event enrichment
case investigation

Part 26 — Do Not Become Tool-Dependent

The analyst workflow should work whether the environment uses:

Platform A
Platform B
Platform C

The transferable skill is:

Understand the data and ask the right investigative question.

Part 27 — Validate SIEM Data Sources

Create:

Source	Events Visible	Latest Timestamp	Status
Windows
Linux
DNS
Firewall
Endpoint

Classify:

Healthy
Delayed
Missing
Unknown

Part 28 — Understand Log Ingestion Delay

An event may occur at:

10:00:00

but appear in the SIEM at:

10:00:35

Therefore distinguish:

Event Time

When activity occurred.

Ingestion Time

When the SIEM received it.

This becomes very important during timeline reconstruction.

Part 29 — Create a Time Standard

Choose one investigation standard.

Recommended:

UTC for master incident timelines

You may also preserve local time.

Example:

Event Time:
2026-08-28 14:15:30 UTC

Local Time:
2026-08-28 19:45:30 IST

Part 30 — Why Timestamp Normalization Matters

Imagine:

Windows:
14:05 UTC

Firewall:
19:35 IST

Email:
14:04 UTC

Endpoint:
19:36 IST

Without normalization, correlation becomes confusing.

Always record timezone.

Part 31 — Create the Time Normalization Register

Source	Original Timezone	Master Timezone	Offset
Windows	UTC	UTC	0
Linux	UTC	UTC	0
Endpoint	Local	UTC
Firewall	Local	UTC

Part 32 — Validate System Clock Consistency

Record:

SOC Workstation Time:

Windows Time:

Linux Time:

SIEM Time:

Difference:

Acceptable:
Yes / No

You are checking visibility and consistency, not changing production clocks.

Part 33 — Create the Investigation Journal

Use:

TIME:

CASE ID:

ANALYST:

ACTION:

DATA SOURCE:

QUERY / METHOD:

RESULT:

INTERPRETATION:

EVIDENCE ID:

NEXT STEP:

Example:

TIME:
14:20 UTC

CASE:
GHC-SOC-LAB01-001

ACTION:
Validated Windows Security log availability.

RESULT:
Authentication events are visible.

INTERPRETATION:
Windows authentication telemetry is available for future
investigations.

EVIDENCE:
EV-004

NEXT STEP:
Validate Linux authentication logs.

Part 34 — Separate Evidence from Notes

Maintain:

Raw Evidence

separately from:

Analyst Notes

For example:

05-Evidence/Original/windows-security.evtx

versus:

09-Case-Notes/windows-analysis.md

Never overwrite your original evidence with analyst edits.

Part 35 — Build the Evidence Register

Use:

Evidence ID	Source	Description	Original	Working Copy
EV-001	Windows	Security log	Yes	Yes
EV-002	Linux	Auth log	Yes	Yes
EV-003	DNS	Query sample	Yes	Yes

Part 36 — Evidence Identification Standard

Use:

EV-001
EV-002
EV-003

Then reference these IDs in:

journal
timeline
findings
case report

Part 37 — Preserve Original Evidence

Recommended model:

Original Evidence
       │
       │ Copy
       ▼
Working Evidence
       │
       ▼
Analysis
       │
       ▼
Redacted Evidence
       │
       ▼
Report

Do not edit the original where avoidable.

Part 38 — Understand Chain of Custody

For SOC investigations, record:

What evidence was collected?

Who collected it?

When?

From where?

How was it stored?

Was it modified?

For this training lab, use a simple chain-of-custody register.

Part 39 — Create the Chain-of-Custody Register

Evidence	Collected By	Date/Time	Source	Action
EV-001	Analyst		WIN01	Exported
EV-002	Analyst		LINUX01	Copied

Part 40 — Understand Evidence Hashing

Where required, hashes can help verify evidence integrity.

Conceptually:

Evidence File
     ↓
Hash
     ↓
Known Value

If the file later changes, the hash may change.

This lab does not require forensic-level evidence handling for every file, but students should understand the concept.

Part 41 — Create the Investigation Timeline Template

Use:

Time UTC	Source	Host/User	Event	Evidence

You will use this heavily in Lab 12.

Part 42 — Create an Alert Register

Even though triage begins in Lab 02, prepare the structure now.

Alert ID	Time	Source	Asset	Severity	Status
ALT-001					New

Suggested statuses:

New
Investigating
Pending
Escalated
Closed

Part 43 — Create a Case Disposition Register

Use consistent classifications:

Benign

Expected Activity

False Positive

Suspicious

Potential Incident

Confirmed Security Incident

Inconclusive

Escalated

Do not create a different vocabulary for every lab.

Part 44 — Separate Severity and Confidence

Example:

Severity:
High

Confidence:
Low

is possible.

Severity means:

How serious would this be?

Confidence means:

How certain are we about the interpretation?

Part 45 — Create the Severity Model

For training, use:

Critical
High
Medium
Low
Informational

Consider:

affected asset
account privilege
number of affected systems
business criticality
evidence of execution
data impact
persistence
network scope

Part 46 — Create the Confidence Model

Use:

High

Multiple correlated evidence sources support the conclusion.

Medium

Evidence strongly suggests the conclusion but important context is missing.

Low

Evidence is incomplete or largely circumstantial.

Part 47 — Create the Investigation Hypothesis Template

During investigations, use:

HYPOTHESIS:

Evidence Supporting:

Evidence Contradicting:

Evidence Missing:

Current Confidence:

Next Validation Step:

This prevents analysts from locking onto the first explanation.

Part 48 — Understand Confirmation Bias

Suppose an alert says:

Malware Detected

A weak analyst thinks:

Host Compromised

A stronger analyst asks:

What exactly was detected?

Did it execute?

What process launched it?

What user was involved?

Did it make network connections?

Was it blocked?

Are other hosts affected?

The data determines the conclusion.

Part 49 — Build the Analyst Question Framework

For any future alert, ask:

WHO?

WHAT?

WHEN?

WHERE?

HOW?

WHAT ELSE?

SO WHAT?

Meaning:

Who?

User/account.

What?

Activity or event.

When?

Timestamp and sequence.

Where?

Host, network, application.

How?

Process, protocol, authentication method.

What Else?

Related events.

So What?

Security impact.

Part 50 — Validate Search Capability

In your chosen SIEM/log platform, confirm you can search by:

host
user
IP address
event type
time range

Record:

Search	Works
Host
User
IP
Time
Event Type

Do not worry about advanced correlation yet.

Part 51 — Create the Saved Query Register

Use:

Query ID	Purpose	Data Source
Q-001	Events by host	All
Q-002	Events by user	Identity
Q-003	Events by source IP	Network
Q-004	Events by time range	All

Exact syntax will depend on your lab SIEM.

Part 52 — Validate Pivoting

A SOC investigation often looks like:

Alert
  ↓
User
  ↓
Host
  ↓
IP
  ↓
DNS
  ↓
Endpoint

Verify that your environment allows you to move between at least two data sources.

For example:

Authentication Event
        ↓
Same Host
        ↓
Endpoint Events

Part 53 — Build the Pivot Register

Starting Evidence	Pivot	Result
User	Host
Host	IP
IP	DNS
Host	Endpoint

Part 54 — Create the IOC Register Template

Future investigations may contain:

IP
domain
URL
hash
email address

Create:

IOC ID	Type	Value	Source	Confidence
IOC-001	Domain

Do not populate it with real unrelated indicators.

Part 55 — Create the Investigation Findings Template

Use:

## Finding ID

### Observation

### Evidence

### Analysis

### Severity

### Confidence

### Scope

### Recommended Action

### Escalation Required

### Remaining Questions

SOC findings are not always vulnerabilities.

They may represent:

suspicious behavior
incident evidence
policy violations
confirmed malicious activity
telemetry gaps

Part 56 — Document Telemetry Gaps

Missing visibility is itself important.

Example:

TELEMETRY GAP:
Endpoint process telemetry unavailable for LINUX01.

Impact:
Process-level investigation may be limited.

Recommendation:
Review endpoint monitoring coverage.

Do not imply malicious activity simply because logs are missing.

Part 57 — Build the Telemetry Coverage Matrix

Asset	Auth	Endpoint	DNS	Network	Application
WIN01	Yes	Yes	Yes	Yes	N/A
LINUX01	Yes	Partial	Yes	Yes	Yes

This becomes extremely useful during investigations.

Part 58 — Identify Critical Logging Gaps

Examples:

No authentication logs from critical server

No endpoint telemetry on privileged workstation

No DNS logs

Firewall events missing source IP

SIEM ingestion delayed significantly

Classify:

Operational Observation

unless the lab specifically asks for a security finding.

Part 59 — Create the SOC Data Health Register

Source	Status	Delay	Completeness
Windows	Healthy	Low	Good
Linux	Healthy	Low	Good
DNS	Partial

Part 60 — Prepare a Sample Case Workflow

Your future cases should follow:

CASE OPENED
     ↓
Alert Recorded
     ↓
Scope Confirmed
     ↓
Initial Evidence Preserved
     ↓
Triage
     ↓
Investigation
     ↓
Correlation
     ↓
Timeline
     ↓
Scope Determination
     ↓
Disposition
     ↓
Escalation / Closure
     ↓
Report

Part 61 — Build the Case Status Model

Use:

NEW
 ↓
TRIAGE
 ↓
INVESTIGATING
 ↓
PENDING / ESCALATED
 ↓
CONTAINED
 ↓
CLOSED

Not every case needs every status.

Part 62 — Define Escalation Criteria

Prepare for later labs.

Potential escalation triggers:

privileged account involved
critical asset involved
malware execution confirmed
lateral activity suspected
multiple systems affected
sensitive data exposure
persistent malicious activity
containment required

Create:

Condition	Escalate
Critical asset affected	Yes
Privileged identity affected	Review
Single false positive	No

Part 63 — Define Containment Decision Fields

Do not perform containment in this setup lab.

Create:

Containment Required:
Yes / No / Unknown

Recommended Action:

Business Impact:

Evidence Preservation Required:

Approval Required:

Escalation Owner:

Part 64 — Create the SOC Analyst Dashboard

Maintain a simple case dashboard:

SOC LAB DASHBOARD

Open Cases:

New Alerts:

Cases Investigating:

Cases Escalated:

Cases Closed:

Log Sources Healthy:

Log Sources Missing:

Current Lab:

Current Case:

Part 65 — Perform a Readiness Validation

Your environment should answer:

Can I locate Windows authentication logs?

Can I locate Linux authentication logs?

Can I identify a DNS event?

Can I identify a network event?

Can I find endpoint telemetry?

Can I search by hostname?

Can I search by user?

Can I search by IP?

Can I search by time?

Can I preserve evidence?

Can I create an investigation timeline?

Can I document a case?

Part 66 — Build the SOC Readiness Matrix

Capability	Ready	Evidence
Windows logs
Linux logs
Identity context
DNS evidence
Network evidence
Endpoint evidence
SIEM search
Timeline
Evidence register
Case notes

Part 67 — Mission Challenge

Complete:

LAB INFORMATION

Lab:
Build Your SOC Analyst Lab

Case ID:

Analyst:

Date:


SOC ENVIRONMENT

SOC Workstation:

SIEM / Log Platform:

Windows Host:

Linux Host:

DNS Source:

Network Source:

Endpoint Source:

Email Source:


ASSETS

Asset 01:

Role:

Criticality:

Asset 02:

Role:

Criticality:


IDENTITIES

Standard User:

Privileged User:

Service Account:


LOG SOURCES

Windows Security:
Available / Missing

Linux Authentication:
Available / Missing

DNS:
Available / Missing

Firewall:
Available / Missing

Proxy:
Available / Missing

Endpoint:
Available / Missing

Email:
Available / Missing


TIME

SOC Timezone:

Windows Timezone:

Linux Timezone:

SIEM Timezone:

Master Investigation Timezone:

Clock Differences:


EVIDENCE

Original Evidence Folder:

Working Evidence Folder:

Redacted Evidence Folder:

Evidence Naming Standard:

Chain of Custody Created:
Yes / No


SIEM

Search by Host:
Yes / No

Search by User:
Yes / No

Search by IP:
Yes / No

Search by Time:
Yes / No

Pivot Between Sources:
Yes / No


TELEMETRY HEALTH

Healthy Sources:

Delayed Sources:

Missing Sources:

Critical Visibility Gaps:


CASE MANAGEMENT

Case Template Created:
Yes / No

Alert Register Created:
Yes / No

IOC Register Created:
Yes / No

Timeline Created:
Yes / No

Journal Created:
Yes / No


FINAL READINESS

Asset Context Ready:
Yes / No

Identity Context Ready:
Yes / No

Log Sources Ready:
Yes / No

Time Normalization Ready:
Yes / No

Evidence Handling Ready:
Yes / No

SIEM Search Ready:
Yes / No

Case Management Ready:
Yes / No

Ready for Alert Triage:
Yes / No

Part 68 — What Not to Do

Do not:

Import unrelated production logs

Collect real employee credentials

Capture personal data unnecessarily

Modify original evidence without retaining a copy

Delete inconvenient evidence

Change timestamps to make events align

Mix local time and UTC without labeling

Store passwords in analyst notes

Share raw security evidence publicly

Create malicious events unnecessarily

Generate malware simply to produce telemetry

Perform password attacks

Disable logging

Modify security controls

Hide telemetry gaps

Assume missing logs mean nothing happened

Treat every alert as an incident

The professional rule is:

Build visibility without creating unnecessary security risk.

Troubleshooting

Windows Events Are Missing

Check:

correct event channel
correct time range
auditing configuration
log ingestion
SIEM delay

Do not immediately conclude the activity did not occur.

Linux Authentication Log Does Not Exist

The distribution may use:

/var/log/secure

or:

journalctl

Identify the correct source.

SIEM Has No Recent Events

Check:

ingestion status
data-source status
event delay
timestamp/timezone
filters

Event Times Do Not Match

Check:

UTC vs local time

before assuming separate events.

Endpoint Data Is Missing

Record the visibility limitation.

Do not invent process details.

DNS Events Are Missing

Determine whether:

DNS logging is disabled
clients use another resolver
source is not ingested
the selected time range is incorrect

Evidence Requirements

Capture at minimum:

Evidence 01

SOC lab scope.

Evidence 02

Lab architecture.

Evidence 03

Case ID and case template.

Evidence 04

Asset Register.

Evidence 05

Identity Register.

Evidence 06

Log Source Inventory.

Evidence 07

Windows log availability.

Evidence 08

Linux log availability.

Evidence 09

DNS data availability.

Evidence 10

Network data availability.

Evidence 11

Endpoint data availability.

Evidence 12

SIEM data-source status.

Evidence 13

Time Normalization Register.

Evidence 14

Clock consistency validation.

Evidence 15

Investigation Journal.

Evidence 16

Evidence Register.

Evidence 17

Chain-of-Custody Register.

Evidence 18

Timeline template.

Evidence 19

Alert Register.

Evidence 20

IOC Register.

Evidence 21

Saved Query Register.

Evidence 22

Pivot Register.

Evidence 23

Telemetry Coverage Matrix.

Evidence 24

SOC Data Health Register.

Evidence 25

SOC Readiness Matrix.

Evidence 26

Mission Challenge worksheet.

Mission Deliverables

Complete:

SOC lab scope documented
SOC architecture documented
case-numbering standard defined
first training case created
Asset Register completed
Identity Register completed
Log Source Inventory completed
Windows telemetry validated
Linux telemetry validated
DNS telemetry identified
network telemetry identified
endpoint telemetry identified
email evidence source identified
SIEM data sources reviewed
ingestion delay understood
master timezone selected
timestamp normalization documented
evidence folder structure created
Evidence Register completed
chain-of-custody template created
investigation journal created
timeline template created
Alert Register created
IOC Register created
severity model defined
confidence model defined
telemetry gaps documented
search capability validated
pivot capability validated
escalation criteria prepared
SOC Readiness Matrix completed
environment declared ready for investigation

Lab Report Template

# Lab 01 — Build Your SOC Analyst Lab

## Executive Summary

## Mission Objective

## Lab Scope

## SOC Architecture

## Case Management Standard

## Asset Register

## Identity Register

## Log Source Inventory

## Windows Telemetry

## Linux Telemetry

## DNS Telemetry

## Network Telemetry

## Endpoint Telemetry

## Email Evidence

## SIEM Data Sources

## Timestamp Normalization

## Evidence Handling

## Chain of Custody

## Investigation Journal

## Alert Register

## IOC Register

## Timeline Framework

## Telemetry Coverage

## Data Health

## Investigation Search Capability

## Escalation Criteria

## SOC Readiness Assessment

## Limitations

## Conclusion

Knowledge Check

Question 1 — Why is asset context important during alert triage?

Because the same security event can have very different risk depending on the system’s role and criticality.

Question 2 — What is the difference between event time and ingestion time?

Event time represents when the activity occurred. Ingestion time represents when the log platform received the event.

Question 3 — Why normalize timestamps?

To accurately correlate events coming from systems using different timezones and logging formats.

Question 4 — Why preserve original evidence?

So the analyst can demonstrate what was originally collected and avoid confusing analyst modifications with source evidence.

Question 5 — Is missing telemetry proof that no activity occurred?

No.

It may indicate a visibility gap.

Question 6 — What is the purpose of an investigation journal?

To preserve a chronological record of analyst actions, searches, observations, evidence, and decisions.

Question 7 — What is the difference between severity and confidence?

Severity represents potential or confirmed impact. Confidence represents how certain the analyst is about the conclusion.

Question 8 — Why create an identity register?

Because user privilege, account type, department, and expected behavior are essential context during identity investigations.

Question 9 — What is a SIEM’s primary role in the SOC workflow?

To centralize, search, correlate, enrich, and alert on security telemetry from multiple sources.

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

“Do I have the data, timestamps, context, evidence process, and investigation workspace required to analyze a security alert professionally?”

Skills Achieved

After completing this lab, you should understand:

SOC lab architecture
case management fundamentals
asset context
identity context
security log sources
Windows logging basics
Linux logging basics
DNS telemetry
network telemetry
endpoint telemetry
email evidence
SIEM concepts
event vs ingestion time
timestamp normalization
evidence preservation
chain-of-custody fundamentals
investigation journaling
timeline preparation
severity vs confidence
telemetry-gap identification
investigation readiness

Professional Takeaway

A weak SOC setup looks like:

Alert Appears
     ↓
Search Randomly
     ↓
Take Screenshot
     ↓
Make Conclusion

A professional SOC setup looks like:

Know the Environment
        ↓
Know the Assets
        ↓
Know the Identities
        ↓
Know the Log Sources
        ↓
Normalize Time
        ↓
Preserve Evidence
        ↓
Record Analyst Actions
        ↓
Correlate Data
        ↓
Reach Defensible Conclusions

Always distinguish:

Alert
  ≠
Incident

Log Missing
  ≠
Activity Did Not Occur

Event Time
  ≠
Ingestion Time

High Severity
  ≠
High Confidence

Raw Evidence
  ≠
Analyst Interpretation

IOC Match
  ≠
Confirmed Compromise

One Event
  ≠
Complete Incident Story

By the end of this lab, you should be able to answer:

“Is my SOC environment organized well enough that another analyst could reproduce my investigation, locate my evidence, understand my timestamps, and continue the case without starting over?”

What’s Next?

➡️ Lab 02 — Security Alert Triage & Prioritization

In the next lab, students will receive a realistic alert queue and decide which alerts should be:

closed as expected activity
classified as false positives
investigated further
prioritized
escalated

They will work with:

alert severity
confidence
asset criticality
identity context
duplicate alerts
supporting telemetry
triage notes
disposition
escalation criteria

The methodology becomes:

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

The central question will be:

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