Chapter 2 — Discrete mathematics
Lesson map
Lesson 02 published. Map, example, EX004.
flowchart TD
N0["Learning outcomes"]
N1["2.1 Sets of users and rights"]
N2["2.2 Relations and functions"]
N3["2.3 Graphs of trust"]
N4["2.4 Logic for rules"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Worked example"]
EX --> Q["Exercise EX004"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["2.1 Sets of users and rights"]
N2["2.2 Relations and functions"]
N3["2.3 Graphs of trust"]
N4["2.4 Logic for rules"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX004"]
[Learning outcomes]
|
v
[2.1 Sets of users and rights]
|
v
[2.2 Relations and functions]
|
v
[2.3 Graphs of trust]
|
v
[2.4 Logic for rules]
|
v
[Worked example] --> [Exercise EX004]
Learning outcomes
You will (1) use sets to describe access rights; (2) model trust and dependencies as graphs; (3) express security rules in logic.
2.1 Sets of users and rights
Lindiwe describes Saltmarsh's access as sets: staff, accounts, groups and permissions. The set of accounts with payroll access should be a subset of the finance group. Set difference makes violations visible: payroll-access accounts minus finance staff should be empty. If it is not, someone holds rights outside their role. She writes such conditions as rules that can be checked automatically, noting that set notation makes a security policy precise enough to test rather than merely discuss. She runs the check against a synthetic directory export and finds four such accounts.
2.2 Relations and functions
A relation links accounts to people. Lindiwe checks whether it is a function: each named account should belong to exactly one person. Shared accounts break this, because actions cannot be traced to an individual. In a synthetic directory she finds several warehouse terminal accounts used by whole shifts. She explains that accountability, a core security property, depends on this mapping being a function, and that service accounts need a named owner even though no person logs in with them. Each shift account is listed.
2.3 Graphs of trust
Lindiwe models Saltmarsh's systems as a directed graph, with an edge where one system trusts another, for example a file server accepting logins from the directory. Reachability shows what an attacker could reach after compromising one node. A compromised depot laptop that can reach the directory can potentially reach almost everything. She learns that graph analysis underlies attack path reasoning, and that removing a few edges, such as unnecessary admin trust, can cut many paths at once. She draws the graph for twenty core systems.
2.4 Logic for rules
Security rules can be stated in logic. Lindiwe writes: for every account, if the account is privileged then multi-factor authentication is enabled. She checks the contrapositive: any account without multi-factor authentication must not be privileged. Prof. Hale shows how precise statements avoid arguments between teams over vague phrases such as admins should be protected. She learns that writing rules formally first makes code checks and audit evidence consistent with the policy wording. She lists five privileged accounts that fail the rule in the synthetic directory, and the identity team agrees to enrol each one before the next audit.
Worked example
Lindiwe uses set difference to find out-of-role payroll access, checks account-to-person mapping, models trust as a graph and writes an MFA rule in logic.
Synthetic case. The directory is synthetic.
Errors and limits
A formal rule can still encode the wrong policy; confirm it with owners.
Exercises
- EX004 — Empty difference. Which set difference should be empty? Rubric: 3 = payroll-access accounts minus finance staff;; 2 = partly correct;; 1 = vague;; 0 = none.
- EX005 — Shared accounts. Why do shared accounts harm accountability? Rubric: 3 = actions cannot be traced to a person;; 2 = partly correct;; 1 = vague;; 0 = none.
- EX006 — Cutting paths. How can many attack paths be cut at once? Rubric: 3 = remove a few trust edges;; 2 = partly correct;; 1 = vague;; 0 = none.
Continue studying — lesson 02 (chapter 02 of 50)
← Chapter 01 · Course chapter index · Chapter 03 →
Continue to the next authored lesson.