Chapter 27 — Network and communications security: verification | Bachelor's Network and communications security

Open, free learning for anyone who wants to protect people and technology. No account is required to read this text or its worked answers.

Chapter 27 — Network and communications security: verification

Lesson map

Lesson 27 published. Map, example, EX079.

flowchart TD
  N0["Learning outcomes"]
  N1["27.1 Verification versus testing"]
  N2["27.2 DNS checks"]
  N3["27.3 Configuration drift"]
  N4["27.4 Independent checking"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Worked example"]
  EX --> Q["Exercise EX079"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["27.1 Verification versus testing"]
  N2["27.2 DNS checks"]
  N3["27.3 Configuration drift"]
  N4["27.4 Independent checking"]
  N5["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX079"]

[Learning outcomes]
    |
    v
[27.1 Verification versus testing]
    |
    v
[27.2 DNS checks]
    |
    v
[27.3 Configuration drift]
    |
    v
[27.4 Independent checking]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX079]

Learning outcomes

You will (1) verify configuration against design; (2) review DNS and name resolution; (3) detect drift.

27.1 Verification versus testing

Testing checks behaviour by sending traffic; verification also checks that the configuration matches the approved design. Priya compares the firewall rules exported from the lab with the needed-flows list, rule by rule, and lists differences. Some differences are errors, others are flows missing from the list. Both kinds are resolved before deployment. Verification catches problems tests miss, such as a rule allowing traffic nobody tested because nobody knew it was there. She records each difference, its cause and its resolution in a verification log, which becomes evidence that the deployed configuration was checked against the design.

27.2 DNS checks

Name resolution is a quiet but important dependency. Priya verifies that each group uses the intended DNS server, that the clinic's internal names resolve only internally, and that external queries go through the provider's resolver rather than directly to arbitrary servers. NIST SP 800-81-2 offers guidance on secure DNS deployment. Controlling DNS supports security in two ways: it prevents some malware from using its own resolvers, and DNS logs show which names devices look up, which can reveal infections early.

A clinic device that suddenly queries an unfamiliar external resolver is therefore worth investigating, because the bypass itself is a signal.

27.3 Configuration drift

After deployment, configurations change through emergency fixes, upgrades and forgotten tweaks. Drift is the gap between the approved configuration and the running one. Priya plans a monthly comparison: export the running configuration, compare it with the stored approved version and list differences. Each difference is either approved through the normal change process or reverted. A simple script comparing the two files is enough for a small organisation and much better than discovering drift during an incident. Approved configurations are stored with version history so changes can be traced.

27.4 Independent checking

The person who wrote a configuration often reads what they meant rather than what they wrote. Priya asks a classmate to verify her lab configuration against the design without help. The classmate finds an object named for the clinical subnet that actually contains the guest range, an error Priya had read past several times. Independent checks are cheap and effective, and small organisations can arrange them with a partner organisation or a supplier under agreement. She thanks the classmate in her report and records the error as evidence of the check's value.

Worked example

Verification finds three differences: one error, one missing flow and one unused rule.

Synthetic case. Configurations are synthetic.

Errors and limits

Verifying only by reading one's own configuration misses errors the author expects not to see.

Exercises

EX079 — Untested rule. What kind of problem does configuration verification catch that testing misses? Rubric: 3 = rules nobody knew existed so never tested;; 2 = hidden rules;; 1 = vague;; 0 = none.
EX080 — DNS control value. Give two security benefits of controlling DNS. Rubric: 3 = block malware resolvers; logs reveal infections;; 2 = two;; 1 = one;; 0 = none.
EX081 — Drift handling. What happens to each difference found in a drift check? Rubric: 3 = approved via change process or reverted;; 2 = fix;; 1 = ignore;; 0 = none.

Synthesis

Comparing configuration to design, checking DNS and monitoring drift keep the deployed network faithful to its design.

Continue studying — chapter 27 of 40

← Chapter 26 (draft) · Course chapter index · Chapter 28 (draft) →