═══════════════════════════════════════════════════════════════════ 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 Afternoon Lecture Notes

 Document ID:        DICDP-CIS-FNC-D02-LN-PM-v1

 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 — The OSI Model and TCP/IP Suite

AFTERNOON SESSION — PPSM and the Verification Methodology

Document ID: DICDP-CIS-FNC-D02-LN-PM-v1 Version: v1.0

Opening — From Layer 4 to the Real Operational Program

This morning you walked through the seven OSI layers and saw what DoD adds at each. At Layer 4 you saw a pointer: "PPSM gets the entire afternoon."

This is the afternoon.

Two things to learn this afternoon, and they are connected.

The first is PPSM — Ports, Protocols, and Services Management — the formal DoD program that controls every port and protocol allowed to cross DoDIN boundaries. You will learn what PPSM is, why it exists, how the boundary model actually works (it has sixteen boundary types, not the four you may see in some older materials), what a Categorized Approved List (CAL) is, how a Vulnerability Assessment (VA) and a Component Local Services Assessment (CLSA) are different, and how PPSM declarations integrate with the RMF package you learned about yesterday.

The second is the analytical methodology every DoD networking professional uses before approving a new system: trust nothing, verify everything. You will learn the five principles of this methodology, the ten-phase investigation process, and then you will walk through a concrete worked example — verifying an open-source SFTP server (SFTPGo) end to end against the analytical discipline.

These two pieces are connected because PPSM is the documentation framework, and "trust nothing, verify everything" is the analytical method that produces honest PPSM declarations. PPSM without verification is paperwork. Verification without PPSM is improvised. Together they are how DoD actually controls what runs on its networks.

This afternoon's content is also the bridge to the lab. The lab tests both: you will apply the PPSM boundary model to a small network you build, and you will apply the verification methodology to real packet data from an SFTP session. You cannot do the lab without the content in this document.

Part 1 — PPSM: The Program That Controls What Runs on the DoDIN

What PPSM Is

In a civilian network, if you want to use a new application, you find an open port and you use it. No one stops you. No one tracks it.

In DoD, every port, protocol, and service used on the DoDIN must be formally registered, evaluated for risk, and approved.

This is PPSM — Ports, Protocols, and Services Management — and it is governed by DoDI 8551.01 (current edition May 31, 2023).

PPSM is the operational expression of yesterday's Rule 3 (Documentation) at the port and protocol layer. Every port that any DoD system opens across a network boundary must be documented in the PPSM registry, with a risk assessment behind it, before traffic is allowed to flow.

Reference: DoDI 8551.01 — Ports, Protocols, and Services Management (PPSM), current edition.

Why PPSM Exists

Every open port on a network device is a potential attack surface. Every protocol carries risk. PPSM ensures that:

• Only known, approved ports are open across DoDIN boundaries

• Every protocol in use has been risk-assessed against known vulnerabilities

• The DoD has an authoritative inventory of what is actually running on its own network

• When a new vulnerability is found in a protocol, DoD can quickly identify every system using that protocol — because they are all registered

The driving principle: you cannot defend what you have not inventoried. PPSM is the inventory of the network's communication surface.

The PPSM Process — How It Works

PPSM has four operational elements that work together:

1 — The Categorized Approved List (CAL): DoD maintains an authoritative list of every approved port/protocol/service combination. Each entry is assigned a risk category based on its vulnerability assessment. The CAL is the answer to the question "is this combination already approved across this kind of boundary?"

2 — The Vulnerability Assessment (VA): A formal analysis of a specific protocol's security properties — its known vulnerabilities, its cryptographic strength, its attack surface, the controls that mitigate its risks. The VA produces the risk category that ends up in the CAL.

3 — The PPSM Registry: The authoritative database where systems declare which ports and protocols they use, in which direction, across which boundary types, between which endpoints. The registry is accessed at pnp.cert.smil.mil/pnp (SIPRNet, CAC required).

4 — Boundary enforcement: Firewalls, JRSS, and other boundary devices enforce the approved CAL and the registered declarations. Unregistered traffic is blocked at the boundary by policy, not by accident.

How PPSM Integrates With the RMF

Yesterday you learned the RMF — the seven-step process that produces an ATO. PPSM is woven into the RMF, not separate from it:

RMF Step	How PPSM appears
Step 2 — Categorize	The system's categorization includes its expected ports and protocols.
Step 3 — Select	NIST SP 800-53 controls related to boundary protection (SC family) drive PPSM requirements.
Step 4 — Implement	The system is configured to use only the declared ports and protocols.
Step 5 — Assess	The PPSM declaration is validated — what is declared must match what is actually observed.
Step 6 — Authorize	No PPSM declaration = no ATO. The AO will not sign.
Step 7 — Monitor	Continuous monitoring confirms the system continues to use only the declared ports.

The relationship is binding in both directions: no system gets an ATO without an accurate PPSM declaration, and the PPSM declaration is part of the ATO package monitored throughout the system's lifetime.

Part 2 — The 16-Boundary PPSM Model

This is where simplified framings get it wrong. Some older training materials describe PPSM as having four boundary types (often called B1-B4). That framing is incorrect. The official PPSM model in current DoDI 8551.01 defines sixteen boundary types, each representing a specific crossing point between defined network zones.

The boundaries divide into two operational groups based on what assessment process applies.

Group A — Boundaries 1–8 and 15 (Cross the DISN)

These are crossings between external networks, the DoD network, DMZs, and DoD enclaves — anything that traverses DISN transport. Any port/protocol traversing these boundaries must either be on the PPSM CAL already or have completed a formal Vulnerability Assessment (VA).

The most operationally common boundaries in this group:

Boundary	What it represents
Boundary 1	External (Internet) → DoD network
Boundary 3	External → DoD DMZ
Boundary 5	DoD DMZ → DoD network
Boundary 7	DoD network → DoD enclave
Boundary 8	DoD enclave → DoD enclave (across the DISN)
Boundary 15	Cloud service provider → DoDIN

If your traffic crosses any of these — meaning it leaves your local enclave and traverses DISN transport — you need a CAL entry or a completed VA.

Group B — Boundaries 9–14 and 16 (Inside the Enclave)

These are crossings that stay within an enclave boundary. Components generate a Component Local Services Assessment (CLSA) form instead of a full VA. The risk assessment is lighter because the traffic does not cross the DISN; it stays inside controlled local infrastructure.

The most operationally common boundary in this group:

Boundary	What it represents
Boundary 16	Tunneled traffic between geographically distributed enclaves under the same Authorizing Official — tunnel must use FIPS 140-2/140-3 or NSA-approved encryption

Boundary 16 is the most-used in this group — it covers the case where one AO operates multiple physical sites and connects them by an encrypted tunnel. The tunnel makes the multi-site environment one logical enclave for PPSM purposes.

Practical Rule

If your traffic crosses Boundaries 1–8 or 15 (DISN transport or cloud):

    → Full Vulnerability Assessment (VA) and CAL entry required



If your traffic stays inside Boundaries 9–14 or 16 (within your enclave):

    → Component Local Services Assessment (CLSA) form



Either way: nothing crosses any boundary without a declaration.

Reference: DISA PPSM FAQ — cyber.mil/connect/faq-ppsm; DoDI 8551.01 (May 31, 2023).

A Worked Example — A Custom Port Between Two Installations

A unit deploys a new server that needs to communicate with a server at another installation using a custom application on TCP port 9876.

Civilian world: Open the port on both firewalls. Done.

DoD world:

1. Check the PPSM Categorized Approved List (CAL) — is TCP/9876 with this protocol listed?

2. Identify which PPSM boundaries the traffic will cross. Installation-to-installation traffic crosses the DISN → this is Boundary 8 (enclave-to-enclave). A full VA is required if the combination is not already on the CAL.

3. If the traffic stayed entirely within a single enclave (Boundaries 9–14), submit a CLSA form instead.

4. Once assessed, register the service in the PPSM Registry at pnp.cert.smil.mil/pnp (SIPRNet, CAC required).

5. Declare the port/protocol usage in the system's RMF package in eMASS.

6. The PPSM CCB (Configuration Control Board) reviews and approves the declaration.

7. Firewall rules are implemented based on the approved CAL entry — not before.

8. PPSM compliance is checked during periodic CCRIs (Command Cyber Readiness Inspections).

Eight steps to open one port. That is the discipline.

Part 3 — The Five Principles of Trust Nothing, Verify Everything

PPSM tells you what must be documented. The next question is: how do you know what to declare?

The answer is the analytical methodology every DoD networking professional applies before approving a new system. It is called trust nothing, verify everything — and it rests on five principles you internalize before opening any tool or reading any vendor document.

Principle 1 — The vendor is not your enemy, but they are not your ally either

The vendor wants to sell the product. You want to secure your network. Their incentives and yours are not the same. Read everything they give you, but verify everything they claim. The vendor is not lying; the vendor is selling.

Principle 2 — What is written on the box is not what is on the wire

A product can be sold as "SFTP" while doing many other things you were not told about: license checks, telemetry uploads, update polls, vendor cloud analytics. The packet capture is the only ground truth. Marketing brochures describe intent; packet captures describe behavior.

Principle 3 — Standard protocols can be misused

SFTP on port 22 with strong ciphers is good. But the same application might also be sending TLS traffic to analytics.vendor.com on port 443 for "usage telemetry," phoning home to license.vendor.com every 24 hours, polling for updates at update.vendor.com, or resolving DNS queries to unexpected domains.

Every one of those is an undeclared connection. In DoD, undeclared = unauthorized.

Principle 4 — The boundary device sees the truth

Firewall logs, IDS alerts, traffic captures, DNS queries — these do not lie. Vendor sales decks do, sometimes accidentally. When evidence from the boundary contradicts a vendor claim, the boundary wins.

Principle 5 — One unverified assumption is one too many

If the vendor says "FIPS-validated encryption," ask: which module? What certificate number? Validated when? Still on the active list? Verify against the NIST CMVP (Cryptographic Module Validation Program) active list at csrc.nist.gov/projects/cryptographic-module-validation-program. An unverified claim is not a fact.

The Five Principles in One Sentence

"I do not care what the vendor says. I care what the packet capture shows. I do not care what the box claims. I care what crosses my boundary. Before I sign anything, I verify everything — and I document what I verified, not what I was told."

That is the analytical discipline DoD demands. Now you apply it.

Part 4 — The Ten-Phase Investigation Process

When you receive a new system to evaluate, you do not skip phases. Every phase produces evidence that goes into the system's ATO package and PPSM declaration. The phases are sequential because each one tests assumptions the previous one made.

Phase	What you do
0	Define the requirement
1	Document review — read everything the vendor provides
2	Lab setup — isolated environment, all traffic monitored
3	Static analysis — examine the software before running it
4	Dynamic baseline — watch it do nothing
5	Functional testing — watch it do its job
6	Protocol verification — is it really what they claim?
7	Cryptographic verification — are the algorithms actually strong?
8	External connection analysis — where does it go?
9	Documentation and submission
10	Continuous monitoring after deployment

What Approvals You Actually Need

For a new system going on a DoD network, the approvals required typically include:

Approval	Authority	What it covers
Categorization	System Owner + AO	Classification level and impact level (RMF Step 2)
Procurement approval	Contracting officer	Through an approved vehicle (NETCENTS-2, SEWP, GSA)
Vendor STIG / cybersecurity evidence	DISA RME	Successor to the legacy DoDIN APL since September 2025
PPSM declaration	PPSM CCB	Based on observed, not claimed, behavior
ATO or IATT	Authorizing Official (AO)	Authority to operate on the network
Connection Approval	Connection Approval Office	ATC issued; registered in SNAP (NIPR) or SGS/GIAP (SIPR)
Firewall change approval	Configuration Control Board	Every firewall rule documented
ISSM/ISSO sign-off	Information System Security Manager	Continuous-monitoring plan in place
Information Owner approval	Owner of the data	Authorizes this system to handle their data

Note on the DoDIN APL: The DoDIN APL was officially sunset on 30 September 2025 under a DoD CIO memo. Cybersecurity requirements have transitioned to the DISA RME Vendor STIG program. Products previously on the APL may continue in use if applicable STIGs are applied, CYBERCOM IAVAs/IAVMs are followed, and the vendor still provides support. New procurement requirements now reference the Vendor STIG program and the upcoming UCR-CORE document.

References: DoDI 8500.01; DoDI 8510.01; DoDI 8551.01; DoDI 8540.01; DISA APL Sunset FAQ (September 2025).

Part 5 — Worked Example: Verifying SFTPGo End to End

The principles and phases above are abstract. The point of this section is to make them concrete by walking through them on a real product: SFTPGo, an open-source SFTP, FTPS, and WebDAV server written in Go.

• GitHub: github.com/drakkan/sftpgo

• License: AGPL-3 (open source — we can inspect everything)

• Documentation: docs.sftpgo.com

SFTPGo was chosen for this walkthrough because it has multiple surfaces to verify:

• SFTP service (the core function)

• Web admin and web client UI on the same HTTP port (extra port to document)

• Update check behavior (potential phone-home — verify per version)

• Optional Prometheus metrics/telemetry endpoint (must be explicitly enabled)

• REST API (served on the same HTTP binding as the web admin)

• Plugin system (third-party code loaded at runtime — configurable port, no fixed default)

Each of these surfaces is something a real evaluator must identify, characterize, and decide what to do with. The walkthrough below shows how.

The Scenario

You are the commander of a team standing up an information exchange system between two locations. The vendor's marketing literature says:

• "Uses standard SFTP protocol"

• "Built-in AES-256 encryption"

• "Compliant with industry standards"

That sounds clean. It is not enough. Here is what you actually do.

Phase 0 — Define the Requirement

Before touching any technology, write down the answers to these questions. They drive every later decision.

Question	Answer for this scenario
What information is being exchanged?	Unclassified daily logistics reports
Between whom?	Field branch (Location A) → HQ (Location B). Both NIPRNet.
Direction?	One-way — field to HQ only
Volume / frequency?	~50 files/day, max 100 MB each
CIA impact?	Confidentiality: Moderate. Integrity: Moderate. Availability: Low.
Classification level?	Controlled Unclassified Information (CUI) — NIPRNet only

You now have your RMF Step 2 categorization input. Moderate-Moderate-Low system, FIPS 199-equivalent categorization. Without this, every later phase is guesswork.

Phase 1 — Document Review

Go to the source — the GitHub repository and the official documentation.

What you read:

• github.com/drakkan/sftpgo — the full source code and README

• docs.sftpgo.com — configuration reference

• sftpgo.json — the default config file; read every section

Specifically look for: default ports, outbound connections (update check, telemetry, metrics), authentication backends (LDAP, OIDC, cloud KMS — each is an external dependency), the plugin system (third-party code loaded at runtime).

What you write down at the end of Phase 1 — the vendor-claimed baseline:

Vendor-claimed item	Source	Note
SFTP service on TCP/2022 by default	Configuration reference	✅ Confirmed default
Web admin and web client both on TCP/8080 by default	Same — both UI components share one HTTP binding	NOT on separate ports by default
Telemetry server — disabled by default (bind_port: 0)	telemetry section in config	Must be explicitly enabled
Update check present in code — behavior depends on version	Source code; check update_check settings	Verify whether enabled in the version deployed
Plugin support via configurable socket/port — no fixed default	plugins section in config	Port defined per-plugin by the operator

Every later phase compares against this vendor-claimed baseline.

Phase 2 — Lab Setup

Stand up the product in an isolated test environment. Never on production.

The setup:

1. Isolated VM — Ubuntu 22.04 in VirtualBox or VMware, no connection to production

2. Network setup: host-only network for the SFTPGo VM, a monitoring VM running Wireshark in promiscuous mode on the same network, a logging proxy between the VM and the Internet to capture outbound HTTP/HTTPS

3. Install SFTPGo: docker pull drakkan/sftpgo:latest

4. On the monitoring VM: Wireshark, tcpdump, dnsmasq (to log DNS queries), mitmproxy (for HTTPS inspection)

The principle: the software runs in an environment where nothing it does can hide.

Phase 3 — Static Analysis

Before starting SFTPGo, examine what it is.

git clone https://github.com/drakkan/sftpgo

Search for hardcoded external endpoints:

grep -r "https://" --include="*.go" | grep -v "_test.go"

grep -r "http://"  --include="*.go" | grep -v "_test.go"

You will find the update check URL, the documentation URLs, and default configuration URLs. Document every one.

Check third-party dependencies:

cat go.mod

Every imported library is a supply-chain risk surface. Flag any that are unmaintained or from unknown sources.

For closed-source software (when you cannot access source code):

strings /path/to/binary | grep -E "https?://|\\.com|\\.io|\\.org"

This often reveals hardcoded URLs in commercial binaries even without source access.

What you find for SFTPGo: an update-check endpoint pointing to GitHub's API (api.github.com). Document it. In production you will disable this — patches are controlled by your team, not pulled automatically.

Phase 4 — Dynamic Baseline

Start SFTPGo with the default configuration. Do not log in. Do not transfer files. Just let it run.

Start a capture on the monitoring VM:

tcpdump -i any -w sftpgo_baseline.pcap host <sftpgo_ip>

Let it run for 1–24 hours. Then analyze.

What you are looking for: did it phone home for an update check? Did it resolve unexpected DNS names? What ports are actually listening?

Check what is listening:

netstat -tlnp

Real observed result for SFTPGo at default config:

• Listening: TCP/2022 (SFTP), TCP/8080 (web admin + web client + REST API combined)

• Telemetry server: not listening — disabled by default (bind_port: 0)

• Outbound: update check behavior — verify against the specific version deployed

• DNS: check for any queries to api.github.com or other external hostnames

That is the observed baseline. Compare it to the vendor-claimed baseline from Phase 1. Any discrepancy is an immediate investigation item — you trust what you observed, not what was claimed.

Phase 5 — Functional Testing

Now actually use the application:

1. Connect using a standard OpenSSH SFTP client and upload a test file — capture during transfer

2. Log into the web admin on TCP/8080 — capture

3. Hit the Prometheus metrics endpoint — capture

4. Try the REST API — capture

5. Deliberately trigger an authentication failure — capture

6. Disconnect mid-transfer — capture

For each action you now have a packet capture showing exactly what the application does.

Phase 6 — Protocol Verification

Open the capture in Wireshark. Filter on port 2022.

Examine the first packets:

• Look for the SSH banner: SSH-2.0-SFTPGo_2.x.x

• If you see SSH-2.0-... → confirmed SSH-2 ✅

• Look for SSH Key Exchange Init messages

• After authentication, look for SSH_MSG_CHANNEL_REQUEST with request type "subsystem" and value "sftp"

If you see all of this, the vendor's claim is verified by packet capture. It is genuine SFTP over SSH-2.

The critical interoperability test: connect using the standard OpenSSH sftp command:

sftp -P 2022 testuser@<sftpgo_ip>

If a standard client works, the protocol is genuinely standard. If it requires a vendor-specific client, the protocol is non-standard regardless of what the vendor calls it.

Phase 7 — Cryptographic Verification

Still in Wireshark, expand the SSH Key Exchange Init packets. Find the algorithm lists.

What you check and what SFTPGo offers by default:

Algorithm type	SFTPGo defaults	Assessment
Key exchange	mlkem768x25519-sha256 (post-quantum), curve25519-sha256, ecdh-sha2-nistp256/384/521, diffie-hellman-group14-sha256, diffie-hellman-group-exchange-sha256	Modern — acceptable ✅
Server host key	rsa-sha2-256, rsa-sha2-512, ecdsa-sha2-nistp256/384/521, ssh-ed25519	Modern — acceptable ✅
Cipher	aes128-gcm@openssh.com, aes256-gcm@openssh.com, chacha20-poly1305@openssh.com, aes128-ctr, aes192-ctr, aes256-ctr	Strong — but see FIPS note ⚠️
MAC	hmac-sha2-256-etm@openssh.com, hmac-sha2-256	Acceptable ✅
Avoid (if offered)	diffie-hellman-group1-sha1, arcfour, 3des-cbc, hmac-md5, hmac-sha1, ssh-dss	Weak — must be disabled

Critical FIPS note: chacha20-poly1305@openssh.com is NOT FIPS-approved. It was not developed through the NIST standardization process and is not on the FIPS-approved algorithm list. For any system that must meet FIPS 140-2/140-3 requirements, chacha20-poly1305 must be explicitly disabled in the SFTPGo config. FIPS-compliant deployments must restrict ciphers to AES-GCM and AES-CTR modes, and key exchange to NIST elliptic curve algorithms — not Curve25519 or post-quantum algorithms (which are also not yet FIPS-approved in all contexts). Always check the NIST CMVP active list for the specific Go cryptographic module version in use.

What you must do after verification: configure SFTPGo to explicitly allow only the algorithms on your unit's approved list. SFTPGo supports explicit cipher, MAC, and KEX configuration. Any algorithm not on the approved list gets removed.

For classified data: SSH-2 with FIPS-validated cryptography alone is not sufficient. Classified data requires NSA Type 1 encryption (TACLANE/HAIPE — Day 8). SFTPGo over SSH on a classified network is acceptable only if it rides inside an existing Type 1 encrypted tunnel — not as standalone protection.

Phase 8 — External Connection Analysis

From your captures, list every destination SFTPGo contacted:

Destination	Apparent purpose	Decision
api.github.com	Software update check	Disable — set update_check_interval: 0. Updates must be controlled by your team.
Prometheus metrics endpoint	Metrics scraping (pull)	Acceptable if metrics scraper IP is restricted at the firewall. Consider disabling if unused.
No other external destinations	—	Confirmed with blocking test below

The blocking test is the most powerful verification technique. Block all outbound from the SFTPGo host except TCP/2022 (SFTP service traffic to authorized endpoints). Then test:

• Does SFTP file transfer still work? Yes ✅ — confirms no essential dependency on external connections.

• What failed? Only the update check. Which you are disabling anyway.

A vendor claim of "no external dependencies" is verified or disproven in ten minutes with this test.

Phase 9 — Documentation

Your output document for the RMF/PPSM package.

Observed ports after hardening:

Port	Protocol	Purpose	Status
TCP/2022	SSH-2 / SFTP subsystem	File transfer	Enabled, restricted to authorized source IPs
TCP/8080	HTTPS (after hardening)	Web admin + web client + REST API (combined binding)	Restrict to admin workstation IPs; consider disabling web client
TCP/10000 (if enabled)	HTTP (Prometheus)	Telemetry / metrics	Disabled by default; if enabled, restrict to SIEM scraper IP
Plugin gRPC (port varies)	gRPC	Plugin system	Disabled — no plugins authorized in this deployment

Verified cryptography: aes256-gcm@openssh.com, hmac-sha2-256-etm@openssh.com — FIPS certificate verified on NIST CMVP active list.

External dependencies after hardening: None.

PPSM declaration: SFTP (SSH-2) on TCP/2022, NIPRNet enclave-to-enclave, Boundary 8 crossing (enclave-to-enclave across DISN) — CAL or VA entry required.

What goes into eMASS: this document, the packet capture evidence, the FIPS certificate verification, the firewall rule set, and the continuous monitoring plan.

What you document is what you observed — not what the vendor claimed.

Phase 10 — Continuous Monitoring

After ATO and deployment:

Activity	Frequency
Re-run 24-hour baseline capture, compare to original	Quarterly
Re-run Phases 4–8 in lab before deploying any new SFTPGo version	Every update
Review SFTP access logs in SIEM	Daily automated alerts
Alert on: failed-login spikes, unusual file sizes, unexpected source IPs, new external destinations	Continuous
ATO review	Annually

After every SFTPGo version update, repeat the lab analysis before deploying. Open-source projects can change their network behavior between releases. A new version may introduce a new telemetry endpoint, a new dependency, or a changed default cipher suite. You do not assume — you verify.

Summary: What This Walkthrough Taught

Phase	The lesson
0 — Define the requirement	You cannot assess risk without knowing what you are protecting.
1 — Document review	The vendor-claimed baseline is the starting point, never the final word.
2 — Lab setup	A monitored isolation environment is mandatory. Not optional.
3 — Static analysis	Inspect the software before running it.
4 — Dynamic baseline	Watch what it does when nobody is using it.
5 — Functional testing	Capture everything while it does its job.
6 — Protocol verification	Trust the packet capture over the marketing material.
7 — Cryptographic verification	Claimed algorithms and negotiated algorithms must match.
8 — External connections	Block everything except the core service. See what breaks.
9 — Documentation	Write what you observed. That is what goes in the ATO package.
10 — Continuous monitoring	Verification is not a one-time event.

End of Day 2

By the end of today you should be comfortable with:

FROM THE MORNING:

✓ TCP/IP as DoD heritage (DARPA, 1969-1983)

✓ The seven OSI layers and what DoD adds at each

✓ Which of the Four Rules applies at each layer

✓ Where encryption happens at multiple layers in DoD

✓ The SIPRNet HTTPS session walkthrough — all seven layers in action



FROM THIS AFTERNOON:

✓ PPSM as Rule 3 (Documentation) at the port/protocol layer

✓ The 16-boundary model — Group A (DISN-crossing) vs Group B (intra-enclave)

✓ The CAL, the VA, and the CLSA — which process applies where

✓ How PPSM integrates with the RMF (no PPSM = no ATO)

✓ The five principles of trust nothing, verify everything

✓ The ten-phase investigation process

✓ The full SFTPGo worked example — what verification actually looks like

Tomorrow you go to Day 3 — the physical and data link layers in detail. You will see TEMPEST, PDS, RED/BLACK, and the physical security doctrine that protects classified networks at Layer 1 and Layer 2. Many of the controls referenced today as "see Day 3" become operational reality tomorrow.

Afternoon Glossary

Term	Meaning
PPSM	Ports, Protocols, and Services Management. The DoD program that controls every port and protocol crossing DoDIN boundaries. Governed by DoDI 8551.01.
DoDI 8551.01	The DoD Instruction that governs PPSM. Current edition May 31, 2023.
CAL	PPSM Categorized Approved List. The authoritative DoD list of approved port/protocol/service combinations, each with a risk category.
VA	Vulnerability Assessment. A formal analysis of a protocol's security properties; required for protocols crossing the DISN (Boundaries 1–8 and 15).
CLSA	Component Local Services Assessment. The lighter-weight assessment form for protocols that stay inside the enclave (Boundaries 9–14 and 16).
PPSM Registry	The authoritative database where systems declare their port and protocol usage. Located at pnp.cert.smil.mil/pnp (SIPRNet, CAC required).
PPSM CCB	PPSM Configuration Control Board — reviews and approves PPSM declarations.
Boundary 7	DoD network → DoD enclave crossing. Common boundary for installation-to-server traffic.
Boundary 8	DoD enclave → DoD enclave across the DISN. Common boundary for installation-to-installation traffic.
Boundary 15	Cloud service provider → DoDIN.
Boundary 16	Tunneled traffic between geographically distributed enclaves under the same Authorizing Official.
DISA RME	DISA's Risk Management Executive — administers the Vendor STIG program that replaced the DoDIN APL in September 2025.
DoDIN APL	DoD Information Network Approved Products List. Sunset on 30 September 2025; superseded by the DISA RME Vendor STIG program.
SNAP	System/Network Approval Process. DISA's NIPRNet connection registration system.
SGS / GIAP	SIPRNet GIAP (SIPRNet Information Assurance Process). The SIPRNet equivalent of SNAP for connection approvals.
CMVP	NIST Cryptographic Module Validation Program. The authoritative list of validated cryptographic modules. Located at csrc.nist.gov/projects/cryptographic-module-validation-program.
eMASS	Enterprise Mission Assurance Support Service. The DoD's RMF/ATO package management system. Covered in Day 1.
IATT	Interim Authority to Test. A temporary authorization for testing purposes, short of a full ATO.
SFTPGo	Open-source SFTP/FTPS/WebDAV server used as the worked example in this lecture. github.com/drakkan/sftpgo.
CCRI	Command Cyber Readiness Inspection. Periodic DISA inspection that verifies STIG compliance, PPSM compliance, and overall cybersecurity posture. Covered in Day 4.

Further Reading and Doctrine References

• DoDI 8551.01 — Ports, Protocols, and Services Management (PPSM), current edition (May 31, 2023)

• DoDI 8500.01 — Cybersecurity

• DoDI 8510.01 — Risk Management Framework for DoD Systems

• DoDI 8540.01 — Cross Domain (CD) Policy

• NIST SP 800-53 Rev 5 — Security and Privacy Controls (especially the SC — System and Communications Protection family)

• NIST CMVP — csrc.nist.gov/projects/cryptographic-module-validation-program — the authoritative list of validated cryptographic modules

• DISA PPSM FAQ — cyber.mil/connect/faq-ppsm

• DISA APL Sunset FAQ (September 2025) — guidance on the transition from APL to Vendor STIG

• DISA Vendor STIG / RME program — cyber.mil/rme/

• PPSM Registry (SIPRNet) — pnp.cert.smil.mil/pnp

Document History

Version	Date	Changes
v1.0	Current	Initial creation of Day 2 Afternoon Lecture Notes. Split from the prior FNC_Day_02_Lecture_v4 single document into a morning/afternoon pair to give PPSM and the verification methodology the space they need. Afternoon contains: opening that picks up the morning's Layer 4 handoff and explains why PPSM and the verification methodology are taught together; Part 1 — what PPSM is, why it exists, the four operational elements (CAL, VA, Registry, boundary enforcement), and how PPSM integrates with the RMF (binding in both directions); Part 2 — the 16-boundary model with the corrected framing that older B1-B4 simplifications are wrong, Group A (DISN-crossing, requires VA + CAL) vs Group B (intra-enclave, uses CLSA), the practical rule for which assessment applies, and a worked example of opening a custom port between two installations; Part 3 — the five principles of trust nothing, verify everything, each principle explained with its operational logic; Part 4 — the ten-phase investigation process, plus a complete approvals table including the DoDIN APL sunset (30 September 2025) and the transition to the DISA RME Vendor STIG program; Part 5 — the full SFTPGo worked example, all ten phases applied to a real open-source product, with packet-level analysis, cryptographic verification, the blocking test for external dependencies, and the final PPSM declaration. The methodology in Parts 3-5 is what the lab will apply on real packet data. Companion to FNC_Day_02_Morning_Lecture_v1. v4-style branding applied: top banner, full nine-line cover panel with Document ID DICDP-CIS-FNC-D02-LN-PM-v1, Restricted Distribution Statement, symmetric bottom footer plus closing banner. All technical claims preserved from v4 source material; PPSM 16-boundary model, DoDI 8551.01 current edition reference (May 31, 2023), APL sunset date, and SFTPGo cryptographic defaults all carried forward unchanged.

═══════════════════════════════════════════════════════════════════ Red Irish Global Services | DICDP | CIS Track | FNC DICDP-CIS-FNC-D02-LN-PM-v1 | Issued: [date] ═══════════════════════════════════════════════════════════════════

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