Chapter 26 — Measuring the starting point | Technologist Systems, endpoints and hardware security

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 26 — Measuring the starting point

Lesson map

Lesson 26 published. Map, example, EX076.

flowchart TD
  N0["Learning outcomes"]
  N1["26.1 Collection"]
  N2["26.2 Method notes"]
  N3["26.3 Presenting"]
  N4["26.4 Unknowns"]
  N5["Checking the scripts against reality"]
  N6["Interpreting and sharing the baseline"]
  N7["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX076"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["26.1 Collection"]
  N2["26.2 Method notes"]
  N3["26.3 Presenting"]
  N4["26.4 Unknowns"]
  N5["Checking the scripts against reality"]
  N6["Interpreting and sharing the baseline"]
  N7["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX076"]

[Learning outcomes]
    |
    v
[26.1 Collection]
    |
    v
[26.2 Method notes]
    |
    v
[26.3 Presenting]
    |
    v
[26.4 Unknowns]
    |
    v
[Checking the scripts against reality]
    |
    v
[Interpreting and sharing the baseline]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX076]

Learning outcomes

You will (1) collect baseline data; (2) record method; (3) present results.

26.1 Collection

Using the scripts, Tomás records the starting values in one week: four stale accounts, two of four servers SSH-compliant, 31 of 94 laptops baseline-compliant, 87 of 94 fully encrypted and four of six servers with backups on time.

Collecting everything in one week keeps the five numbers comparable, since they describe the trust at the same point in time. The values match the earlier labs and checks: four stale accounts from the export, two compliant servers from the SSH script, 87 laptops fully encrypted and mis01 and print01 late on backups.

26.2 Method notes

For each measure, he writes the source, date and script used, so the measurement can be repeated exactly at the end.

The notes also record any manual step, such as the date range chosen for an export or which console page was used, because small differences in method can change a count. With these notes, Dev or another student could repeat the measurement at the end of term and get comparable numbers. Tomás keeps the notes beside the scripts so they are not separated.

26.3 Presenting

He shows Dev a one-page table and a short explanation of each gap.

The table has one row per measure with the count, the total, the date and a one-sentence explanation of the gap. Tomás keeps it to one page so Dev can share it with the business manager without editing. He presents it as facts about systems, not about anyone's work, and asks Dev to correct anything he has misread before it goes further. Encryption at 87 of 94 and laptop settings at 31 of 94 appear side by side, which makes the uneven picture obvious at a glance.

26.4 Unknowns

Laptops offline during the week are counted separately rather than assumed compliant.

Five laptops were offline during the measuring week, and each is listed by name as unknown. Counting them as compliant would have raised the result, while counting them as failing would have lowered it; neither would have been true. They are checked when they reconnect, and the method notes record when each one was finally measured and what it showed. The same rule applies at the end of term, so unknowns cannot quietly improve the final numbers either.

Checking the scripts against reality

Before relying on the scripts, Tomás checks a few results by hand. He confirms one stale account in the directory console, opens the SSH configuration on one server and checks encryption on two laptops. All match the script output, which gives confidence in the rest, and he records the spot checks in his method notes so his instructor can see the measurements were validated. The whole baseline takes about six hours of his time and one hour of Dev's, a cost he records because it shows the measurement can be repeated cheaply every term.

Interpreting and sharing the baseline

The baseline shows uneven strengths. Encryption is already good at 87 of 94 laptops, while laptop settings are weak at 31 of 94. This shapes the plan: encryption needs a handful of fixes, while the laptop baseline needs a proper pilot and rollout, and seeing it early stops Tomás spending equal time on every area. The table is shared with the business manager with a note that the numbers are a starting point, not a judgement on Dev's work. That framing matters: a single technician covering two schools has had little time for checks, and blame would make him less willing to share problems.

Worked example

Five laptops were offline; the baseline table lists them as unknown.

Synthetic case. Figures are synthetic.

Errors and limits

Counting unknowns as compliant flatters the result.

Exercises

EX076 — Repeatability. Why record the script and date for each measure? Rubric: 3 = exact repeat later;; 2 = repeat;; 1 = vague;; 0 = none.
EX077 — Unknown handling. How should offline laptops be counted? Rubric: 3 = separately as unknown;; 2 = excluded;; 1 = compliant;; 0 = none.
EX078 — Presentation. What makes a baseline table useful to managers? Rubric: 3 = counts with totals and plain notes;; 2 = counts;; 1 = vague;; 0 = none.

Synthesis

A careful, documented baseline makes later comparison fair.

Continue studying — chapter 26 of 30

← Chapter 25 (draft) · Course chapter index · Chapter 27 (draft) →