Chapter 15 — Security fundamentals | Engineering Privacy and data protection

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 15 — Security fundamentals

Lesson map

Lesson 15 published. Map, example, EX043.

flowchart TD
  N0["Learning outcomes"]
  N1["15.1 Security serves privacy"]
  N2["15.2 Authentication"]
  N3["15.3 Article 32 measures"]
  N4["15.4 Integrity for patients"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Worked example"]
  EX --> Q["Exercise EX043"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["15.1 Security serves privacy"]
  N2["15.2 Authentication"]
  N3["15.3 Article 32 measures"]
  N4["15.4 Integrity for patients"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX043"]

[Learning outcomes]
    |
    v
[15.1 Security serves privacy]
    |
    v
[15.2 Authentication]
    |
    v
[15.3 Article 32 measures]
    |
    v
[15.4 Integrity for patients]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX043]

Learning outcomes

You will (1) relate confidentiality, integrity and availability to data protection; (2) apply authentication suited to health data; (3) understand security's role in GDPR Article 32.

15.1 Security serves privacy

Zara learns the classic security goals: confidentiality, integrity and availability. She relates them to data protection. Confidentiality prevents unauthorised disclosure of health records; integrity prevents wrong results reaching a patient; availability ensures clinicians can see records during a consultation. The GDPR lists integrity and confidentiality as a principle in Article 5(1)(f). But Zara notes that privacy is broader than security: a perfectly secure system can still collect too much or use data for unexpected purposes, so security is necessary but not sufficient.

15.2 Authentication

Pellmore patients log in with passwords. Zara reviews options and recommends adding a second factor for viewing records and for changing contact details, the actions most attractive to attackers. She avoids text-message codes as the only option, offering an authenticator app as well, and she ensures that recovery does not depend on knowledge questions whose answers are often public. Clinicians get stronger authentication because they can see many patients' records. She explains that authentication strength should follow the harm an account could do.

15.3 Article 32 measures

Article 32 lists examples of security measures: pseudonymisation and encryption, the ability to ensure ongoing confidentiality, integrity, availability and resilience, the ability to restore access after an incident, and regular testing. Zara maps Pellmore's controls to each example and finds gaps in restoring access and in testing. She explains that the article requires measures appropriate to the risk, taking into account the state of the art and costs, which makes risk assessment the starting point rather than a fixed list of controls. Encryption is named explicitly.

15.4 Integrity for patients

Zara studies an integrity failure: a test result attached to the wrong patient. This is both a safety and a data protection problem, because it discloses one patient's data to another and may harm both. She proposes checks: matching on two identifiers before attaching results, and alerts when names differ. She notes that errors like this are personal data breaches under the GDPR definition in Article 4(12), which includes accidental disclosure, not only attacks, and that they must be handled through the breach process.

Worked example

Zara links security goals to data protection, adds step-up authentication, maps controls to Article 32 and treats misattached results as both a safety issue and a personal data breach.

Synthetic case. Pellmore's controls are synthetic; GDPR Articles 4(12), 5(1)(f) and 32 are real.

Errors and limits

Strong authentication can exclude patients with limited access to devices; offer alternatives.

Exercises

EX043 — Not sufficient. Why is security necessary but not sufficient for privacy? Rubric: 3 = a secure system can still over-collect or misuse data;; 2 = mentions purposes;; 1 = equates them;; 0 = none.
EX044 — Step-up actions. Which patient actions get a second factor, and why? Rubric: 3 = viewing records and changing contacts, the most attractive to attackers;; 2 = names one;; 1 = all logins only;; 0 = none.
EX045 — Accidental breach. Is a result attached to the wrong patient a personal data breach? Rubric: 3 = yes; Article 4(12) includes accidental disclosure;; 2 = yes without reason;; 1 = no;; 0 = none.

Synthesis

Chapter 15 relates security to data protection. Chapter 16 takes a systems view.

Continue studying — chapter 15 of 50

← Chapter 14 (draft) · Course chapter index · Chapter 16 (draft) →