Chapter 1 — Calculus I
Lesson map
Lesson 01 published. Map, example, EX001.
flowchart TD
N0["Learning outcomes"]
N1["1.1 Why calculus in a SOC"]
N2["1.2 The course case"]
N3["1.3 From continuous to discrete"]
N4["Lab — queue as a rate"]
N5["1.4 Reading the result"]
N6["1.5 Engineering meaning"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX001"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["1.1 Why calculus in a SOC"]
N2["1.2 The course case"]
N3["1.3 From continuous to discrete"]
N4["Lab — queue as a rate"]
N5["1.4 Reading the result"]
N6["1.5 Engineering meaning"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX001"]
[Learning outcomes]
|
v
[1.1 Why calculus in a SOC]
|
v
[1.2 The course case]
|
v
[1.3 From continuous to discrete]
|
v
[Lab — queue as a rate]
|
v
[1.4 Reading the result]
|
v
[1.5 Engineering meaning]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX001]
Learning outcomes
You will (1) model an alert queue with rates of change; (2) read a derivative as "how fast the backlog grows"; (3) connect continuous models with hourly data; (4) explain why SOC staffing is a rate problem.
1.1 Why calculus in a SOC
Security operations handle flows: alerts arrive, analysts clear them, and the backlog is what is left. Calculus is the language of change. If A(t) is the arrival rate and C(t) the clearing rate, the backlog B(t) changes as dB/dt = A(t) − C(t). When arrivals exceed capacity, the backlog rises; when capacity exceeds arrivals, it falls.
The same equation describes a bath filling while the plug is half open. For a SOC lead, its value is that it separates two questions people often mix up: how many alerts arrived today, and how fast they arrived compared with how fast the team can work. A day with a modest total can still overwhelm a shift if most alerts arrive within two hours.
1.2 The course case
Amara Osei, an engineering student at the fictional Kingsbridge Engineering University, joins the security operations centre of the fictional Lindqvist Freight on placement. Her mentor is detection engineer Paolo Ricci. On her first day the customer portal suffers a burst of failed logins, and the alert queue grows faster than the two analysts on shift can clear it.
The burst is a common pattern on public login pages: many failed attempts against many usernames, often from a small range of addresses. Amara's first task is not to decide whether an attack happened but to understand why the queue grew, which leads directly into rates. The same incident returns throughout the book, each chapter looking at it through a different tool.
1.3 From continuous to discrete
Real data comes in hourly counts, not smooth curves. The derivative becomes a difference: backlog change per hour equals arrivals that hour minus alerts handled. The integral — total backlog — becomes a running sum.
In symbols, B[n] = B[n−1] + A[n] − C[n], with the rule that backlog cannot fall below zero, since an idle analyst cannot clear alerts that do not exist yet. The hourly step is a choice; per-minute counts would show more detail but more noise. Amara builds the running sum in a spreadsheet first, one row per hour, so every step can be checked by hand.
Lab — queue as a rate
"""Alert queue as a rate problem: backlog change = arrivals - handled, per hour (synthetic)."""
arrivals = [40, 55, 70, 90, 85, 60, 45, 30] # alerts per hour, 08:00-16:00
capacity = 60 # alerts the shift can triage per hour
backlog = 0
peak = 0
for h, a in enumerate(arrivals):
handled = min(capacity, backlog + a)
rate = a - handled
backlog += rate
peak = max(peak, backlog)
print(f"{8+h:02d}:00 arrivals={a:3} handled={handled:3} d(backlog)/dt={rate:+4} backlog={backlog:3}")
print("peak backlog", peak, "| backlog at 16:00", backlog)
Run with python3 lab_queue.py. Verified output:
08:00 arrivals= 40 handled= 40 d(backlog)/dt= +0 backlog= 0
09:00 arrivals= 55 handled= 55 d(backlog)/dt= +0 backlog= 0
10:00 arrivals= 70 handled= 60 d(backlog)/dt= +10 backlog= 10
11:00 arrivals= 90 handled= 60 d(backlog)/dt= +30 backlog= 40
12:00 arrivals= 85 handled= 60 d(backlog)/dt= +25 backlog= 65
13:00 arrivals= 60 handled= 60 d(backlog)/dt= +0 backlog= 65
14:00 arrivals= 45 handled= 60 d(backlog)/dt= -15 backlog= 50
15:00 arrivals= 30 handled= 60 d(backlog)/dt= -30 backlog= 20
peak backlog 65 | backlog at 16:00 20
1.4 Reading the result
With a capacity of 60 alerts per hour, the backlog stays at zero until 10:00, then grows at +10, +30 and +25 per hour, peaking at 65 alerts by 13:00. It only begins to fall at 14:00 and is still 20 at 16:00. The peak follows the area between the arrival curve and the capacity line, not the single worst hour.
The surprise for Amara is that the backlog keeps rising after the worst hour has passed. As long as arrivals exceed sixty, the queue grows, even if more slowly. It falls only once arrivals drop below capacity, and then only by the size of that gap each hour. That is why the queue lingered into the afternoon although the burst itself was over by early afternoon.
1.5 Engineering meaning
Adding one analyst at 10:00 would raise capacity above the peak arrival rate and keep the backlog near zero. Rates, not daily totals, tell you when help is needed.
The same model answers other questions too: how long a backlog of 65 takes to clear at a given spare capacity, or how early help must arrive to keep the peak under a target. Paolo points out that real analysts do not clear alerts at a fixed rate, since hard alerts take longer, so the model gives a planning estimate rather than a precise forecast.
Worked example
Paolo asks Amara how long an alert that arrives at 12:00 waits. She reasons that it joins a queue of 40 alerts with capacity 60 per hour, so it waits about 40 minutes before an analyst reaches it — long enough to matter for a live credential attack.
Synthetic case. Lindqvist Freight, Kingsbridge University, Amara and Paolo are invented; the counts come from the lab script.
Errors and limits
The model assumes every alert takes the same time and analysts never pause; real triage time varies widely, so treat results as first estimates.
Exercises
- EX001 — Backlog equation. Write the equation for backlog change and explain each term. Rubric: 3 = dB/dt = A − C with arrivals and clearing explained; 2 = equation without meaning; 1 = words only; 0 = none.
- EX002 — Peak timing. When and why does the backlog peak in the lab? Rubric: 3 = 13:00 at 65; arrivals exceed capacity 10:00–12:00 and equal it at 13:00; 2 = peak value only; 1 = wrong time; 0 = none.
- EX003 — Waiting time. Estimate the wait for an alert arriving at 12:00. Rubric: 3 = about 40 minutes from 40 queued at 60/h; 2 = method without number; 1 = guess; 0 = none.
Synthesis
Alert queues follow rates; treating arrivals and capacity as functions of time shows when backlogs form and how much extra capacity removes them.