Chapter 22 — Web3, blockchain and cryptoasset security: automation

Lesson map

Lesson 22 published. Map, example, EX064.

flowchart TD
  N0["Learning outcomes"]
  N1["22.1 Automating routine checks"]
  N2["Lab — Configuration drift check"]
  N3["22.2 Reading drift and keeping humans in charge"]
  N4["22.3 Follow-up and lessons"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Worked example"]
  EX --> Q["Exercise EX064"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["22.1 Automating routine checks"]
  N2["Lab — Configuration drift check"]
  N3["22.2 Reading drift and keeping humans in charge"]
  N4["22.3 Follow-up and lessons"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX064"]

[Learning outcomes]
    |
    v
[22.1 Automating routine checks]
    |
    v
[Lab — Configuration drift check]
    |
    v
[22.2 Reading drift and keeping humans in charge]
    |
    v
[22.3 Follow-up and lessons]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX064]

Learning outcomes

You will (1) automate routine checks safely; (2) detect configuration drift; (3) keep humans in decisions.

22.1 Automating routine checks

Lucas automates the checks he has been running by hand: node synchronisation, privileged event matching, grant reconciliation and configuration comparison. Each runs on a schedule, writes results to a dated log and sends a summary email each morning. Automation makes checks consistent and frees time for investigation. He keeps every automated check read-only and reviews the code with a classmate before deploying it. Ms Adebayo warns that automation can hide problems if no one reads the output, so each summary names a person responsible for reading it that day.

Lab — Configuration drift check

"""Compare node configurations with an approved baseline (synthetic, read-only)."""
BASELINE = {"client": "2.4.1", "rpc_public": False, "peers": "allowlist", "log_days": 90, "ntp": True}
NODES = {
    "node-a": {"client": "2.4.1", "rpc_public": False, "peers": "allowlist", "log_days": 90, "ntp": True},
    "node-b": {"client": "2.4.0", "rpc_public": False, "peers": "allowlist", "log_days": 90, "ntp": True},
    "node-c": {"client": "2.4.1", "rpc_public": True, "peers": "allowlist", "log_days": 30, "ntp": True},
}

def main():
    total = 0
    for node, cfg in NODES.items():
        diffs = [f"{k}={cfg[k]!r} (baseline {v!r})" for k, v in BASELINE.items() if cfg.get(k) != v]
        total += len(diffs)
        print(f"{node}: {'ok' if not diffs else '; '.join(diffs)}")
    print(f"settings checked {len(BASELINE) * len(NODES)}; drift {total}")

if __name__ == "__main__":
    main()

Run with python3 lab_drift.py. Verified output:

node-a: ok
node-b: client='2.4.0' (baseline '2.4.1')
node-c: rpc_public=True (baseline False); log_days=30 (baseline 90)
settings checked 15; drift 3

22.2 Reading drift and keeping humans in charge

The drift lab compares five settings on three nodes, fifteen in total, and finds three differences: node-b runs client 2.4.0 instead of 2.4.1, and node-c has a public programming interface and keeps logs for only 30 days instead of 90. Node-a matches. Lucas treats the public interface as urgent and the others as routine. He does not let the script change settings automatically; a person reviews each difference and applies fixes through the change process. Automation detects; people decide and act, especially when changes affect live nodes.

22.3 Follow-up and lessons

Investigation shows node-c's interface became public after a provider maintenance reset its firewall, and its log setting reverted at the same time. Node-b had missed the last update window. All three are fixed through tickets and the drift check rerun shows no differences. Lucas adds the drift check to run after every provider maintenance notice. He notes that drift is normal in real systems, because updates, resets and manual fixes all change settings, and that only regular comparison with a baseline keeps it under control.

Worked example

The drift lab finds 3 differences in 15 settings: node-b's client version, and node-c's public interface and 30-day logs, traced to a provider reset.

Synthetic case. The node configurations and investigation are synthetic.

Errors and limits

Letting automation change live settings without review can turn a detection into an outage.

Exercises

• EX064 — Settings compared. How many settings does the drift lab compare in total?
  Show marking criteria

  Rubric: 3 = fifteen;; 2 = 15;; 1 = five;; 0 = none.
• EX065 — Urgent drift. Which drift is treated as urgent?
  Show marking criteria

  Rubric: 3 = node-c's public programming interface;; 2 = public interface;; 1 = log days;; 0 = none.
• EX066 — Drift cause. What caused node-c's drift?
  Show marking criteria

  Rubric: 3 = a provider maintenance reset;; 2 = provider reset;; 1 = an attacker;; 0 = none.

Synthesis

Automated drift detection with human decisions keeps node configurations aligned.

Continue studying — chapter 22 of 30

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