High School IntermediateModule I1Lesson 8 of 8

I1.8 Network Defense Analysis Lab

Complete a full fictional investigation using architecture, addressing, DNS, DHCP, services, firewall, segmentation, endpoint, identity, monitoring, and change evidence.

Previous Lesson Back to Module Module Test

Lesson Progress

Network Defense Analysis Lab

High School Intermediate • I1: Networking for Defenders • Lesson 8 of 8

100% complete

Readiness Check

Before You Start

0/5 ready

Capstone Hook

Explain the Whole Path, Not Just the Loudest Alert

A device may have a healthy link, correct VLAN, successful DNS response, and active application process, yet still fail because it received an address from the wrong scope and was placed in the wrong firewall zone. The strongest investigation traces every layer and corrects the earliest supported mismatch.

Weak response

“The firewall denied traffic, so disable the firewall.”

Strong response

“Preserve evidence, trace the path, compare design and observed state, identify the first supported mismatch, and correct only the approved cause.”

Objective 1

Correlate fictional architecture, addressing, DNS, DHCP, firewall, endpoint, identity, and change evidence.

Objective 2

Build a defensible timeline using device, address, service, zone, owner, and timestamp context.

Objective 3

Separate confirmed facts, likely explanations, missing evidence, and unsupported assumptions.

Objective 4

Identify the earliest supported mismatch instead of changing the loudest control.

Objective 5

Write a concise network-defense report with confidence, impact, ownership, validation, and rollback.

Why This Matters

Network Defense Requires Correlation, Prioritization, and Validation

Security teams rarely receive one perfect answer. They combine architecture, configuration, identity, application, and event evidence while protecting availability, preserving logs, respecting ownership, and communicating clearly.

Investigation Workflow

Six Phases of Safe Network Analysis

Scope

Define the fictional environment, affected systems, time window, authority, evidence, and prohibited actions.

Preserve

Record original logs, diagrams, rules, leases, identities, and changes before recommending corrections.

Correlate

Connect device, user, address, VLAN, subnet, DNS, service, firewall, endpoint, and timeline evidence.

Compare

Check observed behavior against approved architecture, dependencies, ownership, and change plans.

Decide

Choose the narrowest proportionate action: monitor, correct, restrict, validate, recover, or escalate.

Communicate

Document findings, confidence, impact, uncertainty, owner, next steps, rollback, and lessons learned.

Evidence Sources

Use Multiple Sources Without Overclaiming

Architecture diagram

Value: Shows intended zones, subnets, services, controls, and approved flows.

Limit: Does not prove the current configuration or observed traffic.

DHCP and VLAN records

Value: Connect a device to an address, prefix, gateway, scope, VLAN, and lease window.

Limit: Do not prove the identity or purpose of every later action.

DNS records

Value: Show requested names, answers, response codes, resolvers, TTLs, and time.

Limit: Do not prove a later connection or application result.

Firewall evidence

Value: Shows zones, addresses, protocol, service, action, matched rule, and time.

Limit: Does not prove complete intent, ownership, or application content.

Endpoint telemetry

Value: Connects a local user, process, interface, and connection.

Limit: Does not prove every control decision along the network path.

Identity and inventory

Value: Shows expected owner, role, device group, environment, and sensitivity.

Limit: May be stale and must be compared with technical evidence.

Change records

Value: Shows approved reason, timing, owner, testing, and rollback.

Limit: Does not prove implementation matched the approved plan.

Monitoring records

Value: Shows alerts, collection health, affected population, and recurrence.

Limit: Missing records may indicate a visibility failure rather than no activity.

Integrated Case

Harborview Media Lab Upload Failure

User report

A fictional media-lab device cannot upload approved coursework after a network change.

Device identity

media-lab-08 is a managed device assigned to the student-media group.

Observed address

DHCP assigns 10.44.20.93/26 with gateway 10.44.20.65 from media-scope-b.

Expected design

The approved diagram requires 10.44.20.0/26 with gateway 10.44.20.1.

DNS evidence

uploads.media-training.test resolves successfully to 192.0.2.80.

Firewall evidence

HTTPS is denied because the source is classified in the guest zone.

Segmentation evidence

The expected VLAN is correct, but the address-to-zone mapping is inconsistent.

Change evidence

A DHCP scope split occurred shortly before the issue and validation was incomplete.

Fake Dashboard

Fake I1 Network Defense Case Dashboard

Integrated training dashboard for the fictional Harborview Media Lab case.

Local connectivity

Healthy

Interface, switch port, and expected VLAN evidence are normal.

Address placement

Incorrect

The device received an address and gateway from the wrong /26 DHCP scope.

Application path

Denied

DNS succeeds, but the firewall applies the guest-zone policy and denies HTTPS.

Fake SOC Alert

Approved Media Upload Blocked by Scope-to-Zone Mismatch

Source: Fake Integrated Network Defense Monitor • Time: 10:22 AM

High Severity

A fictional managed media-lab device received 10.44.20.93/26 and gateway 10.44.20.65 after a DHCP scope split. The correct VLAN is present, DNS succeeds, but the firewall classifies the source as guest and denies HTTPS.

Defensive recommendation: Preserve evidence, confirm the approved first-/26 design, have the responsible owner correct the DHCP scope or zone mapping, renew the lease, validate the expected subnet and zone, retest HTTPS, and monitor for recurrence.

Fake Log Panel

Fake Integrated Investigation Timeline

training-log-viewer.log

09:58:00 CHANGE title='media-lab DHCP scope split' approved='true' validation='partial'
10:05:11 INVENTORY device='media-lab-08' group='student-media' expected_subnet='10.44.20.0/26'
10:06:02 LINK interface='wlan0' state='up' signal='good'
10:06:04 SWITCH device='media-lab-08' vlan='220' status='expected'
10:06:08 DHCP device='media-lab-08' address='10.44.20.93' prefix='/26' gateway='10.44.20.65' scope='media-scope-b'
10:06:31 DNS query='uploads.media-training.test' answer='192.0.2.80' status='success'
10:06:33 ENDPOINT process='media-uploader.exe' destination='192.0.2.80:443/tcp'
10:06:33 FIREWALL source='10.44.20.93' source_zone='guest' destination='192.0.2.80' service='https' action='deny'
10:11:20 DESIGN vlan='220' intended_subnet='10.44.20.0/26' intended_gateway='10.44.20.1' intended_zone='student-media'
10:18:07 MONITORING similar_devices_affected='6' first_seen='after_scope_split'
10:22:14 CORRELATION finding='incorrect_DHCP_scope_or_zone_mapping' confidence='high'

Training note: this is fake data for defensive analysis practice only.

Evidence-Based Decisions

Answer the Investigation Questions in Order

Is local connectivity working?

Yes

Interface, switch, and expected VLAN evidence are healthy.

Did the device receive an address?

Yes, but from the wrong subnet

10.44.20.93/26 belongs to 10.44.20.64/26 rather than the expected first /26.

Does DNS work?

Yes

The approved service name resolves successfully.

Is the required service permitted?

The firewall applies the guest-zone policy and denies HTTPS.

Is the firewall necessarily wrong?

Not proven

The rule may be correct for guest traffic; the stronger mismatch is the source classification.

Highest-confidence finding

Scope or zone-mapping error

Address, gateway, zone, design, timing, and change evidence support the same explanation.

Analyze the Evidence

Which Final Finding Is Best Supported?

The fictional device is approved, managed, and assigned to the student-media group.

The interface and expected VLAN are healthy.

The device receives 10.44.20.93/26 and gateway 10.44.20.65 from media-scope-b.

The approved design requires 10.44.20.0/26, gateway 10.44.20.1, and the student-media zone.

DNS succeeds and the endpoint attempts HTTPS to the approved upload service.

The firewall classifies the source as guest and denies the connection.

Six similar devices show the same problem after the approved DHCP scope split.

What is the strongest final conclusion and next action?

Defensive Reporting

Structure the Final Report

Finding

State the technical issue in one evidence-based sentence.

Evidence

List the exact fictional records and timestamps supporting the finding.

Impact

Explain affected users, systems, services, and approved workflows.

Confidence

Use high, medium, or low confidence and explain why.

Missing evidence

Identify unanswered questions, unavailable logs, or validation gaps.

Recommended action

Name the narrowest authorized correction or escalation step.

Owner

Identify the team or role responsible for approval and implementation.

Validation and rollback

Define success criteria, monitoring, and how to reverse the change.

Common Mistakes

Mistakes That Weaken a Full Investigation

Changing the firewall before confirming the source-zone assignment.

Assuming DNS failed because the upload page did not work.

Ignoring the prefix length and missing the subnet boundary.

Treating the assigned IP address as permanent proof of one user.

Assuming the VLAN and firewall zone are identical concepts.

Failing to preserve the original lease, rule, logs, and change evidence.

Using only one source instead of comparing architecture and observed activity.

Calling the event malicious without evidence of hostile intent.

Making several changes at once and losing the ability to validate the actual cause.

Publishing real addresses, rules, diagrams, or internal architecture.

Integrated Safe Lab

Complete the Harborview Network Defense Case

Your role

Authorized Junior Network Defender

Analyze the supplied fake evidence, write conclusions, and recommend actions. Do not alter any real or fictional production system directly.

Required deliverables

One-page incident summary.
Evidence table with source, timestamp, value, and limitation.
Layered network path from device to application.
Address and subnet analysis.
DNS, DHCP, service, and firewall correlation.
Confidence statement and missing-evidence list.
Authorized correction, validation, rollback, and monitoring plan.

All work must remain fictional and defensive. Do not use real packet captures, scanners, diagrams, firewall exports, credentials, addresses, or production settings.

Scenario Decision Lab

The Team Wants to Disable the Firewall Rule

A fictional team member argues that the firewall denial is the cause and suggests disabling the rule before reviewing the DHCP scope, zone mapping, or approved design.

Scenario Decision Lab

One Device Remains in the Wrong Scope

After an authorized correction, most fictional devices receive the expected first-/26 addresses and upload successfully. One device remains in the second /26 range.

Defender Habits

Integrated Network Defense Analysis Checklist

Check Your Understanding

I1.8 Mini Quiz: Network Defense Analysis Lab

Choose your answers first. Explanations appear only after submission.

1. Which finding is best supported by the evidence?

2. Why preserve the original evidence before correction?

3. What does the successful DNS response prove?

4. What is the safest correction approach?

5. Why state confidence in a report?

6. Which source best confirms address assignment during the event window?

7. What should happen after the approved correction?

Portfolio Prompt

Create a complete fictional Network Defense Investigation Report for the Harborview Media Lab case. Include executive summary, scope, architecture diagram, evidence inventory, timeline, subnet analysis, DNS and DHCP findings, firewall and segmentation analysis, root-cause statement, confidence, impact, missing evidence, recommended correction, validation, rollback, monitoring, ownership, communication, and lessons learned.

Use only fictional organizations, devices, identities, services, rules, logs, diagrams, and documentation address ranges.

Make each conclusion traceable to specific evidence.

State evidence limits and uncertainty clearly.

Do not include real addresses, internal names, firewall exports, packet captures, credentials, or production architecture.

Key Takeaways

What You Should Remember

1.Strong network investigations correlate architecture, addressing, DNS, DHCP, firewalls, segmentation, endpoint, identity, monitoring, and change evidence.

2.The earliest supported mismatch is often more important than the loudest alert.

3.A firewall denial may be correct when an endpoint is placed in the wrong zone or subnet.

4.Evidence must be preserved before correction and compared again during validation.

5.Defenders communicate facts, confidence, impact, uncertainty, ownership, and next actions clearly.

6.Safe corrections are narrow, authorized, documented, reversible, validated, monitored, and followed by updated documentation.

Navigation

Complete Module I1

Previous: I1.7 Reading Safe Network Diagrams Back to Module Next: I1 Module Test