Chapter 1 — Mathematical reasoning | Bachelor's Incident response and cyber resilience

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 1 — Mathematical reasoning

Lesson map

Lesson 01 published. Map, example, EX001.

flowchart TD
  N0["Learning outcomes and connection"]
  N1["1.1 Why responders need formal reasoning"]
  N2["1.2 Sets, predicates and quantifiers"]
  N3["1.3 Functions, mappings and their failure modes"]
  N4["1.4 Implication, converse and contrapositive"]
  N5["1.5 Correlation is not implication"]
  N6["1.6 Units and dimensional consistency"]
  N7["1.7 Uncertainty as part of the statement"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX001"]

Logical drawing

flowchart LR
  N0["Learning outcomes and connection"]
  N1["1.1 Why responders need formal reasoning"]
  N2["1.2 Sets, predicates and quantifiers"]
  N3["1.3 Functions, mappings and their failure modes"]
  N4["1.4 Implication, converse and contrapositive"]
  N5["1.5 Correlation is not implication"]
  N6["1.6 Units and dimensional consistency"]
  N7["1.7 Uncertainty as part of the statement"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX001"]

[Learning outcomes and connection]
    |
    v
[1.1 Why responders need formal reasoning]
    |
    v
[1.2 Sets, predicates and quantifiers]
    |
    v
[1.3 Functions, mappings and their failure modes]
    |
    v
[1.4 Implication, converse and contrapositive]
    |
    v
[1.5 Correlation is not implication]
    |
    v
[1.6 Units and dimensional consistency]
    |
    v
[1.7 Uncertainty as part of the statement]
    |
    v
[Worked example] --> [Exercise EX001]

Learning outcomes and connection

After this chapter you can (1) restate an incident-response claim as a precise statement about sets, functions and implications; (2) refute a universal claim with a single well-chosen counterexample; (3) separate a correlation in a dashboard from a causal claim; and (4) carry units and uncertainty through a calculation so that a number cannot silently change meaning. The chapter assumes school algebra. It prepares Chapter 2, where the same habits are applied to computing systems, and it is the base for statistics (Chapter 12) and measurement (Chapter 15).

1.1 Why responders need formal reasoning

Incident response is full of confident sentences: "faster triage reduces impact", "all privileged sign-ins come through the VPN", "no data left the network". Each is a claim about a set of cases and a relationship between properties of those cases. When such a sentence is wrong, the cost is real: a team that believes every privileged sign-in passes through the VPN will not look for one that did not. Mathematical reasoning does not make responders slower; it makes their sentences checkable. The goal at bachelor's level is not proof-writing for its own sake but the habit of asking: over which cases is this claimed, what exactly is asserted, and what single observation would make it false?

1.2 Sets, predicates and quantifiers

A set is a collection of distinct objects, for example the set C of incident cases opened in a quarter. A predicate is a property that each element has or lacks, such as Fast(c): "case c was triaged within 15 minutes". Quantifiers tell you how much is claimed. "For all c in C, Fast(c) implies LowImpact(c)" is a universal claim; "there exists c in C with Fast(c) and HighImpact(c)" is an existential claim. The two are linked: the negation of "for all, P implies Q" is "there exists one with P and not Q". That is why one counterexample is enough to refute a universal claim, while no number of confirming examples proves it.

Set operations make filters explicit. If A is the set of cases with authentication alerts and B the set with endpoint alerts, A ∩ B (both), A ∪ B (either) and A \ B (authentication only) are different populations, and a percentage computed on one cannot be reported as if it described another. Many dashboard errors are set errors: a rate computed on closed cases, Cclosed, is quoted as a rate for all cases, C.

1.3 Functions, mappings and their failure modes

A function f: X → Y assigns exactly one output to each input. Severity assignment should behave like a function from case facts to a severity level: identical facts, identical level. When two analysts give the same facts different levels, the "function" is not well defined, and any metric built on severity inherits that ambiguity. Two properties matter often. A function is injective when distinct inputs give distinct outputs; a pseudonymization mapping from user names to tokens must be injective or two people will be merged into one token. A function is total when it is defined for every input; a parser that crashes on malformed timestamps is partial, and the inputs it rejects are a hidden subset that may not be random.

1.4 Implication, converse and contrapositive

The statement P → Q ("if P then Q") is false only when P is true and Q is false. Its contrapositive, ¬Q → ¬P, is logically equivalent; its converse, Q → P, is not. Responders confuse these constantly. "If an account is compromised, it will show impossible-travel alerts" does not license "this account shows impossible travel, so it is compromised" (converse), nor "no impossible-travel alert, so not compromised" (that is the inverse, ¬P → ¬Q, also not equivalent). The contrapositive is the useful one: "if no impossible-travel alert was possible because the account signs in only from one location, then the rule cannot be our detection for this account".

1.5 Correlation is not implication

A dashboard can show that cases triaged quickly have lower average impact. That is an association between two variables over a set. Causation would require that changing triage speed, holding other things fixed, changes impact. Several mechanisms produce the association without causation: easy, low-impact cases are triaged quickly because they are easy (reverse direction); a night shift with fewer staff both triages slowly and receives a different case mix (common cause); and only cases that were closed are counted (selection). Formal reasoning gives you the vocabulary to name each mechanism and design a check.

1.6 Units and dimensional consistency

Every quantity in a report should carry a unit. "Mean time to contain: 4.2" is not information. Units also catch errors: adding minutes to hours, or dividing incidents by analysts and calling the result a rate per day. A useful discipline is to write the unit next to every intermediate value. Ratios need explicit denominators: "incidents per 1,000 endpoints per month" is comparable across sites; "incidents" alone is not.

Units also expose hidden conversions. If one clinic logs triage time in minutes and the managed detection service reports it in hours, a merged column averages incompatible numbers without any error message. Before combining sources, list each field with its unit and its source, convert explicitly in one place, and keep the original column so a reviewer can repeat the conversion. A percentage is a ratio too: write what was divided by what, because 30 per cent of alerts and 30 per cent of cases describe different populations.

1.7 Uncertainty as part of the statement

A value without uncertainty claims more than it knows. At this stage you need three simple tools: ranges ("between 120 and 340 accounts, depending on whether disabled accounts are included"), explicit assumptions ("assuming the log clock is accurate to ±2 seconds"), and the distinction between unknown and zero. A field that is empty because a sensor was offline is not evidence that nothing happened. Writing "unknown (sensor gap 02:00–03:10)" is mathematically more honest than writing 0.

Uncertainty also has to survive arithmetic. If an account count is a range, a cost estimate built on it is a range as well, and reporting only the midpoint quietly discards what you knew. When a number feeds a decision, state the end of the range that would change the decision, so the reader sees whether the uncertainty actually matters for the choice in front of them.

1.8 Worked example (synthetic): the dashboard claim

All names and numbers in this example are fictional. The response team at the Harbourline Health Cooperative, a synthetic regional clinic network used throughout this book, publishes a dashboard sentence: "Faster triage always reduces incident impact." The quarter contains 40 cases. Impact is scored 1–4 by a review panel after closure.

Step 1 — formalize. Let C be the 40 cases. Let t(c) be triage time in minutes and i(c) the impact score. "Always reduces" most plausibly means: for all pairs of cases a, b in C, if t(a) < t(b) then i(a) ≤ i(b). That is a universal claim about a monotone relationship.

Step 2 — find a counterexample. Case H-07 was triaged in 6 minutes and scored impact 4 (ransomware detected late in its life cycle); case H-19 was triaged in 55 minutes and scored impact 1 (a misdirected phishing report). The pair (H-07, H-19) satisfies t(a) < t(b) but i(a) > i(b). The universal claim is false.

Step 3 — repair the claim. A defensible version is an existential or average claim with stated scope: "In Q3, among closed cases, the mean impact score of cases triaged within 15 minutes (n = 22) was 1.8, versus 2.3 for slower cases (n = 18); this is an association, not evidence that speed caused lower impact."

Step 4 — name the data needed to test a causal version. One would need cases comparable in their initial facts, triage speed varying for reasons unrelated to impact (for example staffing changes), and impact measured the same way for all, including still-open cases.

1.9 Practical activity

Take any three sentences from a public incident report or vendor dashboard. For each, write the set it ranges over, the predicate(s), the quantifier, and one observation that would falsify it. Then mark each value with its unit and say whether "unknown" could have been recorded as zero.

A worked line might read: set, all phishing reports received by a clinic network in March; predicate, reported by staff rather than caught by a filter; quantifier, all; falsifier, one report raised automatically by the mail gateway. Compare your three analyses with a classmate. Where you disagree about the set, the original sentence was ambiguous, and that ambiguity is the finding worth writing down rather than a mistake to hide.

1.10 Common errors and limits

Treating many confirming examples as proof of a universal claim.
Reasoning from the converse or inverse of an implication.
Reporting a rate without its denominator or on a different set from the one named.
Recording missing data as zero.
Over-formalizing: the aim is clarity about claims, not symbols for their own sake. Formal reasoning cannot tell you whether a premise (a log line, a witness statement) is true; that is the job of evidence evaluation later in the book.

A further limit concerns small sets. The Harbourline quarter has only 40 cases, so a single unusual case such as H-07 can move a mean noticeably; report counts beside averages so the reader can judge stability. Finally, a repaired claim is only as good as its scope: an association true for closed Q3 cases says nothing about next quarter's open ones.

Exercises — chapter 1

Attempt each exercise before opening the worked results. Every case, organization, person, address and number in an exercise is synthetic unless a cited public source is named.

EX001 — Counterexample hunt. Inputs: the claim "every incident involving a privileged account is high severity" and the synthetic cases P1 (privileged test account in an isolated lab, no data, impact 1), P2 (domain administrator used from an unknown host, impact 4). Steps: formalize the claim with a quantifier; decide whether either case refutes it; rewrite the claim so that it is defensible. Rubric: 3 = correct formalization, P1 identified as counterexample under a severity-equals-impact reading, scoped rewrite; 2 = counterexample found but rewrite still universal; 1 = argued by examples only; 0 = none.

EX002 — Converse trap. Inputs: "If a host is infected with the synthetic malware family KESTREL, it beacons every 60 seconds to an external address." An analyst sees a host beaconing every 60 seconds. Steps: state the converse, inverse and contrapositive; say which inference the analyst may draw; list two other explanations for 60-second beacons. Rubric: 3 = all three forms correct, conclusion limited to "consistent with", two plausible alternatives (e.g., update agent, monitoring heartbeat); 2 = one form wrong; 1 = analyst's conclusion accepted; 0 = none.

EX003 — Units and denominators. Inputs: Site North: 18 phishing reports, 450 staff, 3 months. Site South: 30 phishing reports, 1,200 staff, 6 months. A manager says South "has a bigger phishing problem". Steps: compute a comparable rate with units; state what the rate measures (reports, not attacks); give one reason the comparison may still mislead. Rubric: 3 = rates correct (North 13.3, South 4.2 reports per 1,000 staff per month), measure correctly named, sound limitation; 2 = arithmetic slip; 1 = raw counts compared; 0 = none.

Chapter synthesis

State every claim with its set, quantifier and units. A universal claim falls to one counterexample; an implication is not its converse; an association is not a cause; and "unknown" is not zero. These habits make later evidence work checkable.

Continue studying — chapter 01 of 40

← Course home · Course chapter index · Chapter 02 →

Continue to the next authored lesson.