Chapter 26 — Security operations and blue team: architecture alternatives
Lesson map
Lesson 26 published. Map, example, EX076.
flowchart TD
N0["Learning outcomes"]
N1["26.1 SOC models"]
N2["26.2 Data platform options"]
N3["26.3 Managed services"]
N4["26.4 Build versus buy"]
N5["26.5 Decision records"]
N6["26.6 Reversibility"]
N7["26.7 Case"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX076"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["26.1 SOC models"]
N2["26.2 Data platform options"]
N3["26.3 Managed services"]
N4["26.4 Build versus buy"]
N5["26.5 Decision records"]
N6["26.6 Reversibility"]
N7["26.7 Case"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX076"]
[Learning outcomes]
|
v
[26.1 SOC models]
|
v
[26.2 Data platform options]
|
v
[26.3 Managed services]
|
v
[26.4 Build versus buy]
|
v
[26.5 Decision records]
|
v
[26.6 Reversibility]
|
v
[26.7 Case]
|
v
[Worked example] --> [Exercise EX076]
Learning outcomes
You will (1) compare SOC architecture models such as centralised, distributed and hybrid; (2) evaluate SIEM, data-lake and managed-service options; (3) weigh build-versus-buy decisions; (4) document architecture decisions with their reasons.
26.1 SOC models
Zimmerman (2014) and Knerler, Parker and Zimmerman (2022) describe SOC structures from small centralised teams to tiered, distributed and federated models. Lindqvist, with one head office and forty depots, runs a small central SOC with depot IT staff as local contacts.
Structure follows size and spread. A tiered model with many specialists suits a large organisation; a federated model suits one with independent business units. Lindqvist's forty depots are too many for central staff to visit but too small to have their own analysts, so depot IT contacts act as eyes and hands on site when needed.
26.2 Data platform options
A traditional SIEM indexes events for fast search and built-in rules. A data-lake approach stores cheaply and queries flexibly but needs more engineering. Many SOCs combine them: hot SIEM for recent, high-value data and a lake for long-term, bulk data.
A SIEM's indexing makes searches fast but costs storage and licence fees per volume. A lake stores raw data cheaply but searches more slowly and needs engineers to build queries and pipelines. Combining them puts data where its use justifies its cost: recent authentication logs in the SIEM, months of firewall logs in the lake.
26.3 Managed services
A managed detection provider can watch at night and bring wider threat knowledge, but knows less about local context and needs clear escalation agreements. Lindqvist considers using one for night coverage.
Night coverage by a provider can be cheaper than a full in-house night shift. The risks are that the provider escalates too much or too little, or lacks context to judge alerts. Clear agreements state which alerts the provider handles, what it may do on its own, and how quickly it must call Lindqvist's on-call engineer.
26.4 Build versus buy
Building gives control and fit; buying gives speed and support. Engineers estimate total cost over several years, including staff time, not just licence price.
A built tool fits exactly but needs people to maintain it after its authors move on. A bought tool comes with updates and support but may force processes to fit its design. Comparing five-year costs, including staff hours for integration and upkeep, often changes the picture from licence price alone. Lindqvist's comparison for its case system shows that a cheaper licence would cost more in integration work within two years, which tips the decision.
26.5 Decision records
Each major choice is written as an architecture decision record: context, options, decision, consequences. Future engineers can see why things are as they are.
Records are short, often one page, and written when the decision is made. Consequences include both benefits and costs, such as lock-in to a vendor format. When a later team wonders why the lake uses a particular format, the record explains the reasoning and the options rejected, saving them from repeating the analysis. Lindqvist stores them next to the code.
26.6 Reversibility
Prefer choices that can be undone. Keeping raw logs in an open format makes changing platforms later possible.
Some choices are hard to reverse: data stored only in a proprietary format may need costly conversion to move. Keeping raw logs in open formats such as JSON lines alongside the platform's own copy preserves options. Reversible choices let a team move faster, since a mistake can be corrected without a major project. Contract terms count too: a short initial term with a vendor is easier to leave than a five-year commitment signed for a discount.
26.7 Case
With storage growing (chapter 6), Lindqvist must decide whether to expand the SIEM or add a lake for firewall and DNS logs.
Expanding the SIEM keeps everything in one place but costs more as volume grows. Adding a lake for firewall and DNS logs, which are bulky but searched less often, keeps the SIEM for high-value data. Amara prepares the comparison with five-year cost estimates and the effect on investigation speed for each log type. The decision goes to the CISO with a recommendation and is recorded as a decision record.
Worked example
Amara's decision record recommends keeping portal, identity and endpoint data in the SIEM for 90 days and sending firewall and DNS logs to a lake after 14 days, with searches from the lake for investigations. Consequence noted: lake queries take minutes, not seconds, so hunt playbooks must allow for that.
Synthetic case. Options and decisions are invented.
Errors and limits
Vendor claims about scale and cost need testing with your own data.
Exercises
- EX076 — Hybrid platform. Explain the hybrid SIEM-plus-lake approach. Rubric: 3 = hot SIEM for recent high-value data, lake for bulk/long-term; 2 = partial; 1 = one only; 0 = none.
- EX077 — Managed night cover. Name one benefit and one risk of a managed provider for nights. Rubric: 3 = coverage and wider knowledge vs less local context, escalation agreements; 2 = one side; 1 = vague; 0 = none.
- EX078 — Decision record. What sections make up an architecture decision record? Rubric: 3 = context, options, decision, consequences; 2 = three; 1 = one; 0 = none.
Synthesis
Compare SOC structures and data platforms on total cost, fit and reversibility, and record why decisions were made.
Continue studying — chapter 26 of 50
← Chapter 25 (draft) · Course chapter index · Chapter 27 (draft) →