◇ OpenCyber Academy
Engineering · Chapter 24 · English

Chapter 24 — Network and communications security: methods I

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 24 — Network and communications security: methods I

Lesson map

Lesson 24 published. Map, example, EX070.

flowchart TD
  N0["Learning outcomes"]
  N1["24.1 From flows to rules"]
  N2["24.2 Rule ordering"]
  N3["24.3 Naming and documentation"]
  N4["24.4 Review method"]
  N5["Grouping services"]
  N6["Testing rules before deployment"]
  N7["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX070"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["24.1 From flows to rules"]
  N2["24.2 Rule ordering"]
  N3["24.3 Naming and documentation"]
  N4["24.4 Review method"]
  N5["Grouping services"]
  N6["Testing rules before deployment"]
  N7["Synthesis"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX070"]

[Learning outcomes]
    |
    v
[24.1 From flows to rules]
    |
    v
[24.2 Rule ordering]
    |
    v
[24.3 Naming and documentation]
    |
    v
[24.4 Review method]
    |
    v
[Grouping services]
    |
    v
[Testing rules before deployment]
    |
    v
[Synthesis]
    |
    v
[Worked example] --> [Exercise EX070]

Learning outcomes

You will (1) apply policy design methods; (2) derive rules from needed flows; (3) review rules systematically.

24.1 From flows to rules

Kofi derives rules directly from the needed-flows list: each flow becomes one rule specifying source zone, destination zone or host, service and a reason. The final rule is default deny. This method follows NIST SP 800-41 Rev. 1, which recommends deny-by-default policies built from documented requirements.

Each needed flow in the model becomes one or more allow rules, with a final deny for everything else. Grouping addresses into named objects keeps rules readable and consistent.

Every rule carries a reference back to the flow it implements, so reviewers can check that nothing was added without a documented need and that removed flows lose their rules.

24.2 Rule ordering

In first-match firewalls, order matters. Specific rules come before general ones, and no allow rule may be shadowed by an earlier deny. Kofi checks ordering with a script that compares each rule with earlier ones.

Firewalls usually apply the first matching rule, so order matters. Specific rules go before broad ones, and a broad allow placed early can silently override later denies. Engineers review order deliberately and test that each rule is actually reached.

Analysis tools or simple scripts can detect shadowed rules, which are never reached because an earlier rule matches every packet they would match, and such rules should be removed or reordered.

24.3 Naming and documentation

Each rule has an identifier, owner and reason, matching the needed-flows list. Rules without owners are a common source of later confusion.

Every rule and object gets a meaningful name following a convention, such as zone, destination and service. Each rule records its purpose, the requirement or flow it serves, its owner, and a review date. Documentation lives with the configuration in version control, so it changes together with the rules. A rule whose purpose nobody can explain is a candidate for removal at the next review.

24.4 Review method

Before deployment, a second engineer reviews each rule against the flows list using the checklist from chapter 14.

Rule review follows a fixed method so nothing is skipped. The reviewer compares rules against the flow model, looking for missing needed flows, rules allowing more than needed, duplicates, rules shadowed by earlier ones, and rules with no recent hits. Each finding is recorded with a proposed action. Repeating the review on a schedule, and after major changes, keeps the rule set from slowly accumulating exceptions.

Grouping services

Rules often refer to groups of services or hosts, such as all file-sharing ports or all branch recorders. Groups make policies shorter and easier to review, but a group that is too broad can quietly permit more than intended. Kofi defines groups from the needed-flows list, names them clearly and reviews their membership as carefully as the rules. A change to a group's membership affects every rule using it, so group changes go through the same review as rule changes.

Testing rules before deployment

For each rule, Kofi writes at least one test flow that should be allowed and one similar flow that should be denied, such as the same source and destination on a different port. Passing both shows the rule is neither too narrow nor too broad. These tests run against the policy in the lab and are kept for regression testing, so later changes that accidentally widen a rule are caught. The approach mirrors unit testing in software, applied to network policy.

Worked example

Twelve needed flows produce twelve allow rules plus default deny; review finds one rule broader than its flow and narrows it.

Synthetic case. Rules are synthetic.

Errors and limits

Copying old rules into a new design imports old mistakes; derive rules from needs instead.

Exercises

Synthesis

Rules derived from documented needs, ordered carefully and reviewed, form a clean policy.

Continue studying — chapter 24 of 50

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