Chapter 4 — Data models | Technologist 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 4 — Data models

Lesson map

Lesson 04 published. Map, example, EX010.

flowchart TD
  N0["Learning outcomes"]
  N1["4.1 Events as records"]
  N2["4.2 Consistent names"]
  N3["4.3 Entities"]
  N4["4.4 Relationships"]
  N5["4.5 Time"]
  N6["4.6 Raw and normalised"]
  N7["4.7 Case"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX010"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["4.1 Events as records"]
  N2["4.2 Consistent names"]
  N3["4.3 Entities"]
  N4["4.4 Relationships"]
  N5["4.5 Time"]
  N6["4.6 Raw and normalised"]
  N7["4.7 Case"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX010"]

[Learning outcomes]
    |
    v
[4.1 Events as records]
    |
    v
[4.2 Consistent names]
    |
    v
[4.3 Entities]
    |
    v
[4.4 Relationships]
    |
    v
[4.5 Time]
    |
    v
[4.6 Raw and normalised]
    |
    v
[4.7 Case]
    |
    v
[Worked example] --> [Exercise EX010]

Learning outcomes

You will (1) describe security events as structured records; (2) define consistent field names; (3) relate events to entities such as users and hosts; (4) explain why consistent models matter across clients.

4.1 Events as records

An event becomes a record with fields: time, host, user, action, outcome, source address. Structured records can be searched, counted and joined.

One lab line becomes a record with time 2026-05-04T01:22:10Z, host CLINIC2-SRV, user reception, action account created and target support2. Once in that form, the SIEM can answer questions such as how many accounts reception created this month, which plain text lines could only answer if someone read them one by one. The same structure applies to the firewall lines, whose source address, destination port and action become fields that rules can filter directly.

4.2 Consistent names

Copperleaf monitors forty clients with different systems. If one calls the field "user", another "account" and a third "UserName", every rule must handle all three. Copperleaf maps all to one common model at ingestion.

Mapping at ingestion means a rule such as alerting on a new administrator is written once against the common field name and works for every client. Without it, Copperleaf would need forty slightly different versions of each rule, and a client whose field name was forgotten would silently get no alerts at all.

4.3 Entities

Users, hosts and clients are entities that persist across events. A table for each holds attributes such as role, criticality and owner.

For BrightSmile the host table holds CLINIC2-SRV with role patient records, criticality high and owner the IT contractor; the user table holds reception as a shared account. When an alert names a host or user, the analyst reads these attributes instead of guessing, and the criticality is what places the alert in the queue. Keeping these attributes in one table means a change, such as a new server role, is made once and appears on every later alert.

4.4 Relationships

A user logs on to a host; a host belongs to a client. These links let analysts ask "which client is this host?" instantly.

The links make questions like Mei's in the worked example easy to answer. From the user support2 the analyst reaches the host CLINIC2-SRV and from the host reaches BrightSmile, so a name that exists at two clients is never confused. The same links answer the reverse question of which users have logged on to a given server in the past week.

4.5 Time

All times are stored in UTC with the original time zone recorded, so events from clients in different zones line up.

BrightSmile's clinics and Copperleaf's analysts may sit in different zones, and some sources log local time. The lab lines end in Z, meaning UTC, so 01:12 in the log is an hour of the night that Mei converts to clinic local time before judging whether it is out of hours. Storing the original zone keeps that conversion checkable later by anyone reviewing the case. Mei's out-of-hours rule in chapter 7 depends on this, since its 07:00 to 19:00 window is clinic local time, not UTC.

4.6 Raw and normalised

The original raw line is kept alongside normalised fields, so nothing is lost if parsing was wrong.

If the parser had split a field wrongly, say putting part of a username into the source address, the raw line still shows what the server actually wrote. Mei can then fix the mapping and reprocess the stored raw lines. For incidents such as BrightSmile's, the raw line is also what the client and any investigator will want to see as evidence. Keeping both forms costs extra storage, but Copperleaf accepts that cost because a lost raw line cannot be recovered later from parsed fields.

4.7 Case

The BrightSmile events from chapter 3 are stored with host CLINIC2-SRV, which links to client BrightSmile and criticality "high".

Because the host links to its client and criticality, the account creation at 01:22 is not just an event ID 4720 on a host name; it is a new account on a high-criticality patient-records server at a named client. That context is what lets Mei treat it as urgent without first looking up which business CLINIC2-SRV belongs to. The same lookup works at every client, so an analyst unfamiliar with BrightSmile still sees immediately that the host stores patient records.

Enrichment

At ingestion, each event is enriched with entity data: the host's client, criticality and role. Analysts see 'CLINIC2-SRV (BrightSmile, critical, patient records)' instead of a bare name, which speeds triage and reduces mistakes when similar host names exist across clients.

Worked example

When Mei searches for "support2", results from two clients appear: BrightSmile's new admin and an old service account at a law firm. Because each event carries the client field, she separates them immediately and confirms that only BrightSmile's is new.

Synthetic case. Records and clients are invented.

Errors and limits

Mapping to a common model can hide source-specific detail; keep the raw record.

Exercises

EX010 — Common model. Why map all clients' fields to one model? Rubric: 3 = rules work across clients without handling variants; 2 = partial; 1 = style; 0 = none.
EX011 — Raw retention. Why keep the raw line? Rubric: 3 = recover if parsing wrong; nothing lost; 2 = partial; 1 = vague; 0 = none.
EX012 — Client field. How did the client field help Mei? Rubric: 3 = separated two clients' support2 accounts at once; 2 = partial; 1 = vague; 0 = none.

Synthesis

Consistent data models make multi-client monitoring searchable and reliable.

Continue studying — chapter 04 of 30

← Chapter 03 (draft) · Course chapter index · Chapter 05 (draft) →