═══════════════════════════════════════════════════════════════════ RESTRICTED DISTRIBUTION — DICDP PROGRAM PARTICIPANTS ONLY ═══════════════════════════════════════════════════════════════════

═══════════════════════════════════════════════════════════════════

 RED IRISH GLOBAL SERVICES

 Defense Information Capacity Development Program (DICDP)

 Communications and Information Systems (CIS) Track — Foundation Level

 Foundation Networking Course | Day 02 Lab

 Document ID:        DICDP-CIS-FNC-D02-LAB-v3

 Issued:             [date of determination]

 Controlled by:      Program Director, DICDP, Red Irish Global Services

 Redirect requests:  ops@redirish.global

 Distribution:       RESTRICTED — Program participants only

═══════════════════════════════════════════════════════════════════

Restricted Distribution Statement

This material is the intellectual property of Red Irish Global Services. Distribution is authorized only to participants enrolled in the Defense Information Capacity Development Program (DICDP). Reproduction, transmission, posting to public networks or social media, sharing with non-participants, or use as the basis for derivative training materials, in whole or in part, requires prior written authorization from Red Irish Global Services. Other requests shall be referred to: ops@redirish.global

Day 2 — Lab: OSI Layers, PPSM Boundaries, and Protocol Verification

Document ID: DICDP-CIS-FNC-D02-LAB-v3 Version: v3.0

Opening — Applying What You Learned Today

This morning you learned the OSI model through the DoD lens — seven layers, each with universal protocols plus DoD-specific discipline. This afternoon you learned PPSM (the 16-boundary documentation framework that controls every port and protocol crossing a DoDIN boundary) and the trust nothing, verify everything methodology — the analytical discipline a DoD networking professional applies before approving any new system.

This lab takes both pieces and puts them in your hands.

Part 1 uses Packet Tracer to make the OSI model concrete. You will build a small DoD-structured NIPRNet network with correct naming, trace packets through each OSI layer using simulation mode, add classification separation, and label PPSM boundary crossings. The exercise reinforces the morning lecture's Layer-by-Layer DoD additions and the afternoon lecture's PPSM boundary model.

Part 2 applies the trust-nothing-verify-everything methodology to real packet data. You will inspect an actual SSH/SFTP session and answer the questions a network analyst must answer before authorizing the protocol on a DoD network: is it really what it claims to be, are the cryptographic algorithms acceptable, where does the application actually connect, and how do you write an honest PPSM declaration based on what you observed.

• Option A uses Wireshark with a pre-captured .pcap file provided by the instructor. This is the preferred option — it puts real packet data in front of you, exactly as the SFTPGo walkthrough in the Afternoon lecture demonstrated.

• Option B is a Packet Tracer only fallback. It covers the same analytical questions using simulation mode and structured analysis worksheets. Use this if Wireshark is not available in your environment.

Tools required:

• Packet Tracer — all students, both parts

• Wireshark — Part 2 Option A only (free download at wireshark.org)

• Instructor-provided capture file: day02_sftp_analysis.pcap (Part 2 Option A)

Duration: 90 minutes total — 45 minutes Part 1, 45 minutes Part 2.

PART 1 — Packet Tracer: OSI Layers in a DoD Network

Objectives

By the end of Part 1 you will be able to:

• Build a small DoD-structured NIPRNet network in Packet Tracer with correct naming

• Use Simulation Mode to trace a packet through multiple OSI layers

• Identify the PDU name at each layer from direct observation

• Label PPSM boundary crossings on a network diagram

• Explain which OSI layer each observed protocol belongs to

Exercise 1 — Build the Topology

Scenario: You are standing up a small NIPRNet communications cell. It has two user workstations, one switch, one router as the Installation Gateway, and a connection to the DISN.

Step 1 — Add devices and apply DoD naming

Open a new Packet Tracer workspace and place the following devices. Name each one exactly as shown — naming is a documentation requirement, not optional.

Device	Packet Tracer Type	Assign this name
User workstation 1	PC	WS-NIPR-01
User workstation 2	PC	WS-NIPR-02
Building switch	2960 Switch	SW-BAN-NIPR-01
Installation Gateway router	1941 Router	RTR-IG-01
DISN (upstream)	Cloud	DISN-DISA

Step 2 — Connect the devices

From	To	Cable type
WS-NIPR-01 FastEthernet0	SW-BAN-NIPR-01 FastEthernet0/1	Copper straight-through
WS-NIPR-02 FastEthernet0	SW-BAN-NIPR-01 FastEthernet0/2	Copper straight-through
SW-BAN-NIPR-01 GigabitEthernet0/1	RTR-IG-01 GigabitEthernet0/0	Copper straight-through
RTR-IG-01 GigabitEthernet0/1	DISN-DISA	Copper straight-through

Step 3 — Configure IP addressing

On WS-NIPR-01:

• IP Address: 10.10.10.10

• Subnet Mask: 255.255.255.0

• Default Gateway: 10.10.10.1

On WS-NIPR-02:

• IP Address: 10.10.10.11

• Subnet Mask: 255.255.255.0

• Default Gateway: 10.10.10.1

On RTR-IG-01 GigabitEthernet0/0 (LAN-facing interface):

enable

configure terminal

interface GigabitEthernet0/0

ip address 10.10.10.1 255.255.255.0

no shutdown

end

Step 4 — Place the Component Demarcation Line marker

Use the Place Note tool. Place a note between RTR-IG-01 and DISN-DISA:

══════════════════════════════════════

COMPONENT DEMARCATION LINE

DISA RESPONSIBILITY → ABOVE

INSTALLATION RESPONSIBILITY → BELOW

Ref: DoDI 8010.01 Section 3.3

══════════════════════════════════════

Step 5 — Place PPSM boundary markers

Using Place Note, add the following labels to your diagram:

• On the link between WS-NIPR-01/WS-NIPR-02 and SW-BAN-NIPR-01:

  PPSM: Intra-enclave traffic (Boundary 9-14 range)
  
  CLSA process applies

• On the link between RTR-IG-01 and DISN-DISA:

  PPSM: Crosses DISN (Boundary 1-8 range)
  
  VA Assessment + CAL entry required
  
  Ref: DoDI 8551.01

Exercise 2 — Trace a Packet Through the OSI Layers

Step 1 — Enter Simulation Mode

Click the Simulation tab at the bottom right. In the Event List Filters, check only ICMP.

Step 2 — Send a ping

On WS-NIPR-01, open the Command Prompt (Desktop tab → Command Prompt) and type:

ping 10.10.10.11

Do not press Enter yet.

Step 3 — Step through the simulation

Press Enter and then click Capture/Forward one step at a time. For each step, click on the packet envelope icon on the diagram to open the PDU information window.

Step 4 — Complete the worksheet

Fill in the table below as you observe each layer in the PDU window:

OSI Layer	PDU Name you observe	Protocol/header you see	Device where observed
Layer 1 — Physical
Layer 2 — Data Link
Layer 3 — Network
Layer 4 — Transport

Expected answers (do not look until you have tried):

OSI Layer	PDU Name	Protocol/header	Device
Layer 1	Bit	Electrical signal on the cable	Any link
Layer 2	Frame	Ethernet header with source/destination MAC addresses	Switch
Layer 3	Packet	IP header with source 10.10.10.10 and destination 10.10.10.11	Router
Layer 4	Segment	ICMP (ping uses ICMP — sits at Layer 3/4 boundary)	Workstations

Discussion questions after completing the worksheet:

1. At the switch, which layer did it read to make its forwarding decision? Why did it not need to go higher?

2. At the router, which layer did it read? What address did it look at?

3. If you could see this same traffic on a real DoD network, what tool would you use? (Answer: Wireshark or the ACAS passive sensor.)

Exercise 3 — Add Classification Separation

Scenario: Your supervisor asks you to add a SIPRNet workstation to the same switch. You know from the Morning lecture (Layer 2 through a DoD lens) and from Day 1's Absolute Rule that this is wrong. This exercise proves it visually.

Step 1 — Add a SIPR workstation

Add a new PC. Name it WS-SIPR-01. Do NOT connect it to SW-BAN-NIPR-01.

Step 2 — Add a separate SIPR switch

Add a new 2960 switch. Name it SW-BAN-SIPR-01.

Connect WS-SIPR-01 to SW-BAN-SIPR-01 only.

Step 3 — Add a visual boundary marker

Use Place Note to add a red-labeled marker between the two switch icons:

⛔ NO CONNECTION PERMITTED ⛔

NIPRNet ←————————————————→ SIPRNet

Physical separation required

Ref: DoDI 8010.01 Sec 3.2.d / DoDI 8500.01

Cross-Domain Solution required for any data transfer

Ref: DoDI 8540.01

Step 4 — Attempt the ping

Assign WS-SIPR-01 IP address 10.10.20.10 and try to ping it from WS-NIPR-01.

Expected result: Ping fails. There is no physical path.

Discussion question: If the two networks need to exchange a specific, controlled piece of information, what is the only authorized mechanism? What organization approves it? (Answer: A Cross-Domain Solution (CDS), approved under DoDI 8540.01 and accredited by the NSA NCDSMO.)

Exercise 4 — PPSM Analysis Worksheet

This exercise does not require Packet Tracer configuration. Use the topology you built in Exercise 1 and answer the questions below.

Scenario: Your unit's operations system needs to use the following services between WS-NIPR-01 and a server at another NIPRNet installation across the DISN:

Service	Port	Protocol
Secure file transfer	TCP/22	SSH/SFTP
Web interface	TCP/443	HTTPS/TLS
Time synchronization	UDP/123	NTP
Network monitoring	UDP/162	SNMP Trap

For each service, answer:

1. Which PPSM boundary type does this traffic cross? (Intra-enclave = boundaries 9–14/16; Crosses DISN = boundaries 1–8/15)

2. Does it need a VA Assessment + CAL entry, or a CLSA?

3. Is the protocol considered secure by default, or does it need hardening?

Service	Boundary type	Process required	Secure by default?
TCP/22 SSH/SFTP
TCP/443 HTTPS
UDP/123 NTP
UDP/162 SNMP Trap

Expected answers:

Service	Boundary type	Process required	Secure by default?
TCP/22 SSH/SFTP	Crosses DISN — Boundary 8 (enclave-to-enclave across the DISN)	VA Assessment + CAL entry	Yes — SSH-2 with strong ciphers. Must verify ciphers per STIG.
TCP/443 HTTPS	Crosses DISN — Boundary 8	VA Assessment + CAL entry	Yes — but TLS version and cipher suite must be STIG-compliant (TLS 1.2 minimum, TLS 1.3 required since Jan 1 2024; no weak ciphers).
UDP/123 NTP	Crosses DISN — Boundary 8	VA Assessment + CAL entry	No — standard NTP has no authentication. DoD requires NTPv4 with authentication keys. Source must be a DoD-authorized time server.
UDP/162 SNMP Trap	Crosses DISN — Boundary 8	VA Assessment + CAL entry	No — SNMPv1/v2c is plaintext. Only SNMPv3 with authentication and encryption is acceptable per STIG.

Note on boundary numbering: Because the scenario is one NIPRNet installation talking to another NIPRNet installation across the DISN, the correct boundary is Boundary 8 (enclave-to-enclave across DISN). Boundary 7 is the DoD network → DoD enclave crossing — used when traffic comes from the broader DoD network down into an enclave, not for enclave-to-enclave traffic between two installations.

PART 2 — Protocol Verification

OPTION A — Wireshark Analysis (Preferred)

Prerequisites

• Wireshark installed (wireshark.org — free download)

• Instructor-provided file: day02_sftp_analysis.pcap

• This file contains a realistic SSH/SFTP session with some background traffic

About the capture file

The instructor has prepared a capture of a system claiming to be an "SFTP-based secure file transfer solution." Your job is not to assume it is what it claims. Your job is to verify.

The capture contains:

• An SSH connection on port 2022

• Some background HTTP/HTTPS traffic

• A DNS query or two

You are performing Phase 6 (Protocol Verification) and Phase 7 (Cryptographic Verification) from the trust-nothing-verify-everything methodology in the Afternoon lecture (Part 5 — the SFTPGo walkthrough).

Exercise 5 — Open and Orient Yourself

Step 1 — Open the capture

File → Open → select day02_sftp_analysis.pcap

Step 2 — Get oriented

Go to Statistics → Protocol Hierarchy. This shows you every protocol in the capture and what percentage of traffic each represents.

Write down what you see:

Protocol	% of packets	Your notes

Discussion question: Before you look at a single packet, what does the protocol distribution tell you? Are there any protocols here that surprise you?

Exercise 6 — Protocol Verification: Is It Really SSH/SFTP?

Step 1 — Filter on port 2022

In the Wireshark filter bar, type:

tcp.port == 2022

Step 2 — Find the SSH banner

Look at the first few packets in the filtered view. Find a packet that contains readable text. Right-click → Follow → TCP Stream.

What to look for:

• The very first readable line should start with SSH-2.0-

• If you see this → SSH-2 is confirmed ✅

• If you see anything else → investigate further before proceeding

Write down exactly what the banner says:

Server banner: ___________________________________

Client banner: ___________________________________

Step 3 — Verify SFTP subsystem

Close the TCP stream view. Back in the filtered packet list, look for an SSH packet after the key exchange. In the packet details pane, expand the SSH layer and look for:

• SSH_MSG_CHANNEL_REQUEST

• Inside it: request type = "subsystem", subsystem name = "sftp"

If you find this → Genuine SFTP confirmed ✅ If the subsystem name is something else → the protocol is not standard SFTP

Write down what you find:

Subsystem requested: ___________________________________

Step 4 — Standard client test (conceptual)

You cannot do this in Wireshark, but record your reasoning: if the subsystem name was "sftp" and the banner showed SSH-2.0-, would a standard OpenSSH client be able to connect?

Answer: ___________________________________

Exercise 7 — Cryptographic Verification: Are the Algorithms Acceptable?

Step 1 — Find the Key Exchange Init packets

In the filter bar:

ssh

Look for packets with SSH Protocol in the Info column, specifically Key Exchange Init.

Click on one. In the packet details pane, expand SSH Protocol → Key Exchange.

Step 2 — Read the algorithm lists

The client and server each advertise their supported algorithms. Fill in what you observe:

Algorithm type	What the server offered	Acceptable?
KEX (key exchange)
Server host key
Encryption (cipher)
MAC

Reference table for your assessment:

Algorithm	Acceptable?	Notes
curve25519-sha256	✅ Yes	Modern — but NOT FIPS-approved
ecdh-sha2-nistp256	✅ Yes	FIPS-approved
diffie-hellman-group1-sha1	❌ No	Weak — forbidden by STIG
aes256-gcm@openssh.com	✅ Yes	Strong, FIPS-approved
aes128-ctr	✅ Yes	Acceptable
chacha20-poly1305@openssh.com	⚠️ Strong but NOT FIPS-approved	Must be disabled for FIPS environments
3des-cbc	❌ No	Weak — forbidden by STIG
hmac-sha2-256-etm@openssh.com	✅ Yes	Strong
hmac-md5	❌ No	Weak — forbidden by STIG
ssh-ed25519	✅ Yes	Modern — but NOT FIPS-approved
rsa-sha2-256 / rsa-sha2-512	✅ Yes	FIPS-approved

Discussion question: Based on what you observed, would this system be approved as-is for a FIPS-required environment? What changes would you require before signing the ATO package?

Exercise 8 — External Connection Analysis: Where Does It Go?

Step 1 — Remove the port 2022 filter

Clear the filter bar. Now you see everything.

Step 2 — Check DNS queries

Filter:

dns

Look at every DNS query in the capture. Write down every hostname that was resolved:

Hostname queried	Your assessment

Discussion question: Are any of these hostnames unexpected for a file transfer service? Which ones would you flag for investigation?

Step 3 — Check all TCP destinations

Filter:

tcp.flags.syn == 1 and tcp.flags.ack == 0

This shows every new outbound TCP connection attempt. Write down every destination IP and port:

Destination IP	Port	Protocol (your guess)	Expected or unexpected?

The blocking test question (conceptual): If you blocked everything except TCP/2022 to the authorized SFTP endpoint, which of the connections you listed would break? Would that affect the core file transfer function?

Exercise 9 — Write the PPSM Declaration (Partial)

Based on your analysis in Exercises 5–8, draft the port/protocol portion of the PPSM declaration for this system. Use the template below.

System name: [Logistics File Transfer System]

Environment: NIPRNet

Boundary crossed: Boundary ___ (describe: ___________________________________)



Declared ports and protocols:

Port: _________ Protocol: _________ Direction: _________

Port: _________ Protocol: _________ Direction: _________



Unexpected connections found during analysis: YES / NO

If YES, describe: ___________________________________



Recommended disposition:

[ ] Approve for CAL entry — no issues found

[ ] Approve with conditions — list conditions: ___________________________________

[ ] Do not approve — issues require remediation: ___________________________________



Analyst name: _____________________ Date: _____________________

This is the document that goes into the RMF package in eMASS — not the vendor's claim sheet.

OPTION B — Packet Tracer Only (Fallback)

Use this option if Wireshark is not available or cannot be installed in your environment.

Option B covers the same analytical thinking as Option A, using Packet Tracer's Simulation Mode and structured written analysis. The lesson is identical — you are still learning to verify, not assume. The difference is that instead of reading a real capture, you observe simulated traffic and reason through what you would expect to see in a real environment.

Exercise 5B — SSH in Simulation Mode: What Packet Tracer Shows (and What It Doesn't)

This exercise has two parts. Part A shows you what Packet Tracer can demonstrate about SSH. Part B is an honest explanation of where Packet Tracer reaches its limit — and why that limit is itself a teaching point.

Part A — Configure SSH and observe in Simulation Mode

Step 1 — Enable SSH on the router

On RTR-IG-01, configure SSH:

enable

configure terminal

hostname RTR-IG-01

ip domain-name mil.dod

crypto key generate rsa general-keys modulus 2048

username admin privilege 15 secret StrongP@ss2026!

ip ssh version 2

line vty 0 4

transport input ssh

login local

exit

Packet Tracer note: In Packet Tracer 8.2.1 and later, the general-keys keyword is required. On real IOS and CML it is optional. If you omit it in Packet Tracer the command will not execute.

Step 2 — Enter Simulation Mode, filter on SSH and TCP

Set the Event List Filter to show SSH and TCP only.

Step 3 — Connect from a workstation

On WS-NIPR-01, open a Command Prompt and type:

ssh -l admin 10.10.10.1

Step through the simulation. For each SSH packet, click the OSI Model tab in the PDU window.

Step 4 — Complete the worksheet from what you observe:

Question	Your answer
What destination port does SSH use?
Which OSI layer handles that port number?
What PDU name is used at Layer 4?
What PDU name is used at Layer 3?
What PDU name is used at Layer 2?
Which layer label does Packet Tracer show for SSH itself?

Part B — What Packet Tracer Cannot Show (and Why That Matters)

Packet Tracer confirms that SSH traffic flows on port 22, sits at Layer 7, and is encapsulated through TCP/IP/Ethernet. That is all it can show.

Packet Tracer does NOT show:

• The SSH server banner (SSH-2.0-...)

• Key Exchange Init messages or negotiated algorithms

• Whether chacha20-poly1305 or aes256-gcm was selected

• Whether the SFTP subsystem was requested or something else

• Whether any unexpected connections were made alongside the session

This is not a limitation to apologize for — it is a core teaching point:

Packet Tracer tells you traffic exists on port 22 labeled "SSH." It cannot tell you whether the claimed protocol behavior is genuine, which ciphers were negotiated, or whether the application is doing anything unexpected. To answer those questions you need a real packet capture and Wireshark — exactly what Option A provides.

Written exercise: In one paragraph, explain why confirming that traffic appears on port 22 labeled "SSH" in a simulation is necessary but not sufficient for approving a system on a DoD network. What additional verification steps from the trust-nothing-verify-everything methodology in the Afternoon lecture (Part 4, the ten-phase process) cannot be performed in Packet Tracer?

Your answer:

_______________________________________________

_______________________________________________

_______________________________________________

Exercise 6B — Protocol Verification Reasoning Exercise

This exercise replaces the Wireshark packet inspection. Instead of reading a capture, you read a scenario and apply the methodology.

Scenario: A vendor has delivered a "secure file transfer application." Your unit's ISSM has asked you to assess it before submitting the ATO package. The vendor claims:

"Our application uses SFTP on port 22 with AES-256 encryption. It is fully secure and requires no additional configuration."

Answer each question below based on the trust-nothing-verify-everything methodology in the Afternoon lecture (Parts 3-5):

Question 1 — Principle 2 check

The vendor says it uses port 22. In the DoD environment, is the vendor's claim that it uses "SFTP" sufficient to approve the connection? Why or why not?

Write your answer:

_______________________________________________

_______________________________________________

Question 2 — Protocol verification

Describe exactly how you would verify the vendor's claim that the application uses SFTP. What tool would you use? What specific thing would you look for in the traffic?

Write your answer:

_______________________________________________

_______________________________________________

Question 3 — Cipher verification

The vendor says "AES-256 encryption." Name two other pieces of information you would need to verify before accepting this claim. Why is "AES-256" alone not sufficient?

Write your answer:

_______________________________________________

_______________________________________________

Question 4 — FIPS environment consideration

If this system must be deployed in a FIPS 140-3 environment, which specific cipher listed in the Day 2 lecture must be disabled even if the vendor offers it? Why?

Write your answer:

_______________________________________________

_______________________________________________

Question 5 — External connections

Describe the "blocking test" from the Afternoon lecture (Part 5, Phase 8). What are you testing, and what does the result tell you?

Write your answer:

_______________________________________________

_______________________________________________

Exercise 7B — Build the PPSM Scenario in Packet Tracer

Scenario: The application connects from WS-NIPR-01 across the DISN to a server at another installation. The application uses TCP/22 (SFTP) and also makes occasional outbound HTTPS calls to update.vendor.com.

Step 1 — Add a destination server

In your existing topology, add a new server device. Name it SRV-SFTP-HQ-01. Connect it to the DISN cloud on the far side to represent the remote installation.

Step 2 — Add PPSM annotation notes

For each connection, add a Place Note with the PPSM assessment:

For TCP/22 SFTP:

Connection: WS-NIPR-01 → SRV-SFTP-HQ-01

Port: TCP/22 Protocol: SSH-2/SFTP

Boundary: Crosses DISN — Boundary 8 (enclave-to-enclave across DISN)

Process: VA Assessment + CAL entry required

Status: APPROVED (pending STIG cipher verification)

For HTTPS to update.vendor.com:

Connection: WS-NIPR-01 → update.vendor.com (external)

Port: TCP/443 Protocol: HTTPS

Boundary: NIPRNet → Internet — Boundary 1

Process: VA Assessment + CAL entry required

Status: ⚠️ FLAGGED — external vendor dependency

Decision required: disable or justify

Step 3 — Discussion question

Which of the two connections above would you block immediately, and which would you investigate further before deciding? Explain your reasoning in one paragraph.

Lab Wrap-Up — Discussion (Both Options)

After completing either Option A or Option B, your group should be able to answer these five questions. Discuss them as a class.

Question 1: A vendor tells you their product "uses industry-standard encryption." What is your first action before writing anything in the ATO package?

Question 2: You run the baseline capture and see traffic to api.github.com from a file transfer server that should only be communicating with one specific remote host. What do you do next?

Question 3: You verify that the application uses SSH-2 with chacha20-poly1305@openssh.com as the cipher. The system is going on NIPRNet only — not a FIPS-required environment. Is this acceptable? What about if it were going on a SIPR-adjacent system?

Question 4: A program manager tells you the PPSM declaration can wait until after the ATO is approved because "it's just admin work." Is this correct? What does DoDI 8551.01 actually require?

Question 5: What is the difference between what goes in the PPSM declaration versus what goes in the RMF package in eMASS? Are they the same document?

Lab Summary

Lab	What it taught
Exercise 1	Build a DoD-named topology with classification separation and PPSM markers
Exercise 2	Trace a real packet through OSI layers in Simulation Mode
Exercise 3	Prove classification separation visually — NIPR and SIPR cannot share a switch
Exercise 4	Apply PPSM boundary thinking to four real protocols — some are secure, some need hardening
Exercise 5 (A or B)	Verify a protocol claim — SSH banner, SFTP subsystem request, or reasoning from scenario
Exercise 6 (A or B)	Verify cryptographic algorithms — read the key exchange, assess against STIG/FIPS requirements
Exercise 7 (A or B)	Identify unexpected external connections and make authorization decisions
Exercise 8–9 / 7B	Write the PPSM declaration from observed data — not vendor claims

The connecting thread: Every exercise in this lab is asking the same question: "What did I observe, and does it match what I was told?" That question is the foundation of every network security decision you will make on the DoDIN.

References

• DoDI 8551.01 — Ports, Protocols, and Services Management (PPSM)

• DoDI 8010.01 — DODIN Transport (demarcation, enclave structure)

• DoDI 8500.01 — Cybersecurity

• DoDI 8540.01 — Cross Domain (CD) Policy

• DoDI 8510.01 — Risk Management Framework (RMF)

• DISA STIG Library — public.cyber.mil/stigs/

• NIST CMVP Active List — csrc.nist.gov/projects/cryptographic-module-validation-program

• Wireshark — wireshark.org

Instructor Notes

For Option A — the .pcap file: The capture file day02_sftp_analysis.pcap should be prepared before class. Recommended content:

• A complete SSH-2 handshake to an SFTP server (SFTPGo or OpenSSH both work)

• At least one file transfer (upload or download)

• One DNS query to an external hostname (simulating an update check) — this is the "unexpected connection" students should flag in Exercise 8

• Background HTTPS traffic to one external hostname

To generate this capture: set up SFTPGo in a local VM with default config (update check enabled), connect with an SFTP client, transfer a test file, and capture the traffic with Wireshark or tcpdump -i any -w day02_sftp_analysis.pcap. The resulting file is typically under 500 KB and easy to distribute.

For Option B: Option B works well for a classroom with strict internet/software restrictions. The reasoning exercises in 6B and 7B can be done as written individual work followed by group discussion. Exercises 5B and 7B require Packet Tracer only. Budget approximately 50 minutes for Option B (the written reasoning takes longer than clicking through Wireshark).

Timing notes:

• Part 1 typically runs 40–50 minutes including discussion.

• Option A Part 2 runs 35–45 minutes.

• Option B Part 2 runs 45–55 minutes.

• If time is short, Exercise 4 (PPSM worksheet) can be assigned as homework after Part 1.

Document History

Version	Date	Changes
v1.0	Previous	Initial draft.
v3.0	Current	Branding integration and Day 2 split alignment. Three changes: (1) v4-style branding wrapper applied — top banner "RESTRICTED DISTRIBUTION — DICDP PROGRAM PARTICIPANTS ONLY," full nine-line cover panel with Document ID DICDP-CIS-FNC-D02-LAB-v3, Restricted Distribution Statement block, symmetric bottom footer and closing banner. "Companion to Day 2 Lecture Notes" subtitle dropped. (2) Opening rewritten to bridge from the new Morning + Afternoon lecture split — explicitly references the Morning lecture's OSI-through-DoD-lens content and the Afternoon lecture's PPSM 16-boundary model and trust-nothing-verify-everything methodology. Sets up Part 1 as exercising the Morning content and Part 2 as exercising the Afternoon content. (3) Reference cleanup — every "Appendix A" reference replaced with specific pointers to the Afternoon lecture parts (Part 3 for the principles, Part 4 for the ten-phase process, Part 5 for the SFTPGo walkthrough). Exercise 4 PPSM boundary classification corrected from Boundary 7 to Boundary 8 (the scenario is enclave-to-enclave across the DISN — Boundary 8 — not DoD-network-to-enclave which is Boundary 7); added an explanatory note clarifying the distinction between the two boundary numbers. Layer 2 separation reference in Exercise 3 updated to point at both the Morning lecture (Layer 2 through a DoD lens) and Day 1's Absolute Rule. TLS version reference updated to "TLS 1.2 minimum, TLS 1.3 required since Jan 1 2024" to match the current STIG language used in the new lectures. All exercise content otherwise preserved unchanged.

═══════════════════════════════════════════════════════════════════ Red Irish Global Services | DICDP | CIS Track | FNC DICDP-CIS-FNC-D02-LAB-v3 | Issued: [date] ═══════════════════════════════════════════════════════════════════

═══════════════════════════════════════════════════════════════════ RESTRICTED DISTRIBUTION — DICDP PROGRAM PARTICIPANTS ONLY ═══════════════════════════════════════════════════════════════════