High School IntermediateModule I1Lesson 1 of 8

I1.1 Network Models and Defensive Thinking

Use the OSI and TCP/IP models to organize fictional network evidence, identify where communication may be failing, map defensive controls, and explain conclusions without overclaiming.

Back to ModuleIntermediate TrackNext Lesson

Lesson Progress

Network Models and Defensive Thinking

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

13% complete

Readiness Check

Before You Start

0/4 ready

Professional Hook

A Browser Error Can Begin at the Cable, the VLAN, the IP Route, the Service Port, the Session, or the Application

When a user reports that “the website is broken,” an intermediate defender does not immediately blame the website. The device may have no link, the wrong network segment, an invalid address, a missing route, a blocked service, an expired certificate, an interrupted session, or an application error. Network models help the defender test these possibilities in an organized order.

Weak response

“The site failed, so disable the firewall and change several settings until it works.”

Strong response

“Preserve the symptom, check evidence layer by layer, correlate the records, identify the lowest confirmed failure, and make only an authorized change.”

Objective 1

Compare the OSI and TCP/IP models without treating either model as a perfect picture of every real network.

Objective 2

Map devices, protocols, services, evidence sources, and defensive controls to the layers where they are most useful.

Objective 3

Use layered reasoning to narrow a fictional connectivity or security problem instead of guessing from one alert.

Objective 4

Separate confirmed evidence, reasonable conclusions, missing context, and actions that require authorization.

Why This Matters

Layered Reasoning Reduces Guessing, Missed Evidence, and Disruptive Changes

Security teams often receive incomplete reports such as “the app is slow,” “the login failed,” or “this destination looks unusual.” Models help teams separate local connectivity, addressing, routing, transport, sessions, encryption, and application behavior. This makes communication clearer and helps defenders choose safer, narrower actions.

Visual Model

The OSI Model as a Defensive Reasoning Map

The layers do not replace real architecture diagrams or logs. They help defenders ask organized questions about where communication, evidence, and controls may belong.

7

Layer

Application

Main responsibility

Provides network functions used by applications and users, such as web access, name resolution, and email.

Examples and evidence

Examples: HTTP/S, DNS, SMTP concepts, application requests

Evidence: Application logs, web requests, DNS queries, authentication events, service errors

Defender question

Which application or service created the activity, and was the request expected?

6

Layer

Presentation

Main responsibility

Represents, transforms, encrypts, compresses, or formats information so systems can interpret it.

Examples and evidence

Examples: TLS concepts, certificates, encoding, data formats

Evidence: Certificate details, encryption status, protocol negotiation, format errors

Defender question

Was the data protected and represented in an expected way?

5

Layer

Session

Main responsibility

Establishes, maintains, and ends communication sessions between applications.

Examples and evidence

Examples: Login sessions, session timeouts, reconnection concepts

Evidence: Session IDs, login duration, timeout events, repeated reconnects

Defender question

Does the session match the expected user, device, duration, and purpose?

4

Layer

Transport

Main responsibility

Moves data between applications using transport protocols, ports, reliability, and connection state.

Examples and evidence

Examples: TCP, UDP, source ports, destination ports

Evidence: Port numbers, connection state, resets, retransmissions, allowed or denied service

Defender question

Which service port and transport behavior are involved?

3

Layer

Network

Main responsibility

Uses logical addresses and routing decisions to move traffic between networks.

Examples and evidence

Examples: IPv4, IPv6 concepts, routing, subnets

Evidence: Source and destination IP addresses, routes, gateways, subnet context

Defender question

Which networks are communicating, and should this path exist?

2

Layer

Data Link

Main responsibility

Moves frames within a local network and identifies local interfaces.

Examples and evidence

Examples: Ethernet, Wi-Fi, MAC addresses, switches, VLAN concepts

Evidence: MAC addresses, switch-port records, VLAN assignment, local link events

Defender question

Which local device, switch path, or VLAN carried the traffic?

1

Layer

Physical

Main responsibility

Carries signals through cables, radio, ports, and physical network equipment.

Examples and evidence

Examples: Cables, wireless signals, network interfaces, link state

Evidence: Link up or down, signal quality, interface state, hardware alarms

Defender question

Is the physical connection available and functioning as expected?

Intermediate habit: begin with the evidence you can confirm, move through the layers carefully, and avoid blaming a higher layer before checking the lower dependencies it needs.

Core Concept

Every Higher Layer Depends on Services Below It

An application cannot reach a remote service without lower-layer communication. However, a working lower layer does not guarantee that every higher layer is functioning or trustworthy. For example, a device can have a working wireless link, valid address, successful DNS response, and allowed HTTPS connection while the application still rejects the login.

Reasoning rule: evidence at one layer confirms only what that evidence actually supports. It should not be stretched into a conclusion about every other layer.

Key Vocabulary

Intermediate Terms for Layered Network Analysis

Network model

A conceptual framework that separates communication into layers so people can describe, design, troubleshoot, and defend networks more consistently.

Layer

A group of related networking responsibilities. Each layer serves the layer above it and depends on the layer below it.

Protocol

A defined set of communication rules used by systems or applications.

Encapsulation

The process of adding layer-specific information as data moves down a networking model before transmission.

Decapsulation

The process of reading and removing layer-specific information as received data moves upward toward an application.

Service

A network-accessible function such as web access, name resolution, address assignment, email, or file sharing.

Observability

The ability to understand system behavior through logs, metrics, traces, alerts, diagrams, and other evidence.

Trust boundary

A point where data, users, devices, or services move between areas with different security expectations or access rules.

Control

A safeguard that helps prevent, detect, respond to, or recover from risk.

Correlation

Connecting evidence from multiple sources, layers, devices, users, and timestamps to build a supported explanation.

Model Comparison

OSI and TCP/IP Describe Similar Responsibilities Differently

The OSI model uses seven layers and is useful for detailed explanation. The TCP/IP model groups responsibilities into fewer layers and more closely reflects common internet architecture discussions.

Application

OSI Layers 5–7

Application services, data representation, encryption concepts, and sessions.

HTTPS, DNS, email concepts, authentication sessions, certificates

Transport

OSI Layer 4

Application-to-application delivery, ports, reliability, and connection state.

TCP, UDP, source ports, destination ports

Internet

OSI Layer 3

Logical addressing and routing traffic between networks.

IP addresses, routers, gateways, subnets

Network Access

OSI Layers 1–2

Local delivery, frames, interfaces, switching, Wi-Fi, cables, and signals.

Ethernet, MAC addresses, VLANs, wireless links

A protocol, tool, or event may involve more than one layer. The goal is not to force every detail into one box; the goal is to organize the strongest available evidence.

Evidence Analysis

What Different Evidence Sources Can and Cannot Prove

Intermediate defenders avoid overclaiming. Every evidence source is useful, but each has limits.

Evidence source

Application log

Strongest layer context

Application

Can support

User action, requested resource, application result, service error, or authentication context.

Cannot prove alone

The complete network path or the identity of every system by itself.

Evidence source

DNS record

Strongest layer context

Application

Can support

A device requested a name and received or failed to receive a response.

Cannot prove alone

That the later connection succeeded or that the destination was trustworthy.

Evidence source

Firewall record

Strongest layer context

Network / Transport

Can support

Source, destination, protocol, port, direction, rule decision, and time.

Cannot prove alone

What the user intended or what the application displayed.

Evidence source

DHCP record

Strongest layer context

Network context

Can support

Which fictional device received an address during a specific time window.

Cannot prove alone

That every later action from the address belonged to the expected user.

Evidence source

Switch or VLAN record

Strongest layer context

Data Link

Can support

Local interface, MAC address, switch port, or network-segment assignment.

Cannot prove alone

The full application purpose by itself.

Evidence source

Endpoint alert

Strongest layer context

Host / Application context

Can support

A process, file, user, or local connection associated with the device.

Cannot prove alone

That all related network activity was malicious without correlation.

Defensive Workflow

Use the Layers to Narrow the Problem

1

Start with the symptom

State what was observed without adding assumptions: failed connection, unusual destination, repeated login, or denied service.

2

Find the lowest confirmed layer

Check whether the link, local network, address, route, service port, session, and application each have supporting evidence.

3

Move upward carefully

Do not blame an application when the device lacks a valid address, and do not blame the network when the application rejected the request.

4

Correlate across sources

Connect DHCP, DNS, firewall, endpoint, application, identity, and change records using device and time context.

5

Choose a proportionate action

Document, monitor, correct an approved configuration, contain, or escalate according to evidence and authority.

Fake Dashboard

Fake Layered Connectivity Dashboard

Training dashboard for the fictional Northstar Learning Network. It combines local link, VLAN, DHCP, DNS, firewall, TLS, session, and application evidence.

Physical and local link

Healthy

Wireless association is stable and the device is visible on a switch-managed access point.

Address and DNS

Healthy

The device received a valid fictional address and resolved portal.training.test.

HTTPS service

Denied

The firewall classified the device in the guest zone instead of the student-lab zone.

Fake SOC Alert

Approved Training Portal Unreachable After Network Change

Source: Fake Service Monitoring • Time: 09:08 AM

Medium Severity
A fictional student-lab device has a healthy wireless link, valid address, successful DNS response, and repeated denied HTTPS attempts after a documented segmentation change.
Defensive recommendation: Preserve the records, compare VLAN and firewall-zone assignments with the approved change, confirm ownership, and escalate the likely configuration mismatch.

Fake Log Panel

Fake Multi-Layer Evidence Timeline

training-log-viewer.log
09:01:52 PHYSICAL interface='wlan0' link_state='up' signal='good'
09:02:04 DATA_LINK device='student-lab-17' vlan='30' mac='02:42:ac:11:00:17'
09:02:08 NETWORK dhcp_address='10.42.16.57' gateway='10.42.16.1' lease='active'
09:02:31 APPLICATION dns_query='portal.training.test' response='198.51.100.42'
09:02:34 TRANSPORT protocol='tcp' destination_port='443' state='attempted'
09:02:34 FIREWALL source_zone='guest' destination='training_portal' action='deny'
09:05:10 CHANGE approved='true' title='student-lab segmentation update'
09:08:03 CORRELATION expected_zone='student-lab' observed_zone='guest' confidence='high'

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

Analyze the Evidence

Which Layered Explanation Is Best Supported?

The fictional device has a stable wireless link and appears in VLAN 30.
DHCP assigned a valid fictional address and gateway.
DNS successfully resolved the approved training portal.
HTTPS attempts were denied because the firewall classified the source as guest.
The approved change says VLAN 30 should map to the student-lab zone.

What is the strongest defensive conclusion and next action?

Common Mistakes

Mistakes That Weaken Layered Analysis

Treating the OSI model as a literal picture of every real device instead of a reasoning framework.
Assuming one log source contains the entire explanation.
Jumping directly to the application layer before confirming link, address, route, and service context.
Assuming a successful DNS response proves the website connection also succeeded.
Assuming an allowed firewall event proves the application request was legitimate.
Confusing a protocol with the application or business purpose that uses it.
Changing network settings without authorization, documentation, testing, and rollback planning.
Ignoring timestamps, time zones, device identity, or approved change records during correlation.

Safe Practice Lab

Build a Layered Evidence Map for a Fictional Service Failure

Fictional Case

Eastview Media Lab Upload Service

A fictional media-lab device can reach the local network and resolve the upload service name, but large approved uploads fail after a network policy update. The evidence set contains a diagram, DHCP record, DNS response, firewall decision, service log, user report, and change ticket.

Required Analysis

  1. Sort each evidence item by its strongest layer context.
  2. Record what each item confirms and what it cannot prove.
  3. Identify the lowest layer with evidence of failure.
  4. Connect device, address, user, service, and timestamps.
  5. Compare the event with the approved policy change.
  6. Write a conclusion with confidence and missing evidence.
  7. Recommend only an authorized, reversible next action.
Do not use real packet captures, live network tools, real addresses, private diagrams, or production settings. The goal is evidence reasoning, not interaction with a real network.

Scenario Decision Lab

DNS Works, but the HTTPS Connection Is Denied

A fictional device receives a valid address, resolves the approved service name, and then receives a firewall denial for TCP destination port 443. The device belongs to an approved group, but the source zone in the firewall log appears incorrect.

Scenario Decision Lab

The Network Connection Succeeds, but the Application Rejects the Login

A fictional browser reaches the approved HTTPS service, the certificate is valid, and the application displays an account-disabled message. Identity records show the user was intentionally disabled during an approved offboarding test.

Defender Habits

Layered Network Analysis Checklist

Check Your Understanding

I1.1 Mini Quiz: Network Models and Defensive Thinking

Choose your answers first. Explanations appear only after submission.

1. Why do defenders use network models?

2. Which OSI layer is most closely associated with IP addressing and routing?

3. Which evidence most directly helps confirm local VLAN or switch placement?

4. What does a successful DNS lookup prove?

5. What is the strongest response to a fictional connection failure?

6. Why can a firewall allow record not prove that an action was safe?

7. Which statement best describes correlation?

Portfolio Prompt

Portfolio Prompt

Create a two-page fictional Layered Network Defense Analysis. Page one should contain a labeled OSI or TCP/IP diagram showing devices, trust boundaries, services, evidence sources, and defensive controls. Page two should explain one fictional connectivity or security event layer by layer, including confirmed facts, evidence limits, correlation, confidence, missing context, recommended action, authorization owner, and validation steps.

Use only fictional systems, users, addresses, domains, logs, diagrams, and organizations.
Show what each evidence source supports instead of claiming that one source proves the entire case.
Include at least one trust boundary, one preventive control, one detective control, and one documented response step.
Do not include real IP addresses, private network diagrams, credentials, live captures, or production configuration details.

Key Takeaways

What You Should Remember

1.The OSI and TCP/IP models organize networking responsibilities, evidence, controls, and communication.
2.A working lower layer is necessary but does not guarantee that every higher layer is working or trustworthy.
3.DNS, firewall, endpoint, switch, identity, and application records each provide partial evidence with limits.
4.Layered analysis starts with the symptom, confirms the lowest supported layer, and moves upward carefully.
5.Intermediate defenders correlate multiple sources, state uncertainty honestly, and recommend only authorized actions.

Navigation

Continue Module I1

Back to ModuleIntermediate TrackNext: I1.2 IP Addressing, Subnets, and Network Boundaries