Chapter 2 — Scope, permission and safe practice

Chapter 2 — Scope, permission and safe practice

Lesson map

Lesson 02 published. Map, example, EX014.

flowchart TD
  N0["Learning outcomes and connection"]
  N1["2.1 Authorization and scope"]
  N2["Visual 2 — the permission boundary"]
  N3["2.2 Why just checking is dangerous here"]
  N4["2.3 The newcomer's boundaries"]
  N5["2.4 Reporting well"]
  N6["2.5 Sharing information carefully: TLP"]
  N7["2.6 Safe places to practise"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX014"]

Logical drawing

flowchart LR
  N0["Learning outcomes and connection"]
  N1["2.1 Authorization and scope"]
  N2["Visual 2 — the permission boundary"]
  N3["2.2 Why just checking is dangerous here"]
  N4["2.3 The newcomer's boundaries"]
  N5["2.4 Reporting well"]
  N6["2.5 Sharing information carefully: TLP"]
  N7["2.6 Safe places to practise"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX014"]

[Learning outcomes and connection]
    |
    v
[2.1 Authorization and scope]
    |
    v
[Visual 2 — the permission boundary]
    |
    v
[2.2 Why just checking is dangerous here]
    |
    v
[2.3 The newcomer's boundaries]
    |
    v
[2.4 Reporting well]
    |
    v
[2.5 Sharing information carefully: TLP]
    |
    v
[2.6 Safe places to practise]
    |
    v
[Worked example] --> [Exercise EX014]

Learning outcomes and connection

After this chapter you will be able to:

• explain what authorization and scope mean, and why good intentions do not replace them;
• list what a newcomer may and may not do with a system in an essential service;
• explain why "just checking" can be dangerous in operational environments;
• report a suspicious event clearly, with the right facts and without investigating;
• use the Traffic Light Protocol to decide who may receive a piece of information;
• choose safe places to practise security skills.

Chapter 1 showed why these services matter. This chapter sets the boundaries that keep your curiosity safe. Chapter 3 then looks inside a service.

2.1 Authorization and scope

Authorization is permission, from the person or organization that owns a system, to do a specific thing with it. Scope is the exact boundary of that permission: which systems, which actions, when, and by whom. A valid authorization is normally written, names the owner who gives it, and says what to do if something goes wrong.

Two consequences follow:

• Having access is not having permission. Your clinic login lets you book appointments. It does not authorize you to explore other folders, try other people's accounts or test whether the system can be broken.
• Good intentions are not authorization. "I was only checking whether it was safe" is not a defence. Many countries treat accessing a computer system without authorization as a crime, whatever the motive, and employers treat it as misconduct.

Professional security testers work under written rules of engagement for exactly this reason; NIST's guide to technical security testing describes planning, rules and approvals before any test begins (NIST SP 800-115). That level of testing is not part of this course.

Visual 2 — the permission boundary

flowchart TD
    A[Idea to inspect or change a service] --> B{Is there owner authorization for this exact action?}
    B -- No or unknown --> C[Do not act; report the observation]
    B -- Yes --> D{Are system, time and method inside scope?}
    D -- No or unknown --> C
    D -- Yes --> E[Only the authorized team follows the approved procedure]

Text alternative: an intention to inspect or change a service passes through two checks: explicit owner permission and exact scope. If either is absent or unclear, stop and report; only the authorized team acts within the approved procedure. A login or good intention does not satisfy either check.

2.2 Why "just checking" is dangerous here

Operational systems — the computers that run pumps, valves, breakers, medical devices and signalling — are often old, finely balanced and built to run without interruption. Guidance for operational technology warns that actions routine in office IT, such as scanning a network, can disrupt these systems (NIST SP 800-82 Rev. 3). A well-meaning newcomer who "just checks" a device can stop it, raise false alarms that pull operators away from real work, or leave the device in an unsafe state. In an essential service, the safest curiosity is the kind that asks a question instead of pressing a button.

2.3 The newcomer's boundaries

2.4 Reporting well

A good report is short, factual and fast. It answers five questions:

1. What did you see? (Exact words on screen, sender address, what happened.)
2. When? (Date and time, with your time zone.)
3. Where? (Which computer, room, system or email account.)
4. What did you do? (For example: "I did not click", or honestly "I clicked the link and typed my password".)
5. What is the possible effect? (Who or what might be affected — one sentence, marked as a guess.)

Honesty matters most in item 4. Reporting quickly that you did click is far more useful than hiding it: the sooner the owner knows, the sooner they can reset a password or isolate a machine. Organizations that punish honest reports get fewer of them. Report to the channel your organization names — a supervisor, IT helpdesk or security mailbox. Many national agencies also accept reports of incidents from organizations; in the United States, for example, CISA publishes a reporting route (CISA, Report to CISA). As a newcomer, report internally first unless your organization tells you otherwise.

2.5 Sharing information carefully: TLP

Details about weaknesses and incidents can help attackers. The Traffic Light Protocol (TLP) 2.0 is a simple set of labels that tells recipients how widely they may share information (FIRST, Traffic Light Protocol):

If you receive something labelled, respect the label. If something is not labelled and might be sensitive, do not share it outside your organization; ask the sender.

2.6 Safe places to practise

You can build real skills without touching anything real: the worked examples and lab in this book; study material such as public incident reports; deliberately vulnerable training environments that you run yourself, offline, on your own computer; and public exercise kits designed for discussion, such as the UK NCSC's Exercise in a Box (NCSC, Exercise in a Box). Everyday personal security habits — strong unique passwords, multi-factor authentication, updates and recognizing phishing — are a good starting point too (CISA, Secure Our World).

2.7 Worked example: the helpful contractor (synthetic)

On Thursday afternoon an unknown man arrives at the clinic desk. "I'm from LinkNet," he says. "Your internet is dropping. I need to plug this box into your network cabinet — it'll only take five minutes. K. Ito said it was fine." Sam has never seen him; Ito is off-site.

Sam's decisions:

• Authorization. Sam does not own the network and cannot authorize work on it. A spoken claim that "Ito said it was fine" is not authorization.
• Verify through a known channel. Sam asks him to wait, then calls H. Novak and K. Ito using the numbers on the clinic's contact list — not a number the visitor offers.
• No "just five minutes". Even if he is genuine, a device plugged into the clinic network without approval could affect the appointment system during clinic hours.
• Report. Ito says no work is booked. Novak asks the visitor to leave and books a proper visit with LinkNet. Sam writes a report:

What: man claiming to be from LinkNet asked to plug a device into the network cabinet; said K. Ito approved. When: Thursday 14:20 (local time). Where: front desk, Larkfield Community Clinic. What I did: did not let him into the cabinet room; called H. Novak and K. Ito on the clinic contact list; Ito confirmed no visit was booked. Possible effect (guess): attempt to gain access to the clinic network. Description: tall, grey LinkNet-style jacket, no ID badge shown.

Sam labels the report TLP:AMBER+STRICT when emailing it to Novak — it stays inside the clinic. Sam does not post about it.

2.8 Practical activity

Write your own "boundary card": five things you may do and five things you may not do with the systems at your workplace or school, written in your own words. Then write a report, using the five questions of 2.4, about a suspicious email you have received personally (remove personal details). Do not click anything in it to gather more facts.

Keep the boundary card somewhere you will see it, and compare it with a classmate's: if one of you allows something the other forbids, check which is right against the may and may-not table. In the email report, item 4 should say honestly what you did, even if that was opening the message. Mark the possible effect as a guess, as Sam did in the contractor report.

2.9 Common errors and limits

• Confusing access with permission.
• "Investigating" a suspicious email or device before reporting it, and so destroying evidence or spreading harm.
• Delaying a report because you are embarrassed you clicked.
• Verifying a caller's identity using contact details they gave you.
• Over-sharing: posting a screenshot of a weakness "to warn people".
• Accepting a name-drop such as "K. Ito said it was fine" as permission, when only the owner can authorize work.
• Sharing a labelled report more widely than its label allows, as Sam avoided by keeping the contractor report inside the clinic.
• Limits: this chapter is general guidance, not legal advice. Laws on unauthorized access and on reporting duties differ by country and sector; follow your organization's policy.

Exercises — chapter 2

EX014 — Access or permission? Objective: distinguish the two. Inputs: Sam can open a shared drive folder called "Payroll" by accident. Steps: say whether Sam may open the files and what Sam should do. Expected evidence: two or three sentences. Rubric: 3 = does not open files, reports the over-broad access to the supervisor so the owner can fix permissions; 2 = does not open but does not report; 1 = opens "to check"; 0 = none.

EX015 — Good intentions. Objective: explain why motive does not authorize. Inputs: a classmate says "it's fine to test the town's water website for weaknesses because I'd tell them if I found anything". Steps: reply in three sentences. Expected evidence: reply. Rubric: 3 = explains no authorization from the owner, likely illegal and could disrupt a public service, suggests practising in a lab or reading the organization's published disclosure policy; 2 = two of these; 1 = one; 0 = none.

EX016 — Scope elements. Objective: recognize what a valid authorization contains. Inputs: section 2.1. Steps: list four things a written authorization should state. Expected evidence: list. Rubric: 3 = who owns and approves, which systems, which actions, when (window), plus who does it or what to do if something goes wrong; 2 = three items; 1 = one or two; 0 = none.

EX017 — Why not scan? Objective: explain OT fragility. Inputs: section 2.2. Steps: explain in two sentences why a network scan that is harmless in an office could be harmful at a water plant. Expected evidence: two sentences. Rubric: 3 = older, sensitive devices can stop or misbehave, and a stopped device can affect a physical process or safety; 2 = mentions one; 1 = vague; 0 = none.

EX018 — Boundaries sort. Objective: apply the may/may-not table. Inputs: (a) locking your screen; (b) restarting the pharmacy fridge controller because its display froze; (c) reporting a suspicious USB stick found in the car park; (d) plugging that USB stick in to find its owner; (e) using a colleague's login because yours expired; (f) reading a public CISA advisory. Steps: mark each may or may not. Expected evidence: six marks. Rubric: 3 = may: a, c, f; may not: b, d, e — with one reason each for the may-nots; 2 = all correct without reasons; 1 = one or two errors; 0 = more.

EX019 — Write a report. Objective: produce a five-part report. Inputs: Sam receives an email "MedBook: your account will be closed today" with a link and a sender address that ends in an unfamiliar domain; Sam clicked the link but closed the page before typing anything, Monday 09:05. Steps: write the report using the five questions. Expected evidence: report. Rubric: 3 = all five parts, honest that the link was clicked, no investigation, possible effect marked as a guess; 2 = four parts; 1 = hides the click or omits time; 0 = none.

EX020 — Honest reporting. Objective: see why speed and honesty matter. Inputs: the same case, but Sam did type the password. Steps: explain what Sam should add to the report and why speed matters. Expected evidence: two or three sentences. Rubric: 3 = states clearly that the password was entered and when, reports immediately so the password can be reset and sign-ins checked, notes that delay gives an attacker time; 2 = states but misses speed; 1 = suggests changing the password silently; 0 = none.

EX021 — Verify the caller. Objective: use a known channel. Inputs: a caller says "This is Larkfield Power. We need the clinic's Wi-Fi password to check your smart meter. Call me back on this number." Steps: say what Sam does. Expected evidence: steps. Rubric: 3 = does not give the password, does not use the caller's number, checks with the supervisor and the power company's published number, reports; 2 = refuses but does not report; 1 = calls back the given number; 0 = gives it.

EX022 — TLP labels. Objective: apply TLP 2.0. Inputs: (a) a national advisory marked TLP:CLEAR; (b) Sam's contractor report in 2.7 marked TLP:AMBER+STRICT; (c) a briefing marked TLP:RED given in a meeting. Steps: say who Sam may share each with. Expected evidence: three answers. Rubric: 3 = (a) anyone; (b) only people inside the clinic; (c) nobody beyond those present; 2 = two correct; 1 = one; 0 = none.

EX023 — Unlabelled information. Objective: default to care. Inputs: a colleague forwards an unlabelled email listing the clinic's network passwords "for convenience". Steps: say what Sam does. Expected evidence: two or three sentences. Rubric: 3 = does not forward or reuse, tells the supervisor/IT that passwords were sent by email so they can be changed, deletes it as instructed; 2 = does not forward but does not report; 1 = saves it; 0 = forwards.

EX024 — Safe practice plan. Objective: choose legitimate practice. Inputs: section 2.6. Steps: describe two ways you could practise security skills this month without touching any real system. Expected evidence: two items. Rubric: 3 = two concrete safe options (book lab, offline training environment on your own computer, public tabletop kit, personal account hygiene) with why each is safe; 2 = two without reasons; 1 = one; 0 = any unsafe option.

EX025 — Social media. Objective: avoid harmful disclosure. Inputs: Sam's friend wants to post "Larkfield Water still uses default passwords!" to warn the public. Steps: explain the risk and a better route. Expected evidence: three sentences. Rubric: 3 = posting could help attackers target a safety-critical service before it is fixed and may be unverified; better: tell the utility through its contact or disclosure route, or the friend's supervisor if they work there; 2 = risk only; 1 = vague; 0 = encourages posting.

EX026 — Contractor case reflection. Objective: extract the decisions in 2.7. Inputs: the worked example. Steps: list the four decisions Sam made and the principle behind each. Expected evidence: four pairs. Rubric: 3 = not Sam's to authorize / authorization must come from the owner; verified via known contacts / do not trust caller-supplied details; refused "five minutes" / unapproved changes can disrupt service; reported and labelled / report and share carefully; 2 = three; 1 = one or two; 0 = none.

Chapter synthesis

Permission comes from the system's owner, is specific and is normally written; access and good intentions are not permission. In essential services, "just checking" can disrupt real processes, so a newcomer's safe actions are to use what they were given, notice, report fast and honestly through a known channel, and share carefully using labels such as TLP. Skills are built in synthetic and study environments, never on live services.

Continue studying — chapter 02 of 04

← Chapter 01 · Course chapter index · Chapter 03 →

Continue to the next authored lesson.