Week 3: Isolated Lab Networks; Authorization Basis

The documentation week. You build the isolated lab network you used informally in Week 2 into a documented setup. The lab produces a network diagram, a per-session authorization log template, and the scope-limit document the academy holds on file for your cohort.

Theme

A reproducible lab is the precondition for trustworthy research. Week 2's CSRF reproduction probably worked; the question Week 3 forces you to answer is: could you reproduce it tomorrow? Could you defend your reproduction methodology if a reviewer asked? Could someone else in your cohort run your reproduction and get the same result?

The answer to all three is "yes, IF the lab is documented." A network diagram says what is connected to what. A per-session authorization log says when, by whom, for what scope. A scope-limit document says what is OUT of bounds. All three together are the artifact the academy points to in any post-incident review: "this work was conducted ethically and within the cohort's authorization."

Week 3's lab is paperwork-heavy and code-light. The temptation is to treat it as filler. Resist the temptation; the labs from Week 4 forward depend on the authorization infrastructure you build this week. The Week 11 capstone-workshop and the Week 12-13 capstone defense both expect this infrastructure to exist; the panel asks "show me your lab portfolio" before any technical question.

By the end of Week 3 you can: draw a network diagram that distinguishes lab traffic from production traffic; write a per-session authorization log that satisfies the academy's discipline; articulate a scope-limit document that protects you against accusations of scope creep.

Schneier weave (~270 words, A Hacker's Mind Ch 7)

Schneier devotes Chapter 7 of A Hacker's Mind to the question of accountability. His worked examples include audit trails in finance (every trade is logged), chain-of-custody documentation in evidence law (every transfer is signed), and the FDA's traceability requirements for pharmaceutical supply chains (every batch is tracked). The pattern across all three is the same: the system that produces high-integrity outcomes is the system whose every state-changing operation is documented.

Adversarial security research operates under the same demand. A vulnerability researcher whose work cannot be traced (no per-session log; no scope document; no authorization record) is a researcher whose work cannot be defended. The discipline of documenting before acting is not bureaucratic overhead; it is the audit trail that distinguishes professional research from indistinguishable-from-malicious behavior.

Schneier's argument is that accountability infrastructure is the design choice that determines whether a system can be trusted by the parties it affects. Tax authorities can trust audited financial statements because the audit trail is examinable; courts can trust forensic evidence because the chain of custody is documented; regulators can trust drug supply chains because batch traceability is enforced. In each case, the trust comes from the accountability mechanism, not from the underlying actor's character.

A reproducing security researcher's accountability mechanism is the lab portfolio. Week 3 builds the portfolio's structure (network diagram + per-session log + scope-limit). Weeks 4 through capstone fill it in. The portfolio is the artifact that lets a future reviewer (academy instructor, employer, court) verify that your adversarial work was conducted under the discipline that distinguishes research from felony.

Reading list (~1 hour)

1. Schneier, A Hacker's Mind, Ch 7 ("Hacking Accountability"). Academy library; calibre id 677.
2. NIST SP 800-115, Technical Guide to Information Security Testing and Assessment at https://csrc.nist.gov/publications/detail/sp/800-115/final. Section 3 (planning phase) and Section 4 (execution phase) are the relevant parts. Free PDF; ~70 pp; read selectively.
3. CERT/CC Coordinated Vulnerability Disclosure guide, "Researcher's responsibilities" at https://vuls.cert.org/confluence/display/CVD/4.+Researcher. Brief; ~15 min.
4. OWASP, "Penetration Testing Execution Standard, Pre-engagement Interactions" at https://www.pentest-standard.org/index.php/Pre-engagement. Industry reference for scope documents.
5. Schneier, Beyond Fear, Ch 7 ("Detection and Response") (optional; if you have access to it; not in the academy library). Older Schneier text; reinforces the accountability framing.

Lecture outline (~50 min)

Part 1: What a lab network is (15 min)

• Definition. A lab network is a network whose participating devices are all owned or authorized by the researcher AND whose traffic is isolated from production networks (the public Internet; any third-party network).
• Why physical isolation. A lab network connected to the public Internet is a lab network from which traffic can escape. The CSRF reproduction in Week 2 could, on a non-isolated network, have hit a device beyond the SB6141 if you got the IP wrong. Physical isolation makes the cost of an error bounded.
• Two acceptable lab-network topologies for ADV-101:
  1. Direct connection. Laptop -> Ethernet cable -> SB6141. No upstream connection. Simplest; the academy's default.
  2. Lab switch. Laptop -> switch -> SB6141. Allows multiple devices on the lab network (a second test laptop, an academy-provided traffic generator). Slightly more complex; useful for advanced cohorts.
• What is NOT acceptable. SB6141 connected to a live cable provider; SB6141 connected to a home router that has Internet access; SB6141 on a Wi-Fi network shared with non-lab devices.

Part 2: Network-diagram conventions (15 min)

• Components. Boxes for devices; labels with device type + IP. Arrows for cables; labels with the medium (Ethernet / USB-Ethernet / serial). Boundaries (dashed boxes) for isolation zones.
• What a useful network diagram includes. Every device's IP address; every link's medium; the isolation boundary; the explicit absence of any link to a non-lab network. The academy's example diagram lives at /handouts/cross-chapter-lab-network-template.md (forward-pointer; this handout is on the curriculum-supplement backlog).
• What a useful network diagram excludes. Internal device topology (you do not need to draw the SB6141's internal architecture; the device is opaque to the lab). Marketing-style cloud icons. Anything that distracts from "what is connected to what."
• Diagram tooling. Plain ASCII art is acceptable. mermaid (Markdown-native, GitHub renders it) is good. Drawio / Excalidraw / OmniGraffle are professional alternatives. The diagram's purpose is communication; pick the tool that communicates.

Part 3: Per-session authorization log (10 min)

• Format. One entry per lab session. Each entry includes: timestamp, lab number, target device serial, action (e.g., "reproduce CSRF; run Tool v0.1"), authorization basis ("per signed cohort authorization filed 2026-MM-DD"), session-end timestamp, any incidents.
• Where it lives. Inside the lab notebook (your ~/adv-101/lab-portfolio.md). The academy reviews the portfolio at capstone defense and during midterm.
• What the entry does. Two things. (1) Forces you to think about scope before acting; the act of writing the line is the check. (2) Produces the audit trail; if a reviewer asks "show me your Lab 5 session," the entry is the answer.

Part 4: Scope-limit document (10 min)

• What is in scope. The specific SB6141 unit (by serial number); the isolated lab network; the activities listed in the cohort authorization (reproduce known CVEs; develop testing tools; document findings).
• What is OUT of scope. Any device the student does not personally own and authorize; any network outside the documented lab; any activity beyond the cohort authorization (developing weaponized exploits; selling discovered vulnerabilities; testing against any production system).
• Why the negative scope matters. Scope-creep is the dominant failure mode of unstructured security research. A student who, in the middle of a lab session, notices their own home router has the same CSRF and decides to "just verify" is now operating outside scope; the verification is unauthorized; CFAA applies. The scope-limit document is the discipline that prevents that decision.
• Template language. The academy provides standard scope-limit text in the cohort authorization document. Lab 3 customizes it for the specific cohort (cohort name; SB6141 serial number; lab-network IP range).

Disclosure-Ethics Sidebar

The accountability infrastructure intersects three norm systems:

The Aaron Swartz case is the cautionary tale: Swartz had legitimate access to JSTOR but no documented authorization for the bulk-download activity that triggered the prosecution. Whether you agree with the prosecution's interpretation of CFAA or not, the absence of explicit documented authorization made the legal defense harder. Your lab portfolio is the academic-research equivalent of the documented authorization Swartz lacked.

Labs (~3 hr)

Lab 3: Isolated Lab Network (labs/lab-3-lab-network.md)

• Goal: build the documented isolated lab network. Produce the network diagram, the per-session authorization log template, and the customized scope-limit document
• Time: ~3 hr
• Artifact: lab-3-network-diagram.md + lab-portfolio-template.md + scope-limit.md in ~/adv-101/lab-3/

Independent practice (~5 hr)

1. Read NIST SP 800-115 §§3-4 carefully (1.5 hr). Section 3 (planning) is the authorization-document section; section 4 (execution) is the per-session-log section. The NIST document is the academic reference; your lab portfolio is the practitioner application.
2. Build a mermaid network diagram (1 hr). On https://mermaid.live/, build a diagram representing your isolated lab network. Try the flowchart and architecture diagram types; pick the clearer for the lab artifact.
3. Read three published pentest engagement letters (1 hr). The TrustedSec sample engagement letter at https://www.trustedsec.com/resources/, the SecureLayer7 template at https://blog.securelayer7.net/penetration-testing-statement-of-work/, and any third example you find via web search. Notice the per-engagement-customized fields (target list; date window; negative scope); these are what your scope-limit document mirrors.
4. Schneier A Hacker's Mind Ch 8 (45 min). Continues the accountability theme into political systems; the chapter is also good background for Lab 9's CVD framing.
5. Cohort coordination (45 min). Compare your scope-limit document with one peer's. Do they agree on the negative-scope language? If not, why? (A consistent cohort-wide negative scope is the academy's preference; instructor will normalize during Lab 3 office hours.)

Reflection prompts (~30 min)

1. The per-session authorization log feels like overhead the first time. Will it still feel like overhead at Lab 7? At the capstone defense? Predict; revisit after each.
2. Your scope-limit document includes a list of negative-scope items. Did writing the list surface any cases you had not previously thought about (e.g., what about a virtual SB6141 in QEMU)? How did you decide?
3. NIST SP 800-115 is one accountability framework; the academy's lab portfolio is another. What does each capture that the other does not?
4. The network diagram for Week 3's lab is dead-simple (laptop + Ethernet + SB6141). What would the diagram look like for the Week 12-13 capstone work? Sketch a draft.
5. One thing from this week you want to know more about?

Adversary Diary (Week 3)

New entries:

• mermaid diagram syntax at https://mermaid.live/. The portable-text diagram tool. Diagrams live in Markdown; render in GitHub, GitLab, and any modern Markdown viewer.
• NIST SP 800-115 at https://csrc.nist.gov/publications/detail/sp/800-115/final. The reference document for security-testing methodology.
• The academy's lab-portfolio.md convention. Your single canonical lab-portfolio file lives at ~/adv-101/lab-portfolio.md. Every session adds an entry; the file is the documentation chain.

What would a reviewer ask?

1. "Walk me through your network diagram. Identify the isolation boundary."
2. "Show me your per-session log entry for Lab 2. Does it satisfy the cohort authorization?"
3. "Your scope-limit document forbids testing devices you do not own. Suppose your roommate gives you verbal permission to test their router. Is that authorization? Defend your answer."

What comes next

Week 4 introduces Python requests, argparse, logging, and exit codes. You build Tool v0.1, the first version of your SB6141 CSRF tool. v0.1's job is to FINGERPRINT the target (probe http://192.168.100.1/; expect a specific response shape; refuse to do anything else if the response does not match). v0.1 is a non-destructive tool; the fingerprint-or-refuse pattern is the safety control the tool inherits across all subsequent versions.