═══════════════════════════════════════════════════════════════════ RESTRICTED DISTRIBUTION — DICDP PROGRAM STAFF 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 — Instructor Answer Key

 Document ID:        DICDP-CIS-FNC-D02-AK-v1

 Issued:             [date of determination]

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

 Redirect requests:  ops@redirish.global

 Distribution:       RESTRICTED — Program staff only

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

Restricted Distribution Statement

This material is the intellectual property of Red Irish Global Services and is restricted to authorized program staff supporting the Defense Information Capacity Development Program (DICDP). Distribution to participants, contractors, or other non-staff parties requires prior written authorization from Red Irish Global Services. Other requests shall be referred to: ops@redirish.global

Day 2 Lab — Instructor Answer Key

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

How to Use This Key

Each answer below gives you the model response and the teaching point behind it. The teaching point is often more important than the exact words — if a student reaches the right reasoning by a different route, that is success.

Where a question has more than one acceptable answer, that is noted. Use the discussion prompts to draw out the reasoning rather than just confirming right or wrong.

The lab references both the Day 2 Morning lecture (OSI through DoD lens) and the Day 2 Afternoon lecture (PPSM and trust-nothing-verify-everything). Students who have not absorbed both will struggle. If a student is missing the conceptual frame, point them back to the relevant lecture section rather than just giving the answer.

Instructor Preparation — Before the Lab

Before delivering the lab, the instructor needs to prepare two things.

1. The Packet Capture File for Option A

The lab references day02_sftp_analysis.pcap — an instructor-provided file. The lab works only if this file actually exists and contains the right content.

To generate the capture file:

1. Stand up an isolated VM (Ubuntu 22.04 or similar) with internet access for the duration of the capture only.

2. Install SFTPGo via Docker:

   docker pull drakkan/sftpgo:latest
   
   docker run -d --name sftpgo \
   
     -p 2022:2022 -p 8080:8080 \
   
     -v $(pwd)/data:/var/lib/sftpgo \
   
     drakkan/sftpgo:latest

3. Create a test user via the web admin at http://localhost:8080.

4. On the same VM (or a paired monitoring VM), start a capture:

   sudo tcpdump -i any -w day02_sftp_analysis.pcap port 2022 or port 80 or port 443 or port 53

5. Let it run for 60 seconds with no activity (captures any update-check phone-home).

6. From another terminal, run an SFTP session with file transfer:

   sftp -P 2022 testuser@localhost
   
   sftp> put /tmp/test.txt
   
   sftp> ls
   
   sftp> get /tmp/test.txt /tmp/test_received.txt
   
   sftp> bye

7. Trigger a failed login attempt (wrong password) so the capture contains an authentication failure too.

8. Stop the capture. The resulting .pcap file is typically under 500 KB.

What the file must contain (lab exercises depend on it):

• An SSH-2 banner exchange on TCP/2022 (Exercise 5, Exercise 6)

• An SSH Key Exchange Init packet with the algorithm lists (Exercise 7)

• A successful authentication and channel open with subsystem="sftp" (Exercise 6)

• One or more external DNS lookups OR HTTP/HTTPS connections (Exercise 8)

• A failed authentication attempt (good for class discussion)

• Optional: a Prometheus metrics or REST API call to TCP/8080

Distribute the file to each student station before the lab starts. The file is unclassified and can be distributed by any normal means (shared drive, USB on classroom systems, network share). It contains nothing sensitive — it is captures of a public open-source SFTP server with synthetic test data.

2. Packet Tracer Environment

Confirm Packet Tracer 8.2.1 or later is installed on each station. The exercises rely on the general-keys keyword in the crypto key generate rsa command, which became required in 8.2.1. Earlier versions of Packet Tracer accept the short form crypto key generate rsa modulus 2048 but later ones do not.

PART 1 — Packet Tracer Exercises

Exercise 1 — Build the Topology

Pure setup. No questions to answer.

Teaching point: the naming convention is not arbitrary. WS-NIPR-01, SW-BAN-NIPR-01, RTR-IG-01 follow the format <role>-<scope>-<classification>-<sequence>. Drill students on this naming on Day 1 if they fight it. By Day 2 it should be muscle memory.

Common student mistake: trying to put both NIPR and SIPR machines on the same diagram with the same color or close to each other. Stop them before they connect anything — Exercise 3 forces the proper separation.

Exercise 2 — Trace a Packet Through the OSI Layers

Worksheet — Expected Answers (matches lab)

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

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

The switch read Layer 2 (Data Link) — specifically the destination MAC address. It did not need to go higher because Layer 2 is sufficient to forward a frame within a single broadcast domain. Reading higher layers would be wasted work, would slow down the switch, and (in DoD) would not even be authorized — Layer 2 is a switch's lane, Layer 3 is a router's lane, and devices stay in their lane.

Teaching point: "stays in its lane" is a useful phrase. Every OSI layer has its own job. A device that snoops higher than its lane is either a security tool (IDS, IPS) or a misconfiguration.

Q2: At the router, which layer did it read? What address did it look at?

The router read Layer 3 (Network) — the destination IP address 10.10.10.11. It compared the destination address against its routing table to decide which interface to send the packet out. The MAC address gets rewritten at each hop, but the IP address stays the same end-to-end.

Teaching point: this is where students realize MAC addresses are local-hop only, while IP addresses are end-to-end. This concept reappears in Day 5 when IP addressing and routing are taught in depth.

Q3: If you could see this same traffic on a real DoD network, what tool would you use?

Wireshark is the standard answer. Also acceptable: tcpdump, ACAS passive sensor, JRSS traffic analysis tools, HBSS/ESS HIP firewall logs. Any tool that captures or inspects actual on-the-wire packets is correct.

Teaching point: Packet Tracer is a learning tool — it shows you the model. Real traffic verification is done with Wireshark and similar tools. This is the bridge to Part 2 of the lab.

Exercise 3 — Classification Separation

Discussion Question

Q: If the two networks need to exchange a specific, controlled piece of information, what is the only authorized mechanism? What organization approves it?

The only authorized mechanism is a Cross-Domain Solution (CDS) — an NSA-accredited engineered device that allows information to cross between classification levels under strict policy controls.

Approval and accreditation:

• The CDS itself is accredited by the NSA NCDSMO (National Cross Domain Strategy and Management Office)

• The specific deployment is authorized by the Authorizing Official (AO) of the systems it connects

• Cross-domain policy is governed by DoDI 8540.01

Teaching point: there is no "I'll just plug a cable in" answer. A CDS is hardware, software, configuration, accreditation, and operational policy — together. This is one of the most tightly controlled categories of equipment in DoD. The CDS concept was introduced in Day 1 Afternoon (Rule 4 — Classification Boundary); this exercise makes it concrete.

What a clever student might ask: "What about a manual transfer — print it out and walk it over?" The answer: that is itself a cross-domain transfer and is subject to its own policy. The Operation Buckshot Yankee incident (2008, covered in Day 8) happened because someone treated a USB drive as if it were not a cross-domain transfer. There is no "informal" version of crossing classification levels.

Exercise 4 — PPSM Analysis Worksheet

The expected answers are already in the lab document. This key adds the teaching points behind each answer.

Service-by-Service Teaching Points

TCP/22 SSH/SFTP:

• Boundary 8 is correct, not Boundary 7. Boundary 7 is DoD network → DoD enclave (traffic coming down into an enclave from the broader DoD network). Boundary 8 is enclave-to-enclave across the DISN — exactly what this scenario describes (one NIPRNet installation talking to another NIPRNet installation).

• A student who answered "Boundary 7" was probably reading the boundary description quickly. Walk them through the difference using the topology they built in Exercise 1.

TCP/443 HTTPS:

• The protocol itself is fine — HTTPS is on the CAL.

• The trick is that TLS 1.2 is the minimum, TLS 1.3 is required since January 1, 2024 per NIST SP 800-52 Rev 2. Older versions are STIG findings.

• Cipher suite must also be STIG-compliant — not every cipher TLS supports is acceptable.

UDP/123 NTP:

• This is the question that catches sloppy students. Standard NTP has no authentication. Anyone on the network path can spoof a time response.

• DoD requires NTPv4 with authentication keys, and the source must be a DoD-authorized time server (USNO, DoD-operated stratum servers — never pool.ntp.org).

• Wrong time on a DoD system is a security failure: certificate validation breaks, audit logs become useless, Kerberos authentication fails. Time integrity is a real attack surface.

UDP/162 SNMP Trap:

• This is the other catch. SNMPv1 and SNMPv2c are plaintext — community strings transmitted in the clear. STIG bans them.

• Only SNMPv3 with authNoPriv or authPriv (authentication + encryption) is acceptable.

• Many products still default to SNMPv2c. This is a common STIG finding during CCRIs.

General Teaching Point — Boundary 7 vs Boundary 8 vs Others

Students will mix up boundaries throughout their careers. The way to lock it in:

Where does the traffic GO TO?



  If destination is the public Internet ......... Boundary 1

  If destination is your own enclave .............. (intra-enclave: 9-14, 16)

  If destination is another enclave via DISN .... Boundary 8

  If destination is a DoD enclave from

     the broader DoD network ..................... Boundary 7

  If destination is a commercial cloud .......... Boundary 15

The question to always ask: where does the traffic actually go, and what does it cross to get there? That determines the boundary.

PART 2 — Protocol Verification

Exercise 5 — Open and Orient (Wireshark, Option A)

Pure orientation. The student opens the capture, identifies that the file contains an SSH session on port 2022 plus some background traffic. No specific answer to grade — confirm the student successfully opened the file and used Wireshark's filtering.

Common stumbling point: students who have never used Wireshark try to scroll through every packet instead of using display filters. Show them tcp.port == 2022 and dns as the two basic filters they need.

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

The student should find:

1. SSH banner: SSH-2.0-SFTPGo_2.x.x (or similar) — confirms it is SSH-2, not SSH-1, and identifies the server software as SFTPGo.

2. Key Exchange Init packet containing the algorithm lists (KEX, host key, cipher, MAC).

3. After authentication, a channel request with subsystem="sftp" — this is the SFTP subsystem being requested over the SSH channel.

Verification logic

• SSH banner present → SSH-2 confirmed ✅

• Key Exchange Init present → standard SSH protocol confirmed ✅

• subsystem="sftp" channel request → SFTP confirmed inside the SSH channel ✅

The verification is complete: the vendor's claim "uses standard SFTP protocol" is verified by packet capture. It is genuine SFTP over SSH-2.

Teaching Point

The critical test in real life is does the standard OpenSSH client work? If sftp -P 2022 testuser@host connects and transfers files, the protocol is interoperable standard SFTP. If a vendor-specific client is required, the protocol is non-standard regardless of what the vendor calls it. This test cannot be done from a pcap file — but the student should know to perform it in a real evaluation.

Exercise 7 — Cryptographic Verification

The student should identify the algorithm lists in the Key Exchange Init packet.

Expected algorithm lists (current SFTPGo defaults)

Algorithm type	Expected values
Key exchange (kex_algorithms)	mlkem768x25519-sha256, curve25519-sha256, ecdh-sha2-nistp256/384/521, diffie-hellman-group14-sha256, diffie-hellman-group-exchange-sha256
Server host key (server_host_key_algorithms)	rsa-sha2-256, rsa-sha2-512, ecdsa-sha2-nistp256/384/521, ssh-ed25519
Cipher (encryption_algorithms)	aes128-gcm@openssh.com, aes256-gcm@openssh.com, chacha20-poly1305@openssh.com, aes128-ctr, aes192-ctr, aes256-ctr
MAC (mac_algorithms)	hmac-sha2-256-etm@openssh.com, hmac-sha2-256

Assessment

• For NIPRNet CUI (the lab scenario): acceptable as-is. All algorithms are modern.

• For any FIPS-required deployment: chacha20-poly1305@openssh.com must be disabled — it is not FIPS-approved. Also Curve25519 and post-quantum algorithms are not yet FIPS-approved in all contexts. FIPS-compliant configuration restricts to AES-GCM/CTR and NIST elliptic curves only.

Teaching Point

The student should leave Exercise 7 understanding two things:

1. Modern strong crypto and FIPS-compliant crypto are different things. Chacha20-Poly1305 is modern and strong, but it is not FIPS-approved because it did not go through the NIST standardization process. A "strong cipher" is not automatically a "FIPS cipher."

2. You must check the FIPS CMVP active list for the actual cryptographic module in use. Saying "FIPS-compliant" without a CMVP certificate number is meaningless. The certificate number must be on the active list, not the Historical list, at csrc.nist.gov/projects/cryptographic-module-validation-program.

Exercise 8 — External Connection Analysis

The student should find evidence in the capture of:

1. DNS queries to one or more external hostnames — most likely api.github.com (SFTPGo's update check endpoint) and possibly others.

2. HTTP or HTTPS connections to those external hostnames.

3. Possibly Prometheus metrics traffic or REST API traffic to TCP/8080 if the capture included it.

Expected list of observed external destinations

Destination	Apparent purpose	Decision
api.github.com	SFTPGo update check	Disable — set update_check_interval: 0 in config. Updates controlled by the team, not pulled automatically.
Any other external host the capture shows	Investigate	Default decision is to disable until justified.

The Blocking Test (Concept)

The student is asked to describe the blocking test from the Afternoon lecture Part 5, Phase 8.

Model answer: the blocking test is a hardening verification. You block all outbound traffic from the application host except the specific service port the application needs (TCP/2022 for SFTP). You then exercise the application. If the core function still works, you have proven the external connections are not essential. If something breaks, you have identified an external dependency that must be either approved or removed.

The blocking test is "the most powerful verification technique" because it converts a vendor claim ("no external dependencies") into a binary observation in ten minutes.

Exercise 9 — Write the PPSM Declaration (Partial)

The student writes a partial PPSM declaration based on observed evidence.

Model PPSM Declaration (partial — what students should produce)

PPSM DECLARATION — PARTIAL



System: SFTPGo file transfer server

Deployment: NIPRNet, Location A field branch → Location B HQ

Classification: Unclassified — CUI category



Observed services (post-hardening):

  - TCP/2022 SSH-2 / SFTP subsystem

    Direction: inbound from authorized source IP only

    Authorized source: WS-NIPR-01 at Location A

    Cryptographic algorithms (verified by packet capture):

      KEX:     curve25519-sha256 (FIPS-noncompliant — disable for FIPS deployments)

      Cipher:  aes256-gcm@openssh.com (FIPS-approved)

      MAC:     hmac-sha2-256-etm@openssh.com (FIPS-approved)

    PPSM boundary crossing: Boundary 8 (enclave-to-enclave across DISN)

    Required process: VA Assessment + CAL entry



External dependencies (post-hardening): none

  - api.github.com (update check) — DISABLED in config

  - All other outbound blocked at host firewall except TCP/2022 to authorized peer



Continuous monitoring:

  - SFTP access logs to SIEM, daily review

  - Quarterly re-baseline capture

  - Re-verification before any version update



Submitting officer: [name, rank]

Date: [date]

The student does not need to produce a complete production declaration — the lab is about understanding what the declaration is and what evidence backs each line. Grade on whether the declaration:

• Identifies the boundary correctly (Boundary 8 — common mistake is Boundary 7)

• Lists observed ports based on capture evidence, not vendor claims

• Notes external dependencies and their status (disabled, blocked)

• Includes the cryptographic verification result

• References continuous monitoring

Teaching Point

Notice the declaration says nothing about what the vendor promised. Every line is what was observed and what was decided. That is what an honest PPSM declaration looks like. The vendor's marketing material does not appear in the declaration — the packet capture and the configuration choices do.

Option B Exercises (Packet Tracer Only Fallback)

If the class is running Option B because Wireshark is unavailable, use these answers.

Exercise 5B — SSH in Simulation Mode

Part A Worksheet (matches lab)

The student observes that Packet Tracer's simulation mode shows:

• TCP port 22 in the segment header (Layer 4)

• "Telnet/SSH" or "Application" label in the PDU details (Layer 7)

• PDU names per layer (Bit / Frame / Packet / Segment)

Part B — Written Exercise

Model answer:

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 because the simulation only shows the labels and structure of the protocol — not its actual behavior. Packet Tracer does not expose the SSH banner exchange, the Key Exchange Init algorithm lists, the cipher negotiation, or the channel subsystem request that proves the protocol is actually SSH-2 with SFTP subsystem. It cannot show whether the cryptographic algorithms negotiated are FIPS-approved. It cannot show external DNS lookups to vendor update endpoints. It cannot show whether the application phones home for license checks. All of these — which require real packet captures with Wireshark — are required for an honest PPSM declaration and ATO package. Packet Tracer proves the protocol claim is plausible; Wireshark proves it is true.

Teaching Point

The whole point of Exercise 5B Part B is to make the student articulate, in their own words, why the lab's Option A is preferred and why Packet Tracer alone cannot fully test for DoD-level verification. If they can write this paragraph clearly, they have understood the trust-nothing-verify-everything methodology — even without seeing the Wireshark evidence.

Exercise 6B — Protocol Verification Reasoning

Each question has a model answer below.

Q1: A vendor sells a product as "secure SSH-based file transfer." What three specific protocol-layer pieces of evidence would you want to see in a real packet capture to confirm the vendor's claim?

Model answer:

1. The SSH-2 banner (SSH-2.0-...) confirming the protocol version is SSH-2, not the obsolete SSH-1

2. The SSH Key Exchange Init packet with algorithm lists, so you can verify acceptable KEX, host key, cipher, and MAC algorithms

3. A channel request with subsystem="sftp" after authentication, confirming SFTP is running inside the SSH session and not some vendor-proprietary protocol

Q2: A vendor says their product is "AES-256 encrypted." This sounds strong. What are three different ways this claim could still be misleading or insufficient for DoD approval?

Model answer:

1. Mode of operation — AES-256 can be used in CBC, GCM, CTR, ECB, and other modes. ECB is broken; older CBC implementations have padding-oracle vulnerabilities. The mode matters, not just the algorithm and key size.

2. FIPS validation of the implementation — AES-256 in a non-FIPS-validated module is not acceptable for FIPS-required deployments. The CMVP certificate number must be on the active list.

3. Key management — AES-256 with a weak key derivation function, hardcoded keys, or keys stored in plaintext is not secure regardless of the algorithm. How keys are generated, stored, and rotated matters as much as the algorithm itself.

Other acceptable points: AES-256 used only for data at rest while data in transit uses something else; AES-256 used between two specific endpoints but TLS 1.0 used between others; AES-256 with a 128-bit IV reused across sessions.

Q3: If you observe a server consistently making outbound DNS queries to a hostname like analytics.vendor.example every few minutes, what does this most likely mean? What is your action?

Model answer: This most likely means the application is sending telemetry, usage analytics, or license-check data to the vendor's analytics infrastructure. In DoD, undeclared = unauthorized. The action is:

• Document the destination, frequency, and time of observation

• Identify the configuration setting that enables this behavior (vendor documentation, source code, config file)

• Disable the behavior if at all possible

• If the behavior cannot be disabled, the product fails DoD evaluation — find an alternative product or escalate the risk acceptance decision to the AO with full documentation

• Block the destination at the host firewall as an immediate containment measure even before deciding the long-term path

Q4: Why is the conclusion "the system uses SSH and is therefore secure" not acceptable in a DoD ATO package?

Model answer: Because SSH is a protocol, not a guarantee of security. SSH can be configured with weak algorithms (3DES, SHA-1 MACs, group1 KEX), can be deployed with weak authentication (passwords instead of keys), can run inside an application that also makes unauthorized external connections, and can be implemented by software with vulnerabilities. The ATO package must document the specific cipher suites in use, the authentication method, the FIPS status of the cryptographic module, the absence of unauthorized external connections, and the STIG-compliance configuration. "It uses SSH" is the starting point of the analysis, never the conclusion.

Exercise 7B — Build the PPSM Scenario in Packet Tracer

Step 3 Discussion Question

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

Model answer:

Block immediately: the HTTPS connection to update.vendor.com (Boundary 1, NIPRNet → Internet). This is an unauthorized external dependency. The application has no operational requirement to reach an external vendor cloud, and DoD's default posture (DoDI 8500.01) is deny-by-default for external connections. Block at the host firewall, then either configure the application to disable the update check or replace the product if it cannot be disabled. Document the disabled feature in the PPSM declaration.

Investigate further: the SFTP connection on TCP/22 to SRV-SFTP-HQ-01. This is the legitimate operational requirement — the entire reason the application exists. But before approval, verify with packet capture (not vendor claim) that:

• The protocol on the wire is genuinely SSH-2 with SFTP subsystem

• The cryptographic algorithms negotiated are STIG-acceptable

• The specific source and destination IPs are the only ones using the port

• No additional traffic flows on the same port

If verified, complete the VA + CAL entry and approve. If discrepancies are found, escalate before any production deployment.

Teaching Point

The point of contrast: the external connection has no business case → block fast. The internal connection IS the business case → verify carefully but plan to approve. Students sometimes mix these up and want to block both ("anything not approved is blocked") or approve both ("the vendor said it was fine"). The right answer is operationally specific to each connection.

Lab Wrap-Up Discussion — Answers

The five wrap-up questions from the lab. These are intended for class discussion; the answers below are talking points for the instructor.

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

Ask which standard, which cipher, which mode, which module, what CMVP certificate number, and verify the certificate is on the active list. "Industry-standard encryption" is a marketing phrase, not a security property. The first action is to convert marketing language into verifiable specifics — and refuse to write anything in the ATO package until the specifics are confirmed by independent evidence (CMVP active list, packet capture, STIG checklist results).

Teaching point: this question tests whether the student has internalized Principle 5 — one unverified assumption is one too many. If they say "I would write down what the vendor said," they have not absorbed the methodology. The right answer is "I would not write anything yet."

Q2: 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?

Investigate, do not panic, do not ignore.

Specific steps:

1. Identify which process on the host is generating the traffic (netstat, ss, lsof)

2. Read the application's configuration to find the setting that controls this behavior

3. Disable the behavior in config and verify with another capture that it has stopped

4. Document the finding in the PPSM declaration: "Update check observed in baseline; disabled in config; verified absent in post-hardening baseline"

5. Block the destination at the host firewall as defense in depth — even after the config change

Teaching point: this is the SFTPGo update check scenario from the lecture. Students who saw the walkthrough should recognize the pattern immediately. If they do not, point them back to Afternoon lecture Part 5 Phase 8.

Q3: 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?

For NIPRNet-only with no FIPS requirement: chacha20-poly1305 is a strong modern cipher — acceptable from a pure cryptographic strength perspective. But check the specific STIG for the deployed system; some DoD STIGs require FIPS regardless of network classification.

For SIPR-adjacent: chacha20-poly1305 alone is not sufficient for SIPRNet. SIPRNet requires NSA Type 1 encryption (HAIPE / TACLANE, Day 8) when classified data crosses untrusted infrastructure. Application-layer SSH on top of Type 1 is fine; SSH alone for SIPR-level traffic is not.

Teaching point: this question tests whether the student understands that algorithm strength and approval status are different axes. Chacha20-poly1305 is mathematically strong but not FIPS-approved. AES-256-GCM is both. Strong algorithms can still fail an approval requirement.

Q4: 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?

The program manager is wrong.

DoDI 8551.01 requires PPSM declarations as part of the RMF process — specifically, the AO will not authorize a system without an accurate, current PPSM declaration. No PPSM declaration = no ATO. They are not sequential ("PPSM comes after ATO") — they are integrated ("PPSM is part of the package that produces the ATO").

This is also why the relationship between PPSM and the RMF was explicitly shown in the Afternoon lecture as binding in both directions: the PPSM declaration drives the ATO, and the ATO commits the system to continuous PPSM compliance throughout its operational life.

Teaching point: if a program manager tells you something about cybersecurity that contradicts the doctrine, the doctrine is correct, not the manager. Cite the instruction politely. DoDI 8551.01 governs this — read it together if needed.

Q5: 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?

They are different but linked.

The PPSM declaration	The RMF package in eMASS
Lists every port, protocol, and service the system uses	The full system security artifacts
Identifies the PPSM boundary type for each crossing	The system categorization (FIPS 199), the System Security Plan, the assessment results, the POA&M, the ATO itself, and continuous monitoring records
Registered in the PPSM Registry (pnp.cert.smil.mil/pnp)	Managed in eMASS
Reviewed and approved by the PPSM CCB	Reviewed and signed by the Authorizing Official

The PPSM declaration is one input to the RMF package. They are not the same document, but the RMF package cannot be complete without a current PPSM declaration. Both must be accurate; both must match each other.

Teaching point: this question tests whether students understand the relationship between different DoD documentation systems. Day 1 introduced eMASS, SNAP, SGS, PPSM Registry, CMRS — five different systems each tracking different things. The PPSM declaration goes in the PPSM Registry; the ATO package goes in eMASS; they reference each other but are separate records in separate systems.

Closing Discussion Prompts (Optional)

Use these to tie the lab together after the exercises:

1. The lab applied the methodology to one product (SFTPGo). Ask: what is the same and what is different when you apply this to a commercial closed-source product instead? (Different: cannot inspect source code, must rely on strings and dynamic analysis. Same: every other phase, especially packet capture and blocking test.)

2. The lab showed how to verify a protocol claim. Ask: how does the same methodology apply when you are not evaluating a product, but troubleshooting an existing system that is doing something unexpected? (Same five principles. Same ten phases, often in different order. Same conclusion: trust the boundary device, not the vendor.)

3. The lab and the lecture both emphasize "what you observed, not what you were told." Ask: in your own organization or unit, what is the single biggest source of "what I was told" claims that should be verified before being treated as fact? (Open discussion — there is no single right answer. The goal is to make the methodology personal, not just academic.)

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

═══════════════════════════════════════════════════════════════════ RESTRICTED DISTRIBUTION — DICDP PROGRAM STAFF ONLY ═══════════════════════════════════════════════════════════════════