Chapter 6 — Calculus II
Lesson map
Lesson 06 published. Map, example, EX016.
flowchart TD
N0["Learning outcomes"]
N1["6.1 Exponential decay"]
N2["6.2 Half-life of exposure"]
N3["6.3 Inflow and backlog"]
N0 --> N1 --> N2 --> N3
N3 --> EX["Worked example"]
EX --> Q["Exercise EX016"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["6.1 Exponential decay"]
N2["6.2 Half-life of exposure"]
N3["6.3 Inflow and backlog"]
N0 --> N1 --> N2 --> N3 --> Q["EX016"]
[Learning outcomes]
|
v
[6.1 Exponential decay]
|
v
[6.2 Half-life of exposure]
|
v
[6.3 Inflow and backlog]
|
v
[Worked example] --> [Exercise EX016]
Learning outcomes
You will (1) model growth and decay in security processes; (2) use exponential models for vulnerability backlog; (3) interpret half-life of exposure.
6.1 Exponential decay
Many security processes decay roughly exponentially. If Saltmarsh patches a fixed fraction of open vulnerabilities each week, the backlog falls by the same proportion every week. Lindiwe fits such a model to synthetic data: about fifteen percent of open findings are closed weekly. Solving the differential equation gives a curve she can compare with targets. Prof. Hale notes that the model is simple but useful for asking whether a target is achievable at current effort. Lindiwe plots the fitted curve against twelve weeks of synthetic closure data.
6.2 Half-life of exposure
From the decay rate, Lindiwe computes a half-life: the time for half of a set of new vulnerabilities to be fixed. At fifteen percent per week, the half-life is a little over four weeks. Critical vulnerabilities exploited in the wild need much faster closure. She concludes that a single weekly rate hides important differences and that Saltmarsh should track separate rates by severity, since an average comfortable for low findings may be dangerous for critical ones. She proposes separate dashboards for each severity.
6.3 Inflow and backlog
The backlog also grows as new vulnerabilities are disclosed. Lindiwe writes a differential equation with constant inflow and proportional closure. Its steady state equals inflow divided by the closure rate. With about sixty new findings per week, the backlog settles near four hundred. To halve it, Saltmarsh must double the closure rate or halve inflow, for example by removing unused software. She learns that reducing what is installed can be as effective as working faster. She lists eleven unused applications that could be removed.
6.4 Limits of the model
Real closures are lumpy: patch days close many at once and difficult systems linger. Lindiwe compares the smooth model with synthetic weekly data and sees large deviations around monthly patch releases. Prof. Hale explains that models guide thinking but must be checked against observations, and that an engineer should state assumptions next to any projection. She adds a sentence to her report noting that the model ignores systems that cannot be patched without vendor support. She shows the deviations in a chart for her report.
Worked example
Lindiwe models vulnerability closure as exponential decay, computes a four-week half-life, derives a steady-state backlog near four hundred and notes the model's limits.
Synthetic case. Rates are synthetic.
Errors and limits
A single average closure rate hides slow handling of critical findings.
Exercises
- EX016 — Half-life. What is the half-life at fifteen percent weekly closure? Rubric: 3 = a little over four weeks;; 2 = close;; 1 = wrong;; 0 = none.
- EX017 — Steady state. What is the steady-state backlog formula? Rubric: 3 = inflow divided by closure rate;; 2 = partly correct;; 1 = vague;; 0 = none.
- EX018 — Reduce inflow. How can inflow be reduced? Rubric: 3 = remove unused software;; 2 = partly correct;; 1 = vague;; 0 = none.
Continue studying — lesson 06 (chapter 06 of 50)
← Chapter 05 · Course chapter index · Chapter 07 →
Continue to the next authored lesson.