Chapter 6 — Discrete structures

Lesson map

Lesson 06 published. Map, example, EX016.

flowchart TD
  N0["Learning outcomes"]
  N1["6.1 Roles as sets"]
  N2["6.2 Segregation of duties"]
  N3["6.3 Dependency graphs"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX016"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["6.1 Roles as sets"]
  N2["6.2 Segregation of duties"]
  N3["6.3 Dependency graphs"]
  N4["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX016"]

[Learning outcomes]
    |
    v
[6.1 Roles as sets]
    |
    v
[6.2 Segregation of duties]
    |
    v
[6.3 Dependency graphs]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX016]

Learning outcomes

You will (1) represent roles and permissions as sets and relations; (2) find segregation of duties conflicts; (3) use graphs to trace dependencies.

6.1 Roles as sets

Sofia represents Elmfield's finance roles as sets of permissions. The payments clerk can enter supplier invoices and record payments. The finance manager can approve payments and add new suppliers. She lists which staff hold which roles and computes each person's combined permissions. One person covering for a colleague holds both roles, giving permission to add a supplier and approve payment to it. Sets make this conflict visible immediately rather than relying on someone noticing. Here the cover arrangement is the source of the conflict, not anyone's intent.

6.2 Segregation of duties

Segregation of duties prevents one person from completing a sensitive process alone. Sofia writes rules as forbidden pairs of permissions, such as add supplier with approve payment. She checks each person's permission set against the rules and finds the one conflict. She recommends that cover arrangements use temporary access with a second approver and an end date. She learns that this simple logic underlies many fraud controls and that it can be checked automatically each month. A monthly automated check would also catch a cover arrangement that was supposed to end but never did.

6.3 Dependency graphs

Sofia draws a graph where nodes are systems and edges show dependencies. The housing management system depends on cloud identity, which depends on email. If cloud identity fails, staff cannot reach housing records. The graph shows that identity is a single point of failure for most services. She learns that graphs reveal hidden concentrations of risk that inventories alone do not show, and that resilience planning should focus on nodes with many dependents. Dr. Haddad suggests checking how staff would reach housing records if cloud identity failed, since the graph shows it supports most services.

Worked example

Sofia finds a segregation of duties conflict through set operations and identifies cloud identity as a single point of failure with a graph.

Synthetic case. Roles, staff and systems are synthetic.

Errors and limits

Permission data may be incomplete. Graphs miss informal dependencies.

Exercises

• EX016 — Conflict found. What conflict did Sofia find?
  Show marking criteria

  Rubric: 3 = one person could add a supplier and approve payment;; 2 = SoD;; 1 = vague;; 0 = none.
• EX017 — Cover fix. How should cover arrangements work?
  Show marking criteria

  Rubric: 3 = temporary access with second approver and end date;; 2 = temporary;; 1 = vague;; 0 = none.
• EX018 — Single point. Which system is a single point of failure?
  Show marking criteria

  Rubric: 3 = cloud identity;; 2 = identity;; 1 = email;; 0 = none.

Synthesis

Sets, relations and graphs make access conflicts and dependency risks visible.

Continue studying — chapter 06 of 40

← Chapter 05 (draft) · Course chapter index · Chapter 07 (draft) →