Chapter 10 — Engineering ethics and safety
Lesson map
Lesson 10 published. Map, example, EX028.
flowchart TD
N0["Learning outcomes"]
N1["10.1 Duty to the public"]
N2["10.2 Responsible disclosure"]
N3["10.3 Safety versus security trade-offs"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX028"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["10.1 Duty to the public"]
N2["10.2 Responsible disclosure"]
N3["10.3 Safety versus security trade-offs"]
N4["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX028"]
[Learning outcomes]
|
v
[10.1 Duty to the public]
|
v
[10.2 Responsible disclosure]
|
v
[10.3 Safety versus security trade-offs]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX028]
Learning outcomes
You will (1) apply engineering ethics to cryptographic systems in critical infrastructure; (2) handle discovered weaknesses responsibly; (3) weigh safety against security.
10.1 Duty to the public
Engineering codes of ethics put public safety first. For a water utility, safety includes reliable water and accurate bills, and also not cutting off supply because a security control fails. Aiyana considers a design where meters refuse to report if their firmware signature cannot be verified. That protects against tampering but could leave the utility blind to leaks if a certificate expires. She learns that engineers must think through failure modes of security controls themselves, because a control that fails dangerously can harm the public it was meant to protect.
10.2 Responsible disclosure
During testing on a lab bench, Aiyana notices that a vendor's meter accepts firmware without checking the signature when its battery is low. She reports it to Marcus, who reports it to the vendor under Ridgeway's coordinated disclosure process, giving the vendor time to fix it before details are shared. She does not post about it or test it on deployed meters. Ethical practice means reporting weaknesses to those who can fix them, keeping details confidential until fixed and never exploiting them, even to prove a point.
10.3 Safety versus security trade-offs
Aiyana writes a short analysis of the low-battery case and of the expiry case. For each, she lists what happens if the control fails open, accepting anything, and if it fails closed, refusing everything. For firmware updates, failing closed is right: a meter should keep its current firmware rather than install unverified code. For reporting readings, failing closed would harm customers, so meters keep reporting while raising an alert. Writing these choices down lets the utility's safety and security teams agree in advance rather than argue during an incident.
Worked example
Aiyana reports a low-battery signature bypass through coordinated disclosure and writes a fail-open versus fail-closed table for firmware updates and readings.
Synthetic case. The vendor flaw is invented for teaching.
Errors and limits
Treating every security control as fail-closed can create safety hazards; treating every one as fail-open invites attack. Disclosure without coordination can harm users.
Exercises
- EX028 — Expiry hazard. What safety risk did Aiyana see in refusing to report on signature failure? Rubric: 3 = utility blind to leaks if a certificate expires;; 2 = outage;; 1 = vague;; 0 = none.
- EX029 — Disclosure path. How was the low-battery flaw handled? Rubric: 3 = reported to Marcus and vendor via coordinated disclosure, kept confidential, not tested on live meters;; 2 = reported;; 1 = posted publicly;; 0 = none.
- EX030 — Firmware fail mode. Should firmware verification fail open or closed, and why? Rubric: 3 = closed: keep current firmware rather than install unverified code;; 2 = closed;; 1 = open;; 0 = none.
Synthesis
Ethical cryptographic engineering protects the public by planning how controls fail and by disclosing weaknesses responsibly.
Continue studying — chapter 10 of 50
← Chapter 09 (draft) · Course chapter index · Chapter 11 (draft) →