Chapter 41 — Network and communications security: system optimization
Lesson map
Lesson 41 published. Map, example, EX121.
flowchart TD
N0["Learning outcomes"]
N1["41.1 Policy optimisation"]
N2["41.2 Logging optimisation"]
N3["41.3 Alert optimisation"]
N4["41.4 Cost"]
N5["Optimising for people as well as machines"]
N6["Guarding against over-optimisation"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX121"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["41.1 Policy optimisation"]
N2["41.2 Logging optimisation"]
N3["41.3 Alert optimisation"]
N4["41.4 Cost"]
N5["Optimising for people as well as machines"]
N6["Guarding against over-optimisation"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX121"]
[Learning outcomes]
|
v
[41.1 Policy optimisation]
|
v
[41.2 Logging optimisation]
|
v
[41.3 Alert optimisation]
|
v
[41.4 Cost]
|
v
[Optimising for people as well as machines]
|
v
[Guarding against over-optimisation]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX121]
Learning outcomes
You will (1) identify inefficiencies; (2) optimise policy and logging; (3) balance cost and coverage.
41.1 Policy optimisation
Once the network is stable, Kofi looks for waste. Rule usage data show three rules unused for ninety days and two address groups containing devices that no longer exist. He asks each rule owner to confirm the rules are no longer needed, then removes them through the normal change process, cutting the policy by about eight percent. Because removing a rule can break a rarely used flow, the regression suite is run before and after, and it confirms behaviour is unchanged. A smaller policy is easier to review and less likely to hide mistakes.
41.2 Logging optimisation
Full logging of every allowed connection on busy links produces far more data than the team ever analyses, and storage costs money. Kofi switches allowed traffic to periodic flow summaries, which record source, destination, service and volume, while keeping full records for every deny and every management connection. Storage falls by about forty percent. Before making the change, he lists the questions past investigations needed to answer and checks that all of them can still be answered from summaries. Optimisation is accepted only if no needed evidence is lost.
41.3 Alert optimisation
The deny-spike alert was set conservatively at launch and fired eleven times in its first month, mostly because of guest devices repeatedly trying to reach printers or file shares they had remembered from other networks. These alerts were real but rarely important. Kofi groups denies by source device before counting and sets a higher threshold for the guest zone than for staff or servers. Alerts drop to three a month, all of which warranted a look. Fewer, more meaningful alerts mean engineers take each one seriously rather than dismissing them.
41.4 Cost
Optimisation has a direct financial effect. The council had planned to buy additional log storage during the year because of growth projected from the launch configuration. After the logging change, current storage covers the required ninety days with room to spare, and the purchase is cancelled. Kofi records the saving and its cause in the project report, so managers can see that operational care pays off. He also notes the time engineers save on alert handling, since staff time is usually the council's largest and most constrained cost.
Optimising for people as well as machines
Optimisation is not only about storage and rules. Kofi also measures how long routine tasks take the engineers. The weekly deny review originally took about ninety minutes because the report listed every deny individually. Grouping denies by zone pair and showing only changes from the previous week cuts the review to about twenty-five minutes while still surfacing the cases that need investigation. Time saved on routine work is time available for improvement and for responding properly to real alerts. He records the before and after times so the council can see the benefit, and so later changes to the report can be judged against them.
Guarding against over-optimisation
Every optimisation removes something, whether rules, log detail or alerts, and each removal could hide a future problem. Kofi applies three safeguards. First, he checks each change against known investigation and audit needs before making it. Second, he keeps changes reversible: log summarisation can be switched back to full detail for a zone during an incident. Third, he records the reason for each optimisation, so a reviewer can revisit it if conditions change, for example if the council later faces a new regulatory retention requirement. These safeguards keep efficiency gains from turning into blind spots that only appear when an incident needs the missing data.
Worked example
After optimisation, regression tests pass and investigation queries still return complete results for the test period.
Synthetic case. Figures are synthetic.
Errors and limits
Optimising logs can remove evidence needed later; check investigation needs first.
Exercises
- EX121 — Rule removal check. How is behaviour confirmed unchanged after removing rules? Rubric: 3 = regression suite;; 2 = tests;; 1 = vague;; 0 = none.
- EX122 — Logging change. What logging change saved storage? Rubric: 3 = summaries for allows, full for denies;; 2 = summaries;; 1 = vague;; 0 = none.
- EX123 — Alert tuning. How was the deny-spike alert improved? Rubric: 3 = grouping by source and zone-specific threshold;; 2 = threshold;; 1 = vague;; 0 = none.
Synthesis
Optimisation keeps the design lean without reducing protection or visibility.
Continue studying — chapter 41 of 50
← Chapter 40 (draft) · Course chapter index · Chapter 42 (draft) →