OpenCyber Academy
Engineering · Chapter 1 · English
Course code: OCA-133Chapter 01: OCA-133-C001

Chapter 1 — Calculus I

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Permanent link

Public activity · 30d

—Participating browsers

—Page views

—Reading sessions

—Exercise opens

Counts reflect browsers that allowed analytics. A reading session requires 30 seconds on a visible page. Browsers are not people.

Learning outcomes

You will (1) read rates of change in intelligence workloads; (2) interpret a derivative as "how fast is this growing now"; (3) approximate an area under a curve to total a workload; (4) avoid extrapolating a local slope too far.

1.1 Rates in a SOC

Indicators arrive in Lantern at a rate that changes during the day: low overnight, rising when partner communities in other time zones publish. If N(t) is the cumulative count of indicators received by hour t, its derivative N′(t) is the arrival rate. Engineers size parsers and enrichment workers for the peak of N′, not for the daily average, because queues form when instantaneous arrival exceeds service.

A feed that delivers most of its daily volume in two morning hours needs workers sized for those hours, even though the average looks gentle. Kofi plots the rate rather than the running total when he checks this, because a cumulative curve hides bursts inside its steady climb.

1.2 Slopes from data

Real data are discrete. A difference quotient — (N(t+1) − N(t)) / 1 hour — estimates the rate. Smoothing over several hours reduces noise but hides short bursts; the choice depends on whether you are planning capacity (use peaks) or reporting trends (smooth).

Kofi keeps two views of the same counts for that reason. The raw hourly differences go to the capacity review, where a single busy hour matters. A six-hour moving average goes into the monthly report, where readers want to know whether partner volume is growing. Each chart says which one it is. Missing hours are left as gaps rather than filled, because an invented value would distort both the peak and the trend.

1.3 Areas as totals

If r(t) is the rate of analyst-hours needed to triage alerts, the integral of r over a shift is the total effort. A trapezoid sum over hourly samples is accurate enough for staffing.

With samples every hour, the trapezoid rule averages each pair of neighbouring rates and multiplies by one hour. Summing those slices across an eight-hour shift gives the analyst-hours the shift must cover. If the result is eleven hours of work and three analysts are on shift, the plan has slack; if it is thirty, the team needs help or a narrower triage scope. The estimate is only as good as the samples, so a missing hour is marked, not guessed.

1.4 Limits of local slopes

A burst during a major campaign may show a steep slope. Projecting that slope a month ahead predicts absurd volumes. Derivatives describe now; models of cause are needed for forecasts.

Kofi saw this when a partner published a large backlog of old indicators in one afternoon. The hourly rate jumped tenfold, then fell back the next day. Had he sized Lantern from that afternoon's slope, BEN would have bought hardware for a load that never returned. A forecast needs an explanation of why volume changes, such as a new partner joining, and the slope only tells him that something changed.

Practice note — Units and dashboards

Lantern's dashboard once plotted the cumulative total where operators expected a rate, and the night shift read a calm flat line as a sudden spike when the axis rescaled. Kofi now labels every chart either 'per hour' or 'cumulative since 00:00 UTC', and the capacity review uses only rate charts.

Worked example

Kofi samples Lantern's cumulative indicator count at 08:00 (12,400), 09:00 (12,700) and 10:00 (13,300). The rate rose from 300 to 600 per hour. He sizes the parser for at least 600 per hour plus headroom, and notes that the jump coincided with a partner's morning bulletin — a scheduled, not structural, increase.

Synthetic case. Lantern's counts are invented for this chapter.

Errors and limits

Confusing the cumulative count with the rate leads to absurd capacity plans. Calculus here measures workloads; it does not predict adversaries.

Exercises

  • EX001 — Hourly rate. Using Kofi's samples, compute the arrival rate between 09:00 and 10:00.
    Show marking criteria
    Rubric: 3 = 600 per hour with method; 2 = number only; 1 = uses cumulative; 0 = none.
  • EX002 — Peak or mean. Explain why parser capacity is sized for peak rate rather than daily mean.
    Show marking criteria
    Rubric: 3 = queues form when arrival exceeds service; mean hides bursts; 2 = partial; 1 = mean is fine; 0 = none.
  • EX003 — Trapezoid total. Analyst-hours needed are 2, 4 and 6 per hour at three consecutive hourly samples. Estimate total effort over those two hours.
    Show marking criteria
    Rubric: 3 = 8 analyst-hours via trapezoids; 2 = method right; 1 = sums to 12; 0 = none.

Synthesis

Rates size systems, areas total effort, and local slopes must not be stretched into forecasts.

Continue studying — chapter 01 of 50

← Course home · Course chapter index · Chapter 02 (draft) →

Practice the exercises

Open a prompt, write your response, then compare it with the worked answer. Five-choice practice appears where a reviewed question is available.

EX001

Opens in 30 days: — · browsers: —

Checking for a reviewed five-choice question…

EX002

Opens in 30 days: — · browsers: —

Checking for a reviewed five-choice question…

EX003

Opens in 30 days: — · browsers: —

Checking for a reviewed five-choice question…

Worked answers

EX001. (13,300 − 12,700) / 1 h = 600 indicators per hour.

EX002. Work queues build whenever arrivals exceed service; a daily mean averages away the bursts that actually overload the parser.

EX003. Trapezoids: (2+4)/2 + (4+6)/2 = 3 + 5 = 8 analyst-hours.