Chapter 10 — Ethics and authorized practice
Lesson map
Lesson 10 published. Map, example, EX019.
flowchart TD
N0["Learning outcomes and connection"]
N1["10.1 Authorisation is the line"]
N2["10.2 Rules of engagement"]
N3["10.3 Disclosure"]
N4["10.4 Professional codes and conflicts"]
N5["10.6 Practical activity"]
N6["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Worked example"]
EX --> Q["Exercise EX019"]
Logical drawing
flowchart LR
N0["Learning outcomes and connection"]
N1["10.1 Authorisation is the line"]
N2["10.2 Rules of engagement"]
N3["10.3 Disclosure"]
N4["10.4 Professional codes and conflicts"]
N5["10.6 Practical activity"]
N6["Chapter synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX019"]
[Learning outcomes and connection]
|
v
[10.1 Authorisation is the line]
|
v
[10.2 Rules of engagement]
|
v
[10.3 Disclosure]
|
v
[10.4 Professional codes and conflicts]
|
v
[10.6 Practical activity]
|
v
[Chapter synthesis]
|
v
[Worked example] --> [Exercise EX019]
Learning outcomes and connection
After this chapter you can (1) explain why authorisation, not technical ability, defines legitimate security work; (2) write a simple rules-of-engagement document for an exercise; (3) handle an accidental discovery about a real system through coordinated disclosure; and (4) reason about conflicts between security, safety, privacy and service continuity using a professional code. It builds on Chapters 1–9 and governs every practical activity in the rest of the book.
10.1 Authorisation is the line
The same command can be maintenance or a crime. What separates them is authorisation: explicit permission from someone entitled to give it, for a defined scope, time and method. Most jurisdictions criminalise unauthorised access to computer systems, and in critical services unauthorised testing can also endanger people: a scan that is harmless to a laptop can crash a controller. So this book's rule is simple and absolute — practical work uses the book's synthetic labs, systems you own, or systems whose owner has given written, specific permission. Curiosity about a real utility's exposed device is not permission.
10.2 Rules of engagement
Authorised exercises are written down in rules of engagement (RoE): who authorises (by name and role); scope (which systems, which addresses, explicitly what is excluded — safety systems usually are); time window; permitted methods; stop conditions ("any unexpected process alarm: stop and call the shift engineer"); communication plan; handling of data found; and how results will be reported. An RoE protects the service, the organisation and the tester. In OT, the RoE is usually agreed with operations and safety engineers, not only the IT security team, and often limits testing to passive observation or offline replicas.
10.3 Disclosure
If you find a vulnerability by accident — a public page exposing a control interface, a misdirected email — the ethical path is to stop, not to explore further, and to report privately to the owner or through a coordinator. Coordinated vulnerability disclosure gives the owner or vendor time to fix before details are published; national bodies such as CISA run programmes that coordinate between finders and vendors (CISA CVD programme). Record what you saw and when, keep it confidential, and do not retain data you were not entitled to access.
10.4 Professional codes and conflicts
The ACM Code of Ethics asks computing professionals to contribute to society and human well-being, avoid harm, be honest and respect privacy, and to "access computing and communication resources only when authorized or when compelled by the public good" (ACM Code, 2018). Real dilemmas set these duties against each other. Should a hospital delay a security patch to a ventilator fleet because the update requires taking devices out of service during a respiratory-illness peak? Should a utility share an incident's details with other utilities when its lawyers advise silence? A structured approach helps: identify stakeholders and harms; identify duties and who holds them; consider alternatives (patch a subset, add a compensating control); decide; record the reasoning and who accepted the residual risk.
10.5 Worked example: the open HMI (synthetic)
This case is synthetic. A student searching for internship information on Calder Water's public website follows a link that opens a web page titled "Pump Station 4 — operator view". No password was requested. The ethical response: do not click anything on the page, do not try other links, take one screenshot of the address bar and title only if needed to report, close the page, and email CW's published security contact (or, if none, the national CERT/CSIRT) saying what was seen, when and how it was reached. Do not post about it. Do not "check whether it is really live". The student's university ethics adviser should be informed. In this synthetic case CW thanks the student, removes the link and finds that the page was a vendor demonstration left on a web server — a reminder that the finder rarely knows the full picture.
10.6 Practical activity
Write a one-page RoE for Laboratory I (Chapter 25), which runs only the book's offline labs on your own computer. Even for a trivial scope, fill every heading: authoriser, scope, exclusions, window, methods, stop conditions, data handling and reporting.
For the stop conditions, "any unexpected behaviour of my own computer, or any attempt by a script to reach the network" is specific and observable. Name yourself as authoriser and tester for the scope, and your tutor as the person told if a stop condition occurs.
10.7 Common errors and limits
- "It was publicly reachable, so it was allowed."
- Verbal authorisation, or authorisation from someone who does not own the system.
- Scope creep during a test ("while I'm here…").
- Keeping data found during a test after the engagement.
- Treating ethics as a compliance checklist rather than a reasoning duty.
The open-HMI worked example tests the first three. The page was publicly reachable, but nobody at CW authorised a visit; a classmate saying "go ahead" does not own the system; and clicking "just one more link" to check whether it is live is scope creep. The fourth would apply if the student kept the screenshot after reporting. The fifth is why the student also told the ethics adviser.
Exercises — chapter 10
EX019 — Write the stop conditions. Objective: protect a live service during an authorised test. Inputs: CPN authorises a passive network-traffic capture in its control room for one day. Steps: write five stop conditions and say who is called for each. Expected evidence: list. Rubric: 3 = five specific, observable conditions (process alarm, unexpected device behaviour, discovery of safety-system traffic outside scope, operator request, data of a sensitive type) with named roles; 2 = generic; 1 = fewer than three; 0 = none.
EX020 — The patch dilemma. Objective: structure an ethical decision. Inputs: the ventilator-patch example in this chapter's discussion of professional codes. Steps: list stakeholders and harms, two alternatives to "patch all now" or "patch none", and write a 150-word decision record naming who accepts the residual risk. Expected evidence: the analysis and record. Rubric: 3 = harms on both sides, credible alternatives (staged patching, isolation plus monitoring), clinical and security owners named; 2 = one side only; 1 = opinion without structure; 0 = none.
Chapter synthesis
Authorisation defines legitimate security work. Write rules of engagement, stop when you stumble on something real and report it privately, and reason through conflicts between duties explicitly, recording who accepted which risk. In critical services, careless testing can harm people.
Continue studying — chapter 10 of 40
← Chapter 09 · Course chapter index · Chapter 11 →
Continue to the next authored lesson.