◇ OpenCyber Academy
Engineering · Chapter 31 · English

Chapter 31 — Security operations and blue team: implementation II

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 31 — Security operations and blue team: implementation II

Lesson map

Lesson 31 published. Map, example, EX091.

flowchart TD
  N0["Learning outcomes"]
  N1["31.1 From studio to production"]
  N2["31.2 Asset enrichment"]
  N3["31.3 Phased rollout"]
  N4["31.4 Pilot findings"]
  N5["31.5 Coordination"]
  N6["31.6 Monitoring the rollout"]
  N7["31.7 Closure"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX091"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["31.1 From studio to production"]
  N2["31.2 Asset enrichment"]
  N3["31.3 Phased rollout"]
  N4["31.4 Pilot findings"]
  N5["31.5 Coordination"]
  N6["31.6 Monitoring the rollout"]
  N7["31.7 Closure"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX091"]

[Learning outcomes]
    |
    v
[31.1 From studio to production]
    |
    v
[31.2 Asset enrichment]
    |
    v
[31.3 Phased rollout]
    |
    v
[31.4 Pilot findings]
    |
    v
[31.5 Coordination]
    |
    v
[31.6 Monitoring the rollout]
    |
    v
[31.7 Closure]
    |
    v
[Worked example] --> [Exercise EX091]

Learning outcomes

You will (1) implement depot network monitoring from the studio design; (2) integrate firewall logs and allow-list policy; (3) implement enrichment for depot assets; (4) manage rollout across many sites.

31.1 From studio to production

The depot design from chapter 25 now becomes real: restrict depot-to-business traffic to five services, log denials, and alert on repeated attempts to new destinations.

Five services cover what depots legitimately need from business systems, such as delivery updates and stock queries. Everything else is denied and logged. Alerting on repeated attempts to new destinations filters out one-off mistakes while catching a device persistently trying to reach systems it should not, which is the behaviour the design was meant to reveal.

31.2 Asset enrichment

Detection needs to know which addresses are depots. Amara works with IT to add depot subnets and device types to the asset inventory, then to the enrichment tables.

Without enrichment, a denial log shows only an address, and an analyst must look up which depot and device it belongs to. With depot subnets and device types in the inventory, alerts arrive showing 'handheld scanner, Depot 14' immediately. The inventory work also helps IT operations, who had no complete list of depot devices before.

31.3 Phased rollout

Forty depots cannot change at once. Three pilot depots go first; issues found there are fixed before the rest follow in groups of ten.

Three pilot depots are chosen to cover different sizes and equipment, so problems that affect only some depot types are likely to appear. Groups of ten after that keep the number of depots affected by any new problem manageable. Each group starts only after the previous one has run cleanly for a set period. Lessons are written up after each group.

31.4 Pilot findings

In the pilot, a label printer at one depot needs to reach a print server not on the allowed list. The firewall denies it, printing stops and the depot calls IT. The team adds the print service, documents why, and checks other depots for the same printers before the next group.

The printer problem shows why the allowed list needs input from people who know depot operations, not just network diagrams. Checking other depots before the next group prevents the same outage elsewhere. Documenting why the print service was added keeps the allowed list understandable, so future reviewers do not remove it as an unexplained exception.

31.5 Coordination

Depot managers get a notice before changes, a contact number and a rollback promise.

Depot managers run busy sites where an unexplained outage can delay deliveries. A notice in advance lets them plan around the change; a contact number gives them someone to call; a rollback promise reassures them that a problem will be reversed quickly rather than debated. Good coordination makes later rollouts easier because trust has been built. Afterwards, managers are asked how the change went. Their answers shape the next notice.

31.6 Monitoring the rollout

A dashboard shows denials per depot per hour; a spike after a change signals a missed legitimate service.

Before a change, denials at a depot are near zero because traffic was not restricted. A sharp rise immediately after the change usually means a legitimate service was missed, as with the printer. Watching the dashboard during each rollout window lets the team react within minutes rather than waiting for complaints from depot staff. A spike outside a rollout window is treated as a possible security event instead.

31.7 Closure

After all depots, the team reviews denial rates and alert volume against the design estimates.

Comparing actual results with estimates checks whether the design assumptions held. If denials are far higher than expected, the allowed list may still be missing services; if alerts are far higher, thresholds may need tuning. The review is written up and linked to the design document, closing the loop from studio to operation. Paolo reads it before the project is closed, and the final figures become the baseline for routine monitoring of depot traffic from then on.

Documenting exceptions

Every allowed service has an owner and a reason in the policy file.

Worked example

After rollout, depot denials average 40 per day across all sites, mostly devices retrying an old update server. The new-destination alert fires twice in the first week; both are a contractor's laptop connected to a depot network. The second leads IT to enforce network access control for visiting devices.

Synthetic case. Depots, devices and counts are invented.

Errors and limits

Restricting traffic can break unknown dependencies; pilots reduce but do not remove that risk.

Exercises

Synthesis

Implement site-wide changes with enrichment, pilots, coordination and monitoring of side effects.

Continue studying — chapter 31 of 50

← Chapter 30 (draft) · Course chapter index · Chapter 32 (draft) →