Chapter 23 — Network and communications security: evaluation | Technologist Network and communications security

Lesson map

Lesson 23 published. Map, example, EX067.

flowchart TD
  N0["Learning outcomes"]
  N1["23.1 Requirements check"]
  N2["23.2 Security indicators"]
  N3["23.3 Support impact"]
  N4["Lab — Resolution times"]
  N5["23.4 Reading the times"]
  N6["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
  N6 --> EX["Worked example"]
  EX --> Q["Exercise EX067"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["23.1 Requirements check"]
  N2["23.2 Security indicators"]
  N3["23.3 Support impact"]
  N4["Lab — Resolution times"]
  N5["23.4 Reading the times"]
  N6["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX067"]

[Learning outcomes]
    |
    v
[23.1 Requirements check]
    |
    v
[23.2 Security indicators]
    |
    v
[23.3 Support impact]
    |
    v
[Lab — Resolution times]
    |
    v
[23.4 Reading the times]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX067]

Learning outcomes

You will (1) evaluate the changes against requirements; (2) measure support impact; (3) report results.

23.1 Requirements check

At the end of the autumn term, Tomás evaluates each requirement. R1 is met: tests and logs show no student or guest connections to administration or management. R2 is met: only listed flows cross zones. R3 is met: management uses SSH and HTTPS only from the management zone, apart from the Telnet slip caught by drift detection. R4 is met for staff wireless. R5 is met: all zones use school resolvers. R6 is met for logs, with ninety days confirmed in December.

23.2 Security indicators

Reachable zone pairs fell from thirty to the fourteen needed flows between zones. Unapproved services fell from four to one restricted exception. Leftover accounts fell from thirty-nine to zero after the termly review. Switches with insecure management fell from two to zero, briefly one when Telnet reappeared. Tomás reports each with before and after values and dates. These indicators show improvement in the risks ranked highest in chapter 5, which is the strongest argument for the project's value. The figures are shared with the governors.

23.3 Support impact

Security changes should not make support worse. Tomás compares network tickets before and after, using the time from report to resolution. He also asks whether runbooks written during the project helped. The synthetic ticket data show resolution times falling, which he attributes partly to clearer zones and logs that make problems easier to diagnose, and partly to the new reporting form. He notes that other factors could contribute, such as fewer new devices in the autumn term. He records these caveats beside the result.

Lab — Resolution times

"""Median time to resolve synthetic network tickets before and after runbooks (stdlib only)."""
import statistics
before = [95, 40, 210, 60, 130, 75, 300, 55, 90, 120]
after = [35, 50, 45, 80, 30, 150, 40, 60, 25, 55]
for n, x in (("before", before), ("after", after)):
    print(f"{n:7} n={len(x)} median {statistics.median(x):.1f} min, max {max(x)} min")
print(f"median change {100*(statistics.median(after)-statistics.median(before))/statistics.median(before):.1f}%")

Run with python3 lab_mttr.py. Verified output:

before  n=10 median 92.5 min, max 300 min
after   n=10 median 47.5 min, max 150 min
median change -48.6%

23.4 Reading the times

The median resolution time falls from 92.5 to 47.5 minutes, a 48.6 percent reduction, and the longest ticket falls from 300 to 150 minutes. With ten tickets in each period, Tomás treats the result as encouraging rather than conclusive and uses medians because a single long ticket would distort the mean. He recommends continuing to record times so that a full year of data can confirm whether the improvement lasts. He also notes that fewer new devices joined in autumn, which could explain part of the change.

Worked example

All six requirements are met; the median ticket resolution time falls by about half.

Synthetic case. Data are synthetic.

Errors and limits

Small samples of tickets can show large changes by chance.

Exercises

EX067 — Reachability change. How did reachable zone pairs change?
Show marking criteria
Rubric: 3 = thirty to fourteen needed flows;; 2 = reduced;; 1 = vague;; 0 = none.
EX068 — Median change. What was the median resolution change?
Show marking criteria
Rubric: 3 = 92.5 to 47.5 minutes, −48.6%;; 2 = about half;; 1 = some;; 0 = none.
EX069 — Median reason. Why use the median for ticket times?
Show marking criteria
Rubric: 3 = one long ticket distorts mean;; 2 = skew;; 1 = easier;; 0 = none.

Synthesis

Evaluation against requirements and support measures shows security improved without harming service.

Continue studying — chapter 23 of 30

← Chapter 22 (draft) · Course chapter index · Chapter 24 (draft) →