What Is a Use Case Library in SOCs?

SigmaHQ's proc_access_win_lsass_memdump.yml fires when a process opens a handle to lsass.exe with an access mask in its list. That is one behaviour, on one platform, from one telemetry source. It does not tell anyone whether the SOC would notice an attacker stealing credentials. The distance between those two statements is the reason use case libraries exist.

The unit above the rule

A use case is the smallest thing a SOC can plan, staff, and report on. It bundles six things: a threat scenario in plain language, the telemetry required to see it, the detection rules that implement it, the playbook analysts run when it fires, the evidence that it works, and a named owner. The rule is an implementation detail inside that bundle. The use case is the commitment.

The reason for the abstraction is a question that arrives roughly once a quarter. Someone in a leadership meeting asks whether the organization is covered for ransomware. A rule count of any size fails to answer it, because rules are not the unit the question was asked in. Four hundred deployed rules is compatible with total blindness to credential theft, and forty rules is compatible with solid coverage of the techniques that actually precede encryption. The honest answer has the shape "we run eleven use cases mapped to ransomware precursor activity, nine are deployed and validated, two are blocked on missing Windows Security event 4688 command-line logging from the OT segment". That sentence needs a library behind it.

The most widely cited public treatment is MaGMa, published in 2017 by the Dutch FI-ISAC through Betaalvereniging Nederland and released into the public domain. MaGMa stands for Management, Growth and Metrics and assessment. It was built from ABN AMRO's internal framework and it structures every use case in three layers: a business layer connecting the use case to business and compliance drivers, a threat layer describing the attack, and an implementation layer covering data sources and rules. The accompanying spreadsheet ships with a few hundred predefined entries across its L1, L2 and L3 levels, many mapped to ATT&CK. You do not have to adopt MaGMa. You do have to solve the problem it solves.

Anatomy of a use case

The record below is an illustration of the shape, not an export from our own environment. Credential dumping is a good worked example because it has clean artifacts, several implementations, and an obvious business consequence.

id: UC-CRED-002
name: Credential dumping from LSASS memory
scenario: >
  An adversary holding local administrator rights on a Windows host opens a
  handle to lsass.exe, reads credential material out of its memory, and
  reuses the recovered accounts to move laterally.
attack:
  - T1003.001
  - T1003.002
business_driver: >
  Domain credential compromise precedes hands-on-keyboard ransomware in most
  public incident reporting. Loss of the tier-0 admin set is a board-level event.
owner: detection-engineering, named individual, reviewed each quarter
status: deployed
telemetry:
  - sysmon_event_10   # ProcessAccess. Off in many shipped Sysmon configs.
  - sysmon_event_1    # ProcessCreate with CommandLine
  - windows_4688      # needs "Include command line in process creation events"
  - edr_process_events
rules:
  - proc_access_win_lsass_dump          # Sysmon 10, GrantedAccess mask
  - proc_creation_win_comsvcs_minidump  # rundll32 comsvcs.dll MiniDump
  - proc_creation_win_reg_save_sam      # reg save HKLM\SAM
playbook: PB-042 (isolate host, force password reset for every account with a
  session on that host, hunt for reuse of those accounts elsewhere)
validation:
  method: Atomic Red Team T1003.001
  cadence: quarterly
coverage_gap: >
  No coverage on hosts without Sysmon deployed. Dumpers that read LSASS via
  direct syscalls or a signed vulnerable driver may never surface a user-mode
  handle open, so the ProcessAccess rule alone is not sufficient.

Three rules, one use case. That ratio is normal and it is exactly why the rule count is a poor metric. The three implementations catch three different attacker choices:

# 1. Handle open plus memory read, the Mimikatz-style path
# Surfaces as Sysmon Event ID 10 with TargetImage \lsass.exe

# 2. Living off the land, no attacker binary on disk
rundll32.exe C:\Windows\System32\comsvcs.dll, MiniDump 672 C:\Windows\Temp\l.dmp full

# 3. Offline hives instead of live memory, T1003.002
reg save HKLM\SAM C:\Windows\Temp\sam.hiv
reg save HKLM\SYSTEM C:\Windows\Temp\sys.hiv

What the rule catches, what it misses

title: LSASS memory access with a read-capable granted access mask
status: experimental
description: >
  Detects a process opening a handle to lsass.exe with an access mask that
  permits reading process memory.
logsource:
  product: windows
  category: process_access
detection:
  selection:
    TargetImage|endswith: '\lsass.exe'
    GrantedAccess:
      - '0x1010'
      - '0x1038'
      - '0x1410'
      - '0x1438'
      - '0x143a'
      - '0x1f0fff'
      - '0x1f1fff'
  filter_installed:
    SourceImage|startswith:
      - 'C:\Program Files\'
      - 'C:\Program Files (x86)\'
      - 'C:\ProgramData\Microsoft\Windows Defender\'
  filter_wmi:
    SourceImage|endswith: '\wmiprvse.exe'
  condition: selection and not 1 of filter_*
falsepositives:
  - Endpoint protection, backup and inventory agents installed outside Program Files
  - Administrators taking a deliberate crash dump with Task Manager or procdump.exe
  - Some VDI brokers and process monitoring tools that read memory for telemetry
level: high

The mask list is the load-bearing part. 0x1410 is PROCESS_QUERY_LIMITED_INFORMATION combined with PROCESS_QUERY_INFORMATION and PROCESS_VM_READ, and PROCESS_VM_READ is what an in-process reader needs. The rule misses anything that avoids that user-mode path entirely, including drivers and direct syscall implementations, and it misses everything on hosts where ProcessAccess is not enabled in the Sysmon config, which is a large fraction of default deployments. It also does nothing on a host where LSA Protection (RunAsPPL under HKLM\SYSTEM\CurrentControlSet\Control\Lsa) has already blocked the access, which is a good outcome but not a detection.

Writing down what a rule misses is not a nicety. It is what turns a use case record into a coverage statement you can defend. If you want the broader engineering discipline that produces these, we covered it in what detection engineering is.

Lifecycle

Every entry in the library sits in exactly one state, and the state is the thing you report on.

1. Proposed. A scenario exists with a business driver. Nothing is built. Most entries die here, and that is healthy.

2. In development. An owner is assigned, telemetry is confirmed available, rules are being written and tested.

3. Deployed. Rules are live in production, the playbook exists, and analysts have been told the alert can arrive.

4. Tuned. Feedback from real alert volume has been applied. False positive filters are documented in the rule, not in a wiki page nobody opens.

5. Retired. The technique is no longer relevant, the platform is gone, or the control that made it possible was removed. Retirement is a decision with a date and a reason, not silent deletion.

The state that gets skipped is tuning. A use case moves to deployed, produces forty alerts a week, analysts quietly build a habit of closing them, and nobody records that the use case is functionally dead. The library exists partly to make that visible.

Where use cases die

Three causes account for most of it.

No owner. An entry with a team name in the owner field has no owner. Teams do not answer questions, people do. When the source log format changes and the rule stops matching, an entry owned by "SOC" gets noticed at the next audit rather than the next week.

No data source. The use case was written from a threat report, the required telemetry was assumed, and nobody checked. Credential dumping coverage that depends on Sysmon Event ID 10 is worth nothing on whatever share of the estate runs a Sysmon config that excludes ProcessAccess, and that share is rarely zero. Confirming the data source before writing the rule is the single highest-value step in the lifecycle, and it is the one most often skipped.

Wrong estate. Someone read a report about a technique against a platform the organization does not run and built the use case anyway. A macOS persistence use case in an all-Windows shop is not coverage, it is a maintenance liability with a green tick next to it. This is the failure mode that coverage-percentage dashboards actively encourage, because filling a gap in a matrix feels like progress regardless of whether the gap was ever a risk.

What the library actually buys you

Coverage reported as use cases maps to business risk. Coverage reported as a rule count maps to nothing.

The difference shows up the moment a question is specific. "Are we covered for ransomware" becomes a list of use cases with states, owners and validation dates, and every gap in it has a cause you can fund: missing telemetry from a segment, an unstaffed owner slot, or a technique nobody has built yet. The same question against a rule catalog produces a number that cannot be wrong and cannot be useful. It also survives staff turnover, which the tacit knowledge in a senior analyst's head does not.

When to skip the formalism

This is process overhead, and it does not pay off at every size. A five-person SOC where everyone knows every rule already has a working use case library, it just lives in conversation instead of a spreadsheet. Forcing a MaGMa-shaped record with business drivers and quarterly validation cadences onto that team costs real detection engineering hours and returns paperwork.

The overhead starts paying when one of these is true: more than one person writes detections and they do not sit together, an auditor or regulator asks for coverage evidence in writing, or people have started leaving and taking undocumented rules with them. Below that threshold, keep a flat list of scenarios with owners and skip the rest. A twelve-line text file that is accurate beats a governance framework that nobody updates.

Summary

A use case is the unit a SOC plans and reports in, and it sits one level above the rule. It carries a threat scenario, its required telemetry, one or more rules, a playbook, validation evidence and a named human owner. The lifecycle runs proposed, in development, deployed, tuned, retired, and most entries die from a missing owner, a missing data source, or a threat that does not apply to the estate. The payoff is that coverage stated in use cases maps to business risk in a way a rule count never will. The cost is real process overhead, and small teams are often right to keep it in conversation instead.

To build the credential access use case above, start from the rules that already exist: LSASS-related detections and the wider Windows catalog.

Telemetry to confirm before this use case leaves the proposed state:

Sysmon Event ID 1   ProcessCreate, CommandLine field populated
Sysmon Event ID 10  ProcessAccess, lsass.exe NOT excluded in the active config
Windows Event 4688  with "Include command line in process creation events" enabled
Windows Event 4656  handle to object, requires a SACL on the LSASS process
Registry            HKLM\SYSTEM\CurrentControlSet\Control\Lsa\RunAsPPL state per host