Chapter 18 — Security architecture | Engineering Security operations and blue team

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 18 — Security architecture

Lesson map

Lesson 18 published. Map, example, EX052.

flowchart TD
  N0["Learning outcomes"]
  N1["18.1 What architecture means"]
  N2["18.2 Zones and boundaries"]
  N3["18.3 Sensor placement"]
  N4["18.4 Protecting the SOC"]
  N5["18.5 Mapping to threats"]
  N6["18.6 Simplicity"]
  N7["18.7 Case"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX052"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["18.1 What architecture means"]
  N2["18.2 Zones and boundaries"]
  N3["18.3 Sensor placement"]
  N4["18.4 Protecting the SOC"]
  N5["18.5 Mapping to threats"]
  N6["18.6 Simplicity"]
  N7["18.7 Case"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX052"]

[Learning outcomes]
    |
    v
[18.1 What architecture means]
    |
    v
[18.2 Zones and boundaries]
    |
    v
[18.3 Sensor placement]
    |
    v
[18.4 Protecting the SOC]
    |
    v
[18.5 Mapping to threats]
    |
    v
[18.6 Simplicity]
    |
    v
[18.7 Case]
    |
    v
[Worked example] --> [Exercise EX052]

Learning outcomes

You will (1) describe security architecture as structured placement of controls; (2) design network zones and trust boundaries; (3) place sensors where they see the most relevant activity; (4) evaluate architecture against threats.

18.1 What architecture means

Security architecture decides where controls sit and how components trust each other. It is the structure that makes individual controls work together rather than a pile of products.

Products bought separately may overlap in some areas and leave gaps in others. Architecture starts from the systems and data to protect, decides which controls each needs, and then chooses products to fill those roles. It also defines how the parts trust one another, such as which systems may send logs to the SIEM and how they prove who they are.

18.2 Zones and boundaries

Lindqvist separates the internet-facing portal, internal business systems, the depot networks that run handheld scanners, and the SOC's own systems. Each boundary has rules about what may cross it. Boundaries are where monitoring is most informative, because legitimate traffic across them is limited and known.

Inside a zone, many systems talk freely and traffic is hard to judge. At a boundary, only specific flows should pass: the portal may call the order system on one port, depots may send scan data to one server. Anything else crossing is suspicious by definition, which gives monitoring a clear baseline to compare against.

18.3 Sensor placement

Sensors belong where they see relevant activity with little noise: at the web tier for the portal, at domain controllers for authentication, at the boundary between business and depot networks. Placing one large sensor at the internet edge sees much traffic but little context.

An edge sensor sees every packet from the internet, most of it scanning noise, without knowing which customer account a request concerned. A sensor at the web tier sees the decrypted request and the username. Placing sensors where the meaning is available, rather than where the volume is highest, gives analysts fewer, richer events to work with.

18.4 Protecting the SOC

The SIEM and case system are valuable targets: they show what defenders can see. They sit in their own zone with separate administrator accounts and multi-factor authentication.

An attacker who controls the SIEM can see which alerts exist, learn which actions are being detected, or delete evidence. Separate administrator accounts mean a compromised staff account in the business zone cannot reach SOC systems. The SOC monitors its own systems too, with alerts on configuration changes and on logins from outside the SOC zone.

18.5 Mapping to threats

Architects check each important ATT&CK technique against the architecture: which control prevents it, which sensor would see it, and which team would respond. Gaps become backlog items. D3FEND helps name the defensive technique each control provides.

The exercise produces a table: each technique in a row, with columns for prevention, detection and response owner. Empty cells are gaps. Not every gap needs closing; some techniques are unlikely against Lindqvist, and the risk discussion decides priorities. D3FEND's names, such as credential hardening, make it easier to compare controls across products.

18.6 Simplicity

Complex architectures hide gaps. Fewer, well-understood boundaries are easier to monitor.

Each extra boundary needs its own rules, sensors and maintenance, and exceptions accumulate over time until nobody remembers why a flow is allowed. Merging zones that serve the same purpose can make monitoring clearer. Amara notes that Lindqvist has three slightly different depot network designs, which multiplies the work of defining normal traffic for each. She proposes one standard depot design, rolled out as each site's equipment is replaced, so the baseline only needs defining once.

18.7 Case

Amara reviews where the portal's logs are produced and finds that the load balancer, which sees the true client addresses, was not forwarding its logs; the web servers saw only the balancer's address for some requests.

Because the balancer replaced client addresses with its own for some requests, the web servers' logs showed many attempts from one internal address. Aggregating by network then grouped unrelated customers together and hid the real sources. Forwarding the balancer's logs, and configuring it to pass the original address in a header, fixes both the data and the rule's accuracy.

Worked example

Before that change goes in, Paolo approves it only after checking that the header cannot be trusted from outside: the balancer overwrites any header a client sends, so the recorded address is reliable.

Synthetic case. The architecture and zones are invented.

Errors and limits

Architecture diagrams drift from reality; verify with traffic and configuration, not only drawings.

Exercises

EX052 — Boundary monitoring. Why is monitoring most informative at trust boundaries? Rubric: 3 = legitimate crossing traffic is limited and known; 2 = partial; 1 = vague; 0 = none.
EX053 — Load balancer gap. What gap did Amara find, and how was it closed safely? Rubric: 3 = balancer logs not forwarded; client header added, balancer overwrites client-sent header; 2 = partial; 1 = ignored; 0 = none.
EX054 — SOC protection. How are the SOC's own systems protected? Rubric: 3 = own zone, separate admin accounts, MFA; 2 = two; 1 = one; 0 = none.

Synthesis

Good architecture places controls and sensors at boundaries, protects the SOC itself and is checked against threats.

Continue studying — chapter 18 of 50

← Chapter 17 (draft) · Course chapter index · Chapter 19 (draft) →