--- title: 'Legal Framework and Ethics' source: 'https://academia.sh/en/courses/introduction-to-cybersecurity/legal-framework-and-ethics' course: 'Introduction to Cybersecurity' language: en updated: '2026-09-13T05:08:03+00:00' license: 'CC BY-SA 4.0' objectives: - 'Establishes written scope as a countable item and counts the assets where the narrow and broad readings diverge' - "Measures scope ambiguity's counterpart at the path level: the undisputedly testable path, the disputed path, and the path left out of scope" - 'Computes the authorization and responsibility cost of widening scope and shows the legitimate-work cost of correct wording' --- # Legal Framework and Ethics Establishing authorization, scope, and responsibility as countable items: in an 18-asset inventory, four scope wordings cover 8, 13, 17, and 15 assets; the disputed item count is 0, 6, 9, and 0; in the wording written as a named list, 9 neighboring assets sit in the same segment; two assets require separate written permission each; and the undisputedly testable path count is 8, 5, 8, and 22. The previous lesson measured responsibility in a 27-cell matrix and left two cells unowned within the organization: the third-party clause's close and sustain cells. The reason for those two cells is not technical. Cutting a step, testing a path, or adding an asset to the list all depend on someone's authority to act on that system, and that authority is granted not by a table but by **a document**. Testing a system without written authorization and a defined scope is both illegal and unprofessional; a path being technically walkable does not make walking it a legitimate act. This lesson treats that document itself as a measurable object. **Rules of engagement** are the text that writes what a test covers, when, and up to what boundary; **scope** is that text's set of assets. What's asked is not the text's tone — it is how many items it defines with a single meaning. ## Writing Scope as an Item - **FR17.** The inventory is 18 assets: the 12 nodes of the set of paths plus 6 neighboring assets sitting in the same network segments. Each asset's owner (organization, partner, supplier) and network segment are written down. Both the inventory and the network are fictional. - **FR18.** Scope is written in four forms: a **named list** (every asset by name), a **segment range** (every asset in the written segments), an **exclusion** (everything except a given segment), **revised wording**. - **FR19.** An asset is **undisputedly** in scope only if the text covers it both by form **and** by name. An asset covered only by form is **disputed**: the text's narrow reading leaves it out, the broad reading leaves it in. - **FR20.** A path is undisputedly testable only if every node on it is undisputedly in scope. - **FR21.** An asset not owned by the organization still requires **separate written permission** even if it falls inside the scope text; a text an organization writes for itself does not produce authority over another organization's asset. - **FR22.** In a scope written as a named list, a single operation at the segment level would touch an out-of-scope neighbor, so every asset is tested in its own window; in a range-written scope, one window per segment is enough. - **FR23.** In the test window, the legitimate requests carried by the tested assets are stopped. - **FR24.** Revised wording names every asset it covers and explicitly excludes assets owned outside the organization. ```js // scope/authority.mjs — four written-scope formats and the asset inventory (MODEL). // There is no real organization, real contract, or real asset; every number is fictional. export const ASSET = ` field-terminal org field yes subscriber-portal org subscriber yes collector org core yes validator org core yes work-order org core yes reading-store org core yes billing org core yes identity-directory org management yes branch-switch org field no field-crew-tablet org field no branch-printer org field no subscriber-record-copy org subscriber no partner-analytics-endpoint partner core no supplier-portal supplier subscriber no management-network org management no backup-endpoint org management no test-copy org management no supplier-endpoint supplier outside no` .trim().split("\n").map((r) => { const [name, owner, segment, listed] = r.trim().split(/\s+/); return { name, owner, segment, named: listed === "yes" }; }); export const EDGE = ` field-terminal collector 420 field-terminal branch-switch 35 subscriber-portal validator 900 subscriber-portal identity-directory 760 supplier-endpoint management-network 18 supplier-endpoint backup-endpoint 6 branch-switch management-network 24 branch-switch collector 110 collector validator 380 collector reading-store 540 validator reading-store 610 validator billing 290 identity-directory management-network 44 identity-directory work-order 150 management-network collector 60 management-network backup-endpoint 12 management-network identity-directory 38 backup-endpoint reading-store 9 work-order validator 130 work-order billing 95` .trim().split("\n").map((r) => { const [a, b, m] = r.trim().split(/\s+/); return { a, b, legit: Number(m) }; }); export const ENTRY = ["field-terminal", "subscriber-portal", "supplier-endpoint"]; export const TARGET = ["reading-store", "billing"]; export const FORMAT = { "named-list": (v) => v.named, "segment": (v) => ["field", "subscriber", "core"].includes(v.segment), "exclusion": (v) => v.segment !== "outside", "revised": (v) => v.owner === "org" && v.segment !== "outside", }; // In range-written formats, a single test window per segment is enough. export const RANGE = ["segment", "exclusion", "revised"]; // These two formats also write every asset they cover BY NAME; the other two rely on the old named list. export const NAMED = ["named-list", "revised"]; export function paths() { const out = {}; for (const k of EDGE) (out[k.a] ??= []).push(k.b); const all = []; const walk = (d, trail) => { if (TARGET.includes(d)) { all.push([...trail]); return; } for (const s of out[d] ?? []) if (!trail.includes(s)) walk(s, [...trail, s]); }; for (const g of ENTRY) walk(g, [g]); return all.map((trail) => ({ trail })); } ``` ## Four Wordings, One Inventory ```js // scope/measure.mjs — four scope formats read over the same inventory and the same set of paths. import { ASSET, EDGE, FORMAT, RANGE, NAMED, paths } from "./authority.mjs"; const P = paths(), FMT = Object.keys(FORMAT); const write = (g, ...s) => console.log(s.map((v, i) => (g[i] < 0 ? String(v).padEnd(-g[i]) : String(v).padStart(g[i]))).join("")); function measure(b) { const covered = ASSET.filter(FORMAT[b]); const named = (v) => v.named || NAMED.includes(b); // does the text name the asset const undisputed = covered.filter(named); // both named and inside the format const disputed = covered.filter((v) => !named(v)); // inside only under the broad reading const conflicting = ASSET.filter((v) => v.named && !FORMAT[b](v)); const permission = covered.filter((v) => v.owner !== "org"); // needs separate written permission const segments = new Set(covered.map((v) => v.segment)); const neighbor = ASSET.filter((v) => !FORMAT[b](v) && segments.has(v.segment)); const u = new Set(undisputed.map((v) => v.name)), c = new Set(covered.map((v) => v.name)); return { covered: covered.length, undisputed: undisputed.length, disputed: disputed.length, conflicting: conflicting.length, permission: permission.length, neighbor: neighbor.length, window: RANGE.includes(b) ? segments.size : covered.length, testable: P.filter((y) => y.trail.every((x) => u.has(x))).length, contested: P.filter((y) => y.trail.every((x) => c.has(x)) && !y.trail.every((x) => u.has(x))).length, outside: P.filter((y) => !y.trail.every((x) => c.has(x))).length, legit: EDGE.filter((k) => u.has(k.a)).reduce((a, k) => a + k.legit, 0) }; } const R = Object.fromEntries(FMT.map((b) => [b, measure(b)])); console.log(`inventory MODEL: ${ASSET.length} assets, ${EDGE.length} steps, ${P.length} paths; ` + `four scope formats read over the same set.`); const T = [-44, 13, 9, 11, 14]; console.log("\n1. how many items the written scope covers, how many are open to dispute"); write(T, "measure", ...FMT); for (const [ad, f] of [["asset counted in scope", (r) => r.covered], [" inside under both readings", (r) => r.undisputed], [" inside only under the broad reading", (r) => r.disputed], ["asset conflicting with the named list", (r) => r.conflicting], ["asset needing separate written permission", (r) => r.permission], ["out of scope, same segment", (r) => r.neighbor]]) write(T, ad, ...FMT.map((b) => f(R[b]))); console.log("\n2. counterpart in the set of paths, and the legitimate-work cost"); write(T, "measure", ...FMT); for (const [ad, f] of [["undisputed testable path", (r) => r.testable], ["disputed path", (r) => r.contested], ["path left out of scope", (r) => r.outside], ["separate test window", (r) => r.window], ["legit request stopped (day)", (r) => r.legit]]) write(T, ad, ...FMT.map((b) => f(R[b]))); const t = R["segment"], s = R["revised"]; console.log(`\nin the segment format, ${t.disputed} assets and ${t.contested} paths are open to dispute; ` + `also ${t.conflicting} asset is in the named list but falls outside the range.`); console.log(`the revised wording leaves ${s.disputed} disputed assets and makes ${s.testable} ` + `paths testable; the remaining ${s.outside} paths pass through an asset owned outside the org.`); ``` ``` inventory MODEL: 18 assets, 20 steps, 30 paths; four scope formats read over the same set. 1. how many items the written scope covers, how many are open to dispute measure named-list segment exclusion revised asset counted in scope 8 13 17 15 inside under both readings 8 7 8 15 inside only under the broad reading 0 6 9 0 asset conflicting with the named list 0 1 0 0 asset needing separate written permission 0 2 2 0 out of scope, same segment 9 0 0 2 2. counterpart in the set of paths, and the legitimate-work cost measure named-list segment exclusion revised undisputed testable path 8 5 8 22 disputed path 0 3 14 0 path left out of scope 22 22 8 8 separate test window 8 3 4 4 legit request stopped (day) 4354 4160 4354 4607 in the segment format, 6 assets and 3 paths are open to dispute; also 1 asset is in the named list but falls outside the range. the revised wording leaves 0 disputed assets and makes 22 paths testable; the remaining 8 paths pass through an asset owned outside the org. ``` The first table reads four texts over the same 18-asset inventory. Assets covered are 8, 13, 17, and 15. Read on its own, this row makes exclusion look widest and the named list look narrowest, as if a scope text's strength were measured by this first row alone. The second row breaks that impression. **Assets undisputedly in scope are 8, 7, 8, and 15.** The exclusion wording covers nine more assets than the named list, but **none** of those nine are inside under both readings; anyone reading the text narrowly counts them as outside. The sentence that widens scope has not added a single undisputed item. The segment wording gives a sharper result. Assets covered rise from 8 to 13, but the undisputed item **drops from 8 to 7**. The reason is in the fourth row: **one asset is named in the list but falls outside the written segment range.** Two sentences in the same text cut against each other, and whether that asset is in scope cannot be read off the text. Writing a range meant to widen scope has instead lowered the undisputed item count. ## Where Authority Is Not the Same Thing as Scope The fifth row draws a separate boundary: in the segment and exclusion wordings, **two** of the covered assets are owned outside the organization — one is a partner organization's analytics endpoint, one is a supplier's portal. A text the organization writes for itself can count these two assets as in scope; that text does not produce **authority** over another organization's asset. Each one needs a separate written permission, and until that permission arrives these items sit not in scope but **in dispute**. The sixth row gives the boundary in the other direction. In the named-list wording, **9 assets** are out of scope but sit in the **same network segment** as the assets in scope. A single operation carried out at the segment level touches all nine of them; touching an out-of-scope asset means stepping outside written authority. The named list zeroes out ambiguity, but that precision has a coordination cost: testing runs not in one window but in a separate window per asset. These two rows show the same text answering three separate questions. **Scope** writes which asset is tested; **authority** writes whose signature grants that test; **responsibility** writes who answers when harm results. The three are separate items, and a text can write one while skipping the other two. The two assets owned outside the organization have scope written but lack authority. The nine named-list neighbors have scope written openly — they are outside — but when a segment-level operation touches them, who is responsible is not written anywhere. A text's measure is not how many assets it counts; it is **whether it answers all three of these questions for every asset.** Ethical obligation sits outside these three items and is broader than them. An out-of-scope path can show itself during testing; not testing it is a legal requirement, **reporting** it is a professional one. Likewise, not overrunning the window, not attempting more than the scope text authorizes, and passing findings only to the signing party are obligations of the party running the test even where the written text is silent. Written authority draws a ceiling; the professional standard also covers staying under that ceiling. ## Scope's Counterpart in the Set of Paths The second table brings the same four texts down to the set of paths and gives scope's real measure. Undisputed testable paths are 8, 5, 8, and **22**. The named list and the exclusion wording give the same number: the nine extra assets the exclusion wording covers are disputed, so they do not make a single path undisputed. The segment wording **drops to 5** — the one conflicting asset alone turns three paths through it disputed. The disputed path row is 0, 3, 14, and 0. In the exclusion wording, **nearly half** of the thirty paths have no textual answer to whether testing them is legitimate. Each of these fourteen paths is a responsibility question: if it is tested and an outage results, who does the written text point to. Leaving the question unanswered leaves both the party running the test and the party requesting it exposed. **A disputed item is an unmeasured path if it is not tested, and an unwritten act if it is.** Paths left out of scope are 22, 22, 8, and 8. In revised wording, all eight remaining paths pass through an asset owned outside the organization. These eight paths are **the same** eight paths that remained after purple work in the first lesson: there they went unseen because of the authorization boundary; here that same boundary keeps them untestable. The length of the set of paths an organization cannot measure on its own network is set not by its own text but by **another organization's signature.** ## The Cost of Correct Wording Revised wording names every item and explicitly excludes assets owned outside the organization: 15 assets, 0 disputed items, 0 separate permissions, 22 testable paths. The last two rows give this outcome's cost. Testing runs in 4 separate windows, and the legitimate requests stopped across those windows are **4,607** a day — the **highest** of the four wordings. This reversal is deliberate. The named list stops 4,354 legitimate requests, the segment wording 4,160; both stop less work because they undisputedly cover fewer assets. Writing scope correctly does not make testing cheaper — **it makes it more expensive.** What's bought in exchange is the tested-path count rising from 8 to 22 and the disputed item dropping to zero. If testing never stops any work at all, there is likely also an asset it never touches. ## Summary - In the 18-asset inventory, four scope wordings cover 8, 13, 17, and 15 assets; assets undisputedly in scope are 8, 7, 8, and 15. The two sentences that widen scope — the segment range and the exclusion — do not increase the undisputed item; the only wording that does is the one naming every asset. - In the segment wording, one asset is named in the list yet falls outside the range; this single conflict alone drops undisputed testable paths from 8 to 5. - Two assets owned outside the organization fall inside the scope text, but the text produces no authority over them; each needs separate written permission. In the named-list wording, 9 out-of-scope assets sit in the same segment as the assets in scope, splitting testing into 8 separate windows. - Disputed paths number 0, 3, 14, and 0. A disputed item is an unmeasured path if untested, and an unwritten act if tested. - Revised wording makes 22 paths testable and zeroes out the disputed item; the remaining 8 paths pass through an asset owned outside the organization and can only be measured with another organization's written permission. - Correct wording costs the most: 4,607 legitimate requests are stopped a day, against 4,160 and 4,354. Testing that never stops any legitimate work has probably also never touched the assets it does not reach. ## Next Step Authority is a document, and that document has now been measured: how many items it defines with a single meaning, how many it opens to dispute, how many paths it makes testable, and how much legitimate work it stops in exchange. Once the text is written, testing becomes executable. One question remains: how the person **able** to do the work the text authorizes is told apart from everyone else. When an organization wants a path tested, two separate measurements face it — knowledge measured in an exam room and skill measured in a lab. The final lesson compares the set of skills these two measure over the same item list: how many items they agree on, how many they diverge on, and which item neither measures.