Chapter 3 — Network and communications security: specialist evidence
Lesson map
Lesson 03 published. Map, example, EX011.
flowchart TD
N0["Learning outcomes"]
N1["3.1 What evidence is needed"]
N2["Lab — VPN peer summary"]
N3["3.2 Reading the summary"]
N4["3.3 Evidence quality"]
N5["3.4 Handling secrets in evidence"]
N6["3.5 From evidence to priorities"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX011"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["3.1 What evidence is needed"]
N2["Lab — VPN peer summary"]
N3["3.2 Reading the summary"]
N4["3.3 Evidence quality"]
N5["3.4 Handling secrets in evidence"]
N6["3.5 From evidence to priorities"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX011"]
[Learning outcomes]
|
v
[3.1 What evidence is needed]
|
v
[Lab — VPN peer summary]
|
v
[3.2 Reading the summary]
|
v
[3.3 Evidence quality]
|
v
[3.4 Handling secrets in evidence]
|
v
[3.5 From evidence to priorities]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX011]
Learning outcomes
You will (1) collect specialist evidence on VPN configuration; (2) interpret results; (3) judge evidence quality.
3.1 What evidence is needed
Before recommending VPN changes, Marta needs evidence about the current state: IKE version, authentication method and key age for every peer. Configuration exports from the routers provide this, and the operations team supplies sanitised copies with addresses and secrets removed. She also records which peers carry customer traffic and which carry only management traffic, since that affects priority. Evidence must be complete for the decision, so she checks the peer list against the provider's network diagram and asks about any peer configured on one side only.
Lab — VPN peer summary
"""Summarise synthetic VPN peer settings: auth method, IKE version and key age (stdlib only)."""
peers = [("depot-north", "IKEv2", "cert", 0), ("depot-south", "IKEv1", "psk", 1460), ("pop-hill", "IKEv2", "psk", 900),
("pop-river", "IKEv2", "cert", 0), ("partner-isp", "IKEv1", "psk", 2190), ("pop-mill", "IKEv2", "cert", 0),
("noc-backup", "IKEv2", "psk", 400), ("pop-ridge", "IKEv1", "psk", 1825)]
flag = []
for name, ike, auth, age in peers:
issues = [x for x, c in (("IKEv1", ike == "IKEv1"), ("psk", auth == "psk"), ("psk>365d", auth == "psk" and age > 365)) if c]
if issues: flag.append(name)
print(f"{name:12}{ike:6}{auth:5}{age:>5}d {','.join(issues) or 'ok'}")
print(f"needs action: {len(flag)} of {len(peers)}; IKEv1: {sum(p[1]=='IKEv1' for p in peers)}; psk: {sum(p[2]=='psk' for p in peers)}")
Run with python3 lab_peers.py. Verified output:
depot-north IKEv2 cert 0d ok
depot-south IKEv1 psk 1460d IKEv1,psk,psk>365d
pop-hill IKEv2 psk 900d psk,psk>365d
pop-river IKEv2 cert 0d ok
partner-isp IKEv1 psk 2190d IKEv1,psk,psk>365d
pop-mill IKEv2 cert 0d ok
noc-backup IKEv2 psk 400d psk,psk>365d
pop-ridge IKEv1 psk 1825d IKEv1,psk,psk>365d
needs action: 5 of 8; IKEv1: 3; psk: 5
3.2 Reading the summary
The synthetic summary shows eight peers. Three use IKEv1 and five use pre-shared keys, all of which are more than a year old; the oldest, with the partner provider, is six years old. Three peers already use IKEv2 with certificates. Five of eight need action. The partner link stands out: it uses IKEv1, a six-year-old key and carries traffic for another organisation, so changing it requires coordination. Marta separates the peers into those the provider controls alone, which can move quickly, and the partner link, which needs a joint plan.
3.3 Evidence quality
Configuration exports show what is configured, not what is negotiated. A peer might be configured for IKEv2 but fall back to IKEv1 if the other end requires it. Marta asks the team to confirm, from router status output, the version actually negotiated for each tunnel. She also checks key ages against change records rather than relying on memory. Evidence quality improves when two independent sources agree; where they disagree, the disagreement itself is a finding, since it means the network may not behave as documented.
3.4 Handling secrets in evidence
Configuration exports can contain keys and passwords. Marta's agreement with the provider forbids receiving any secret, so exports are sanitised by the operations team before she sees them, using a script that replaces key values with placeholders. She checks each file for anything missed before analysis. If she ever received a secret, the agreement requires her to report it and the provider to change it. Evidence handling is part of specialist competence: careless handling could create the very exposure the project aims to reduce.
3.5 From evidence to priorities
With confirmed evidence, Marta ranks the peers. Peers carrying customer traffic with old pre-shared keys come first, then management-only peers, then the partner link, which is important but slower to change. She estimates effort for each, using the three already-migrated peers as a guide to time per migration. Linking evidence directly to an ordered plan makes the analysis useful; a list of weaknesses without priorities leaves the operations team unsure where to begin and tempted to start with the easiest rather than the most important.
Worked example
Five of eight peers need action; three IKEv1 peers and five pre-shared keys are confirmed by negotiated status as well as configuration.
Synthetic case. Peer data are synthetic.
Errors and limits
Trusting configuration alone misses fallback behaviour visible only in negotiated status.
Exercises
- EX011 — Peers needing action. How many peers need action and why? Rubric: 3 = five, all with old pre-shared keys, three also IKEv1;; 2 = five;; 1 = three;; 0 = none.
- EX012 — Configured versus negotiated. Why check negotiated status as well as configuration? Rubric: 3 = fallback may differ from configuration;; 2 = differences;; 1 = duplicate;; 0 = none.
- EX013 — Partner link complexity. Why does the partner link take longer to change? Rubric: 3 = needs joint coordination with another organisation;; 2 = coordination;; 1 = technical;; 0 = none.
- EX014 — Secret received. What must happen if a secret appears in evidence? Rubric: 3 = report it and provider changes it;; 2 = report;; 1 = delete quietly;; 0 = none.
- EX015 — Two-source agreement. What does disagreement between two evidence sources indicate? Rubric: 3 = network may not behave as documented; a finding;; 2 = problem;; 1 = error in one;; 0 = none.
Synthesis
Specialist evidence must be complete, cross-checked, safely handled and turned into priorities.
Continue studying — chapter 03 of 12
← Chapter 02 (draft) · Course chapter index · Chapter 04 (draft) →