# Chapter 9 Labs: Law, Ethics, Professional Practice, and AI Governance

This chapter is a law-and-ethics module. All four labs are deliberate **paper/desk
exercises** - legal classification drills, a policy-drafting task, and a moot-court
debate. No network target is attacked and no CLI tool is run against a service. The
labs intentionally model how real practitioners reason about law rather than how they
run scanners.

The compose file provides an optional `workspace` container (ubuntu:24.04 + pandoc +
vim) so students can draft and export documents without installing anything locally. It
is not required; any text editor works.

---

## Prerequisites

- Docker Engine 24+ and Docker Compose v2 (only needed for the optional workspace)
- No special hardware, disk space, or host software required for the paper labs
- The labs run fully offline once this repository is cloned

## Quick Start (optional workspace only)

```bash
docker compose up -d
docker compose exec workspace bash
# work inside /workspace - files persist in the workspace-output volume
docker compose down -v   # cleanup when done
```

---

## Safety and Authorisation Note

Every lab in this chapter is explicitly marked "paper exercise" or "desk exercise" in
the book. The scenarios describe real laws and real cases; the work is analysis and
drafting, not execution.

**Do not use any technique, tool, or probe described in these labs against a system you
do not own and are not explicitly authorised to test.** The chapter's through-line -
"authorisation is the line between research and crime" - applies to the labs themselves.

---

## Lab 9.1: Trace One Product Through the CRA

**Section:** 9.5 - The Cyber Resilience Act

**Objective:** Apply the EU Cyber Resilience Act (Regulation (EU) 2024/2847) to a real
product, practising the classification and obligation-mapping skills the Act demands of
any manufacturer shipping into the EU market.

**Setup:** No container needed. Choose one product you own or maintain that has digital
elements: a router, password manager, connected doorbell, or IoT sensor.

**Walkthrough:**

1. **Classify under Article 7.** Is the product default class, important (Annex III
   Class I or II), or critical (Annex IV)? Write one paragraph justifying your tier
   against the Annex lists. A password manager sits in Annex III Class I (important);
   a general home router is default class; a smartcard OS or HSM is Annex IV (critical).

2. **List security-by-design duties.** For your chosen product write down at least three
   specific measures it would need to meet: secure default configuration (no universal
   passwords, no open ports not required for operation), no known exploitable
   vulnerabilities at release, and a defined update support period published before sale.
   Cite the relevant CRA article for each (Article 13 carries the main manufacturer duties).

3. **Map the supply chain.** Identify the manufacturer, importer, and distributor in the
   product's supply chain. Note which CRA duty each role carries: the manufacturer bears
   the full conformity-assessment and CE-marking burden; the importer verifies the
   manufacturer has done that work before placing the product on the EU market; the
   distributor checks the CE mark is present.

4. **Map the reporting obligation.** If an actively exploited vulnerability is discovered
   after 11 September 2026 (when Article 71(2) applies), who reports it, to whom
   (ENISA via the EUVDB plus the national CSIRT), and within what window (24 hours for
   early warning, 72 hours for the notification with impact assessment, 14 days for
   the final report)?

5. **Write one paragraph** on whether a CE mark will, after 11 December 2027 (full
   application date), mean more to a buyer than it does today. Consider what it
   represents legally (a manufacturer's declaration of conformity) versus what it has
   historically signalled (a safety check not always understood as a security guarantee).

**Expected Output:** A structured one-page analysis: tier classification with justification,
three duty examples with article citations, supply-chain role table, reporting-obligation
timeline, and a concluding paragraph on the CE mark's evolving meaning.

**Verify Completion:** Your write-up must include: (a) a named tier with the Annex/Article
reference, (b) at least three Article 13 duties with citations, (c) all three supply-chain
roles with their distinct obligations, (d) the 24h/72h/14-day reporting cadence and the
two reporting bodies, and (e) a substantive paragraph on the CE mark post-2027.

**Cleanup:** No container to stop. Archive your document to `labs/ch09/outputs/` if using
the compose workspace.

---

## Lab 9.2: EU AI Act Tiering Drill

**Section:** 9.6 - The EU AI Act

**Objective:** Correctly assign EU AI Act risk tiers to six AI systems, including one
deliberate trap, using Article 5, Article 6, Annex III, and Article 50 as the decision
tree.

**Setup:** Paper only. Do not build, probe, or deploy any system; this is classification
work.

**The Four Tiers (decision order):**

| Tier | Source | Consequence |
|------|--------|-------------|
| Unacceptable (prohibited) | Article 5 | System may not be deployed |
| High-risk | Article 6 + Annex III | Conformity assessment, human oversight, logging, registration |
| Limited-risk | Article 50 | Transparency obligations only (disclosure to users) |
| Minimal-risk | No specific article | No obligations |

**Walkthrough - classify each system:**

1. **A government system that rates citizens' trustworthiness from unrelated everyday
   behaviour and assigns benefits or penalties.**
   - Answer: Unacceptable. Article 5(1)(c) - social scoring by public authorities.

2. **An AI tool that screens and ranks job applicants to produce a shortlist.**
   - Answer: High-risk. Annex III, point 4 - employment and worker management (recruitment,
     promotion, task allocation, monitoring, termination).

3. **A customer-service chatbot on a retail website.**
   - Answer: Limited-risk. Article 50(1) - chatbots must inform users they are interacting
     with AI. No Annex III use case present.

4. **An AI spam filter that sorts and prioritises an inbox.**
   - Answer: Minimal-risk. No prohibited use, no Annex III application, no synthetic-content
     output, no interaction persona.

5. **A generative tool that produces photorealistic synthetic images.**
   - Answer: Limited-risk. Article 50(2) - synthetic media (deepfakes, synthetic video/audio/
     text that appears real) must be labelled as AI-generated.

6. **The Trap: a bank deploys an AI chatbot to help customers, and the same underlying model
   also scores their creditworthiness to approve or deny loans.**
   - Answer: High-risk for the whole system. Annex III, point 5(b) - AI used in
     creditworthiness assessment. The chatbot UI does not lower the tier; classify by
     what the system does, not what the interface calls it. The chatbot facade sits over
     a high-risk system, importing all high-risk obligations: risk management (Article 9),
     data governance (Article 10), technical documentation (Article 11), logging
     (Article 12), transparency to deployers (Article 13), human oversight (Article 14),
     and accuracy/robustness/cybersecurity (Article 15).

**Expected Output:** A table with six rows: system name, tier assigned, controlling
article/annex, and one-sentence justification.

**Verify Completion:** All six tiers match the answer key. The trap answer (6) must name
Annex III point 5(b) and explain why the chatbot UI does not change the tier.

**Cleanup:** None required.

---

## Lab 9.3: Draft a Responsible-Disclosure Policy

**Section:** 9.11 - Vulnerability Disclosure

**Objective:** Write a one-page coordinated-disclosure policy for a fictional company,
"Northgate Logistics," that meets the four structural requirements of ISO/IEC 29147 and
includes an honest, legally precise safe-harbour clause.

**Setup:** Paper or the optional compose workspace. Do not test any real system you do
not own and are not authorised to test. This is a drafting exercise only.

**Walkthrough - four required sections:**

**1. Reporting Channel (ISO/IEC 29147)**

Publish a single intake point. Write the text for a `security@northgate.example` email
inbox (or a web form equivalent). Commit to acknowledging every report with a unique
tracking ID within a stated window. Two business days is the recommended default.

Example text:
```
Contact: security@northgate.example
Acknowledgement: every report receives a unique tracking ID within 2 business days.
```

**2. Scope**

List in-scope assets explicitly: the Northgate Logistics public web application at
`www.northgate.example`, the customer portal at `portal.northgate.example`, and any
API documented in the developer portal.

List out-of-scope actions explicitly: no data exfiltration or destruction, no access to
data belonging to real users, no social engineering of Northgate employees, no denial-of-
service testing, no physical security testing. Scope is the spine of the policy: the
Coalfire/Dallas County courthouse case (Section 9.10) is scope ambiguity in practice.

**3. Safe-Harbour Clause**

Draft the clause. Promise not to pursue civil or criminal action for good-faith, in-scope
research that does not exceed what is necessary to demonstrate the vulnerability.

Then add the required caveat:
```
This clause is a contractual promise by Northgate Logistics only. It is not the US
Department of Justice 2022 good-faith charging policy (which is prosecutorial discretion
binding on no private party and revocable at any time). It provides no statutory immunity
under the Computer Fraud and Abuse Act, the Computer Misuse Act, or any other law. It
binds only Northgate for in-scope work performed in good faith.
```

**4. Disclosure Timeline**

Adopt a 90+30 model modelled on Google Project Zero:
- 90 days from notification to patch
- Public technical disclosure 30 days after the patch ships (to allow patching time)
- 14-day grace period available once, at Northgate's discretion, if a fix is imminent
- 7-day clock for vulnerabilities with confirmed in-the-wild exploitation (3-day grace)

Justify in two sentences: fixed deadlines convert a patch from a best-effort intention
into a dated commitment; the compressed in-the-wild clock exists because users under live
attack cannot wait ninety days.

**Deliverable Check:** A complete policy has all four: intake channel with SLA, explicit
in-scope/out-of-scope list, safe-harbour clause with the "not a statutory shield" caveat,
and a disclosure timeline with justification.

**Expected Output:** A one-page document (300-500 words) with four clearly labelled
sections.

**Verify Completion:** Peer-review against the deliverable check. Every item must be
present and the safe-harbour caveat must name that it is not a DOJ policy and not a
statutory shield.

**Cleanup:** If using the workspace container, copy your document out before running
`docker compose down -v` (the volume is deleted on teardown).

---

## Lab 9.4: Ethics in the Dock (Moot Court)

**Section:** 9.15 - The AI Frontier and Professional Ethics

**Objective:** Practise applying legal and professional-ethics instruments to ambiguous
real-world scenarios through structured adversarial argument. The deliverable is a
defensible chain of reasoning anchored to a primary source, not a correct verdict.

**Setup:** Paper exercise. Form three groups: Prosecution, Defence, and Bench. Each
side argues for five minutes per scenario; the Bench rules and must cite the controlling
instrument. Run all three scenarios.

**Authorisation guard rail:** Do not execute any technique or probe described in any
scenario. Every scenario is a paper analysis of conduct that already occurred or is
hypothetical. The rule the chapter returns to - "authorisation is the line between
research and crime" - applies to this lab.

**Scenario 1: Bug Bounty Gone Wrong**

A researcher enrolled in a public bug-bounty program pivots from the in-scope web
application to an out-of-scope internal admin panel "to prove impact," then requests a
larger payout.

Arguments to use:
- Program scope as the authorisation boundary (the safe-harbour clause only covers
  in-scope work)
- The US DOJ 2022 good-faith policy: good faith does not extend to deliberate scope
  violation or to "extortion" (threatening disclosure to extract a larger payment)
- Van Buren v. United States (593 U.S. 374, 2021): the "gates-up-or-down" test
  (authorisation is binary per resource, not a matter of purpose or intent after access)

The Bench should rule on: (a) whether the pivot was authorised; (b) whether the payout
request crossed from disclosure to extortion; (c) which instrument provides the clearest
controlling rule.

**Scenario 2: Dual-Use Research**

A researcher writes and publishes a banking-malware module described as "for defensive
education." They never deploy it; a third party uses it six months later.

Arguments to use:
- The Marcus Hutchins case (Section 9.8): pleaded guilty in 2019 to writing and
  distributing the Kronos banking trojan years before his WannaCry work; the law
  weighed the original conduct, not the later public benefit
- Where is the line between writing or publishing a tool and deploying it?
- What role does intent play? (Under the UK Computer Misuse Act 1990, intent to impair
  is an element of the s.3 offence; writing and publishing alone may not satisfy it.
  Under the CFAA, the analysis differs. Under professional codes, publication of a
  functional weapon-grade tool raises ACM Code principle 2.8: "access computing and
  communication resources only when authorized.")
- Who bears accountability for third-party misuse?

The Bench should rule on: (a) whether publication alone was the offence or whether
deployment is required; (b) whether later beneficial work is a relevant mitigating
factor under any instrument; (c) which code or statute draws the clearest line.

**Scenario 3: AI-Assisted Offensive Tooling**

A red-teamer fine-tunes an open large language model to auto-generate polymorphic
phishing campaigns and exploit variants, then open-sources the fine-tuned weights.

Arguments to use:
- Dual-use: the tool has genuine red-team value and genuine attacker value
- EU AI Act Article 14 (human oversight obligation for high-risk systems) and NIST AI
  RMF GOVERN function: who is accountable when an autonomous AI tool acts on its own
  inference, and does open-sourcing transfer or eliminate that accountability?
- Unsettled training-corpus provenance: the model was fine-tuned on curated exploit
  examples. Does that raise copyright and liability questions analogous to NYT v.
  OpenAI (No. 1:23-cv-11195)?
- The defence "it's just a research tool, the law has not caught up" is not a defence;
  it is the lesson. Where law is silent, professional codes and ethics fill the gap.

The Bench should rule on: (a) whether open-sourcing shifts accountability; (b) which
AI Act or RMF provision is the closest analogue; (c) what a defensible professional
decision would have looked like before release.

**Expected Output:** For each scenario: a one-paragraph Prosecution argument, a one-
paragraph Defence argument, and a Bench ruling with a named controlling instrument
(statute, regulation, case, or professional code clause).

**Verify Completion:** Every ruling names a specific primary source. The Bench ruling for
Scenario 3 must engage with at least one AI-specific instrument (EU AI Act or NIST AI
RMF), not only computer-misuse law.

**Cleanup:** None required.

---

## Teardown

```bash
docker compose -f labs/ch09/docker-compose.yml down -v
```

This removes the workspace container and the `workspace-output` volume. Save any
documents you want to keep before running teardown.

---

## References

- EU AI Act: Regulation (EU) 2024/1689 - https://eur-lex.europa.eu/eli/reg/2024/1689/oj
- EU Cyber Resilience Act: Regulation (EU) 2024/2847 - https://eur-lex.europa.eu/eli/reg/2024/2847/oj
- ISO/IEC 29147:2018 - Vulnerability disclosure
- ISO/IEC 30111:2019 - Vulnerability handling processes
- US DOJ CFAA good-faith policy (2022) - https://www.justice.gov/archives/opa/pr/department-justice-announces-new-policy-charging-cases-under-computer-fraud-and-abuse-act
- Van Buren v. United States, 593 U.S. 374 (2021)
- NIST AI RMF (AI 100-1, January 2023) - https://airc.nist.gov/RMF
- Google Project Zero Vulnerability Disclosure Policy - https://projectzero.google/vulnerability-disclosure-policy.html
- ACM Code of Ethics (2018) - https://www.acm.org/code-of-ethics
- ISC2 Code of Ethics - https://www.isc2.org/ethics
