Chapter 22 — Network and communications security: data and dependencies

Lesson map

Lesson 22 published. Map, example, EX064.

flowchart TD
  N0["Learning outcomes"]
  N1["22.1 Why central logs"]
  N2["22.2 The syslog format"]
  N3["Lab — Syslog parsing"]
  N4["22.3 Reading the summary"]
  N5["22.4 Time and completeness"]
  N6["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
  N6 --> EX["Worked example"]
  EX --> Q["Exercise EX064"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["22.1 Why central logs"]
  N2["22.2 The syslog format"]
  N3["Lab — Syslog parsing"]
  N4["22.3 Reading the summary"]
  N5["22.4 Time and completeness"]
  N6["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX064"]

[Learning outcomes]
    |
    v
[22.1 Why central logs]
    |
    v
[22.2 The syslog format]
    |
    v
[Lab — Syslog parsing]
    |
    v
[22.3 Reading the summary]
    |
    v
[22.4 Time and completeness]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX064]

Learning outcomes

You will (1) collect logs in a standard format; (2) parse syslog; (3) summarise events by severity.

22.1 Why central logs

Logs record what network devices did: connections allowed and denied, logins, configuration changes and errors. At the clinics, each device keeps its own small log that overwrites itself within days, so evidence disappears before anyone looks. Central logging sends copies to one store where they are kept for the agreed period, searched together and protected from tampering on the devices that produced them. Priya treats central logging as the first detection control, since every later analysis depends on logs existing and being complete.

22.2 The syslog format

Many network devices send logs using syslog. RFC 5424 defines a structured format: a priority value in angle brackets, a version number, a timestamp, the host name, the application name and further fields, then the message. The priority combines facility, which indicates the type of source, and severity, from emergency to debug, as facility times eight plus severity. Standard formats let one parser handle many devices. Priya notes that real devices often deviate slightly from the standard, so parsers must cope with variations.

Lab — Syslog parsing

"""Parse synthetic RFC 5424 syslog lines and count by severity (stdlib only)."""
import re, collections
lines = ["<134>1 2026-03-02T08:00:01Z fw1 filter - - - allow staff->portal",
         "<132>1 2026-03-02T08:00:05Z fw1 filter - - - deny guest->clinical",
         "<132>1 2026-03-02T08:00:06Z fw1 filter - - - deny guest->clinical",
         "<131>1 2026-03-02T08:01:00Z ap3 radius - - - auth failure user n.ortiz",
         "<134>1 2026-03-02T08:02:10Z fw1 filter - - - allow clinical->lab",
         "<130>1 2026-03-02T08:03:00Z fw1 system - - - config changed by admin2",
         "bad line without header",
         "<132>1 2026-03-02T08:04:40Z fw1 filter - - - deny guest->mgmt"]
names = ["emerg", "alert", "crit", "err", "warning", "notice", "info", "debug"]
pat = re.compile(r"^<(\d{1,3})>1 (\S+) (\S+) (\S+)")
count, bad = collections.Counter(), 0
for l in lines:
    m = pat.match(l)
    if not m: bad += 1; continue
    pri = int(m.group(1)); count[names[pri % 8]] += 1
for k in names:
    if count[k]: print(f"{k:8}{count[k]}")
print("parsed", sum(count.values()), "malformed", bad)

Run with python3 lab_syslog.py. Verified output:

crit    1
err     1
warning 3
info    2
parsed 7 malformed 1

22.3 Reading the summary

The parser reads eight synthetic lines and parses seven, reporting one malformed line rather than crashing or silently skipping it. By severity there are three warnings, all denied guest connections towards clinical and management groups; two informational allowed connections; one error for a failed wireless authentication; and one critical event for a configuration change by an administrator. Priya points out that the critical configuration change and the repeated guest denies are the items worth a human look, while the allowed connections are routine.

22.4 Time and completeness

Logs from different devices can only be combined if clocks agree. Priya adds time synchronisation to every device and records times in UTC, converting for display. She also monitors completeness: if a device that normally sends hundreds of lines an hour sends none, either it is quiet or logging has failed. Silent failures are dangerous because they look like calm periods. A simple check comparing each device's hourly count against its usual range catches most of them before an investigation discovers missing evidence.

Worked example

The lab reports three warnings, one error, one critical and two informational events, with one malformed line.

Synthetic case. Log lines and names are synthetic.

Errors and limits

Parsing logs without counting malformed lines hides data loss.

Exercises

• EX064 — Priority arithmetic. Which severity does priority 132 represent, and why?
  Show marking criteria

  Rubric: 3 = warning: 132 mod 8 = 4;; 2 = warning;; 1 = guesses;; 0 = none.
• EX065 — Items to review. Which parsed events deserve human review first?
  Show marking criteria

  Rubric: 3 = critical config change and guest denies;; 2 = config change;; 1 = all;; 0 = none.
• EX066 — Silent logging failure. How can a silent logging failure be detected?
  Show marking criteria

  Rubric: 3 = compare device line counts with usual range;; 2 = monitor volume;; 1 = vague;; 0 = none.

Synthesis

Standard-format central logs with synchronised time and completeness checks make detection possible.

Continue studying — chapter 22 of 40

← Chapter 21 (draft) · Course chapter index · Chapter 23 (draft) →