◇ OpenCyber Academy
Professional · Chapter 4 · English

Chapter 4 — Detection with ATT&CK and Sigma

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 — Detection with ATT&CK and Sigma

Lesson map

Lesson 04 published. Map, example, EX016.

flowchart TD
  N0["Learning outcomes"]
  N1["4.1 Starting from threats"]
  N2["4.2 Shared rules"]
  N3["4.3 Adapting"]
  N4["4.4 Testing"]
  N5["4.5 Honest coverage"]
  N6["4.6 D3FEND"]
  N7["Rule ownership"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Worked example"]
  EX --> Q["Exercise EX016"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["4.1 Starting from threats"]
  N2["4.2 Shared rules"]
  N3["4.3 Adapting"]
  N4["4.4 Testing"]
  N5["4.5 Honest coverage"]
  N6["4.6 D3FEND"]
  N7["Rule ownership"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX016"]

[Learning outcomes]
    |
    v
[4.1 Starting from threats]
    |
    v
[4.2 Shared rules]
    |
    v
[4.3 Adapting]
    |
    v
[4.4 Testing]
    |
    v
[4.5 Honest coverage]
    |
    v
[4.6 D3FEND]
    |
    v
[Rule ownership]
    |
    v
[Worked example] --> [Exercise EX016]

Learning outcomes

You will (1) map threats to ATT&CK techniques; (2) select detections from shared Sigma rules; (3) adapt rules to the environment; (4) record coverage honestly.

4.1 Starting from threats

The March event combined valid accounts used remotely, account manipulation (adding to an admin group) and data collection from a file share. MITRE ATT&CK (Strom et al., 2018) names these behaviours so detections can be planned and compared. Naming behaviours lets Priya plan detections for each part of March: a rule for unusual remote logins, one for admin group changes and one for large file reads. The ATT&CK names also let her compare her rules with published rules and with the provider's catalogue. The coverage table lists each technique with its rule, data source and test status, so the board can see what Fenwick would detect.

4.2 Shared rules

SigmaHQ publishes open detection rules in a vendor-neutral format. The provider converts selected rules into its SIEM. Priya chooses rules for admin group changes, new-country VPN logins and mass file reads. Starting from shared rules saves time and benefits from others' testing, but converting them can change how they behave. Priya asks the provider to show each converted rule and test it on Fenwick's data before it is counted. The three rules correspond to the three behaviours in March, so replaying that event tests them directly. Each rule's page records the SigmaHQ source, how the provider converted it and who owns it, which is what the provider later peer-reviewed.

4.3 Adapting

Shared rules assume generic environments. Fenwick's IT team legitimately changes admin groups during maintenance, so the rule adds context: changes outside an approved change window are high; inside, low. Without context, the rule would fire on every maintenance change, and the provider would soon learn to ignore it. With change windows, a change outside maintenance raises a high alert, which is what happened in March at 22:43. Priya gives the provider the change calendar and asks IT to record each maintenance window in advance, so the context stays accurate. Tom reviews the rule each month with the calendar to check it is working as intended.

4.4 Testing

Each rule is tested by replaying the synthetic March events and a normal week. Replaying March shows whether each rule catches the attack, and replaying a normal week shows how often it fires on legitimate activity. A rule that catches March but fires constantly in a normal week would overwhelm the provider. The replay showed that the three rules would have raised a critical alert within ten minutes of the March login. Each test is recorded with the date, data used and result, and failed tests lead to rule changes before the rule goes live.

4.5 Honest coverage

The coverage table lists each technique, rule, data source and tested status. Untested rules are not counted as coverage. Counting only tested rules keeps the coverage table honest: a rule that exists but has never been tested might not fire at all. When a rule changes or a data source is replaced, its tested status is reset until it is tested again. The provider later found two rules that would not fire on the new VPN product, which showed why this matters. Priya presents the table to the board with tested and untested rules shown separately.

4.6 D3FEND

MITRE D3FEND (Kaloroumakis and Smith, 2021) helps describe defensive measures, such as account monitoring, in a consistent vocabulary for the board. Using D3FEND terms lets Priya describe what Fenwick does to defend itself, such as monitoring accounts and analysing network traffic, in the same consistent way as ATT&CK describes attacks. This helps the board compare defensive measures with the threats they address. Priya uses it only for description and does not claim that naming a measure proves it works; testing does that.

Rule ownership

Every rule has an owner who answers questions about it and reviews it twice a year. Tom owns the rules for accounts and VPN; the provider owns its standard rules for malware and email. Ownership stops rules from quietly breaking when systems change, such as the VPN upgrade planned for next year.

Rule documentation

Each rule has a short page with purpose, data and first triage steps.

Worked example

Replaying March, the three rules fire at 22:41, 22:43 and about 22:50 (mass read threshold of 1,000 files in 10 minutes). Together they would have raised a critical alert within 10 minutes if anyone had been watching.

Synthetic case. Rules and timings are synthetic.

Errors and limits

ATT&CK describes known behaviours; novel behaviour may not fit any technique.

Exercises

Synthesis

Plan detections from real threats, adapt shared rules and count only tested coverage.

Continue studying — chapter 04 of 12

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