Chapter 15 — Security fundamentals

Chapter 15 — Security fundamentals

Lesson map

Lesson 15 published. Map, example, EX043.

flowchart TD
  N0["Learning outcomes"]
  N1["15.1 Three properties"]
  N2["15.2 Access by role"]
  N3["15.3 Incidents and data"]
  N4["15.4 Security and governance together"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX043"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["15.1 Three properties"]
  N2["15.2 Access by role"]
  N3["15.3 Incidents and data"]
  N4["15.4 Security and governance together"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX043"]

[Learning outcomes]
    |
    v
[15.1 Three properties]
    |
    v
[15.2 Access by role]
    |
    v
[15.3 Incidents and data]
    |
    v
[15.4 Security and governance together]
    |
    v
[Worked example] --> [Exercise EX043]

Learning outcomes

You will (1) apply confidentiality, integrity and availability to utility data; (2) choose access controls for data sets; (3) relate security incidents to data governance.

15.1 Three properties

Kofi applies the classic security properties to Tidewater's data. Confidentiality protects customer details and the priority services register. Integrity protects meter readings and sensor values from unauthorised change, which matters for billing and safety. Availability ensures operators see sensor data during incidents. Different data sets need different emphasis: control system data need availability and integrity first, while customer data need confidentiality. Governance assigns these priorities so engineers know which trade-offs are acceptable. The priorities are written into each data set's catalogue entry so engineers see them when building systems.

15.2 Access by role

Kofi designs role-based access for data sets. Billing analysts see readings and tariffs but not the priority register. Field staff see premise and meter details for jobs assigned to them. Data scientists work on pseudonymised extracts with customer identifiers replaced. Each role is approved by the data owner. He finds that analysts currently share one account for the data warehouse, which prevents accountability, and replaces it with named accounts linked to roles. Access is reviewed by each owner every quarter, and unused roles are removed.

15.3 Incidents and data

When a contractor's laptop with a customer extract is stolen, Kofi helps analyse the incident. The extract contained names and addresses for one district and was not encrypted. Because it was personal data, the data protection officer assesses notification under Article 33 of the GDPR. Kofi traces why the extract existed: a one-off request approved informally. He recommends that extracts follow a request process with an owner's approval, minimal fields, encryption and an expiry date. The district's customers receive a letter explaining what happened.

15.4 Security and governance together

Kofi notes that security controls protect data, while governance decides what data should exist, who owns them and for what purposes. The stolen extract would have been harmless if governance had refused unnecessary fields or required pseudonymisation. Prof. Varga explains that the two disciplines share tools such as access control and logging, but answer different questions, and that effective organisations connect them through shared ownership and policies. At Tidewater, the security manager and the data governance lead now meet monthly and share one register of data risks.

Worked example

Kofi assigns security priorities by data set, designs role-based access with named warehouse accounts, analyses a stolen extract and recommends a governed extract process.

Synthetic case. The incident is synthetic; GDPR Article 33 is real.

Errors and limits

Pseudonymised data remain personal data; protect them accordingly.

Exercises

• EX043 — Control data priority. Which properties come first for control system data? Rubric: 3 = availability and integrity;; 2 = both;; 1 = one;; 0 = none.
• EX044 — Shared account. What warehouse problem did Kofi fix? Rubric: 3 = shared analyst account replaced by named accounts;; 2 = partly correct;; 1 = vague;; 0 = none.
• EX045 — Extract rules. Name two rules for future extracts. Rubric: 3 = owner approval, minimal fields, encryption, expiry;; 2 = two;; 1 = one;; 0 = none.

Continue studying — lesson 15 (chapter 15 of 50)

← Chapter 14 · Course chapter index · Chapter 16 →

Continue to the next authored lesson.