Lesson map
Lesson 12 published. Map, example, EX034.
flowchart TD
N0["Learning outcomes"]
N1["12.1 Permissions"]
N2["12.2 System logs"]
N3["12.3 Temporary files"]
N4["12.4 Updates and patching"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Worked example"]
EX --> Q["Exercise EX034"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["12.1 Permissions"]
N2["12.2 System logs"]
N3["12.3 Temporary files"]
N4["12.4 Updates and patching"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX034"]
[Learning outcomes]
|
v
[12.1 Permissions]
|
v
[12.2 System logs]
|
v
[12.3 Temporary files]
|
v
[12.4 Updates and patching]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX034]
Learning outcomes
You will (1) apply file permissions to protect records; (2) control logging at the operating system level; (3) manage temporary files.
12.1 Permissions
Zara studies how operating systems enforce permissions. On Pellmore's records server she finds that export files are written to a shared directory readable by all users. Any account on the server, including monitoring tools, could read them. She changes the export process to write into a directory owned by a dedicated service account with no access for others. Least privilege at the operating system level is a basic control, she notes, but it is often overlooked because applications are tested on developer machines where everyone is an administrator.
12.2 System logs
Operating systems log events, and applications sometimes write sensitive data into system logs. Zara searches Pellmore's server logs for patterns resembling birth dates and email addresses and finds several. She configures log rotation with defined retention and adds a filter that masks identifiers before they are written. She also restricts who can read the logs. Logs are needed for security, she writes, but they must be designed with the same care as databases, because they often contain the most complete record of what happened to whom.
12.3 Temporary files
Report generation creates temporary files on disk, which are not always cleaned up after crashes. Zara finds hundreds of leftover temporary reports containing patient names. She changes the process to use the operating system's secure temporary file functions with restrictive permissions and to clean up on start, and she adds a scheduled job that deletes any temporary report older than one day. The finding shows her that data protection requires attention to the unglamorous parts of systems as well as their main databases.
12.4 Updates and patching
Finally, Zara checks patch levels. Unpatched operating systems are a frequent cause of breaches. She learns that Pellmore patches monthly but has no record of when critical patches were applied. She proposes tracking patch delay as a metric and agreeing a maximum delay for critical security updates. Prof. Holm reminds her that Article 32 asks for a process for regularly testing and evaluating the effectiveness of security measures, and patch metrics are one way to show that such a process actually exists. Her metric: days to patch.
Worked example
Zara moves exports to a service-owned directory, masks identifiers in system logs, cleans leftover temporary reports and proposes tracking patch delay.
Synthetic case. The server findings are synthetic; GDPR Article 32 is real.
Errors and limits
Masking filters miss unusual formats; periodic searches remain necessary.
Exercises
- EX034 — Shared export directory. What was wrong with the export directory?
Show marking criteria
Rubric: 3 = it was readable by every account on the server;; 2 = mentions permissions;; 1 = vague;; 0 = none. - EX035 — Temporary reports. How does Zara deal with leftover temporary reports?
Show marking criteria
Rubric: 3 = secure temp functions, cleanup on start and a daily deletion job;; 2 = one measure;; 1 = ignores;; 0 = none. - EX036 — Patch metric. Why track patch delay?
Show marking criteria
Rubric: 3 = to show a regular process for testing and maintaining security, as Article 32 expects;; 2 = mentions patching;; 1 = vague;; 0 = none.
Synthesis
Chapter 12 tightens the operating system. Chapter 13 enforces retention in databases.
Continue studying — chapter 12 of 50
← Chapter 11 (draft) · Course chapter index · Chapter 13 (draft) →