Lab Guide: Unit 1 — CCT Foundations & AI Landscape

CSEC 601 | Weeks 1–4 | Semester 1

Four hands-on lab sessions applying Collaborative Critical Thinking to real security scenarios, building your first AI-assisted security workflows, and establishing baseline performance metrics.

Claude as your CCT learning partner: Use Claude to pressure-test your CCT reasoning. After each reflection question in this unit, share your answer with Claude and ask: "What am I missing? What assumption am I making that might not hold?"

Unit 1 Lab Progress 0 / 30 steps complete

Week 1 — First AI-Assisted Investigation & CCT Incident Analysis

WEEK 1Lab: Claude Code Setup + Meridian Financial Incident

Lab Goal: Install Claude Code, run your first AI-assisted investigation, and apply all five CCT pillars to a realistic data exfiltration scenario. You will measure your baseline MTTI and submit a structured threat assessment.

Using Claude as your learning partner: Throughout this course, you'll see "Conversation Starters" — pre-written prompts you can paste directly into Claude or adapt for your own context. These aren't scripts to copy blindly. They're starting points. After running a conversation starter, follow up with your own questions based on what Claude actually said. The best learning happens in the back-and-forth after the first prompt, not in the first prompt itself.

Lab Exercise: Meridian Financial Incident Analysis

Scenario: You are a junior SOC analyst at Meridian Financial. At 2:34 AM EST on March 3, 2026, your SIEM fires: VP John Chen's account (jchen@meridian.local) accessed the production data warehouse from 203.45.12.89 (Singapore proxy), downloaded 47 CSV files (2.3 GB of revenue reports, client balances, transaction histories) in 8 minutes 34 seconds using valid credentials + successful MFA. Leadership requires a preliminary assessment in 30 minutes.

Separate the security track from the personnel track. Investigation data (logs, alerts, access records) and personnel data (HR records, role, employment status) must be handled in separate workstreams. Attribution and containment are distinct processes. Do not include personnel judgments in technical incident documentation. The suspect in an investigation has not been determined to be a perpetrator.

Try the /think Skill Before You Start

Before opening Claude Code, use the /think skill to structure your approach. It maps directly to CCT — surface your assumptions, identify risks, and consider alternatives before touching any tool. Perfect for incident analysis where gut instinct can lead you astray.

⭳ Download think.md 👁 All Course Skills

curl -o ~/.claude/commands/think.md https://raw.githubusercontent.com/r33n3/Noctua/main/docs/skills/think.md
# Then in any Claude Code session:
/think analyze the Meridian Financial incident — what do we know, what are we assuming, and what could explain this alert?

Check each step as you complete it. Your progress is saved automatically.

Step 1: Verify Claude Code is installed

Open your terminal and confirm Claude Code responds.

claude --version
# Expected: claude-code/x.x.x

Step 2: Create the lab working directory

All Unit 1 lab files live here.

mkdir -p ~/noctua-labs/unit1/week1
cd ~/noctua-labs/unit1/week1

Step 3: Download the incident data file

Download incident-data.md — the pre-built Meridian Financial incident report with full SIEM alert, authentication logs, data warehouse session detail, file inventory, contextual intelligence, and known unknowns. Save it to your lab directory.

Lab data files — all data files for this course are available in the course data directory. Click the download button below or access them directly from the course GitHub repository under docs/data/. If a file does not open, right-click the button and choose "Save link as."

⭳ Download incident-data.md 👁 View in browser

mkdir -p ~/noctua-labs/unit1/week1
cp ~/Downloads/incident-data.md ~/noctua-labs/unit1/week1/
# Or if viewing locally from the course docs folder:
cp ./data/incident-data.md ~/noctua-labs/unit1/week1/

Step 4: Launch Claude Code and submit Phase 1 CCT prompt

Open Claude Code and paste the structured CCT analysis prompt from the Week 1 lecture (the prompt with all 5 pillars). Observe Claude work through each pillar systematically.

claude
# Then paste the CCT 5-pillar analysis prompt from the lecture material

Step 5: Verify Claude's output contains all 5 pillars

Check: Does the response explicitly address Evidence-Based Analysis, Inclusive Perspective, Strategic Connections, Adaptive Innovation, and Ethical Governance? If any are missing, ask Claude to add them.

AI recommendations must overlay your organization's IR playbooks. The model in this lab recommended "soft containment" — session token revocation and IP block, but explicitly not account lockout. A student reviewer correctly identified this as too lax for a P1 incident. Standard IR practice at most organizations mandates immediate account lockout at P1 severity.

AI-generated recommendations are starting points, not authority. Always overlay model output with your organization's documented procedures: P1 playbooks, containment checklists, escalation matrices. Use the model as a thinking partner — not as a replacement for organizational policy.

CCT connection: This is Pillar 4 (Adaptive Innovation) applied to the model's own output. The student caught something the model missed because they had real-world IR context the model lacked. That's human-AI collaboration working correctly.

Step 6: Submit Phase 2 structured JSON analysis prompt

Ask Claude to produce the same analysis formatted as JSON with fields: evidence_summary, alternative_hypotheses (array of 3), next_steps, assumptions, confidence_scores.

Containment sequence matters: isolate before terminate. Terminating a running instance before isolating it destroys forensic evidence — memory contents, process tree, open network connections, active sessions. Standard IR procedure:

Network quarantine (cut external access)
Forensic image capture (memory + disk)
Preserve and document
Then terminate if needed

Premature termination is one of the most common IR mistakes. It feels decisive; it destroys evidence.

Step 7: Save the structured output

Copy Claude's JSON output to threat-assessment.json. Verify it is valid JSON with python3 -m json.tool threat-assessment.json.

python3 -m json.tool threat-assessment.json
# Should print formatted JSON without errors

What MTTI improvement should and shouldn't look like. Execution phases — prompt construction, Claude generation, output formatting — will get dramatically faster as your context engineering improves. That's legitimate improvement. CCT phases — reasoning, judgment, challenge, integration — should remain weighted. A compressed CCT phase is a failure mode, not a success metric. If your MTTI drops because you stopped challenging AI output, you've made yourself less effective, not more.

Step 8: Create your metrics log CSV

Record timestamps for each phase of your investigation. Calculate your MTTI. This is your Week 1 baseline — you will compare against this in Sprint weeks.

# metrics-log.csv
incident_id,phase,start_time,end_time,duration_min
MF-2026-0342,data_load,[your time],[your time],
MF-2026-0342,cct_analysis,[your time],[your time],
MF-2026-0342,claude_prompt,[your time],[your time],
MF-2026-0342,review,[your time],[your time],

Week 1 Deliverables

threat-assessment.json — Claude's structured CCT analysis in valid JSON format
CCT Analysis Report (800–1000 words) — your own write-up applying all 5 pillars, with 3 follow-up questions you would ask before escalating
metrics-log.csv — timestamps for each phase and your calculated MTTI baseline
CCT Journal Entry (500–750 words) — reflect on your first experience using AI as a thinking partner; what did Claude surface that you hadn't considered?

Week 2 — Cognitive Bias & CCT Deep Dive

WEEK 2Lab: Bias Identification & CCT-Structured Rewrite

Lab Goal: Identify cognitive biases embedded in a flawed security investigation report, map them to CCT pillars, then use Claude Code to produce a corrected, CCT-structured version. Document how bias reduction changes the investigative conclusion.

Lab Exercise: Bias Identification & CCT Rewrite

Sample Biased Report to Analyze: The following report contains multiple cognitive biases. Do NOT show it to Claude Code first — identify biases yourself before comparing with Claude's output.

INCIDENT REPORT — Account Access Anomaly
Analyst: J. Martinez | Date: March 5, 2026 | Ticket: INC-0455

SUMMARY: Confirmed insider threat. Account belongs to a contractor
from Eastern Europe (historically high-risk region for our org).
Downloads occurred at 2 AM, which is suspicious for any normal user.
The contractor recently had access elevated and has been "acting
weird" according to teammates. Prior to this incident, no issues —
but that's likely because they were biding their time.

EVIDENCE:
- 2:03 AM access from contractor account (bdavis@contractors.local)
- Downloaded 15 files from the project repository
- Account elevated to senior access 3 weeks ago by IT
- Source IP: 92.118.45.201 (Romania, VPN service)

RECOMMENDATION: Immediate termination of employment contract.
Preserve all evidence for law enforcement referral.
Do NOT notify the contractor — they will destroy evidence.

Step 1: Manual bias identification

Create bias-analysis.md. Without using Claude, list every cognitive bias you can identify in the report above. For each: name the bias, quote the offending text, and state why it's a bias.

Step 2: Map each bias to a CCT pillar

For each bias you identified, record which CCT pillar was violated. Example: "Stating the contractor was 'biding their time' without evidence violates Evidence-Based Analysis (inference presented as fact)."

Step 3: Use Claude Code for bias audit

Open Claude Code and ask: "Review this security incident report for cognitive biases. For each bias found, identify the type of bias, the specific text, the CCT pillar violated, and how it could lead to an incorrect conclusion." Then paste the report.

claude
# Prompt: "You are an expert in cognitive bias and security analysis.
# Review this incident report for ALL cognitive biases present.
# For each bias: (1) name the bias type, (2) quote the exact text,
# (3) identify which CCT pillar it violates, (4) explain the risk
# of acting on this conclusion. [paste report]"

Step 4: Compare your manual list vs. Claude's audit

Note any biases Claude found that you missed, and any you found that Claude missed. This gap analysis shows both your blind spots and Claude's. Add these observations to bias-analysis.md.

Step 5: CCT-structured rewrite with Claude Code

Ask Claude to rewrite the biased report using strict CCT structure: separate Observations (Layer 1) from Inferences (Layer 2) from Hypotheses (Layer 3) from Conclusions (Layer 4). Save as cct-investigation.md.

Step 6: Does the recommendation change?

Compare the original recommendation (immediate termination) to the CCT-structured recommendation. Document: Did removing bias change the action? What additional information does CCT require before a decision can be made?

Step 7: Write your 2-page bias reflection

Address: Which bias was most dangerous? What is the cost to the contractor if the original recommendation is acted upon without CCT review? How does CCT protect both the organization and the individual?

Week 2 Deliverables

bias-analysis.md — manual bias identification with CCT pillar mapping, plus gap analysis comparing your list to Claude's
cct-investigation.md — Claude's CCT-structured rewrite with 4-layer separation
2-page reflection — analysis of how bias removal changes the investigation outcome and the real-world stakes of biased security reports

Week 3 — Modern AI Landscape for Security

WEEK 3Lab: Model Comparison & Phishing Analysis

Lab Goal: Empirically compare Claude Sonnet vs. Claude Haiku on a security analysis task. Build a model selection framework based on accuracy, cost, speed, and hallucination risk. Learn how context window size affects analysis quality.

Lab Exercise: Phishing Email Analysis Comparative Study

# Sample phishing email for analysis (save as phishing-sample.txt):

From: security@microsoft-account-alert.net
To: employee@yourcompany.com
Subject: URGENT: Unusual sign-in activity detected on your account

Dear Microsoft Account User,

We have detected unusual sign-in activity on your Microsoft account
associated with this email address. To prevent unauthorized access
and protect your data, your account access has been temporarily
limited.

Verify your identity within 24 hours to restore full access:
http://microsoft-secure-verify.account-protection.xyz/verify?token=82hX9k

If you do not verify, your account and all associated data (OneDrive,
Teams, Outlook) will be permanently suspended.

Microsoft Account Security Team
support@microsoft.com

Step 1: Create lab directory and save the sample

mkdir -p ~/noctua-labs/unit1/week3
cd ~/noctua-labs/unit1/week3
# Save the sample above as phishing-sample.txt

Step 2: Run detailed analysis with Claude Sonnet

Use Claude Code with model claude-sonnet-4-6 (default). Ask for a comprehensive phishing analysis: indicators, confidence level, IoCs, recommended user action, and any false-positive risk.

claude
# Prompt: "Analyze this email for phishing indicators. For each
# indicator: type, severity, confidence (0-100%), and explanation.
# Conclude with: is_phishing (true/false), confidence, user_action,
# false_positive_risk. Format as JSON."

Step 3: Run quick analysis with a minimal prompt (speed test)

Now submit the same email with only: "Is this email phishing? Answer: yes/no, 3 indicators, confidence %." Record how response quality changes.

Step 4: Build your model selection comparison matrix

Step 5: Test with a legitimate email (false positive check)

Create a legitimate-sounding email from your IT team (e.g., routine password reset reminder). Run the same detailed analysis. Does the model correctly identify it as legitimate? How does confidence score differ?

Step 6: Calculate cost projections

Estimate API cost for your organization's email volume (assume 10,000 emails/day). Compare: detailed prompt vs. quick prompt. How does prompt engineering affect the cost-accuracy trade-off?

# Claude Sonnet pricing (March 2026):
# Input: $3.00 / 1M tokens | Output: $15.00 / 1M tokens
# Estimate tokens per email analysis (input + output combined)
# 10,000 emails/day * [tokens per analysis] * [price per token] = daily cost

Step 7: Write your model selection recommendation (1 page)

Based on your data: for a SOC phishing triage workflow, what is the right model + prompt combination? Justify using accuracy, cost, and CCT principles (specifically: what is the cost of a false positive? A false negative?).

Going Deeper — Explore What the Lecture Introduced

Explore on your own (optional but recommended):

Transformer architecture: Ask Claude to explain the attention mechanism in a transformer model in terms of what it means for security analysis — what does "attention" actually compute?
Context window comparison: Research current context window sizes for Claude Sonnet, GPT-4o, and Gemini 1.5 Pro. What does a 200K token context window actually enable?
Open source model tradeoffs: Ask Claude to compare running a local Llama model vs. using the Claude API for a security use case. What are the tradeoffs around privacy, cost, and capability?
Privacy tradeoffs: What data should never leave your network, even to a trusted AI API provider? Build a quick classification: (a) safe to send, (b) anonymize first, (c) never send.

Extension: Context budget logging — Add a counter to your agent that logs the token count before and after each tool call. When does context grow fastest? What types of tool results are most expensive? Observe the pattern before optimizing. You can surface this with Claude's API response metadata (usage.input_tokens), or prompt Claude Code to estimate token counts per step. Document your findings in a brief note: which steps are the most expensive context contributors, and which are cheap?

Extension: Context window stress test — Take your working agent and deliberately fill the context with a long conversation history. At what point does response quality degrade? At what point does cost per call make the agent economically unviable? Document your findings in a one-paragraph note. Suggested approach: add 10–15 turns of prior conversation to the context before your main analysis prompt, and compare output quality against a clean-context run. This is not a theoretical exercise — context bloat in multi-turn agent workflows is one of the most common production failure modes.

Week 3 Deliverables

model-comparison.md — comparison matrix across approaches, including false positive test results
Model Selection Recommendation (1 page) — justified recommendation with cost analysis
CCT Journal Entry — how did testing force you to think more carefully about the cost of AI errors in security?

Week 4 — Context Engineering

WEEK 4Lab: Building a Security Analyst System Prompt

Lab Goal: Apply context engineering principles to build a reusable, high-quality system prompt for a security analyst agent. Empirically measure how engineering the context improves output quality versus a naive approach.

Lab Exercise: Engineering a Security Analyst System Prompt

Step 1: Create a Version 1 minimal system prompt

Create v1-system-prompt.md with only: "You are a security analyst. Analyze security incidents and provide recommendations." Test this against the Meridian Financial incident from Week 1.

mkdir -p ~/noctua-labs/unit1/week4
# Create v1-system-prompt.md with minimal prompt
# Test in Claude Code by starting with:
claude
# Then: "Using system prompt: [v1 text]. Now analyze: [incident data]"

Step 2: Document V1 output quality

Record: Does V1 use CCT structure? Does it separate observations from inferences? Does it ask clarifying questions? Does it flag ethical considerations? Does it produce structured output? Rate each 1-5.

Step 3: Apply context engineering — build Version 2

Create v2-system-prompt.md incorporating: (1) detailed role definition with expertise scope, (2) required CCT structure for all analyses, (3) JSON output schema, (4) explicit constraints (what NOT to do), (5) escalation criteria. See the structure below.

# v2-system-prompt.md structure:

## Role
You are a senior security analyst and incident responder with 10+
years of experience. You specialize in threat hunting, digital
forensics, and AI-augmented security operations.

## Operating Principles
- ALWAYS separate observations (Layer 1) from inferences (Layer 2)
  from hypotheses (Layer 3) from conclusions (Layer 4)
- NEVER attribute malicious intent without supporting evidence
- ALWAYS list what information is missing before concluding
- ALWAYS provide alternative innocent explanations
- ALWAYS address ethical implications of your recommendations

## Required Output Format
{
  "observations": [],
  "inferences": [],
  "top_3_hypotheses": [{"narrative": "", "probability": 0, "supporting_evidence": []}],
  "missing_information": [],
  "next_steps": [],
  "ethical_considerations": "",
  "recommendation": "",
  "confidence": 0
}

## Escalation Criteria
Escalate to incident commander if: evidence suggests active exfiltration
in progress, evidence of lateral movement, or data volume exceeds 1GB.

Step 4: Test V2 against the same Meridian Financial incident

Use the same incident data as Step 1. Apply V2 system prompt in your Claude Code session. Compare the output quality against your V1 ratings.

Step 5: Rate V2 across the same dimensions

Re-rate V2 outputs 1-5 across: CCT structure, observation/inference separation, clarifying questions, ethical considerations, output structure. Calculate improvement delta V1 → V2.

Step 6: Add tool definition stubs to your system prompt

Add a "Available Tools" section to V2 listing: query_siem(time_range, account), lookup_ip(ip_address), get_user_profile(username), query_dlp_logs(account, date_range). Retest — does Claude now reference these tools in its recommendations?

Step 7: Save your context-engineered template

Save security-analyst-context-v2.md as your reusable template. You will use this as the foundation for your MCP server system prompt in Unit 2.

Step 8: Write your context engineering reflection

Document: What was the V1 → V2 improvement score? What specific elements of context engineering made the biggest difference? Which of the Core Four (Prompt, Model, Context, Tools) did you modify, and how?

Week 4 Deliverables

v1-system-prompt.md and security-analyst-context-v2.md — both versions with documented rating scores
Context Engineering Report (1-2 pages) — V1 vs. V2 comparison, what changed, quantified improvement
Context Library Template — your reusable security analyst context file that you will build on throughout the course

Why you're creating CLAUDE.md here. In this lab, you're using Claude Code to review your own work from earlier weeks. CLAUDE.md tells Claude what kind of project this is, what your role is, and what context to bring to every session. Without it, Claude starts every conversation cold. With it, Claude enters already oriented. You'll update this file throughout the course as your project evolves.

CLAUDE.md vs. Context Library — what's the difference?

	CLAUDE.md	Context Library
What it is	Project file Claude Code auto-loads	Your portable collection of reusable patterns
When it loads	Every Claude Code session in that directory	When you explicitly feed it to the model
Scope	Project-specific	Portable across projects and platforms
Platform	Claude Code only	Any AI platform
Analogy	Standing orders for a specific office	Your professional playbook you carry everywhere

Use CLAUDE.md for project-specific context. Use your context library for reusable analyst patterns and system prompts you want available anywhere.

Save Your Context Permanently — Create a CLAUDE.md

You now have a context library. Teach Claude Code to load it automatically. Create a CLAUDE.md file in your project root — Claude Code reads it at the start of every session before you type a single word. Put your context library references, working standards, and architectural preferences there. You'll never have to re-explain your style to a new session again.

Use this prompt right now:

Based on the context library files I just built, write a CLAUDE.md that Claude Code should auto-load at the start of every security project session. Include my analyst system prompt reference, CCT framework, and output format standards.

Unit 1 Complete

You have worked through all four weeks of CCT Foundations & AI Landscape labs.

Topics introduced this unit that return later:

Slash commands (/think, /build-spec, /worktree-setup, /retro, /harness-assess) — introduced briefly; full coverage in Unit 4
MCP server configuration — you'll build your first MCP server in Unit 2
RAG and retrieval — introduced as a concept; you'll build a RAG system in Unit 2 Week 8
Open source model deployment — tradeoffs covered here; production deployment is a Semester 2 topic
CLAUDE.md as ongoing memory — created in Week 4; you'll evolve it throughout the course

Two harnesses — one concept, two different jobs

You will encounter the word "harness" throughout this course. It always means the same thing — the system of controls that shape and constrain agent behavior — but it refers to two distinct contexts that are easy to confuse:

Harness	What it constrains	Lives in	When you build it
Development	Claude while you work — what it can read, write, and run in your session	`.claude/settings.json`, `.claude/hooks/`	Unit 1 setup, evolved throughout
Deployment	The agent you ship — what it validates, filters, and enforces in production	`harnesses/<agent>/blueprint.yaml`, `fixed_steps/`	Unit 7 and Unit 8 only

They use the same enforcement vocabulary — hooks, deny rules, deterministic pipelines — but they protect different things. The development harness protects you and your codebase. The deployment harness protects the users and systems your agent operates in.

What you mastered

CCT 5 pillars and how to apply them to AI-generated outputs
Context engineering as a first-class design decision
AI model landscape: capabilities, costs, tradeoffs
CLAUDE.md vs. context library distinction

What was introduced (returns in later units)

Slash commands and Claude Code skills (Unit 4)
MCP architecture and tool design (Unit 2)
RAG and knowledge retrieval (Unit 2)
Cedar policy enforcement (Unit 3)

What's waiting next

Unit 2 moves from interacting with Claude to building with it — you'll design and deploy your first MCP server, giving Claude access to real security tools.

Before starting Unit 2 — verify your setup:

Python 3.10 or higher installed
Claude Code installed and authenticated (claude --version works)
Anthropic API key configured in your environment
uv or pip available for package management
Git configured with your name and email
A code editor ready (VS Code recommended)

If any of these are missing, set them up before Week 5. Unit 2 Day 2 starts with running Python code.

Next: Unit 2 Lab Guide — Agent Tool Architecture →

Lab Guide: Unit 1 — CCT Foundations & AI Landscape

Week 1 — First AI-Assisted Investigation & CCT Incident Analysis

Knowledge Check — Before You Start

Lab Exercise: Meridian Financial Incident Analysis

Week 1 Deliverables

Week 2 — Cognitive Bias & CCT Deep Dive

Knowledge Check — Week 2

Lab Exercise: Bias Identification & CCT Rewrite

Week 2 Deliverables

Week 3 — Modern AI Landscape for Security

Knowledge Check — Week 3

Lab Exercise: Phishing Email Analysis Comparative Study

Week 3 Deliverables

Week 4 — Context Engineering

Knowledge Check — Week 4

Lab Exercise: Engineering a Security Analyst System Prompt

Week 4 Deliverables

Unit 1 Complete