◇ OpenCyber Academy
Engineering · Chapter 2 · English

Chapter 2 — Discrete mathematics

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 2 — Discrete mathematics

Lesson map

Lesson 02 published. Map, example, EX004.

flowchart TD
  N0["Learning outcomes"]
  N1["2.1 Sets in detection"]
  N2["2.2 Logic"]
  N3["2.3 Relations and graphs"]
  N4["2.4 Counting"]
  N5["2.5 Case use"]
  N6["2.6 Precision of language"]
  N7["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX004"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["2.1 Sets in detection"]
  N2["2.2 Logic"]
  N3["2.3 Relations and graphs"]
  N4["2.4 Counting"]
  N5["2.5 Case use"]
  N6["2.6 Precision of language"]
  N7["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX004"]
[Learning outcomes]
    |
    v
[2.1 Sets in detection]
    |
    v
[2.2 Logic]
    |
    v
[2.3 Relations and graphs]
    |
    v
[2.4 Counting]
    |
    v
[2.5 Case use]
    |
    v
[2.6 Precision of language]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX004]

Learning outcomes

You will (1) use sets and relations to describe users, hosts and alerts; (2) apply logic to detection conditions; (3) count combinations for correlation rules; (4) reason about graphs of logons.

2.1 Sets in detection

A detection often asks set questions. Which users failed to log in from network N? Which of them later succeeded? If F is the set of usernames with failures and S the set with successes from the same network, F ∩ S are accounts that may have been guessed correctly.

Set notation turns a vague hunch into a precise query. The intersection does not prove compromise; a customer who mistyped a password twice and then succeeded also lands in F ∩ S. What it does is shrink the list from everyone who failed to the few worth a closer look, which is what a triage step should do.

2.2 Logic

Rule conditions are logical formulas. "Process is PowerShell AND parent is an Office application" is a conjunction; adding OR widens a rule; adding NOT narrows it. Writing conditions in logic makes their scope explicit and testable, which is how the Sigma format expresses detection logic.

Mistakes in logic produce real errors: writing OR where AND was meant can turn a precise rule into one that fires on every Office document. Truth tables help check small rules by listing every combination of conditions and the expected outcome. Sigma rules use named selections joined in a condition line, which keeps the logic readable even when each selection has many fields.

2.3 Relations and graphs

A logon from user u to host h is a pair (u, h). Together the pairs form a bipartite graph. An account that suddenly connects to many new hosts shows as a node whose degree jumps.

Degree here means the number of distinct hosts an account touches in a time window. A help-desk account might normally connect to dozens, while a payroll clerk connects to two or three, so the jump matters relative to each account's own history. Graphs also show paths, such as an account reaching a server through an intermediate host, which lists of pairs hide.

2.4 Counting

Correlation rules combine events. With 7 event types, a rule over any 3 types in order has 7 × 6 × 5 = 210 possibilities. Counting shows why exhaustive correlation explodes and why rules must be chosen from threat knowledge, such as MITRE ATT&CK techniques.

If order does not matter, the count drops to 7 choose 3, which is 35, but adding time windows and field conditions multiplies the possibilities again. No team can write and test hundreds of correlations, so threat knowledge narrows the search to sequences attackers actually use. ATT&CK provides that grounding by describing techniques observed in real intrusions.

2.5 Case use

During the portal burst, Amara lists F (usernames with failures from 203.0.113.0/24) and S (usernames with success from the same network). One name, u5, is in both: a candidate compromised customer account.

The address range 203.0.113.0/24 is reserved for documentation, which suits a synthetic case. Amara writes both sets out explicitly, which lets Paolo check her reasoning line by line. The next step is not to lock u5 at once but to check the success's details, such as time, device and what the session did, before deciding on action.

2.6 Precision of language

Discrete maths forces exact language: "many" becomes "more than 5 distinct usernames in 10 minutes". That precision makes rules reviewable.

Reviewable means another analyst can read the rule and agree, or disagree, on what it should catch. 'Many' invites arguments; 'more than five in ten minutes' invites a test. The precise version can also be tuned with evidence, by counting how often legitimate users exceed five failures in ten minutes and adjusting the threshold with data rather than opinion. Units belong in every threshold.

Worked example

Amara writes the rule condition as: count(distinct username where result = fail and source in N, 10 min) > 5 AND exists(username in that set where result = ok). Paolo notes that the second clause turns a noisy "spray" alert into a sharper "possible compromise" alert.

Synthetic case. Usernames and networks are synthetic.

Errors and limits

Set logic is exact but the data is not: missing logs make sets incomplete, so empty results do not prove absence.

Exercises

Synthesis

Sets, logic, graphs and counting give detection rules exact meaning and show why rule choice must be guided by threat knowledge.

Continue studying — chapter 02 of 50

← Chapter 01 (draft) · Course chapter index · Chapter 03 (draft) →